[Bug report] getTokens & npc/pc condition

[JamzTheMan]

OK, after banging my head, discovered what looks to be a bug in the "conditions" parameter for Wiki: getTokens().

The following "conditions" only seem to work for tokens on the Token layer:

npc - If the token must be a NPC, set to true(1) or false(0).
pc - If the token must be a PC, set to true(1) or false(0).

Although, Wiki: isPC() and Wiki: isNPC() seem to work fine regardless of layer. Can anyone else confirm this behavior?

[wolph42]

Might be as intended, although I'll agree that's it's not something I would want. I can't test as I'm mobile these days.

[Azhrei]

That might be on purpose. Tokens on the OBJECT layer were originally called "stamps" and tokens on the BACKGROUND layer were referred to as "maps" or "stamps". So using the term "token" (or its attendant PC and NPC terms) might be viewed as a non-sequitor.

The source code might shed some light on this, but then again it might not.

[JamzTheMan]

I can't see any reason why you would want/need this though. Especially for hidden layer. Heck, you may even have, say, animated objects or gargoyles on the object layer so it's not obvious to the players.

Specifically I needed to work with NPC tokens that are "dead" and moved to the object layer (to get out of the way).

My thought is, if isNPC() and isPC() work on those layers, this should as well?

[Full Bleed]

My thought is, if isNPC() and isPC() work on those layers, this should as well?

I agree.

[Lee]

I thought I'd give an answer to this on my quick drive thru. From what I've seen, turning tokens into stamps when moved out of the token layer or having stamps in general prevents the triggering of token "hooks" such as onTokenMove. Honestly, it has come in handy when rearranging stuff in the other layers when there is an active session going on and a coded oTM exists.

[JamzTheMan]

I guess I'm ok with "hooks" so much as it hasn't given me a problem. But looking for tokens/stamps for macro use based on criteria should not be restricted. What if you have some ship to ship battle? You have PC ships and NPC ships, you have the ships on the object layer so you can move the tokens around more freely. But then the kraken comes and attacks all the PC ships?

Heck, in this case, I suppose OTM of moving the ships through the water would be needed so you could also detect and move the tokens with it and check for minefields.

[wolph42]

I agree with Jamz, hooks only working on token and hidden is ok. Functions however in which you can explicitly state which layer they should act on and for which 'properties' the tokens have should act on those layers and properties. Moreover, the fact that it also does not work for hidden layer means its effectively a bug.

[Lee]

@Jamz: From what I recall, how an object is determined either as a token or stamp is by looking at which layer it is on; hence, a token is only a token on the Token layer and a stamp anywhere else. Design-wise, it makes a lot of sense if we consider that it is likely that the bulk of MT users aren't script savvy, but even if he/she were, looking at the overview of the MT's token-centric design, operations/functions/etc should only interact with objects when they are tokens, and the easiest way to delineate what is a token and what is not is by layer segregation.

If it weren't so, there would have to be a means by which each created/copied/dropped object is tagged as a token or a stamp. Off the top of my head, there will always be a manual operation involved somewhere, even if, by default, everything put on the map is a token (i.e. we wanted a stamp/background instead). That would be an inelegant process as compared to differentiating by layer location, IMO.

From what I recall going through that part of the code, it seemed unfinished. Token related processes were relatively complete, but the other layers looked to be earmarked for added features, evidenced by the author(s) putting in code to track collections of objects per layer. If it were me, I'd find that useful for features such as object collision, movement blocking, etc. not to mention if a scripter were to work with a smaller set of objects (instead of what we currently do by taking all tokens and filtering this collection), macro execution speed will likely improve.

@wolph Again, looking at the design, I don't think objects are supposed to be tokens even on the hidden layer. I believe adopters without any programming savvy will find less pitfalls if things remain as they are.

The ideal end would be finishing the designed intent, which is highly unlikely in the official code, or to break the design to satisfy desired features. All in all, I'm for either; any info/opinion I gave here is just my 2 cents, so do take it with a grain of salt.

[wolph42]

@Lee. Its not often, but this time I have to (strongly) disagree. In cases where its ambiguous, or better said: there is no filter, like with 'onTokenMove' I agree. After all you cannot choose which layers are effected by ontokenmove and which not, so the choice has to be made for you and in that case I agree that object and background are left out (not sure about hidden).

However in case there IS a filter I do not want some 'hidden' filter in addition that thwarts my script.
If I script:

Code: Select all

 'get me ALL tokens from Object layer that are set to PC and have the state Dead' 

as Wiki: getTokens() exactly allows me to ask for, I do not expect some hidden filter ignoring the PC part of my code. If I would have wanted that I would have simple coded:

Code: Select all

'get me ALL tokens from Object layer that have the state Dead'

Since the script ALLOWS these filters it should not IGNORE them later on. This makes absolutely no sense and it *will* cause confusion, just like it does now.

What you are aiming at IS already in the code: if I were to simply run

Code: Select all

'get me all tokens that are set to PC and have the state Dead'

in other words, I do not set the layer, then automatically ONLY the token layer is accessed. This is exactly what you described and I agree with you that it should do it that way. But NOT if I tell it to do it differently.

So to conclude:
- If no filters are set by the scripter I agree that it should only return TOKEN layer tokens.
- If however layer filters ARE set by the scripter they should ALWAYS be executed and not be ignored. Anything that remains ambiguous (no filter is set) should be dealt with as logical as possible (which I believe it currently does, with the exception of the OP)

[CoveredInFish]

Since the script ALLOWS these filters it should not IGNORE them later on. This makes absolutely no sense and it *will* cause confusion, just like it does now.
[...]
[if] I do not set the layer, then automatically ONLY the token layer is accessed. This is exactly what you described and I agree with you that it should do it that way. But NOT if I tell it to do it differently.

+1, I agree totally.

[JamzTheMan]

Also, given the fact that the wiki does not state this as a limitation, it only confused me more when it didn't work.

But alas my PC died in the storm yesterday so i can't look into it.

I think for 2.0 the intent was to allow more layers and be able to define the behavior of those layers. That would help define tokens vs stamps.

[Azhrei]

However in case there IS a filter I do not want some 'hidden' filter in addition that thwarts my script.

I agree with this. If a filter has been explicitly stated, then any implied filters should be turned off. THis let's the programmer do what they need to do, even if it is inconsistent with normal usage.

I'll look into implementing it like this.

[wolph42]

However in case there IS a filter I do not want some 'hidden' filter in addition that thwarts my script.

I agree with this. If a filter has been explicitly stated, then any implied filters should be turned off. THis let's the programmer do what they need to do, even if it is inconsistent with normal usage.

I'll look into implementing it like this.

thnx!!

[Azhrei]

I've made the change. Apparently back in b77 the layer was added as a searchable field, but some of the other filters (like NPC, PC, and EXPOSED) did not have their layer checks properly modified.

The fix was added as rev 5974. Note that a new error message has been added to the English translation to future-proof a couple checks, so other languages will need their translations updated.