Roadmap for CE 1.0

Started by WillLem, January 21, 2025, 01:51:12 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

WillLem

Upcoming Features for CE 1.0

It's probably a good idea to make a start with CE soon. The very first edition will feature only "gimmes" that users are likely to either benefit from, or not notice.

Just in case my idea of a "gimme" differs from yours, here's a full list what I intend to implement for NeoLemmix CE 1.0. It seems like a lot, but the features are all relatively small and easy to implement, so they're the best ones for starters. I'll take my time with it and regularly post progress updates to keep everyone in the loop and offer plenty of opportunity for feedback.

I've added the Clamoji ( :8(): ) to the topics I think might be somewhat controversial at this early stage, and will give extra time for feedback before adding these. And of course, anything without the Clamoji is also still open for discussion and feedback.

Features already implemented in CE will be marked with a Gold Talisman ( :tal-gold: ), and those currently in progress or not yet started will be marked with a Walker lemming ( :lemming: ).

Please note: This will likely take several weeks. You have plenty of time to give feedback, and it WILL be taken into account if provided. If any issues are raised regarding any feature, that feature will not go ahead until any discussion around it is resolved. On the other hand, your silence will have to be interpreted as "go ahead" so that CE can be moved forward.

Please also note: Where possible (and not otherwise noted), anything that is optional will be set to the current NL status quo by default.

Lemming States

:tal-gold: Sleeper lemming state - this state is entered when time runs out and the lemming reaches the exit. It's a mostly aesthetic state to replace the buggy-looking cluster of exiting lems, but it's also useful for simulating exit behaviour as these lems cannot be assigned to, and are deducted from the lemming count

Options Menu

:tal-gold: Add option to deactivate helper overlays - reducing UI clutter should always be possible, helps to onboard newbies.

:tal-gold: Add option to set the number of skill queue frames - 0 is essentially "off", 15 is the default (status quo), up to a maximum of 20.

:tal-gold: Add more auto-naming options for Replay files and widen the dropdowns for easier reading

:tal-gold: Re-word 'Don't Replay After Backwards Frameskips' as 'Replay After Backwards Frameskips' and check it by default (every effort will be made to preserve current user option, but it may need to be re-set following this change)

:tal-gold: Add option to Replay after Restart (or not) -  a frequently requested feature which might become unnecessary again in a future update (if we can improve Replay UI)

:tal-gold: Add option to load either the Next Unsolved Level, or the Last Active Level (current behaviour)

:tal-gold: Hotkey Config - Add 'Restore' (restores previously saved layout), 'Cancel' (discards changes), 'Save & Close' and 'Clear All Keys' buttons

:tal-gold: Hotkey Config - Add text label (rather than a popup) to let users know when 'Find Key' is listening for a keypress

:tal-gold: Hotkey Config - (Bugfix) Allow typing "-" into the Time Skip text input without resetting the cursor

Replay Features

:tal-gold: Updates to Replay Editor:
* Add ability to double-click a replay event to jump to that frame
* Add ability to delete all future assignments for a particular lemming (from the currently-selected event onwards)

Level Select Menu

:tal-gold: Upgrade keyboard compatibility; allow arrow-key-browsing to load each level preview, load the selected level into the player by pressing [Enter]

:tal-gold: Add "Reset Talismans" button, so players can reset their talisman progress on a per-level basis (very handy for level testing, and when re-playing an already-completed pack)

:tal-gold: Add "Level Search" capability

:tal-gold: Add "Edit Level" button - opens the currently-selected level in the Editor

:tal-gold: Increase width of, and text size in, Level Select treeview

Other Updates & Bugfixes

:tal-gold: Fix cursor zoom bug

:tal-gold: Always show total number of lemmings under cursor regardless of priority/type (i.e. zombie, neutral)

:tal-gold: Display level title and save requirement info in Window Caption (also display "Mass Replay Check" when in MRC mode)

:tal-gold: Fade In Menu screens (in addition to Fade Out) to make between-screen transitions smoother

:tal-gold: Upgrade keyboard compatibility of all menus/dialogs; they'll respond to [Esc] by closing, etc.

:tal-gold: Lemmings shrug and "OK" sound is played when a level is cheated (this is just for fun!)

:tal-gold: Add placeholder Menu graphics & layout to differentiate NeoLemmix "CE" from regular NeoLemmix - Please note: the current updated graphics are placeholders so that CE 1.0 is immediately visually different from NL 12.14. A topic will be made for updating the main menu in due course, where we can discuss gfx, layout, etc in more depth, to be applied in a future update.

:tal-gold: Update welcome screen with pictures, etc (further updates may be made to the Welcome Screen in the future)

Editor Updates

:tal-gold: The SLX Editor (a more advanced version of the NL Editor) will be included with CE. It has an option to set the controls to "NeoLemmix Mode" so that it can be used seamlessly with NeoLemmix, and offers new features such as Piece Search, Custom Hotkeys, Grid Lines for Snap-to-Grid mode, and more.

Current ETA for NL-CE 1.0-RC is End of Jan 2025.

