RPTools.net

I've been working on a new framework recently, and several of my macros create lots of duplicate tokens. I didn't anticipate that it wouldn't work when run by a player (rather than GM). Is there a reason that duplicate token names aren't allowed, even when being created/set via a trusted macro? I can probably work around it without too much trouble, I'm just curious.

It should be okay when done by the GM or in a trusted macro. Odds are good your macro isn't trusted even though you think it is. That happens a lot.

What is the smallest macro you can create that demonstrates the problem?

Yeah, I've had non-trusted macros creep in before, although I don't think that's the case here. I'm pretty sure every macro makes use of at least one trusted-only function. (I make heavy use of the 'id' version of getProperty, for example.) Anyways, I can try to repro this when I get home from work in a simpler environment.

Hmm, okay. I just tested this... I actually found a second problem, I think. Started a fresh copy of b82. Made two campaign macros, with 'Apply to Selected' checked. One has 'Allow Players to Edit', and the other doesn't. (Named them 'Trusted' and 'Dangerous'). They have identical bodies:



Started a server, connected with a second copy of MT as a player. I can select a token as the GM, run either macro, and get an exact duplicate token. The output from both macros indicates that the macro is trusted.

First Bug: Clearly, the 'Dangerous' macro should be returning 0 from isTrusted, right?

Second Bug: Even through the 'Trusted' macro is letting me make the second token with the same name, it still pops up the dialog telling the player that only the GM can create multiple tokens with the same name.

AFAIR every macro the GM clicks to execute is trusted. Trust is really just an issue for player clients. (Correct me if I'm wrong here!)

Sorry. I meant to clarify. Both macros indicate that they're trusted, even when being run by the connected player.

Okay, 2nd mystery solved. Campaign macros can never be changed by players, so they're always trusted, independently of that checkbox. That still leaves the original bug, which is still just as easy to reproduce. Additionally, copyToken can only be called from a trusted macro, so there is no circumstance where that warning about multiple same-named tokens should appear from doing so.

I've got a couple of other things to fix during the day today if I can get to them, so I'll add this one as well.

If this is happening it means some one has made a change that introduced a bug. If the macro is player editable and auto execute then it should be non trusted otherwise you allow the players to modify what the GM is running. If its not auto execute (it gets copied into input window only, and GM can edit before pushing return) then its trusted just as if the GM typed it in

I did some testing on this. Simple macro outputting Wiki: isTrusted() gave me this result

CiF, you should really post that in the Wiki and/or on it's own thread. Some of those conditions don't seem correct, like the line below your note.

I'll do ... but have to come back from work first, so it'll take me some hours or more likely it'll be tomorrow.

I agree.

The first group is fine since player-edit doesn't matter for Campaign macros, nor should it.

The second group is wrong since player-edit should result in Wiki: isTrusted() being 0, even when executed by the GM.

The third group should be exactly the same as the second group. AFAIK there's no difference in trust whether the token is a lib: token or not; lib: tokens simply have other features that make them useful.

The fourth group is fine for the same reason that the first group was okay.

The last group seems wrong, since a player executing code on a token they could have dropped onto the map should never be trusted. Even if they can't edit it (they could edit it elsewhere on drop it on the map) we can't trust it. Not sure about Lib: tokens -- can a player drop a Lib: token on the map? if so, they could change the macros to be non-editable, then take away ownership for themselves, thus making the Lib: token appear trusted to MT. (Side issue: should players be able to remove themselves from the ownership list? If they couldn't it would solve this particular issue.)

Players can make lib tokens, but the player editable flag can not be removed by a player only a GM. Only the GM can remove the last player from the ownership list in a token, or remove the owned by all flag if there are no players.

See http://forums.rptools.net/viewtopic.php?f=3&t=17721&p=187823#p187823 for information on those other ones that may not at first appear not to be correct.

Looks like I screwed that up with an update to the Wiki: setOwner() function a couple of builds back. It's now very careful to check the trusted state and ensuring that untrusted execution always leaves the current player's name in the ownership list.

I've found and fixed the "you must be GM" popup as well; the change is committed as revision 5631.