View Full Version : Having trouble select objects by name

01 January 2004, 12:20 AM
I'm trying to select objects by name and not array number. It seems like the following should work, but it doesn't...

bob = "box01"
select bob (or "select $bob")

But if I type in...

bob = geometry as array
select bob[1] (assuming the first object in the array is "box01")

that works.

What's the difference?

01 January 2004, 09:55 AM
Use getnodebyname. See the online reference for more info.


obj = getnodebyname "Box01"
if obj != undefined then select obj

getnodebyname returns undefined if the object doesn't exist.

Hope this helps,
- Martijn

01 January 2004, 05:23 PM
Thanks for the response. That helps. I actually did see that in the reference, but I was wondering more about why it doesn't work to just use the straight variable. Why do you have to use this workaround in the first place?

It just seems like there are expressions that seems like they should work but don't. I guess I'll have to study MS more deeply and understand why.

01 January 2004, 05:27 PM
in your example, it should look like:

bob = $box01
select bob

objects in max need '$' before their name to tell it that its an object in the scene.

The reason your array works is that you are getting all the geometry. If you had tried:
bob= box01 as array;
select bob[1]

you'd get an error.
You seem to know about the $, but you tried to put it in front of the variable, not the actual object.


01 January 2004, 06:16 PM
Bob = "Box01"
Bob now holds a string variable, not the actual scene object!
To get the object named 'Box01', use :
Bob = getNodeByName "Box01"

To store a scene object directly into a variable, use :
Bob = $Box01

or if the objects' name contains spaces, you should surround the name by single quotation marks :
Bob = $'Name with spaces'

Can't explain this very well right now, hope you understand what I mean ;)

- Martijn

01 January 2004, 10:22 PM
I think I see what you mean. It just seems strange that string can't also be considered an object name since it's using the exact same letters. But I guess there're other things going on behind the scenes that I can't see. Just something I have to accept and get on with my life. :)

01 January 2004, 04:12 AM
Originally posted by FatAssasin
I think I see what you mean. It just seems strange that string can't also be considered an object name since it's using the exact same letters. But I guess there're other things going on behind the scenes that I can't see. Just something I have to accept and get on with my life. :)

How about this - think of humans and their names.
If you call the name of a human it does not mean you are possessing that human (although some esoterics think it is like that). A string contains just letter, it is like the name on the address of a mail envelope, but not what is located at that address.

The original way of converting name strings into actual objects was

theName = "Box01"
theObject = Execute ("$'"+theName+"'")

As you can see, in this case you are building a new string containing the name inside of single quotes and prefixed by $ to denote you want to access an actual object and not just have a name tag consisting of a couple of characters.
The Execute command does the same as pressing the Enter key after a line in the Listener - it sends the characters in the string you entered to the MAXScript Parser (the "translator" of the language) which tries to figure out what you want and converts your string into a MAXScript expression.
In the above case the string looks like an object name (as it has $ before the name), so the Parser generates code that goes looking for that object in the scene database. If it finds it, it returns a node value which points at that object and assigns it to the variable theObject. (If it is unsuccessful, it just returns undefined)
Next time you reference the variable theObject, it contains a direct pointer to the desired object.

If you would try

theName = "Box01"
theObject = execute theName

you would get undefined because Execute tries to convert the string "Box01" into an expression, and because there is nothing else telling it what type of expression Box01 should be, it assumes it is a MAXScript variable. So it converts the string into a variable, then goes to peek into that variable and finds out that is is not defined yet!

But if you try

Box01 = "Look At This!"
theName = "Box01"
theObject = execute theName

you will get the result "Look At This!" stored in the variable theObject, because the user variable Box01 was already defined in the global context. (that's where execute is always... well, executed).

If you would write

theName = "Box01"
theObject = theName

then you have a string of characters assigned to a vatiable. The value of the variable is stored at some location in memory.
If you now assign the variable to the variable theObject, the value of the first variable is being copied to a new memory address corresponding to the second variable, but the actual value type does not change - it remains a string of characters.

Imagine what would happen if MAXScript would decide at this point that "Box01" suspiciously looks like a name of a scene object and would store the object instead of the string into the second variable... You wouldn't be able to do anything reasonable because your values would have their own life...

Most functions expect specific value types. Select expects a single node or a collection of nodes (never a collection of strings). So when you supply a string istead of a node value, it just complains you are not providing the right type of data.

There are some cases where types can be converted implicitly by MAXScript itself. These are described in the help, but object names and object paths do not belong to those....

Did this help?



01 January 2004, 11:37 AM

01 January 2004, 05:34 PM
Wow, thanks Bobo. That was very comprehensive and informative. It really clears things up for me. :applause:

CGTalk Moderation
01 January 2006, 11:00 AM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.