[Closed] Problem with collect in max9

This looks like a bug to me. For some reason, Max 9 is returning the user property as a long integer value of value 0L (zero) rather than the string “L” returned by Max 8. It shouldn’t affect what you’re doing, but Autodesk did introduce the new Integer64 value type in Max 9…looks like a new bug might have been created along the way.

--Max 8 Listener
getuserprop $ "SYSTEM_SIDE"
"L"
classOf (getuserprop $ "SYSTEM_SIDE")
String
 
--Max 9 Listener
getuserprop $ "SYSTEM_SIDE"
0L
classOf (getuserprop $ "SYSTEM_SIDE")
Integer64

I was able to get the results you want by changing the User Property string to “Left” and then testing for that. Its an easy workaround to suggest, but it might not be easy for you to implement…hopefully you’re not dealing with legacy content filled with “L” strings.

Hi Dan,
I love conundrums like this, so I had a crack:

for obj in objects do
 	(
 	local prop = getuserprop obj "SYSTEM_SIDE"
 	format "% : %
" prop (classof prop)
 	)
 

Reveals:

R : String
 R : String
 R : String
 0L : Integer64
 0L : Integer64
 0L : Integer64

The help topic “64 Bit Values – Double, Integer64, IntegerPtr” sheds some light:

Three new Number classes have been added to MAXScript in 3ds Max 9: Double, Integer64 and IntegerPtr
bit.hexAsInt will output a Integer64 in the input string contains an “L”, a IntegerPtr if it contains a “P”.

So if you type: bit.IntAsHex (0 as integer64) you get “0L”

So it looks like max is treating the lone “L” as an Integer64. I guess this is similar as to when you get screwy results adding 1f & 10t (tiem values) or such like.

If you change the “L” to “Left” or such like it should sort things out

Thanks Guys for the speedy response! Its part of quite a large script I have been writing for over a year, and I thought max9 was about to flush all my toil down the bog. I`m glad it can be resolved, I would never have worked out what was happening on my own.

Thanks again

Dan

Hi John,

Well my definition of a bug is something that is broken, and I wouldn’t say this is broken, more just the way it is. I just tested it in max6 (with some time values, eg 25f), and got the same result

What I’m driving at is it’s not a “new bug”, it must be just how the maxscript interpreter works (but I wouldn’t know, I’m just a scripter, not a computer scientist).

But I get your point about there not being a digit in front of the “L” or the “f” making it screwy.

Actually, I think this is new…in Max 8 getUserProp() would return “L” as the string “L”, while Max 9 returned it as the Integer64 value 0L. The behavior with time values that you’re describing has been consistent, but this change in Max 9 is something that wouldn’t bite a scripter until they upgraded to Max 9. Subsequently, a lot of legacy rigging scripts are likely to have unnecessary problems.

You’re right though…if this behavior had been consistent through the versions, I wouldn’t call it a problem either.

Well Im glad that you sorted this out for me as I use “L” for left in all my rigs. It would be nice if get user prop just returned the string if there is no number before it in all instances. 3D in general is all about work arounds isn’t it.