Ai4rei

I don't mind as long as there is sufficient feedback when it does not work, since I do not have time to actually test it on various clients; I only test whether the hex in itself is applied correctly.

EvilPuncker: Updated WDGTranslateClientIntoEnglish, decided to call it "Make Character", though (interface and source calls it that way). Expect shared palettes this weekend, unless somethings screws up my free-time. WDGRemoveQuakeSkillEffect and WDGRemoveHourlyGameGrade are in testing. Remaining stuff should be done within next days. Judas: There is a WDGDisableMultipleWindows already.

Added WDGEnableAsciiInText and WDGRemoveHourlyPlaytimeMinder (binary builds, sources). Also before someone asks, I won't do anything to unpack themida clients (time consuming), but... I see a chance for hot-patching becoming the next "diffing" method.

In an attempt to recover the lost changes to get the source to the state of the last binary release, I'd like to ask you (when you have the time) if you happen to have an, at least approximate, list of the changes missing.

So far I'm reading into the SDK and related code to get how it works. Enable ASCII characters will come, too.

Then let me pull some assumptions out of my sleeve, correct me if I'm wrong. Shared Palettes Makes the client use the same clothes palette set (ex. body_<id>.pal) for all classes instead of having to make a palette set for each class (<class>_<gender>_<id>.pal). Disable (Multiple) Windows Preventing the client from being started multiple times simultaneously.

I wonder why I haven't noticed this earlier. Then if there is still interest from the community, I would resume the development as part of the atwl project, of course while keeping the attribution intact. Kind of reminds me of my HDD crash, were I was about to lose sources of all projects, and I don't want this project to die either.

It does not match for most recent clients, that's why I wrote, that I need a client version, if it does not work for someone.

Squishyyy: Whether your OS is 32-bit or 64-bit does not matter, as long Gravity does not release a 64-bit version of the RO client. MuzTank: Do not change the OptionInfo.lub in \RO\System . Also the registry part (yes the Lua setup still saves few settings in the registry) needs Admin rights, which the setup should ask for. Actually, you should not even be able to run the setup without administrator rights.

Hmm... I have written a hex before for this. If it does not work for you, you will have to tell your client version (XXXX-XX-XXyRagexeRE).

crypt.cpp looks pretty familiar, so I don't think you should attribute it to yourself when you did not write it, but only modified it a little.

Have tested the most recent version with a clean 2012-04-10aRagexeRE and it starts without warnings, with specified resolution (ex. 800x600). Taking the second error message into account, you are probably missing option defaults lub file, or rather the entire system folder in your RO folder. Following files should be in there: \RO\System\MsgString.lub \RO\System\OptionInfo.lub (read-only setup defaults + OptionInfoList and CmdOnOffList declaration) \RO\System\Towninfo.lub (2nd error message) \RO\System\itemInfo.lub \RO\System\Font \RO\System\Font\RixSquirrel_12.eot \RO\System\Font\RixMiniHeart_10.eot \RO\System\Font\RixNHCgogo_10.eot \RO\System\Font\RixSquirrel_10.eot \RO\System\Font\RixMagic_10.eot \RO\System\Font\RixLoveangel_10.eot \RO\System\Font\RixLoveangel_12.eot \RO\System\Font\RixJJangu_10.eot \RO\System\Font\RixKid_10.eot \RO\System\Font\RixFreshman_10.eot \RO\System\Font\NHCgogo_10.eot \RO\System\Font\NHCgogo_12.eot \RO\System\Font\RixDiary_10.eot \RO\System\LuaFiles514 \RO\System\LuaFiles514\OptionInfo.lub Override settings (OptionInfo.lua) saved by Setup and Client are in SaveData folder. Because the official setup does this as well to keep settings written by the client.

Hmm... both should be equivalent Lua code, can you tell me any error messages the client is printing? The latest version has been thoroughly tested with 2012-07-02aRagexeRE. The source is not up-to-date and does not support Lua clients, you might want to tell me the errors you got while compiling though.

Released v2.4.0, resolves issues with Lua settings not being used by the client, among others. Updating is highly recommended.

It's not open as in open-source, but open as in free. That does not prevent me from releasing the source on some occasions, though.

There's a bug in OpenSetup, which causes the client, among others, ignore the window size settings. Fix is in progress.

Released v2.3.0, with Czech and Korean translations; no functional changes.

Released v2.2.0, with Brazilian Portuguese and a couple of fixes.

There's an issue with certain range of clients (those before 'savedata' update), that read the settings from the old location and save them to the new one or the other way around. You might want to try changing "data\lua files\optioninfo\optioninfo_f.lub" and use the setup that was current at the time the client was released. Lua-Opensetup only supports savedata location and disregards optioninfo_f for now.

ftp://ragnarok.nowcdn.co.kr:20021/Patch/<file> example: ftp://ragnarok.nowcdn.co.kr:20021/Patch/2012-05-29bragexe.rgz Edit: was too slow

It does already, as stated in the post above yours. iRO is part of said bundle.

The RO client changes it's priority class depending on whether it is active (normal priority) or not (idle priority). So when you switch back to the client from the application used to set the priority class (taskmgr/procexp), the priority class is not kept.

Fits, thanks. I'll see how Windows calls "Codepage" on pt-BR locale. The translation will be part of the next release.

Thank you very much. There are just two small issues. "Placa de vídeo VooDoo3 instalada" does not fit the UI, it has also been changed to just "VooDoo3 graphics card" in the last release, since other languages had problems to fit in as well. The other don't know if you left "Codepage" (ROExt) as is, intentionally or just missed it.

Thanks, updated the explanation for /stateinfo.