I was working on a script to log the unique handles of objects in the scene, so I was using primitives as a basic test:
for i in $ do
(
print i.handle
)
Fairly straightforward. The only problem is some of my test primitives were teapots, and it seems that the .handle attribute is reserved for the teapots actual handle, not its unique identifier! (You get true instead of a number).
Now, this is not a huge problem. I doubt there’s many instances where i’m going to need to keep track of a teapot primitive. I just thought it would probably make sense to keep reserved words out of basic objects.
From the mxs help:
It is safer to say $box01.inode.handle than $box01.handle. This is to prevent cases where the baseobject has property called handle, like a teapot, and you get that objects handle instead of the node handle.
cheers,
o
The only handle reference I could find was off the Interface: iNode page. I didn’t notice the big glaring neon page called Node Handles. Perhaps those two pages need to reference each other!
Thanks for the clarification ofer_z!
Ha! and here all this time I’ve been thinking to myself “I guess I’ll use inode.handle… but really what are the chances of using it on a teapot?” Wayda go and ruin my belief I was begrudingly wasting my time.
That’s actually a good idea. As you can see, this was added on Max 4 when most of the MAXScript Help got messed up in the attempt to split it into a User Manual and a Reference, with virtually everything duplicated. I am still cleaning up the mess 7 releases later.
And don’t forget the imagemap mis-link for the radiobuttons for “Max 2010 – The Year Autodesk makes Contact”.
That bugger has snuck through quite a few max releases.
I added the image maps in 2008, so it slipped through just ONE update 😈
Also, read the text on the UI that links leads too… ROTFL!
Hahaha well it feels like ages based on how many times it’s tricked me.
While this thread is completely hijacked:
It would be awesome if you did a similar “example script” for .net objects in the 2010 manual.