PDA

View Full Version : AearonSetup (system for spreading and organizing scripts in a network environment)

Aearon
11-13-2005, 02:26 PM
AearonSetup (+ SoulPix Scripts Package)

Hey guys, after seeing a maya masterclass dvd about organizing a character pipeline using scripted tools (including automatically updating the tools on each workstation and putting them in a menu) i decided to give this a try in max.

This is a first beta of AearonSetup

AearonSetup_0.1.zip (http://aearon.de/files/public/AearonSetup_0.1.zip)

There's still a lot of error checking missing, it's just developed to a point where it worked for us in the situations we use it in ;) plus there is no documentation for the individual scripts yet.

1. Description

System for spreading and organizing scripts in a network environment using 3dsmax.

2. Features

- Updates scripts from a network folder
- No writing macroscript headers, they are automatically generated based on the folder structure and put into the local “UI\macroscripts” folder
- macros are automatically put into a menu within the main menu, they are sorted into submenu’s according to their category, so you have one clean menu with a list of all you macros
- Startup Scripts (Usually containing structs, scripted plugins and the like) are copied to the local startupfolder and are executed.
- Because everything is copied to the local installation, stuff still works if the network is down

3. Installation

The script consists of two files, one is a startup script that needs to be installed locally, it contains a reference to the location of the second file, which does the actual work and should be in a location accessible to all workstations. There is very little going on in the local file, so maintenance is minimal, everything you need to change is in one place.

These are the steps to install the script:




Copy the contents of the “AearonSetup” directory to a location that is accessible to all workstations
Copy “AearonSetup_Startup.ms” to the 3dsmax scripts startup directory (e.g. ‘C:\3dsmax7\scripts\startup) of all workstations
In the startup file, Change the line “Global AearonSetup_Path = "\\\\Server\\Raid\AeraonSetup\\"” to reflect whatever location you chose in step 1
(optional) In “AearonSetup_Main.ms” Change the variable “Prefix” from “SoulPix” to whatever you like
4. Using Scripts with AearonSetup

Now on to the actual scripts to be used with this system, some of those we use at SoulPix are included in the package, so you can take a look at them to see how they are organized as well, here are the basic rules:

Within the network folder, there’s a macros directory. This contains all the macroscripts sorted into subfolders.

These don’t need a macroscript header, it’s generated automatically. All you need instead is this (let’s say we have a script named “Point_Cache_Manager.ms” in the subfolder animation):


toolTip="Point Cache Manager"
buttonText="Point Cache Manager"

--start macro
do script stuff


The macroscript for this file will be generated like this:
- The macro’s internal name will be the same as the filename minus the extension (Point_Cache_Manager)
- The macro’s category will be the same as the subfolder it’s in, plus the prefix you set (so with prefix set to “SoulPix”, the category will be “SoulPix – Animation”)
- The ToolTip and ButtonText will be read from the script file
- The macro’s content will be anything after the “—start macro” line

Also, the macro will automatically be put into “Animation” submenu within the AearonSetup menu

Any “regular” macros you want updated over the network you can put into Macros_3rdParty\ (they will be copied to the local macroscripts folder and executed from there)

any scripts you want executed at startup, you can put into startup\ (they will be put into a local startup subfolder and executed from there)

CAUTION: before copying the macroscripts, all macros starting with “SoulPix_” (or whatever prefix you set) in the local UI\macroscripts folder will be deleted, this is to make sure there is no junk left over should any scripts be removed on the server. All menus containing the prefix will be removed as well so they can be rebuilt using the script found on the server. Bottomline: If you change the prefix, don’t change it to anything that is bound to delete any existing scripts or menus. For example all standard max macros start with “Macro_”, so chosing macro as your prefix is probably not a good idea.

DISCLAIMER: Everything (c) Kai Stavginski 2005. Feel free to use this as you wish, but please drop me a line if you decide to use it, or parts of it, in a production environment

http://aearon.de/files/public/AearonSetup_Graph.gif
Martin Andersen
11-13-2005, 02:59 PM
Thanks alot, will look into it next time I'm on a project with network
pokoy
11-13-2005, 03:53 PM
great tool! surely needed for a long time already! i like the automated generation of a menu - if i understand right, this is generated automatically, does it...?

