Does anybody know a way to create a scriptJob that watches for an object duplication event?
Thanks,
-bN
Anybody?
why would you need a scriptjob for that? ui mean isetad of using the standard duplicate use a duplicate thet does the job like you do (you are calling diplicate anyways, and theres just one duplicate so if you temprarily or pernmanently modify your duplicate to do it right then...)
bent: i don't think there is a way. you could "dodgy" up a solution, but i'm not sure how reliable it would be. if you use the -DagObjectCreated event, and then look in the undo queue to see if the last command was a duplcate command, that might do the trick well enough...
i expect he has his reasons... sounds like hes writing tools that won't be being used by just himself joojaa...
writing tools that are invisible to artists in a studio is pretty important in my opinion. both invisible and foolproof. its the mecca really...
Thanks for the undo trick, I will look into it.
The problem I'm trying to solve involves a polygonal object that has attributes connected to a scriptNode. The problem occurs when the object is duplicated, the scriptNode is also duplicated behind the scenes, rather than the duplicated object simply being connected to the original scriptNode.
It hoses everything up. So I'm trying to find a workaround, and I figured that I could do a scriptJob that would check for a "duplicate" event.
As far as Joojaa's solution, I would like to hack the "duplicate" command, but alas, it is a command and not a MEL script. Doh!
rather than the duplicated object simply being connected to the original scriptNode.
so are you sure you've got duplicate "input connections" turned on? i'm sure you have, but i just had to check... 
while the duplicate command is a mel command, the duplicate functino in maya is handled via scripts... ie, when you hit duplicate from the menu, it doesn't directly call the duplicate command. so it is actually possible to go with joojaa's method.
just check out the script editor when you do a duplicate. it'll tell you what script its calling.
Yes, I did think of this, but unfortunately I need to account for people's customizations as well -- whether they've transferred the button to a shelf, or added a hotkey with some other bundled MEL scripting included in the operation.
I think what I'm going to do is to create a scriptJob that checks the undo queue every time a new selection is made which checks for the gmatch of "uplicate", and then run the script based on that check. I'll basically have to clean up the mess that was made by the duplicate command, and the scriptJob performing a check every single time something is selected seems like overkill, but hey, whatever works, right?
Ok your perspective here is a bit blocked by your ability think of ONE solution! Let me try to explain this is somehow very hard to understand even tough the concept is about as simple as it gets.
Se i understand that the duplicate is a command But. NO user actualy goes ahead and types duplicate in the command prompt.
They use shortcuts and the menu. Now if you change the command in the menu and the shortcut then IT IS totaly invisible to the user!! And its much better practice too. The only thing you need to notify is the scripting crew.
Besides now you actualy have the option of using the duplicate versus not. And this also makes you scriptnode free!
Its the same thing only done at one level deeper! I know this is a problematic solution in many ways (because all shelf buttons would need updating etc etc) But its the best option. (you can parse the files to account for the change tough! IVe done this suceesfully many times)
But this undo method is lined up with similliar caveats... Plus it makes maya sluggish!
THis is why i would like to se all maya commands etc wraped up in mel Even if its obsolete then you can account for theese kindso things.
yeah but i think you'll find that all menu items, and all shelf buttons made by users (unless they know a bit about scripting, and have written their own fancy pants shelf buttons) use the basic command:
performDuplicate false;
also, typing performDuplcicate 2; gives you the text of the command with all options that maya runs.
before you go ahead an implement the slightly complicated scriptjob technique, try out the "hack the performDuplicate script" technique first. after all, it should only take you seconds to try out...
oh and joojaa, scriptjobs hardly make maya sluggish... i mean, a freshly opened version of maya already has like 30 scriptjobs running. 1 more is going to make stuff all of a difference. especially if all its doing is querying the undo queue...
No but a badly designed, or choosen script job can make it sluggish (avoid it if you can in any way). And here the entire idea is just too ovberblown! I mean as you said one can just edit performDuplicate its infinitely easier.
I mean it file if you duplicate 10 things, but what if a user writes a scriptjob to create 1000 object copies now he suddenly runs a few thousand lines of scriptjob withhout knowing it! Also bacause the user is not avware of this (you effectively made him blind about this thats invisibility for you) he might end up in trouble thats VERY hard if not imposible to notice!
I mean what if he decides to disable history for any reason. Such as inside the script!
Also it isnt hard to grep all files using duplicate and append some lines there automaticaly!
But id suspect that many users do have duplicate in ther shelf as the runtime command!
Also: just occured to me that if you start using scriptjobs for a ultimete solution yooull soon end up having a few hunderd of them running (yeah if i wasnt so intent in not doing scriptjobs id asume i would have something like 50 or so running in addition to the 30, altough it could probably be optimized somehow)! Now i have some 3 of them over the default.
BUt i was thinking of this over the weekend (couldnt help it) and one question popped in my head, what if i register a command that has the sema name as a default maya runtime command, wich takes preceedence? And if the new one then this is the ultimate way to override things!
To clear some things up, I can't hack the performDuplicate script because there are occasions where it is not used, such as the native Maya command "duplicate -rr -un".
I am using scriptNodes as shepherds in my scene to organize potentially thousands of objects for a special Manager I've written--basically a way to tag certain objects with unique properties and have them update real-time whenever I alter the scriptNode's attributes.
If you know of a way to replace the "duplicate" command using MEL, that would be great, but I still need to use the command inside of the command that I would replace it with. Ack.
I agree that I'd like to stay away from scriptJobs as a rule, but I can't think of another workaround for this problem.
-bN
Hi bN,
I take it you're making a game editor of some sort and are thus managing the hell out of objects [img]http://www2.highendnet.com/forums/icons/smile.gif[/img] I have run into a similar problem, although I have the advantage of combining MEL with the API in most of our tools. If you have anyone there that is API saavy, there is the following class: MModelMessage which exists to give you two callbacks: BeforeDuplicate and AfterDuplicate. Quite handy really!The other thing I've done is capture the event DagObjectCreated:
scriptJob -kws -protected -compressUndo true -event DagObjectCreated
Then I have it call into a function (again in an API, but is probably doable from MEL) that looks at the currently selected items (if they hit duplicate, Maya automatically selects all the newly duplicated objects). In our case, if any of the selected objects have a duplicate of a particular property that is supposed to be unique on every object (we tag all of the created objects, which it sounds like you're doing too), that object must have been duplicated and we can handle it appropriately. (You also have to deal with the issue of instances as well though because they have the same behavior, and if you're trying to differentiate, don't forget to check for the new nodes being instances instead) And I agree with you that hooking into the UI is NOT a robust solution for the exact reasons you mentioned.
Cheers,
Taytay
No hooking into ui isnt ideal but you can easily go thru all scripts and encapsulate all calls to duplicate into one of your own calls (wich then calls the thing the script did), Along with a nice //automaticaly editted. Wich leaves the user of the script informed of the change!
If you want to stay out of the api offcourse.
I see what you're saying, but I do think it has some pitfalls. As bN has pointed out, that does not account for the fact that artists might install their own custom scripts that they download from a site such as HE3D and those might make calls to duplicate. It also does not accomodate patches or upgrades to Maya which will require new versions of script files which, under this solution, would have to be searched through and replaced again. I think we're both talking about writing an "editor mode" for Maya which places these restrictions on the artist for the purpose of guiding/overseeing the data when in this "mode". I doubt either of us are advocating making this change a permanent and invisible one to mess with the artists' ability to duplicate in all cases.
Cheers,
Taylor
Well yeah thats true. Also if you dislike doing things in the api you could allways make the api justa conveyor of the message to any mel file of your liking, right.
And invisibility is a boon but can be a curse too!
True that. After seeing so much functionality in the API, I would guess that someone could become VERY popular writing a plugin that simply exposes that functionality to MEL. That way artists and others who are only comfortable in the scripting environment could do a LOT more but still stay in MEL.
Cheers,
Taytay