Ai4rei

That's because the server abuses the guild chat packet to make some messages look more fancy. Added: WDGUseCustomFont Changes interface font for all langtypes. binary builds, sources

kRO main (kro-rag) uses 'patch.txt' and kRO sakray (kro-renewal) uses 'patchRE.txt' right now. The only patch server known to me, that used 'patch3.txt' is kRO sakray (kro-sak) from before renewal, which is offline for about 2 years. Don't bother reading if you are not into experimenting and cannot use the command line (cmd.exe/command.com) on Windows.

You can consider my DLLs being an update to Shin's DLLs.

It's client-independent, so you are probably doing it wrong.

Added: WDGChatColorNormal WDGChatColorGuild WDGChatColorParty Controls both the own and others' chat color independently. I should have done that with the public chat as well, but I no longer feel like doing so. WDGChatColorSelf Dropped: WDGTranslateClientIntoEnglish Use WDGTranslateClient instead. binary builds, sources

Added: WDGChatColorGM Changes the public chat text color of GMs to a user-defined color (color-picker). I'd really appreciate someone to test this and report whether or not this actually works correctly, especially the color itself (only tested for matches in 2012-07-02). Afterwards plug-ins for the remaining chat types will follow. Thanks. binary builds, sources

My answer was directed towards M45T3R. No idea what would cause your issue, Rytech.

Your translation file has wrong encoding, looks like UTF-8 to me; or the langtype does not support your language.

afxres.h error is due to the fact, that you probably use Visual Studio Express rather than the full version. The remaining is probably me not considering namespaces or some other C++ oddity.

We have three people knowing (to some extent) how to expand heal/dmg to 9 digits, each of them holding some pieces of the puzzle, great.

DeePee: Can you test, if the following hex (316 bytes) solves your issue? F: 6AFF68AB43730064A1000000005081ECC4000000A160927D0033C4898424C0000000535657A160927D0033C4508D8424D400000064A3000000008BBC24E80000008B9C24E400000057538D442420508BF1E88AFDFFFFC78424DC00000000000000837C24200066899ECC0000000F84880000000FBF8ECA0000008D47EF99F7F9C74424102A0000000FAFC883C10481FB18010000894C24147C08C7442410410100008D4C2414518D542414528BCEE81DC106008D842490000000508D4C241CC744241C14000000E8F4920B008B3594C47C008D4C241851B998FF8700E84FFD23008B542414508B44241452508D8C249C000000518BCEE815A10A00C78424DC000000FFFFFFFF8D4C2418E8215BFBFF8B8C24D400000064890D00000000595F5E5B8B8C24C000000033CCE81936280081C4D0000000C20800 R: 6AFF68AB43730064A1000000005081ECC4400000A160927D0033C4898424C0400000535657A160927D0033C4508D8424D440000064A3000000008BBC24E84000008B9C24E440000057538D442420508BF1E88AFDFFFFC78424DC40000000000000837C24200066899ECC0000000F84880000000FBF8ECA0000008D47EF99F7F9C74424102A0000000FAFC883C10481FB18010000894C24147C08C7442410410100008D4C2414518D542414528BCEE81DC106008D842490000000508D4C241CC744241C14000000E8F4920B008B3594C47C008D4C241851B998FF8700E84FFD23008B542414508B44241452508D8C249C000000518BCEE815A10A00C78424DC400000FFFFFFFF8D4C2418E8215BFBFF8B8C24D440000064890D00000000595F5E5B8B8C24C040000033CCE81936280081C4D0400000C20800 Basically it increases the stack of the crashing function, but since there is no stack frame, writing a plug-in for this is rather painful. 64K hairstyles changes the order of hairstyles 1-12, so you have to fix up you palettes to continue working properly. In the days of RUNE, there was a hairstyle data pack, that updated the official hairstyles to work properly with this diff, but I wonder if something like this is still available. WDGEnableMultipleGRFExtended Everything to be said is here: And before someone says, max. damage != max. skill damage, the function that takes care of the numbers is shared by both.

