Welcome!

Join our community of MMO enthusiasts and game developers! By registering, you'll gain access to discussions on the latest developments in MMO server files and collaborate with like-minded individuals. Join us today and unlock the potential of MMO server development!

Join Today!

Client unresponsive

lai

Newbie Spellweaver
Joined
Jan 27, 2018
Messages
14
Reaction score
1
So i've been adding and implementing somethings from higher version on to my server. I've started to notice when I spawn a boss or something or enter a map. Things get out of place images and renders start to disappear, entering another map via portal is delayed. Bgm sounds don't change from map to map and then after a bit the client freezes you can still hear the bgm.
Some mobs also are out of place. I'm pretty sure this isn't a memory leak from my source but maybe the client isn't rendering some images properly.

If I close the client and re-open it everything seems fine. This doesn't happen all the time but randomly and only with after interacting with the new stuff I implemented.
@Kimberly @Eric if you could shine some light on this issue, would be appreciative.
When I try to log out, my screen remains black and unresponsive.

I'm almost certain this happens only after killing a boss I added from a different version.

Version i'm using is v0.62
I have Windows 10
with Nvidia GFX 1060

Edit: This is what happens when I try logging out during the render issue (most of the times it is pitch black and I can't do anything just kill the process with taskmgr)


lai - Client unresponsive - RaGEZONE Forums
 
Last edited:
Moderator
Staff member
Moderator
Joined
Jul 30, 2012
Messages
1,102
Reaction score
432
This is the infamous 'GFX' bug that happen for people using NVIDIA. Unfortunately this is a client bug that is not easily fixed.
 
Upvote 0

lai

Newbie Spellweaver
Joined
Jan 27, 2018
Messages
14
Reaction score
1
This is the infamous 'GFX' bug that happen for people using NVIDIA. Unfortunately this is a client bug that is not easily fixed.

Is there any more information I can find regarding this issue? I've only seen/read this post:


but my client never reaches 1 GB mem and I don't use windows XP.
 
Upvote 0
Moderator
Staff member
Moderator
Joined
Jul 30, 2012
Messages
1,102
Reaction score
432
There's not much info but Private Servers usually suggest you to change your GFX setting a lot during bossing (which refreshes it) or getting an XP VMware, or just turning off NVIDIA altogether.
 
Upvote 0

lai

Newbie Spellweaver
Joined
Jan 27, 2018
Messages
14
Reaction score
1
There's not much info but Private Servers usually suggest you to change your GFX setting a lot during bossing (which refreshes it) or getting an XP VMware, or just turning off NVIDIA altogether.
So i'm assuming no pre-bb server has actually fixed this issue? Just worked around it?
 
Upvote 0
Moderator
Staff member
Moderator
Joined
Jul 30, 2012
Messages
1,102
Reaction score
432
There's currently no known fix for Windows 10 + NVIDIA (client memory leaks). We have fixed it for OS's prior, but the method is not currently public, since it wasn't completely done by us.
 
Upvote 0
Junior Spellweaver
Joined
Jun 3, 2010
Messages
164
Reaction score
41
There's currently no known fix for Windows 10 + NVIDIA (client memory leaks). We have fixed it for OS's prior, but the method is not currently public, since it wasn't completely done by us.

Have you ever tried using a hack to disable background, foreground. tile, ... while bossing?
 
Upvote 0
Custom Title Activated
Loyal Member
Joined
Jan 18, 2010
Messages
3,109
Reaction score
1,139
So i'm assuming no pre-bb server has actually fixed this issue? Just worked around it?

I've fixed both of the issues in my client(s), so it can be done if you know what's involved and what you're doing. For now, however, I plan to keep all of my implementations regarding these issues private.

Oh, and do you by any chance use a lot of WZ Edits, or any at all? This can also be caused because of the MapleLib/WzLib library and how it repacks WZ files. If not, then this is just the same issue that would occur in GMS. It is indeed a client memory leak though, and it is fixed in all post-bb clients.
 
Upvote 0
Moderator
Staff member
Moderator
Joined
Jul 30, 2012
Messages
1,102
Reaction score
432
I've fixed both of the issues in my client(s), so it can be done if you know what's involved and what you're doing. For now, however, I plan to keep all of my implementations regarding these issues private.

Oh, and do you by any chance use a lot of WZ Edits, or any at all? This can also be caused because of the MapleLib/WzLib library and how it repacks WZ files. If not, then this is just the same issue that would occur in GMS. It is indeed a client memory leak though, and it is fixed in all post-bb clients.

From what I understood its a memory leak exclusive to Windows 10, because after we've applied different ways to load .wz files the GFX issue was resolved for everyone, including NVIDIA users, except those using NVIDIA AND Windows 10.

But yeah we didn't found the solution for the W10 issue yet, sadly.

Very fantastic news to hear it <exist> though. Private or not, I don't really care. It means that someday this whole stupid GFX issues can be resolved.
 
Upvote 0
Custom Title Activated
Loyal Member
Joined
Jan 18, 2010
Messages
3,109
Reaction score
1,139
From what I understood its a memory leak exclusive to Windows 10, because after we've applied different ways to load .wz files the GFX issue was resolved for everyone, including NVIDIA users, except those using NVIDIA AND Windows 10.

But yeah we didn't found the solution for the W10 issue yet, sadly.

Very fantastic news to hear it <exist> though. Private or not, I don't really care. It means that someday this whole stupid GFX issues can be resolved.

Not exactly, but maybe your other fixes helped work around it. The issue is actually caused on all versions of Windows after XP (starting from Vista, with a change in the OS itself I believe). The reason why you were able to fix it by applying a different way to load your .wz files is because the memory leak has something to do directly with WZ files and their libraries used.

As for windows 10 compatibility on all versions/clients, the issue is indeed what I had documented and pinpointed in my thread here on RZ. If you can fix/patch the location that I mentioned had caused the parameter error, then you've got windows 10 completely compatible with any version, no more parameter error ever again. I've tested it on v83, v90, and v117 to confirm it.
 
Upvote 0
Junior Spellweaver
Joined
Sep 16, 2017
Messages
156
Reaction score
36
Oh, and do you by any chance use a lot of WZ Edits, or any at all? This can also be caused because of the MapleLib/WzLib library and how it repacks WZ files.

I'll take this chance to ask a question that's been bugging me for a little while, if this isn't going too off-topic.

A few months ago I used HaRepacker to remove certain weapon type nodes that are unused in v83, from some Cash weapon covers.
However, that edit would cause people to face this issue at seemingly random times; they'd disconnect, crash, get glitched menus and graphics, even after having just been sitting idle in Henesys.

From what you said, I'd assume that the edit itself is the culprit. So, is there any other way to implement that change, in a way that wouldn't be prone to crash?
 
Upvote 0
Custom Title Activated
Loyal Member
Joined
Jan 18, 2010
Messages
3,109
Reaction score
1,139
I'll take this chance to ask a question that's been bugging me for a little while, if this isn't going too off-topic.

A few months ago I used HaRepacker to remove certain weapon type nodes that are unused in v83, from some Cash weapon covers.
However, that edit would cause people to face this issue at seemingly random times; they'd disconnect, crash, get glitched menus and graphics, even after having just been sitting idle in Henesys.

From what you said, I'd assume that the edit itself is the culprit. So, is there any other way to implement that change, in a way that wouldn't be prone to crash?

The issue entirely is how MapleLib repacks your WZ files after saving them. It isn't because you removed nodes (it's fairly close to how Nexon does it, but it writes it all to file in proper order), it's because you've edited XX amount of item(s). For each item that you've changed, you'd have to of loaded the property, and that means it has to repack the images of said item upon save. That's where the issue lies; let's just say Nexon uses various pixel formats for a reason and encrypts them back with zlib. Every time you save an image, no matter how big or small or the color bitmap involved, it always uses the A8R8G8B8 pixel format. For example, if you ever tried to modify the Nexon/Wizet intros to completely custom 60fps effects and it lags your client to death or even crashes/glitches the login, this is why. Those should be the R5G6B5 pixel format, and if they are saved and encoded that way, the changes make no drastic effect on the client. There's other issues around HaRepacker as well, but the one regarding the image glitching/client lag is because of that. The library over the years has added the ways to be able to decrypt all of the different kinds of newer pixel formats (DXT3/DXT5/etc), but it's only ever re-encrypted them all into one single format.
 
