Maplestory Myths - know any?

Do you really think I should add this in? It's really just ragers spreading this around.

Thanks to everyone for your contributions!

There was actually a rumor for a while that I heard that said that 90% Potential scrolls were bugged, and worked less often then 70%s.

I have no knowledge about how true that really is, but I've never once failed a 90%, so I want to say it's false. Even if it was a bug at some point, it's most likely been fixed by now, so anyone who says it is almost definitely wrong.

Also: About the randomness of things, and multiple of the same thing occurring simultaneously (Like getting the same item from Gacha twice): Aren't random values derived from the time-stamp on the computer/server at the time the random value is created? If this is true in Nexon's code, that would give a perfectly valid reason for the strange occurrences where the same thing happens multiple times, because it's running off the same time-stamp. It's not that you screwed up enough scrolls that it now decides to be nice to you, but you just got lucky.

Why people so gambler's fallacy?

Good lord it's like painful to watch any baseball broadcast.

I always thought certain drops would drop more often in a certain spot.
Like maybe Ilbi's had a higher chance of dropping by a ladder more so than anywhere else on the map.

A true RNG only exists conceptually. A computer uses no such thing.

Would this be considered a true RNG? Just wondering.

About the randomness of things, and multiple of the same thing occurring simultaneously (Like getting the same item from Gacha twice): Aren't random values derived from the time-stamp on the computer/server at the time the random value is created? If this is true in Nexon's code, that would give a perfectly valid reason for the strange occurrences where the same thing happens multiple times, because it's running off the same time-stamp. It's not that you screwed up enough scrolls that it now decides to be nice to you, but you just got lucky.

I think that if you reproduce a specific time, the RNG will spit out the same number and therefore you would get the same result. However, I highly doubt that close times will result in the same/similar numbers.

A true RNG only exists conceptually. A computer uses no such thing.

Would this be considered a true RNG? Just wondering.

About the randomness of things, and multiple of the same thing occurring simultaneously (Like getting the same item from Gacha twice): Aren't random values derived from the time-stamp on the computer/server at the time the random value is created? If this is true in Nexon's code, that would give a perfectly valid reason for the strange occurrences where the same thing happens multiple times, because it's running off the same time-stamp. It's not that you screwed up enough scrolls that it now decides to be nice to you, but you just got lucky.

I think that if you reproduce a specific time, the RNG will spit out the same number and therefore you would get the same result. However, I highly doubt that close times will result in the same/similar numbers.

Polantaris speaks the truth. It's a common problem with Linux PRNGs if you seed with time(). However, most other PRNGs (Mersenne Twister being the most popular) utilize a stream state. Also, it's very unlikely that Nexon would run their server application twice in the same second to cause a restart or any sort of predictability that would affect the average mapler.

I have no idea how possible the following is, just a theory but:
Is it possible that the random number generation is based on a seed updated by the game itself? If it's not updated frequently enough, it would create these anomalies. You have the source code though, Fiel, so you would be able to tell for sure.

I feel like there should be some way to explain that type of anomaly, because I've noticed it too. Obviously "junk scrolling" doesn't work, but there's got to be something to explain why there's random instances where you see several of the same item all at once, or that low rate scrolling can succeed a whole lot in one go. I often see Gachapon messages of the same person getting the same item 2, and sometimes even 3 times in a row. In the case of equipment, it shares the same stats and everything. Seems like the random seed gets frozen or something, so it dishes out the same numbers.

I have no idea how possible the following is, just a theory but:
Is it possible that the random number generation is based on a seed updated by the game itself? If it's not updated frequently enough, it would create these anomalies. You have the source code though, Fiel, so you would be able to tell for sure.

I feel like there should be some way to explain that type of anomaly, because I've noticed it too. Obviously "junk scrolling" doesn't work, but there's got to be something to explain why there's random instances where you see several of the same item all at once, or that low rate scrolling can succeed a whole lot in one go. I often see Gachapon messages of the same person getting the same item 2, and sometimes even 3 times in a row. In the case of equipment, it shares the same stats and everything. Seems like the random seed gets frozen or something, so it dishes out the same numbers.

Come to think of it, I have gotten 2 Lunar Dews within 15 seconds of each other, and Peridot hunters often claim the same, except with Peridots in lieu of dews.

Come to think of it, I have gotten 2 Lunar Dews within 15 seconds of each other, and Peridot hunters often claim the same, except with Peridots in lieu of dews.

