CGTalk > Software > Autodesk Maya > Maya Programming
Login register
Thread Closed share thread « Previous Thread | Next Thread »  
Thread Tools Search this Thread Display Modes
Old 10-26-2005, 09:00 PM   #1
Nenox's Avatar
Sune Kempf
IO Interactive
Copenhagen, Denmark
Join Date: Feb 2003
Posts: 178
Sourcing of procs. Advice wanted!


I'm scripting my "ass off" at the moment, making everything as procedures/functions. Most saved into seperate files. Trouble is that number of files my script folder is exploding.

So I would like to structure them a bit. Putting eg. all the procs related to handeling curves into one .mel file. And so forth. Making little proc packages, if you will.

But as far as I know Maya only sources the proc, that is equal to the script file name, on startup. And I would like to be able to call any proc from any file/other proc.

I see three options:

A: Make sure to run the source command for the "script package" you need, from within the proc that needs to call the proc from within that "script package".. Whew!

B: Make a script that sources all scripts within a specific folder. That script would have to ba called from all procs

C: Run the folder source script, on maya startup.

But I don't really know..
Any ideas of how I handle this in a sweet way?!

--- rigging blog ---

Last edited by Nenox : 10-26-2005 at 09:09 PM.
Old 10-26-2005, 09:31 PM   #2
MEL Monkey
mhovland's Avatar
Mike Hovland
Technical Artist
Chicago, USA
Join Date: Feb 2002
Posts: 580
What I do is set up a new folder, in my case named "libs". As I'm scripting, if I find a section of code that I am constantly copying into a bunch of scripts so I have access to the procs, I abstract the code out so that it accepts arguments and returns results, and then save it out into my "libs" folder.

If you go this route, you will have to add the "libs" folder, or whatever you name yours, to the MAYA_SCRIPT_PATH variable in the Maya.env file, so Maya knows to search there for scripts at startup.

As to sourcing all the correct scripts, I have found to be true, that as long as the script is hashed in when Maya starts, that you will have access to all the contained procs inside them.
mike hovland
lead technical artist

Life beats down and crushes the soul... art reminds you that you have one. - Stella Adler
Old 10-27-2005, 12:41 AM   #3
Nenox's Avatar
Sune Kempf
IO Interactive
Copenhagen, Denmark
Join Date: Feb 2003
Posts: 178
Thanks for answering!

This is basicaly what I'm allready doing. I set up a special folder and have added it to the maya.env.

This is a test script file "procTest.mel" - that I put in that folder:

global proc procTest(){
print "procTest";

global proc procTestA(){
print "a";

global proc procTestB(){
print "b";

When maya has loaded, If I try to run the proc procTestA or procTestB - maya can't find it. Once I either source the script manualy or run the proc with the same name as the script, I can then run all procs contained. This is regardless of whether I do it from the script editor or another proc.

So a strategy could be to simpely have an empty proc (does nothing) that is named the same as the "script package" file. Then allways call that before calling any of the other procs contained in the script.

An alternative would be to source them in "usersetup". But I would like my scripts to work on any machine, and not have to set that up for other people.

What do you think?
--- rigging blog ---

Last edited by Nenox : 10-27-2005 at 12:45 AM.
Old 10-27-2005, 08:59 AM   #4
goleafsgo's Avatar
Tim Fowler
SW Development Manager - Maya
Burlington, Canada
Join Date: Apr 2004
Posts: 955
An alternative would be to source them in "usersetup". But I would like my scripts to work on any machine, and not have to set that up for other people.

If a proc needs to be called and it doesn't have the same name as the file then someone has to source it...that's just the way it works...and that's what usersetup.mel is for so I wouldn't go too far out of your way to avoid it. All you need to do is add one line to that file...that's not too hard is it?

Personally, I don't try to avoid having a lot of .mel files with only one proc in it that is intended to be called from outside and having the names match so I don't have to source it myself.
Old 10-27-2005, 12:56 PM   #5
jdj's Avatar
Daniel Johansson
Join Date: Aug 2003
Posts: 227
Hi nenox,

This thread might have some interesting tidbits for you:

We got a bit sidetracked at the end, but anyway.

/ Daniel
Old 10-27-2005, 01:20 PM   #6
Nenox's Avatar
Sune Kempf
IO Interactive
Copenhagen, Denmark
Join Date: Feb 2003
Posts: 178
Thanks guys!

Yeah, that thread waws dynamite. Right now I'm going for the solution of sourcing the scripts another script needs to call, in the script that calls them. But I'm sure I will try and make this smarter in the future. I'm also inspired by the Custom Character Toolkit stuff and I'm currentely building my own autorig, based on those ideas. Scriptwise anyway. I would love to create menus etc. by using folder structure like they do, but in attempting, it has beed a bit much for me to solve, at this point. But there is allways hope for the futore...

Cheers :-)
--- rigging blog ---
Old 10-31-2005, 03:26 PM   #7
technical director
Join Date: May 2003
Posts: 128
I know this is minority opinion--but I think the whole business of sourcing procs from
other scripts is usually unnecessary and unhelpful. Generally the sourced procs are
small and could easily be included in the main script--certainly this would simplify editing.

If you have a core of tried and try utility procs--like zoo utiliities--there might be some merit.
Again all of these are small and could easily be cut into the main script. The only really
useful case would be a long script which is tested and fungible--but this is not really common. There is the case of wrapper scripts--but thats different.
Old 10-31-2005, 03:26 PM   #8
CGTalk Moderation
CGTalk Forum Leader
Join Date: Sep 2003
Posts: 1,066,478
Thread automatically closed

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.
CGTalk Policy/Legalities
Note that as CGTalk Members, you agree to the terms and conditions of using this website.
Thread Closed share thread

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Society of Digital Artists

Powered by vBulletin
Copyright 2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump

All times are GMT. The time now is 01:42 AM.

Powered by vBulletin
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.