Can a scriptNode refer to itself?

[garyfixler]

In certain other languages I've used, I've been able to ask for something like "this" to refer to the calling environment. For example, you can type the following in the address bar in Firefox:

javascript:alert(this.location)

That pops up an alert window that tells you the location (URL) of the window you're in, because 'this' refers to the window itself, and 'location' is a property of windows. I'm looking for something like 'this' for use inside of a scriptNode. If I write a command in a scriptNode that refers to an object in the scene, then reference the whole thing in with a namespace, the scriptNode is broken, as it's looking for 'object', rather than 'namespace:object'.

If I can get a scriptNode to ask who it is, I can gather the namespace from its own name and use that in the scriptNode's script to refer properly to the object[s] with which it was referenced.

An alernative thought was to try to hook the scriptNode itself to another object with some kind of direct connection, say:

connectAttr myScriptNode.caching someObject.whatever

This would allow me to work off of a selected object - it could check to see if it has a scriptNode connected to a particular channel through that caching channel, but it still doesn't really work when setting up something like an attribute-watching scriptJob in a scriptNode, especially when you have multiple instances of the same object with various namespace names, because it still doesn't know which scriptJob is itself, and therefore which object it's supposed to work with.

I'd like to hear what others who have solved this problem have done.

I've set up things before wherein an enum attr with dropdown choices fires off a scriptJob that's been watching it, with that scriptJob set up by a scriptNode that gets namespaces and bakes them into the scriptJob by searching through objects and finding them, but that's kludgy, and it doesn't work with multiple instances of the same object.

[joojaa]

No such function available.

You can hack around this by giving the script node a string or integer attribute and then generate a randon guid and search all script nodes for that guid. However its very easy to make a custom node that does exactly what you want tough.

A word of warning: Needing this is a a bit of a problem in itself. So if you need this sort of thing then your trying to fix a bad design decision with a bad or possibly worse design decision. So at minimum it is a indication that your doing something slightly wrong, At worst its a indication that your doing something horribly wrong. Basically nodes should not need to know this.

Be specially caregfull if you find you need this a lot. Itpoints to cartain too rigid view of the problem space3 that can easily be avoided by thinking a bit broader. So while ive needed this on occasion, ive found that theres really never any sane need for this particular feature. So not having this function easily available saves you lot fo headaches down the line.

In fact no node should need this kind of ability. the connection thing on the otherhand should be built in. IMHO.

but it still doesn't really work when setting up something like an attribute-watching scriptJob in a scriptNode,
especially when you have multiple instances of the same object

ahh bingo. I spotted your problem. You think I need a to trigger on event and use scriptJob. Whereas you SHOULD be thinking expression node or custom node instead. Both of which make for a much shorter path to solve most problems of this kind.

[garyfixler]

Thanks, Joojaa,

I definitely don't need it a lot, and kind of don't want to be using it right now, but I don't know of any other way to make certain things trigger. I would like to write custom nodes, but am not a full programmer, and don't know how to do that. I should probably bite the bullet and learn that, but there is another aspect to this, and that is that by keeping it 100% within the constructs provided by MEL, the file becomes a contained unit that cannot break because of missing MEL scripts or plugins. I can send this file to anyone with this version of Maya all by itself, and it just works. With employee turnaround, too, it becomes a pain to manage what goes with what, as the people who know that a particular set of scripts helps a particular set of files leave, and no one else knows how things work anymore.

I definitely tried to find a direct-connection way to go about the couple of things I've wanted done in recent months, but couldn't solve one. For most things, the functionality doesn't need to be contained, and so I write separate tools and utilities that exist outside and work for all, but once in awhile I just want something to go with a particular file to solve one small issue where I can find no other solid alternative that doesn't require extra things in addition to the file.

All that said, I came to the same conclusion you did. I wrote a scriptNode that finds scriptNodes with a UID and modifies their scripts to know their own namespace. I realized last night that expressions don't need this, and actually, telling an expression what it's namespace was, and having it prepend it to object names caused it to fail. I would get an error message that some namespace:object did not exist, and could actually copy that name from the error message, paste it in the command line with "select" before it, and it would select the object, so clearly it did exist. I guess under the hood the expression knows what namespace it's in and secretly prepends any object names called out in the expression with that namespace, because a simple test with an expression that told locator1 to move to x=2 worked when referenced in with a namespace. ScriptNodes don't appear to understand this, though.

