Which part?
If they've changed anything since the clients I've looked at, it's how they determine the seeds, when they seed, and/or how the rand stream works. This is entirely possible, however, they would not have changed it so much that the basic theory doesn't apply.
Furthermore, you can see evidence of this in critical hits and damage. In some other thread, Fiel has mentioned that even though the client has displayed a bunch of damage, he did very little actual damage. The only way that would be possible is if the calculations are mirrored on the server side and the client is of little consequence. I assure you 100% that critical hit information is not stored in the packets, either, so those must be produced on the server side. If you did the calculations for that solely by damage, you would have inaccuracies, of which global has none.
Also, due to the way the C standard library rand works (it's not a good random function, I'm sure Google can show you precisely why), you experience higher frequencies in a given bit location, which means that success will be more slanted to the side that isn't checked against. For example, if you do randinteger < success, having a higher frequency of higher bits will result in lower success. Inversely, having a lower frequency of higher bits will result in higher success.
I might have screwed up, I forget which bits it is that rand is skewed toward, but I know it's generally skewed toward one end of the bytes.
EDIT: It seems that damage and crits use either a Tausworthe or a slightly modified Tausworthe generator. Not sure if this applies to scrolling or what, but if it does, that would be a bit better than I initially suspected. If they did switch to this generator, they switched since .56 and it's fairly recent in "Nexon years."
LazyBui Wrote:MapleStory uses the VC++ implementation of C standard library rand. It initially seeds the generator with the tick count of your machine when you launch the client. The number of calls to rand() in the client greatly exceeds 1000. The call graph for rand() is extremely complicated. The client calls rand() constantly even when the client is doing nothing at all. They never call srand() again after that initial seeding.Numerous things support this data. When I looked at older clients, this is how they worked. It's very easy to determine that they use Visual C++ on their clients. Once a system this powerful in terms of catching cheating is in place, it seems like folly to get rid of it.
Predicting it on the client side would literally be impossible for a human and it would take a very smart program or client modifications for an application. Predicting it on the server side isn't possible at all. The server mirrors the rand() stream of every single client somehow. I'm not quite sure how they do it, but I'm positive that they do.
If they've changed anything since the clients I've looked at, it's how they determine the seeds, when they seed, and/or how the rand stream works. This is entirely possible, however, they would not have changed it so much that the basic theory doesn't apply.
Furthermore, you can see evidence of this in critical hits and damage. In some other thread, Fiel has mentioned that even though the client has displayed a bunch of damage, he did very little actual damage. The only way that would be possible is if the calculations are mirrored on the server side and the client is of little consequence. I assure you 100% that critical hit information is not stored in the packets, either, so those must be produced on the server side. If you did the calculations for that solely by damage, you would have inaccuracies, of which global has none.
LazyBui Wrote:At this point, I'm going to turn to pure speculation. The low order bit periods occur less frequently in the C standard library rand(), which is why success seems so rare sometimes. I have a reason to believe that server rand() is separated from client rand(), and I believe that server-sided calculations are seeded by player ID and that's why some players seem to have extraordinary "luck" while others have extraordinary levels of the opposite.No actual data fits this hypothesis, it's simply a conjecture based on my experience that certain players have a somewhat consistent stream of success or failure. If this was the case, it would explain "godly scrollers" as a bit more than mere luck. Although you could probably make an argument that they got lucky getting a lucky seed.. or something like that.
Also, due to the way the C standard library rand works (it's not a good random function, I'm sure Google can show you precisely why), you experience higher frequencies in a given bit location, which means that success will be more slanted to the side that isn't checked against. For example, if you do randinteger < success, having a higher frequency of higher bits will result in lower success. Inversely, having a lower frequency of higher bits will result in higher success.
I might have screwed up, I forget which bits it is that rand is skewed toward, but I know it's generally skewed toward one end of the bytes.
EDIT: It seems that damage and crits use either a Tausworthe or a slightly modified Tausworthe generator. Not sure if this applies to scrolling or what, but if it does, that would be a bit better than I initially suspected. If they did switch to this generator, they switched since .56 and it's fairly recent in "Nexon years."