Properties and the retention thereof

[Rumble]

Hey Craig, Trevor, or someone in the know: can you give me a short explanation of the retention of properties in a token, even if the properties aren't currently set up in the campaign in which the token is being used?

As I understand it, Campaign Properties are just those properties that are directly visible when you double-click on a token, but it is not all the properties a token has (and in fact, that's a handy thing for macro writing because you can set/get "invisible" or "hidden" properties via macro, without cluttering the visible properties window).

So, when you have a property, say, "Strength", from an older campaign or already saved on an RPTOK, and you bring it into a new campaign that has the property Strength configured, my assumption is that any new value entered for Strength will override an old one.

However, if the token has a strength value already from times gone past, and you don't override it with a default value - if you write a macro to reference "Strength," will it get the value from before, or is MapTool able to handle that gracefully?

I apologize for the poorly worded questions. The reason I ask is that I'm trying to explain this in a simple and non-panic-inducing way. I'm not sure I should bother at all, actually, but I think it's important (it reared its head while I was learning macro coding) and I'd hate to have a new user run into a mysterious problem due to the token retaining its old properties, without giving them some warning that it could happen.

[Lindharin]

In a recent build (b52-b54 I think, not sure exactly which) Craig added code that prevents macros from accessing properties that are not in the Campaign Properties, with one exception: the getProperty() and setProperty() functions.

So if a token was created in a campaign that had a campaign property of Strength (or if a property of Strength was added using setProperty()), and then brought into a new campaign (or simply changed to a different property set in the same campaign) that does not have Strength, then:

• If the user types [1d20+Strength] in chat, he'll be prompted for a value of Strength each time; it does not save it anywhere and is treated like a local variable.
• If a macro includes [1d20+Strength], he'll be prompted for a value of Strength each time; it does not save it anywhere and is treated like a local variable.
• If a macro uses [1d20+getProperty("Strength")] it will read the hidden property. And if it uses [setProperty("Strength", 2) it will override and reset that hidden property to 2.

[/list]

I believe this to be correct. Craig will need to confirm that this is correct, but I figured I might save him some time by typing it up. Then he can just say yay or nay.

[Rumble]

In a recent build (b52-b54 I think, not sure exactly which) Craig added code that prevents macros from accessing properties that are not in the Campaign Properties, with one exception: the getProperty() and setProperty() functions.

So if a token was created in a campaign that had a campaign property of Strength (or if a property of Strength was added using setProperty()), and then brought into a new campaign (or simply changed to a different property set in the same campaign) that does not have Strength, then:

• If the user types [1d20+Strength] in chat, he'll be prompted for a value of Strength each time; it does not save it anywhere and is treated like a local variable.
• If a macro includes [1d20+Strength], he'll be prompted for a value of Strength each time; it does not save it anywhere and is treated like a local variable.
• If a macro uses [1d20+getProperty("Strength")] it will read the hidden property. And if it uses [setProperty("Strength", 2) it will override and reset that hidden property to 2.

[/list]

I believe this to be correct. Craig will need to confirm that this is correct, but I figured I might save him some time by typing it up. Then he can just say yay or nay.

Cool. I vaguely recall that post by Craig (I think it was because I posted some querulous whining about how old properties were still showing up), and that's what I thought he'd done to make it so that MapTool is smart enough to only go after things in the campaign properties unless you use get/setPropert()

[Craig]

In a recent build (b52-b54 I think, not sure exactly which) Craig added code that prevents macros from accessing properties that are not in the Campaign Properties, with one exception: the getProperty() and setProperty() functions.

So if a token was created in a campaign that had a campaign property of Strength (or if a property of Strength was added using setProperty()), and then brought into a new campaign (or simply changed to a different property set in the same campaign) that does not have Strength, then:

• If the user types [1d20+Strength] in chat, he'll be prompted for a value of Strength each time; it does not save it anywhere and is treated like a local variable.
• If a macro includes [1d20+Strength], he'll be prompted for a value of Strength each time; it does not save it anywhere and is treated like a local variable.
• If a macro uses [1d20+getProperty("Strength")] it will read the hidden property. And if it uses [setProperty("Strength", 2) it will override and reset that hidden property to 2.

[/list]

I believe this to be correct. Craig will need to confirm that this is correct, but I figured I might save him some time by typing it up. Then he can just say yay or nay.

Cool. I vaguely recall that post by Craig (I think it was because I posted some querulous whining about how old properties were still showing up), and that's what I thought he'd done to make it so that MapTool is smart enough to only go after things in the campaign properties unless you use get/setPropert()

This is correct (apart from the whining ). While its nice to be able to have any property you want on your token, it becomes a problem because you never know if variables are going to interfere with it or if you are accidentally using it as a variable. So only the ones in the campaign properties for the token type are variables, all others are only useable via get/setProperty, but they are all saved.