[1.7.0] canSeeToken wrong with snap to grid vbl

Thoughts, Help, Feature Requests, Bug Reports, Developing code for...

Moderators: dorpond, trevor, Azhrei

Forum rules
PLEASE don't post images of your entire desktop, attach entire campaign files when only a single file is needed, or generally act in some other anti-social behavior. :)
Post Reply
User avatar
wyrmwood_lives
Cave Troll
Posts: 25
Joined: Fri Nov 08, 2019 10:22 pm

[1.7.0] canSeeToken wrong with snap to grid vbl

Post by wyrmwood_lives »

This isn't a "bug" per se, but more of a usability problem.

If two tokens are visible, and you impersonate the first and select the second, then type into the chat

Code: Select all

[canSeeToken(getSelected())]
The output to the chat is
["TOP_LEFT", "BOTTOM_LEFT", "TOP_RIGHT", "BOTTOM_RIGHT", "CENTER"]
without_vbl.jpg
without_vbl.jpg (48.86 KiB) Viewed 498 times
If you add vbl, using snap to grid,
now the output is
["TOP_LEFT", "CENTER"]
The only way around this is add the vbl without snap to grid such that it is slightly outside the grid lines.
with_vbl.jpg
with_vbl.jpg (56.26 KiB) Viewed 498 times
Workaround: Don't use snap to grid vbl, but there is no workaround for adjacent rooms or hallways with an intervening wall. All squares along the vbl will have this issue. In any case it's not a great workaround as adding vbl without snap to grid is cumbersome.

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: [1.7.0] canSeeToken wrong with snap to grid vbl

Post by wolph42 »

yes VBl needs to bleed into a square when snapped to grid and bleeds into upper and left (it needs to be placed *somewhere*), leaving the token only the left and up side not covered in vbl but bottom left is covered by bottom vbl so only upper left (and obviously centre) are left to see.

User avatar
wyrmwood_lives
Cave Troll
Posts: 25
Joined: Fri Nov 08, 2019 10:22 pm

Re: [1.7.0] canSeeToken wrong with snap to grid vbl

Post by wyrmwood_lives »

Can't the canSeeToken logic be written to ignore the cell boundary? This is especially important for vbl between two adjacent squares with a wall in between. VBL beside a token shouldn't "block" that token.

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: [1.7.0] canSeeToken wrong with snap to grid vbl

Post by wolph42 »

wyrmwood_lives wrote:
Wed Jan 13, 2021 6:17 pm
Can't the canSeeToken logic be written to ignore the cell boundary? This is especially important for vbl between two adjacent squares with a wall in between. VBL beside a token shouldn't "block" that token.
I wouldnt take into account that logic as there are most likely permutations to take into account I don't see right away, but not looking at the actualy corner but a few pixels inwards might be a solution... then again different grid resolutions might influence the thickness of the vbl lines vs the resolution of the token, so you would have to take that into account. and of course there might be applications used by users who use this quirk so thats something. and useing grid offset might also be an influencing factor changing the logic and probably another 25 factors...

User avatar
wyrmwood_lives
Cave Troll
Posts: 25
Joined: Fri Nov 08, 2019 10:22 pm

Re: [1.7.0] canSeeToken wrong with snap to grid vbl

Post by wyrmwood_lives »

Well, it can be done with a macro...

Code: Select all


[h: target = getSelected()]
[h: x = getTokenX(1, target)]
[h: y = getTokenY(1, target)]

[h: mapInfo = getInfo("map")]
[h: cellSize = json.path.read(mapInfo, "grid.['cell width']")]

[h: points = "{}"]
[h: points = json.set(points, "TOP_LEFT", json.set("{}", "x", x+1, "y", y+1))]
[h: points = json.set(points, "BOTTOM_LEFT", json.set("{}", "x", x+1, "y", y+cellSize-1))]
[h: points = json.set(points, "TOP_RIGHT", json.set("{}", "x", x+cellSize-1, "y", y+1))]
[h: points = json.set(points, "BOTTOM_RIGHT", json.set("{}", "x", x+cellSize-1, "y", y+cellSize-1))]
[h: points = json.set(points, "CENTER", json.set("{}", "x", x+cellSize/2, "y", y+cellSize/2))]
[h: strformat("<pre>%s</pre>", json.indent(points, 2))]
[h: visiblePoints = "[]"]
[h, foreach(point, points), code:{
    [x1 = json.path.read(points, point+".x")]
    [y1 = json.path.read(points, point+".y")]
    [if (isVisible(x1, y1)): visiblePoints = json.append(visiblePoints, point)]
}]
[strformat("<pre>%s</pre>", json.indent(visiblePoints, 2))]
Untitled.jpg
Untitled.jpg (54.03 KiB) Viewed 436 times

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: [1.7.0] canSeeToken wrong with snap to grid vbl

Post by aliasmask »

Well done. I would probably account for creature size as well though. Honestly, I wish this was done on the backend of the canSeeToken() function because of the VBL issue. Much faster if done in java than it is with the macroscript.

User avatar
wyrmwood_lives
Cave Troll
Posts: 25
Joined: Fri Nov 08, 2019 10:22 pm

Re: [1.7.0] canSeeToken wrong with snap to grid vbl

Post by wyrmwood_lives »

Thanks! This was just the "example" version. I will publish what I have soon, but it's very much "alpha" at this point, but because of how many of the built-ins work, I have overrides for most of them. I think in an effort to be system agnostic, Maptool really requires customization. However, that customization is pretty straight forward once you get your head around the syntax! I have also found that the wiki hasn't aged well :) Much of it is outdated or simply incorrect (the logging information for example). But, since it's a community effort, I should quit complaining and start updating it!

COVID pushed me away from FTF games and re-visting this, initially with the idea that it would only work for gms has kind of blown up! That and retrieving data from dnd5eapi This tool has grown much!

Post Reply

Return to “MapTool”