Secondary animations for triggered objects: Experimental version available

Started by namida, May 02, 2019, 09:24:27 PM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

mobius

I have a few artistic suggestions, and I'm willing to attempt the changes myself if that's okay but I won't  promise atm that I can.

Imo the flashing lights look a bit weird. Instead for the;
-pillar chain trap I suggest something like the top part turning or the chain swaying.
-marble trap; the top and/or bottom part could bob up and down like the icicle trap
-same for the brick squasher trap. Or since this one doesn't stick out as well; have some nob or needle thing bob up from below similar to the marble trap.
-pillar needle traps; the needles could protrude back and forth just a little bit.
everything by me: https://www.lemmingsforums.net/index.php?topic=5982.msg96035#msg96035

"Not knowing how near the truth is, we seek it far away."
-Hakuin Ekaku

"I have seen a heap of trouble in my life, and most of it has never come to pass" - Mark Twain


namida

Whatever ideas you want to put forward, do keep in mind - it needs to be an animation that animates when the trap is idle; and stops, disappears or noticably changes when the trap is disabled. (Optionally, it can also stop, change or disappear when the trap is busy.) The stop / disappear can be "upon reaching frame 0", rather than instant.

This isn't because NL requires this as such, but rather because the whole point of using these is to more clearly show (a) that a trap is an interactive object of some kind, hence the animation when idle; and (b) that a trap is disabled, by some appearance that's different from the idle appearance.

As long as suggestions / proposals meet that criteria, I'm happy to consider them - and I'm also happy to help with actually making them work, as I can see how this system could be a bit intimidating at first (though it honestly is pretty simple once you get the hang of it).
My projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)

IchoTolot

I would advice to only rely on the flashing lights when nothing else really works.

They look alright on the bear trap, but on the other ones they look very odd.

I agree with mobius proposals here (for the brick stomper a bobbing up and down I would say would be enough if executed right). The stopping of rotations/vibrations I would say is enough of a sign that a trap is disabled. And the killing animation + trap sound is enough to show that these traps are indeed busy.

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.

As a result of more and more animations that will trickle in I guess the "styles" download will need frequent updates during the time after this becomes stable.


I will most likely tackle the L2/L3 objects one at a time once this becomes stable --> adding more animations slowly as time progresses, but I still would be thankful for helping hands. I won't make a time-consuming marathon to get these out as quickly as possible.

namida

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

Since these have zero effect on physics, I prefer a different approach: Make something that does the job; if something really good comes along, we can replace it later. Indeed, I might have done a few of these differently if I waited until the feature was in its current state - when I did the L1 ones (as opposed to ONML, which I did later), NL didn't support things like "hide the secondary animation when the object is triggered", so eg. a bobbing up and down wouldn't've been possible to make look good. But indeed, I'm open to accepting better ones if anyone's willing to make them - and as I've said, I'm quite happy to help with the "making it work" side of things.
My projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)

namida

Uploaded an experimental version update, commit 8b2a634. The biggest change is a bugfix, fixing a bug which caused flipped / inverted / rotated objects to disappear (at best) or crash NeoLemmix (at worst) for most object types. That aside, it includes a slight fix to the Brick style's wheel trap.
My projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)

namida

Uploaded a new experimental, commit 8e435a5. Fixes a minor bug (where "HIDE" as the default state for an object didn't work, unless the default animation state was also specified and wasn't "PLAY" or "MATCH_PRIMARY"). The new experimental also includes secondary animations for all traps and locked exits in Lemmings Plus and Doomsday Lemmings styles.
My projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)

namida

Uploaded a new experimental, commit 17cd97c. Aside from a few improvements / fixes here and there (and a few more secondary animations in my styles), it also contains an experimental editor version, EXP A397DAF. This editor version handles secondary animations, sort of - it gets NeoLemmix to render the composite image of the object. This does mean a bit of lag while loading styles (and possible black screen flashes - that's just NeoLemmix running very briefly). There's room to improve here - and some of that room-to-improve is already implemented on the NeoLemmix player side - but that's lower priority than just getting it working in general.

Please be warned - this experimental editor also includes Shimmier support; but the secondary anims experimental player does NOT have support for the shimmier. So the shimmier not working in this experimental is not a bug.

If you're trying out this experimental, please in particular report any instance in which an object with secondary animations - in particular, one with secondary animations that are outside the object's original boundaries - loads or saves in the editor at an incorrect position. So far, I haven't found any cases in which there's problems, but the potential is there due to how it's implemented so it's something I'd especially like anyone testing this to look out for.
My projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)

