Impersonating A Token

Developer discussion regarding MapTool 1.4

Moderators: Azhrei, dorpond, trevor

Forum rules
Posting now open to all registered forum users.
Post Reply
Lord_Ashes
Kobold
Posts: 15
Joined: Tue Jun 18, 2019 7:43 pm

Impersonating A Token

Post by Lord_Ashes »

I have a framework which uses a lib token for storing game properties and which has the macros for a lot of the background stuff. Typically player tokens just have macros which call macros on the lib token. In order for this to work, the token needs to be a lib token (as far as I can tell) because player tokens can only call macros on other tokens if they are a lib token. So far, so good.

Once of the macros that I have is one that allows the GM to select a player or NPC token, adjust the health, update the health bar and provide a textual description of the current life situation. We are playing a campaign where rolls are secret and only known to the GM. Players still initiate the roll (to feel more involved) but they only see that they initiated the roll and only the GM sees the results. We are doing a similar thing with HP. Players can see their and the enemy life bars but not the exact numbers. The approximate HP is indicated by the life bar and also by a description such as lightly wounded, moderately wounded, etc.

The issue that I am having is that because the macro runs on the lib token, the result (in the chat) is said by the "lib:GM" token. While this works, I would prefer to have a more nice name (like "GM" instead of "lib:GM"). I believe that in order to do this, I need to impersonate a token (e.g. create a GM token and then impersonate it) but I have not figured out how to do that.

Within the macro, I have tried:

Code: Select all

/impersonate GM [r: selection + " is now " + condition]
and

Code: Select all

[r, token("GM"): selection + " is now " + condition]
and

Code: Select all

[h: switchToken("GM")]
[r: selection + " is now " + condition]
But neither works. The first returns everything after impersonate as a string. The second and third still speaks as the lib token.

Phergus
Deity
Posts: 7112
Joined: Fri May 12, 2006 8:56 pm
Location: Middle of Nowhere, NM
Contact:

Re: Impersonating A Token

Post by Phergus »

Lord_Ashes wrote:
Thu Jun 20, 2019 7:26 am

Code: Select all

[r, token("GM"): selection + " is now " + condition]
and

Code: Select all

[h: switchToken("GM")]
[r: selection + " is now " + condition]
The token() roll option and switchToken() both just set the current Token for purposes of evaluating token properties, states and such. Which token the output is attributed to is a function of which token is impersonated.

If you have a macro named "Test" on a lib token named "lib:foo" with this:

Code: Select all

My name is [r: token.name].
And then you put a macro like this on a token:

Code: Select all

[r, macro("[email protected]:foo"):""]
The output will be from the selected token.

Or you can put the same macro code in a campaign macro and check the Apply To Selected Tokens box and it will work the same way. Select a token(s) and click on the campaign macro.

Lord_Ashes
Kobold
Posts: 15
Joined: Tue Jun 18, 2019 7:43 pm

Re: Impersonating A Token

Post by Lord_Ashes »

In my case I don't want to put it on the player tokens and/or campaign because I don't want the players to have access to the macro. The intention of the macro is for the GM to trigger it. Thus the macro is executed by GM from lib:GM but I would prefer for the corresponding chat entry to say "GM" as opposed to "lib:GM".

User avatar
aliasmask
Deity
Posts: 8580
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: Impersonating A Token

Post by aliasmask »

First line of macro:

Code: Select all

[H: abort(isGM())]
You can then put it in to the campaign window for easy access and only the GM can run it.

Phergus
Deity
Posts: 7112
Joined: Fri May 12, 2006 8:56 pm
Location: Middle of Nowhere, NM
Contact:

Re: Impersonating A Token

Post by Phergus »

It's generally a good idea to protect GM-only macros from being run by players and aliasmask's suggestion is the easiest method for that.

You can also put macros on the Global macro panel which is a bit of a misnomer. It's not global in the sense that all clients can see it. It is global in that it will always be available no matter what campaign you have loaded but is limited to your client. Your players won't be able to see them and run them.

Lord_Ashes
Kobold
Posts: 15
Joined: Tue Jun 18, 2019 7:43 pm

Re: Impersonating A Token

Post by Lord_Ashes »

Once again, thanks for the suggestion.

I resolved the impersonation issue by creating myself a GM token. This means players use their own tokens and the GM has a GM token so none of the library responses come back using the library name. This seems to work well except for the fast that I now need to add two tokens (the library and GM) to each map...not a big deal.

Phergus
Deity
Posts: 7112
Joined: Fri May 12, 2006 8:56 pm
Location: Middle of Nowhere, NM
Contact:

Re: Impersonating A Token

Post by Phergus »

You do realize that you can set macros to not be editable by players? It also keeps them from viewing them in the session.

Also if the macros on the player tokens only call UDFs from lib:tokens, they can't see anything anyways.

Already noted in a different thread but don't copy lib:tokens to multiple maps. Create one map just to hold your lib:tokens (and other stashed tokens or images) and leave that map hidden from the players.

Lord_Ashes
Kobold
Posts: 15
Joined: Tue Jun 18, 2019 7:43 pm

Re: Impersonating A Token

Post by Lord_Ashes »

Phergus wrote:
Sun Jun 23, 2019 12:53 pm
You do realize that you can set macros to not be editable by players? It also keeps them from viewing them in the session.
Yes. I move away from having the game information on the player tokens because if a player owns a token they can always look at the properties (unless they are hidden). So I moved everything to a lib token (macros and properties) so that players can't see game stats.
Phergus wrote:
Sun Jun 23, 2019 12:53 pm
Also if the macros on the player tokens only call UDFs from lib:tokens, they can't see anything anyways.
Exactly. That is why I moved the macros to the lib token. My OP issue was when the GM executed macros. Originally I was doing this from the lib token itself which was causing all visible text to appear as if said by the lib token. Later I introduced a GM token which, just like the player tokens, just calls macros on the lib token, which resolved my issue.
Phergus wrote:
Sun Jun 23, 2019 12:53 pm
Already noted in a different thread but don't copy lib:tokens to multiple maps. Create one map just to hold your lib:tokens (and other stashed tokens or images) and leave that map hidden from the players.
I'm working on that (as per other thread) but there seem to be issues. I believe the problem is that macro calls to lib tokens can access the lib token on any map but that macro is run from the map that generated the call. This means, for example, that if the lib token stores or reads properties from itself (using calls that specifically identify the lib token) the getProprty or setProperty fails because the current map does not have such a token.

User avatar
Full Bleed
Demigod
Posts: 4446
Joined: Sun Feb 25, 2007 11:53 am
Location: MD
Contact:

Re: Impersonating A Token

Post by Full Bleed »

Lord_Ashes wrote:
Sun Jun 23, 2019 7:58 pm
This means, for example, that if the lib token stores or reads properties from itself (using calls that specifically identify the lib token) the getProprty or setProperty fails because the current map does not have such a token.
If you're using Wiki: getLibProperty() and Wiki: setLibProperty() it doesn't matter where the call comes from.

The regular get and setProperty functions default to the current token.
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."

Post Reply

Return to “MapTool 1.4”