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 - namida

Pages: 1 [2] 3 4 ... 609
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.

I proposed this earlier: Remove "DISARMED" (which I think is what you're thinking of here - "DISABLED" has a much larger scope, though does include such a situation), and expand the definition of "EXHAUSTED" to include such traps instead. As far as I can tell, with no changes to "DISABLED" (ie: a single-use trap fulfills this condition when either used-up or disarmed), anything possible with the "DISARMED" keyword (fulfilled by a single use trap when disarmed, but not when used-up) is also possible with the proposed expansion of the "EXHAUSTED" keyword (fulfilled by a single use trap when used-up, but not when disarmed) - any such setup using the current keywords (which can be changed without BC concerns, as they don't yet exist outside of experimentals and experimental features are never guaranteed), reverse the order of the DISABLED and DISARMED conditions, then replace DISABLED with EXHAUSTED, and DISARMED with DISABLED.

Some changes to be aware of on other object types:
- "DISABLED" and "DISARMED" are currently identical for infinite-use traps. However, I feel "EXHAUSTED" should never be true for these (thus, disarmed infinite-use traps can only be detected via the DISABLED condition).
- I feel it would make sense for "EXHAUSTED" to be true on a pickup skill that's been used. I have no particularly strong preference either way as to whether "DISABLED" also remains true for such; it's currently that way because no other rule allows detecting a used-up pickup skill, and DISABLED's general rule fits better than any other rule does. (Although maybe based on the "general rule" argument, DISABLED should remain true as well for pickup skills that are used up.)
- Same logic as pickup skills, also goes for unlock buttons.

The changes described in this post are not yet implemented; just proposals.

The custom lemmings for those styles are not included in the NL download.

Are they actual sprites from L2 (with additions for the NL-specific skills, of course) - or at least close to their color scheme - or are they just "here's some lemming sprites that work well with that style"? If it's the former, I suggest we look at integrating them into the NL download. Otherwise, they should be made part of a custom style (at which point they could, in that form, be added to the download). I can say now that I do not want custom lemming sprites for my styles, so the Machine ones would need to be added to a custom style if they're to make it in.

We have six sets of lemmings sprites in the default styles download:
- default
- xmas
- plom_halayangube
- plom_festiveshangtu
- arty_underwater
- arty_silhouette

Of these, "default" and "xmas" have Shimmier sprites (I've just done the latter), the other four do not. Arty's styles' sprites appear to just be recolors of the default sprites, but plom's look like they'll need a bit more work.

As per Nepster's suggestion earlier in the topic (or maybe in PM?), "INITIAL_FRAME RANDOM" is now valid and recognized input. A negative number will also have the effect of a random initial frame, but let's encourage use of "INITIAL_FRAME RANDOM" rather than "INITIAL_FRAME -1".

Additionally, I have removed the support for recognizing the older "PREVIEW_FRAME" and "RANDOM_START_FRAME". Why? Because (unless they're used by some very recent - as in last few weeks - addition to the styles download) the former hasn't been used at all, and the latter is only used in a handful of my own styles - which I can easily make sure are up to date, and already have done so in the repo. Very possibly because the style convertor didn't handle them properly, and their existance was never really drawn attention to.

The earlier post detailing the system has been updated to reflect:
a) $PRIMARY_ANIMATION should be used in all cases, and define-in-main-segment should be treated as deprecated (previously, it was suggested that for now $PRIMARY_ANIMATION should only be used if use of an unsupported-in-main-segment new feature was desired)
b) Change of "CUT_xxxx" to "NINE_SLICE_xxxx"
c) Removal of "PREVIEW_FRAME" and "RANDOM_START_FRAME" in the backwards-compatibility code
d) Removal of the "LEFT" and "RIGHT" conditions
e) Addition of "INITIAL_FRAME RANDOM" as recognized (previously, no special keyword, but a negative number would have the same effect - negative number still works, because it'd be extra effort to make it not work, but advise against using it as "RANDOM" is clearer)
f) "HIDE" specified without a corresponding STATE, will set the state to PAUSE (previously STOP)

