[DISCUSSION] [PLAYER] Let's discuss skill assignments.

[Proxima]

Re 1, my proposal was to no longer disallow assignment to jumpers in the first place. ie. if you click a jumper with Builder selected, he immediately starts building just like a walker would.

In mid-air? That just sounds really weird.

[namida]

He's not really midair, more on the side of a slope - essentially, the logic here is to think of the jumper as just an extension of the walker.

Here's an experimental version that implements this change:
https://www.dropbox.com/s/py0b8txofap3vip/NeoLemmix_V1.44n_1603101522.exe

(Note: When loading any NXP, you'll get a warning that it may be incompatible. As long as it doesn't use gimmicks, secret level triggers, or non-standard teleporters, you can ignore this warning.)

In this test version, Walker, Blocker, Platformer, Builder, Platformer, Stacker, Basher, Miner and Digger can be assigned to jumpers, provided all other conditions usually required to assign them are met.

So, let me know whether you think this change should be kept, or dropped.

[ccexplore]

Re 1, my proposal was to no longer disallow assignment to jumpers in the first place. ie. if you click a jumper with Builder selected, he immediately starts building just like a walker would.

Nepster mentioned downward slopes as well, for which jumpers are not applicable.

[IchoTolot]

I sense a big backroute potential in this experimental version. Through this skills can be assigned at new (not originally intended) heights.
But i cannot proof it without testing 1000 different scenarios for hours + having other testers run through it again. But beeing in the heat of of finding a solution to a level you will use this to fiddle sth out that works but is not intented for sure.
Also performing a task while mid jump still seems very weird und unlogical.

If this is dropped again it wouldn't be a huge miss either, because of already existing frame forwards/backwards.

[namida]

Re 1, my proposal was to no longer disallow assignment to jumpers in the first place. ie. if you click a jumper with Builder selected, he immediately starts building just like a walker would.

Nepster mentioned downward slopes as well, for which jumpers are not applicable.

That's a good point. Assignment to fallers is much more game-breaking than assignment to jumpers...

I sense a big backroute potential in this experimental version. Through this skills can be assigned at new (not originally intended) heights.
But i cannot proof it without testing 1000 different scenarios for hours + having other testers run through it again. But beeing in the heat of of finding a solution to a level you will use this to fiddle sth out that works but is not intented for sure.
Also performing a task while mid jump still seems very weird und unlogical.

If this is dropped again it wouldn't be a huge miss either, because of already existing frame forwards/backwards.

It's very much an experimental feature at this stage. If it's not liked - which it doesn't seem to be - I just drop the branch that has the code for it, and we never see skills assigned to jumpers again (except those which have always been possible to assign to jumpers - the permanent skills, plus Bomber and Stoner).

Are there many levels which rely on a jump to avoid a backroute? I can't think of many; I can think of more cases of the opposite to be honest (avoid jumps in order to avoid backroutes - usually via building against the terrain that would otherwise result in a jump).

[Nepster]

Re 1, my proposal was to no longer disallow assignment to jumpers in the first place. ie. if you click a jumper with Builder selected, he immediately starts building just like a walker would.

This is a very bad idea due to the reasons ccexplore (no improvement for downwards slopes) and IchoTolot (more backroutes) mentioned. Moreover allowing to start builders, platformers and especially stackers mid-jump has the potential for lots of incredibly annoying tricks/glitches (I can provide example levels if needed). I would rather keep the old handling than allowing to start skills at some intermediate height.

Perhaps I should have given more background on the reason, why I made this suggestion in the first place:
When already pausing, the frame advance options are already good enough so that further improvements are not really needed. But when I play an easy level where it doesn't really matter where I assign a basher/builder/whatever, I just want to assign the skill. Currently I have to pause the game for this (or hope to be lucky), which I find dissatisfactory. Even if there is no big slope, but only some bumpy terrain (grass in the Dirt style or on rocks in the Rock style) it sometimes happens that a skill doesn't get assigned, due to unlucky timing. When this happens during fast forward or when I press 10sec-skip directly afterwards (without double-checking the assignment), it is very annoying.
So I definitely don't want to add new positions where non-permanent skills can be started, but only ensure that those unlucky skill assignments will still be executed at the earliest moment, when such assignments are regularly allowed.

Assignment to fallers is much more game-breaking than assignment to jumpers...

