This is great
Considering strings I would like to suggest reusing the same strings data for similar strings, when one string is the tail of the other string. For example, if one uses two strings: "<03>Item" and "Item" in a map they share the single strings data block: "<03>Item". This little improvement to strings recycling is
very useful when implementing various in-game menus.
Read more.
About trigger editor. MacroTriggers is not flawless. If one wishes to make an advanced text editor for triggers, implementing macro capabilities for triggers replication, I can help him with the design. I have got some fresh thoughts on this topic.
To my mind a perfect trigger editor should not be either fully textual, nor fully user interface based. Such an editor should combine UI and text as a one. To get an idea of what I am talking about, have a look at the picture:
Currently selected trigger is in the blue box. From current selection you could select previous or next triggers pressing up and down arrows. If one wishes to modify the trigger he presses Enter, which moves focus inside the trigger and toggles to the text mode (just in place!). After finishing he let's say presses Shift+Enter which saves changes to the trigger and pops user up to the triggers selection level. If user wants to add a new trigger directly below the selected one he presses Ins. There are collapse boxes (red on the picture) to collapse triggers (also one can group triggers and collapse whole groups, then he can group groups of triggers and so on). One can write trigger comments which display directly above or below the trigger not hiding actions and conditions (unless collapsed). Also one can assign labels to triggers and display only triggers with the specific label.
A perfect example of such an interface is a Google Notebook plugin for Mozilla Firefox, which looks like this:
Also capabilities for triggers replication are strongly required. The design should support specification of replication of the desired trigger. This meta-trigger will then make up a group of similar triggers, which could be previewed but should be stored in the original form. I don't know how to explain it well at the moment, but if you'll have a look on Tuxlar's Astrogears triggers you'll probably get the point of what I am talking about.
With my experience of MacroTriggers I came up that other things which are required for a handy triggers tool are capabilities to define different "variables" (or in other words a way to give various names to map objects), to evaluate expressions with these objects, to specify raw conditions and actions in text way, and to define user conditions and actions via existing ones (technically, if one has means to define conditions from other conditions, only two kinds of "native" elements are required: raw condition and raw action, all other conditions and actions are defined via these).
Read more.
Some.