[bug?] blocker miner interaction

[mobius]

I noticed that the miner shadow displays a weird pattern and the pattern is correct; that is this is how the miner actually behaves. As a lemming draws closer to a blocker his mining path will turn when he gets close to the blocker; for just 1 frame, but if he advances for a couple more frames he doesn't turn, but keeps going, then a couple of frames further; he turns again. Is this intended? Seems odd.

see video to demonstrate: As said; I later actually mined and confirmed this is how it behaves.

https://www.youtube.com/watch?v=OeVqw3VPGpo&feature=youtu.be

[IchoTolot]

This should be because of the miner checks for steel/trigger areas. I don't know the exact code but here is my guess :

There is one check right above the ground tunnel shape where the miner checks normally for steel/trigger areas in the way right before the actual lem. This is your normal turn around.
And one check is right under the lemming to check if he is standing on steel or a trigger. ----> And here is your 1 pixel turn!   The lem gets turned around here, because of the check for the actual lem position.
The normal turn area is for the miner forwards check as you expected it.

Hope this explains it right and I am not totally wrong.

[ccexplore]

This doesn't feel like something we actually want, even if it falls out of how the checks are currently performed for the NL miner.  AFAIK it doesn't even happen like that in original Lemmings.

If IchoTolot's explanation is correct, it sounds like effectively, if the swinging axe can hit the blocker's arm, that's enough to turn the miner around, even though the miner himself is not actually close enough yet to feel the blocker.  This feels a little iffy and is sufficiently different from checking for steel, that I don't think we should blindly apply how we handle steel to the blocker case.

[ccexplore]

I had a closer look.  I think the most baffling case is the one where the miner went from not turning to turning, but just at that one particular pixel when he's still relatively far away from the blocker.  Ignoring that, when the miner started not very close to the blocker, he probably gets low enough by the time he's within range of the blocker's arm that he no longer gets turned, and further mining soon frees the blocker.  Only when he started very close to the blocker would he not have gotten low enough when within range of blocker's arm, and can still feel the blocker, getting turned.  Yet even closer (probably only at the last pixel before finally getting turned as a walker) and his first swing might reach just far enough to free the blocker, so he never got a chance to get turned.

So I guess maybe it's not too different from original Lemmings after all.  The only case that still looks questionable is that first case of getting turned, which happens even though the miner started relatively far away from the blocker, and it's not obvious why it only works that way on that one specific pixel.

[nin10doadict]

I actually have noticed this behavior myself and thought it strange, but dismissed it as some strange quirk of the engine. It generally doesn't get in the way of a puzzle anyway.

[Nepster]

As ccexplore already guess, the "weird" behavior appears, because the game checks for freed blockers when computing blueprints: If the miner frees the blocker a straight path is displayed. If the miner doesn't free the blocker, you'll get the zig-zag line.

The turning at the far-away pixel is a combination of the exact miner removal mask and how deep the blocker field reaches. This is kind of unfortunate, but I don't see a way to fix this without invalidating tons of replays.

[IchoTolot]

I think having the 1 pixel that turns the miner again is ok comparing to completely overhaul the miner physics again. Also, as nin10doadict siad it really doesn't get in the way of solving levels and one tiny framestep gets you to the desired behavior anyway. I never actively noticed it and just did another framestep instead anyway.