In terms of what the editor needs to know to account for these:
a) Nothing, for now. The editor still needs to, for now, be able to understand either format.
b) Keyword change
c) The editor can remove the code (if any) for handling these two keywords
d) The editor can remove the code (if any) for handling these two conditions
e) The editor should recognize "INITIAL_FRAME RANDOM" and treat it as equivalent to a negative INITIAL_FRAME, however the editor handles those (player-side, a random frame is chosen, but editor side a rule like "always frame 0" might make more sense)
f) Nothing. HIDE + PAUSE and HIDE + STOP are equivalent as far as the editor needs to account for (there are subtle differences player-side - when the animation becomes visible again, it'll be on frame 0 in the case of HIDE + STOP, but on whatever frame it was on before disappearing (or the initial frame, if it's never animated or been STOP'd yet) in the case of HIDE + PAUSE).

Site Discussion / Re: Planned site downtime.
« on: May 19, 2019, 08:53:39 pm »
Email issue should be fixed now. The git repo had my old personal email address configured as the FROM for emails; I updated it to my up-to-date one. However - it should actually be coming from some kind of (the domain being the critical part) email address, to work with the SMTP provider we're using (SparkPost).

I've fixed this now.

In regards to logging in issues, I haven't had any issues with that (unless he means that he needed to activate his account or reset his password, and wasn't receiving the email, therefore couldn't log in). I quickly popped onto IRC, but it seems he isn't online now.

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.

1. Alright. Let's have a solid plan for when it will be removed altogether - maybe something like "whichever comes last, 2 further major version updates, or the first major version update after 6 months from now". Not sure re: use of graphic set tool, I know the majority of users don't use it but I don't know if it goes as far as "no one does". Latest version has 431 downloads, but (a) this is over a whole year, (b) a lot of that likely comes from webcrawlers, (c) if the installer downloads it via a link, that will be included in these counts, and (d) downloaded != uses.
2. Yep, this makes sense. We should have a "Information regarding V12.05.00 for style creators" topic, separate from the release topic, and stickied. As well as drawing attention to this change, it can also explain the new features, including best practices for using them.
3. I'm a bit reluctant to change anything we don't need to right away. It would be preferable that - at least for a little while - the styles download remains physics-compatible with older versions, as well as as graphically compatible as can be achieved without either (a) being detrimental to the new version in any way, or (b) using ugly hacks, like having both info in main segment and a $PRIMARY_ANIMATION. Perhaps wait until a V12.5.1 update to do this.

In regards to actually converting styles, it should be possible to make a command line tool that automates this. As explained in a post earlier in the topic, NeoLemmix handles data in the main segment of the file, by internally translating it to a $PRIMARY_ANIMATION segment - this isn't a metaphor, it's literally what NeoLemmix does. Doing this, removing the old lines, and writing the result to a file, would be a sufficient tool. The only case it wouldn't cover is objects that use the MASK feature, and as far as I know, this was only ever default:pickup and default:owa_XXXX - easy enough to handle these two manually, plus the mask side of things is already updated in the repo.

Again I point out that many games nowadays features so-called hotkeys and no buttons. Pressing keys without any kind of visual button the screen is very common.

Most games nowdays also have gameplay not even remotely comparable to Lemmings. Probably the closest would be RTS games; I'm not familiar with the super-modern ones, but I recall every game in the Age of Empires series would have on-screen buttons for everything - albeit with some of the more advanced features hidden if you don't enable an "advanced mode".

another idea on 'removing' a button is to place the release rate change function up to overtop of entrances (this is how Revolution worked--you left or right clicked the entrances and the number appeared temporarily above it). That would free up one more space.

This might give the impression that each entrance's release rate can be adjusted independently.

I just took a look at what the compact panel looks like - I haven't used it in so long, that I didn't remember off-hand. I know the DOS L1 skill panel (which is also 320px wide) would have room for two more skills, by removing some of the filler between the panels and the minimap / to the right of the minimap - but NL's compact panel has made use of this space for a fast forward button and an increase to the minimap width.

Perhaps this can be reversed - shrink the minimap a tiny bit and remove the fast-forward button. This makes room for two more skills on the compact panel. On the full-size panel, we've got 8 utility buttons that aren't stacked - Pause, Nuke, Fast Forward, Restart, Framestep Back, Framestep Forward, Clear Physics, and Load Replay. (We also have two buttons for directional select, but these are stacked.) Maybe we can stack some of these - I would definitely be okay with stacking the framestep ones in the same way as the directional select. Maybe Fast Forward and Restart can also be stacked - and then, viola, we've got room for two more skills. Perhaps we could stack even more aggressively, to also give a slightly wider minimap - I think this is more beneficial than these buttons being full-height.

As per discussions me and Nepster have had in PM, the keywords "CUT_LEFT" etc are changed to "NINE_SLICE_LEFT" etc. They still work exactly the same; just the keyword itself is changed.

As per the discussions in this topic, the "LEFT" and "RIGHT" conditions have (for now) been removed. If a use case where these are needed arises, please bring it up, and we can consider re-adding them.

Bugs & Suggestions / Re: [Sug.] [Player] Remember last played pack
« on: May 17, 2019, 08:27:07 pm »
It wouldn't be too much extra work to implement a feature that allows shortcuts to a specific pack. On a technical level - the shortcut would just need to include command line arguments something like "-pack [name of pack's folder]". NeoLemmix can probably even be made to generate these shortcuts, perhaps a "Create shortcut to this pack" button in the level select menu that creates such a shortcut in NeoLemmix's folder, and you can then copy / move that shortcut to wherever you like.

