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.
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.
* Don't assert on pointers that point _into_ elements in tables that accept pointers to elements. This is a data error, but the metadata is fine.
* Do clear anchors that would be in the middle of a new run
* Do clear anchors on pointers if that pointer has nothing pointing to it.
* Clear format when introducing a SpriteTemplateStream
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
Animation scripts can use the same engine as map scripts and battle scripts... except that they include a new type of parameter.
With animation scripts, the last parameter of some lines is allowed to include arbitrarily many arguments. This is represented by putting the last argument in brackets `[]`.
* battle script jumpifstat commands now properly categorize their destination as a battle script
* pasting a battle script or XSE script that forces a repoint will now properly interpret inner-pointers at the newly repointed address. This removes the need to paste a second time to fix up addresses after a paste causes a repoint.
* the script decompilers now do a bit more validation before running, so that they don't try to decompile data that is clearly not a script.
When copying a battle script and pasting it elsewhere, if some of the pointers are back into later points in the same script, the new pointers should point into the new script. Do this by checking for relative labels before checking for absolute addresses.
Merging lists takes a long time. Since we want the pointer sources to be sorted at all times, lets expose that detail and take advantage of it to allow us to merge-sort any time we combine tables together. This significantly increases list-merging speeds.
* Allow battle scripts to _not_ add a new code body if the code body contains a subset of already found code.
* Allow battle scripts to include XXXXXX: labels for parts that have things pointing directly to them.
* Improve battle script parameter recognition.
* remove undo within script editor textboxes
* properly clear formats when a script gets shorter
* properly clear formats of where pointers used to be when a script changes
* When checking for a need to repoint, use the proper script type
battle scripts are almost identical to pokescripts in how they work. Each command has a single-byte code, followed by some number of arguments, each of which are 1 to 4 bytes.
Because of these similarities, we can reuse the same engine code and just load the engine from another file. So the code tool can have a 4th mode and basically just work for free. Runs for battle scripts can be as simple as XSE runs: just a single byte, don't bothe decoding, show decoding only in the tool.
Still to add: how to know which battle script commands are ending commands, or which ones point to other battle scripts, or which ones point to strings. How to view battle scripts in the editor? Etc.
