[Discussion] Infinite chain between Slider<->Walker inside the digger pit

[Armani]

With precise timing and position, it's possible to set up an infinite cycle of slider <-> walker transition inside a digger pit.

When slider try to slide down the terrain, the digger dig away that terrain at the exact moment and the slider transit to walker instead of sliding down.

Quote from Discord

Armani - I think it's completely fair and indeed a neat trick. but i could also see some arguments that this isnt fair for the same reason as climber infinitely climbing inside the basher tunnel is banned.

kaywhyn - does this always happen? here, i notice that the slider goes at the exact moment when the digger digs away a pixel of terrain

Armani - only with some presise timing and precise digger position, it really have to be precise though

kaywhyn - ah, ok, yea that's what i wanted to know :stuck_out_tongue: so maybe if the digger didn't remove terrain at the exact moment the lemming starts sliding then this won't happen similar to the climber infinitely going in a basher/miner tunnel, like you said

namida - create a topic... this should get some wider discussion my gut feeling is that i don't like it, but i'm not sure how easy it would be to cleanly prevent it

[Dullstar]

It makes sense why this works, but it has the potential to create some irritatingly fiddly solutions as well as not being particularly intuitive.

[IchoTolot]

This just seems wrong to me.

It is a very similar to the case of a climber being stuck in a loop while another lemming is bashing/mining beside him. We purposely patched out that behavior in NL.

Therefore I think this should be patched out as well.

[Silken Healer]

Whilst I agree that it is a fair and neat trick (as armani said), I feel it should be patched out if the climber-basher loop was patched out. They feel like 2 sides of a coin and it would be unfair if one was patched out and one wasn't.

[Simon]

Looks like corollary of placing the slider's/climber's pin in the wall.

This is a powerful delay that is finnicky to trigger. I'd try to remove this even if the code becomes nasty.

-- Simon

[namida]

Looks like corollary of placing the slider's/climber's pin in the wall.

Not this time it's not. It's more an unfortunate coincidence of the exact range of terrain checks, and the exact timings of the dehoister and digger.

[WillLem]

I think it's completely fair and indeed a neat trick. but i could also see some arguments that this isnt fair for the same reason as climber infinitely climbing inside the basher tunnel is banned

It is a very similar to the case of a climber being stuck in a loop while another lemming is bashing/mining beside him. We purposely patched out that behavior in NL

Why?

I don't see how either of these behaviours is a problem tbh, because both are reasonable to expect and make physical sense based on how the skills work.

[Dullstar]

My (possibly wrong) interpretation of what's going on here:
- The slider walks of the edge, begins dehoisting.
- The digger clears a pixel of terrain.
- After dehoisting, the slider no longer has terrain, so it falls.

Observed result:
- The slider begins falling and lands on the edge of the digger pit.

Desired behavior:
- The slider should either keep sliding, or fall off the wall into whatever's below the wall (appears to be a death pit in the example). Ideally, this result should be consistent and not dependent on the exact timing with which the slider reaches the edge; I have a slight preference towards always allow the slide in this situation. If a digger can remove the terrain from the slider when timed correctly, however, then it should at least fall away from the wall and not into it. Sure, maybe internally the lemming is 1px into the wall, but the player shouldn't need to worry about this implementation detail.

[IchoTolot]

Why?

I don't see how either of these behaviours is a problem tbh, because both are reasonable to expect and make physical sense based on how the skills work.

Those behaviors were one of the most annoying things in Lemmini ! Why? Because it is barely controllable.

You can easily see why it happens, but the expectation when it happens is the catch and you usually do not want this to happen.

They are neat when a level purposely uses them and everything is set up so that the behavior is easy to trigger.

In all other cases (which are 99% of the time ) this happens by pure accident and it totally screws you over as you usually simply want lemmings to turn at the end of the tunnel! And you cannot simply plan this in as you would need to be able to guess the problematic intervals on which the climber arrives on sight alone.

And this is the point where we would go back to adding more execution difficulty which NL purposely wants to avoid as much as possible.

[WillLem]

If a digger can remove the terrain from the slider when timed correctly, however, then it should at least fall away from the wall and not into it

Hmm, this would kinda mess with the consistency of the Slider always being expected to face the wall after dehoisting.

Because of this, I agree that Sliding should be preferred, so +1 for that.

[Simon]

If a digger can remove the terrain from the slider when timed correctly, however, then it should at least fall away from the wall and not into it

Hmm, this would kinda mess with the consistency of the Slider always being expected to face the wall after dehoisting.

With "away from the wall", I believe that Dullstar means the lemming's x-position, not the facing direction.

Looks like corollary of placing the slider's/climber's pin in the wall.

And the positioning inside the wall prompted me to say this. But the positioning is not the source of the fidgety timing: The delay works only sometimes, depending on when exactly the slideable walker arrives at the edge that will be dug away. Usually, the lemming continues to slide.

namida is right that the fundamental timing issue doesn't arise from the positioning, and that instead the timing issue arises from the check for arriving at bottom of wall.

The positioning governs only the symptom of the bug, either premature falling (facing the wall) or the powerful walk/slide loop in OP's gif. I believe we want neither; we want the lemming to continue to slide.

-- Simon

[namida]

Yeah, I agree that continuing to slide is the right outcome.

The loop feels wrong, and I agree with the comparison to the climber-basher interaction that was specifically removed.

Falling 1px outside the wall is inconsistent with how the slider otherwise behaves when it runs out of terrain to slide down - it would fall in line with the wall, not 1px out from it.

Exactly what the rule should be to make it happen is another question - and one I'd need to take a much closer look at this (and the underlying code) again to figure out - but yeah, "continue sliding" feels right to me.

[Armani]

In climber-basher interaction we've been talking about, infinite loop was patched out but still the climber can climb inside the basher tunnel for one basher stroke with some good timing.
So if we decide to let the slider lemming continue sliding in OP's gif situation, will we allow to let him turn left one time so he can for example bash to the left in OP's gif situation?

[namida]

Commit 205cf95 implements a fix for this.

Specifically: When a lemming becomes a dehoister, the Y coordinate of the pixel he's standing on is remembered (note: we don't need to remember X, because his X coordinate is not going to change while dehoisting). Then, when doing the terrain checks, if the pixel at this Y coordinate has become nonsolid, the pixel below it is checked as well, and only if that one is also nonsolid, the fall routine is triggered. All terrain checks at other heights work as normal. To handle an edge case - if the dehoister is teleported, the Y coordinate is "forgotten" and terrain checks proceed as normal from that point onwards.

Leaving this topic open so the fix can be discussed. I'll likely get an RC with this up later today.

[namida]

I assume everyone's happy with the fix / hasn't found any bugs?