[P-BUG][PLAYER] Overlapping preplaced blockers cancelling others is inconsistent

Started by namida, November 19, 2021, 06:04:51 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

namida

Fix will be included in NL V12.13.0

Discovered this while investigating another bug: https://www.lemmingsforums.net/index.php?topic=5830.msg94480#msg94480

QuoteReordering the lemmings (in the level file) does affect this. Some orders raise an entirely different bug. It also appears that the bug occurs (with the same result) when the splitter is left-facing too; however, it only occurs if the splitter actually turns the lemming around (in either direction).

(Z = zombie, L = left blocker, R = right blocker)

ZLR - This one raises a bug where R ends up as a walker rather than a blocker when gameplay starts (however, he's still a blocker on the preview screen). This topic's bug does not occur.
ZRL - This topic's bug occurs, L becomes infected.
LZR - This one also raises the ZLR bug. This topic's bug also occurs, L becomes infected.
RZL - This topic's bug occurs, R becomes infected.
LRZ - The ZLR bug occurs; this topic's bug does not.
RLZ - This topic's bug occurs, L becomes infected.

The sample level (originally created by GigaLem to showcase the other topic's bug) is attached here too for convenience.
My projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)

namida

Specifically, this seems to occur when R is the last non-zombie preplaced lemming. Or more specifically - when R is after L in the order.

In all three cases, making L a non-blocker averts this bug. Making Z a blocker has no effect either way.

This, combined with how close together L and R are in the first place in this level, leads me to believe that what's actually going on here is that L and R are simply too close together for blockers to legally be placed - and the actual bug is not that R loses blocker status, but that L does not (in a case where R is placed first).

This theory is pretty much confirmed by that moving the blockers 1 pixel further apart, the cancellation of R's blocker status no longer occurs. Now, to figure out why this doesn't also happen to L...
My projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)

namida

Turns out there were multiple inaccuracies in the code responsible for checking for overlapping blocker fields, including during gameplay (ie: not just affecting preplaced lemmings). Fortunately, it would appear these are of the "forbid an assignment that should be valid" type, not the "allow an assignment that shouldn't be" - which should mean no replay breakage. In the particular cases described in this topic, it was not that L should not have been able to block; rather, it was that R should have been able to.

This has been fixed in commit a326cc8 and the fix will be included in V12.13.0.
My projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)