WillLem

#1
Progress update

Features marked with a Gold Talisman ( :tal-gold: ) are fully implemented and ready for release.

IchoTolot

Comments:

QuoteRe-word 'Don't Replay After Backwards Frameskips' as 'Replay After Backwards Frameskips' and uncheck it by default (every effort will be made to preserve current user option, but it may need to be re-set following this change)

The current standard should be 'Don't Replay After Backwards Frameskips' turned off as I recall. So this should be a change of standard as I understand it.

The standard option then should always be 'Replay After Backwards Frameskips'. If the player skips backwards, it is really bad that the standard is then to not save their inputs in a replay. Player input should not be deleted by accident!
Imaginge you discover Backwards Frameskip by accident and then all your progress is lost. That would be a great source of rage.

QuoteAdd "Reset Talismans" button, so players can reset their talisman progress on a per-level basis. Very handy for level testing, and when replaying an already-completed pack!

This should come with an "Are you sure?" promt.


QuoteAdd an "Assign Fail" sound; this plays whenever a skill assignment is attempted, and fails

1st: I think this should also be able to be turned off. Especially in levels where I might needs to spam the skills a bit it could get on someones nerves. Also when you want to precisely place blockers as close together as possible you might run into a ton of extra sounds here as well.

2nd: When skill queuing is on and I assign a skill that can be queued and excuted in a few frames - does it count as failed in that moment? As then it should not count as failed.

QuoteAdd sounds for Jumpers and Laserers - Jumper sound is the one from L2, see SLX for Laserer sound

Could you mabe directly attach the soundfiles?

Also I don't think those should have extra sounds. If you need to spam these in a level it can really get on your nerves!
Currently skill sounds are very limited (bombers,stoners and the disarmer) and I think that is a good thing.

The most controversial thing I see here: Don't overload the player with 1000 sounds! Be it the skill panel or the skills themselves!

QuoteAdd pitch-shifted sound to Skill buttons (modelled on Amiga/Lemmini) - this could also be made optional if people dislike it

100% optional please and it being turned off as standard.


QuoteAdd pitch-shifted sound to RR/SI -/+ buttons (modelled on Amiga/Lemmini) - this can be toggled off in options if players prefer silent RR buttons - this will be "not silent" by default

I have no problem with SLX going the noisy route, but I think here the standard should again be silence.


QuoteChange cursor to Red when in normal Replay mode, and Blue when in Replay Insert mode - another visually very noticeable one, but necessary for adding clarity to these modes. Could be made optional if people dislike it, or the cursors themselves could be redesigned (e.g. with scissor icon, etc).

I am in favor here, but you might need to test this as the red and especially blue could be hard to see against some tilesets - so choose the colors with care. A total redisign would need to be tested first.

Simon

#3
Quote:8(): 'Replay After Backwards Frameskips' and uncheck it by default

Like Icho, I recommend to check it by default.

The default should be that rewinding preserves the assignments, and that you must cut the replay explicitly to erase the assignments. The newbie confusion doesn't come from this default; NL confuses the newbies because NL doesn't tell them how to cut the replay. You'll fix this confusion elsewhere.

Quoteevery effort will be made to preserve current user option, but it may need to be re-set following this change

Right. It's nice to heed the user's old setting when you reword the boolean option to positive. If you can't heed that, it's okay to fall back to this option's default on first run. The default will be that rewinding keeps the replay, which matches most people's settings.

Anyway, I'm happy that you brought this up in the first place. UI is important and negatively-worded checkboxes are surprisingly confusing.

-- Simon

Armani

I'd love to see everything in the level select menu. 8-)

Animate Replay "R" icon: I don't want an animation on that one. I don't mind it being clickable though.

Add an "Assign Fail" sound, Add pitch-shifted sound to RR/SI -/+ buttons: please no. I can see them being annoying very often. If Assign Fail sound doesn't apply to queuing skill as ichotolot said, it would be better but still it's redundant.

Will there be a RC version? I'm having a hard time imagining what it will look like after some of these features are implemented.
e.g. deactivating helper overlays, mouseover hints to all skill panel buttons

I remember you said you are going to implement a feature only if more than certain % of the people agree and 75% should be the absolute minimum in a poll. Is that still valid?  ???
My newest NeoLemmix level pack: Holiday Lemmings 2024 8-)
Xmas themed collaboration pack with Mobiethian :D

My other NeoLemmix level packs(in chronological order):
  Lemmings Uncharted
  Xmas Lemmings 2021
  Lemmings Halloween 2023

WillLem

#5
Quote from: IchoTolot on January 21, 2025, 05:04:19 PMThe standard option then should always be 'Replay After Backwards Frameskips'. If the player skips backwards, it is really bad that the standard is then to not save their inputs in a replay. Player input should not be deleted by accident!

Yes, agreed. I've updated the list.

Quote from: IchoTolot on January 21, 2025, 05:04:19 PMThis should come with an "Are you sure?" promt.

Of course!

