Wheel of Misfortune -- inconsistent physics

[Simon]

Hi,



Here's a bug level, Wheel of Misfortune. See attachment for level, and for the solving replay.

Successive hints for solving yourself

Hint 1

You need both builders for the exit platform. Therefore, you must contain the crowd with 1 blocker, 1 exploder, 1 disarmer.

Hint 2

If you removed the trap from the level, the level would be unsolvable!

Hint 3

The floor is thin, an exploder crater would make a fatal hole. Yet the exploder is a key skill.

Hint 4

The 2nd lemming builds. The 4th lemming gets all the remaining skills.

Hint 5

The 4th lemming blocks directly on the wheel's trigger area.

Hint 6

The 4th lemming is already a disarmer when it blocks on the trap.

Hint 7

Assign disarmer to lem #4 on spawn. Assign blocker to lem #4 when directly on the wheel's trigger area. Assign builder to lem #2 at the cliff. Assign exploder to the blocking #4.

This level highlights an inconsistency of the engine. Decide whether there is a bug, and if so, what to do!

The inconsistency -- spoiler

Exploder reacts to exits and traps: An exploder cannot be assigned anything, but it will react to trigger areas. Exit trigger areas turn the exploder into an exiter. Trap trigger areas turn the exploder into a disarmer, or begin eating the lemming.

Blocker reacts to exits, but not to traps: Put a blocker in front of a locked exit. Open the exit. The blocker jumps into the exit. But put a blocker on a busy trap. Wait until the trap has finished eating. The trap will not eat the blocker!

My proposal -- spoiler

Make blockers react to traps. As soon as the trap has finished eating someone else, let the blocker disarm the trap, or get eaten.

-- Simon

[IchoTolot]

I would join Simon's proposal, that the trap should react to the blocker.  The exit does and so should the trap.

[Nepster]

For now I implemented, that blockers react to all trigger types, except to flippers (where the only effect would be a madly dancing flipper and a totally arbitrary walking direction once the blocker is freed). So not only will be blocker be eaten by the Wheel of Misfortune, blockers will also be teleported away,...

Note that this isn't yet a final decision on this matter. If it turns out that there are problems with the new mechanics, or that it is generally disliked, we can easily revert the changes and go back to the V1.43 machanics.

[namida]

For now I implemented, that blockers react to all trigger types, except to flippers (where the only effect would be a madly dancing flipper and a totally arbitrary walking direction once the blocker is freed). So not only will be blocker be eaten by the Wheel of Misfortune, blockers will also be teleported away,...

Note that this isn't yet a final decision on this matter. If it turns out that there are problems with the new mechanics, or that it is generally disliked, we can easily revert the changes and go back to the V1.43 machanics.

The one thing that comes to mind is when should the blocker field be removed?

In the case of teleporters, should it disappear immediately and be restored only when the lemming is "freed" from the receiver?

In the case of a trap, should it remain until the trap animation is finished?

The reason for putting this forward is that we already have one special case where a blocker field remains on a non-blocker - when the blocker becomes an OhNoer.

Also - what you describe with splitters would not happen, I don't think. Unless you've changed this, when a lemming enters a splitter's trigger area (regardless of whether or not it causes a change in direction), it gains immunity to that splitter (but not other splitters) until it has spent one frame outside the splitter's trigger area.



Otherwise, one alternative solution could simply be to add Ohnoer to the conditions that are not eligible to disarm (and thus they would get trapped). This already applies for most other states that aren't walkers.

[Nepster]

The one thing that comes to mind is when should the blocker field be removed?

In the case of teleporters, should it disappear immediately and be restored only when the lemming is "freed" from the receiver?

In the case of a trap, should it remain until the trap animation is finished?

The reason for putting this forward is that we already have one special case where a blocker field remains on a non-blocker - when the blocker becomes an OhNoer.

There is one difference: OhNoers are still standing at the blocker's position and act of their own will (as much as lemmings ever do that). So they can still communicate to other lemmings that they should turn around.
Teleporting lemmings on the other hand are simply nowhere on the level, so how can they interact with other lemmings? And when would we switch the position of the blocker field to the receiver? If we do when the receiver starts working, then the blocker field appears before the lemming arrives there. If we only add it once the receiver animation is finished, then we have a blocker field in front of a non-working teleporter for a time.
For lemmings that are killed by traps: I personally consider them dead the moment the animation starts, because in the last frames of the animation, the bits and pieces that remain are certainly no longer a living lemming. And I have a hard time believing, that a dead lemming within a trap can still maintain a blocker field, especially if the trap moves the lemming away as e.g. the chameleon or the rope trap (pillar style) do. (On a side note: As we currently remove lemmings when triggering a trap, keeping blocker fields would mean rather big changes in the code here).

For these reasons, the blocker fields for teleported or trapped lemmings are currently removed on encountering the trigger area, and only reset (in the case of teleporters) when the lemming appears again at the receiver.

Also - what you describe with splitters would not happen, I don't think. Unless you've changed this, when a lemming enters a splitter's trigger area (regardless of whether or not it causes a change in direction), it gains immunity to that splitter (but not other splitters) until it has spent one frame outside the splitter's trigger area.

Thanks, I forgot about this. But either way, splitters don't interact with blockers, so no harm in keeping the current code.

Otherwise, one alternative solution could simply be to add Ohnoer to the conditions that are not eligible to disarm (and thus they would get trapped). This already applies for most other states that aren't walkers.

Very good point. OhNoers disarming traps doesn't make any sense. This bug was even present before changing the blocker behavior:

Spoiler for LPIII

Using the trick of LPIII, Fierce 1 "Dead is the new black", it is already possible to get OhNoers onto trigger areas, if the trigger areas reach exactly to the top of the terrain, but not above^*. They then start disarming and forget to explode...
^* Actually due to another bug introduced by doing intermediate checks, the trigger area may sometimes reach one or two pixels above the terrain and will still get disarmed. The lemming will then disarm the trap while hovering in the air...

[Simon]

This depends on terrain below feet now.

In 1.48:
<Nepster> Lemming can disarm trap if it has a pixel below its feet and is not climbing, swimming or ohnoing.
<SimonN> wtf, since when does stuff [triggered traps] depend on pixel below

I'm sure this will catch many corner cases, but trap behavior depends on pixels below feet now. Strikes me as odd. Other gadgets never depend on terrain?

-- Simon

[namida]

The disarming action depends on having terrain to stand on. The trap's kill effect can still impact a midair lemming.

[Simon]

The disarming action depends on having terrain to stand on. The trap's kill effect can still impact a midair lemming.

I have understood that from Nepster's description already. The question is about rules design, not how the code handles it.

In 1.48, a hungry trap eats a lem if (the lem is in mid-air, or the lem lacks the disarmer ability, or is climbing/swimming/ohnoing). Otherwise, the lem disarms the trap.

In this formulation, it's obvious how the trap's behavior depends on terrain. Are there any other gadgets whose function you can describe like so? If the triggered trap is the only gadget, what is the rules advantage of terrain dependency particularly for traps?

-- Simon

[namida]

Exits, where the lemming must be floating, gliding, or standing on solid ground.

There was discussion about applying the same rule to teleporters, but this didn't happen in the end IIRC.