Skotlex

I strongly suspect that the custom aura patch no longer works. At some point Gravity changed the aura system to use "ring_.tga" (with a few colours there like red, blue, black and white) instead of "blue_ring.tga". pikapika2.bmp and freezing_circle.bmp are still in intact (in texture\effect\). It didn't work in the client I tried patching (2013-03-20e), but I guess it just doesn't work with any of the 2013 clients. Has anybody here managed to use the "custom aura" patch? This should be at least noted on the opening post.

Hmm.... I had this bug just now, and it turns out (in my case) that the problem was some outdated code. rAthena trunk should work correctly, so perhaps this is caused by some custom code bug. The specific issue was that I was using an older char-server codebase, and my char-server was sending back after authentication (0x2727 in parse_fromlogin) mmo_char_send006b() instead of mmo_char_send(). What this means is, if you just send 006b, you are only sending packet 0x6b (character list), whereas the server should send (for 2013 clients) packets 0x82d, 0x9a0, and 0x20d. In particular, I think the problem lies in packet 0x82d, because this is the one that sends in how many characters you are allowed to have (sd->char_slot, which defaults to MAX_CHARS if character_slots is zero in the account database). In any case, rA-trunk should be correct, so I suggest you look closer at what packets are being sent/received so you can figure out where the actual bug is.

Have people truly not solved this yet? Or I just haven't bumped into the proper thread? In any case, there's a way to solve it by modifying the lua files. In "lua files/optioninfo/optioninfo_f.lub" look for the function "SaveToFileCmdOnOffValueEx(nID)" and just add the proper lines: function SaveToFileCmdOnOffValueEx(nID) if nID == 0 then saveFile = io.open("SaveData\\OptionInfo.lua", "w") else saveFile = io.open("data\\OptionInfo.lua", "w") end if saveFile ~= nil then saveFile:write("CmdOnOffList = {}\n") saveFile:write("OptionInfoList = {}\n") for k, v in pairs(CmdOnOffOderList) do local value = c_GetCmdOnOffValue(v) if value ~= -1 then saveFile:write(string.format("CmdOnOffList[\"%s\"] = %d\n", v, value)) end end saveFile:write("\n") io.close(saveFile) end end The lines added (if you can't spot them) are "saveFile:write("CmdOnOffList = {}\n")" and "saveFile:write("OptionInfoList = {}\n")"

I don't know if this was asked before (can't read all 26 pages of this thread), but is there a way to increase the palette limit for clothes? I was trying to update my client here, but I noticed that the client only supports (I think) 512 colours, as dye numbers above that just display a black-silhouette sprite for the body. I am using shared-palettes type 2 and the 2013-03-20e client, if those matter.

Hmm.... I do have some objections to the idea behind this. It is troublesome that there are two places where packet definitions are stored (clif.c and packet_db.txt), however there is a reason for this: The packet_db file stores packets and their structures as they are received/sent by clients. clif.c holds packet lengths and definitions for replies to the client. The server uses a PACKETVER define to decide how to structure packets before replying. Why it can't use the packet_db information itself? Well, besides code-complexity, in many cases you don't know which version are the multiple recipients. And, you can always use an older PACKETVER value and the clients will still work as they usually have no problems accepting old packets as replies. The packet_db file is useful because it allows people to add the information required to parse new clients without having to modify the server code (by simply mapping the new packets to previous versions, or mapping them to be discarded if they cannot be supported yet). clif.c is slightly smart in the sense that clif_send calls will drop packets that are not supposed by a client (so if a server creates a response using a newer packet which is not supported by a target recipient, it will be dropped). However, this only applies to area packets that are send to multiple targets, not those who are directly sent to a single recipient. I suppose it would be possible to rewrite the system to use a single packet_db file that also includes the structure for server-reply packets (thus deprecating the need for PACKETVER), but that would require an almost complete rewrite of most functions in the clif.c file. Hmm... all in all, this would be no minor task. I do agree that server auto detecting the client version is no easy task (using the wantToConnect packet to identify the version), though it already doesn't hurt to leave the guessing in place, rather than lock down the server to supporting a single version.

Hmm... may I suggest a new release version after the website gets restored? Is not that people shouldn't update and we need new Miruku updates every few months... but...! The fact that you don't need to bundle "Ragnarok Renewal" (because renewal is already included in the basic RO install) would mean a nearly 50% size savings reduction, and I think that's a very important detail for any and all future downloads. It just irks to me think that we are wasting so much disk space (and bandwidth) when getting this client package...