Not going to do this one due to paid service constraints.

Stack-based buffer overflow, probably did not take the multi-language prefix into account. Will see what can be done about it. Queued.

Added: WDGTranslateClient Only basic functionality tested, error-conditions are untested. The file has to be in same folder as the plugin. binary builds, sources

Do pets/monsters speak Korean with 'recent clients' or do they not speak at all? If not at all, then I assume it's a job for the server now, to make them speak. Edit: Since there were little file parse difficulties in the translation plug-in, I had to alter the file format a little. This is current candidate for implementation: // WDGTranslateClient.txt // // == Format ======================================================= // // Only comments recognized are lines prefixed with '//'. Indented // and trailing comments are not supported. // // Each translation is a set of two lines, the earlier being the // original text (CP949, EUC-KR is fine too; UNICODE/UTF-8 is not) // and the latter being the translation to place into the client. // // The length of the translation is limited to the length of the // original string plus 1 aligned to be multiple of 4, minus 1. // // Example: // - "asdf" = 4 +1 (zero termination of the string) = 5 // - Next multiple of 4 for 5 is 8 (2x4) // - 8 -1 = 7 characters usable for translation string // // Lines to look for start with 'F:', lines with replacement string // start with 'R:'. The line syntax is the same as the one used for // matches within the plugins. That is, literal strings are enclosed // in ' everything else is interpreted as hexadecimal bytes. // // Example: // | // Bytes can be separated by spaces... // | F:C4 C9 B8 AF C5 CD 20 B8 B8 B5 E9 B1 E2 // | R:'Make Character' // | // | // ...but do not need to. // | F:28C4B3B8AFC5CD2FC3D120BDBDB7D429 // | R:'(Used / Total)' // // Do not use byte 00 at the end of strings, as it is appended auto- // magically. Do not use it within strings either, unless you have a // really good reason to do so. // // Partial strings are not matched, the original string is always // assumed to be complete. Since mismatches are still likely to // occur for shorter strings, place longer strings at the beginning // and the short ones and the end of the file. // // ================================================================= // Translate Delete Time // F:2564BFF9202564C0CF202564BDC3202564BAD0202564C3CA R:'Delete: %d/%d - %d:%d:%d' F:2564B3E2202564BFF9202564C0CF202564BDC3202564BAD0202564C3CA20 R:'%d/%d/%d - %d:%d:%d'

I'll see what can be done about it. While I personally do not like that "if it's not there, try the other", but I get your point. I'd probably go the "if it's not in 악세사리/<gender> try 악세사리/ instead" way, then.

2012-07-02aRagexeRE ____________ Edit: Updated: WDGUseRagnarokIcon Made it work with recent clients.

I don't think it is normal, yet the diff only changes the packet being sent, as such should be unrelated. I'll test it when I get around to do that. oh ok. thanks. i would wait for the confirmation. It does not crash for me. Of course the client closes, but that happens even without the patch, by design.

Peopleperson49: Mind taking this to the appropriate support section? Your problem is completely irrelevant to this topic.

Was applied to packet 0x81, extended it now to cover packet 0x6A as well. I don't think it is normal, yet the diff only changes the packet being sent, as such should be unrelated. I'll test it when I get around to do that.

The plug-in has a mission, but no code yet. Decided to spend some time on RO Patcher Lite again.

What did you enter as parameter? Works fine for me (tested with parameter 4096, and *mes with 4000 dots). Then apply custom aura sprites and use empty aura sprites.

For one: And the other is: I have obsoleted the 'restore login window' diff in favor of packet 0x825. This also applies to my own login window restore hex.

Try WDGAlwaysCallSelectKoreaClientInfo. I do not support the login window restore and any stuff associated with it. conf/battle/client.conf: max_lv: 98 And set bit 1 in client_limit_unit_lv if not already set, that should do the trick.