Quote from: IchoTolot on January 21, 2025, 05:04:19 PMRe: Assign Fail Sound
...
1st: I think this should also be able to be turned off
...
2nd: When skill queuing is on and I assign a skill that can be queued and excuted in a few frames - does it count as failed in that moment? As then it should not count as failed.

It can be optional for sure.

Regarding skill queueing, that's a very good point. It's likely that the queueing logic can be harnessed and applied to the assign fail sound. Now investigating; downgraded the completion status of this feature to Silver.

Quote from: IchoTolot on January 21, 2025, 05:04:19 PMCould you mabe directly attach the soundfiles?

Done, see the features post.

Quote from: IchoTolot on January 21, 2025, 05:04:19 PMThe most controversial thing I see here: Don't overload the player with 1000 sounds!#

Replied to this in its own topic. I think the sound scheme in general warrants this.

Quote from: IchoTolot on January 21, 2025, 05:04:19 PMRe: Cursor colours for Replay / Replay Insert:

I am in favor here, but you might need to test this as the red and especially blue could be hard to see against some tilesets - so choose the colors with care. A total redisign would need to be tested first.

We have plenty of time to test this out before we settle on a final version. We can even differentiate them with symbols as well (scissors, etc). For the first release, I'll implement them as they currently are and we can go from there.

Quote from: Simon on January 21, 2025, 06:20:42 PMI'm happy that you brought this up in the first place. UI is important and negatively-worded checkboxes are surprisingly confusing.

Yes, I'm having a look at the config menu and seeing if any other options can be reworded to "enable this" rather than "disable this". In some cases it might be more appropriate to keep the negative wording (e.g. Disable background images, where the "active" choice is probably to disable them).

Quote from: Armani on January 21, 2025, 06:43:35 PMAnimate Replay "R" icon: I don't want an animation on that one. I don't mind it being clickable though.

OK, let's make the animation optional for version 1.0, and switch it on by default; give it a try, turn it off if it's an issue. If feedback following 1.0 is that most people have turned the animation off, we can remove it. For this particular feature, I'd rather take that approach than just not implement it.

Also, this topic addresses your concerns regarding the sounds.

Quote from: Armani on January 21, 2025, 06:43:35 PMWill there be a RC version? I'm having a hard time imagining what it will look like after some of these features are implemented.

Yes, an RC is a good idea. It feels a bit less "official" and we can try some of this stuff out without worrying it will necessarily all go ahead into the final release.

The first release, then, will be 1.0-RC.

Quote from: Armani on January 21, 2025, 06:43:35 PMI remember you said you are going to implement a feature only if more than certain % of the people agree and 75% should be the absolute minimum in a poll. Is that still valid?  ???

Absolutely. In the event of a poll, we should set a minimum standard of 75% for "go ahead". Here's the process as I imagine it:

Uncontested features will go ahead as planned. If a feature gets enough (in this community, > 1) "no thanks" comments, I'll either remove the feature from the list or create a topic. We'll then discuss it, maybe try it out in an RC if appropriate, and then ultimately poll it to see what the consensus is. That seems to be the fairest way to proceed.

WillLem

EDIT: Fixed links in the previous message

namida

Quote from: WillLem on January 21, 2025, 01:51:12 PM:lemming: Sleeper lemming state - this state is entered when time runs out and the lemming reaches the exit. It's a mostly aesthetic state to replace the buggy-looking cluster of exiting lems, but it's also useful for simulating exit behaviour as these lems cannot be assigned to.
Make sure this plays nicely with custom lemming sprites, including those that have not been modified to account for it. EDIT: And also that the time might run out while lemmings are mid-exiting.

Quote from: WillLem on January 21, 2025, 01:51:12 PM:lemming: Add option to deactivate skill queuing - another one that should definitely be optional as it's input-related.
Keep in mind that the assignment windows for some skills have been set under the assumption that skill queueing exists, in particular, niche transitions to Shimmier. Even though it's technically UI, I would argue this one leans a bit too much into physics to be messing with.

Quote from: WillLem on January 21, 2025, 01:51:12 PM:lemming: Hotkey Config - Add Reset, Cancel and Save & Close buttons
There's already reset at least (or rather, three resets - one for each default layout option).
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)

Armani

QuoteUncontested features will go ahead as planned. If a feature gets enough (in this community, > 1) "no thanks" comments, I'll either remove the feature from the list or create a topic. We'll then discuss it, maybe try it out in an RC if appropriate, and then ultimately poll it to see what the consensus is. That seems to be the fairest way to proceed.

Yeah. That sounds fair enough. Thanks for clarifying it and your works on CE :D
My newest NeoLemmix level pack: Holiday Lemmings 2024 8-)
Xmas themed collaboration pack with Mobiethian :D

My other NeoLemmix level packs(in chronological order):
  Lemmings Uncharted
  Xmas Lemmings 2021
  Lemmings Halloween 2023

WillLem

#9
Quote from: namida on January 21, 2025, 08:36:46 PMMake sure this plays nicely with custom lemming sprites, including those that have not been modified to account for it.

