We used to have a bat file system here for updating scripts and plugins, but it was not a dependable way of getting updates out, people forget or just didn’t do it. So not long after I got here I setup a system here that always keeps scripts up to date on all machines and a tool to notify of plugin updates (which kills max, grabs the latest plugs and restarts max). We keep all of our scripts on a centralized file server, and access them via macroscripts. The only drawback to this is if the server is offline the scripts are not accessable, but then again most of the dev tools are not available either, so the server is brought up quite fast.
The centralized deployment of scripts allows for eveyone to always have access to the same tools as well as tool fixes and updates. Currently new scripts require a simple max restart, but script updates happen instantly. I can itterate through many changes without hastling the artists with new installs or updates.
Thanks Pete. A lot
Ya a batch file is limited but no one has to remember as it was updated when you logged in every time using a short cut in the startup dir. I final went with a perl system, it didn’t kill max but that would have been a good idea. The system I set up finaly was driven by an INI system where I could control who got what scripts on the production. I only did this for testing reasons so that I could setup serniors in departments with new tools to test before I let the masses at them.
There must be about a million ways to handle it so look into as many as you can before you have to live with your solution. Another thing to take into account that I use a lot over the last couple of years are .mzp packages. This will allow you to create install packs for scripts and other assets. For each client I have a single script package that I can update and send out. This package can just be draged into the viewport in max and it will install every thing that is needed. One of the things that it installs is a script that will call the install package on each startup of Max. It will check if the date on the mzp has changed since the last install and run it if need be. All tools are updated all at once from a nice protable package.
hello. let me make my humble contribution. Like someone sugested here, i use a .ini on the server and a startup script checking for version number, when the version number is changed, by me, a script is called to copy the new scripts or replace the new versions of the old ones. it´s working well for a long time. when i get some free time (i´m not exclusively on scripting, unfortunately) i do some improvements, mey next one will be a method to control and choose the scripts that will be replaced and copied to the other machines. this way i want to have a better control over unninstalling those scripts too.
hope i contributed someway.
Gustavo
That’s a great way of doing it Gustavo, would you be willing to share how you access the ini values via the startup script?
edit –
okay – i looked into it and it’s more simple than i thought. Thanks for the idea though, Gustavo. Actually, thanks to everyone for discussing the thier methods. I now have a script (verifyinstall.ms) that sits in the startup scripts and tests for a variable in an ini file on the server. When ive changed a script, ill make a new installer (changing the version number on the verifyinstall.ms) and change the value in the ini. When max starts, it pops up a reminder. Thats good enough for what i want to achieve.
VerVar = getIniSetting "Y:\\Maxscripts\\Version.ini" "Version" "versionnumber"
if VerVar != "1.12" then
(
messagebox "update available"
)
else ()
at a push you could have a querybox that calls a shelllaunch to the installer if you wanted.
hi Pudgerboy, sorry for taking so long to reply. The method i use is a little bit different, cause i use 2 ini files, sorry i didn´t mentioned this before. My script is something like:
global localinifile = (getdir #maxroot) + "inifile.ini"
global networkinifile = "your network path\\inifile.ini"
localversion = getinisetting localinifile "(your section)" "(your key)"
networkversion = getinisetting networkinifile "(your section)" "(your key)"
if localversion != networkversion then include "your_network_path\\Install_new_version.ms"
so i have a local and a network ini and compare the two. when it´s different i call a script that will delete the old scripts and copy the new ones. this part is the one i wnat to make better, with a dialog, which only i will use, to select the new files and generate an array on the server so the script only have to check this array and copy the files. right now i have to write a line to each file i want to copy.
hope it helped,
Gustavo
Hi Gustavo,
That really helped thank you – i don’t think i’ll need it the same level as you but its a good way enabling the network update. I’m going to try to use ini files to store variables from now on too so i’ve learned a new thing!
Cheers!
Forgot to say the install_new_version script also updates the local ini so max doesn´t try to copy new scripts every time is fired up. About the ini files, i use them to set user preferences to the scripts i made or remember a rollout´s state, for example. it´s very useful. i´m also trying to learn something new every day, this forum is full of scripts i can´t even understand and i want to do it, someday. cya