[BUG] Blockers don't work on One-Way Fields [FIXED]

[WillLem]

From a conversation on Discord:

Blocker fields are ignored on one way fields ... it's occuring in NL too

[namida]

One or the other has to take priority in this case. Which one it is, is not going to be changed at this point.

[jkapp76]

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.

[WillLem]

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.

[Flopsy]

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?

[WillLem]

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.

[jkapp76]

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.

You could use the same (assign) tone but pitch it down to sound negative.

[WillLem]

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).

[jkapp76]

disallowing OWF blockers fixes this as well, right?

[WillLem]

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.

[WillLem]

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:



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.