in case i decide not to load the scripts from the network, how is it disabled? just by removing the file from the "startup"-folder?

and finally: if i would like to use this in a production environment, is it for free just by informing you?

thanks for sharing it with the community.
Aearon
11-13-2005, 04:29 PM
yep, the menu is generated automatically.

if you don't want the scripts to update, removing the startup file will keep everything intact, and not do any updates, yeah. you can also just comment out the last line in the startup file

i plan to add a tool for setting some options for this as well, and disabling the updates / a manual update option will probably be one of them.

you're free to use it in production, i'd just like to know who uses it and if it is of any use ;)

also if you need anything specific just drop me a line
Vsai
11-28-2005, 02:03 PM
I'm experimenting with this now, and must say thats a pretty damn cool setup you've got going on there.

One thing i noticed was a file i had here, where there was a 'line' of ---'s at the end of the file for some reason, kept choking on an unexpected end of file, changing line 133 of the AeronSetup_Main.ms to be macroHeader +="\n)\n" seeems to have helped, that was the only big problem i ran into in my experimenting so far :)

Edit: nope, thats not the problem, hmm, i'm tossing over a script that i can't get to work with it, and for the life of me, i can't see any reason why
PEN
11-28-2005, 02:28 PM
I did this a bit differently in production. Nice set up you have there tho. What I did was to just use an INI file that listed what macros went where in the custom menu. That menu you is recreated every time that you start Max. I could add and remove tools from the UI by just adding and removing what was in the INI file. For uploading to each computer I originaly just had a DOS Batch file that worked great but then eventualy built a system in Pearl that was more intellegent about it.

What happens with your system if you want to include macros that already exist or have been written by others. Do you have to remove the Macro headers?
Vsai
11-28-2005, 03:37 PM
a 'pass through' type file works as long as the filename doesn't conflict with the previously defined Macroscriptname!, with the main content being for instance:


toolTip="RenameObjs"
buttonText="Rename Objects (max)"

--start macro

macros.run "Tools" "RenameObjects"


little awkward with some things, i'm noticing that scripts that do much work with files (format/pathing/etc) tend to fail unless adjusted for escape chars, since the whole script gets read into a string at one point while its creating the headers.

Overall pretty neat, and learning a couple of tricks just poking around inside, so much thanks for sharing :)
Vsai
11-28-2005, 08:59 PM
Heres a small macro that i tossed together at one point when frustratedly debugging someone elses scene ;) i'm pretty sure its just the 'format's that are causing the problems, but i'm not sure how that could be 'error checked' before hand

! Edited to remove demo script that didn't actually work.. ! :)

It seems to always choke for me on the 'format myMacro to:(macroFile)' line in the AeronSetup_Main.ms file, (Which you can see where the problem is by running that file directly in max, as opposed to the 'update' script. both 'myMacro and macroFile appear to be perfectly normal to me. /wtf?

Btw, do that a few times without it getting to the 'close' section of the script and you can crash max pretty reliably :)
Aearon
12-03-2005, 02:15 AM
thanks so much for the feedback guys!

vsai: i added the macroHeader +="\n)\n" fix as well, you are right it does solve some problems

there is one thing you can't have in a macro file... it's %'s, this is because i write the macroscript to a file using format... i'll try to find another way to write the file asap, just haven't run into the problem because by now i mostly execute structs/fn's inside the macros

thanks for taking the time to post this!

PEN: thanks for the input, i guess in the end a system like your's, using external info for the macros/menu, is probably a bit more solid.

but having no one central file is a big plus when there's multiple people working on the script collection. adding new scripts is very straight forward for anyone with a bit of maxscript knowledge. i've noticed it actually motivates people to go ahead and write a lot of simple, sometimes project specific tools, that anyone can immediately use on their machines

