If the user modified a list or added new elements to it, don't modify the list during version upgrades. If the list has never been modified, go ahead and update the list based on the new default metadata.
This is implementing by storing a 'Default Hash' for lists. The user that modifies the list will leave the default hash alone, and the program can notice the mismatch and avoid updating the modified list.
Tasks already do what I was wanting to do (manage work timing), and do it better with more features, and do it in a way that other developers will more easily understand. Stop being weird, just use a Task.
This allows us to have parameters from toml metadata passed in to the process of how we create formatted runs. In this change, we add the ability for trainer teams to _not_ scale the IV value from a number 0-255 to a number 0-31. This is important since some patches depend on using the entire byte, rather than just the top 5 bits.
Since the model is now in charge of the FormatRunFactory. the model can decide to use different types of factories for different roms. This lets us turn different features on/off between the pokemon games and other games. We may use this capability later.
Unmapped Constants are much like Unmapped Pointers: they're tracked by the Model, the metadata, and undo, but they don't have a spot in the file. This allows us to create constants using the existing syntax `@constant=value` which can then be referenced in thumb code using `.word`s.
* New test to show that we can save unmapped constants from the ViewModel to Metadata
* New test to show that we can load unmapped constants from Metadata to the Model
* New test to show that we can undo the adding of unmapped constants
* New test to show that unmapped constants can be used in thumb words
they were dynamic, but that causes issues when upgrading. Since the tables are back to back, loading the female table with a dynamic length sees all the male names and tries to incorporate them, so the male names get deleted.
Make the resize-clear smarter. When clearing out a format to add other formats at the end, clear the format at the beginning to preserve pointer information.
Also, CFRU defaults to 17 bytes per ability name.
A new set of 6 tests prove that upgrading from old versions to new versions works correctly. It currently tests 0.3, 0.3.5, and 0.4 with FireRed and Emerald.
... and man, it found a ton of issues. I lost track of how many issues it found, but I'm glad I wrote those tests.
* RomName needed to update to data.header.romname
* Several tables didn't load the correct length because they were dependent on things that hadn't been loaded yet.
* One table broke during an update, and no longer loaded correctly in Ruby or Emerald.
* Several tables didn't update their formats correctly during upgrade.
*
Since tables are loaded from metadata before constants, loading metadata made the types load as a single-element table. This is wrong. Make it change the length of the type name table when it later loads the constants.
This should be true in the general case too, not just the startup case. When a new constant is loaded, if a table is known to have that length, update the table accordingly.
Add additional testing to verify that the constant is correct before adding it. This matters for a new TOML being created for an existing rom, where some of the values may've been changed.
Add additional verification that all the constants / table lengths actually match up after loading is complete.
Initialization happens on a background thread. We want to be able to run commands when initialization is complete. The way this was done before wasn't very thread safe. The new version will always run the command.
* If initialization is complete, it runs the command right away.
* If initialization is not complete, it defers execution until initialization is done.
* Initialization is measured in scopes. An inner scope will not run initialization work when it's done, since there's still more initialization work that needs to be completed.
* Things like "goto" will now defer execution until initialization is complete. For most users, this won't matter. For speed users, it means that goto will now work the way they expect.
Streams now have the ability to express a "visualization" of the stream, which is a list of PixelViewModels. The table tool will display those in the background of the textbox, over to the right.
Users have requested the ability to control how much space is skipped between runs. Right now, the default in 0x100 bytes. But this means that data ends up getting rather spaced out, in a way that may be undesirable.
Users can now adjust the spacing used when data auto-moves.
As I add more constants, it becomes apparent that I need a more condensed format for adding these. This won't make it much easier to add, but it will make it easier to see.
HardCodeTablesModel can make a table too long, and then fix it later by making it shorter. If this happens, any 'inner pointers' need to be converted to individual runs.
* Clear the format before adding the new NoInfoRun, because otherwise we have a temporary run conflict.
* Grab the array name before doing the negative append, since the array name might be cleared during that step.
* Improve Debug Asserts to give better messages.
Lots of people use CFRU. I don't really want to support it, but it's going to be a while before I have anything even slightly capable of replacing it. I should do some basic checks to detect it and include some code to handle certain things it changes.
Change the paradigm: instead of saying "final write + offset = destination", say "destination + offset = final write". This means that you can write things like <data.moves.stats.battle+4>, which will resolve in bytes to the pointer + 4, while resolving as a pointer to the move stats.
* Show "Edit" next to goto, to give people an idea for how to get back.
* Show a commit button
* Animate the blur / background to make it less jarring
* Close button
* Improve visibility of start token buttons
* Default text when empty
* Rename data.trainer.stats to data.trainers.stats for consistency
The list of tables is getting crazy, and I keep adding more.
* Don't show tables in the table list if they're 'matched length' tables. Example, level-up moves. These are already accessible because the table tool uses matched-length tokens to show multiple tables in the tool at once, to make editing data easier.
* Split the tables between two lists: a header (containing up to two tokens) and a body (containing the rest). This should allow for progressive disclosure, to help make the list more manageable.
Does Enumerable.Range(0, n) in a more compact way.
It's a thing that we need to type a lot.
Also add a new test that captures a problem parsing Overworlds in FireRed
Named bytes can provide an easy way to edit code by marking the purpose of specific bytes in the ROM. It can also help keep the values properly in sync.
The only reason we can find these is because we have a pointer to the table. So make sure that these pointers are properly recognized. They used to be, but it broke sometime when working on table expansion.
Related: When relocating a table for expansion, make sure there's enough room for all the extra elements, not just one.
Also, when checking for whether or not we need to seek for pointers, don't seek if the incoming run already has pointers attached.
