Lemmings Forums
Other Lemmings Projects => SuperLemmix => Closed SuperLemmix Bugs / Suggestions => Topic started by: WillLem on May 03, 2023, 08:50:47 PM
-
From a conversation on Discord:
Blocker fields are ignored on one way fields ... it's occuring in NL too
(https://i.imgur.com/gREBil5.png)
-
One or the other has to take priority in this case. Which one it is, is not going to be changed at this point.
-
About the blockers getting ignored in one-way zones...
Could you just disallow blockers in these zones? Make the selecting tone (or a fail tone) but not reduce the amount of available blockers?
This would (I think) have a better look and feel.
-
Could you just disallow blockers in these zones? Make the selecting tone (or a fail tone) but not reduce the amount of available blockers?
Agreed; since it has to be one or the other then it seems best to just not allow Blockers to be assigned on a OWF, in the same way that Miners/Diggers can't be assigned when walking on steel. This has now been fixed in Commit ed5d6b8db.
Meanwhile, a fail sound would be ideal for any and all disallowed assignments... this is something that would have to be done separately though, I'll add it to the to-do list. (https://www.lemmingsforums.net/index.php?topic=6180.msg98208#msg98208)
-
It's weird because the blockers used to work on One Way Fields, the replay I used was from a 2017 version of NL and the blocker would keep the Lemmings in a bunch on the one way field, they would be trapped in a pixel effectively.
Just don't know what has occurred in the NL code to stop this behaviour suddenly?
-
Just don't know what has occurred in the NL code to stop this behaviour suddenly?
If it's past behaviour that doesn't work now, it's likely the result of a bugfix elsewhere. I've had a quick look through the trigger areas code and can't find anything obvious that's causing Blockers to be ignored.
I've re-opened this topic because tbh I can't see any reason why Blockers shouldn't work on OWFs; if I can figure out how to restore this behaviour, and if it turns out that it was more of a design choice than a bugfix, then I'll bring it back. Otherwise, the best option as it stands is to prevent Blockers from being assignable; the next update will behave this way to prevent confusion in the meantime.
-
Meanwhile, a fail sound would be ideal for any and all disallowed assignments... this is something that would have to be done separately though, I'll add it to the to-do list. (https://www.lemmingsforums.net/index.php?topic=6180.msg98208#msg98208)
You could use the same (assign) tone but pitch it down to sound negative.
-
There's a further complication to this; Blockers are only ignored on left-facing OWFs, not right-facing ones (it's the same in NL as well).
-
disallowing OWF blockers fixes this as well, right?
-
disallowing OWF blockers fixes this as well, right?
Yes, it nullifies the problem completely. However, I'd prefer to allow Blockers on OWFs.
There's an else statement in the force-field trigger check which, if removed (so that each statement has it's own independent if-then), switches the behaviour around (so Blockers are ignored on right-facing fields, and work on left-facing ones).
So, it would seem that, as things currently stand, Blockers only work on either left-facing or right-facing one-way-fields. And, even when it does work, the lemmings flip back-and-forth between facing left and facing right, which looks wierd and buggy.
-
OK, I think I've found a fix.
Lemmings now do a separate check for the specific case that they have a contradictory force-field vertically in front of them. If this is the case, their X position is increased (or decreased, depending on the direction they're facing) by 1 pixel. This stops the flipping back-and-forth, whilst keeping them walking in place at the Blocker/Vertical field's trigger area. Basically, like this:
(https://i.imgur.com/wRymkuk.gif)
Testing is needed, and this fix may cause issues with overlapping contradictory fields in general, but - for now - it's better than only having Blockers work in one direction, and not being able to assign them at all.
Commit 9c948f9e4 implements this fix.