My thoughts on the random movesets...
Posted by: Tweaker
Date: 2006-03-25 00:20:01
Think of it this way: Each Pokemon has its own value which defines a 16-bit pointer from an index somewhere in the ROM. When you come up with a Pokemon such as Missingno., this means what it sounds like – a missing number in this table. Perhaps ones that were planned to be implemented, but never were. What we get would be the leftover/incomplete stats from these scrapped Pokemon, right?
But then we move on to odder values, such as 4_4 and the like. These make less and less sense as you up the current Pokemon ID values, and some even crash! This is makes me think that this value is reading beyond the actual sprite index for the Pokemon stat definitions, and is reading random data in place of actual pointers. Because of this, and how some produce odd results, it makes me think there's a predetermined layout of values to define stats for Pokemon in the game, and bad pointers lead to random values (which would explain learning moves after level 100). So the way I see it, this layout of values defines these main things:
-ID for mappings frame to use for names. Note how some are completely random, and some are Missingno. – I bet you the Missingno. ones were supposed to be real Pokemon at one point, and got scrapped during development. So they replaced the stat definitions they had and the mappings definition with the ID for the "Missingno." frame, to define that the value is indeed unused.
-Moves to learn (via an pointer index, defined by ID), and at what level to (hex value). This would make it so once the index has ended and the game is reading random pointers, that this value table could still produce some sort of stats, nonsensical as they are. For example, if a move definition were to be something like "AB FE," that would tell the Pokemon to learn move ID AB (which very well could be something like "HM05" or "COOLTRAINER," depending on the text entry on the index) at level 254 (FE in hex = 254 in decimal). Note that I'm pretty sure this isn't how the game does things, but it seems like a plausible method based on the fact that these nonsense Pokemon ID values can be accessed with partially working Pokemon.
-Pointer to mappings for Pokemon art. Now THIS is the interesting part – The whole glitched names/graphics for invalid Pokemon are undoubtedly due to incorrect mappings, reading from a redundant section in VRAM. The second part of this would be the art to uncompress when a Pokemon appears – if this is defined somehow along with which mappings to use, then the fact that the graphics are total garbage could also be due to the fact that the data being decompressed is NOT art, but random data instead. From my experience in reading generic data as art data, it appears almost exactly like the art for 'M' et all. By actually finding these definitions, we can probably fix these glitches to load entirely new Pokemon of our own creation. Taking a look at some Pokemon hacks around, doing this actually won't be much of a problem. This stat table would be the only thing in the way.
To get to the main point regarding random moves (and I may have actually stated it already) - Moves, and the mappings ID for them are stored in a close, but seperate area. Both these tables co-interact with each other – they define the move programming and mappings to use for them. These "glitch moves" most likely point to now-non-existant programming, which define a mappings ID for a text entry that DOES exist (hence cooltrainer, or etc).
…god, did I really type that much? Anyway, if anyone here knows how the game engine works and would like to enlighten/correct me, I'd greatly appreciate it. This is what I've come up with among many observations, and I most likely could be wrong, but this is the conclusion I've come to.