Object Name abstraction

[Anonymous]

I've gone through all of the...vaguely organized max script references I could find and I've hit something of a road block. How (from a max script controller) do I reference the object calling the controller script? Is it even possible?

-edit-

Let me clarify this. I don't want to explicitly define an object's name, I want it referenced as a variable.

[Anonymous]

I can't open max right now, but my guess is, what you're looking for is "dependsOn" this function works in max 2008 & 2009.
good luck.

[Steve_Curley]

DependsOn is obsolete as of Max 8 and shouldn't be used in new scripts as per the Maxscript help.

@LostSoul - maybe "This" is what you're after? Search for "local variable in scripted controllers" in the MXS help (searching for "this" doesn't work).

[Anonymous]

The max script reference to "this" is...pretty spartan and not entirely helpful, to say nothing of using a keyword search for information on a word as...frequently used as "this" is.

I'm trying to set up a float-script controller that generates a value based on two variables, one being a variable from the calling object (a quick and dirty float value hack assigned to the object), and the other is an external global variable harvested from an explicit object.name call in the script. The snag is that I'm not finding an elegant (or even simple) method of abstracting the object that is calling the script as a variable/node from which I can extract the requisite local variable.

I'm trying to create a parent/child chain system for the path constraints percentile controller. Considering that I intend for the script to be instanced across around a hundred objects, I obviously can't have every single object in the chain using its own version of the contoller script (ie each one explicitly calling itself). I don't mind redefining the parent object definition in the script since every child in the chain is going to share the same parent.

You'd think it would be far less convoluted to get something as significant as the object calling the script in the first place...

[Steve_Curley]

Yes - "this" is rather under-explained, unfortunately. If you were just talking about 2 objects then using a 3rd (probably a dummy) would be an easy alternative - just use an unused property to "host" the script, but that is not going to be practical in your situation.

Hopefully someone with more in-depth experience of MXS than I have will jump in here...

[Anonymous]

If anyone else stumbles on this thread I've been using

dependentArray = (refs.dependentNodes this)
controlledNode = dependentArray 

It's not pretty, but works on my nodes