The trouble with the example video shown is that it looks like the flashing light is just a second object behind the bear trap. If it, say, turns off when the trap is disarmed, then it's a little more convincing.
Looks really good this does namida :)
I'm excited to make use of this feature in my Sonic tilesets, is there anything I can do to prepare my tilesets for this feature. Like how would I make the image strip now with respect to these changes?
I hate having too many folders. I rather have more files - even more if the pairs of 2-4 have fitting names. :P
Maybe discussing possible animations first and then implement would be best for the original tilesets ???. For the custom ones the creator should have the last word.
-Locked exits: I have not seriously looked into this so forgive me if I'm misunderstanding here but why do we need idling animations for locked exits? Isn't it enough that a door is over the exit signifying that it's locked and when it unlocks the door opens (goes away)?Until now we always have two sprites for locked exits: One actual exit object and the second one the flames on top. The idling animations would allow combinung these two sprites. So you would only place a single locked-exit object in the level and it would have the usual nice flames.
-Question to Nepster: Why is it bad that you must have an exe next to your editor? Why would you want/need to have it anywhere else? Or are you simply saying that it's bad that the editor depend upon the exe?1) I do have several editor test applications, that don't have any NeoLemmix.exe next to them.
2) It is very, very important for me to be able to use the editor without a NeoLemmix.exe next to it. Yes, for play-testing the NeoLemmix.exe is necessary, but this should be an exception. Now, we cannot even display levels without having a NeoLemmix.exe next to it!
So what is not needed?
- I really see no need for nine-slicing
WRT complicating the code - most of the important stuff is contained in its own classes. Also, Simon suggested in Discord that the system should be future-proof and allow for multiple animations, in case future objects end up needing more. So I did exactly that. Lots of flexibility for content creators is a bonus that results from this. This system can easily be updated in the future to give extra conditions, if objects are added where they're relevant. It already accounts for objects that might end up needing multiple secondary animations - indeed, I've already found use cases for this:I have nothing against future-proof extensible design. But it should be easy to understand and use. And given my problems to understand why we need nine-slicing, when to use it or even how to create a decent first frame for the editor, the current design is not easy to understand.
- default:pickup - Absorbing masks into the secondary anims system, instead of having both of them in effect (which seems silly, as masks are basically just recolored but otherwise simpler secondary animations), means two secondaries are needed for the two different color regions. This would also hold true for any future objects that need multiple recoloring - and while this is currently only used by default:pickup and the various default:owa_xxx objects, it's supported for literally any object of any type in any style.
- namida_basement:exit - This one is purely aesthetic, and could be done without multiple (or even any) secondaries, had it been done up front. The only way in which it depends on the secondary anims system is that it allows the glows to be outside the original boundaries of the object.
- namida_horror:exit_02 - This one previously didn't have any secondary-animation-via-second-object (just the unlock animation, otherwise it was static), but had a (non-animated) red or green light depending on unlock status. Now, the light glows - this needs one secondary anim for the red glow, and one for the green glow. As well as multiple-secondary support in general, this also relies on the conditional logic type stuff - which really is quite simple.
And this is just with "what could it be useful for on existing objects". There's even more potential for it on new objects, which can be designed with these capabilities in mind.
Ok, slowly but surely I start to understand what nine-slicing is about. But this seems to me like a completely different use-case than secondary animations, or am I mistaken there? Secondary animations are for switching animations depending on the object state, while nine-slicing is about nice looking edges of resizable objects.QuoteSo what is not needed?
- I really see no need for nine-slicing
Okay, I'm going to disagree with you really hard on this one. If anything, I would rather ditch the complex secondary anims and keep the nine-slicing feature. As a particularly strong case, take a look at the updrafts in namida_machine. To get the proper visual appearance, any updraft region using that style's updraft (assuming it doesn't intersect indestructible terrain or level boundaries on one or more sides) previously needed nine objects in the level, of six different object types (with the last three being the same object as another three, but flipped horizontally). With nine-slicing, this can now be done as a single object, and retain perfect visual appearance. The default updraft, and the fire objects in namida_machine, have also benefitted from this to a lesser extent. Further uses for this could allow for nice vertical resizing of water objects, too, rather than having to paste multiples on top of each other - I just haven't got around to actually doing this yet. Essentially - any resizable object that should have a clearly-defined edge, benefits hugely from this feature.
I would perhaps agree that there's no real need for secondary animations to support it, but with the current implementation, it would be more code for secondaries to not support it.I now wonder: Does NL first merge the secondary animations into the primary one and then apply the nine-slicing, or the other was around, i.e. first apply nine-slicing to both animations and then merge them?
I would also agree that it should really have been implemented as a separate feature that in turn is supported in the animation system, instead of being implemented together with this animation system, but I approached this as a general "improve the object rendering" and thus did both at the same time.Yeah, see my comments above. There has been quite a bit of confusion about this on my part.
I now wonder: Does NL first merge the secondary animations into the primary one and then apply the nine-slicing, or the other was around, i.e. first apply nine-slicing to both animations and then merge them?
As soon as we have a system, where I don't have to look at the NL player rendering code to find out what the first (idling) frame should look like, but can determine this purely from the posts here and the .nxmo/.png files, I am happy. In that case I will gladly implement that rendering in the editor, to avoid the dependency to the NL player completely.
By that I understand "something that affects the rules / game mechanics" of Lemmings.
...
Are there any other gameplay-relevant uses for this?
[explanations on animations]Ok, that's a lot of information and I am pretty sure I am still misunderstanding half of it. I have a few questions, but almost certainly more will appear once I start implementing the editor-side rendering in earnest:
I was actually quite surprised to see triggered animations had been removed. Unlike radiation / slowfreeze, they don't complicate gameplay, and 99% of the code needed for them to function is needed anyway for other object types that still exist (most notably traps, which are essentially just a triggered animation that also removes a lemming). And especially with the secondary animations feature, there's probably a lot of artistic potential in them, too...The main reason is player expectations: If something triggers, then this signals a game physics effect on a lemming. With the various gadget types it is hard enough to newer players to learn the various effects NL supports. No need to confuse them with no-effect effects ;). This all stems directly from my own experience as a player: Such objects have been very rare, so when I first encountered it, I wasn't even aware that NeoLemmix supported triggered animations. So I tried for half an hour to find out, what this gadget actually does and never found anything! :devil::devil::devil:
1) Why do we have to distinguish between primary animations and secondary ones? It seems that the secondary animations are even more flexible, and the only advantage of primary animations is, that they override certain attributes. But then the style designer should not set the attributes in the first place.
2) As the STATEs seem to be (and should be) mutually exclusive, they should be set as an attributes, i.e. like "STATE PLAY". If we have stuff like "LOOP_TO_ZERO" as keywords, that would indicate to me, that it can be combined with the "PLAY" or "PAUSE" state for example.I noted above that it seems weird to have them defined as single-line keywords in one place, and values of a "STATE" keyword in another. Good point here; let's make it "STATE _____" in both cases.
3) Why do we need "Z_INDEX"? The default specifies a certain order anyway, which is pretty natural, so I don't see any need for this attribute.Currently, the primary animation is treated as coming first in file order regardless of where it's actually placed. Z_INDEX allows placing in front of OR behind it. We would need to change how the primary animation is defined, to continue allowing for this without a Z_INDEX - relying on its order in the file, since it uses a $PRIMARY_ANIMATION tag instead of an $ANIMATION, would violate the "lines / sections are not order-sensitive in relation to lines / sections with different keywords" rule, and would also need a rule on where in the Z order it goes if specified in the main segment (for backwards compatibility, or just because it's an object with only one animation, or any other reason).
4) Why do we need "HIDE" as an option for secondary animations? If we are not displaying anything, then why have this secondary animation at all?Reason 1 - future animations that don't get used directly. For example, digits for a limited-count exit / entrance.
5) Regarding "INITIAL_FRAME": At what point did we deprecate "RANDOM_START_FRAME" and introduced the "-1" instead? I would have preferred to add "INITIAL_FRAME RANDOM" instead. (Might very well be, that it was me who introduced the "-1" and I am criticizing myself here...)No, this was something I did during creating this system. Yeah, "INITIAL_FRAME RANDOM" could be a special case that's interpreted as equivalent to -1. I'd say similar logic to in your point #2 applies here - don't have it as an entirely separate command either way.
6) I am still unsure which of the STATEs and the TRIGGER types are actually necessary for the most common use-cases (i.e. idling traps and locked exits), and which are just for potential future use? Can we stick to the absolute essentials for now? This would help people like me to get used to this.I've already found use cases for all of these (except, IIRC, "TRIGGERED", but there are differences player-side between this and "BUSY"*), though some are definitely more common. But as a few examples:
The main reason is player expectations: If something triggers, then this signals a game physics effect on a lemming.Counter-examples: Unlock buttons, pickup skills, locked exits. None of their animations directly affect a lemming physics-wise. Counter-counter-point: ...although they do all indicate something physics-related at least.
With the various gadget types it is hard enough to newer players to learn the various effects NL supports. No need to confuse them with no-effect effects ;). This all stems directly from my own experience as a player: Such objects have been very rare, so when I first encountered it, I wasn't even aware that NeoLemmix supported triggered animations. So I tried for half an hour to find out, what this gadget actually does and never found anything! :devil::devil::devil:We have clear physics mode nowdays; and an up-to-date NeoLemmix Introduction Pack should help here too. I did start working on something, but then got bored with it for now.
PS: I actually would prefer an even stronger rule, namely: If something moves, it either is currently interacting with a lemming or has at least the potential for it. Unfortunately moving background pieces break that rule (which is why I wanted to remove them at some point)...Clear physics mode, and (maybe?) the "hide background" options deal with those situations. (Triggered animations could perhaps be included in that option too, maybe a general "remove visual fluff" option? I suspect few, if any, users will feel the need to be able to pick-and-choose on a finer level here.). NeoLemmix has always tried to account for both the puzzle side and the artistic side of creativity; triggered animations and moving backgrounds are both beneficial to this, and the full extent of secondary animations will be helpful to that end too.
bool DoesConditionPass(bool conditionResult, enum conditionRequirement)
// enum values: "TRUE", "FALSE", <not present>
{
switch (conditionRequirement)
{
case "TRUE": return conditionResult;
case "FALSE": return !conditionResult;
case <not present>: return true;
}
}
int GetAnimationDisplayFrame(params)
{
const int RESULT_HIDE = -1; // actual value doesn't matter, just needs to be a unique negative number
const int RESULT_RANDOM = -2;
const int RESULT_HIDE_OR_RANDOM = -3;
bool hideIfAllowed;
enum state; // enum values: "PLAY", "PAUSE", "STOP", "LOOP_TO_ZERO", "MATCH_PRIMARY_FRAME", <other / not present>
foreach ($ANIMATION + all "$TRIGGER"s inside it) // $ANIMATION first, then each $TRIGGER in file order
{
if (this is a $TRIGGER, not the base $ANIMATION)
{
bool conditionsPassed = true;
// FRAME_ZERO
bool thisConditionState = true;
if (<gadget type> is not one of [infinite-trap, /*pickup, locked-exit,*/ teleporter, receiver, splitter, hatch])
or (<gagdet type> is splitter && gadget is facing right (ie: frame 1))
// or (<gadget type> is pickup && gadget has a skill assigned (ie: not frame 0))
// or (<gadget type> is locked exit && level contains unlock buttons (ie: exit should display as frame 1))
thisConditionState = false;
if (!DoesConditionPass(thisConditionState, $TRIGGER."FRAME_ZERO"))
Continue; // the forEach loop
// FRAME_ONE
bool thisConditionState = true;
if (<gadget type> is not one of [pickup, locked-exit, button, splitter, single-trap])
or (<gagdet type> is splitter && gadget is facing left (ie: frame 0))
// or (<gadget type> is pickup && gadget has no skill assigned (ie: frame 0))
// or (<gadget type> is locked exit && level lacks unlock buttons (ie: exit should display as frame 0))
thisConditionState = false;
if (!DoesConditionPass(thisConditionState, $TRIGGER."FRAME_ONE"))
Continue; // the forEach loop
// TRIGGERED
if (!DoesConditionPass(false, $TRIGGER."TRIGGERED"))
Continue;
// BUSY
if (!DoesConditionPass(false, $TRIGGER."BUSY"))
Continue;
// DISABLED
bool thisConditionState = false;
// if (<gadget type> is teleporter && <no receivers exist in level>)
// or (<gadget type> is receiver && <no teleporters exist in level)
// thisConditionState = true;
if (!DoesConditionPass(thisConditionState, $TRIGGER."DISABLED"))
Continue;
}
}
hideIfAllowed = $TRIGGER."HIDE".IsPresent?; // or $ANIMATION, as applicable
state = $TRIGGER."STATE"; // or $ANIMATION, as applicable.
if (state = <other / not present>)
{
if (hideIfAllowed)
state = "STOP";
else
state = "PLAY";
}
}
if (hideIfAllowed)
{
if (state is one of [STOP, PAUSE])
return RESULT_HIDE;
if (state is LOOP_TO_ZERO && $ANIMATION."INITIAL_FRAME" = 0) // INITIAL_FRAME being absent counts as zero here
return RESULT_HIDE;
if (state is LOOP_TO_ZERO && $ANIMATION."INITIAL_FRAME" < 0)
return RESULT_HIDE_OR_RANDOM; // edge case.
}
switch (state)
{
case "PAUSE", "PLAY", "LOOP_TO_ZERO": // note that <other / not present> is already changed
// to either "PLAY" or "STOP" by this point
if ($ANIMATION."INITIAL_FRAME" < 0)
return RESULT_RANDOM;
else
return $ANIMATION."INITIAL_FRAME";
case "STOP":
return 0;
case "MATCH_PRIMARY_FRAME":
return <primary anim's frame>;
}
}
If something moves, it either is currently interacting with a lemming or has at least the potential for it.
- For a teleporter (A) linked to a receiver (B), "TRIGGERED" is true for A while A is animating, and true for B while B is animating; at other times, it is "false". "BUSY" is true for both A and B while either of them is animating, and "false" at other times.
Hmm, I haven't thought about such a very strong link between two gadgets' states/animations. This breaks a 1:1-association between states and animations. I'll read everything again before advising further; I'd really like to keep all physics intact.
Not all animations classify into idle or busy. I'd rather not associate "primary" with busy and "secondary" with idle (exits feel more idle than busy, yet have only a primary animation).
Sorry, but if they are so similar, then why do we need to differentiate them? I still see no reason for this. Wouldn't it be easier for both player and editor to have just one $ANIMATION keyword? Then all the issues with the Z_INDEX would disappear as well.Quote1) Why do we have to distinguish between primary animations and secondary ones? It seems that the secondary animations are even more flexible, and the only advantage of primary animations is, that they override certain attributes. But then the style designer should not set the attributes in the first place.
Primary animation is tied to physics, same way that the lone animation up until now has been. Aside from that, they are indeed identical (outside of NL rejecting a few specific settings on the primary) - the primary animation is loaded by the same code as the secondaries just with a few properties being overridden. Rendering also uses the same code as primaries, though frame update does not - the primary is perpetually in a "paused" state, with the frame number being directly manipulated by game physics.
Future animations should not be part of the style (or at least not be referenced in the nxmo file). I don't understand your reason 2: Is it not possible to describe within the $TRIGGER part, that the animation should only start under some condition (potentially in combination with an empty first frame)?Quote4) Why do we need "HIDE" as an option for secondary animations? If we are not displaying anything, then why have this secondary animation at all?Reason 1 - future animations that don't get used directly. For example, digits for a limited-count exit / entrance.
Reason 2 - animations that don't display in default state, but do when one of the triggers is fulfilled. For an example of this, see namida_horror:exit_02. Or the inverse - displaying usually, and hiding when a condition is fulfilled - which namida_horror:exit_02 also provides an example of.
Well, yes, one can always come up with some use-cases for anything. But a lot of your examples above don't sound like they occur often. As such I really don't know whether it is useful to have them: They add complexity and are potential sources for bugs. Is usage in one or two pieces really enough to compensate for this? My idea here is to implement only the most common features at first and then see what further requests are supported by multiple users here. After all - if I learned one thing from the change to new-formats, it is: Adding new features is far easier than removing existing ones.Quote6) I am still unsure which of the STATEs and the TRIGGER types are actually necessary for the most common use-cases (i.e. idling traps and locked exits), and which are just for potential future use? Can we stick to the absolute essentials for now? This would help people like me to get used to this.I've already found use cases for all of these (except, IIRC, "TRIGGERED", but there are differences player-side between this and "BUSY"*), though some are definitely more common. But as a few examples:
- The common blinking-light makes use of the instant-stop (vs loop_to_zero), and the "BUSY" condition (light stops blinking while trap is killing) and "DISABLED" condition (light stops blinking when trap disarmed).
- The "bob up and down / side to side when idle" effect, eg. ohno_snow:trap, requires hiding secondary animations on a BUSY (or TRIGGERED) condition to avoid really weird visuals when triggered, and the "PAUSE" (without going back to frame zero) so the position won't suddenly jump by a couple of pixels (depending on current frame) when the trap gets disarmed.
- For an example of why the absence of these can be important, see ohno_brick:trap_02. The secondary animation on that one only pauses (remaining on its current frame) when the trap is disarmed, not in any other case.
A post earlier in the topic (https://www.lemmingsforums.net/index.php?topic=4188.msg75007#msg75007), which I've mostly been keeping updated with new exp's, details in full how this new system works.Ok, will probably have to read through all of this. Thanks for linking it.
Yeah, perhaps a more precise way of stating my point would have been: If something animates, this signals a game physics effect either on a single level or the level state as a whole.QuoteThe main reason is player expectations: If something triggers, then this signals a game physics effect on a lemming.Counter-examples: Unlock buttons, pickup skills, locked exits. None of their animations directly affect a lemming physics-wise. Counter-counter-point: ...although they do all indicate something physics-related at least.
But I don't want to play Lemmings in the future only in clear physics mode! My goal is still that the usual level image gives the player all the necessary information, with clear-physics being used only as a fallback.QuoteWith the various gadget types it is hard enough to newer players to learn the various effects NL supports. No need to confuse them with no-effect effects ;). This all stems directly from my own experience as a player: Such objects have been very rare, so when I first encountered it, I wasn't even aware that NeoLemmix supported triggered animations. So I tried for half an hour to find out, what this gadget actually does and never found anything! :devil::devil::devil:We have clear physics mode nowdays; and an up-to-date NeoLemmix Introduction Pack should help here too. I did start working on something, but then got bored with it for now.
NeoLemmix has always tried to account for both the puzzle side and the artistic side of creativity;... but it's still mainly a computer game, not some art show. As such NeoLemmix has to strike a balance between these two, and triggered animations are far more confusing for game-play compared to the artistic advantages. At least their removal was one of the least controversial cullings, with only one or two triggered animations ever made for the old-formats styles, which tells me that there is no real need for them even from an artistic point of view.
Perhaps we should approach this as a joint effort - you know how you like things to be loaded, etc; while I understand in full how the system works, down to the technicalities / etc.Basically I am currently using the editor support also as a check: Is this feature simple enough that other users, except you yourself, can understand and use this feature? So I would like to continue trying to implement the frame-finding in the editor, but you are more than welcome to check the implementation, once I consider my implementation finished. Nevertheless thanks for the offer! :thumbsup:
Yeah, and I totally agree with you that we need idling animations both from an artistic and from a game-play point of view. I am just criticizing the (remaining) complexity of the current solution.Quote from: NepsterIf something moves, it either is currently interacting with a lemming or has at least the potential for it.I have pushed for more than 2 animations per gadget because of an even stronger variant of this guideline: What moves, can interact, and what does not move, is terrain.
Future animations should not be part of the style (or at least not be referenced in the nxmo file). I don't understand your reason 2: Is it not possible to describe within the $TRIGGER part, that the animation should only start under some condition (potentially in combination with an empty first frame)?
- Remove gatcDisarmed and use gatcDisabled instead: The only difference is for one-use traps, but as the game basically treats used-up such traps in the same way as disarmed ones anyway (for all other purposes like display in clear-physics), I don't see a compelling reason to have this distinction here.
For hatches, left-facing only occurs when flipping the hatch, which (hopefully) flips the secondary animations as well.
Regarding less differentiation for the primary animation and getting rid of Z_INDEX (the former of which I feel is necessary if we're going to do the latter) - yeah, we could make this an $ANIMATION section that includes the "PRIMARY" keyword. The only thing here is we need a rule here - if the primary is instead defined in the main section (and I absolutely want to keep this, for many reasons), does it get treated as being first or last in the animation list? I would lean towards "last" here, for the same reason I defaulted it's Z-index to 1 - although not always, we'll usually want to draw the secondary behind the primary in case of overlap.Sorry for being obnoxious here, but I still don't understand why we need either a $PRIMARY-ANIMATION or a PRIMARY keyword? What would turn impossible if we just had the usual .png, that we already had in all previous versions, and then only the secondary animations? In other word: What would be impossible to do, if I never used either $PRIMARY-ANIMATION or the PRIMARY keyword?
"LEFT", "RIGHT": Maybe these are unnessecary. Let's remove them for now, maybe? Adding them back later would be simple enough.You convinced me, that having "DISARMED" as an extra keyword is worth having. But I would still remove the "LEFT" and "RIGHT" keywords for now (though keep the code in an extra branch, so that we can easily merge it back into the main one if desired).
"DISARMED" vs "DISABLED": As mentioned above, I do feel it's important to have some way to distinguish between "disarmed" and "used up" on a single-use trap, which is why I separated these in the first place. But I'm open to acheiving this a different way - as long as distinguishing remains possible.
PS: Any reason you reimplemented nineslicing? If you just didn't see I had implemented it, no worries. But if you did, but chose to use your own implementation - mind if I ask what in particular you weren't keen on from mine, just so I get an idea of how you want things done for future commits?Yeah, I simply didn't see your implementation, mainly because I didn't think of checking and was on a train ride when I coded my implementation. See your PMs for a code-review of your implementation.
Sorry for being obnoxious here, but I still don't understand why we need either a $PRIMARY-ANIMATION or a PRIMARY keyword? What would turn impossible if we just had the usual .png, that we already had in all previous versions, and then only the secondary animations? In other word: What would be impossible to do, if I never used either $PRIMARY-ANIMATION or the PRIMARY keyword?
The primary animation can be defined in either a $PRIMARY_ANIMATION segment (or as an alternate proposal: an $ANIMATION segment with a "PRIMARY" keyword), or in the main segment of the NXMO file.Yeah, that's a much better way to ask my question, than what I wrote above. Until your latest post, I was confused when to use $PRIMARY_ANIMATION and when to use the main section (or whether I have to duplicate stuff now).
The downside here is - either loading code needs to be duplicated, or the main segment has to be parsed a second time (as an $ANIMATION segment), or it just ends up getting translated internally to an $ANIMATION segment with special handling (which is pretty much what already happens).If adding a $PRIMARY-ANIMATION part is still optional, then you will have to parse it (twice?) regardless of whether we change it to main-section only or not. So I don't see any downside of forcing primary animations to be defined in the main section. If nothing else, then it removes the confusion about when to define stuff in the main section and when to use $PRIMARY-ANIMATIONs.
Also, I don't really know how I'd feel about having a "NAME" parameter for an animation, in the main segment - though perhaps NAME could just be disallowed altogether for the primary.Good point, but so far it worked pretty well to use the same name for the .nxmo file and the main animation .png file.
If adding a $PRIMARY-ANIMATION part is still optional, then you will have to parse it (twice?) regardless of whether we change it to main-section only or not. So I don't see any downside of forcing primary animations to be defined in the main section. If nothing else, then it removes the confusion about when to define stuff in the main section and when to use $PRIMARY-ANIMATIONs.
If adding a $PRIMARY-ANIMATION part is still optional, then you will have to parse it (twice?) regardless of whether we change it to main-section only or not. So I don't see any downside of forcing primary animations to be defined in the main section. If nothing else, then it removes the confusion about when to define stuff in the main section and when to use $PRIMARY-ANIMATIONs.
Good point, but so far it worked pretty well to use the same name for the .nxmo file and the main animation .png file.
The intent here - $PRIMARY_ANIMATION would eventually become the "normal" way of defining it, and - a long way down the track - use of the main section would be deprecated and maybe eventually removed.Ok, now I can understand why you introduced the $PRIMARY_ANIMATION. While I wouldn't have done so myself, it might actually prove useful in the long run. So let's keep the $PRIMARY_ANIMATION (which I prefer over adding a PRIMARY attribute to secondary animations), but do three other things as well:
Ok, now I can understand why you introduced the $PRIMARY_ANIMATION. While I wouldn't have done so myself, it might actually prove useful in the long run. So let's keep the $PRIMARY_ANIMATION (which I prefer over adding a PRIMARY attribute to secondary animations), but do three other things as well:
1) Deprecate the old way right away (which is mainly a case of making this change in the graphics tool - but does anyone still use it?)
2) Clearly communicate that new styles should use $PRIMARY_ANIMATIONs. Don't we have some guidelines about graphic style creation here on the forums, where this should be added?
3) Fully change a few styles right now, so that other graphic designers have enough examples to copy from.
If DISABLED is one-shot trap that has been used, then rename to EXHAUSTED. It's the same principle as behind the exit that closes after a given number of exiters.
DISABLED vs. DISARMED vs. EXHAUSEDTo make namida's suggestion somewhat easier to digest, I tried to create a table for the current implementation.
Type | DISABLED | DISARMED | EXHAUSTED
-----------+----------+------------------+-----------
Inf. Trap | disarmed | disarmed | --
Once Trap | disarmed | disarmed or used | used
Pickup | used | -- | used
Button | used | -- | used
Limit Exit | -- | -- | used
The suggestion seems to be something like: Type | DISABLED | EXHAUSTED
-----------+----------+-----------
Inf. Trap | disarmed | --
Once Trap | disarmed | used
Pickup | -- | used
Button | -- | used
Limit Exit | -- | used
Please correct me (or just edit this post), if I made mistakes in summarizing your post. I am in favor for the change (i.e. having only DISABLED and EXHAUSED).2. Yep, this makes sense. We should have a "Information regarding V12.05.00 for style creators" topic, [...] Perhaps wait until a V12.5.1 update to do this.The shimmier together with the secondary animations seem large enough to me to go even to V13.0.0. While this might not be totally according to semantic versioning, this might help players to distinguish versions and ensure compatibility between player versions and level packs.
The shimmier together with the secondary animations seem large enough to me to go even to V13.0.0. While this might not be totally according to semantic versioning, this might help players to distinguish versions and ensure compatibility between player versions and level packs.