möbius: Thanks for pitching in with demand for this. ;-)

QuoteI think the best solution to this problem is to simply have the selection priority invert button work with not only walkers

Your idea works for mass-assigning floaters to fallers.

But a dense bunch of walkers couldn't be mass-assigned like that, because they don't stop walking after the assignment. Mass-assigning climbers to walkers is maybe more common, and would exhibit the same interaction with select-only-X.

With the current priority code, select-only-walkers or priority-invert alone can't solve the underlying problem.

I'm biased from having implemented my own solution, priorityForNewAc(). The code may be ugly, but the resulting behavior feels good.

Quote from: namidaHowever, a rule of "ignore lemmings the skill cannot be assigned to" may work as a fairly logical starting point.

Yeah.

-- Simon

Have 10 lems densely packed. We want to assign floaters to all of them. Select floater. a) Hover with the mouse over the bunch, and click 10 times. Alternatively, b) hold select-only-walkers, and click 10 times on the bunch.

Expected: 10 floater assignments to 10 different lems.

Observed instead: 1 assignment, both in a) and b). The game seems to prioritize the existing floater for further assignments.

-- Simon

Status: Changes have been made to prioritization algorithm, see this post. Topic remains open so how to improve it further (if nessecary) can be discussed.

No problem, do as you wish. Since 1.37, there is no urgency here anymore.

-- Simon

Huge improvement. I'm not raging anymore about forgetting the preview stats during play.

People have been asking about the rescue blink. The negative sign of the flag's number moves the digits further to the right, away from the flag, closer to the unrelated time icon.

Inspired me to draw this. Could omit the minus sign, and, after winninng, draw this winner's cup instead of the flag.

No problem adding bells and whistles to winning, you might even flash the number a couple times. It stroke me as odd to have an option for such a minor visual detail, because it lost its original purpose, notifying about the win.

-- Simon

The bug in Natural Step is fixed, cool. The music builds up with much variety, without clashes now.

Crystallized Comfort: Yep, awesome track! No matter how long you're stuck on a level, don't be overwhelmed, and it's gonna be all right.

<Proxima> the new music is awesome :)
<Proxima> hmm, it ends too abruptly though, maybe hold the last note a bit longer
<SimonN> yeah, listening to it again now
<Proxima> it has a nice "easy" feeling to it, it wouldn't irritate me if it was playing for a long time on a level I was stuck on
<SimonN> right, it's calm and doesn't discourage you from a serious attempt
<SimonN> I believe I know what NaOH describes as too piercing an instrument and recommends a calmer instrument for
<SimonN> without her comment, I wouldn't have noticed it, but there is something to it
<Proxima> hmm, which?
<SimonN> the trumpets at 2:25 and again at 2:27
<SimonN> it's a matter of taste, I can see why they might be perceived as too intrusive
<Proxima> hmm, maybe, I didn't have a problem with them

-- Simon

1) Icho and I aren't sure.

In NL, you cannot walk-turn any of these: climber, floater, glider, detrapper disarmer. So: Not walk-turning swimmers would be consistent with all other performers of permanent abilities. Are turnable swimmers more intuitive? Icho isn't sure: Even though it breaks consistency with other permanents, turning as a swimmer in real-life is very much possible.

Assigning walker to a swimming swimmer turns the swimmer in L3, and costs a swimming tool. It's never used in L3 level design. I'd have expected the walker to act like in L3, but I'm biased from knowing L3 since childhood.

2) If it bombs, it should destroy terrain. Icho and I agree on this with you.

-- Simon

Hnn, remove.

Consistency is valuable. You focus almost exclusively on puzzle solving than on execution and trial-error, and offer error-correcting control features. Timed bombers make things hard solely by execution. If Geofflems is the only pack affected, you can ask the autor for his reason -- may well be "I figured that timed is the standard."

You will lose minor mechanics: A few levels have relied on can't-bomb-during-fall-from-hatch without knowing it, and needed straightforward backroute fixes. Can't set the timer on a lem, then have him become zombie, then have him bomb amongst a zombie horde.

Yeah, people were happy in Lix, no timed skills in singleplayer. This again was inspired by NL having untimed, and recognizing that as a good idea.

-- Simon

An exciting release, congratulations.

I've played the introduction pack for the first time. The more informative skillbar finally obviates the trip back to the preview screen, to read about initial lems and save requirement.

-- Simon

