Wild guess: The editor cannot decide between displaying scroll bars or not. It first decides that it needs a vertical scroll bar, shrinks the level area accordingly, then notices that it actually doesn't need the scroll bar and forgets to enlarge the level area again.

1) The current styles.ini simply contains my own preferences of names (and ordering), so I don't consider the current user-friendly names to be official.
2) The user-friendly name has a lot more restrictions concerning style name length (not fixed in terms of number of characters, but rather concerning display width), because the editor just has little space for it. So we would have to tell all style creators that. I would really like to avoid having to edit the styles themselves myself.

QuoteDISABLED vs. DISARMED vs. EXHAUSED

To make namida's suggestion somewhat easier to digest, I tried to create a table for the current implementation.
- "--" means that this situation can never happen
- "disarmed" means that a lemming with a disarmer skill worked on it
- "used" means that (one or more) lemmings interacted with the object normally and due to that it can no longer interact

   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).

Quote from: namida on May 19, 2019, 08:25:10 PM
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.

Quote from: namida on May 17, 2019, 07:39:39 PM
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:
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.

QuoteThe 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).

QuoteThe 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.

QuoteAlso, 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.

I implemented now a better way of rendering flipped hatches: The hatch sprite now gets never flipped (consistent with the player), but now an arrow is drawn at the bottom right corner of the hatch to indicate the direction.

Quote from: namida on May 15, 2019, 08:17:41 AM
Let's suppose we have a tunnel that's vertically *just* too short for a shimmier (or maybe even shorter than that), followed by a drop (but the ceiling continues). If you assign a shimmier to a lemming on the last pixel before he drops off the edge, he can shimmy from that point.

Fixed now.

Once we have the remaining shimmier sprites, I would merge the shimmier code in the main master branch for the official release.

Thanks for the concise summary of the current state

QuoteRegarding 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?

Quote"LEFT", "RIGHT": Maybe these are unnessecary. Let's remove them for now, maybe? Adding them back later would be simple enough.
"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.

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).

QuotePS: 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.

