Features for a Community Edition

[WillLem]

Progress update

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

[IchoTolot]

Comments:

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

Add "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.

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

Add 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!

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

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

Change 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]

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

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

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? 

[WillLem]

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!

Yes, agreed. I've updated the list.

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

Of course!

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

Could you mabe directly attach the soundfiles?

Done, see the features post.

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

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

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

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

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.

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.

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? 

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]

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.

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.

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

[Armani]

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.

Yeah. That sounds fair enough. Thanks for clarifying it and your works on CE

[WillLem]

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

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

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.

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.

There'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]

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

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

[WillLem]

"use the default style Sleeper sprite to fill the gap"

This

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

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