namida

For the purpose of improving the load times - one thing I could do is not have NeoLemmix regenerate the images every time the editor runs, but rather, the editor keeps a saved copy of them.

However, this means that either (a) the editor needs to detect if the object has been changed; or (b) the user needs to manually delete the cached copy if the object changes.

The editor could try to detect changes by looking at modified dates of files. Checking this for the primary animation's PNG file and the metainfo file, which are the only parts that could affect physics, is easy enough. Checking for modifications to secondary animation graphics would be a bit trickier. So my thought here is - if changes to the NXMO file or primary animation PNG file are detected, regenerate the image. Otherwise, assume the cached copy is good. A content creator who wishes to force regeneration could either delete the cached copy, or just load and re-save (thus changing the modified date) the files. How does this sound?

That aside, NeoLemmix also has support for being asked to render multiple objects in a single run. Making the editor make use of this would hugely improve load times, it's just a fair bit of work - but I intend to try and do this.
My projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)

namida

Known bug in experimental (occurs in the editor, but I think it's the game's fault): If loading a level that uses pieces that rely on NeoLemmix rendering them, in a style that has not yet been loaded into memory, NeoLemmix gives a few error messages then hangs while trying to render, which in turn causes the editor to hang until either it or NeoLemmix is terminated.

Workaround: Before loading a level, switch to its style in the piece selector and display the objects. This loads them into memory, after which you should be able to load the level without issues.
My projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)

namida

Uploaded yet another experimental. This one actually performs pretty well now editor-side. Instead of requesting pieces on-demand from NeoLemmix, the first time the editor runs, it asks NeoLemmix to pre-render all pieces that have secondary animations or recoloring on the primary animations. These get saved in an "editor" folder, and next time the editor runs, it just loads them directly from there.

Obviously, this means changes to the pieces won't be reflected. One option is to delete the "editor" folder (or more precisely, the "render" subfolder inside it), at which point the editor will request a new render of all pieces next time it runs. Advanced users can also make NeoLemmix produce these renders via command line arguments:
Render all styles:        NeoLemmix.exe render -editor
Render specific style(s): NeoLemmix.exe render -editor [style 1] [style 2] [style 3] ...


So for the most part, the editor will display objects with secondary animations visible. There are some limitations:
- Displaying secondary animations is currently not supported on pickup skill objects
- Displaying secondary animations is currently not supported on one-way arrow objects
- Displaying secondary animations is not supported (and likely will never be supported) on resizable objects where the primary animation is nine-sliced
- Displaying secondary animations may be inaccurate for resizable objects, especially if the boundaries of the primary and secondary animations differ or the secondary animations are nine-sliced

Still, I think this is well and truly good enough for real-world usage. There's still likely a few bugs to iron out (I already know of one; trigger areas are inaccurate for objects with secondary animations that extend outside the primary's bounds), but I'm quite happy with the loading / displaying in general.
My projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)

Nepster

Sorry for being so late to the party, but I just now realized, how complex the system became. When I first read about this, it looked a lot easier...

What did we need?
Mainly idling animations for traps and idling animations for locked exits.

What of all the new features are actually needed for this?
- Secondary animation sprites as png
- One animation group within the nxmo file
- Attributes "NAME", "FRAMES", "OFFSET_X" and "OFFSET_Y" and possibly the definitions when to start/stop the animation

So what is not needed?
- I really see no need for nine-slicing
- Why do we want to have multiple secondary animations?

Finally: Why do I care?
1) I want to keep it as simple as possible. We culled so much to make NeoLemmix simpler to use and now we have dozens of options to define animations, that I currently don't understand. Sorry, but it's bad enough (though necessary) to have the .nxmo files, so they should at least be as easy to write and understand as possible. And this means having only the most important options.
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!
The experimental editor version released by namida has this dependency, which goes explicitely against my wishes for the editor, as mentioned to him by PM.