Previous discussion in now-locked NL 2 topic: More responsive "frame + 1 sec backwards". The problem has been explained pretty thoroughly.

tl;dr: To go back in time, NL restarts the level and recomputes from the very beginnig. This is comparatively slow, even on a reasonably fast Windows machine. There are algorithms to improve performance.

Low-performance framestepping feels more appropriately labelled as bug than suggestion. People refrain from using framestepping for correcting larger distances. Framestepping back and forth frivolously adds to the game experience, lowers the cost of experiments during play, therefore unfolds the feature's potential fully.

Let's not sweep under the rug that NL's framestepping was the inspiration to make the feature in Lix. People became very happy once it was in.

More existing discussion:

• IRC #lix, 2016-01-13, around 16:24 UTC, between namida and me.
• Framestepping, improve performance on large steps, a github issue for D Lix. I've put in details, but this was mainly a note to myself. You (namida) have developed the basic idea yourself already; if the github issue remains unclear, ask for clarification.

-- Simon

Status: Changes to the framestepping / state saving and loading have been implemented that should greatly improve performance; change is included in V1.39n-B update.

All this sounds like there should be much better level selection UI in general. Selecting levels with cursor keys, and waiting for them to render fully, can be tedious. Next/same level  might always be accessible from the results, etc.

This would finally render the level code entry obsolete.

Appropriate and good UI here is very costly and elaborate to make. Hackjob solutions like the cheat key might be interesting intermediate solutions.

-- Simon

Update from IRC yesterday. "VSI" == variable spawn interval, either per level, or as a game feature to allow it. In case it's unclear which of the two is meant, ask.

Visibility: In a level with VSI, VSI should become more visible/pronounced in the user interface. Right now, VSI doesn't look like an important feature, but sometimes, it is critically important. This is a mismatch.

Announce rare time limit: I would like to have a big, flashy warning on starting a singleplayer level with time limit. No-time-limit is the norm, but time limits occur often enough to become very annoying if unnoticed.

Announce rare VSI: If level designers allow VSI only where it's required or probably helpful, VSI levels should get a similar warning, or really obvious UI support for VSI. I believe this is unnatural, but namida wouldn't find it that strange.

Make pack work with/without VSI: I see Nepster's suggestion as an improvement over the status quo: If it's easy to design a level without requiring VSI, then make it solvable with the default SI. Most levels in the community pack can be easily adapted. The solution isn't always runners, it's often much simpler.

No replacement: Spawn interval cannot be replaced 1-to-1 with skills. There is no equivalent.  Runners replace only one use case, and have their own drawbacks. 1-to-1 translation to skills would mean skills like "stall faller/walker that has just come from the hatch", which introduce extra mechanics that, like VSI, clash with the game design of "every interaction is a skill, you get to choose almost freely to whom to assign".

Trampolines: Neither Proxima nor I like these too much, they behave strangely and defy intuition. They fit better into the game than VSI, because they're purely reactive to lixes, not introducing new player-lix interaction. I'd be neutral or moderately happy to remove them. They're used in 2 lemforum levels, 2 Clam levels, 3 Rubix levels. In multiplayer, trampolines haven't spiced up levels, only made stupid levels more stupid. But that would be material for a new thread.

Still pro-fixed-SI: I continue to believe that culling SI is a bit healthier than Nepster's suggestion. We offer anti-frustration by high-performance framestepping and by deprecating unnecessary pixel precision. Yes, level design would change slightly, because VSI is not the easy route out of designing clustering anymore. Finding the appropriate SI becomes a job of the level designer instead of the player.

-- Simon

Digger cancelling: Would like to discuss this in IRC with you sometime, in case any similar problem comes up with with pneumatic-hammer digging.

-- Simon

Level title instead of filename: Sensible suggestion, will keep in mind. Level title is what people associate with a level most.

File ordering would be mixed up; but the custom-order file (_order.X.txt in a level dir) does the same. Level title instead of filename makes it slightly harder for automated matching (level -> list of replays for this level). I believe I shouldn't rely on the filename for this matching anyway. This kind of database operation, if it's wanted later, can get an appropriate solution once time comes.

Level title can depend on language chosen by the player. Setting several titles is loosely deprecated, except for tutorial levels.

The alternative is to rename Rubix's levels in the main release, and use an odering file. Rubix has made his pack before the ordering file became a feature, and needed to cook up his own solution.

(Ideally, both levels and replays should be handled with a content-addressable filesystem >_>)

-- Simon