As it happens, at least 5 of the custom sprite sets already have a Sleeper sprite in the SLX styles, so we could move those over.

Beyond this though, what would you suggest in terms of accounting for unmodified sets?

Quote from: namida on January 21, 2025, 08:36:46 PMAnd also that the time might run out while lemmings are mid-exiting.

This can be solved by allowing Exiting lems to transition to Sleeper; it was implemented in SLX for a very short time before I decided that any lem that has begun exiting should finish, and count towards the save req. Obviously that isn't an option for NL-CE, but transitioning a lem mid-exit-animation is still viable, and represents the actual result of that action in terms of save req.

Quote from: namida on January 21, 2025, 08:36:46 PMKeep in mind that the assignment windows for some skills have been set under the assumption that skill queueing exists, in particular, niche transitions to Shimmier. Even though it's technically UI, I would argue this one leans a bit too much into physics to be messing with.

This could be accounted for by specifically allowing Shimmier assignments to be queued. Saying that, I had a quick look and couldn't see anything specifically linking Shimmiers (i.e. as opposed to just any skill) to queued assignments. I'll have a closer look when I get around to this specific feature, but if you happen to know whereabouts it is in the meantime I definitely think this option is a worthwhile addition, given how aggressively it interprets user input.

Quote from: namida on January 21, 2025, 08:36:46 PMThere's already reset at least (or rather, three resets - one for each default layout option).

"Reset" in this context means "Reset to whatever layout was active when the config form was opened" as opposed to resetting to one of the preset layouts. It's for if users make changes but then change their mind; rather than having to cancel and then re-open, they can reset instead.

namida

Quote from: WillLem on January 21, 2025, 11:04:27 PMBeyond this though, what would you suggest in terms of accounting for unmodified sets?
I'm on the fence between "fall back on the frozen-exiter behavior" vs "use the default style Sleeper sprite to fill the gap". I don't think this is significant enough to implement an option for; just pick one or the other and go with it.

Quote from: WillLem on January 21, 2025, 11:04:27 PMThis could be accounted for by specifically allowing Shimmier assignments to be queued. Saying that, I had a quick look and couldn't see anything specifically linking Shimmiers to queued assigments. I'll have a closer look when I get around to this specific feature, but if you happen to know whereabouts it is in the meantime I definitely think this one is worthwhile, given how aggressively it interprets user input.
It's not that any special behavior is explicitly coded, but rather that there's a lot of scenarios where there is only a one frame window to assign a shimmier (eg. slider->shimmier transition), and skill queueing is relied on to make this practical - even with framestepping, it's not the most convenient assignment to make otherwise.
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)

WillLem

Quote from: namida on January 21, 2025, 11:08:31 PM"use the default style Sleeper sprite to fill the gap"

This :thumbsup:

Quote from: namida on January 21, 2025, 11:08:31 PMIt's not that any special behavior is explicitly coded, but rather that there's a lot of scenarios where there is only a one frame window to assign a shimmier (eg. slider->shimmier transition), and skill queueing is relied on to make this practical

I see. In that case it would be easy enough to pass Shimmier assignments through to the skill queue as an edge case; in fact, it's more or less necessary, for the very reason you've stated. In SLX I've added a "Dangler" state to increase assignability; it's mainly Slider > Shimmier that causes issues. Climbers are generally OK.

Maybe the option could be to set the number of frames a skill should be queued for on a 0-15 scale, as opposed to simply turning it on or off (still allowing for Shimmier assignments, that is).

WillLem

#12
Progress update

Changes to the config menu:

• Added option to deactivate helper overlays - this applies only to the overlays shown at the start of the level, and the pre-assigned hatch icons. CPM, fall distance ruler, lemming cap counts and all other UI helpers are still displayed.

• Added option to deactivate skill queuing (Shimmier assignments are queued regardless of setting).

• Added more auto-naming options (i.e. "Username + etc".) for Replay files and widened the dropdowns for easier reading.

• Re-worded 'Don't Replay After Backwards Frameskips' as 'Replay After Backwards Frameskips' and checked it by default. Any existing user option should be preserved; be sure to copy your settings over before starting NL-CE for this to work, otherwise just set it again (it's probably worth taking a fresh look at the config menu anyway tbh).

• Added option to Replay after Restart (or not) - if unchecked, the replay is cleared when restarting the level. It's also cleared when exiting the level and then re-loading it from preview/postview.

• Added option to load either the Next Unsolved Level, or the Last Active Level. The setting is observed (and therefore the relevant level is loaded) when the Main Menu screen is active; this is so it's still possible to browse through the level pack from the Preview screen.

Updated the features list to show what's completed.

WillLem

I'll likely re-work the list of features for 1.0 tomorrow (too tired to do it now). It's probably best to reduce it by about half, and release an RC sooner. That way, people have less new features to process. Less is more at this stage.

WillLem

#14
I've revised the features list. I was considering delaying the implementation of the sounds, but discussion seems to be fairly focused on that so it's probably worth going ahead with those.

To clarify once again: none of this is final. We'll test the features in an RC, keep the ones we like, change/remove the ones we don't.

