DM Token Lock Movement Showing To PCs

[MrDDT]

I've noticed while playing that when a DM uses token lock movement (using alt drag token as a DM) it will show the movement to players even those they are out of LOS and or under darkness.

See attached screenshot.

Left is DM client, right is PC client.

[Zacchaeus]

I'm not seeing this. What ruleset? Are you testing in a new campaign without extensions? Other steps needed to reproduce?

[MrDDT]

I'm not seeing this. What ruleset? Are you testing in a new campaign without extensions? Other steps needed to reproduce?

With no exts loaded, I can make it happen 100% of the time.

Simply put token lock on. Darkness turned on.
Hold ALT as a DM, move a token around. No matter where it is, players can see the movement.

5E sample campaign.

[Zacchaeus]

And I can't reproduce it at all. So what's different in your set up.

[MrDDT]

And I can't reproduce it at all. So what's different in your set up.

Do you have those tokens as hidden in the CT? Looks like they are, but I can't see the CT, just looking at the image.

[Zacchaeus]

They were, yes. I just threw it up to test. Does it matter? Do the trails not show if they are visible on the CT? I tested in other campaigns before I tested in the sample campaign with the same results whether hidden or visible. I thought maybe there was something about the sample campaign. I’m fairly sure it has no line of sight or lighting on the maps. And do you see this in other campaigns or just the sample one. I think if this was a universal issue we’d have seen a lot of reports. Is this just a recent thing? The client hasn’t been updated in a while so I’d have expected some more reports.

[MrDDT]

They were, yes. I just threw it up to test. Does it matter? Do the trails not show if they are visible on the CT? I tested in other campaigns before I tested in the sample campaign with the same results whether hidden or visible. I thought maybe there was something about the sample campaign. I’m fairly sure it has no line of sight or lighting on the maps. And do you see this in other campaigns or just the sample one. I think if this was a universal issue we’d have seen a lot of reports. Is this just a recent thing? The client hasn’t been updated in a while so I’d have expected some more reports.

I've only noticed it while being a player, which I'm normally not. Also not a lot of people know about the ALT moving with locked tokens that a DM does so most DM'd don't even use it.
No telling how long it's been there.

It's in all campaigns I've seen now (on my own campaigns) and others can make it happen on their computers/campaigns (which is how I noticed it).

[Moon Wizard]

We'd have to get an exact example of a campaign where this is happening. Can you make a simple CoreRPG or 5E campaign using the default SRD modules and letter tokens to show us an example?

Regards,
JPG

[Moon Wizard]

Also, do you have all the toggles on for your map? (Lighting, Line-of-sight, and token lock)

If you have lighting on, but LoS off, you're probably going to get behaviors you might not expect.

Regards,
JPG

[MrDDT]

We'd have to get an exact example of a campaign where this is happening. Can you make a simple CoreRPG or 5E campaign using the default SRD modules and letter tokens to show us an example?

Regards,
JPG


Also, do you have all the toggles on for your map? (Lighting, Line-of-sight, and token lock)

If you have lighting on, but LoS off, you're probably going to get behaviors you might not expect.

Regards,
JPG

Here are all the settings, as I said I can do it in any campaign not just mine, and I even tried it in the 5e sample campaign. I have no idea about other rulesets as I don't ever use them I have no idea what they can or can't do.

I have the DM screen as the big background, with the player screen over the top of it circled in red. The second picture is the DM settings.

I have nothing loaded, no modules no exts.

[Moon Wizard]

That's odd; I'm not seeing any of that. Can you zip up a simple example campaign where you see it, just to see if anything makes a difference?

Thanks,
JPG

[Moon Wizard]

Also, what version is being reported in the launch screen?

JPG

[Zacchaeus]

So I've been able to reproduce this - sort of. Proceed as follows (token lock enabled and DM using ALT+move on the NPC tokens)

1. Any map that has line of sight on it and share with client
2. Add a PC token who has no vision or light source
3. Add any NPC token with or without a light source to a place on the map which is behind any LoS occluder
4. Move the NPC token around and the client doesn't see any movement lines
5. Move the NPC token to where the PC token could see it if they had light or vision - in other words where the NPC token isn't blocked by LoS
6. Now move the NPC token anywhere and the client will register the movement lines.

The images below illustrate this - the first pair the NPC token starts behind LoS occluders and the client doesn't register the movement. In the second pair the NPC starts in a position not blocked by Line of sight and the movement is registered on the client side. I see no difference no matter what settings are used or whether the map is set to background or not. Also giving the PC a light or vision source doesn't change the outcome. Fog of war doesn't seem to have any effect (in other words if the NPC token starts a move where the PC token has been but can no longer see then the movement lines aren't registered).

