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.
Bug(?): getTokens and docked MT panels [MT 1.86 and1.87]
Moderators: dorpond, trevor, Azhrei, giliath, jay, Mr.Ice
Re: Bug(?): getTokens and docked MT panels [MT 1.86 and1.87]
That sounds pretty bad. I'll test that out.
Downloads:
- Notepad++ MapTool addon
- RPEdit details (v1.3)
- Coding Tips: Modularity and Design
- Videos: Macro Writing Tools
Re: Bug(?): getTokens and docked MT panels [MT 1.86 and1.87]
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.
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.
Downloads:
- Notepad++ MapTool addon
- RPEdit details (v1.3)
- Coding Tips: Modularity and Design
- Videos: Macro Writing Tools
Re: Bug(?): getTokens and docked MT panels [MT 1.86 and1.87]
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 Thanks again
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 Thanks again
My stuff for the community:
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
Re: Bug(?): getTokens and docked MT panels [MT 1.86 and1.87]
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:
A dock reduces the visible area of the map display pane. Slide-out and floated panels don't, though.
Code: Select all
case VISIBLE:
for (GUID id : zoneRenderer.getVisibleTokenSet()) {
tokenList.add(zone.getToken(id));
}
Re: Bug(?): getTokens and docked MT panels [MT 1.86 and1.87]
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.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.
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.
Downloads:
- Notepad++ MapTool addon
- RPEdit details (v1.3)
- Coding Tips: Modularity and Design
- Videos: Macro Writing Tools
- 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]
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)
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)
Re: Bug(?): getTokens and docked MT panels [MT 1.86 and1.87]
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.
My stuff for the community:
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
- jfrazierjr
- Deity
- Posts: 5176
- Joined: Tue Sep 11, 2007 7:31 pm
Re: Bug(?): getTokens and docked MT panels [MT 1.86 and1.87]
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...."
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..
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..