Dullstar

Regarding skill queuing: if we're going to have a setting for it, maybe it should be for the number of frames to queue for rather than a binary yes/no.

WillLem

#16
Made some progress with the Level Select menu today. Everything completed so far is marked with the Gold Talisman ( :tal-gold: ) here.

Quote from: Dullstar on January 24, 2025, 12:12:34 AMRegarding skill queuing: if we're going to have a setting for it, maybe it should be for the number of frames to queue for rather than a binary yes/no.

Funnily enough, I had the same idea! Yes, we can try this for sure. EDIT: This is now implemented.

WillLem

Updated v1.0 features list - completed items are marked with a Gold Talisman ( :tal-gold: )

Could do with some feedback on Skill Panel, Replay Features and Sounds - these are still pending discussion prior to initial implementation.

A reminder that even if something has already been implemented at this stage, it can still be updated, revised or removed altogether following RC testing.

In some cases, it has simply been easier to implement several features at once due to the way they're intrinsically linked, which is why this initial version has a lot of features; most of them have been small and relatively easy to implement, so it's no problem to re-work them if needs be.

If we can reach some firm(ish) conclusions on the remaining list items, it may even be possible to get the RC ready within in the next week or so.

IchoTolot

#18
I have one more suggestion, but not regarding the overall feature list. It's more about speed and overview.

As more and more topics begin to seperate from this one, I slowly loose the overview about what the cureent state is.
Yes, implementation wise everything is listed in the first post, but that is not the point.
Also there can be a difference between the first post list and the actual implementation, but I want to get to the point.

The list is just very large! Also you need to keep track on more and more discussion topics to stay on top and I slowly start to notice fatique crawling up inside of me (we even just now had a new major update).
My time is limited and I want to do more than just keep track on the CE.

Maybe to descibe me viewpoint a bit more:
I am mostly about playing levels and level creation and not discussions about the engine (Simon would be way more into that  ;) ) - here I am mostly concerned that it functions as intended, properly and that new additions do not do more harm than good (here I count in the extra sounds for example).
I do not like posting in a lot of engine discussion topics, I rather play levels and create my own stuff. It is just that for that I have to rely on a stable engine that does not constantly grind my gears!

That is also something I noticed about the SLX dev cycle, but as I am not a SLX user I did not care there: Topics on topics and new developments to keep track on. While slowly feedback starts to dwindle - I noticed that at some point you asked about more feedback there, but to me it seemed like the sheer amount was too overwhelming.
At some point in the "Recent posts" section it was nearly just new SLX dev topics!

Here the topic has just really started now in January and it's already slowly moving to that direction.

Therefore my suggestion (with maybe an extention to SLX even  ;) ): Slowdown and for the first RC focus on 1 or 2 of the aspects, test those, wait for feedback, finalize them and then move to the next area. We are not in a rush!
Maybe just start with the "Options Menu" and "Level Select Menu" and after we are done with those move on to the "Replay Features".


This way people do not get overwhelmed by the sheer amount of features and we can properly implement and test them in a controled manner.
Otherwise they may just move to "why even bother?" and just stay with standard NL.

WillLem

@IchoTolot In the time it took you to compose that reply, you could have posted one or two sentences regarding the features! ;P

But OK, you're more concerned about how fast things are moving, so let's address that.

I can't really do much about my natural workflow speed. What I can do, however, is put CE lower down on my priority list so that I get around to it less; this will obviously help to temper the out-rolling of features. I could also take more frequent breaks during sessions (which is something I'm aiming to do anyway for health reasons).

Another thing that will slow it down is feedback and testing, which we haven't had a chance to get to yet. Let's see how the first RC pans out.

Quote from: IchoTolot on January 26, 2025, 01:36:04 PMAlso there can be a difference between the first post list and the actual implementation

Not so. I update the OP to reflect the subtle changes in implementation, perhaps following discussion, insight, or implementation itself.

The OP list will always be an accurate representation of exactly what's going on in CE; in fact, that's kind of the whole point of it.

I realise people might struggle to keep up with what's going on, so I keep that list as up-to-date as possible, thus providing a quick-glance progress overview. Please do use it that way! - especially if you're struggling to keep up.

Quote from: IchoTolot on January 26, 2025, 01:36:04 PMThe list is just very large!

I explained this in the post prior to yours: "In some cases, it has simply been easier to implement several features at once due to the way they're intrinsically linked, which is why this initial version has a lot of features".

Future versions will have less features. At present, I'm mainly migrating stuff over from SLX that has already been implemented, tested and regarded as an improvement by the few people that use it. So, there's a lot to get through.

I will rein it in a bit though! ;P

Quote from: IchoTolot on January 26, 2025, 01:36:04 PMSlowdown and for the first RC focus on 1 or 2 of the aspects, test those, wait for feedback, finalize them and then move to the next area. We are not in a rush!

OK, I suppose it wouldn't hurt to just go ahead with what's already implemented and leave the other stuff for next time.