Upvote 0
Moderator
Staff member
Moderator
Joined
Jul 30, 2012
Messages
1,102
Reaction score
432
As for windows 10 compatibility on all versions/clients, the issue is indeed what I had documented and pinpointed in my thread here on RZ. If you can fix/patch the location that I mentioned had caused the parameter error, then you've got windows 10 completely compatible with any version, no more parameter error ever again. I've tested it on v83, v90, and v117 to confirm it.

I have no bootup errors on my server (Paremeter is incorrect is fixed). Basically, Only Windows 10 users are still experiencing the graphics issue this topic is about, while I did resolve it for all the other OS's by changing the .wz format

Here's a video of it in action:


Timeline of the video
@0:15 - The first encounter of client glitch in which the attacking animation of Targa is facing the opposite direction of attackers and dissappears
@1:01 - Key config GUI gets broken
@1:02 towards the end - Gradual increase in fps stutter. You should be able to notice it well since the clip has been recorded in 60 fps. Also the face animation starts desyncing.
@1:19 - chat box GUI gets broken
@1:23 - menu GUI gets broken
@2:39 - unusually fast walkspeed?

Basically the game tears up apart more and more, start to lag spike more and more, and eventually crashes. I am aware this is exactly what GFX/the memory leaks are, but the interesting part is that its only happening to Windows 10 now after our fixes, so there must be something else left that is tearing Windows 10 apart regarding compatibility/memory leaks.
 
