MapTool 1.3 Development Build 40

[BigO]

@BigO: Nope. It doesn't work. I impersonated the token and then ran the macro from the selection panel again. Once again it targeted the other goblin. I also tried it from the impersonate panel. It still targeted the other goblin.

Well then, I humbly stand corrected.

[jfrazierjr]

Edit: I have found that impersonate is not targeting the correct token. I click the "Goblin(24)" token and right-click->Impersonate but it is picking up the "goblin(52)" token elsewhere on the map. This explains why both the selection and impersonated panels are screwing up.

@BigO: Nope. It doesn't work. I impersonated the token and then ran the macro from the selection panel again. Once again it targeted the other goblin. I also tried it from the impersonate panel. It still targeted the other goblin.

@jfrazierjr: Yes I remember that conversation. I think this is a bad idea. We have copy/paste functionality and this is great. Indeed there are many posts in the forum saying this should be done. By copying and pasting, the GM name is incremented keeping a distinct label for the different creatures. As there are distinct names for tokens, surely we can have a targeting system in the code that requires the targeted token to agree with the selected token in both GM name and Player name. It's only an && statement for goodness sake.

As for the question of whether we should give distinct player names to all our tokens I'll give you a couple of counter-examples.

1. A crowd scene. I want 100 townsfolk tokens. I am not going to give them all unique names. I do however want to be able to run macros on the assassin hidden in the crowd who has a player name of 'passerby' just like all the others.

2. Wargaming. I want a unit of 10 space marines. Each token is identical. i have no interest in naming all of them individually, yet it is important that I be able to run macros on them all accurately.

In addition, the token I am running the macros on is called Goblin whereas the token that is getting hit with all the damage is called goblin. They are loaded from different rptok files. They have different stats, handouts and portraits. They are on entirely separate areas of the map. Now I don't want to have to remember the name of every other token I have placed on the map every time I place a new token just so that I can be sure that the macro targets the correct token. As it stands it is all very Dorian Grey (there's a minion goblin on -42hp and an invulnerable goblin in the front line).

After all that, the issue comes down to one points. Impersonate is buggy and should check both the player name and GM name of a token when it targets the token to impersonate. Currently it seems able to target entirely separate tokens, both from the right-click menu and from the selection tab.

I am with you all the way. I didn't say I like the way it was, just that I have a understanding of why it is that way. I also want all my goblins to be show to the players as goblin, regardless of if it's a goblin cutter, a goblin blackblade, a goblin hexer, etc.

While I do plan to do some coding, I have no intention(no matter how much I might want to!!) to touch the code that is causing this "problem" in the near future. There is just way to much possibility for totally screwing up the whole impersonation system if someone who does not have a good understanding of how it works makes such a change. It may very well be as simple as checking both names, but I rather doubt it based on the little I have looked at the code and what Ryss has said in the past and I just would not feel comfortable with what might be a simple change to take the risk of destroying one of the application's main features.

[torstan]

I entirely agree! It's definitely a non-trivial problem.

With a little more testing it gets stranger and stranger. Currently I have Goblin(24) impersonated. In the impersonate window I have the correct image for Goblin(24) and the correct names. However, in the chat window, if I type, it says "Goblin: <text>" - so the correct capitalisation. However, the token image is of goblin, not Goblin. Also, if I type into chat:

Code: Select all

I have {CurrHp} hit points left

it goes and gets hold of goblin(52)'s hit points rather than Goblin(24)'s, even though the name it throws to chat is Goblin not goblin.

Whew, I hope you're still with me.

Now if I run a macro on the token, using the impersonate window then the text comes into chat as "goblin: <macro output>". Note that here it is being honest about the goblin in question in the name. If I do it on the right-click menu of Goblin(24) it also targets goblin(52). Now whatever we might think about individual names, I would hope that a right-click menu on a token would affect that token and no other.

Now how about this. A player renames his token "Dragon" while the DM is not watching and then types

Code: Select all

<!-- [CurrHp=5] -->

before changing his name back to normal again. I don't know if that would work (can't test player behaviour on here as I can't set up a server at work) but if it does then it's pretty broken.

[BigO]

