Ai4rei

No.

Any specific resolutions? The client works in pretty much any configuration, including FullHD, both windowed and full screen. Though I'm aware of some graphics card+resolution combination that causes the screen to go ////, but haven't been able to reproduce it myself, yet. Edit: Ops, did not notice it's a year old topic...

The only available mirror server broke. Edit: Should be fixed after all files get back online. Should work now. Edit: Updated to 2.4.9, fixes, among others, some elevation-related issues.

Updated to 2.4.8, adds support for ASLR and DEP, improves kRO mirror balancing and the GRF repacking scenario.

Looks certainly interesting, I wonder what will Gravity think of it

There were issues with debugging and parsing unpacked clients, due to varying quality of the unpacks.

I assume you refer to 2014-10-22b. That client is Themida infested, so no.

If you have control over app.exe, you can launch app.exe and make it in turn launch the client.

ActionType=0 (1 if you want to make the launcher close)ActionData=PatcherName.exe Edit:Updated to 1.9.2, adds support for ASLR/DEP. Some code maintenance.

The client uses those registry keys, whether you want or not.

The random value is the current fade-volume of the bgm; as you close the client, the BGM fades out asynchronously, and depending on when the saving kicks in, it uses that value (that's the last fix about). Though since E0h is indeed BGM volume and E4h fade-volume, and E8h effect-volume, it's interesting that SFX affect BGM with this patch. Could you look, if HKEY_LOCAL_MACHINESoftwareGravityRagnarok or HKEY_LOCAL_MACHINESoftwareGravityRenewSetup is somehow affected with and without the last patch?

Try this instead then: F: 8B82E00000005068R: 8B82E40000005068

Make a backup of your client and try the following patch: F: 790233C08981E40000008B491C85C97408R: 790233C08981E00000008B491C85C97408

Nothing out of the ordinary, so it probably is as zackdreaver said.

Undo the changes, as these were error conditions. If they do not apply to you, then it was already OK. Can you post a screen-shot of your RO folder?

Do you... - have a OptionInfo.lub file in your savedata folder? - have a OptionInfo.lua file in your savedata folder with a read-only attribute set?

That client looks into SystemLuaFiles514 instead of System.

What client version (date) do you use?

That is not the correct way to solve it. Actually OpenSetup should tell you upon saving settings, what is wrong with your settings files, see the opensetup.log file. If it tells you, that you are missing OptionInfo.lub in your RO System folder, you can get it here.

Looks like a feature to prevent unintentional Zeny-overflow during vending.

Would it be possible to have a screenshot and client version? Edit: Two fools, same reasoning.

/camera controls the "lazy camera follow movement" when you walk (it looks as if the camera is not keeping up with your movements). Changing the mouse-wheel direction for zooming requires a modification of the client, which if done improperly, causes the window scroll-bars to reverse-move as well.

No you cannot, but whether the bitmap is compressed in GRF or saved as PNG does not make that much difference anyway (among others because they use the same kind of compression). Also JPG is lossy, so transparency magenta would bleed out. Example: - Bitmap: 622 KB - Bitmap in GRF: 125 KB - PNG: 107 KB - PNG in GRF: 107 KB