Upvote 0

lai

Newbie Spellweaver
Joined
Jan 27, 2018
Messages
14
Reaction score
1
I've fixed both of the issues in my client(s), so it can be done if you know what's involved and what you're doing. For now, however, I plan to keep all of my implementations regarding these issues private.

Oh, and do you by any chance use a lot of WZ Edits, or any at all? This can also be caused because of the MapleLib/WzLib library and how it repacks WZ files. If not, then this is just the same issue that would occur in GMS. It is indeed a client memory leak though, and it is fixed in all post-bb clients.

The ladder, I do have quite a bit of wz edits for the pre-bb version I use, the only thing keeping me from adding more content is this. I've also used harepacker for the wz editing. Would this mean my newly added wz edits would be meaningless even if I were to somehow fix the memory leak? I really don't want to have to remove all that time and effort I spent on it.

Is there a way to pack the wz files I add correctly? Or would I have to re-do them?

Also strangely enough, trying horntail on a clean v62 also causes me to have said issue's I described in the OP.
 
Upvote 0
Skilled Illusionist
Joined
May 28, 2011
Messages
380
Reaction score
38
I've fixed both of the issues in my client(s), so it can be done if you know what's involved and what you're doing. For now, however, I plan to keep all of my implementations regarding these issues private.

Oh, and do you by any chance use a lot of WZ Edits, or any at all? This can also be caused because of the MapleLib/WzLib library and how it repacks WZ files. If not, then this is just the same issue that would occur in GMS. It is indeed a client memory leak though, and it is fixed in all post-bb clients.
So, it's okay to save as A8R8G8B8 when using post-big bang clients? Did they just add A8R8G8B8 support to the newer clients or what? Just curious why you mentioned that the MapleLib/WzLib issue doesn't happen on post-big bang clients.
 
Upvote 0
Custom Title Activated
Loyal Member
Joined
Jan 18, 2010
Messages
3,109
Reaction score
1,139
So, it's okay to save as A8R8G8B8 when using post-big bang clients? Did they just add A8R8G8B8 support to the newer clients or what? Just curious why you mentioned that the MapleLib/WzLib issue doesn't happen on post-big bang clients.

If you apply the same amount of wz edits you would in a pre-bb client, it would still apply to post-bb. Don't forget, GMS has still had this image glitching bug even in recent versions because the client begins to eat up so much memory. Also, another thing to point out is that by saving all images as that format is what is making your files so much bigger than they were before. If you were to save your file but with every node saved and nothing changed (so it's clean, but a re-save under MapleLib), your file will be significantly bigger than before even knowing it's completely identical.

EDIT: Since someone had asked me how to determine what the pixel format is of each property read from the wz's, here is nexon's raw serialization parsing for WzCanvas that determines what each byte is.

