Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Nepster

Pages: 1 [2] 3 4 ... 125
16
[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:
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.
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.
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?
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...)
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 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:
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)...

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

Quote
So 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.
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.
If this take on secondary animations vs. nine-slicing is somewhat correct, could we please split the discussions (and feature branches)? I think I would have appreciated nine-slicing a lot more, if you had it introduced it in a thread "Nine-slicing: Resizable objects with nice edges" instead of here in "Secondary animations for triggered objects". 

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 see reasons for both: The second one is more flexible, but it's easy to forget to add the nine-slicing parameters although one probably always wants to have 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.

18
The editor actually tries to get the current monitor resolution and read the user settings (like the zoom factor) from the player settings, so that it can set the screen start rectangle to exactly the size you will see on your current computer. Only if this fails, the editor reverts to the standard 320x160.
This looks like there is still some bug in the algorithm, so that it falls back to the default. Will have a look.

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


20
Fixed for the next release

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

22
Closed / Re: [SUG][PLAYER] Multiple user profiles.
« on: May 04, 2019, 12:01:27 PM »

23
Closed / Re: [SUG][PLAYER] Multiple user profiles.
« on: May 04, 2019, 07:25:21 AM »
In principle this is a good idea, but I have a few problems with the details (or perhaps I just misunderstood some points):
1) It's totally fine to ask for a username input the very first time NeoLemmix starts (similar to how we ask for high/low-res settings and hotkey layout). However I think it will be annoying if this pops up any other time, except on explicit user input that asks for this. In other words: We should copy the way Lix handles this.
2) Similarly, I would like the automatic selection of the previously used profile (even if it may just be the guest profile) to be the standard setting. Actually I would even pose the question: Do we even need a settings option to disable automatic profile selection?
3) The guest profile (rename this to "default" perhaps?) should still save all the data. I totally expect lots of users to consistently play on this profile, because they are the only ones playing on their computer. At least if the amount of people using Windows under the default admin account is any indication... :P
4) Regarding the "save progression for each user" feature: Could we save the profile name to all the replay files. When running a replay (whether manually loaded or in mass replay check mode), we can then check for the profile name match to determine whether to save the progress. There was already a feature request in that regard, but I deemed it too much work for too little gain. But with already coded user profiles, it should be reasonable fast to add (at least a non-perfect solution that just works in 99% of all cases and possibly fails on edge cases like loaded and slightly modified replays).
Edit: Oh, you already found the other feature request and posted there. Didn't see that previously :-[
5) Regarding testplay mode: This could become annoying if it behaves differently than usual gameplay regarding profiles (especially as the hotkeys and settings are profile-specific). I would rather use the usual automatic profile selection, but completely disable saving the progression. Or am I missing other reasons not to use the main account for playtesting own new levels from the editor?

24
For sake of completeness: During the early days of the new formats, there have been several additions to the orig_pillar coming from the L2 classic tileset. IIRC these were mainly diagonal/triangular wood pieces. They have been created by möbius, added by myself and should stay as they extend this style nicely and fit pretty well.

The six pieces Proxima listed were proposed by möbius and added by myself, too (except for the marble teleporter, for which namida Proxima is responsible). I still deem them useful and fitting additions to the styles, so they should stay as well (unless someone can think of good reasons otherwise).

PS: I am curious about a list of the removed pieces, too.

Edit: Attributed marble teleporter correctly now.

25
NeoLemmix Levels / Re: Ski Sloping Lemmings (80 Levels)
« on: April 09, 2019, 05:23:43 PM »
Ok, I finally solved 4-19, too. While the solution is very nice, I feel that you really should give players a bit more leeway in placing their skills.
Spoiler (click to show/hide)

26
NeoLemmix Levels / Re: Ski Sloping Lemmings (80 Levels)
« on: April 04, 2019, 03:56:15 PM »
Thanks for the reply.

Quote
A journey level was completed nicely, you let one die.
Which NeoLemmix version do you use? When I load my replay, it saves all lemmings.

27
NeoLemmix Levels / Re: Ski Sloping Lemmings (80 Levels)
« on: April 03, 2019, 08:04:08 PM »
Attached are lots of replays.

Spoiler (click to show/hide)

28
Closed / Re: opening old levels
« on: March 18, 2019, 05:25:55 PM »
If you are talking about the levels from the old vanilla Lemmix database, then I do have them all converted into the newest nxlv-format. I just haven't released them yet, because only half of them are tested and I am constantly forgetting about them :(. It it helps, I can attach them. Just be warned that a lot of them still need some adjustments.

29
Closed / Re: [BUG][CONTENT] nx_sketches style is missing
« on: March 11, 2019, 06:35:30 PM »
I did a brief search through the code and I don't think NeoLemmix currently supports sketch objects. There is a type "DOM_SKETCH" internally, but it is never used anywhere. And neither can the editor write sketch pieces to .nxlv level files, nor can NeoLemmix read them in.

So I suggest renaming this thread to something like "[SUG][EDITOR] Add sketch pieces".
Regarding the workload: This wouldn't be too bad if such pieces aren't stored in the nxlv-files, meaning no persistence at all. It they should be persistent over saving and reloading a level, we would have to extend the nxlv-format, which is somewhat more work.

30
Yes, this F12 is a special hotkey on the main menu. I wasn't aware of it either :lem-shocked:. And your suspicion is pretty much spot-on: We set up the images for all the layers, just never draw the terrain and background onto them, because we trust the preview screen to have done so (because it has to do it anyway...).
I would be in favor of removing this functionality: Given that the screen loading time is now much faster than in the elder days, there shouldn't be any reason to keep it any longer.

Pages: 1 [2] 3 4 ... 125