[v0.62/v0.83/??] Understanding the 'Rush' bug

[Kimberly]

Heya.

There's one client sided bug I am curious about for longest time, which is known in the Private Server scene as the Rush bug.

The rush bug is a bug that seems to be happening to random users who haven't shut down their PC for a very long time, since it seems like it get solved if they either restart their PC or use windows automatic update, and than restart. As of this topic I have the bug at my work PC, who didn't got shut down for very long time (41 days to be exact). Logging out your windows account and relogging doesn't solve it, nor does restarting the maple client. I don't want to restart the PC since i want experiment more with this rather rare bug.

Why is it called the Rush bug? Well, for starters Rush no longer works, at all.

However, there's also other behavior, and its always the same behavior that happens to users, which is known as following so far:

-The monster item drop sound as well as your own item drop sound no longer works/is silent
-Monster HP and name no longer shows, regarding the setting
-Rush as stated earlier no longer works; pressing the hotkey does nothing
-Corkscrew blow no longer works. You can charge it, but releasing it does nothing
-Backspin blow no longer works; pressing the hotkey does nothing

As far as I am aware this happens in every v0.62 server and from

You must be registered to see links

Though I am not sure if in v0.83 it has similar behavior, but from what I see the answer is

You must be registered to see links

.

I am really curious why this could be a thing, and how its related to having the PC long on for long time, as well as it being fixed after a restart (not client restart)... Its always 100% the same issues once it happens, so it must be something.

I have no clue if this is still a thing in v0.90 or higher.

 

[Silver Fang]

Hey Kimberly!

My players started to experience this "Rush" bug also.Server version is v.83 and I was confused why rush didn't work for them randomly.
My personal computer is always on and I have never experience the "rush" bug yet. Would it be due to certain computers? I'll ask my players more details and edit this post later. Would love to have this issue fix or find a better reasoning why it occurs.

 

[Kimberly]

It surely start happen randomly and it always resolve for them on a reboot/Windows Update + reboot. While I say it may be related of not rebooting for long time, there's zero prove they are related

I am still lacking technical info such as following

-The OS: the computer at work is Windows 10, I never asked my users who have/had the issue, will do in future
-When exactly it started happen; unfortunately I do not Maple all day at work, but maybe there's a patern
-I never checked if new characters will get same issue, but most likely they do

I am still very sure this is a client sided issue though.

 

[Yuuroido]

Isn't it 24.9 days?
Since they usually use a signed int for 'tCur', following pattern won't work properly.

//INIT
this->tLastUpdate = 0;

//ACTION ... none or call UPDATE function

//UPDATE
int tCur = get_update_time();//or timeGetTime(); or GetTickCount();? I'm not sure but it gets the elapsed milliseconds since Windows was started.
if (tCur - this->tLastUpdate >= 500) {//won't happen
    this->tLastUpdate = tCur;
}

I heard that mob hp bar/name's issue or some skill problems are still reproducible on the latest version.

You must be registered to see links

 

[Kimberly]

Changing in-game settings, shutting down the MapleStory client, or even re-installing it, does not change anything. The only known cure is a Full Shutdown and restart of the computer, as apparently a Hybrid/Quick Restart preserves whatever it was that got corrupted.

Sounds very much so like the 'rush bug', more so by fact HP/Name also disappears as listed bugs. Very interesting this is even a thing still on latest version.

 

[Eric]

Never actually heard of this bug until now, but very good point Yuuroido However, timeGetTime and GetTickCount functions in C++ are unsigned ints which means it'd be 2^32 milliseconds which would be up to like 50 days total (well, just short of it). I wasn't thinking of the time wrapping!

Assuming Nexon knows that this is the issue, I don't see why this has not yet been fixed.. Other than the game still operating on 32bit architectures so they can't make use of timeGetTime64, I fail to understand why they don't pre-check the OS's current uptime or better manage their durations. Actually, since the time they use is tracked initially when the application runs and not Windows, they could make their own function of timeGetTime().

// upon runtime CWvsApp is what sets up our application through WinMain
// we can safely assign our initial time here
void CWvsApp::CWvsApp(CWvsApp *this, const char *sCmdLine) {
    unsigned int tStart;

    tStart = timeGetTime(); // initial application time
    // Then, we need a 4-byte variable to store this time that we can later access in.
    this->m_tUpdateTime = tStart; // Just an example, this is Nexon's "get_update_time" check that they use.
}

DWORD MS_timeGetTime() { // MapleStory's timeGetTime! ;)
    CWvsApp *pApp;

    pApp = TSingleton<CWvsApp>::GetInstance();
    return timeGetTime() - pApp->m_tUpdateTime; // Return the duration difference and remove wrap-around.
}

Fixing this in v62 probably wouldn't be so bad honestly, I've done way worse before. We'd need a class that we can store our 4-byte variable in from the start that isn't going to be changed. Then, we would replace the CALL addresses in 45 locations from a external timeGetTime call and replace it with an internal MS_timeGetTime() call (our own function) that subtracts the initial time. Then, we'd need to actually make our own function like shown above. We would only need to go to this extent if a user's OS has been running for more than 50 days, otherwise the time returns just fine; to make sure of this, we would validate and compare timeGetTime first in our function. Once our function makes sure that their time is > 50 days, we return timeGetTime() - tStart, otherwise we just return timeGetTime(). I'm sure there's other ways to calculate it as well. Sadly, the higher the version after 62 we go, the more timeGetTime and GetTickCount calls increase: for v83, 124; for v90: 137, etc.

tl;dr this is just an issue because it's using 32bit calls which wrap after 2^32 of milliseconds and Nexon's too lazy to fix it, with time invested in modifying your client and also having some assembly knowledge, you can fix this "rush bug" issue.

 

[ahnlab]

I enjoyed reading your comments, very interesting

Well, I had this bug not a long ago, in GMS v182.2. One of my computers was off for over 60 days, and when I turned it on, update maplestory and then ran it, I encoutered with the issues described above. I couldn't see monsters' hp bar and name, change graphic settings, etc..
In addition to that, maplestory consumed 2 times more ram than the normal (normal was about 850MB and that pc consumed 1680~).
I tried to reboot my pc few times but it didn't work, I also deleted maplestory's registry, but nothing changed.
Then, I read on reddit that users who had this issue, solved it by performing a "full shutdown". I googled it, and after doing a full shutdown, the problem solved !

The OS of this PC is Win10 64bit.
MapleStory was installed on the HDD and not on the SSD.