This list appears to be a list of names for the areas. Not sure if it's connected to the overworld map, travel map, or something else. But it seems to be the only place where all the town/route names are stored in a single list.
Previous bug:
* Go to some wide data (like trainerdata)
* Scroll all the way to the right
* Do a pointer jump
* Scrollbar is gone, but data-clicking still thinks you're scrolled.
This allows us to detect what version of the app was used to last save changes to this file, which lets us detect when the user has upgraded HMA and is now using it on a file last touched with an older version.
For example, we could notice that there were new auto-tables added since the last version, and the user might want us to add them.
At this point, the start screen has become just a wall of text that no one reads. If I simplify it and only expose the tables people would most likely want to edit, it's more likely to be helpful for beginners.
With this change, you can now type a name of a bit into a bitfield to turn it on, and type a lone dash '-' to clear the bitfield. This makes it possible to have paste-scripts know the names of the moves they want to set, and then set them. For example:
`@tutormoves/bulbasaur - "mega kick" "solar beam" "grass knot"
The dash clears the bitfield, and then typing the names sets those bits.
The battle scripting commands are each an assembly routine that specifies what a specific battle script command does. Right now these are just raw pointers, but I have a feeling I'm going to want these in the future...
Each game handles the pickup tables a little differently. R/S/FR/LG store an item and the odds of getting that item (cumulative). Emerald instead stores two tables, one for common items and one for rare items. What values are used from within those tables are based on the pokemon's level.
When a table is expanded, instead of giving a new element a value based on whatever value is already there (usually FF), change the value so that the new element matches the previous element. This is likely not the value that the user wants, but it's a much better default than FF.
Previously, any invalid values typed into a pointer field in the table tool would be overwitten immediately with correct data. This made it almost impossible to manually type a value that would eventually be valid, such as `<null>`. This is now corrected: if the user types a value that would be an error, the error value is left in the field and no change or notification is made to the model.
When parsing table-streams, we shouldn't rely on an exception in the ArrayRun constructor. We should avoid even calling the ArrayRun constructor. Save exceptions for cases that are exceptional.
Make the `ExpandableTutorsWorks` test run slightly faster by letting it re-use Singletons between multiple tests for multiple ViewModels. Since the Singletons are uneditable, this is safe.
ScrollRegion should notify width change _after_ updating scroll range.
ViewPort should notify UI that the ScrollValue has changed after the ScrollRegion.Width changes.
Animation should be skipped if the previous scroll value isn't known.
update pp-pointers and code that uses them:
- search for the 5 pointers to the pp-data
- search for 42 00 12 18 92 00 (uses of a multiply by 12, the movedata width)
- find the nearest earlier use, and update to 0C 22 42 43 12 1D (*12+4)
update limiters:
- find uses of B1 20 40 00 81 42 (the limiter code)
- change the 00 to 02 (multiply by 512 instead of 2, MUCH higher limit)
Previously, the creating a new ViewPort loaded from 2 text files and creating a new HardcodeTablesMoel loaded from 1 text file. This is a lot of parsing!
Refactor to do the parsing once, in the EditorViewModel, using a Singleton class to hold the non-editable loaded data. Inject that data into the appropriate structers later on.
To prevent massive refactoring in the tests, not every ViewPort needs to be given a Singletons instance. Instead, allow a ViewPort to still do its own parsing. However, BaseViewModelTestClass has been updated to make this work for a majority of tests, along with changes to AutoSearchTests's fixture and several of the Setup methods that are used by multiple tests.
There are 5 pointers to the PP field in the movedata table. One of the goals of move-expansion is to simplify this by shifting these directly to the movedata table, so that repointing works automatically.
The 5 routines call only 2 subroutines using the PP field pointer, so my previous attempt changed those 2 subroutines. However, I failed to realize that (lots of) other code also calls these subroutines, so changing these subroutines has adverse side-effects. To correct this, I should change the 5 routines instead of the two subroutines.
This has been prototyped with FireRed and needs to be expanded to the other 8 roms.
This is currently not a user-exposed feature, but it was very helpful while researching how to make the proper changes for move-expansion.
It shouldn't be exposed (CodeTool.IsReadOnly=false) until I figure out how to handle edge cases and compile error reporting better.
The code didn't quite do what I meant for it to do. Fixed the broken offsets, fixed the broken code, and made the operation use the undo system.
The code still doesn't have the effect I expected, but at least it's now making the changes I expected.
Also adds automated tests to show that the code works like I expect. Note that this hasn't been tested in the actual games yet.
Note that a version of QuickEditItemDecorator needs to be checked in to avoid a boot-strap issue, since QuickEditItemDecorator is needed in the same assembly as IQuickEditItem. I could alternatively do a double-build of only the interfaces to fix this, but that seems heavy-handed for now.
When loading from a TOML file, the bitsegment might get created before the table that it's based on. If so, then the bitsegment (and thus the entire table) will need to be expanded. When that happens, we need to expand in-place, because the original format was too short to encompass the data.
When that happens, we need to clear away whatever format is already in that spot, because that format is known to be wrong.
Related change: do a ResolveConflicts step as soon as we finish loading the metadata, to make sure that the metadata-load didn't leave us in a bad state.
To help users understand the features of the program, go ahead and have the table tool open by default. This has the benifit of showing a drop-down list with all the current known tables, so the user can quickly jump to them. This is similar to how other programs show some of their tools by default, helping the user know what things are possible with the application.
Also move the Table Tool to be the top tool for consistency.
