Originally posted by imameliaI'd figured on just having one 0x30-byte table of VRAM addresses, one 0x18-byte table of trigger settings, and one...um...0xB40-byte table of animation data (2 bytes per frame, 4 frames per animation, 2 possible animation states, 0x18 animations, 0xF tilesets). ...Where did you get the 0x1B animations from, anyway?
While 2*4*0x18*0xF is indeed 0xB40 bytes, you've forgotten about frames for trigger animations. If you open up JW's editor, you'll notice it includes the trigger animations (8 of them) but does not include the extra 5/18 slots that SMW doesn't make use of, so you have 13+8=0x1B animations.
Assuming you want to go further and allow a full 0x18 animations and also only wish to include trigger states for the ones the game originally did, your table should really be 2*4*(0x18+8)*0xF=0xF00 bytes.
Originally posted by imameliaSpeaking of tilesets, would there be any use for tileset F? Maybe for bypassing all original loading routines or something, kind of like how item memory setting 3 disables item memory?
There are probably better ways to bypass things, where you wouldn't be left wondering what might break in the original game.
Originally posted by mengrid... and a crazy idea: Office's ribbon look, that would fit perfectly with the unification of another tools
Not really a fan of the ribbon.
Originally posted by ShogFusoya, you said that you have some "higher" priorities than the rather not-that-important Undo/Zoom Button. But...what are you priorities?
The most recent priority was replacing the Map16 editor. That's pretty much done though, except for one feature that I might go further on but haven't gotten around to yet.