In regards to increasing the panel's width - when the current-standard (ie: non-compact, with the extra feature buttons and the larger minimap) panel was introduced, some users complained it appeared too small on their screen, because there wasn't room to zoom it further. Let's consider - on common resolutions, can we add 16px (the width of one button) to each skill panel type, without forcing a lower level of zoom? What about 32px?

To start off with, some details to be aware of:
- I am assuming full-screen here. If anyone has any particularly specific setups using a windowed display that they're concerned about, please mention this so they can be taken into account.
- NeoLemmix is DPI-unaware. This means that, for example, if your display resolution is 1920x1080, but you have Windows scaling set to 150%, NeoLemmix thinks it's running on a 1280x720 resolution display (with the upscaling from that performed by the OS, not by NeoLemmix). I will account for (a) the most common cases, (b) cases that I personally use, or (c) cases that anyone else mentions they personally use.
- When unzoomed, the standard skill panel is 416px wide.
- When unzoomed, the compact skill panel is 320px wide.
- Both skill panels are 40px tall. Irrelevant here, but mentioning for completeness's sake.
- These widths include the minimap, and the height includes the information text above the actual skills. In terms of NeoLemmix's internal workings, this entire area is the skill panel, and is rendered / zoomed as one large area.

Again - please let me know if you use a resolution or zoom factor not covered here, so it can be taken into account to decide whether widening is feasible.

Resolutions overview (click to show/hide)

Overall - the compact panel gets hit much harder by this than the standard one, going against the whole reason it was implemented. This alone might be grounds not to do this for the compact panel (as there's no rule saying we can't eg. increase the with on the standard one, while shrinking the minimap or shrinking the pause / nuke buttons on the compact panel).

The standard panel on the other hand is only affected, out of the common cases, at a (perceived) resolution that's 1280px wide; or at resolutions where NL won't run well anyway. But 1280px wide is one of the most common, possibly even the most common, resolution widths, so it definitely needs to be considered...

In such a case, you wouldn't need to display the scroll buttons unless there's 9 or more skills - indeed, I would say we shouldn't display them unless there's 9 or more; this way more attention is drawn to that there's extra ones to scroll to.

But overall, page-flipping is essentially just a variation of scrolling, which seems very unpopular as an approach to deal with this. If we do increase the limit, it's most likely going to be one of the following ways:
a) Shrink the minimap
b) Increase the total width of the skill panel
c) Remove or shrink some of the existing buttons

There is of course a limit on how many extra skills we can squeeze in with this - 9 total is definitely doable, 10 should be possible, if we want more than that we'd probably have to use a combination of those approaches. But this is okay - the strongest preference seems to be for just a slight increase.

I would definitely say - regardless of decisions (other than a decision of "don't change anything", which seems extremely unlikely), we should approach this in a way that, the behind-the-scenes code can handle unlimited skill types, and only the UI limits things. This way, it'll make things easier if there's ever a decision in the future to accomodate an even higher limit.

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.

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. However, for now, use of the main section was preserved for backwards (and to some extent, forwards) compatibility. This is why I didn't bother to code full support for all of the new options, but instead just popped in code that translates in-memory the main section lines to a $PRIMARY_ANIMATION segment.

Had this been a new engine being made from scratch, with no worries of existing content or what existing users are familiar with, it would be only $PRIMARY_ANIMATION (or $ANIMATION with PRIMARY keyword - one or the other, not "either one is valid") for sure.

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.

Thinking a bit more clearly now - if the primary is defined in the main segment, there'll be some duplication either way, unless we literally just parse the main section twice - once as a main NXMO section, and once as an $ANIMATION section would be, keeping in mind this also means we need to make sure there's never keyword overlap between the two. At best, this would consist of the same translation code currently used to turn this into a $PRIMARY_ANIMATION segment (which can be loaded as a normal animation, just with a few things overridden / ignored), just without the option of using such a segment directly - and in turn, without the option of ever deprecating it.

