tm
fm
sm
mm
If a user property is set equal to any of these, when using the getUserProp funcition the return is always 0f. The class of the return is Time.
Looks like this has something to do with Frames, Time, etc.
Stev
This is surprising, but it looks like the conversion of the value really assumes the actual digits are missing and you are specifying minutes, seconds, frames and ticks here.
t = tick
f = frame
s = second
m = minute
0s0m –> 0f
1m1f –> 1801f (1 min = 60 sec. * 30 fps = 1800f + 1f = 1801f)
2f100t –> 2.625f
and so on. In your case, it looks like the parser assumes you meant 0t 0f 0s and 0m and always converts the value to a 0 frames time.
This is probably because GetUserProp tries to read a string and figure out what MAXScript value it could be. If it cannot convert the string into a MAXScript value, it returns a string. If it finds any value class your string can be converted to, it does so.
This is why
setUserProp $ “Test” “bobo”
getUserProp $ “Test”
“bobo” –always returns a string because bobo cannot be converted to any MXS value
setUserProp $ “Test” “1”
getUserProp $ “Test”
1 –although we set it as string, we get back an integer
setUserProp $ “Test” “1m1f”
getUserProp $ “Test”
1801f –we set a string, but it IS a time signature, so it is turned into a time value
setUserProp $ “Test” “0m0f”
getUserProp $ “Test”
0f –same, the time value equals to 0 frames
setUserProp $ “Test” “mf”
getUserProp $ “Test”
0f –same without the zeros, the time value equals again to 0 frames
I think it is the GetUserProp() only. Most other methods for data retrieval return a string when they see one, including getIniSetting() and getAppData(), and it looks like Execute() has no problem converting these strings to values. The readValue() method also seems to be reading correctly from a fileStream or stringStream.
I guess it IS a bug, but I don’t know whether fixing it would break the correct reading of time values from the user props…