although the system is mostly geared towards in-house tools, external scripts can be updated using this system as well, but i'm still working on a proper implementation of this. for now they are not put into the menu, there's just a "3rd party macros" folder from where they get copied to the local macroscript folders and executed. this works great for complex script packages which i don't want in the menu, but still available on everyone's machine (for example i got paul hormis' timscripts working this way, blurscripts are harder to integrate because of the way they are structured)

another way i've used for now is macro.run and other means to reference 3rd party scripts from within the menu

i'll try to come up with a solution for putting 3rd party scripts in the categorized folders as well, i think it will be best make the system just copy them over to the local installation without messing with their headers, they can be put into the menu anyway i guess

again thanks for the input guys, i'll post an updated version pretty soon
Aearon
12-03-2005, 02:47 AM
Vsai, here are a few lines of code to replace the "format ... to:" part, it think this should resolve your problem, you script works for me now

macroFileName = (localPath + Prefix + "_" + (getFilenameFile myFiles[i]) + ".mcr")
macroFile = fOpen macroFileName "wt"

if macroFile != undefined then
(
writeString macroFile myMacro
fClose macroFile

fileIn macroFileName
)
tuomasj
12-04-2005, 12:08 AM
Hey nice script! I have made same kind of script launcher system for us.

I have small tip: If you add a logon script in windows group policy that copies your startup script into scripts/startup/ directory, you don't have to worry if workstations have right file copied in right place. This way the file gets copied everytime they log on. And if you want to push it little bit further, you could add log off script, which copies changed files (ini-file etc) on users home directory.

--tuomas
PEN
12-04-2005, 11:54 AM
thanks so much for the feedback guys!

PEN: thanks for the input, i guess in the end a system like your's, using external info for the macros/menu, is probably a bit more solid.

but having no one central file is a big plus when there's multiple people working on the script collection. adding new scripts is very straight forward for anyone with a bit of maxscript knowledge. i've noticed it actually motivates people to go ahead and write a lot of simple, sometimes project specific tools, that anyone can immediately use on their machines



Have you looked at MZP files? I also have my scripts packaged all together that when run it extracts and organizes the scripts to the correct folders, runs them all and installs and builds the menu systems. What is nice about this is if you are working with outside houses then all you have to do is send them one file.

I like the system that you are setting up but I think that it is prone to errors and requires changes to existing scripts and doesn't work with how scripted are intended to work in Max.
Aearon
12-04-2005, 12:17 PM
your comments are very valid. i agree there are some factors about this that might backfire in some way, though we're using this system in production and it hasn't given us any problems.

if i we need to send the script package to outside people we just have to zip up the stdscript/startup/macroscript files my system copied/generated

mzp files are a great idea for packaging this up. actually i could combine this with my system (automate the packaging), because the result of what my setup does is just standard scripts/macroscripts.

i'm ironing out the big downside of not being able to use 3rd party macros with this right now (they will simply get copied over to the local install as they are, so no changes necessary, all i'll do is parse the headers in there so i can put them into the menu automatically)

i can't thank you enough for taking the time to discuss this PEN, it's great to hear from someone who has experience setting up a system like this!
PEN
12-04-2005, 03:41 PM
Hey your welcome. It is good to see new ideas on it as well. I have also thought of setting up a system that automaticaly reads in headers and sets up the menus but you still don't realy have a way of sorting them into submenus other then the category of the macro and you might not want it this way. This is why I went with the INI system instead.

Another addition that I did with the INI ssystem was to set it up so that not every one was able to get all tools or plugins. The reason for this was so we could restrict certain tools that we didn't want some departments or users messing with. I had a restricted user set that was based on a second INI that had user logins listed. If your login was in that INI that you got the restricted tools. I also used this for testing new tools as I would release them to only the department heads first for testing then if they worked I could just move them to the non-restricted install. It is realy easy to set up multiple levels of users this way as well.

I don't know if that is of interest to you but it worked well for me. I did this all with perl but it could be done with MXS just for Max. I think I will look into Python next time I do it as I didn't really get along with Perl, I havn't used Python but looking at it I think it looks more like MXS or C++ but I could be wrong.
Aearon
12-07-2005, 10:25 PM
That's a great idea, we don't need this for now because we're a very small shop actually, but still a good thing to keep in mind.

with the internal macros i could implement this easily (just a few lines before the tooltip/buttontext defintions), but this would be an additional complication with 3rd party scripts.

i hope i'll find some time to work more on this over the weekend.
CGTalk Moderation
12-07-2005, 10:26 PM
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.