Problem loading mel with maya file

[aslam-hussain]

Hi this is hussain new to mel scripting, may be it is simple sorry for that. please help me with this...

I have created curve with name Pelvis_Ctrl with attribute Mirror_Pose. If i change the attr Mirror pose, set of commands need to execute. I have used Script job command to do this task. I have used Script node to parent this script to the scene file. If i execute the command it works but the problem is if i close the file and reopen the file the script doedn't work. I again needed to execute this commands. May be i was wrong with "scriptNode" command . Pls help me with this so that i d't run this scipt every time i open the file. Here we go..

scriptNode -st 1 -bs dothis;
global proc dothis()
{
scriptJob -per -cu true -ac "Pelvis_Ctrl.Mirror_Pose" "sel";
}

global proc sel()
{
print "script works";
}

dothis;

Thanks n advance...

[ldunham1]

try writing it into an expression as a start-up node with the scene. I set up something very similar at work, so will have a look and give ya a more detailed explanation.

[andrehitsoy]

You have to change the 'Execute On:' mode to 'Open/Close' (the default is 'Demand'). Then the script node should evaluate when you open the scene.

[joojaa]

yeah except iwhat your trying to do is NOT a smart thing to do, Your bining a nonattribute action to attribute and thats not really sane.

Intergate in different manner.

[andrehitsoy]

Create an enum attribute called pevisCtrl on your scriptNode.
ConnectAttr -f "Pelvis_Ctrl.message" "yourscriptNode.pelvisCtrl.

In the scriptNode have this proc:

global proc string getRigScriptNode(){
    string $scripts[] = `ls -type "script"`;
    for ($script in $scripts) {
        if (`attributeQuery -node $script -ex "pelvisCtrl"`) {
            return $script;
        }
    }
}
 
global proc string getRigNameSpace(string $script){
	string $ns = "";
	string $buffer[];
	$numTokens = `tokenize $script ":" $buffer`;
	if ($numTokens>1){
		$ns = "";
		for ($namespace in $buffer){
			$ns = $ns + $namespace + ":";
		}
	}
	return $ns;
}
 
global string $rigScriptNode;
$rigScriptNode = `getRigScriptNode`;
 
global string $rigNameSpace;
$rigNameSpace = `getRigNameSpace $rigScriptNode `;
 
string $pelvisCtrl = $rigNameSpace + "Pelvis_Ctrl";
 
global proc mirrorPose(string $rigNameSpace){
	string $sel[] = `ls -fl -sl`;
	if ($sel[0] == $rigNameSpace + "mirrorPoseTriggerCtrl"){ //
 
		DO THE MIRROR POSE STUFF HERE
 
		print "Pose successfully mirrored.\n".
	}
 
}
 
global int $jobNum = 0;
$jobNum = `scriptJob -e "SelectionChanged" "mirrorPose $rigNameSpace"`;

Now you can have a trigger object (like a nurbs curve thingy or text or whatever) follow the rig and when you select it it will mirror the pose.
Also namespace safe, if you decide to reference the rig.

The nice thing is that now you can have shitloads of workflow mel scripts that are name dependant and they will still work when rig is referenced .

Andre

[joojaa]

Still not a good solution. Its actually far better to bind your scripts to some other gui such as the rmb marking menu.

[andrehitsoy]

It's actually an awesome solution for binding mel scripts to a scene and declare global strings containing namespaces for the scene's content. Never had problems with it.

I can agree with running scriptjobs is not an ideal solution (in that they're a hassle to kill and they can slow things down even if they're not evaluated during playback) but linking mel procedures to scenes using scriptNodes is a very good solution. At least for keeping track of names when namespaces are involved.