With a little more testing it gets stranger and stranger. Currently I have Goblin(24) impersonated. In the impersonate window I have the correct image for Goblin(24) and the correct names. However, in the chat window, if I type, it says "Goblin: <text>" - so the correct capitalisation. However, the token image is of goblin, not Goblin. Also, if I type into chat:

Code: Select all

I have {CurrHp} hit points left

it goes and gets hold of goblin(52)'s hit points rather than Goblin(24)'s, even though the name it throws to chat is Goblin not goblin.

Does goblin 52 happen to be the one with the highest number? If you add ten more does that same behavior start happening to goblin(62)?

[torstan]

Nope, there is a goblin(53) who was getting off lightly until I changed the name of goblin(52) to beatingStick(52), at which point goblin(53) suddenly became the target - without me changing anything else - which means it's definitely the way impersonation is using the player name.

Note, goblin(53) was always there, but it was goblin(52) that was getting hit.

Edit: Just threw a whole load more goblins at the map - all the way up to goblin(72) - in different locations around the centre of the action and the macros still seek out goblin(52).

I also just changed my player's token to goblin (note - no server running so it's not a full test) and hit him for damage. Once again, goblin(52) takes the beating.

[jfrazierjr]

With a little more testing it gets stranger and stranger. Currently I have Goblin(24) impersonated. In the impersonate window I have the correct image for Goblin(24) and the correct names. However, in the chat window, if I type, it says "Goblin: <text>" - so the correct capitalisation. However, the token image is of goblin, not Goblin. Also, if I type into chat:

Code: Select all

I have {CurrHp} hit points left

it goes and gets hold of goblin(52)'s hit points rather than Goblin(24)'s, even though the name it throws to chat is Goblin not goblin.

Does goblin 52 happen to be the one with the highest number? If you add ten more does that same behavior start happening to goblin(62)?

I don't think that matters. What I believe it does is looks through the token list, finds the first token with the matching name, and then gets that tokens GUID. I may be wrong as it's been a few weeks since I looked at that code, but I think that's it.

[jfrazierjr]

Now if I run a macro on the token, using the impersonate window then the text comes into chat as "goblin: <macro>". Note that here it is being honest about the goblin in question in the name. If I do it on the right-click menu of Goblin(24) it also targets goblin(52). Now whatever we might think about individual names, I would hope that a right-click menu on a token would affect that token and no other.

Nope. What I think happens, even on the right click menu is that it finds the token name in the tokenlist and gets the GUI, impersonates said token, executes the macro, and then un impersonates the macro IF it was not already impersonated.... not 100% sure on that though. Easy to check.. run a rightclick macro and in the chat window up arrow and see if there is an /im blah there...

[jfrazierjr]

Nope, there is a goblin(53) who was getting off lightly until I changed the name of goblin(52) to beatingStick(52), at which point goblin(53) suddenly became the target - without me changing anything else - which means it's definitely the way impersonation is using the player name.

Note, goblin(53) was always there, but it was goblin(52) that was getting hit.

Edit: Just threw a whole load more goblins at the map - all the way up to goblin(72) - in different locations around the centre of the action and the macros still seek out goblin(52).

I also just changed my player's token to goblin (note - no server running so it's not a full test) and hit him for damage. Once again, goblin(52) takes the beating.

WARNING: CODESPEAK BELOW!

Yes, I would expect it to be based on the load order of the goblins on the screen. As I said, the /im stuff just gets the token list and interates over it till it finds a match. Of the top of my head, I don't know if this is an array/arraylist(order sensitive) or a map (random place inserts). I would probably expect it's an array list and new token are just added to the end of the "stack".

[Brigand]

I'm really starting to think we need some kind of pseudo-scripting ability in macros for targeting and a user definable asset tag for tokens and other objects on the map.

NWN had a very good system and it'd be a good one to copy.

[torstan]

Okay. I did a test and yes, right-click uses /im.

So there are a few things to come out of this.

• /im is not case-sensitive

• /im only uses the player name of a token
  • I've argued as to why I think this is a really bad idea, but I can see why this would be a coding nightmare to fix

• Copying and pasting tokens without changing their names will break macros that use/modify properties

This also answers my question about players running tokens on monsters. As long as 'Restricted Player Impersonation' is ticked, this should stop players modifying monsters by changing their token name.

