It's not a typing issue, it's that Token.setProperty is analogous to setRawProperty so unconditionally sets that value even if it's the default, while the MTScript and UI use a code path that checks whether the result is identical to the default and removes the value if it is.
Using getRawProperty is pretty much the only way to notice the distinction, though I suppose if you change defaults that would be another way.

Adding a Token.setRawProperty method that has the same behaviour as it currently works and a Token.setProperty that checks if it matches the default wouldn't be difficult, but like #4900 it invites the question whether there should be a version that instead of evaluating the default and comparing it against the value you set, that there should be a more light-weight version that treats the default as a value instead of an expression.

From your Discord message you're just attempting to reset the property to its default, which should have a Token.resetProperty binding, which would be easy and uncontroversial to add.

Thanks for looking into this!

Adding a Token.setRawProperty method that has the same behaviour as it currently works and a Token.setProperty that checks if it matches the default wouldn't be difficult, but like #4900 it invites the question whether there should be a version that instead of evaluating the default and comparing it against the value you set, that there should be a more light-weight version that treats the default as a value instead of an expression.

I think the paradigm you've set up in #4900 makes sense to expand into setProperty, as you've described here. To be honest the whole Raw vs. non-Raw property paradigm feels a bit kludgy to me, but I don't think it can really be modified without destroying backwards compatibility So having setProperty be the default, less irritating version seems good.

From your Discord message you're just attempting to reset the property to its default, which should have a Token.resetProperty binding, which would be easy and uncontroversial to add.

This would be good as well, but while this is my current use case I can foresee issues still arising when generally setting a value that happens to be the default - using Temp HP as an example again, would happen commonly when damaging a creature and removing all of its Temp HP.

Adding a Token.setRawProperty method that has the same behaviour as it currently works and a Token.setProperty that checks if it matches the default wouldn't be difficult, but like #4900 it invites the question whether there should be a version that instead of evaluating the default and comparing it against the value you set, that there should be a more light-weight version that treats the default as a value instead of an expression.

I think the paradigm you've set up in #4900 makes sense to expand into setProperty, as you've described here. To be honest the whole Raw vs. non-Raw property paradigm feels a bit kludgy to me, but I don't think it can really be modified without destroying backwards compatibility So having setProperty be the default, less irritating version seems good.

I'm not a fan of raw vs non-raw either, but that's because I don't like the behaviour of resetting a property if the value you set it to is the same as the default.

It means you've got to evaluate the default expression every time you set a property and you might intentionally want a value to be set to a value that happens to be the default but conceptually isn't.

e.g. If I have a Hero token type that has Strength 10, and I have a given token with Strength 10 because they started with 10, were cursed for a -1 and have a magic sword that gives +1 I would like that to still be 10 after I decide that late on in the campaign new heroes need a buff and I change the token type to have default Strength 12.

I would prefer that resetting to default were an explicit step, there is a macro function to do it and I could add a JavaScript function.
I would prefer that the API is:

• Token.setProperty - behaves as setRawProperty
• Token.getPropertyDefault - returns the value of the default
• Token.getPropertyDefaultEvaluated - evaluates the default expression and returns that value
• Token.resetProperty - removes the value from the token so it falls back to the default.

This way you could implement resetting to default however you like, without evaluating the content.

However this is a pipe dream if every time you open the token editor and save it's going to evaluate the default and remove the value if it's the same as the default.

Since that is a much wider change that'd have compatibility issues I suppose I'll settle for:

• Token.setProperty - behaves as setProperty, evaluating the default and resetting the property if the new value is the same as the default.
• Token.setRawProperty - sets the value directly without checking against the default
• Token.getPropertyDefault - returns the value of the default
• Token.getPropertyDefaultEvaluated - evaluates the default expression and returns that value
• Token.resetProperty - removes the value from the token so it falls back to the default.

Okay, now that I've actually had time to look at it, it's the Token Editor dialog that's different here.

Setting values by name in impersonation scope sets the value. The MTScript setProperty macro function sets the value in the token's property mapping the same as the new JavaScript Token.setProperty.

It's only the edit dialog that resets token property values if they equal their default.

Seems we were both wrong about how it works. Checking back through the logs it's always been the case that macros set the values directly and you need to use resetProperty if you want it to clear it to use the default, but the token editor wipes it, which doesn't seem like a useful way to work.