We aren't in a rush, sure, but the counterpoint to this is that we waited for nearly 2 years for NL 12.13, at least in part because users are slow to give feedback (if at all); I don't want it to take so long to get CE up and running.

So, what we need is a compromise between feature rollout and feedback waiting time. I can see 3 possible ways forward with this:

:lemming: Option 1: We agree as a community on a development schedule, which I can then aim to stick to. I'd be happy to work to something that someone else draws up if that makes everyone feel a bit better about the rate of updates/progress, and then people know in advance how long they have to catch up with what's going on and provide the necessary feedback, should they wish to do so.

:lemming: Option 2: We agree as a community on a feature limit per-version, which again gives me something to aim for and helps to keep the new feature set less overwhelming with each version.

:lemming: Option 3: We agree as a community on feedback waiting time at the very least; I need to know how long I should wait before proceeding with anything.

We can also combine any of the above options.

Whatever we decide, waiting indefinitely is not an option for CE development; I'd rather abandon the project altogether than go ahead on that basis. Or, just put together my own version of NL and then make it publicly available for those that might want it. But, I don't really want to do it that way and I'm sure others wouldn't want that either; I think it would be much better to involve the community in development.

But, for that, the community needs to get involved! All I can do is post updates and hope people care enough to reply, the rest is up to everyone else!

Quote from: IchoTolot on January 26, 2025, 01:36:04 PMMaybe just start with the "Options Menu" and "Level Select Menu" and after we are done with those move on to the "Replay Features".[/b]

This way people do not get overwhelmed by the sheer amount of features and we can properly implement and test them in a controled manner.

OK, for the meantime, I'll take your advice. I'll prepare an RC release soon and leave the features that haven't yet been implemented until next time.

Simon

Right, release what you have. You have the zoom bugfix, you evaluate keypresses during level selection, ..., all that carries real value.

-- Simon

namida

Quote from: WillLem on January 26, 2025, 05:10:59 PMI can't really do much about my natural workflow speed. What I can do, however, is put CE lower down on my priority list so that I get around to it less; this will obviously help to temper the out-rolling of features. I could also take more frequent breaks during sessions (which is something I'm aiming to do anyway for health reasons).
You can also keep various developments in side branches, if you feel like working on them now, and then work towards rolling them out later. You could even consider making topics about them so people who do want to give the input can, while applying a unique tag to them (maybe something like [LONGTERM]) to indicate they're not under consideration for the immediate upcoming releases.
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)

WillLem

#22
Quote from: namida on January 26, 2025, 09:38:28 PMYou can also keep various developments in side branches

Yes, I could probably do with getting used to working with branches more regularly. SuperLemmix development is mostly one long branch, plus a recently-added branch with a feature I haven't managed to make much progress on.

For CE, though, branches is almost certainly a must.

Quote from: namida on January 26, 2025, 09:38:28 PMapplying a unique tag to them (maybe something like [LONGTERM]) to indicate they're not under consideration for the immediate upcoming releases.

This is a good idea. For now, I'll try to keep the topics to a minimum because I think that might be what's bothering some people, and I'll roll out groups of features that can be discussed in bunches, like with this topic.

Then, if something generates a fair bit of discussion, it can be broken out into its own topic with the [LONGTERM] tag if development on it needs to be delayed for any reason.

WillLem

Quote from: Simon on January 26, 2025, 05:34:30 PMRight, release what you have

Yes, let's do it! Here's the first RC build.

Also, let's agree on one (or a combination) of these going forward, to help steady the pace of CE development:

:lemming: Option 1: We agree as a community on a development schedule, which I can then aim to stick to. I'd be happy to work to something that someone else draws up if that makes everyone feel a bit better about the rate of updates/progress, and then people know in advance how long they have to catch up with what's going on and provide the necessary feedback, should they wish to do so.

:lemming: Option 2: We agree as a community on a feature limit per-version, which again gives me something to aim for and helps to keep the new feature set less overwhelming with each version.

:lemming: Option 3: We agree as a community on feedback waiting time at the very least; I need to know how long I should wait before proceeding with anything.

IchoTolot

I will probably test out the first RC version this weekend.

namida

Quote from: WillLem on January 27, 2025, 01:07:55 AM
Quote from: Simon on January 26, 2025, 05:34:30 PMRight, release what you have

Yes, let's do it! Here's the first RC build.

Also, let's agree on one (or a combination) of these going forward, to help steady the pace of CE development:

:lemming: Option 1: We agree as a community on a development schedule, which I can then aim to stick to. I'd be happy to work to something that someone else draws up if that makes everyone feel a bit better about the rate of updates/progress, and then people know in advance how long they have to catch up with what's going on and provide the necessary feedback, should they wish to do so.

:lemming: Option 2: We agree as a community on a feature limit per-version, which again gives me something to aim for and helps to keep the new feature set less overwhelming with each version.

:lemming: Option 3: We agree as a community on feedback waiting time at the very least; I need to know how long I should wait before proceeding with anything.

Option 3 should be considered regardless - at least in the form of a minimum expected timespan between RC and stable. You don't have to meet that timespan exactly; just no shorter than it. (In fact, it's probably a good idea to wait at least a couple of days longer. There's always people who leave it until the last minute.)