Quote from: Proxima on May 17, 2019, 12:55:11 AM
I don't like the suggestion to make the minimap variable-sized. It's true that it doesn't cope well with large levels, but there's no reason to think size of level is negatively correlated with number of skill types (if anything, you'd expect to see positive correlation).

Instead, we could get rid of some of the "Korean washing machine" buttons. Directional select can go; it's much more convenient to use a hotkey.

If you select the "Compact Skill Panel" (which is the old-style one) in "Options -> Interface", you don't get the "Korean washing machine" button like directional select, you just have nuke, pause and fast forward.
Nevertheless suggestions like removing nuke and fast forward (and make Esc non-configurable, so that players can't lock themselves out) sound like sensible alternatives to shrinking the minimap.

As I mentioned in the other thread:

QuoteI prefer the NeoLemmix system over the Lix system of always displaying all skills, because the Lix system means lots of grayed-out buttons (because the skill is not used in the level) and less flexibility regarding additions of new skills.

However this was written from a NeoLemmix perspective with the question in mind: Should we copy the Lix skill panel for NeoLemmix? For Lix itself, I have less problems with the current skill panel: Lix simply has less skills than NeoLemmix and Lix does not plan to add new skills (like the NeoLemmix shimmier and jumper) in the near future.

I implemented it this way to give at least some visual clue in the editor, how the hatch is facing. So the actually intended behavior would have been exactly what you did in your commit 3177040.

I totally agree though, that this was not a perfect solution and should be replaced by something like displaying a small directional marker in the editor. Will have a look...

Quote from: IchoTolot on May 15, 2019, 11:34:03 AM
As I tend to get easily confused with the yellow rectangle way and speed is not essential as in Lix multiplayer, I would tend to the red rectangle way.

Then we would need another way to tell the player that wrap is active though.

I would still say yellow is faster and you need to be fast in MP Lix, but it can get very confusing depending on the level (especially small levels can get confusing). Here in NL we don't need to be very fast and therefore I tend to red.

The main problem with the gimmick-implementation (which used the red rectangle) was, that one could never be sure where the lemming would reappear when moving out of the level boundary. This made these gimmick levels extremely annoying to play. So I think any reintroduction of this feature would need a way to scroll beyond the level boundaries and allow displaying the yellow area on screen.

My suggestion: Add potential for two more skills, i.e. 10 in total. By shrinking the minimap, we can fit them in nicely. As this would mean making the menu bar more adaptive to the number of skills in the level, I would go even as far as: Never display any empty skill panels, but use the newly freed space for the minimap (so that a level with just two skills would have a huge minimap).

Quote from: Strato Incendus on May 15, 2019, 01:43:48 PM
When the number of skill types exceeds 8, the section of the bar dedicated to skills (rather than the Minimap, Replay/Rewind buttons etc.) remains the same size, but the cells for the individual skills get smaller. In this case, one would have to put this to a litmus test to see how small the individual skill button can actually get when you throw in all skill types which are currently available.

As we currently store everything in pixelated sprites, I fear that they will look horrible when shrinking the cells.

Quote from: Strato Incendus on May 15, 2019, 01:43:48 PM
The skill bar expands - most likely to the right - when additional skills are added, at the cost of shrinking the other components. Most likely, this would mean making the Minimap less wide, since buttons like Pause/Nuke/Rewind/Clear Physics should remain the same size as the skill buttons. This would not require the buttons to be redrawn, but the Minimap would have to be able to adapt in size - not gradually, fortunately, but at least step-wise, becoming one step smaller for each increase of the skill bar beyond 8.

As mentioned above, I like a solution similar to this, but remember some previous discussions that this would only work for at most 10 skills in total. Note that even now NeoLemmix supports some different minimap sizes (IIRC depending on window size and zoom factor), so this should not be too much work regarding the minimap.

Quote from: Strato Incendus on May 15, 2019, 01:43:48 PM
Scrolling through a skill bar which is only partly visible - totally had not thought of that. That somehwat violates the "immediacy" philosophy though, which has already lead to changes that follow principles such as "one should never have to use clear physics", the level itself should show you everything you need to know right from the start.

As Simon already mentioned, the skills are so vital to the game, that they should always be displayed.

PS: I prefer the NeoLemmix system over the Lix system of always displaying all skills, because the Lix system would mean lots of grayed-out buttons (because the skill is not used in the level) and less flexibility regarding additions of new skills.

Quote from: namida on May 15, 2019, 08:17:41 AM
Let's suppose we have a tunnel that's vertically *just* too short for a shimmier (or maybe even shorter than that), followed by a drop (but the ceiling continues). If you assign a shimmier to a lemming on the last pixel before he drops off the edge, he can shimmy from that point.

Good find! Totally agree that this should be changed.

Quote from: namida on May 15, 2019, 08:17:41 AM
Also, I'm really not sure about the Shimmier's placement in the skill order. I know in general there's an intention to overhaul the order altogether, but as far as the current system goes - I feel it should come either between Disarmer and Bomber, or between Blocker and Platformer, with me leaning a bit more strongly towards the latter. Reasoning: It's a short-term ability that's used instantly and is gone once the lemming stops performing the action, but doesn't modify the terrain in any way, similar to the blocker. Reasoning behind between Disarmer and Bomber: It gives a lemming a movement ability, like permanent skills do; but unlike them it is not permanent so shouldn't be in the middle.

Yeah, I should probably start on the whole skill reordering business soon. I have a few free days this week, so chances are decent that I might finally find some time for it.

Quote from: Strato Incendus on May 15, 2019, 01:32:46 PM
Another thing I've noticed: When a Shimmier gets towards a piece of terrain that is slightly higher than the position of his feet, he performs the Hoister animation (like a Climber does when he's done), without actually being a Climber.

I actually find this pretty neat - I just wanted to ask whether it was intended or not? It seems to be the Shimmier equivalent of the "six-pixel jumps" that Walkers can perform.

I also don't see any other way to do this, because the core rules say that every 1-pixel gap should be enough for a lemming to slip through. And since transitioning from a Climber into a Shimmier is possible, but not from a Shimmier into a Climber, the Shimmier needs to gain some height automatically when shimmying towards a platform that lies lower than the ceiling he's holding on to (=i.e. there is a gap he can slip into), but higher than the position of his feet.

Yes, this is totally intended. It was the only decent-looking way (I found) to transition from shimmier to a walker on a high ledge.

Quote from: namida on May 13, 2019, 10:32:27 PM

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.

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.

Quote from: namida on May 13, 2019, 10:32:27 PM

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.

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)?

Quote from: namida on May 13, 2019, 10:32:27 PM

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.

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.
As such I really approve your most recent changes. But I would go even farther:
- 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.
- Remove gatcLeft and gatcRight: For hatches, left-facing only occurs when flipping the hatch, which (hopefully) flips the secondary animations as well. So the only use-case would be splitters with a direction-dependant animation. But then I really wonder whether we need to introduce two keywords just for this use-case? I would prefer omitting them for the first version with secondary animations and see whether there is actual demand for it.

Quote from: namida on May 13, 2019, 10:32:27 PM
A post earlier in the topic, 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.

Quote from: namida on May 13, 2019, 10:32:27 PM

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.

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.

Quote from: namida on May 13, 2019, 10:32:27 PM

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!

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.

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.

Quote from: namida on May 13, 2019, 10:32:27 PM
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.

Quote from: namida on May 13, 2019, 10:32:27 PM
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!
And with your latest changes we go a good way in the direction towards "simple enough for me to understand".

Quote from: Simon on May 14, 2019, 11:08:12 AM

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.

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.

---

Finally one note regarding nine-slicing: I tried today to implement native editor-support for it and it worked pretty smoothly. For this feature I am happy to say: It is so simple, that even I can understand it! I just have one minor suggestion: Rename the keywords from "CUT_LEFT" to "NINE_SLICE_LEFT" (and similar for the other directions). The current naming suggests (at least to me) some kind of cropping, i.e. we cut away some part of the piece.