PHP:
public override WzConstants.COMError raw_Serialize(WzArchive pArchive)
{
    if (pArchive != null)
    {
        WzStream ws = new WzStream(pArchive, null);
    
        ws.ReadByte();//pData
        if (ws.ReadByte() != 0) {
            WzSerialize ppProperty = null;

            WzPCOM.PcCreateObject("Property", out ppProperty);
        
            this.pProperty = (WzProperty) ppProperty;
            this.pProperty.raw_Serialize(pArchive);
        } else {
            this.pProperty = null;
        }
    
        this.uWidth = ws.Read();
        this.uHeight = ws.Read();
    
        if (this.uWidth >= 0x10000 || this.uHeight >= 0x10000) {
            return WzConstants.COMError.INVALID_CANVAS;
        }
    
        this.nPixFormat = ws.Read();
        if (this.nPixFormat != (int) PixFormat.A4R4G4B4 && this.nPixFormat != (int) PixFormat.A8R8G8B8 && this.nPixFormat != (int) PixFormat.R5G6B5
            && this.nPixFormat != (int) PixFormat.DXT3 && this.nPixFormat != (int) PixFormat.DXT5)
        {
            return WzConstants.COMError.INVALID_TYPE;
        }
        this.nMagLevel = ws.Read();
        if (this.nMagLevel < 0) {
            return WzConstants.COMError.INVALID_CANVAS;
        }
    
        for (int i = 0; i < 4; i++) {
            ws.Read();
        }
    
        int uSize = ws.ReadInt();
        if (uSize != 0)
        {
            bool bEncrypted = ws.pArchive.Encrypted();

            SerializeData(ws, uSize, bEncrypted);
        }

        return WzConstants.COMError.SUCCESS;
    }
    return WzConstants.COMError.INVALID_ARCHIVE;
}

and this is MapleLib:
PHP:
internal WzPngProperty(WzBinaryReader reader, bool parseNow)
{
    // Read compressed bytes
    width = reader.ReadCompressedInt();
    height = reader.ReadCompressedInt();
    format = reader.ReadCompressedInt();
    format2 = reader.ReadByte();
    reader.BaseStream.Position += 4;
    offs = reader.BaseStream.Position;
    int len = reader.ReadInt32() - 1;
    reader.BaseStream.Position += 1;

    if (len > 0)
    {
        if (parseNow)
        {
            compressedBytes = wzReader.ReadBytes(len);
            ParsePng();
        }
        else 
            reader.BaseStream.Position += len;
    }
    wzReader = reader;
}
 
Last edited:
Upvote 0

lai

Newbie Spellweaver
Joined
Jan 27, 2018
Messages
14
Reaction score
1
so basically, a pre-bb client can't support adding lot's of Wz edits unless those wz img's are in the correct format? That's what i'm understanding from this anyway.
 
Upvote 0
Skilled Illusionist
Joined
May 28, 2011
Messages
380
Reaction score
38
If you apply the same amount of wz edits you would in a pre-bb client, it would still apply to post-bb. Don't forget, GMS has still had this image glitching bug even in recent versions because the client begins to eat up so much memory. Also, another thing to point out is that by saving all images as that format is what is making your files so much bigger than they were before. If you were to save your file but with every node saved and nothing changed (so it's clean, but a re-save under MapleLib), your file will be significantly bigger than before even knowing it's completely identical.

EDIT: Since someone had asked me how to determine what the pixel format is of each property read from the wz's, here is nexon's raw serialization parsing for WzCanvas that determines what each byte is.

PHP:
public override WzConstants.COMError raw_Serialize(WzArchive pArchive)
{
    if (pArchive != null)
    {
        WzStream ws = new WzStream(pArchive, null);
    
        ws.ReadByte();//pData
        if (ws.ReadByte() != 0) {
            WzSerialize ppProperty = null;

            WzPCOM.PcCreateObject("Property", out ppProperty);
        
            this.pProperty = (WzProperty) ppProperty;
            this.pProperty.raw_Serialize(pArchive);
        } else {
            this.pProperty = null;
        }
    
        this.uWidth = ws.Read();
        this.uHeight = ws.Read();
    
        if (this.uWidth >= 0x10000 || this.uHeight >= 0x10000) {
            return WzConstants.COMError.INVALID_CANVAS;
        }
    
        this.nPixFormat = ws.Read();
        if (this.nPixFormat != (int) PixFormat.A4R4G4B4 && this.nPixFormat != (int) PixFormat.A8R8G8B8 && this.nPixFormat != (int) PixFormat.R5G6B5
            && this.nPixFormat != (int) PixFormat.DXT3 && this.nPixFormat != (int) PixFormat.DXT5)
        {
            return WzConstants.COMError.INVALID_TYPE;
        }
        this.nMagLevel = ws.Read();
        if (this.nMagLevel < 0) {
            return WzConstants.COMError.INVALID_CANVAS;
        }
    
        for (int i = 0; i < 4; i++) {
            ws.Read();
        }
    
        int uSize = ws.ReadInt();
        if (uSize != 0)
        {
            bool bEncrypted = ws.pArchive.Encrypted();

            SerializeData(ws, uSize, bEncrypted);
        }

        return WzConstants.COMError.SUCCESS;
    }
    return WzConstants.COMError.INVALID_ARCHIVE;
}

