So check this out. Create an object, select it, run these two lines:
setuserprop $ “testProp” “t9”
getuserprop $ “testProp”
The last line returns 0f. That’s right, it returns a time value. Seriously, WTF?
If I try to evaluate t9, it is obviously undefined. I am well aware ‘t’ denotes a time literal. But like using ‘d’ for double, etc., it comes after the number, not before. Besides, t9 is nothing, while 9t is a time value, just as d9 is nothing, and 9d would represent a double value. So, what gives?
I’m aware I can ‘get around’ this by encasing t9 in quotes (so, setuserprop $ “testProp” ““t9″”), but that is already a workaround- instead of ‘t’ as the first character, it is a ” symbol. Or I can use ‘tee9’ or something else. I’m just more curious what the hell is causing this behaviour.
“t9” gets interpreted as a time value, as you mentioned – specifically, as “0t9x” where “x” would be another time format symbol… except it’s missing, thus the 9 gets ignored and you’re left with “0t”, which evaluates as 0f.
E.g. “1f10s” is a perfectly valid time value (of 301 frames at 30fps), despite looking backwards (one would expect that to be written as “10s1f”)
As for why it evaluates to a time value at all – get/setUserProp are just lazy interfaces to the user properties buffer, which itself is a big string. It could return everything as string values and leave it up to you how to handle that string, but it was more convenient for it to try and parse the values and return something that’s sensible…99% of the time.
The fact that Max would take
setuserprop $ “testProp” “8”
getuserprop $ “testProp”
and return 8 is understandable- setting it as a string should force it to be a string, but whatever. I cannot understand what the parser is doing to interpret t9 as 0t… I’ll submit it as a bug. God I wish there were a way to replace Maxscript’s functions, sooner or later I’m going to stop using MXS’ built in functions directly in code altogether, and just call them through intermediates, though this in turn slows things down… ah well, ‘tee9’ will be his name instead.
well, near’s the parser know, the value evaluates to a number, and thus returns it as such:
"t9" as number
0f
I fully agree that setUserProp should recognize that you’re feeding it a string, and automatically stringify the result itself, though. 5 and “5” are two different things, but as far as setUserProp is concerned… they’re not %)