This way, adds a small bit of extra work now, in exchange for - once this feature's stable and been around a good amount of time - being able to deprecate the main-segment way further down the track more cleanly.

Good point, but so far it worked pretty well to use the same name for the .nxmo file and the main animation .png file.

Yeah, this is probably the simplest way if we go with main-section-only - just add NAME to the fields prohibited on the primary. I would like to keep the "if no name is specified, the main PNG file is used" capability on secondaries though, as two secondaries with the same graphic (and thus, a primary and a secondary with the same graphic) is allowed, and at any rate prohibiting this would be trivial to bypass (by creating a second copy of the PNG file with a different name). Of course this shouldn't be used on things like exits, traps, etc, but it might be useful for decorative objects.

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?

I'm not quite getting what part of this doesn't make sense, so I'll try to cover everything. Also because this way, I'm thinking through it again myself.

The primary animation, in this system, is equivalent to the only animation under the old system. As such - it is tied to physics. Physics control which frame it's on, and which frame it's on can affect physics.
Could this be changed, so that the primary animation is just like any other? It's not impossible. But let's take for example, a DOM_TRAP. The frame count of the primary animation affects physics - if it has 20 frames, it can't kill another lemming for 20 physics updates. But if it has 10, it can kill another lemming 10 physics updates later. Also, the primary animation remains stopped until the trap is triggered, at which point it animates once. We do have "LOOP_TO_ZERO", but this will do nothing if set while the animation is already on frame zero; its purpose is to allow the animation to complete gracefully (then not repeat), rather than abruptly terminate, when we want the animation to stop. Thus, some kind of "RUN_ONCE" state (which presumably, advances the frame to 1 then changes to LOOP_TO_ZERO) - which would also need extra code to differentiate between eg. "the trap is still triggered" vs "the trap has been triggered again" - would have to be introduced. The object would still need to define how many physics updates the object is triggered for anyway. To me, it sounds like this would just complicate things.

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.
Could this be changed, to only one or the other? Changing it to the sub-segment only would require modifying all existing NXMO files, and break forwards / backwards compatibility completely (by comparison, under the current experimental, new objects using the main segment are backwards compatible physics-wise though might look weird, while old objects are 100% forwards-compatible). On the other hand, changing it to the main segment only - that's feasible, yeah. Maybe that makes more sense than having the A or B options. 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). 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.

Or is it, the primary animation shouldn't need to be explicitly defined?
For this, I'd assume the rule is that either the first or last $ANIMATION, becomes the primary one. If so - this works only if we keep Z_INDEX, otherwise it's not possible to choose whether secondaries are drawn above or below the primary. This is a feasible - if maybe a bit counter-intuitive - approach if Z_INDEX is kept.

Bugs & Suggestions / Re: [Sug.] [Player] Remember last played pack
« on: May 17, 2019, 10:50:36 am »
I know this might be more difficult now that levels aren't complete pack files anymore, but maybe it is possible to point the game to one specific level folder right at the start?

Would Proxima's request alone be enough to satisfy what you want here, ie: if you were playing SEBLems last time you were in NeoLemmix, it'll be on SEBLems next time you start? Or would you like a way you could eg. have a shortcut you click that opens Lemmings Plus I, another shortcut for Lemmings Reunion, etc?

Bugs & Suggestions / Re: [Sug.] [Player] Remember last played pack
« on: May 17, 2019, 04:48:31 am »
I could've sworn I replied to this. Maybe it got lost during the upgrade. Anyway, this should be easy enough to implement and it's a good idea, so I'll look into it next time I'm working on NL code.

Site Discussion / Re: Planned site downtime.
« on: May 17, 2019, 03:25:37 am »
Ran into a few more difficulties than expected, but ultimately, the upgrade was a success and we're now on SMF 2.0.15. Additionally, we now have automatic regular backups in place - prior to now, we've relied on myself or Nessy manually making backups, which neither of us have been particularly reliable at doing. That's changed now - it's all automated, backups will occur once per month. This will occur on the 1st of the month at around 6AM UTC; the forums and may be slightly laggy around this time (probably for about 5 minutes at most). As has always been the case, the backups are accessible to all administrators and global moderators, and are hosted off-site.

As always when any updates to the site occur, please let us know if you encounter any issues.

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