Yommy

I have noticed too, Asking for help from the community on complex projects is hard. there is like 1% that have enough skill to help, and of the ones who can, none want to dedicate time to another project. same with some of my projects (plenty of people will happily use the project though) YomRawr

for anyone that is interested.. I committed some changes, added ability to test a specific patch against all clients, so we can see when a patch starts to fail

Thank you for a nice effort I just spent a few minutes adding support for diffgen to download the last 150 clients into a folder which will be used for pattern testing. i will make something to try a specific patch against all the clients in this folder, to find exactly when things break Yom

when i get some time, i will write up some documentation about what packets are, and how they are structured and i really hope people release the scripts they capture from official servers, to make rAthena better. the script mode could probably be expanded more too, but i am too busy for this

Something that the project requires.. Sometimes a pattern breaks, and we need a way to check a specific pattern against all the clients. (and something to fetch about a years worth of clients) so we can find exactly when the pattern fails

http://rathena.org/wiki/Packets look around 0x287, these have been public for ages i didnt add support for old clients yet, i will add this soon but really i wanted people to help with the project. if you can capture the correct packet, you can do anything

C = Client Z = Zone(map server) A = Account(login server) H = cHar(char server) CZ = client to zone ZC = zone to client These are official packet names how gravity programmed them i tried to login to kRO months ago, but i failed to capture any body relocation packets and i couldnt make any char to do this skill but yes, it could capture the packet sequence used

yay, someone understands and the intention was meant for capturing dialogue of official server scripts that rAthena does not hold yet and also it was to show a single use of this framework, it can capture any data, mob info from sense, etc but the main usage was for analyzing new packets to add support for new clients in rAthena any ideas?? edit: maybe due to my slow connection I'll try to other machine.. this is probably due to incorrect plen file, and packet at 31 has an incorrect length be sure to use a plen file extracted from the actual client used to connect using the tool in dev folder

This is kRO Main client, and this is another example of the power in this tool, it was simple to capture and understand the packets in this new cash shop it works on a packet level, so unless some server uses some strange packets or encryption, it should work or could be made to work

Well this cannot take script functionality, this still needs to be programmed, the tool can only take data sent in packets...,npc locations, dialog, menus, options chosen, everything else will still need to be programmed its the same as writing down everything the npc says, and creating the npc yourself

This is a personal project i was working on while i was analyzing the ragnarok network protocol. It started several years ago, and could only read wpe .pac captures, and displayed some basic output of the network traffic. Now it displays 95% of all packets, and shows all the data structures inside each packet. furthermore, it now uses a dll injected into the client, which sends all packet data to the parser for real-time analysis The Parser can use diffrent modes to output or record data captured from the packets, the image above being "full_info" And this is a simple test showing a capture of NPC data, to reconstruct scripts in real-time and saves to file. This mode is intended to ease dialog capture from official servers with new npc's that rAthena does not have. But the main function is to analyze the network protocol,to see the order packets are transmitted and to allow new client features to be added quicker. I rewrote the parser at the begining of this year, with a more OOP based style, but some sources of packet data are not working/missing dll injection - working good capture with winpcap(taking packets direct from network card) - broken with bad connections, due to tcp retransmission, which i cannot figure out wpe .pac reading - still to be added back svn location : https://www.assembla...ubversion/nodes As with most of my projects, PHP needs to be installed as this is PHP Command line scripting. for this to work you have 2 options 1) edit the bat file, and change 'php' to the location of your php.exe 2) add your php folder to windows paths, so you can call php from anywhere.. http://www.php.net/manual/en/faq.installation.php#faq.installation.addtopath If anybody has any interest or wants to help improve, send me a message YomRawr <3

I think its time to release this more public, and try to revive the whole project. So i am asking if anyone who can code PHP and knows how to modify client ASM code wants to help DiffGen is a small framework we wrote to generate .diff files, it uses patterns with wildcards to find the patch locations Naturally these patterns fail when gravity significantly changes parts of the client source, but these are easy to fix up. (except when gravity changed compiler to vc9, and broke *every* pattern ) Also the core can be used for other tasks, as demonstrated with the XtractMsgStringTable and XtractPacketLength patches When the compiler change happened, we rewrote DiffGen as DiffGen2, fixed all the patterns, and also made xDiffGen2, which outputs the diff files using an XML format, and added the ability to use variables for some patch values. so then the diff patcher can do things like "set custom window title" or "set chatbox text length" in the patcher. Because of this feature, there was no diff patcher that supported the new xDiff, so LightFighter created a new patcher and even included support for "profiles", to store your selected diff options, etc. Anyway im drifting.. Onto the goods, Requires PHP installed (and the php path to windows) SVN is located at : https://subversion.a....com/svn/Yommy/ The main goal of the project is to make an amazing diff generator, which can easily be extended the core functions are simple to use, which makes the patch files easy to create. If anyone wants to help with the project, just register an assembla account and send me a message on here explaining your intentions and if anyone wants me to explain how something works, just ask YomRawr <3

Another note that may interest, It is not required to compile the lua, a simple rename to .lub and the client can read it without problem Compiled lua is harder to read, but anybody with common sense can decompile Yom <3

type /showname maby you accidentally patched the option to default enabled, or didnt patch to disable it, or something o_O

install is supported when using cmake you can specify where by setting INSTALL_TO=path and CMAKE_INSTALL_PATH=/where/to/install/ by default it installs to the subdir install/

Your method seems wrong, I think it would be easier to create new items for each refine level. And I'm sure the stackability is defined in the server Another method would be to change the type to be weapon with onequip to delete item, but that would make it in the wrong inventory section. The hex edit is quite advanced and to do this every client update would be a pain for anyone using this system Yom <3

http://subversion.assembla.com/svn/lubtool/trunk/ i did not public it because its nowhere near release code, not even alpha code just enough hacked code to make some output. good luck understanding it Yom <3

my request - remove the renewal its not needed anymore, for a long time i once did a grf compare, and 99% of files in rdata.grf was binary exact in data.grf in 2 weeks, that 1% will be merged to data.grf, and a new 1% added to rdata.grf i guess people still think you need the renewal client for renewal/3rd class. this is wrong, its been in main server for a long time. and if you are really set on including it you should remove the files from rdata that is same in data (unpack data and rdata to separate folders, compare folders with "beyond compare", delete files from rdata folder that are same, repack. you will see it drop to a few megabyte total) this should save alot of bandwidth and less download for people Yom

i think it would be best, if we put PreRE into its own branch. and then Renewal into the trunk as active development. it might help to remove all backwards compatible support for older clients in this renewal trunk. there is way too many #ifdef packetver this should make the code alot cleaner and easier to debug.