Binding scripts to the gui is not the same as having it follow scene files (I'm assuming the reason for having it follow the scene file is because the mel procedures are context sensitive and is meant to work on stuff in that particular scene).

How would you implement a dynamic rmb menu so that it only exists in that scene? Having the scriptNode run a mel procedure that changes the menu? After Maya is launched? That doesn't work does it?

But yeah, you could have the namespace check procedure in the actual scripts that gets called through rmb marking menu entries, but that's a more permanent implementation.

That being said, I agree with Joojaa about running commands by attribute change is not a very intuitive approach. That's why I suggested selection trigger, as it is a more precise 'action'. But rmb command is probably even better in general for running commands.

[joojaa]

Binding scripts to the gui is not the same as having it follow scene file.

Err... yes it is. NOTHING! and i mean nothing says you cant bind the gui items in the same way. I was in no way saying having scripts follow the scenes is a bad thing in general. In parctice they are misused a lot tough*. What I was saying binding a action that runs out on attribute change is a bad idea.

See mirror scripts are actions and binding action to attribute is not very smart thing to do. Why? Well inherently thay do not respond in the same way attributes do, attributes forlw down the graph, whereas actions are done once. Now the real problem is that a user might not see this. and if you key a attribute thats bound to a changescriptjob then your going to have weird consequences. Second its not inuitive to sue theese actions as youd need to change a attribute to make it happen. Which does not reflöect on how actions really work.

How would you implement a dynamic rmb menu so that it only exists in that scene?

Same way as you do it outside the scene. Ok ill do a example. Wait a sec firing maya up.

• and I wouldnt open a scene form others with scriptjobs in them, big security issue.

[joojaa]

OK put the following in scriptjob:

 
global proc jooDagMenuCustomize(string $parentName, string $object)
{
    if (attributeExists("addDagMenu",$object))
    {
        eval(`getAttr ($object+".addDagMenu")`+"(\""+$object+"\")");
    }
}
 
 
global proc jooNothingSelectedCustomize(string $parentName){
  // placeholder
}
 
 
// lets hook the customisations up
global proc buildObjectMenuItemsNow( string $parentName)
{
	global int $gIsMarkingMenuOn;
	if (`popupMenu -e -exists $parentName`) {
		popupMenu -e -deleteAllItems $parentName;	
		if (`popupMenu -q -mm $parentName` != $gIsMarkingMenuOn) {
			popupMenu -e -mm $gIsMarkingMenuOn $parentName;
		}
		if (!`dagObjectHit -mn $parentName`) {
			string $leadObject[] = `ls -sl -tail 1 -typ transform -typ shape`;
			if (size($leadObject) > 0) {
				dagMenuProc($parentName, $leadObject[0]);
				jooDagMenuCustomize($parentName, $leadObject[0]);
			} else {
				setParent -menu $parentName;
 
				menuItem
					-label (uiRes("m_buildObjectMenuItemsNow.kSelectAll"))
					-radialPosition "S"
					-command ("SelectAll");
 
 
				menuItem
					-label (uiRes("m_buildObjectMenuItemsNow.kCompleteTool"))
					-radialPosition "N"
					-command ("CompleteCurrentTool");
 
				jooNothingSelectedCustomize($parentName);
				setParent ..;
			}
		}
	} else {
		warning (uiRes("m_buildObjectMenuItemsNow.kParentWarn"));
	}
}

Ok now add a object with attribute a string addDagMenu thats a custmisation for your object. Now i dont have time to tweak things so thsi ONLY works when you click on space where theres no object while having a object selected. If id do the easy thing i would beraek your maya experience.

But now i have to feed the kids.

[andrehitsoy]

Nice explanation and example, Joojaa.

See mirror scripts are actions and binding action to attribute is not very smart thing to do. Why? Well inherently thay do not respond in the same way >>attributes do, attributes forlw down the graph, whereas actions are done once. Now the real problem is that a user might not see this. and if you key a >>attribute thats bound to a changescriptjob then your going to have weird consequences. Second its not inuitive to sue theese actions as youd need to >>change a attribute to make it happen. Which does not reflöect on how actions really work.

As you can see in my previous post, I totally  agree with the attribute change/action issue. But I didn't think about editing menus with DagMenu procs before. Nice one, Cheers.

[joojaa]

Yeah just wanted to be clear on the subject.

[andrehitsoy]

I'd still personally recommend identifying and declaring a global string $namespace for referenced assets that you have a shelf of workflow scripts for, though. It's a nice way of keeping track of things.
Joojaa: Have you got any better ideas (I'm sure you have) on how to keep track of and work with referenced objects from a particular scene file?

[joojaa]

Well in general id like to sidestep the entire issue of using namespaces to identify stuff. Ideally youd read the data from a set of somekind. Or in this case the global refenece node, which contains all the info for you to querry. (and its nevre stale).

Unfortunately mayas not really geared towards independent one file assets as mayas more about shipping entire projects worth of soulutions and then offcourse theres really no need to keep it all in one file so the extra asets such as custom nodes etc will keep along fine.

[andrehitsoy]

Unfortunately mayas not really geared towards independent one file assets

Care to elaborate?