Localhost Workshop

This is like Gods work. When you have the time can you please provide one for GMS version 111?
You can find the setup in
Thanks in advance!:D:
 
That 4GB thing, the "GFX issues": Are you talking about that annoying problem where if you enter too many maps in a server (v83 for example), and you begin to see things disappear, ending with a crash? Would be nice to have a 4GB v83 version of that. I'm assuming it's 4GB due to something relating to it being a 32-bit program.
 
I'm getting a popup with 'Failed to Initialize nProtect KeyCrypt (2)' after the Wizet screen when launching both v62 clients with wine on win98... Trying again with XP/7/10 the message is the same, only with (2) becoming (1114).

I see @thepack was able to get v62 running on Linux, so am I missing something here?

I'm able to get the v68 client running with wine though!
 
Last edited:
xcbxcbcxb
 
Last edited:
@neeerp

I don't actually have wine installed on my host. It's all dockerized and I bind-mount my X11 and pulseaudio sockets onto the container. What version of wine have you tried with v62? I got it to work on wine 6.23. I did see your error about KeyCrypt, though. What worked for me was NOT using WINEARCH=win32 when initializing winecfg. Also, I did not have to change the OS target (Windows 7 by default on wine 6.23). Perhaps try removing your ~/.wine directory and doing a winecfg from scratch?
9sin

That's a hack to get v62 working on wine a long time ago. You had to do set an environment variable WINEARCH=win32 and then set the target OS as 98, along with putting 2 extra dlls into your wine directory. This guy did it 9 years ago https://forum.ragezone.com/f922/maplestory-v62-linux-wine-896880/ and I was able to replicate his success only on a Linux Mint VM. Didn't work with docker unfortunately.
 
sdgbxcxbxcb
 
Last edited:
That 4GB thing, the "GFX issues": Are you talking about that annoying problem where if you enter too many maps in a server (v83 for example), and you begin to see things disappear, ending with a crash? Would be nice to have a 4GB v83 version of that. I'm assuming it's 4GB due to something relating to it being a 32-bit program.
agree
 
@Hendi48 Thanks for the god work!

I always want to make a VMS server and i request you to make this localhost. This is the only client i get, this VMS is around 2008 and doesn't have Pirate Job, only 4th job available.

Here is the full file setup:

Thank You,
 
@Hendi48 Thanks for the god work!

This is TMS V90 and here is the full file setup:

Thanks alot.
 
Hendi48 I'm using the dockerized Java server that I created https://forum.ragezone.com/f427/v62-docker-1150928/ . Zero disconnection problems when I used to own an actual Windows computer dedicated to playing the game, albeit with a different .exe on that machine.

Have you tried GMSv62_4GB.exe on wine? One scenario that I've come across that seems to disconnect me quickly (like, within a few attacks) is killing mobs in HHG1 with the boomerang step attack. Spawning Zakum also takes me back to the login screen within a few minutes. Mind giving that a shot? Thanks!

I've investigated this issue and was able to reproduce it with your container. It's not an issue with Wine or the 4GB client. I ran the server on WSL2 and the client natively on Windows 10. The disconnect happens because the client fails a packet verification check, meaning it received bogus data from the server. This can happen because of lacking synchronization when the server is encrypting packets concurrently. A fix that seemed to work for me in your source is to move the getPacketHeader call into the synchronized block in MaplePacketEncoder.java. Said function accesses the IV, which must always be guarded for concurrent access.

Now the interesting question is, why does the issue not occur with the existing v62 localhost? Well, that's because someone went and patched the check in the client to skip invalid packets and go to the next one. Patch the client in order to compensate for crappy servers. Can't make this **** up lol.
 
I've investigated this issue and was able to reproduce it with your container. It's not an issue with Wine or the 4GB client. I ran the server on WSL2 and the client natively on Windows 10. The disconnect happens because the client fails a packet verification check, meaning it received bogus data from the server. This can happen because of lacking synchronization when the server is encrypting packets concurrently. A fix that seemed to work for me in your source is to move the getPacketHeader call into the synchronized block in MaplePacketEncoder.java. Said function accesses the IV, which must always be guarded for concurrent access.

Now the interesting question is, why does the issue not occur with the existing v62 localhost? Well, that's because someone went and patched the check in the client to skip invalid packets and go to the next one. Patch the client in order to compensate for crappy servers. Can't make this **** up lol.

Ha, you're telling me the client I used to be using all along had been patched because they couldn't get around a race condition on the server.

I moved into the first line of the synchronized block and it works like a charm. Thanks, Hendi. I commend your godly skillz and truly appreciate the help!


@Hendi48 If you don't mind me pestering you once more, do you mind checking this out?



It's a process to convert v62 .wz files (except List.wz) into XML dumps, then convert those XML dumps back into encrypted .wz files. The use case for this is to be able to "edit" .wz files (by just changing plain old XML files) without having to use the harepacker GUI. When I use those re-encoded .wz files in wine, every single thing seems to work in the game except when I enter a map with monsters, wine crashes and spits this into the console:

Code:
0118:err:ntdll:RtlpWaitForCriticalSection section 00110094 "dlls/ntdll/heap.c: main process heap section" wait timed out in thread 0118, blocked by 0024, retrying (60 sec)

I couldn't find a workable solution through extensive googling.

The entrypoint for the script is here:

I also updated to fix the race condition and update the base java image; my docker build cache contained a very stale java 6 image and when I cleared the cache, using java 6 broke everything. Java 7 is compatible because it still uses the old rhino JS engine.
 
@Hendi48 If you don't mind me pestering you once more, do you mind checking this out?



It's a process to convert v62 .wz files (except List.wz) into XML dumps, then convert those XML dumps back into encrypted .wz files. The use case for this is to be able to "edit" .wz files (by just changing plain old XML files) without having to use the harepacker GUI. When I use those re-encoded .wz files in wine, every single thing seems to work in the game except when I enter a map with monsters, wine crashes and spits this into the console:

Code:
0118:err:ntdll:RtlpWaitForCriticalSection section 00110094 "dlls/ntdll/heap.c: main process heap section" wait timed out in thread 0118, blocked by 0024, retrying (60 sec)

I couldn't find a workable solution through extensive googling.

The entrypoint for the script is here:
Hm, that should also be happening on Windows, then. Anyway, you already mentioned List.wz: This basically contains a list of Mob imgs that have additional encryption applied to their canvases. Since you said mobs specifically crash, I assume the repacker doesn't apply this encryption and the client then faults after having "decrypted" garbage. As a quick fix, you could try deleting List.wz or setting it to an empty file.

I also updated to fix the race condition and update the base java image; my docker build cache contained a very stale java 6 image and when I cleared the cache, using java 6 broke everything. Java 7 is compatible because it still uses the old rhino JS engine.
Yeah, the java 6 image was also segfaulting for me and I had to use 7.
 
For those wondering, here's how to edit the client to start in windowed mode in v83:
Code:
FIND:      A1 C8 1A BF 
CHANGE TO: B8 00 00 00
For those on a GNU system (not sure if other sed's support \x):
sed "s/\xA1\xC8\x1A\xBF/\xB8\x00\x00\x00/g" GMSv83.exe > GMSv83-w.exe

Thanks to Eric's post here:
https://forum.ragezone.com/f921/windows-8-10-client-support-1126357-post8758145/#post8758145

For wine users, any issues with focus and keyboard try this:
 
Last edited:
Hm, that should also be happening on Windows, then. Anyway, you already mentioned List.wz: This basically contains a list of Mob imgs that have additional encryption applied to their canvases. Since you said mobs specifically crash, I assume the repacker doesn't apply this encryption and the client then faults after having "decrypted" garbage. As a quick fix, you could try deleting List.wz or setting it to an empty file.


Yeah, the java 6 image was also segfaulting for me and I had to use 7.


Deleting List.wz or creating a zero-byte file called List.wz makes the game unable to start.

Code:
error code: -2147287038 (Unknown error 0x80030002)

It's beyond me what causes mobs to fail. Strangely enough, I'm able to spawn Zakum/Horntail on the admin account by typing !zakum or !horntail into the chat and there's no crashing, but as soon as I step into a map with snails I crash.
 
Deleting List.wz or creating a zero-byte file called List.wz makes the game unable to start.

Code:
error code: -2147287038 (Unknown error 0x80030002)

It's beyond me what causes mobs to fail. Strangely enough, I'm able to spawn Zakum/Horntail on the admin account by typing !zakum or !horntail into the chat and there's no crashing, but as soon as I step into a map with snails I crash.

Edit list.wz and remove all entries except 1 line named "Dummy" which should do the job. Anyway, it's exactly what is already mentioned a few posts before this one why that happens, and that's because of the mobs listed in list.wz using encrypted canvases that repacker does not support at all. Edit anything with that mob in repacker and it'll completely break
 
@Kimberly I tried to edit that List.wz file with the harepacker GUI using wine but it always crashes whenever I try to save the file.

I got annoyed with the GUI and decided to dig into the code myself. It turned out that there's a ListWzUsed on WzPngProperty that deals with the compression, so basically what I did was do a recursive search of all the png's in the original .wz files that had ListWzUsed=true, then parse the XMLs, and then set ListWzUsed=true on png's that were detected in the original .wz files. is updated and the commit for this change is


One thing to note is that there's one img where the compressed size (I think it was like 180000 bytes) is longer than the WzKey (65535 bytes). The img in question is Mob.wz/9300180 so I came up with which is an attempt to "invert" the decompression logic here


And it all seems to work. I took the compiled .wz files and played the game as normal, no issues. Thank you all for pushing me in the right direction!
 
Wow what an awesome thread in a very long time, good job Hendi - nice seeing you again!

P.s. hope those rumors about you working with snooPBoy on that MapleGlobal bs are fake news!!!
 
Back