How to move forward?
Let us take a step back and discuss, which of the new features we actually do need, and let's not add the others (or rather let them live in an unreleased git branch). I really hope that we can find a simpler solution and that the editor itself can determine how a gadget should look like.
PS: As I thought the secondary animations were implemented in a much simpler way and wasn't aware of namida's work until now, I added a purely editor-based solution (basically overlapping the first animation frames of the main animation and the secondary one (if available))

mobius

I agree with Nepster that things should be kept as simple as possible so they can be finished quickly and done in a neat matter and not become too convoluted.

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

-I don't care if multiple secondary animations are implemented. One idle animation per trap seems enough for me. Again, I'm only saying this because I'd rather see more work go into other features which is just a personal wish of mine.
But the 3 different states as they are seems pretty good to me: idle, working, disarmed. (disarmed having no animation). When things are more uniform they are easier to understand.

-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?
everything by me: https://www.lemmingsforums.net/index.php?topic=5982.msg96035#msg96035

"Not knowing how near the truth is, we seek it far away."
-Hakuin Ekaku

"I have seen a heap of trouble in my life, and most of it has never come to pass" - Mark Twain


Nepster

Quote from: mobius on May 12, 2019, 05:22:08 PM
-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.

Quote from: mobius on May 12, 2019, 05:22:08 PM
-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) With more dependencies, you would have to ensure that compatible versions are installed. Currently you can use the editor with practically any new-formats NeoLemmix player. It is bad enough that current/older versions of the editor will no longer display objects as nicely as they currently do, but we don't have to make this situation even worse.
3) Finally, it is indeed some kind of abstract principle. But it's there for good reasons: At work we have multiple applications that communicate and work together - and our support now has lists about "which version works with which other version", because our customers regularly have problems running the system and it always has to do with some communication failure between the applications. That's why I really don't want to have even more inter-application communication than necessary - it creates more problems (that are extremely hard to debug!) than it solves.


namida

Quote2) 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!

Latest experimental from post 1 (and latest source code in my repo) has a fallback for this - if NeoLemmix isn't present, it won't make the request, and will simply display only the primary animation of the object. It does this as a one-time thing on first run (and later runs, if the "editor/render" folder has been deleted by the user), not on a regular basis - you could even copy these files from another NeoLemmix install, and get the benefits of player-rendered pieces, without needing a copy of the player to be present.

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

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 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.
My projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)

namida

The experimental editor in the exp version has been updated. The update contains a couple of bug fixes:
- Trigger areas displayed are incorrect for rotated objects, if the object is resizable in only one direction (unrelated to this feature, but no reason not to pull the fix into it)
- Trigger areas displayed are incorrect for player-rendered objects, if the object's secondary animation extends outside the primary animation's boundaries
- Nine-sliced objects are not sliced correctly if flipped / inverted / rotated, unless the slicing is symmetrical.

Nepster has written code which, as an alternative to my get-NeoLemmix-to-render code, attempts to display the first frame of the secondary animation ("the" because his code only supports one single secondary animation). I intend to (but haven't yet) integrate this into this experimental, so that we have both features - it'll get NeoLemmix to produce a good render if available, and if NeoLemmix isn't present or the specific object's render isn't there, it'll use Nepster's system as a better fallback than the primary animation alone. Not sure what the best way is to handle determining which secondary to show if there's more than one, this might have to be specifically stated in the NXMO file in the case of more than one secondary animation.

EDIT: I've also updated the exp copy of the player. Of particular interest, as Nepster feels the Shimmier is more or less ready to go for the next stable version, I see no reason not to include Shimmier support in this experimental. As such, the latest secondary-anims experimental now also includes Shimmier support. If upgrading from a previous secondary-anims experimental, make sure to re-extract the "default" style, as the pickup skill graphic has been updated to include the Shimmier, and it also includes necessary graphics for the panel and lemming sprites.

SECOND EDIT: I've integrated Nepster's secondary anim loading code as a fallback when no pre-render of the piece exists. This could occur if the piece was created (or had a secondary animation added) more recently than when the editor requested a build of the animations, or if NeoLemmix isn't present or is a version that doesn't support rendering. (Todo: Make the editor not even request the render in this latter case. It already doesn't attempt to request a render if NeoLemmix is not present.)
My projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)