Option 1 isn't an awful idea, but will you stick to it? Will you have new features to justify each one? Of course, it could also be a minimum.

Option 2 is one I'd be cautious of. Certianly, consider one or two major ideas per release, but don't limit the minor stuff - I wouldn't consider counting something like "option to display the title screen panels in a single line" towards such a limit, for example. (I also wouldn't implement this option at all, but it came to mind as something that's reasonably fitting as an example here.) Rather than an arbitrary number limit, I'd suggest instead just going off feel - try to stick to just a small number of major things per update, with perhaps a few more minor ones.

If you aren't getting much feedback in the discussion topics, or if it's hard to explain / for people to understand, don't forget that experimental releases are an option too. Use these sparingly, of course, but they can be useful. (They also need not always be publicly released, for that matter. It may be worthwhile making a branch for them similar to the release / RC branches in NL's repo, so that anyone who really wants to can build it from source - and also so you can track down exactly what commit the experimental was based on if this becomes useful for investigating a bug.) There's also the option of going ahead with it in the RC and seeing how people respond to that. When all else fails, there is also always the option of revert it (or make it a setting) later.
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)

WillLem

#26
Quote from: namida on January 28, 2025, 07:38:25 AMOption 3 ... You don't have to meet that timespan exactly; just no shorter than it. (In fact, it's probably a good idea to wait at least a couple of days longer ... )

Yes, erring on the side of giving more time for people to respond is a given, whatever we decide.

Quote from: namida on January 28, 2025, 07:38:25 AMOption 1 isn't an awful idea, but will you stick to it?

I mean, I'll try my best to, of course! When it comes to deadlines, I'm always more likely to be working up to the last minute rather than having everything ready early. Not always, but usually.

Ironically then, having a deadline to work towards might actually slow me down! Any shrewd observers of SuperLemmix development will have noticed that I'm always putting my own self-imposed deadlines back, probably because I tend to make them quite unrealistic. With help from the community, we'd be more likely to come up with realistic and desirable deadlines which I can then aim for.

Quote from: namida on January 28, 2025, 07:38:25 AMOption 1 ... Will you have new features to justify each one?

Yes, I think that for at least the first few versions the problem will be having too many and needing to spread them out evenly. Once it comes to the point where all the features that can be migrated over from SLX have been implemented, it'll just be a case of responding to new suggestions and bugfixes, for which we likely won't need a specific schedule anyway (although I'd still be open to sticking to one if that's what people would prefer).

Quote from: namida on January 28, 2025, 07:38:25 AMOption 2 is one I'd be cautious of. Certianly, consider one or two major ideas per release, but don't limit the minor stuff

Yes, in all honesty I'd be less happy about Option 2 being chosen as the only way forward; it seems best when combined with one or both of the other options. It certainly makes sense to agree on some nice round number for the major features, as you've suggested (maybe no more than 3?), where minor features can be within some reasonable but not necessarily defined limit.

The only problem there is that I tend not to know what could be considered a "major" feature vs. a "minor" feature. From my point of view, something like SLX's Rewind button is a minor feature, but others may view is as a major feature due to its impact on the UI. Other features are more clear cut, like Playback Mode (obviously major) and displaying level info in the Window Caption (obviously minor), but I may need some guidance now and again if "major" features are slipping through the net as "minor" features.

Quote from: namida on January 28, 2025, 07:38:25 AMhere's also the option of going ahead with it in the RC and seeing how people respond to that. When all else fails, there is also always the option of revert it (or make it a setting) later.

Yes, I'm pretty sure that this is most likely what will end up happening most of the time, i.e. if feedback isn't forthcoming and/or I'd rather people test a feature before dismissing it (likely), it'll go to RC and then be removed later if it's polled out.

IchoTolot

A first test run of the player.  :)

Critical things:

- I managed to make the program not respond anymore and even after waiting for a few mins it did not solve the issue: I searched for a level - this took long and I wanted to cancel the search - So i simply pressed close on the level select menu. That did not go well!
Expected: Search gets interrupted and the window closes.

- The menu transtions are now really slow. It's like 100% more time for switching screens. Is it because of the  smoother transitions?

QuoteFade In Menu screens (in addition to Fade Out) to make between-screen transitions smoother

Yeah, either make them optional and off by default or throw them out. This really steals your time!

I liked:

- Sleeper lemming state

- The assignment failed sound is chosen quite good. I would not mind it, but miners and diggers on steel should make this exact sound as well and not the "hit steel" one. There the assignment fails as well, they do not hit steel! If so they would turn on top of that.

- The new level select screen.


I most kept to things that could bug me for the first test run. I did not test the editor or the new replay editor things so far.

WillLem

#28
Quote from: IchoTolot on February 02, 2025, 12:26:45 PM- I managed to make the program not respond anymore and even after waiting for a few mins it did not solve the issue: I searched for a level - this took long