My usual use of scriptNodes that create scriptJobs is to occasionally add a dropdown channel for an object that allows choosing from a string list, which then fires off the scriptJob watcher (on attribute change, -ac) to do something and reset the value to the first item ('select', 'choose', etc). I've been using this here and there in game production environments for about 6 years now and it's never failed, so I'm pretty confident about it now. Most of the time I would not seek a scriptNode->scriptJob solution, however. It's just nice to have it in the bag of tricks.

I have put:

string $ns = "";

as the first line of any scriptNodes I want to have know their own namespace internally. A separate scriptNode loops through scriptNodes looking for that as a first line and changes any to read:

string $ns = "namespace:";

where "namespace" is the actual namespace name of that scriptNode. Then from inside the scriptNode, I can prepend $ns to anything. It worked well in my tests. Again, not an all-the-time solution, but a solid little trick for that occasional need. Oh, and I surround the scripts in those scriptNodes with { and } to keep the $ns variable contained to them. I'm not sure if scriptNodes are self-contained anyway, but it didn't hurt to stick those in there.

I'll add that you said there's never really any sane need - I agree! Well, I could kind of argue one thing I did was sort of sane, but you could just as easily argue against it. For me it's a cute little extra, like being able to select a character's main position node, having a "character" channel with the text "select" in the box, and being able to drop down a list of characters, choosing one, and having it flip back to "select" as well as swapping out the reference for the selected character. It's not needed - they could be kept separate, anims could be transferred, a separate tool could do this work - but the animators all loved it (not that exactly, but I've done a few similar tricks with it), and 9 months of daily use and abuse of 60+ characters with the ability never broke it, so in the end, it does seem pretty robust.

You also said the direct connection thing would be nice - also agree. I'd rather have scriptNodes work like expressions, where they know the namespace they're in and presume any objects called out in their scripts are for objects in that namespace. That would be much preferrable to what I did to solve this.

Thanks again![url]../../../users/joojaa/forums[/url]

[joojaa]

Expressions are NOT MEL

I guess under the hood the expression knows what namespace it's in and secretly
prepends any object names called out in the expression with that namespace,
because a simple test with an expression that told locator1 to move to x=2 worked
when referenced in with a namespace. ScriptNodes don't appear to understand this, though.

Alas thats not exactly how they work. They are in the neamespace so they operate in that namespace this sis why they were created to make sloppy exprssions possible. However exprssions dont need to know the names of things. In fact they do not know the names of things. it just appears to YOU when you go script time to do this. With teh expetion of times when you run mel withein iexpressions.

See theres a inetemediary compiler in place for expressions. whenever you do direct connections in exporssions ala:

object.attribute=object2.attribute*2;

the preprcessor goes and replaces this with

.I[0]=.O[0]+2;

now .I[0] is a pointer to the first input of the exprssion node and repsectovely .O[0] is the first output of said exprsssion node. Thsi is how nodes work they just see things inseide themselves. But since those are conneced to something esle they apparently see:  object.attribute and object2.attribute repectively. The data gets connverted to meaningfull text for you to see but its not stored that way. SWicne its the ndoes data it can NEVER point wrong, irrespectively of the name.

This si why storing string names is bad in expressions. even tough:

object.Attribute = 10;

and

setAttr object.Attribute 10;

Accomplish the sem thing they work differently. The first one is:

.I[X] = 10;

wheras the other really points to the string "object.Attribute". IN FACT mel has this concept of implied strings wiwch is why

print foo;

works

whereas

print hello there;

does not.

[joojaa]

Oh one more thing,

like being able to select a character's main position node, having a "character" channel with
the text "select" in the box, and being able to drop down a list of characters, choosing one,
and having it flip back to "select" as well as swapping out the reference for the selected character.

Yes however theres a natural way to do this, its called a set and a set could have done this and more without needing to know anything special, tis way you wouldnt need this script many times just oen geral purpose one that handles all yoru characters without anything extra for chars. And offcours eyou can put that script in the scriptjob or put it as part of the prpject mel folder.

(thing is maya filea are never really sekf contained. Texture files will need to get published etc so you would never submit just one file for anybody but a full project with environment in a zip file.)