[+][BUG][PL] Inconsistent skill/projection shadows with (de)assigners

[GigaLem]

While the topic originally sounded confusing (original topic name was "New Objects interrupt skill mask in a non-interrupted instance"), here is a lemming highlighted to show the miner tunnel facing left.
Each object is tagged correctly and Lemming will mine the tunnel despite the new object (skill adder in this case) saying other wise.

this also makes Miner+builder tunnels difficult to judge because of the skill adder stopping the mask preemptively showing an incorrect mask outcome.

[namida]

As this wouldn't affect physics, it's something WillLem can (and likely will) fix in CE. I believe that the simulations for those shadows contain a list of objects that are considered to not interrupt the shadow; so it's just a matter of adding the new types to this list.

To reword what GigaLem is saying here (this wording will mostly be useful to WillLem or other people looking at NL source code): When a simulation of a lemming is performed for the sake of creating a shadow - or at least, shadows from the building / tunneling skills - if the simulated lemming passes through the trigger area of one of the new object types, the simulation treats it as if the skill is interrupted at that point, even if it isn't actually.

[Simon]

Ah. Similar problem then to the Fixed: Skill shadow ignores death from out-of-bounds. Yeah, the shadows don't always follow real physics.

Reworded topic title from:
New Objects interrupt skill mask in a non-interrupted instance
to:
New Objects stop miner shadow, but real miner continues

-- Simon

[WillLem]

Fixed in CE commit 19db02d7.

if the simulated lemming passes through the trigger area of one of the new object types, the simulation treats it as if the skill is interrupted at that point, even if it isn't actually.

Thanks for this, helped to pinpoint the source of the bug fairly quickly.

I believe that the simulations for those shadows contain a list of objects that are considered to not interrupt the shadow; so it's just a matter of adding the new types to this list.

It was the other way around: these objects are included in a list of interactions that should interrupt the simulation (e.g. trap and isn't a disarmer, fire, water, teleporters, etc) so it was a case of removing them from that list.

I do wonder though... although these objects shouldn't outright interrupt the projection shadow, they should update its trajectory. For example, this projected Glider shadow should detect the skill remover and transition the simulated lem to faller:



And similarly, since the lem passes through the Glider assigner in the first place, the simulated lem should glide rather than fall:



So, the OP bug is fixed for basic skill shadows, but more will need to be done to take assigners/de-assigners into account for projection shadows.

[namida]

I'm now remembering: I intended for the assigners, deassigners and portals to specifically cancel the projection shadow, as an alternative to having to make the shadow handle these cases (as it would be a relatively rare edge case anyway of needing a shadow that passes through one). Seems however, I forgot to make it only apply to the projection shadow (and maybe also added neutralizers / deneutralizers by mistake?).

[WillLem]

I'm now remembering: I intended for the assigners, deassigners and portals to specifically cancel the projection shadow

I figured this might be the case. This approach might come in handy if I can't get the updated projections to work.

Speaking of which, I've had a go at updating the projection shadow for (de)assigners. So far, I can get it to work for assigners, but only by applying all permaskills to the simulated lem: obviously not ideal, more work needed.

I've had mixed success with de-assigners. Not sure what I'm doing wrong, I'll keep trying with it.

Seems however, I forgot to make it only apply to the projection shadow (and maybe also added neutralizers / deneutralizers by mistake?).

You didn't add (de)neutralizers, no worries there. If there is a way to stop simulation only for projections, this might come in handy.