Script node & expression evaluation order problem

[ggladstone]

Has anyone noticed a problem where a script node set to execute on open/close as a 'before' script actually evaluates AFTER expressions in the scene?

What I'm doing is declaring a global procedure in my script node. I then have an expression in my scene that calls that procedure. I've noticed that whenever I start a new instance of maya and load the scene an error is reported after the scene is read associated with the expression indicating that the procedure the expression is calling is not defined. However at this point, if the time slider is advanced, or if the procedure is called manually through the command line it works fine. In other words upon scene load it seems the script node that declares the procedure is getting executed AFTER the expression in the scene that needs to call the procedure.

Call me nuts, but I would expect the script node to evaluate before any expressions (script node is set to open/close as a 'before' script).

This ends up causing a real problem if the scene is saved with the time slider at a frame that you would later like to render through mayabatch. Because if you saved the scene with the time slider at frame 10, then when you go to render frame 10 the expressions fail to evaluate correctly affecting your render accordingly.

My current work-around is to save the scene with the time slider at a frame that's outside the range that will ever be rendered. This forces maya to actually step to a different frame when rendering assuring that the global procedure declared in the script node is available to subsequent calls via scene expressions.

Is this just a bug that sucks or is it intended to work this way?

thanks if you read this far,
greg

[joojaa]

what do you habe it set to? open/close or gui open/close or scene Config ui config...

gui open close is definetly too late...

Also you could just bundle the code in your creation expression somehow, then allow the expression to do whatever it needs at start and then change a switch that makes it behave like it did previously...

but as far a s i can tell my open/close gets evelauated before my expression!

[ggladstone]

Thanks for the response.

Just to clarify I'm dealing with scene expressions, not particle expressions. My script node is set to open/close (not GUI open/close).

You can recreate my problem pretty easily in just a few steps:

-create a script node set to 'open/close' and declare the following inside it:
global proc printStuff()
{
print "STUFFn";
}

-next create a scene expression that simply calls that procedure:
printStuff();

-now save your scene, quit/restart maya, and load the scene.

Immediately after the scene is read if you look at the output in the script editor winodw you should observe an error that the procedure being called in the scene expression is undefined. To me this indicates that the scene expression was evaluated before the script node. Of course if you advance a frame then the error goes away and the call to the procedure works.

I'd be interested to know if anyone can canfirm this behavior.

Thanks again,
greg

[joojaa]

aaah yeees... but declaring a procedure is probebly defeered till maya has enough time... Expressions sdhouldnt in general depend on mel routines or youll grow hottibly slow.

A better way would be to make a project mel directory and dump the mel there.

[ggladstone]

The speed of calling procedures in expressions in our case is barely measurable. I agree that lots of mel routines in expressions is a slow way to do things in general. Though it's a relatively fast and flexible way to prototype the proccess before commiting it all to a plug-in.

Thanks again for your input!

[joojaa]

I know.

Well yes but sourcing a script first time might take some time... wich can be a source of your problem.

what i would do is make the script source itself! or put the mel in a file in wichway it gets sourced at correct time.

[kerm52]

Do you know about the evalDefferred command?

Basically here is what happens:
When you run mel, it has to get interpereted and checked for errors before it is executed. This means if you call a procedure inside the same script that defined it, maya may return an error. When you use evalDeferred, maya waits until the next idle time to try and evaluate that code. This can get you out of quite a few unexplainable problems.