Hello
I almost finish beta version of a guide-based Setup tool. It’s time to deploy the scripts on all the workstations and I wanna be sure to make it the right way, making the update process quick and easy.
It’s the first time I use maxscript in production and I realize I don’t really know how to organize the datas.
I plan to create a simple “.ms” file in the “#scripts/startup” directory.
This script should load all the “.mcr” (macros.load “Z:/3ds Max 9/AutoRigs/macros/make_biped.mcr”), in order to load the last versions of macros, while the “Z:/3ds Max 9/AutoRigs/macros/” is managed by Alienbrain.
Is it the right way ?
I don’t really know how to deploy the custom UIs neither. What if I just overwrite the “DefaultUI.ui” ?
If someone with some experience with maxscript in production can give me some directions, his help would be greatly appreciated ( I don’t wanna make a big mess )
In a similar situation, I install a single startup.ms file that loads various other files from the source control directories (outside the Max path) much like you describe. That way as I bug fix and update my various scripts, and check them in, people get the latest versions simply by getting the latest revision out of source control.
The startup.ms basically reads a text file that lists all the current .mcr files (etc) that I have defined, and then does a Macros.load on those specific files. This allows me to add new tools very easily by just tacking their names on to the text file of .mcr's. (or conversely removing tools that don't work or are deprecated)
I also have the startup.ms file scan the creation date of another startup.ms in the source control directories. If the file is newer, it copies it over itself.
I implemented this method in order to trivialize the updating and adding to users tools without the nees to run some installer script or something all the time.
Bugs fixes, new features, and new tools are just one Source-control sync and a Max restart away for all my users. :)
I tried at first to deploy custom UI’s… All it did was upset artists who don’t like their UI’s altered behind their back. So i just let them do it on their own.
im doing exacly the same thing…and need a little advice/help, as im now stuck.
i have included these two things in my startup.ms file
macros.load “…”
cui.loadConfig “…”
it works like a charm, but for one problem. For example, if i’m loading lots of macroscripts, and take the BlurScripts for example, and the macro is referencing the scripts folder for all the scripts(which is now residing on a server, and not locally). Is there a way to re-link them…i have quite a few loaders that open up selections of .ms.
its like i need to make max look for scripts else where, like re-pointing the system paths, to make it aware of where they are…?
Tim I think that you will have to change this in the mcr itself. I use DOS batch scripts to do upload scripts from the server to all the machines, simple and fast to set up. Just need to restart max to get the update installed. You can also look at using mzp files for a package that can do all the loading and all you have to do is call on it.
cheers Paul, that looks like the easiest way for the time being. There isnt lots of machines to update, and I could go around and manually do it, but im trying to future proof potentially lots of updates. Once i get organised I will get someone to write all this for me. Im next to useless at maxscript and anything code related!
Kramsurfer…sounds like a good setup, whats the filein command? and how do you deal with macro’s that relate to other .ms files? have you edited them all as paul is suggesting?
I should mention that if you run a .mcr file that is not in the macro scripts folder it will create one there. This can be a real mess because if you have multiple macroScript definitions in one mcr file it will create a seperate mcr file for each one.
I have a folder on the network that is everything we’ve added to the standard max install. I compare the local to the network on startup and DL anything at that time.
If it’s a DLL or Icons then warn the user to restart Max.
If it’s a .mcr ( always in the /macroScripts/ folder) then “filein” it to update the definitions.
If it’s a .ms or .mse then just d/l it to the right spot.
Works great with about 20 artists here…
Good luck
Keith Morrison
www.focus360.com
I have this article written by Jeff Hanna bookmarked that talks about custom installers vs. mzp files. It might help solve some of the issues mentioned or at least provide an alternative:
http://www.scriptspot.com/Tutorials/NSIS/Creation%20Application%20Installers%20for%20MaxScripts.htm
You could go as far as setting up a system to automate the installer creation and distribution.
Here is the DOS command for copying files from one location to another. This will only copy newer or new files.
type help xcopy in the DOS window for all the information.
xcopy from to [switches]
xcopy Z:\myFiles D:\myfiles /E /D /Y
This worked for me with a production with 90 people. Not the best solution but it got us through six years of production before I wrote a much more robust version in Perl. I was also updating more then just Max so the DOS and perl solutions worked well as it would be nuts to have to run a max script to update Maya or combustion for instance. There was Max, Maya, combustion, photoshop and others that were taken care of all at the same time.
magic! thanks. gonna give that a whirl!
I should mention that it copies all folders and sub folders and creates new folders if they don’t exist in the target dir already.