Walls are not completely blocking movement

[adminwheel3]

I'm having an issue where tokens can regularly move a half-step through walls. I did have Peek .1 turned on at one point, but I have since turned it off, because that, combined with semi-permeable walls was making my maps a confusing jumble. Any help would be appreciated.

Correction: the issue is not that they can move a half-step through walls, which is what I incorrectly presumed was allowing for vision to pass through the walls. The issue is that walls can be seen through - most often (but not always) when a token is partially overlapping a solid wall.

[adminwheel3]

And in case it matters - I've tested this will all extensions turned off.

[bwatford]

Same issue as above with single line walls and 0.1 peak turned on.

[MrDDT]

Same issue.63757

[Moon Wizard]

If you are having a map issue, please provide a copy of the campaign zipped up as well as the name of the image record affected.
(If you are using images/modules not sold through the FG store, we will need those also.)

Regards,
JPG

[MrDDT]

If you are having a map issue, please provide a copy of the campaign zipped up as well as the name of the image record affected.
(If you are using images/modules not sold through the FG store, we will need those also.)

Regards,
JPG

Fundamental Fantasy Map Pack by Josh.
Map UnderWaterCaves

This is not a normal use case but this is one I found on a map I knew you would have and in a clean campaign.
5E campaign linked.

6376063761

[Moon Wizard]

I was talking with Carl; and he reminded me that we had done this by design.

If all the edges and corners of a token were checked before moving into walls, then tokens would never be able to move through winding cavern corridors as they would constantly be getting hung up or blocked for being too narrow. Also, blocking this also precludes "Squeezing" type of rules that allow Larger creatures to move through narrower spaces.

Regards,
JPG

[Moon Wizard]

@MrDDT,

I'll pass along your example to Carl; because while the token edges being able to overlap the wall is by design, seeing through walls is not.

Regards,
JPG

[adminwheel3]

@MrDDT,

I'll pass along your example to Carl; because while the token edges being able to overlap the wall is by design, seeing through walls is not.

Regards,
JPG

If another example is needed, I can supply - I've just not gone through this process before.

It feels like there are two, related issues taking place - and MrDTT is correct - the main issue is seeing through the walls, which sometimes just happens, as in these images I reattached. There you can the token is not adjacent to the wall where vision is penetrating, with the solid wall shown in the second image.

That said, I can most easily trigger this see-through bug when mouse-dragging a token across the line of a solid wall. Using arrow key movement combined with grid snapping does not trigger the bug associated with mouse-dragging, but other locations where the walls can been seen through, even with arrow key movement, can still be found.

[MrDDT]

If another example is needed, I can supply - I've just not gone through this process before.

It feels like there are two, related issues taking place - and MrDTT is correct - the main issue is seeing through the walls, which sometimes just happens, as in the first image I reattached.

That said, I can most easily trigger this see-through bug when mouse-dragging a token across the line of a solid wall. Using arrow key movement combined with grid snapping does not trigger the bug associated with mouse-dragging, but other locations where the walls can been seen through, even with arrow key movement, can still be found.

They will need the campaign, not just pictures. They want to know what is going on and hard to see that in just pictures.

[adminwheel3]

Ok Fine -but no laughing at my campaign folder size. It's Rubenesque.

https://1drv.ms/u/s!AmavEqHQ4NZSkPpnvmOQz6yd86fHxA?e=8EehsC

The file in question is Ruined Dock Area.jpg.

[LordEntrails]

If another example is needed, I can supply - I've just not gone through this process before.

It feels like there are two, related issues taking place - and MrDTT is correct - the main issue is seeing through the walls, which sometimes just happens, as in these images I reattached. There you can the token is not adjacent to the wall where vision is penetrating, with the solid wall shown in the second image.

That said, I can most easily trigger this see-through bug when mouse-dragging a token across the line of a solid wall. Using arrow key movement combined with grid snapping does not trigger the bug associated with mouse-dragging, but other locations where the walls can been seen through, even with arrow key movement, can still be found.
There was a bug like this a year or more ago, I don't remember specifically. Until it was fixed, a work around was just to move the wall node a single pixel one way or another. Don't know if that will work in this case.

[MrDDT]

There was a bug like this a year or more ago, I don't remember specifically. Until it was fixed, a work around was just to move the wall node a single pixel one way or another. Don't know if that will work in this case.

If we have to double check all LOS and then move walls all the time and replace them. It would be worth it to me just to pick another VTT. I understand you are giving a work around, but it's way to common for it to be viable to "work around" it.

We could also use masking, or not allow tokens to be moved with dragging, or other options.

[LordEntrails]

If we have to double check all LOS and then move walls all the time and replace them. It would be worth it to me just to pick another VTT. I understand you are giving a work around, but it's way to common for it to be viable to "work around" it.

We could also use masking, or not allow tokens to be moved with dragging, or other options.
I did not say this was a solution. I said this was a "work around". Nor did I ever say or imply that it should not be fixed.

[jharp]

I have provided many similar samples over time but to my knowledge they have never been fixed. They have acknowledged the issues but it is always in work for a better system.

I pray it gets fixed as I simply stopped making maps rather than fight the bugs.

Jason

[adminwheel3]

Hey there Smiteworks - reaching out to see if there is an update on the status of this bug? Campaign files were provided as requested - and its been reported by multiple users.

Thanks!

[Moon Wizard]

There are conditions in the LoS algorithm that can cause this condition with multiple lines parallel to each other. We’ve tried fixing internally multiple times; but the overhauls to fix are always too slow performance wise. We are talking internally about taking another pass at this for summer release. It’s not something that can be rushed, since it impacts multiple systems and performance so heavily.

In the mean time, as a work around, adjusting LoS points where the issue occurs even by a single arrow adjust often fixes these issues.

Thanks to everyone who provided data. Carl will be looking at those to see if anything quick can be done; and using for test cases for future releases using new algorithms.

Regards,
JPG

[MrDDT]

There are conditions in the LoS algorithm that can cause this condition with multiple lines parallel to each other. We’ve tried fixing internally multiple times; but the overhauls to fix are always too slow performance wise. We are talking internally about taking another pass at this for summer release. It’s not something that can be rushed, since it impacts multiple systems and performance so heavily.

In the mean time, as a work around, adjusting LoS points where the issue occurs even by a single arrow adjust often fixes these issues.

Thanks to everyone who provided data. Carl will be looking at those to see if anything quick can be done; and using for test cases for future releases using new algorithms.

Regards,
JPG

Thank you MW for the transparency and working on this.

[adminwheel3]

There are conditions in the LoS algorithm that can cause this condition with multiple lines parallel to each other. We’ve tried fixing internally multiple times; but the overhauls to fix are always too slow performance wise. We are talking internally about taking another pass at this for summer release. It’s not something that can be rushed, since it impacts multiple systems and performance so heavily.

In the mean time, as a work around, adjusting LoS points where the issue occurs even by a single arrow adjust often fixes these issues.

Thanks to everyone who provided data. Carl will be looking at those to see if anything quick can be done; and using for test cases for future releases using new algorithms.

Regards,
JPG

Thanks for the clarification - good luck with the work!