That is the reason why I suggested to remember the skill assignment for a few frames until the lemming reaches again solid ground, where he can regularly start working.

2. Should the one-assignment-per-frame limitation be kept?

I would put removing this limitation as [LOW-PRIORITY]. While it would be nice to remove the problems with colliding assignments from player and replay, it is not really game-breaking. I cannot think of any (non-artificial) level, where changes here create new backroutes.

[namida]

Here's another question which a recent post raised: Miners on wrong one-ways.

Currently it is possible to assign a miner when they're standing on a wrong-direction one way wall. The result is that they take a swipe, remove no terrain, and turn around.

Compare this to the following cases (which themself may definitely be questioned too):
a) Basher vs wrong one-way. Depending on the exact positioning, the assignment may be disallowed.
b) Miner vs wrong one-way in front of him. This will generally disallow the assignment - including even if an already-mining lemming at the same position may be unaffected by it.
c) Miner standing on steel. This will disallow the assignment (on the other hand, steel in front of him does not, even if a one-way at the same position would).
d) Digger on top of steel. Once again, this prevents the assignment.

[Simon]

We've discussed this when Nepster was here.

Assignment prevention is extra complexity, my first hunch was always-allow. But I give in to Nepster's and Icho's recommendation to keep assignment prevention. Turning a lemming on steel should continue to cost more than one miner.

a) need to investigate
b) sounds inconsistent, but need to investigate
c-on-the-one-hand) good
c-on-the-other-hand) inconsistent
d) good

We'd like to treat wrong-faced OWWs exactly like steel. Make a dedicated function for steel and wrong-OWW checks, and re-route through this function all the manual reads from the special map within the assignment prevention and the skill performance.

Need to investigate: What skills cancel when touching steel (miner), what skills cancel when they would move into steel (maybe the digger?).

-- Simon

[namida]

Under current behaviour, the miner and the basher have multiple checks. Under the proposed new basher behaviour, well, you can see for yourself above.

The digger behaviour is - and always has been, even back in L1 - stop if either (a) there's a steel pixel immediately below the digger at any time (so the transition to walker happens immediately after digging out a row), or (b) the digger has nothing to cling on to. NeoLemmix only slightly adjusts the latter part, in that steel pixels don't count, nor does the outermost pixel on each side.

Using a common function to check for these is an excellent idea.

[IchoTolot]

Our logic here was simple:   Miner isn't allowed to assign on steel (a too easy turn around) ----> one-ways in wrong direction should be the same

So only one check for one-ways and steel nessecary.

[Nepster]

OK, here a proposal for a more radical change:
  Only allow assigning bashers, miners or diggers, if applying the terrain removal mask would remove at least one terrain pixel.

Please tell me, why this suggestion is an incredibly bad idea .

[IchoTolot]

OK, here a proposal for a more radical change:
  Only allow assigning bashers, miners or diggers, if applying the terrain removal mask would remove at least one terrain pixel.

Please tell me, why this suggestion is an incredibly bad idea .

This can be bad for backwards compability.

The basher swing is used sometimes for delaying (LP 1's "Lightspeed Lemming" comes to my mind) + appyling a basher a few frames before a wall so that it takes longer could be affected.
Furthermore it would prevent the usage of the basher most of the time in a level, which is very weird overall. So it would nearly be the only skill which can be only assigned in certain spots.
Also why is a basher that swings 1 time in mid air a bad thing?

[Simon]

I'd like to allow assignments that don't remove any earth.

New suggestion (One-Function): When trying to assign skill X, run X's terminate-due-to-steel function. If that function would abort the skill, disallow the assignment.

Definition of terminate-due-to-steel function: Right now, each skill X terminates on touching steel, or when falling, or when running out of material. Move X's steel checks into a separate function particular to X, so each destructive skill has its own function. That function runs whenever the lemming moves. Steel remains fixed in place, so it doesn't matter whether we run the terminate-due-to-steel every frame, or only after the lemming moves.

This simplifies the rules: One rule governs both assignment and termination.

-- Simon

[Proxima]

But that gets rid of the extremely common build-then-mine to turn around on steel....

[Simon]

Build-then-mine: Do you wait until the first step is built? With my proposed One-Function, you can mine, after building and stepping onto the first step.

Or can you assign miner to a builder standing on steel? That would be questionable behavior by itself.

-- Simon