when pasting text, always complete the current cell by putting an extra space on the end. This might not be quite what we want, as we may want to paste something and then be in the middle of a cell edit... but more often, we want to paste multiple cells, and the last cell doesn't commit correctly if we didn't copy a space.
If a single sprite only supports 16 colors but has multiple palettes, you can cycle through the available palettes while editing it. But editing a 8x8 tile has special logic that causes it to switch the palette associated with a tile... which doesn't work in this case. So the 8x8 special logic should be skipped if its a 16-color image.
only expand the table using data that was already within the table for the new elements. This means that if you're doubling-or-more, you'll get the first element potentially multiple times (before you would get a _negative_ element, which doesn't exist)
Pasting raw bytes is useful in a few situations. But pasting over a pointer isn't safe. So any time you paste over a pointer (or pointer in a table), paste-raw-bytes will clear the formatting. Other than that, it's an easy way to paste arbitrary data, but can cause issues if you're not careful, such as pasting over compressed data.
if a tile isn't changed, don't remove it. This fixes an edge case in certain tilemaps (ex. emerald summary screen tilemap1) where a specific tile is used no matter what the tilemap says. Edits on the tilemap that don't effect the specific tile won't change the tile, and everything should still look right.
instead of calculating their length each time, an edited script can be passed its previous length. This lets you have multiple ends within the same script without issue.
The Measure step of the ColumnStackPanel is very slow, because the ContentControls that it holds, created from the DataTemplates, are very complex. Maybe a custom control could be created for the table with a much simpler visual tree.
Instead of taking the available name.token.parts and concatenating them in every possible order, add an algorithm that can check for the best match among the possible tokens and use that. Then remove that token from the list and try to match the rest.
This algorithm is more complicated, but doesn't require as many string and list operations, and searches k short strings instead of E(k) long strings, so it's faster.
In rare cases, you can get a race condition where we try to turn the address-for-anchor keys into a list while also adding a new address-for-anchor key. This multi-threaded work can crash the app.
Use a thread-locking version of version of the dictionary to prevent Keys from being accessed at the same time as Add.
Previously, trying to edit a script with gotos/calls inline would cause trouble, because the destination is likely contained within the same script. But HMA parses the anchor and puts the script in a separate textbox, which is confusing. Worse, it prevents you from making your script longer, because it thinks it would overwrite itself because of the anchor.
Add logic to handle this case.
- If a script is completely contained within the script that's currently under edit, don't give the script its own textbox.
- If the script would overwrite some bytes, but those bytes are a script that (1) is totally contained within the script you're editing, and (2) is only referenced by the script you're editing; then allow the overwrite to occur.
This has been a thorn in the project's side for too long. Remove Auto-Implement from the project. Include the needed types, and the created implementations. If more implementations are needed, or the current implementations need to be updated, I can add them by hand. The implementations that I've actually needed have been comparable simple compared to what AutomImplement provides: I haven't needed custom property or event implementations, for example. And I haven't needed custom constructor overrides, or overrides for multiple methods with the same name. Go ahead and remove it, along with the code generation steps that come with compiling the app/tests.
When showing a sprite in the table tool, we check to see what table index it is so we can use that index to find the palette. We need to do the same thing with tilesets. This means that GetPixels() needs a new parameter, the tableIndex, which can be passed in from any context that cares about it. Most of the time, getting the pixels doesn't care what the table index is. But now tilemaps can use this to figure out which tileset to use.