The only factor seems to be that the NPC token must start in a place which isn't blocked by Line of Sight.

[MrDDT]

That's odd; I'm not seeing any of that. Can you zip up a simple example campaign where you see it, just to see if anything makes a difference?

Thanks,
JPG


Also, what version is being reported in the launch screen?

JPG


So I've been able to reproduce this - sort of. Proceed as follows (token lock enabled and DM using ALT+move on the NPC tokens)

1. Any map that has line of sight on it and share with client
2. Add a PC token who has no vision or light source
3. Add any NPC token with or without a light source to a place on the map which is behind any LoS occluder
4. Move the NPC token around and the client doesn't see any movement lines
5. Move the NPC token to where the PC token could see it if they had light or vision - in other words where the NPC token isn't blocked by LoS
6. Now move the NPC token anywhere and the client will register the movement lines.

The images below illustrate this - the first pair the NPC token starts behind LoS occluders and the client doesn't register the movement. In the second pair the NPC starts in a position not blocked by Line of sight and the movement is registered on the client side. I see no difference no matter what settings are used or whether the map is set to background or not. Also giving the PC a light or vision source doesn't change the outcome. Fog of war doesn't seem to have any effect (in other words if the NPC token starts a move where the PC token has been but can no longer see then the movement lines aren't registered).

The only factor seems to be that the NPC token must start in a place which isn't blocked by Line of Sight.


I can, but there is nothing really to it.

I have v4.1.4 Ultimate (2021-6-08)

At least you can see it now.

Do I need to send the campaign file still?



Also giving the PC a light or vision source doesn't change the outcome. Fog of war doesn't seem to have any effect (in other words if the NPC token starts a move where the PC token has been but can no longer see then the movement lines aren't registered).

This is incorrect for me.

As long as the NPC token starts a move where the PC token can't see and it is not blocked by LOS, it will show the move. FOW or not.
The quoted statement above would be correct if you changed the word "aren't" to "are" might have been a typo.

Glad we got it worked out, it seems that LOS is working fine, but the lighting/vision is the issue.

[Zacchaeus]

It isn't sorted out.

What I'm seeing is the polar opposite of what you are seeing. The client only sees the movement arrows if the NPC token starts their move when not blocked by Line of Sight. From your screenshots the client is seeing the movement arrows when they are behind wall occluders.
I further tested this and it makes no difference if lighting is switched off and it further makes no difference if lighting is on and Line of sight is off. In all cases the client only sees the NPC movement arrows if the NPC token starts its move in sight of the PC token.

[MrDDT]

It isn't sorted out.

What I'm seeing is the polar opposite of what you are seeing. The client only sees the movement arrows if the NPC token starts their move when not blocked by Line of Sight. From your screenshots the client is seeing the movement arrows when they are behind wall occluders.
I further tested this and it makes no difference if lighting is switched off and it further makes no difference if lighting is on and Line of sight is off. In all cases the client only sees the NPC movement arrows if the NPC token starts its move in sight of the PC token.



Ok so lets do this over.

LOS = Walls
Lighting = Darkness/Darkvision/Lights etc

There are no LOS on any of my pictures. Only lighting.

In your last picture (Capture4.jpg), you caused it to happen. Token can not see the target (total blackness) yet they can see the movement (in total blackness).

Now when LOS is placed, LOS is causing it to work correctly. Token can not see because of LOS the movement before or after, as it should.


So here is how I would restated my first post now I know exactly what is happening when.


Token lock on.
Darkness on.
No LOS (or no LOS blocking to each token at the start of NPC token ALT move).

PCs Token with LOS but not Lighting to NPC token can see NPC tokens moves when the DM uses ALT move token.

[Moon Wizard]

I am able to recreate Zaccaheus's specific case.

One of the reasons why I wanted a campaign was to avoid all this back and forth, and semantic issues.
(i.e. lighting and line-of-sight toggles for functionality on a map are very different than whether any lights or any line-of-sight blockers are defined on a map.)
A simple test campaign with exact steps will remove any uncertainty and guesswork.

If you have lighting and LoS toggles enabled, and you have lights defined but no LoS blockers defined, then you are essentially getting the example case that Zacchaeus posted (I think).
In his example, if the token is visible to LoS without lighting (but does consider LoS blockers), then the planned movement path does appear to client. From your statements, since you have no LoS blockers defined, then the tokens are always visible to LoS without lighting. So, I think this is the issue.

If you feel like I'm missing something, please provide example campaign and exact steps, so that we can dispose of the guesswork and semantic confusion.

Thanks,
JPG

[MrDDT]

I am able to recreate Zaccaheus's specific case.

One of the reasons why I wanted a campaign was to avoid all this back and forth, and semantic issues.
(i.e. lighting and line-of-sight toggles for functionality on a map are very different than whether any lights or any line-of-sight blockers are defined on a map.)
A simple test campaign with exact steps will remove any uncertainty and guesswork.

If you have lighting and LoS toggles enabled, and you have lights defined but no LoS blockers defined, then you are essentially getting the example case that Zacchaeus posted (I think).
In his example, if the token is visible to LoS without lighting (but does consider LoS blockers), then the planned movement path does appear to client. From your statements, since you have no LoS blockers defined, then the tokens are always visible to LoS without lighting. So, I think this is the issue.

If you feel like I'm missing something, please provide example campaign and exact steps, so that we can dispose of the guesswork and semantic confusion.

Thanks,
JPG


It almost feels like you guys are going out of your way to not do this correctly. It's so easy, I've had like 15 people tell me about it also. I've shown the steps to over 15 people and they all can make it happen first try with me just saying exactly what I said already.


I will leave it here, if you want to fix it you can. I know the issue so I can avoid it. I will deal with the update if or once you guys fix it. Good luck with your product.

[Zacchaeus]

So if you had mentioned in post #1 that you didn't have Line of Sight on - instead of having us waste our time for two days until post #16 then we might have been able to recreate and answer your specific problem a helluva lot faster.

[Kelrugem]

I was able to reproduce it :)

