Research shows that the addresses and dimensions graphics.menu.boxes.picker.tilemap _are_ correct. However, HMA is unable to display the tilemap corrrectly, because the tilemap assumes that the tileset in question starts at tile 0x100 instead of tile 0x00. This is similar to how palettes can start at page 3 or 4 instead of having to start at page 0, and should probably be handled in a similar fashion, with the tileset being aware of its own offset.
HMA cannot handle this right now, so the tilemap is commented and untested.
Current test process:
* Run utility
* Increase pokemon by 10.
* Increase pokedex.stats by 10.
* sound.pokemon.cry.growl and sound.pokemon.cry.normal -> expand by 10
* update pokemon name, import a sprite, change catch rate to 255, set a new pokedex description
* reorder pokedex and change wild/87 to see new wild pokemon
* expand one of the habitats (example, data.pokedex.habitat.pages/"Grassland POKéMON"/data/2/pokemon)
-> check data.pokemon.count and data.pokedex.count -> are they updated automatically?
-> test:
-> can catch the pokemon, shows right entry on capture.
-> shows up right in the dex
This still doesn't work right, but this changes all of my current notes into code, as well as adding some more TODOs about things I need to care about.
The behavior of the += version of `add` is undefined if both registers are low registers. In this case, we need to patch the instruction to replace it with the more traditional 3 register version: a = a + b.
base-16 values can be entered by prefixing with 0x or $.
base-16 values will be output by the script parser if the argument is suffixed with |h
All other values will now naturally decompile to base-10.
Notification previously worked when changing via the main view or when changing via an element in the table tool. But notification didn't work right for stream deserialization, since the stream wasn't aware of what was changing.
Now, all write-data-to-model methods return a flag expressing whether or not they actually wrote any data. This makes it possible for streams to know which elements of the stream were changed, which means notification now works correctly.
Note that we are not notifying for compressed data changes or whenever a new stream is created from scratch.
* When given 4 instructions, that's enough space to replace it with a load, a branch, and an address.
* If the 4 instructions are such that they don't have any external dependencies (they don't contain a branch or a load), they can be safely moved to a new address.
These two points together mean that we can arbitrarily (and safely) expand almost any function. This should be very useful for both users and prototyping.
In FR/LG, TMs get two images: one for shops and the PC etc, and one for the TM case. The TM case uses one sprite for all the TMs, but then uses a palette that's set based on the TMs type. These palettes need to be expanded to allow for a new Fairy-Type palette.
fixed a bug in R/S v1: when adding a constant, clear the existing format before adding it. This matters in case the constant was found in a location that contained auto-discovered text or sprite data that is in error.
Using ClearFormat can change the count of runs in an unexpected way, which makes the index we found unusable. So we need to use ObserveRunWritten like the other sections of this method do... which means we need to add a special "am I allowed to make changes" check into the ModelDelta code that handles tracking MatchedWord changes.
* Add draft of nature-count constant and expansion automation script. It's incomplete: more research has to be done into pokeblocks and emerald.
* Fix item effects table length
* Tilemaps specify which palette pages they use. Palettes specify which palette pages they provide. These should match in the default anchors. Add a test that verifies that they do match.
graphics.bag.inside2.palette and graphics.gamecorner.game.palette were totally using the wrong palette!
Not only do we need to clear any excess after the new run is inserted (if the old run was longer), we also need to clear any conflict before the new run is inserted (if the new run is longer). This prevents format conflicts.
* script repointing should during ?????? pointer resolution: make sure that the pointer resolves to a different address than the script repoints to. This happened because we were looking for freespace for the new pointer and the moved script at the same time.
* when auto-repointing a script, clear the old pointer format and update their anchors with the new destination. This is not happening automatically because scripts don't hold all their length like other runs do, so repointing them left their pointers behind.