I tested the Search feature with more than 9,000 levels in the levels folder and it takes about 20 seconds for the first search and up to 10 seconds for subsequent searches. Slow, but not that slow! ;P

Needless to say, it's much quicker with less levels in the folder. I'll see if I can do anything to make it quicker.

Yes, I've had it go unresponsive too. Larger level collections seem to be the cause, but I'm not exactly sure what's going wrong.

Quote from: IchoTolot on February 02, 2025, 12:26:45 PMI wanted to cancel the search - So i simply pressed close on the level select menu. That did not go well!
Expected: Search gets interrupted and the window closes.

Unable to replicate this one.

On my system, the cursor is hidden altogether during searches, so clicking "Close" isn't an option. I'll see if there's a way to keep the form active during searches; you're right, it should definitely be possible to cancel out of a search.

I found another bug with this as well: if a search returns no results, the results list isn't displayed at all, so it isn't possible to close out of the search feature and back to the main treeview; this will definitely be fixed in the next update.

Quote from: IchoTolot on February 02, 2025, 12:26:45 PM- The menu transtions are now really slow. It's like 100% more time for switching screens. Is it because of the  smoother transitions?

What you're probably seeing is that the Fade In/Out effect has been made deliberately slower than it is in regular NeoLemmix. A "screen fade time" option could sort that out, with 0 being instant, up to some reasonable maximum. Or a simple On/Off could suffice.

Quote from: IchoTolot on February 02, 2025, 12:26:45 PMminers and diggers on steel should make this exact sound as well and not the "hit steel" one. There the assignment fails as well, they do not hit steel! If so they would turn on top of that.

I see what you mean and I don't completely disagree.

I've replied here to keep it in its own topic, and just in case we need to poll it at some stage.

IchoTolot

I know it's not that slow, but I just saw the bar and thought "hmm can I cancel this?" and then fell right into the problem.  ;)

I replicated the unresponsiveness again:

I searched for a phrase (in my case "epitome" for the last United level) - search begins and then I clicked a couple of times on "close" in the bottom right corner -> NL does not respond anymore.

I can close during searches and I do have the cursor - I also want to keep it.  ;) 

I do think the ability to interrupt is a good thing.

WillLem

Quote from: IchoTolot on February 02, 2025, 07:32:55 PMI can close during searches

Ah OK. So it's only when the form has already gone unresponsive that you can't cancel the search?

I wonder how you're keeping the cursor and I'm not...? My cursor remains active, but appears behind the form. That points to it not being a program-side thing...

WillLem

#31
Fixed various bugs with the Level Search feature.

• Optimised search speed massively - instead of loading each and every node label and analyzing its text, we simply get the level title from the node data and then build a list of the matched nodes. It's gone from around 20 seconds for a search of 9000+ levels to more like 2 seconds! Initial search is now much faster even for large numbers of levels and search results, subsequent searches are near enough instantaneous.

• Choosing a level is also much snappier, as the logic there has also been optimised - we now only load the relevant branches of the tree to which the level belongs, and don't load any UI elements until absolutely needed.

• Added a call for the app to process messages periodically during search; this ensures UI responsiveness, keeps the cursor on top of the form, and allows interacting with the form even during the search process. Due to the search optimisation, it's not really necessary, but it should prevent the form from going unresponsive anyway.

• If no search results are found, the search results list is displayed anyway (with a "No results found" message) and the "Close" button is made visible so the user can return to the level treeview.

namida

...is the Close button not always there?
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)

WillLem

Quote from: namida on February 06, 2025, 08:32:56 PM...is the Close button not always there?

As in "Close Search". It appears when the search results are shown so it's pretty obvious it's for that purpose, but I could rename the button anyway.

namida

Quote from: WillLem on February 06, 2025, 08:41:46 PM
Quote from: namida on February 06, 2025, 08:32:56 PM...is the Close button not always there?

As in "Close Search". It appears when the search results are shown so it's pretty obvious it's for that purpose, but I could rename the button anyway.

You said that the close button is made visible if no results are found. I took this as meaning that if results are found, it wouldn't be there, which seems weird?
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)

WillLem

Quote from: namida on February 06, 2025, 10:11:01 PMYou said that the close button is made visible if no results are found. I took this as meaning that if results are found, it wouldn't be there, which seems weird?

Simple misunderstanding. In the current RC, when no results are found, results are not shown and neither is the "Close" button. So, it's then necessary to do a search which definitely will yield results in order to get the search results and button to show, so that it's then possible to return to treeview.

This bug is now fixed. The results and button are now always shown following a search, regardless of results count.

namida

It should be possible to close without performing a search at all too (eg if the user opens it via a misclick), if it isn't already.
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)

WillLem

Quote from: namida on Today at 03:47:06 AMIt should be possible to close without performing a search at all too (eg if the user opens it via a misclick), if it isn't already.

The only way to "open" it is to perform a search. If the search field is empty, nothing happens. And searches are now so fast that even if a user managed to type something by accident and then accidentally trigger the search it wouldn't be too much of an issue. I did put in a "Cancel Search" button at one point, I guess it could be put back for emergencies.