Ai4rei

Updated to 4.1.3, this release fixes an assertion when applying optimized patches. Updated to 4.1.4, this release adds support for the new, short-lived (2021-11-03 ~ 2021-11-17) kRO Sakray server. This is a different server from the one removed in 4.1.2 and requires a new full client. There is no mirror support for this one and it is released only as part of the bundle package.

Which one?

DirectDrawEnumerateEx... Driver: NULL - DriverDescription: dgVoodoo DirectX Wrapper - DriverName: display - Monitor: 00000000 DirectDrawCreateEx... done (hr=0x80004005). Driver: {5462FCC8-45ED-451E-A2CF-E57E8EF80122} - DriverDescription: Intel(R) HD Graphics - DriverName: \\.\DISPLAY1 - Monitor: 00010001 DirectDrawCreateEx... done (hr=0x80004005). DirectDrawEnumerateEx... done (hr=0x00000000). Creating the DirectX devices fails with E_FAIL. Most likely a problem with dgVoodoo (bad configuration or insufficient hardware). See which files of those listed in the dgVooDoo2 manual are inside the non-working RO folder (only) and try to remove them (most likely ddraw.dll or d3d9.dll). Alternatively you can try troubleshooting dgVooDoo, but I have no experience with it and it is beyond the scope of this topic.

May I ask you to run DevInfo (http://ai4rei.net/soft/#devinfo ) in the RO folder where 1) it does not work 2) where it works and report back the results. [2021-07-16 09:03:07.095][Info] Enumerated 0 DX7 drivers. Normally this result is not possible (either it finds something or fails), but I have seen the enumeration to crash internally in the RO client before and returning success without doing anything.

@unrestricted According to the screenshot, DirectDraw is disabled, which is necessary for RO, so I cannot believe other servers work fine. For Windows 10, a 2016 driver is rather old, so he might want to try reinstall the driver for integrated graphics (if possible with a recent driver from Intel's website, unless the computer is old). In addition, retrieve the opensetup.log (SHIFT + ESC in OpenSetup) for more troubleshooting.

Updated to 4.0.1, this release fixes, among others, an issue that prevented updating jRO RAG (thx to @legendx for reporting), when there are more than one year worth of patches to apply. -- This should fix your problem @legendx and @napasaro.

If you could provide all of the problem details, it would be good. If you cannot recreate it, it should be recorded in the Event Log (Application category, Appcrash Event) as well. For now I only see, that the 32-bit patcher tripped a should never happen guarded scenario.

Works for me™. Try recreating the folder and/or check security permission of that folder (at least read/write current directory). From the screenshot it does not look like you use Windows 10, so there is probably no defender to interfere, but if you use an AV software, try disabling that temporarily to see, if that helps. Report back whether that helped or if a follow up is needed.

What is the path to the patcher? Like C:\RO\...

As stated before, a GRF is needed. The patcher will not attempt to create a GRF if it is missing or otherwise invisible. In this non-standard scenario you have to create a zero length data.grf to fool the patcher into thinking, that it just created the GRF. This may sound like a bug, but has been a feature since v2.0, though in the past the patcher created the GRF without nagging. The main reason for the change was, that if you are sharing one data.grf between multiple RO servers, each in a different folder, you may forget to return the GRF back before patching and end up with something incomplete. Basically it makes you aware, that you misplaced the GRF and should look for it before you start patching it. It's a patcher after all, not a GRF tool. TL;DR: If there is no GRF, patcher will not work. If you do not have one, make a zero-length GRF.

The provided source is not complete (thus for reference only). The latest commits were preparation work for the ROCred+RSU merge, so please wait for that. There won't be further stand-alone ROCred releases.

2010-07-30RE is broken, use 2010-07-28RE or 2010-08-04RE. RO OpenSetup This will tell you, if there is something wrong with your RO folder in regard to setup. If there are no resolutions to choose from, make sure: Your graphics card drivers are installed (Microsoft Basic Display Adapter is not a proper driver) No mirror driver is running (ex. VNC/RDP server) If it still does not work, you can try providing the output of this or that.

At least an empty grf file, though why would you use the patcher without files?

Updated to 4.0.0, this major release contains a refreshed UI, completely reworked GRF engine, native 64-bit builds and other, far too many under-the-hood changes and bug fixes to mention them all, see included doc/history.txt for details.

That differs by server, even on official, sometimes significantly. Doing find/grep on your npc folder is probably all you need.

For various reasons an idea came up, to have a reverse search (or search-by-image) function in the NPC list. The question is, would there be general demand for such a function, or not?

Sakray data too old, only clients from 2018+ are supported. Older clients will be only supported, if someone provides a mirror server for that.

Àΰ£Á·\¼ºÁ÷ÀÚ\¼ºÁ÷ÀÚ_³²_´Ü°Ë_°Ë±¤.act Hair style has nothing to do with that. The missing file corresponds to a male (남/³²) acolyte (성직자/¼ºÁ÷ÀÚ) with a dagger-type weapon (단검/´Ü°Ë). Acolyte classes generally do not wear knifes or daggers, so this resource does not exist in regular data. Changing jobs should un-equip all equipment to prevent this sort of errors, but for some reason, it did not in your case. Edit: Just noticed, this thread is pretty old.

Create a thread in a DLL, that displays a topmost window with a bitmap in it and close it when the main window is created (which can be detected in various ways, for example polling with FindWindow). That DLL must be added to client's imports (or recycle an existing one if you know how). Edit: For example like this: https://github.com/ai4rei/splash

Updated to 2.14.2, adds /mable and /zoom, updates Japanese and Russian translation and fixes UI glitches and a bug in logging.

Updated to 2.4.28, fixes file corruption caused by back-ports from trunk, that were added to 2.4.26. Please read follow up instructions, if you update from 2.4.26 or 2.4.27.

That's always an option, but that does not fix the patcher. A bugfix is underway.

Seems .26 broke RGZ unpacking and since kRO has been resetting rdata.grf, it got corrupted. But no worries, the GRF will recover after I fix the patcher.

Updated to 2.4.27, fixes possible buffer corruption (security issue).

https://www.lua.org/manual/5.1/luac.html https://sourceforge.net/projects/luabinaries/files/5.1.4/