Deploying / managing scripts across studio

[AlexP]

Those if you managing more than one workstation, how are you deploying and managing scripts?

Plugins are easy enough - network location, point the ini to it - done

But if I create a toolbar with a bunch of different 3rd-party scripts, how on earth do I then deploy that toolbar to everyone else packaged along with all the necessary scripts?

Or - how would one create a rollout/script that had a bunch of buttons linked to the scripts that could then be packaged and distributed and updated

I started creating a rollout, I added one button, realised it was going to take about 3 years to custom add a bunch of buttons and point them to each individual script and stopped. There must be a way to automate this.

Any ideas?

[Codi]

We usually just install macros on workstations that point to the actual script on the file server, something like this:

macroScript sample_script
category:"Company Tools"
buttonText:"Sample Script"
(
    fileIn @"\\Server\tools\maxscript\sample_script.ms"
)

The target script can open directly a tool or contain a list of buttons that run other scripts using "fileIn"

[^Lele^]

Filein has its own set of issues (f.e. it's always global.), which would become evident when enough scripts were added.
The one safe way to deploy a Max configuration to a workstation, that i have seen, is a diff-copy off a server unto the local workstation.
That way, one can configure what should be copied over depending on the "department" or artist's task, and then offload the network entirely as the required (new?) files are copied over.
There are also a few issues with plugins running off a networked location which, given the scattered nature of plugin development, have little chance to be resolved (ever?), and the local copy sidesteps.

[thablanch]

We do similar to Codi, a single button that points out to a server located toolbox.
Don't know about the filein.
We are working with ini files, so not pointing at a single script but at a ever evolving toolbox.
@"C:\@BLABLA_paths.ini
Worked flawless for a couple years now, updated on the fly.

[^Lele^]

Don't know about the filein.
We are working with ini files, so not pointing at a single script but at a ever evolving toolbox.
@"C:\@BLABLA_paths.ini
Worked flawless for a couple years now, updated on the fly.

https://help.autodesk.com/view/3DSMA...222EDA1C71_htm
"The script file content is compiled in a global scope context, as opposed to the scope in effect when the filein() method is executed. For more information, see Scope_of_Variables."

It only becomes a problem when things clash (variable names, f.e.).
The remote copy process, admittedly, is more laborious, and if there are no departments which do not need to see other departments' tools, it's probably overkill.

[Codi]

Filein has its own set of issues (f.e. it's always global.), which would become evident when enough scripts were added.

Correct me if I'm wrong, but I think that opening a script with fileIn is basically the same as running it, it will be evaluated on global scope anyway. It would be different if for example fileIn was used inside a script to load a shared library, then the library contents would be global and might clash with another script using the same library.

[^Lele^]

Well, it's easy to test:
Script one is simply this:

(
    myLocalVar = "local in the script!"
)

save and close the script as local.ms somewhere.
Running the locally scoped (top and bottom brackets do that) script will correctly print the variable value, but calling the variable from outside the script returns undefined.

running a

fileIn "local.ms"

without its own scope will promote all the variables in the properly scoped script to global. typing "mylocalVar" will return its value from wherever inside Max.
Which could not be achieved simply running the script by itself.

So, as stated, if you have proper control on proceedings, and there is never a risk of mishandling, you're safe and sound (the method's there for a reason. ).
When things get complicated (run fileins from external files, allow users their own set of scripts, and so on and so forth), then one may get bitten, and then it's going to be quite difficult to figure out what happened, and where.

[Codi]

True, it behaves different in this case. This never been a problem the way we structure our scripts, but will have this into account

[AlexP]

Thread subscription didnt work...

Thanks for the input.

Lele - thats what I was thinking - just a simple copy paste, BUT the issue I have is how to get a nice toolbar to appear with all the right buttons etc. automatically.

Currently I do it manually on everyones workstation and everytime I setup max, everyone manages to lose/delete/destroy the scripts I set up for them within 2 weeks.

[^Lele^]

Lele - thats what I was thinking - just a simple copy paste, BUT the issue I have is how to get a nice toolbar to appear with all the right buttons etc. automatically.

If you pasted the ini which deals with the UI that should be appearing too. Not sure if it's in the user folder or the main max root, though.

everyone manages to lose/delete/destroy the scripts I set up for them within 2 weeks.

Why do you think i turned into this a**hat? Years of seeing that done, AND getting yelled at for others doing it too, eheh (joking!).

[AlexP]

Ah ok cool, I'll take a look.

Drives me insane !