MapTool 1.3 Development Build 53

[jfrazierjr]

Not a bug... don't do that. All tokens need unique names, especially if your going to be doing some macro stuff. There is also a practical aspect to this. Imagine you have player targeting, how do you know which one is which if they all have the same name???

I'm not selecting a token from a list (as you would be in a targeting scenario perhaps), I'm running a macro that lives on the token itself. I've clicked "apply to token" or whatever in the macro. When I run a macro on a token, I expect it to affect that token regardless of it's name.

I am not trying to be a butt here, but the above is immaterial. Internally, the tokens are stored by name, you try to get by name, you get the one on the top of the list every time, it has no clue that there might be 1 or 1000 with the same name and need to treat them separately. There has been some talk about this before (I made the exact same mistake 9 months ago). Again, the end result is that the macros have ZERO context as to which specific token was run other than the name and if the name is duplicated, then you will pretty much have every macro act on the first token of that name.

My statement however was specifically and directly referencing IF you (as some people do, like myself for example) allow your players to get a drop down box that let's them select the target they want to put the attack against. Again, while this may annoy some people, there is a VERY practical purpose for not changing this behavior, because then those who target creatures would have no clue which one is which if they all have the same name. Yes, we can now filter by range, but what if they are all the same range, etc?

It doesn't say "apply to the first instance of a token with the same name as the currently selected token" it says (something along the lines of) "apply to the currently selected token".

It can be worked around of course, but there's the issue of players seeing Beast 1 and assuming there must be a Beast 2, etc. somewhere.

Then turn on random naming and warn them not to meta game, say for example if they see beast 45, does not mean there are at least 44 other beasts. Alternatly, just give them all unique names(I assume you don't have a totally different image for each creature of the same type??? )

[cubeblue]

I understand, in a programmatic sense, why the macros do what they do. I'm saying the implementation is flawed. The end result is counter-intuitive and only makes sense from the perspective of the program, not the user. I argue that it appears to function different than intended, or at the very least, as is labeled.

I love this program, and this is minor quibble, so I'm only responding because I don't think you understand quite what I'm driving at. It's a subtle difference, and as long as it's being debated, I believe there's a better way it could work (eventually, somewhere down the road).

Do you see the "false advertising" implicit in the following scenario?:

When macro is run, if it is marked as "apply to the currently selected token", the macro-code must be going through this sort of process:

Code: Select all

OK, I apply these effects to the currently selected token.  
The name of the currently selected token is "Beast".  
OK, let's look through all the tokens in this campaign/map and find "Beast", then lets get a reference to that token object.  
OK, I found it (Beast [1]), now I apply the effects to this token".

If "apply to currently selected token" is checked, then shouldn't it actually do this instead?:

Code: Select all

OK, I apply these effects to currently selected  token.
I grab a reference to the currently selected token object (regardless of any of its names).
Now I apply the effects to this token.

Do you see the difference in what's implied and what happens? Which makes more sense to the user? Which is a programmatic short-cut (and probably due to macros and scripting having been implemented in a blitz over the last many builds).

I'm not criticizing, I'm not saying I could do better. I'm just trying to argue that of the two ways presented here, one makes more sense in the long run.

I can see how it easily could have emerged naturally in the code, especially in the way Trevor and others have been pushing through so many innovative and cool features at a breakneck pace. I'll certainly work around it, and it's not a big deal at all. I'm so happy to have such a functional software suite that is system and rules agnostic, user friendly, attractively designed, and free.

[Veggiesama]

Do what I do. Give all your baddies unique names ("Rover", "Donald", "Arakathosaklamaktoplagon") and give the same type of enemy the same token picture and label ("Human Guard" or whatever).

[Rumble]

Perhaps this could be circumvented with a warning of some sort, like when you try to give a file the same name as an existing file.

"Warning: There is already a token named (Name) on this map. Having multiple tokens with the same name may cause macros to behave unpredictably. Are you sure you want to do this?"

[jfrazierjr]

...snip...

Oh.. I don't disagree with your logic at all, as I said, I fell in the the EXACT same trap 9 months ago (LONG before the "apply to the currently selected token" checkbox was even a glimmer of a feature in someone's(Lindharin????) head). Unfortunately, as we have both found out the hard way, it does not work like that.

Also unfortunately, said requirement for a unique name for each token is actually a godsend now with being able to use getTokens() function to build a list of targets, so I hope it is NOT changed.

[cubeblue]

Perhaps this could be circumvented with a warning of some sort, like when you try to give a file the same name as an existing file.

"Warning: There is already a token named (Name) on this map. Having multiple tokens with the same name may cause macros to behave unpredictably. Are you sure you want to do this?"

Yeah, maybe that would help other players. I don't know. I think eventually the "apply to selected token" macros should simply grab a reference to the currently selected token (it seems like that should actually be easier to code, but not having seen how the references are tracked I can't be sure).

In the meantime it may be best to simply document it clearly. Maybe put in a little blurb in the macro section to highlight this behavior.

An alternative would be to change the "apply to currently selected token" verbiage to something more accurate, but I'm sure "apply to the first token with the name of the currently selected token" would be more confusing for just about everyone

[Rumble]

Perhaps this could be circumvented with a warning of some sort, like when you try to give a file the same name as an existing file.

"Warning: There is already a token named (Name) on this map. Having multiple tokens with the same name may cause macros to behave unpredictably. Are you sure you want to do this?"