That could easily be due to system clock resynching and feeding the same microsecond back as the seed twice in the same second.

That could easily be due to system clock resynching and feeding the same microsecond back as the seed twice in the same second.

Ah, OK.

Also [MENTION=1]Fiel[/MENTION], it just occurred to me that the code you posted disproving the 100% thing was probably for normal blue/GM scrolls.

Just wondering if AEEs were implemented in BrazilMS, and if so, did they have similar code that would prevent 100%s from failing?

Ah, OK.

Also [MENTION=1]Fiel[/MENTION], it just occurred to me that the code you posted disproving the 100% thing was probably for normal blue/GM scrolls.

Just wondering if AEEs were implemented in BrazilMS, and if so, did they have similar code that would prevent 100%s from failing?

No no, wait. Before I go on a wild goose chase, you need to prove that this is for blue/GM scrolls only. I don't think you have a good concept of what a blue/GM scroll is. In the data there is no conceptual or contextual difference between a blue scroll, GM scroll, 10%, 30%, or whathaveyou. They're all in the same file. And if it's for a blue/GM scroll, then why the hell would it check for any success rate at all, let alone the cursed rate?

Your argument is dumb. You either need more education or need to stop being so gullible. >_>

No no, wait. Before I go on a wild goose chase, you need to prove that this is for blue/GM scrolls only. I don't think you have a good concept of what a blue/GM scroll is. In the data there is no conceptual or contextual difference between a blue scroll, GM scroll, 10%, 30%, or whathaveyou. They're all in the same file. And if it's for a blue/GM scroll, then why the hell would it check for any success rate at all?

Your argument is dumb. You either need more education or need to stop being so gullible. >_>

Welp, sorry. I actually meant "relevant to blue/GM scrolls," since obviously it included dark scrolls. But apparently that's still wrong. I just thought that since AEE's and EE's might have had different coding because they would have to check for the number of stars and the explosion rate was 100%.
I do agree that I need more education - I've never proclaimed to be an expert on any of this, but I think my post was more of a request than an argument. Anywho, thank you for the quick response. =P

I apologize if I seem a bit short. It's just annoying that people are posting to these myths sections with conclusions and no supporting premises. Your post was an example of such.

I doubt BMS had EE/AEE back then. However, the issue only questioned 100% scrolls. The code directly refutes that.

Just realized that no one ever answered this question. Could I get an answer please? Cookie will be provided.

Just realized that no one ever answered this question. Could I get an answer please? Cookie will be provided.

Yes it's possible.

Yes it's possible.

As promised.

Just realized that no one ever answered this question. Could I get an answer please? Cookie will be provided.

It is possible, but the Maroon Mops really do have an average attack of 220. If someone managed to actually come across one, legitimately or otherwise, then .wz editing wouldn't be necessary.

I just did some research on how others had programmed the CRand32__Random() method. It turns out that the random method is a proprietary one, and the seeds in the random method are dependent upon all random events in the game. Every time some CRand32 method is called the seeds are changed. It would be impossible to isolate any given event as being due to a bad PRNG because each random method cannot be tested individually from the perspective of a user on Maplestory Global. You would have to test it on a PServer to know for sure. The Random() method has no known period and no currently discovered biases.

It irks me a bit that their PRNG is a proprietary implementation as that can be subject to programmer error and poor implementations, but there's not much I can do about it.

Here's a few that are either myths or I'm just curious about it (but doesn't really warrant a thread in the Q&A).

Killing a monster while it is being knocked back into the edge of the screen causes it to drop nothing. (prevalent in PQs)

Potential stats are determined as soon as it receives a pot or cubed (ie: the Lens themselves don't determine the stats; using better lens don't give you "better" lines or higher chance of ranking up).

-

I think those are actually true but does anyone have anything to concretely support/disprove it? o-o

Potential stats are determined as soon as it receives a pot or cubed (ie: the Lens themselves don't determine the stats; using better lens don't give you "better" lines or higher chance of ranking up).

Pot stats are determined immediately when a potential scroll or cubed is used (i.e. it's hidden potential)

Confirmation #1: There was a hack that let people see the hidden stats of unrevealed items

Confirmation #2: Revealing an item and having it rollbacked produced the same potential lines post-rollback on multiple occasions that it was statistically significant to say that the stats are locked in when they are in hidden-potential form.