Updating custom scripts over a network

[PEN]

some one did somthing really fancy and posted it here but what I did for years was to have a batch file on the server that uploaded all the scripts on the server to the correct Max folders each time they logged in. On each of the users machines was a shortcut to the batch file and it was in the windows start folder so that it was launched each time the user logged in.

All I needed to do was make sure that the folders on the server where correct. For the menu I had a dynamic one that rebuilt itself each time Max was launched using an INI file that I created. This way I could also control what tools the users could see.

Eventualy I did this all with perl scripts but the batch files worked in production for years without problems.

[floyd1510]

Thanks Pen for the reply,

The problem is that i am still very new to programming compared to you and the other gurus around. I exactly got what you said, but i cannot implement it since i do not know how to use Perl. I am planning to start with it though.

Thanks a lot anyways,

Vikram,

[pokoy]

hi Vikram,
have a look a this script: aearon setup (http://forums.cgsociety.org/showthread.php?t=293684&highlight=aearonsetup)
i've set it up at work and it works like a charm. you'll have to make minor changes (add 4 lines) to them, but it's worth it. there is also an option to update the scripts.

[bnvm]

I had a simular issue at my work. I am constantly some custom scripted utilities and I didn't want to have my co-workers to have to constantly copy the updated scripts to there machines. My solution was to copy all of the scripts to a folder on the network. Next I created a simple loading script like this.

--loading script
global ScriptPath = "O:\3ds max scripts\\"
filein (ScriptPath + "max-utility.ms")

I had my coworkers copy this script into the scripts\startup folder.

list file points to max-utility.ms. This script loads in the serveral scripted utilites that I created. The script looks like this.

--load rollout utilities
------------------
filein (ScriptPath + "max-plugins.ms")
filein (ScriptPath + "max-utility-01.ms")
filein (ScriptPath + "max-utility-02.ms")
------------------
--load utility to utilities panel
------------------
filein (ScriptPath + "max-utility-UI.ms")
openUtility maxUtility
max create mode
------------------
--load settings
------------------
filein (ScriptPath + "max-startup-settings.ms")
------------------


The are a few advantages to organizing it this way.

First, if the scripts need to be moved to a different location all I need to do is update the
ScriptPath variable with the new path location in the loading script and copy the new script my co-workers computers.

Second, unless the path to the scripts changes my co-workers never need install the scripts again, since the loading script simply loads in max-utility.ms file. I can make changes to the existing scripts by simply updating the existing ones, or add new scripts by adding an additional fileIn commands to the max-utility.ms file.

It has been two years and I have not had to manually install any scripts on my co-workers machines, even though I have made alot of updates and added a lot of content. I just have a second loading script that I install on my machine that points to scripts on my local machine so I can edit the utility on my machine and then just copy the updated scripts to the network drive once I know they are working. Any changes I make to the scripts are automatically loaded when max is started. There may be better ways of doing this, but this method has worked well for me.

[Moosley]

We have all the scripts on the file server and add a path to the folder in the External Plugins tab on the User Paths dialog... Scripts get run and updated each time max loads.

[PEN]

Like I said, I didn't use perl for years, just a DOS batch file.

[PEN]

I had a simular issue at my work. I am constantly some custom scripted utilities and I didn't want to have my co-workers to have to constantly copy the updated scripts to there machines. My solution was to copy all of the scripts to a folder on the network. Next I created a simple loading script like this.

--loading script
global ScriptPath = "O:\3ds max scripts\\"
filein (ScriptPath + "max-utility.ms")

I had my coworkers copy this script into the scripts\startup folder.

list file points to max-utility.ms. This script loads in the serveral scripted utilites that I created. The script looks like this.

--load rollout utilities
------------------
filein (ScriptPath + "max-plugins.ms")
filein (ScriptPath + "max-utility-01.ms")
filein (ScriptPath + "max-utility-02.ms")
------------------
--load utility to utilities panel
------------------
filein (ScriptPath + "max-utility-UI.ms")
openUtility maxUtility
max create mode
------------------
--load settings
------------------
filein (ScriptPath + "max-startup-settings.ms")
------------------


The are a few advantages to organizing it this way.

First, if the scripts need to be moved to a different location all I need to do is update the
ScriptPath variable with the new path location in the loading script and copy the new script my co-workers computers.

Second, unless the path to the scripts changes my co-workers never need install the scripts again, since the loading script simply loads in max-utility.ms file. I can make changes to the existing scripts by simply updating the existing ones, or add new scripts by adding an additional fileIn commands to the max-utility.ms file.

It has been two years and I have not had to manually install any scripts on my co-workers machines, even though I have made alot of updates and added a lot of content. I just have a second loading script that I install on my machine that points to scripts on my local machine so I can edit the utility on my machine and then just copy the updated scripts to the network drive once I know they are working. Any changes I make to the scripts are automatically loaded when max is started. There may be better ways of doing this, but this method has worked well for me.

The problem with this is if you filein mcr files it will create mcr files for you in the macroScript folder. If you have many macros in one file to keep them organized max will create a new script for each. This can be a complete mess when you want to remove scripts from the system.

[LoneRobot]

I'm currently using an application installer as per Jeff hannas tutorial on scriptspot. If i change it, i just re-compile the installer with a new version number and get everyone to run the new install. I'd ideally like a better way of updating without relying on everyone to run the installer. Perhaps a startup script that checks an ini file located on the server for the version number? i dunno. I know Polyboost and Orionflame do this sort of thing with the interweb.

Normal conversation in the office - "Hey Pete, you know that script you told me about three months ago that would save me loads of time? i'd like it now" etc,etc,etc....:scream:

[floyd1510]

Thanks a lot guys,


This is great! Thanks Pokoy for the Aearon Setup. I'll check it up. I'm just checking and shall get back after trying bnvm's idea too. But as Paul said, removing scripts since they add them as macroscripts to the local max, is there a way unneeded scripts can be removed???

And hey Pete, colud you give me a link to that Jeff hannas tutorial on scriptspot

Thanks a lot all you guys for the help,

Vikram.

[PEN]

I dont' know if the others handle it but this is where the batch file came in. It was stored on the server so I could add any lines to it that I wanted.

[Blue]

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.

[LoneRobot]

Hey Vikram,

here's the link to the tutorials - scriptspot (http://www.scriptspot.com/start.asp?p=tutorials)

[floyd1510]

Thanks Pete. A lot

[PEN]

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.

[Guga001]

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

[LoneRobot]

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.

[Guga001]

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

[LoneRobot]

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!

[Guga001]

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

[CGTalk Moderation]

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.