and this is MapleLib:
PHP:
internal WzPngProperty(WzBinaryReader reader, bool parseNow)
{
    // Read compressed bytes
    width = reader.ReadCompressedInt();
    height = reader.ReadCompressedInt();
    format = reader.ReadCompressedInt();
    format2 = reader.ReadByte();
    reader.BaseStream.Position += 4;
    offs = reader.BaseStream.Position;
    int len = reader.ReadInt32() - 1;
    reader.BaseStream.Position += 1;

    if (len > 0)
    {
        if (parseNow)
        {
            compressedBytes = wzReader.ReadBytes(len);
            ParsePng();
        }
        else 
            reader.BaseStream.Position += len;
    }
    wzReader = reader;
}
Thanks for this.

However, still, what did you mean when you said post big bang clients don't have an issue. Was that a memory leak separate from the pixel format saving? Just wanted clarification on what you said earlier.
 
Upvote 0
Custom Title Activated
Loyal Member
Joined
Jan 18, 2010
Messages
3,109
Reaction score
1,139
Thanks for this.

However, still, what did you mean when you said post big bang clients don't have an issue. Was that a memory leak separate from the pixel format saving? Just wanted clarification on what you said earlier.

Yes, they're two different issues that go hand in hand with each other. While post-bb clients may have the memory leak fixed regarding the wz libraries and loading/disposing/etc, that just means that if you were on clean GMS files then you wouldn't be crashing while trying to fight Zakum/Horntail. However, if you apply crazy amount of wz edits in a high version just like you would in a low version (which is rare because people copy hundreds of thousands of high-version content into low versions, not the other way around), then you would end up with graphical bugs in UI windows and eventually crash. By saving them in the default format that HaRepacker always uses, it uses a lot of memory - hence why the files are bigger. At the same time, this means the client will utilize more memory for every image it has to load on the items (which is a lot). This is what will cause even post-bb clients to hog a ton of memory and eventually crash.
lai not exactly the "correct" format, but their "original" given format. imagine saving every image into the new DXT5 image bitmaps, it'd be even bigger than it already is now. but yes, you basically got the idea - a lot of wz edits can cause graphical issues due to a lot of memory.
 
Upvote 0

lai

Newbie Spellweaver
Joined
Jan 27, 2018
Messages
14
Reaction score
1
Yes, they're two different issues that go hand in hand with each other. While post-bb clients may have the memory leak fixed regarding the wz libraries and loading/disposing/etc, that just means that if you were on clean GMS files then you wouldn't be crashing while trying to fight Zakum/Horntail. However, if you apply crazy amount of wz edits in a high version just like you would in a low version (which is rare because people copy hundreds of thousands of high-version content into low versions, not the other way around), then you would end up with graphical bugs in UI windows and eventually crash. By saving them in the default format that HaRepacker always uses, it uses a lot of memory - hence why the files are bigger. At the same time, this means the client will utilize more memory for every image it has to load on the items (which is a lot). This is what will cause even post-bb clients to hog a ton of memory and eventually crash.
lai not exactly the "correct" format, but their "original" given format. imagine saving every image into the new DXT5 image bitmaps, it'd be even bigger than it already is now. but yes, you basically got the idea - a lot of wz edits can cause graphical issues due to a lot of memory.

Okay so we have 2 issues with pree bb clients, 1 being the memory leak and the 2nd being adding lots of wz edits in a modified format from the original which in return aids to the original memory leak problem.

That being said if I were able to fix this, this would mean having to re-add all the custom wz edits again? In general, is there a limit for the amount of wz edits that can be done even with such a fix?
 
Upvote 0
Back
Top