PDA

View Full Version : PC token vs wall/closed window behavior



Weissrolf
March 15th, 2021, 15:52
Could someone explain the following behavior to me when clients/players try to move their token through a wall/closed window?

Animated GIF:
https://i.imgur.com/P9xFTnF.gif

LordEntrails
March 15th, 2021, 16:01
I'm not seeing behavior that is other than what I would expect and hope for.

The token is stopped by walls. Their is still a cursor shadow though that show where the actual cursor is, even though the token can't move there. If there was no shadow, then it would be very disorienting to move the cursor but have no visual indicator or where the computer thinks the cursor actually is.

I've used programs that stop the the visual indicator, and it causes lots of problems.

Weissrolf
March 15th, 2021, 16:03
The token is only stopped by the wall left to the window, but enters the wall on the right of the window. This is what perplexes me. At one point it even passes through the closed window, because it came from within the wall.

The GM view of the walls don't show anything particularly different between both sides, but they still behave differently.

We saw several maps where player tokens entered walls like that. I mean to remember that at one point a token even entered so deep into the wall that the player saw the other side of the wall, but my memory may fail me there.

Personally I would prefer if tokens were allowed about two-fifth into walls, so that they can still occupy grid boxes, but don't enter too far.

BaneTBC
March 15th, 2021, 16:17
Looking at what is showing in the LoS occluders, there doesn't appear to actually be a window there, it is just a plain open area that any token can pass through. Dragging the token with your mouse, you're bound to get a little oddity in what you're seeing, because there is a little video lag between where your mouse has moved and where the image shows, you'd be a bit better off checking using keyboard movement to a degree. I'd recommend actually putting in the occluders for the window and retest.

pindercarl
March 15th, 2021, 16:23
The token is only stopped by the wall left to the window, but enters the wall on the right of the window. This is what perplexes me. At one point it even passes through the closed window, because it came from within the wall.

The GM view of the walls don't show anything particularly different between both sides, but they still behave differently.

We saw several maps where player tokens entered walls like that. I mean to remember that at one point a token even entered so deep into the wall that the player saw the other side of the wall, but my memory may fail me there.

Personally I would prefer if tokens were allowed about two-fifth into walls, so that they can still occupy grid boxes, but don't enter too far.

I'll need a copy of the campaign and the name of the map with the issue.

Weissrolf
March 15th, 2021, 16:23
Concise question: Why does the token enter the wall on the right side, but not on the left side?

https://i.imgur.com/AM2MYW0.png

Weissrolf
March 15th, 2021, 16:31
I just found my own answer:

https://i.imgur.com/G2XDnnZ.gif

Left:
https://i.imgur.com/mVKl8Z1.png

Right:
https://i.imgur.com/E8sZldL.png

I think the whole wall vs. token logic could use a bit of improvement. We want tokens to occupy grid spaces outside a wall without them looking through the wall. We get that currently, but as you can see the results are somewhat inconsistent.

pindercarl
March 15th, 2021, 16:33
Concise question: Why does the token enter the wall on the right side, but not on the left side?

https://i.imgur.com/AM2MYW0.png

The check to see if movement is blocked checks between the position of the token and target destination of the token. You have grid snap enabled, so both the initial position of the token and the target position with snapped to the grid. You doorway is not snapped to the grid so the token is blocked from the left and not blocked from the right.

Also, regarding your first post, based on this screenshot that is not a window.

Weissrolf
March 15th, 2021, 16:38
We also need a modifier (usually shift) to allow drawing of straight horizontal and vertical LoS lines.

Weissrolf
March 15th, 2021, 16:55
The check to see if movement is blocked checks between the position of the token and target destination of the token. You have grid snap enabled, so both the initial position of the token and the target position with snapped to the grid.
In this case it depended on a single pixel between left and right side. We could blame the person drawing the LoS lines, but since there does not seem to be any modifier to draw straight horizontal lines it's hard to get that right.


Also, regarding your first post, based on this screenshot that is not a window.
I did not change anything on this map. That the first animated GIF screenshot does not include the LoS occluder seems to have been a bug of FGU then, because it was absolutely present and switchable (open/closed).

Furthermore, you may notice that the later screenshot shows the window as "terrain" (green) instead, so seeing the token walk through it was a misinterpretation (not connected to entering the wall). Since I don't draw my own maps/LoS I had to do some trial & error to find out about that. The map is "Cinderclaw mine" from the Age of Ashes AP 2, as bought from the SW shop.

Overall I suggest that tokens can always enter walls by one-third or two-fifth instead of being stopped at half-grid steps, even when snap-to-grid is enabled. Else the GM has to manually move them around to allows PC tokens to stand in confined quarters where one pixel LoS can make or break player movement.