It looks like you're new here. If you want to get involved, click one of these buttons!
My fault, I looked at it incorrectly but it seems to be a signed int32 (therefore it caps at 2^31-1, (24.8 days)) rather than a DWORD (unsigned int32).This is gonna sound unrealistic, but I found a way to reproduce this 100% consistently. I found it through reverse engineering, so I don't think I can share the details here.
To reproduce, have your system run for 2^32 milliseconds (or 49.7 days) with no full shutdowns. That's it lol..
Hint to Nexon's developers: the 'timeGetTime' API on Windows returns a DWORD therefore it caps at 2^32, unfortunately the value this API returns only gets reset when you boot from a full shutdown.
Now, why is this called "Memory/DLL Corruption" if there's nothing "corrupted"...?
It's called "Memory/DLL Corruption" because:
1. The process behaves abnormally. This means that either its data or its code are not as they should be (and normally are). Hence, "corruption".
2. Restarting the process does not restore normalcy. Therefore, the cause of the problem is not within the process' own memory.
3. (Full) Restarting the computer does restore normalcy. Therefore, the cause of the problem is not in persistent memory (HDD).
4. Therefore, the cause of the problem is in volatile memory that does not belong to the process alone. I don't know enough about Windows programming to know what forms of "shared memory" it has, hence the "memory/DLL".
Yours is an interesting theory, but I have two problems with it.
1. I have a Windows 7 laptop (where all shutdowns are "full") and looking at the event log I see it has never been up for 49 days straight. Longest I can see is 27 days. And yet Maple does go into this abnormal state on that computer. Note that I use this computer for mules, and sometimes don't even notice or care that Maple is "corrupted" on it.
Looking at my Windows 10 computer's event log, it looks like the correct number for when Maple "corrupts" is around 25 or possibly even 21 days. But I am not sure as I don't know how to differentiate "full" from "hybrid" shutdowns in that log. It does seem fairly consistent, though, which lends credence to the thought that the cause of the "corruption" is not user behavior but something external.
2. It's true that timeGetTime only returns a DWORD, but if I understand correctly it wraps back to 0 once it reaches MAXINT. While this might cause the Maple client to behave strangely if it happens to be up at the moment of rollover, the strange behavior should not persist after restarting the client. Unless it saves the time "high water mark" into persistent memory (HDD, Registry, etc) for whatever reason - in which case a full shutdown wouldn't help either.
Neospector wrote: »
Neospector wrote: »Client-side skills also run the risk of wz editing. That's why most things in the game are server-sided now.
Neospector wrote: »I'm not saying you can't lowering latency shouldn't be a goal, I'm saying having a high ping or being ping-dependent isn't a bug. Some classes benefit from lower ping, but that's just the way they're designed.
Neospector wrote: »This is not a bug, some classes in many games simply rely on ping and many game communities sort their classes based on being "ping friendly". For example, this Overwatch thread which suggests that one of the best classes to play on high ping is typically Torbjörn.
Ping is a very difficult issue, since it's based on your physical location, the physical location of the server, our (society's) technological level, and even something as silly as the speed of light versus the speed of computers. While certain game updates can improve on latency, ping can only really be solved by being closer to the server or making all classes functionally similar. The former option isn't feasible, and the second option isn't desirable.
If you want to suggest changes to improve latency, you may, but this isn't something that can be "fixed" in the same way Root Abyss boxes DCing players or a missing tooltip on Metro hair can.
