Bug(?): getTokens and docked MT panels [MT 1.86 and1.87]

Discuss macro implementations, ask for macro help (to share your creations, see User Creations, probably either Campaign Frameworks or Drop-in Resources).

Moderators: dorpond, trevor, Azhrei, giliath, jay, Mr.Ice

Post Reply
Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Bug(?): getTokens and docked MT panels [MT 1.86 and1.87]

Post by Lee »

I've only done some testing, but something curious happens when a token get's obscured/overlaid/hidden by a docked MT panel (e.g. Selection, Impersonated etc). This only happens when Vision is enabled.

I have an attack macro that checks how much a token is within the view of an attacker. After the check is passed, I use getTokenNames/getTokens, where I pass the "visible" condition, Funnily, when I cover the target tokens involved with a docked panel, they can't be "seen" (i.e. returning an empty json array); but when I cover them completely with a floating frame, they're "seen" just fine. Furthermore, when hidden by a docked panel, if even a single pixel is visible, then the token becomes "visible".

I only discovered this by accident and was wondering if this was by design (like because docked panels reside on a certain layer), or not.

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

Re: Bug(?): getTokens and docked MT panels [MT 1.86 and1.87]

Post by aliasmask »

That sounds pretty bad. I'll test that out.

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

Re: Bug(?): getTokens and docked MT panels [MT 1.86 and1.87]

Post by aliasmask »

I know visible has nothing to do with a token being seen, per se, but the visible check box. I tested this with getVisibleTokenNames as well with the same results.

Your observations are confirmed. I usually use Wiki: getTokens(), perhaps with a radius condition or state, then loop through and use Wiki: canSeeToken() to get tokens based on vision.

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: Bug(?): getTokens and docked MT panels [MT 1.86 and1.87]

Post by Lee »

Thanks A.M. for checking in on this. I do have all those conditions and visible canSeeToken point checks in there as well. I just happened to use that Visible flag early on (when I started using MT), as a convenient status check. Code kind of grew around it, so it would require rewriting several macros to if I ever think to remove it XD

In any case, this bug is not a biggie on my end of things. I just happened upon it while working on this notebook where I had to resize/dock panels to maximize design space :lol: Thanks again :)

tiorthan
Cave Troll
Posts: 84
Joined: Fri Aug 24, 2012 8:56 am
Location: Germany
Contact:

Re: Bug(?): getTokens and docked MT panels [MT 1.86 and1.87]

Post by tiorthan »

I've just tried this but I don't think that's a bug. The visible condition on getTokens() checks visibility with the renderer. This is the relevant part of the code that does this:

Code: Select all

case VISIBLE:
    for (GUID id : zoneRenderer.getVisibleTokenSet()) {
        tokenList.add(zone.getToken(id));
    }
A dock reduces the visible area of the map display pane. Slide-out and floated panels don't, though.

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

Re: Bug(?): getTokens and docked MT panels [MT 1.86 and1.87]

Post by aliasmask »

getVisibleTokenNames() Function

This function returns a string list or JSON Array of Token:token names for the tokens that are visible to the player. The type of the value returned depends on the delimiter parameter.
I think the description, although correct probably needs more explaining. I know it invokes the thought that it will list all tokens that are able to be seen by the player, not necessarily just the tokens currently displayed on the screen. The distinction is minor, but there is one.

For example, I'm panning around my screen and I see several tokens. I stop my panning where one token that I could see is off the screen. I would think of that token as visible to the player (just not that second).

Returning visible tokens is kind of meta to the interface rather than to the token. But now that I know this I can find uses for it. An example would be I want the player to always see a specific token, so I keep making a check to see if it is visible, if not, I execute a goto command to keep the player focused on that spot.

User avatar
CoveredInFish
Demigod
Posts: 3104
Joined: Mon Jun 29, 2009 10:37 am
Location: Germany
Contact:

Re: Bug(?): getTokens and docked MT panels [MT 1.86 and1.87]

Post by CoveredInFish »

As far as I can remember getTokens() visible filter works like that since ages. I always thougt of it as expected behaviour - although the behaviour aliasmask described would be preferable.


I think that was the reason someone came up with that canSeeToken()-workaround for this.

Probably having a filter for rendered tokens (as visible is now?) isnt even that useful, although I'd vote for keeping it available if someone fixes this. Maybe by adding a new filter (onScreen or rendered or somethink alike)

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: Bug(?): getTokens and docked MT panels [MT 1.86 and1.87]

Post by Lee »

That's what I thought too (referring to A.M.'s post), or that the condition involves visibility relative from a token's perspective. Thank you for clarifying this by pointing out the code section, tiorthan. Now that I see how it was implemented, it makes sense as to why.

User avatar
jfrazierjr
Deity
Posts: 5176
Joined: Tue Sep 11, 2007 7:31 pm

Re: Bug(?): getTokens and docked MT panels [MT 1.86 and1.87]

Post by jfrazierjr »

yea.. so just throwing out my thoughts here from a code perspective and what I recall(which may be wrong)..

So, all vision stuff is boxed(or should be) based upon whats currently show on the the screen. It's a performance technique that if not implemented would make an already slow system(in some cases) significantly slower. In essence, any calculations outside the view port of whats on the screen are just ignored and not actually calculated which can greatly speed up the rendering. So, you can easily see this my having two tokens. Have one call canSeeToken() on the other(should work if you have already revealed and all that jazz). Then pan the screen so the "target" token is not in the view port and it should say "no, can't see that token".) Now, while this is not logically correct there is no way I can think of changing it to make it ever work until we have a total re-write of the vision system which of course won't happen in 1.3, so it's more a matter of "just remember this...."
I save all my Campaign Files to DropBox. Not only can I access a campaign file from pretty much any OS that will run Maptool(Win,OSX, linux), but each file is versioned, so if something goes crazy wild, I can always roll back to a previous version of the same file.

Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..

Post Reply

Return to “Macros”