Here the steps (using the attached campaign)

1. Open the AmnizuWachstation (the only image in that campaign)
2. Observe there is Bob the Scotsman in the upper left corner, and an aboleth in the lower right
3. Join yourself and take ownership of Bob, Bob has darkvision
4. Open the image on the host and the client (image should already be shared)
5. On the host side: Move the aboleth while pressing alt at the start :) (such that the typical lock token movement starts) Keep the movement of the aboleth outside of Bob's darkvision
6. Observe on the client side that the movement is completely shown, even if the Aboleth's movement never touches the darkvision area

Hope that helps :)

[Kelrugem]

So I've been able to reproduce this - sort of. Proceed as follows (token lock enabled and DM using ALT+move on the NPC tokens)

1. Any map that has line of sight on it and share with client
2. Add a PC token who has no vision or light source
3. Add any NPC token with or without a light source to a place on the map which is behind any LoS occluder
4. Move the NPC token around and the client doesn't see any movement lines
5. Move the NPC token to where the PC token could see it if they had light or vision - in other words where the NPC token isn't blocked by LoS
6. Now move the NPC token anywhere and the client will register the movement lines.

The images below illustrate this - the first pair the NPC token starts behind LoS occluders and the client doesn't register the movement. In the second pair the NPC starts in a position not blocked by Line of sight and the movement is registered on the client side. I see no difference no matter what settings are used or whether the map is set to background or not. Also giving the PC a light or vision source doesn't change the outcome. Fog of war doesn't seem to have any effect (in other words if the NPC token starts a move where the PC token has been but can no longer see then the movement lines aren't registered).

The only factor seems to be that the NPC token must start in a place which isn't blocked by Line of Sight.


I am able to recreate Zaccaheus's specific case.

One of the reasons why I wanted a campaign was to avoid all this back and forth, and semantic issues.
(i.e. lighting and line-of-sight toggles for functionality on a map are very different than whether any lights or any line-of-sight blockers are defined on a map.)
A simple test campaign with exact steps will remove any uncertainty and guesswork.

If you have lighting and LoS toggles enabled, and you have lights defined but no LoS blockers defined, then you are essentially getting the example case that Zacchaeus posted (I think).
In his example, if the token is visible to LoS without lighting (but does consider LoS blockers), then the planned movement path does appear to client. From your statements, since you have no LoS blockers defined, then the tokens are always visible to LoS without lighting. So, I think this is the issue.

If you feel like I'm missing something, please provide example campaign and exact steps, so that we can dispose of the guesswork and semantic confusion.

Thanks,
JPG

Ah, and now I see that the problem/issue was already reproduced and understood, just with more details (including LoS occluders, not just activated LoS) :D

I only read the last posts here and had the impression that a sample campaign may be needed :)

(MrDDT's suggestion here is basically that the shown path should also respect lighting, not just LoS, and maybe even make the part of the path invisible which is behind LoS occluders or in darkness. But that sounds like complicated coding)