First the bug, which is difficult to explain, but here goes:
- gm and player client connected
- Two tokens on a map: A and B.
- Player owns both tokens
- client view of player is centred on A
- A is selected
When Player moves a token an event macro is triggered that
1. moves token B in a relative path (so if A is moved 4 squares to the right, then B is moved 4 squares to the right) with the moveToken command
2. centres view of player client to token B
4. runs exposePCAreaOnly()
If the player now moves B the commands 1 to 4 are triggered again but now for token A.
It turns out that exposePCAreaOnly does not (entirely) work in this case. If you cram some pauses in the macro you'll notice that after the exposePCAreaOnly command all the FoW is reset except around the selected PC token, however when the macro is finished the previously exposed area shows up again.
The workaround. Might be useful in other circumstances as well:
Trying to fix this issue I tried the following:
- first I tried to defer the command, no result (old area was still exposed).
- Then I tried broadcast a macrolink… no result
- Then I tried broadcasting the macrolink to the gm client...no result
- Then I tried broadcasting the macrolink from the gm client to the pc client: Worked!! (finally)
However the command needs to be initiated after the player moved his token… so… I created a broadcast from the player client to the gm that ran a broacast from the gm client to the pc that ran the exposePCAreaOnly which worked!!
here the code:
last line after the event has been triggered on the Player client:
[broadcast(macroLink("", 'bounceDefer@lib:EventMacros', 'none', owners), 'gm')]
owners is the list of owners of the tokens that just gained focus (so B in above example)
macro bounce defer is ran from the gm client:
[broadcast(macroLink("", 'deferResetFoW@lib:EventMacros', 'none'), arg(0))]
deferResetFoW is again ran from the player client:
Its quite an overkill on commands and traffic to just get the FoW reset, but I need this to work. This workaround might also work on the copyToken() issue. Didn't try, but who knows.