[Closed] Tools set delivery

want to say in advance… a MZP solution can’t work in my case. An included plugin is loaded and can’t be unloaded or overwritten on disk.

My pipeline for the tool “3dCutout” is:
One installer(.exe) that will install all files at specific folder(Program Files by default). This installer will detect all installed 3dsMax by looking at the registry/Local Machine. Then for each Max it will create a separate shortcut. This shortcuts will run the main .exe from instaled folder that will manage everything. for example registration and also check for update by sending an https to my server. If there is an update, it will be downloaded and installed BEFORE running the Max. if registration and updating was OK, main .exe will run the 3dsmax.exe with commandline and specific arguments like custom ini, custom UI and custom startup.ms. So because of custom ini, you can also change the viewport driver, gamma setting,Additional Macros,Additional Startup Scripts and everything which is inside the custom ini. This way you can manage and change all things without copying even single file to the Max’s directory.

thank you MZ… i will collect all ideas and comment it later

At rebellion we had a company wide 3dsmax start up script ( mostly to make sure the system unit size was set consitantly when max booted up ). This script was added to each 3dsmax deployment by the IT dept

Additional scripts , icons, and macros were pointed at a custom local drive on each machine. New scripts were delivered to this drive via perforce. Each user was responsible for staying up to date with the scripts they needed in the same way the were responsible for keeping up date with game project code and assets.

This method works fine for a games company because user are experienced with version control, alas no
VFX company I’ve been at uses version control for artists.

I’ve been looking at simple ways to automate building mzp files for release online. I’m mostly there with maxscript and text file manifests. All the files get moved to the right folder and i do the zip by hand. I’ve yet to implement automated zip which i guess i can do using python.

Building and testing MZP files by hand seems to take a long time, but with an automated solution I could daily mzp updates if needed. I wonder if this would be a simple approach for a vfx company

Don’t waste your time by rar or zip automation. I prefer InnoSetup which is professional,free and easy to use installer.It will manage everything specially reading and writing in registry without any permission problems.

We work with a variety of in-house maxscripts. No in-house plugins with dlls etc so our solution may be a bit less complex than others.

We had a bit more chaos a few years back when a script would be written or updated and it would be emailed out to the artists but inevitably team members would use different versions and I’d get emails about how something was broken or a bug still existed or a feature wasn’t in their script and I would always have to investigate and determine which version they were using.

Finally, I built a script panel, which essentially is just a pretty UI script with buttons that file-in a couple dozen of the latest scripts from a networked location. All team members know they show only access our scripts via this panel. When I or another of the scripting savy guys does an update we just update the script in the networked location this panel is connected to and everyone on the team is instantly using up-to-date stuff .

When we upgrade to a new version of Max I always have IT install a start-up script that makes sure this panel script is installed and it makes another file-in to another networked script that checks units and does a few other things. Using this script I can also do other checks on Max or even check to make sure other things like Photoshop plugins have been installed correctly.

These networked locations that hold our library of scripts are different in each of our studios so for some of the newer scripts that need the location of things that are different studio to studio we use a call to json file that lives with the networked script that stores the locations of these assets. Just as an example one studio may have it’s deadline repo on their R drive and another studio may have it on it’s T drive and we need those locations for our custom submitter to work.

I wrote a standalone installer to parse the 3dsmax.ini and plugins.ini and add and overwrite the required paths to plugins and script files. It has functioned for years without issue ( once I figured out out the correct text format to save the inis as )
There is the somewhat painful overhead of writing your own ini parser, but it is a bit easier than packaging a 3rd party one.
I would say Denis, python is your friend here as there are even packaged that will compile your python install script to an exe to reduce issues with deployment.

c# or Python doesn’t matter to me… i picked c# and provide some .NET methods with my .DLL from the standard package to setup tool paths.

I wrote a plugin that we’ve been using at MAKE for a few years that allows us to update plugins from a shared path on the network, accessed by 150+ computers simultaneously, without every running into file lock errors.

Basically, it’s a DLL loader plugin that each machine loads during startup. Instead of seeing all the plugin files directly, each machine just sees the loader. When max starts up, it loads the loader plugin from network directory A (pointed to in each machine’s plugin.ini), which copies all relevant plugins from a hardcoded network directory B to a temporary local directly and manually loads them itself. The local directly name is given a random token so you can have multiple max instances open that have different versions of the network plugins (so that multiple max instances don’t lock the local copies of the network plugin files on each other either). Each time the loader initializes, it also attempts to delete any existing previously-copied local plugin files in those temp directories (if it’s not able to delete them, it means a different max instance is holding them which is okay, and if it is able to delete them, it results in a successful cleanup of the temp plugin files). The reason for doing cleanup during startup instead of shutdown, is because if max crashes or closes unexpectedly for whatever reason, that cleanup phase isn’t missed.

So long story short…it allows us to update plugins on the network without having to ensure all max instances across the entire farm are closed and is basically a hassle-free way of managing plugins that only rely on their .dlX to be loaded (plugins with a more complex installer can’t be loaded this way).

The plugin is property of MAKE so I can’t release it, but it is very simple so any other curious developers should be able to recreate it quite easily.