[BUG] Adding @Tigger[] Modifier to an @Door[] Trigger Silently Fails

[kitt-schlatter]

Module Version: v0.8.20

Description

When adding an @trigger[] modifier to a normally working @door[] trigger, the trigger will now silently fail to trigger. This occurs whether you used "doorClose" or "doorOpen".

Additionally, if the @trigger[] modifier is included after the @door[] definition, then it is ignored, and the trigger will execute only on "doorOpen" regardless of what was specified. I don't know if this is intended or not, but it is contrary to the following example given in the documentation:

@door[*]{Missioni}@trigger[DoorOpen]@macro[pause_the_game]

To Reproduce

1. Attempt to execute a simple @door[] trigger and observe that it works correctly on door open.
2. Add an @trigger[doorClose] or @trigger[doorOpen] modifier before the @door[] definition, and observe that nothing happens on door open or close.
3. Add an @trigger[doorClose] or @trigger[doorOpen doorClose] modifier after the @door[] definition, and observe that it only triggers on "doorOpen"

Expected behavior

The @door[] trigger executes successfully according to the criteria specified in the @trigger[] modifier.

Screenshots

N/A

Browser:

N/A - Standalone Executable.

Foundry Version:

v0.8.9

Game System:

D&D 5E

Additional context

I did not extensively test all variation of @trigger[] Modifiers, but confirmed that an @trigger[whisper] modifier works correctly on an @token[] trigger. So, the issue may be localized to just @door[] related triggers.

[p4535992]

Should be fixed with 0.8.21 let me know

[kitt-schlatter]

There still appears to be some strange behavior. If you have a couple @door[] @trigger[closeDoor] triggers setup, one of them appears to get into a "dead" state where it wont respond to the trigger anymore. If you edit and save the script though, they will reset and a new door can become dead. It looks like it's the second door I interact with after a refresh (save the script again) that becomes dead.

[p4535992]

can you pass me the triggers line ?

[kitt-schlatter]

Alright, so I did some additional testing, and I was able to narrow things down a bit.

First, I made some adjustments to the trigger to create a simple Hello World style example for you, and it worked just fine. Then, when I reverted the trigger back to exactly how it was before, it's also started working just fine when it wasn't before. I also setup brand new assets to test with, and those were also working just fine.

However, when I modified the trigger to be in the order of: @Trigger[closeDoor] @door[], then the weirdness started occurring again, and persisted even if I changed it back to the @Door[] @Trigger[closeDoor] ordering until I did an F5 refresh, at which point it would work again. So putting it in the second ordering appears to have put things in a bad state which Trigger Happy needed a refresh to recover from. This ordering worked correctly in previous version of Trigger Happy, but perhaps that's changed and is not the intended way of using the modifier now.

I'll leave it up to you to decide if this issue is resolved or not. For testing purposes, this is the script I was using (replacing relevant door details):

@door[4050,2450,4150,2450] @trigger[doorClose] @chatmessage[Door1]
@door[4050,2550,4150,2550] @trigger[doorClose] @chatmessage[Door2]
@door[4050,2650,4150,2650] @trigger[doorClose] @chatmessage[Door3]

[kitt-schlatter]

Some more follow up: I was able to reproduce the issue again without the ordering in the script mattering. I'm still not clear what's causing it, but I was unable to reproduce it with a simple hello world example; however, I can reproduce it with the actual script I'm running on trigger, which changes a door to a wall, and vice versa. So, it's possible that's related somehow? But, I couldn't reproduce the issue when I changed the door to a wall and back manually.

[kitt-schlatter]

And, even more follow up: I was also able to reproduce the issue without changing walls to doors simply by triggering the other doors to open. I'll include the macro I'm trigger here, as well as the full script, so hopefully you can reproduce and see what I'm seeing.

The Macro I'm triggering, which I called TriggerDoor, is:

let wallUpdates = [];
for(let i = 0; i < args.length; i++) {
wallUpdates.push({_id: args[i], ds: CONST.WALL_DOOR_STATES.OPEN});
}

await canvas.scene.updateEmbeddedDocuments("Wall", wallUpdates);

And this is the journal entry for TriggerHappy I have that uses it:

// First Set of Three Doors
@door[3850,2450,3950,2450] @trigger[doorClose] @chatmessage[/TriggerDoor "tBR5MZT5SQf0FI7v" "SMk6CzbKcVFXspf9"]
@door[3850,2550,3950,2550] @trigger[doorClose] @chatmessage[/TriggerDoor "lKzoGELim4Zn83qN" "tBR5MZT5SQf0FI7v"]
@door[3850,2650,3950,2650] @trigger[doorClose] @chatmessage[/TriggerDoor "SMk6CzbKcVFXspf9" "lKzoGELim4Zn83qN"]

// Second Set of Three Doors
@door[4050,2450,4150,2450] @trigger[doorClose] @chatmessage[/TriggerDoor "I2m4nbNec6wn50ux" "ZOIH1Lk4kKYf1oJO"]
@door[4050,2550,4150,2550] @trigger[doorClose] @chatmessage[/TriggerDoor "zAnGRuOLuldN3IdL" "I2m4nbNec6wn50ux"]
@door[4050,2650,4150,2650] @trigger[doorClose] @chatmessage[/TriggerDoor "ZOIH1Lk4kKYf1oJO" "zAnGRuOLuldN3IdL"]

Basically there are three doors, and when one closes, it should open the other two "linked" doors. This works at first, but if you constantly close these doors, eventually they start to get bugged and are only fixed by a refresh. This didn't occur with previous version of TriggerHappy as far as I know.