Yeah, maybe that would help other players. I don't know. I think eventually the "apply to selected token" macros should simply grab a reference to the currently selected token (it seems like that should actually be easier to code, but not having seen how the references are tracked I can't be sure).

I don't know how it works either; I had assumed that it worked off of the token ID, but I suppose not. In any case, for now, it's a "Stop Doing That" workaround. There are a few of those in there, each of which (except this one, I think) has nailed me.

[cubeblue]

Also unfortunately, said requirement for a unique name for each token is actually a godsend now with being able to use getTokens() function to build a list of targets, so I hope it is NOT changed.

Ah, OK. So, basically, if the functionality were changed, people would be encouraged to use non-unique names and the getTokens() function would be less useful in said games.

Perhaps then all names should be forced unique. If you try to name something the same way, you'll get an error (or a warning at the least). If we're ever going to have targeting of this sort, it will be necessary anyways, as you've pointed out.

I'm sort of waiting for the day when I can click on a PC token, then right-click, select "set as target" on another token, and then that targeted token is the current PC's target. Then in macros I can simply refer to something like getTargetToken(), etc. There would need to be a keyboard shortcut for this too, since right-click and select within such a large context menu would be a slow process.

[jfrazierjr]

I'm sort of waiting for the day when I can click on a PC token, then right-click, select "set as target" on another token, and then that targeted token is the current PC's target. Then in macros I can simply refer to something like getTargetToken(), etc. There would need to be a keyboard shortcut for this too, since right-click and select within such a large context menu would be a slow process.

Again, not trying to be argumentative, but... This approach may work for simple situations, but what if (as happens frequently in the games I play at least) you have different bonuses and penalties to hit different selected targets. Now, some of these (range perhaps) could be auto calculated since that's something a macro function can expose), but not all of them are so cut an dried. Example, I am targeting 6 orcs:

Orc1 is normal
Orc2 I have flanking on and get a +2 to hit
Orc3 is in cover so I get -2 to hit
Orc4 has total concealment so I have -5 to hit
Orc5 is a sworn target (marked, etc) and I have a +3 to hit
Orc6 was just hit by my Ally Foo which gives me a +1 to hit him until my allies turn again.

Now, macros can program around some of this, but not all (flanking is the big one I am thinking of as being hard/impossible to macro up). However, programming all those rules into the macro code and remembering all of them during the programming is just a heck of a lot of work. I have no problem with people who want to use selection based targeting, but personally, I highly doubt that I will ever get to a point where it will work for me and I just prefer explicit selection and mods using an input() field. BTW, I was originally against using popup boxes to input mods UNTIL it became possible to use list boxes to select targets, but now I am 100% the other way.

[Rumble]

I think looking at this from the ability to do certain macro things - like getTokens() or targeting - is focusing too much on one thing, while the problem is general: many, if not all, macros will behave unpredictably if there are tokens with identical names on the map and the macro performs operations based on the properties of those tokens.

I agree that when the checkbox says "Apply to Selected Tokens," it is perfectly reasonable to expect that it will work only on the selected tokens, no matter if there's another token over there that has the same name. In fact, I'm surprised that it does not (I had assumed it worked with token ID's rather than token names).

I also agree that it's probably a good idea in general to have unique token names, just for the sake of ease of use (even if you never target a token, it's nice for a player to say / chat "I want to hit Monster 1" instead of "I want to hit the Monster located at grid coordinates 3,7" or "the one up above, two spaces left, and right beneath that gray thing").

My point being that if MapTool won't always behave properly with non-unique names, I think it's worth changing MapTool in one of two ways. Either a) make it so that it will behave properly with non-unique tokens, or b) warn users that non-unique naming poses some problems with macros, and if they want to use macros, they will need to use unique names.

[Brigand]

Take a cue from Neverwinter Nights. Bastardize the GM Name into a Reference Tag. This is what needs to happen.

1. Name = Display Name, is not used for targeting or anything at all other than display.
2. GM Name = Tag, this is used for all token id's and must be unique. Don't even allow them to have the same tag.

[Cweord]

This may have been mentioned before, there are so many posts these days I loose track.

Just been playing with light to help some one out, and I had a though.

How hard would it be to have an NPC version of vision, that only the GM could see - this would make it easyer to tell if your NPCs could see the players . . . . .

[trevor]

This may have been mentioned before, there are so many posts these days I loose track.

Just been playing with light to help some one out, and I had a though.

How hard would it be to have an NPC version of vision, that only the GM could see - this would make it easyer to tell if your NPCs could see the players . . . . .

This is something I'm working on fixing up

[cubeblue]

On jfrazierjr's suggestion I went in and selected "random two-digit" numbering on duplicate tokens, but when I copy and paste a token, it still gets an incremental digit. So Beast 1 copied and pasted becomes Beast 2, etc. Is this a bug?

[cubeblue]

Again, not trying to be argumentative, but... This approach may work for simple situations, but what if (as happens frequently in the games I play at least) you have different bonuses and penalties to hit different selected targets. Now, some of these (range perhaps) could be auto calculated since that's something a macro function can expose), but not all of them are so cut an dried.

Yeah, you're right. There are a lot of concerns that come into play with targeting in general. And what about area of effect macros? I use a power that hits multiple targets, but does different things based on each one's location, status, etc.

I'm not planning on upping my own macros to account for targeting anytime in the near future. For now, all of my macros simply state the facts/rolled totals of the attack/dmg rolls and the players must make a determination whether the attack hit or not based on the target(s)'s defense.