I’m looking for any advice on distributing scripted tools to users across our network. We currently have an update system that copies newer files from a network share every time a user reboots. This is not my favorite method. What I am moving toward is distributing a single script that calls a loader via filein. The loader and all of the associated tools reside on the server and I can make changes any time. This seems very simple to me but I’m sure there are pitfalls and better methods.
What tips do you have for this or similar systems of distribution?
thank you,
jonah
I posted a similar question at tech-artists.org … http://tech-artists.org/forum/showthread.php?t=124
Thanks Chris. That helps a lot. I like the ideas in Aeron and will likely go with something similar.
For years I did this with a DOS batch file that launched when a user logged in. I then took another step where I replaced all the Max short cuts with a Dos batch that loaded the script each time Max started and then loaded Max.
One of the scripts removes a custom menu and rebuilds it from an INI file that is on the server. If the Server is down it wouldn’t do the rebuild.
I didn’t want to rely on the team updating their own machines as I knew there would be problems with this.
Incorporating Perforce in a system like this is a better idea.
Another system that I developed years ago was done in Perl, if I did it again I would use Py, it was similar to the Dos system except it could track users and only load certain files to certain machines based on rights. This was for testing and management tools. The tool was based on INI type files again on the server and loaded up the scripts to the local machines and again a couple Max scripts were fired when loading to setup Max with a menu and specific settings for the project.
At blur it’s a network repository of all scripts – which is under svn control. Developers have a local copy checked out that they can run in a ‘dev environment’ and then when ready can commit to the studio-wide repository. Each user only gets a few files locally actually, pretty much just a basic startup script that does a file-in for the libraries on the network. Each user also gets a tool called Treegrunt locally as well which is used to browse/run the available tools on the network, and can create macros so people can add them to their toolbars / menus as they please (which are set up to file-in from the network). <<This is all available in the latest blur beta stuff on blur.com You’d have to do just a bit of tweaking to get it working somewhere else, but it’s actually really easy to get going.
Right now Treegrunt is getting a major overhaul (via python), so it should be much faster / more fully featured when it’s done, but for now this setup works pretty well. We also ended up using the blur tools at another studio recently, and it really saved a lot of time.
I have looked at the Blur stuff and it looked very good indeed. So every thing is always coming from the network? I have run into issues before with this sort of set up if the network goes down so it is the only reason that I have avoided it that way.
Yup, always off the network… of course it could be modified to work a number of ways… ie: if you decide to create a macro it could in fact create a local version of the script (and that macro could check to see if it needs an update when you run it) so if the network is down at least the stuff you use most often would still work. Though if the network is down, you’ll likely have issues getting licenses too.
Prime Focus uses an “update what is needed” route where it checks everything before you start max and will copy off the server if anything is different. I personally like the idea of having the tools be updated on the fly off the network so you don’t need anybody to restart max, you just re run your script and you’ve got the latest version.
I’ve made a script similar to this at work.
The script is in stdplugs/stdscripts/ folder and sync the tools from the network before they load. Sadly it doesn’t work for plugins because they are loaded before any script.
Did anybody here have found a solution for syncing plugins when max load?
Max will auto-load any scripts in plugin directories, so if you just need scripts to load on startup, do this:
-add a network share path to each computer’s plugin.ini file
-put scripts in that share folder
They’ll be loaded automatically by all the computers, and to distribute an update, just put it in the share and overwrite the old file.
That’s what I do for MAKE’s farm and it works fine.
I have a maxscript that updates all macro’s/menu entries/scripts with the press of a button. So it’s a user responsibility to update to the latest tools. I also don’t rely on the network to always work, I’d like to have it locally.
Although when I feel our network is ready for it (not too much shifting of servers etc) I’d probably take Tyson’s route with a way to update on the fly as well.
Every script I make has a first line that acts like a header like:
–@type:macro;categorie:Rigging;name:Extra Bone Tools;description:Extra tools for rigging
This line determines where in the menu the tool gets a macroscript. The macroscripts get created on the fly and are registered in a ini file. This way I can do cleanup on update. The header determines where the script is going to live, in the startup or as macroscript, or as a plugin. The script itself simply gets an include statement in the new macroscript.
If the header is not found the file won’t be copied to max. I’m pretty happy with it sofar.
Only external tools like pstools and c# dll’s is something I have yet implement.
-Johan
It’s done before max loads actually with some sync tool – you could easily write a batch file to do this (xcopy perhaps) and then run max afterwards.
Hm yeah but this way the animator can’t double-click on a max file from explorer or the current source control application anymore. I can’t afford this. 🙁
I’ve tried re-writing the sync script in c++ as a global utility plugin but with no success.
For now, animators still have to get the plugins from the source control software when new versions comes out. Not very hard to do but still… XD
Actually – make it an exe, and replace the 3dsmax.exe, and allow it to take an argument (the max file when they double click it), then have that exe open the real exe (which was renamed of course)