So it's at least as much of a feature as a bug and winds up with me asking for /im to be clever enough to look at the GM name as well when it is used implicitly in the right-click menu, macro panels and so on.

[jfrazierjr]

Okay. I did a test and yes, right-click uses /im.

So there are a few things to come out of this.

• /im is not case-sensitive

• /im only uses the player name of a token
  • I've argued as to why I think this is a really bad idea, but I can see why this would be a coding nightmare to fix

• Copying and pasting tokens without changing their names will break macros that use/modify properties

This also answers my question about players running tokens on monsters. As long as 'Restricted Player Impersonation' is ticked, this should stop players modifying monsters by changing their token name.

So it's at least as much of a feature as a bug and winds up with me asking for /im to be clever enough to look at the GM name as well when it is used implicitly in the right-click menu, macro panels and so on.

Yep, I forgot this earlier, but the macro code usually checks for ownership to make sure that you can't run a token on something you don't own. This is one of the "problems" surrounding how to get a "targeting" system to work and why it is not as easy as saying "everything selected is my target, just run the macro". Though it would be a good feature to have,
I would be just as happy to have a "roll this expression x times" with a prompt and me still have to manually update any non owned token properties in some way (macro). Perhaps a good side benefit is selection based targeting WITHOUT selection modification. For example, if using Kniza's proposal(as implemented by Mr. Pokeylope) for multiple rolls:

[C:targets."target.Name takes damage: " + (1d8 + str + dex + end) + "<br>"]

where SELECTION starts a loop on selected elements and prints out something like:

Goblin 1 takes damage: 9
Goblin 7 takes damage: 3
Goblin 12 takes damage: 12

The loop is already there in the design of this feature, the question comes to can it be pulled from the count of selected elements or not and then can the current one's name be pulled out and printed to chat.

Oh... this is the other place where having unique names is good, because if they are all Goblin, then how does the DM know which one took which damage. For me as a player of ranged people, the one with the highest damage output would always hit the closes melee enemy. Lucky me, eh????

[BigO]

Oh... this is the other place where having unique names is good, because if they are all Goblin, then how does the DM know which one took which damage.

Health meter states?

[torstan]

Have it output the GM name in the GM chat.

It used to be the case that every token had a numeric identifier that showed up when you pressed the up arrow to look at a macro that had recently been run through the right-click menu. This was (as I understand it) entirely independent of changes to token name and gave a unique identifier for every token.

Given the tendency of players to screw with their tokens, I would say that having identifier for each token that can't be changed is a good idea. Every time a token needs to be identified behind the scenes this should be the identifier that is called. As I understand it, this was how it used to work. I have no idea why this changed.

However I am not really a coder so I'll just stick to asking that if I right-click a token and go to a menu option, that the menu option in question (/im, macro or whatever) target the token that I'm clicking, independent of the names of other tokens on the map.

(Just thought of another case. Say I have a dragon called Dragon on the map, and a player who has decided for fun to rename their character Dragon. Now when I run a macro on the NPC Dragon there is a chance it will actually target the player's token - because as GM I implicitly have /im access to all tokens. That's surely a bad idea.)

[applekor]

/im only uses the player name of a token
I've argued as to why I think this is a really bad idea, but I can see why this would be a coding nightmare to fix

Heh. Ah yes, the identification issue that just won't die. The last time this came up, Ryss was posting macro button patches like a madman. This is the reason why I was making up my own explicitimpersonate macro at the time. Any of the new stuff I've been working on for my own purposes, I've been using explicit token identification methods instead of the typical /im or name matching.

I would still argue that a refactoring of the code for the next minor revision (i.e. 1.4) should include a revamping of key elements in the system to use explicit identification instead of the current name resolution scheme. Obviously we can't entirely get rid of name resolution since it still has value in the /im command, but disambiguation wherever else possible would be a great help.

[jfrazierjr]

Oh... this is the other place where having unique names is good, because if they are all Goblin, then how does the DM know which one took which damage.

Health meter states?

Cept you don't know which one to "target" to apply the damage to. If it were all taken care of automatically, then yea, who cares. But if the GM has to read the chat window and do that stuff manually, he would need a unique individual.