As per Nepster's suggestion earlier in the topic (or maybe in PM?), "INITIAL_FRAME RANDOM" is now valid and recognized input. A negative number will also have the effect of a random initial frame, but let's encourage use of "INITIAL_FRAME RANDOM" rather than "INITIAL_FRAME -1".
Additionally, I have removed the support for recognizing the older "PREVIEW_FRAME" and "RANDOM_START_FRAME". Why? Because (unless they're used by some
very recent - as in last few weeks - addition to the styles download) the former hasn't been used
at all, and the latter is only used in a handful of my own styles - which I can easily make sure are up to date, and already have done so in the repo. Very possibly because the style convertor didn't handle them properly, and their existance was never really drawn attention to.
The earlier post detailing the system has been updated to reflect:
a) $PRIMARY_ANIMATION should be used in all cases, and define-in-main-segment should be treated as deprecated (previously, it was suggested that for now $PRIMARY_ANIMATION should only be used if use of an unsupported-in-main-segment new feature was desired)
b) Change of "CUT_xxxx" to "NINE_SLICE_xxxx"
c) Removal of "PREVIEW_FRAME" and "RANDOM_START_FRAME" in the backwards-compatibility code
d) Removal of the "LEFT" and "RIGHT" conditions
e) Addition of "INITIAL_FRAME RANDOM" as recognized (previously, no special keyword, but a negative number would have the same effect - negative number still works, because it'd be extra effort to make it
not work, but advise against using it as "RANDOM" is clearer)
f) "HIDE" specified without a corresponding STATE, will set the state to PAUSE (previously STOP)
In terms of what the editor needs to know to account for these:
a) Nothing, for now. The editor still needs to, for now, be able to understand either format.
b) Keyword change
c) The editor can remove the code (if any) for handling these two keywords
d) The editor can remove the code (if any) for handling these two conditions
e) The editor should recognize "INITIAL_FRAME RANDOM" and treat it as equivalent to a negative INITIAL_FRAME, however the editor handles those (player-side, a random frame is chosen, but editor side a rule like "always frame 0" might make more sense)
f) Nothing. HIDE + PAUSE and HIDE + STOP are equivalent as far as the editor needs to account for (there are subtle differences player-side - when the animation becomes visible again, it'll be on frame 0 in the case of HIDE + STOP, but on whatever frame it was on before disappearing (or the initial frame, if it's never animated or been STOP'd yet) in the case of HIDE + PAUSE).