Maxscripts Use .mzp or .exe installer? What about version control?

Mark Dygert · Apr 2010

I've been researching different ways to bundle scripts, release them to coworkers (not releasing them externally). We're probably going to switch over to 2011 a few weeks after it releases so I'm looking for a painless way to get everyone back up and running.

My current process is I write scripts in notepad++ or the maxscript editor and release via mzp.

My Version control is by file name and diligence. The final scripts always have the same name so they overwrite the existing ones.

What needs to be installed:
- .ms to scripts and a few to scripts/startup
- one plug-in to plugins
- a few dozen icons

.mzp cons:
- Poor documentation. The examples I find are somewhat advanced for what I need to do and often the mzp.run launches another script that launches another script that... well you get the point.
- I can't get drag-drop to work thanks to the poor documentation.
- Everyone needs constant refresher courses on how to install them.
- mzp.run seems to be very limited in commands it can run?
- Its a pain to zip everything and rename the file just to test install.
- No uninstaller so everything has to be done manually.

mzp pros:
- It beats installing each script manually... but only by a little.
- Installs to the right spot.

exe cons:
- It's using another app to build exe's.
- Doesn't run scripts once they're installed so if you have macroscripts they need to be run manually or some kind of startup script needs to be installed?
- no one trusts a exe installer but since its internal they probably will?
- Could possibly be installed to the wrong spot by the user? There might be a way to detect the install path of max but thats getting into things I don't know much about.
- I don't really want to learn more syntax and language in order to compile simple installers.

exe installer pros:
- Version control done a little better.
- It can also uninstall files it installs but doesn't get the macros that install.
- a little less of a pain to deal with when testing.

So there we go, thats all I know about the subject I'm leaning toward exe but I'm not really sure its the best way to go? mzp has some nice features if I can figure out how to get them to work and once I get a working mzp system it could be fine?

SyncViewS · Apr 2010

Hi Vig, as you can guess by looking at my scripts, I'm for mzp. Many of the cons you stated can be overridden, or at last you'd need to clash with them only once, then it's only a question of keeping the installer updated.

.mzp cons:
- Poor documentation.
You're right, but once you got a setup working, you won't look at it anymore.

- often the mzp.run launches another script that launches another script that...
This depends on how you structure it. I usually use mzp to unpack all needed files into a temporary directory, then run a single .ms file to perform all the installation operations, like copying, moving files and executing each script for the first time to make it instantly available.

- I can't get drag-drop to work thanks to the poor documentation.
Write the commands once and forget about it.

- Everyone needs constant refresher courses on how to install them.
Once enabled Drag And Drop, it can open a simple dialog to ask if the user wants to perform installation and provide infos at the end of the process

- Its a pain to zip everything and rename the file just to test install.
Yes, it is, definitely! No workaround

- No uninstaller so everything has to be done manually.
The uninstallation process can be managed by the same .ms file that manages installation. On Drag And Drop the .ms file can see if the scripts are already installed and ask for a reinstallation or uninstallation.

exe cons:
- It's using another app to build exe's.
I've seen some installers made with the free tools nsis

- Doesn't run scripts once they're installed so if you have macroscripts they need to be run manually or some kind of startup script needs to be installed?
No infos on this topic.

- no one trusts a exe installer but since its internal they probably will?
Yep, .exe are often a NoNo

- Could possibly be installed to the wrong spot by the user? There might be a way to detect the install path of max but thats getting into things I don't know much about.
There is some insight by Richard Annema (Caustic Graphics / SplutterFish) here and here

- I don't really want to learn more syntax and language in order to compile simple installers.
Agreed. I ditched it too.

In the end I'd say, pick IC.Shape.mzp rename it as .zip and take a look at files:
- mzp.run
- IC_Shape_installation.ms (called by mzp.run)

Rob everything you need, and ask wherever you need help

If you want to take the FileHandler structure, get it from IllusionCatalyst web site, MaxScript page, filed under "System Structures", because the published one has some glitches I'll fix in next release.

renderhjs · Apr 2010

Vig wrote: »

What needs to be installed:
- .ms to scripts and a few to scripts/startup
- one plug-in to plugins
- a few dozen icons

.mzp cons:
- Poor documentation. The examples I find are somewhat advanced for what I need to do and often the mzp.run launches another script that launches another script that... well you get the point.

- I can't get drag-drop to work thanks to the poor documentation.

- Everyone needs constant refresher courses on how to install them.

- mzp.run seems to be very limited in commands it can run?

- Its a pain to zip everything and rename the file just to test install.

- No uninstaller so everything has to be done manually.

mzp pros:
- It beats installing each script manually... but only by a little.
- Installs to the right spot.

I think most things can be solved with MZP it just needs some time to research and test, but it is certainly powerful and the easiest way to install scripts when used with the drag and drop way.
From my expierence I would suggest triggering a maxscript file that actually takes care of the installation simply because the mzp.run syntax is different from the maxscript syntax and very very limited.

With TexTools at some point I had to invest more time into the MZP stuff because at first the mzp.run file was just copying files to the scripts folder.
It was limited and not everyone was able or happy to install it that way.
textools_3.00_install.gif

So what I did was besides reading the incomplete documentation was heading over to scriptspot and download lots of other scripts that used a MZP system. With that finally the drag and drop stuff worked as well ( wasn't able to solve it before).

Anyway regarding your con points:

Using just a single mzp.run to distribute all files can be tricky. I think it was the drag and drop stuff that failed for me when trying to copy several different files using multiple copy commands. Also some of the #folder stuff was outdated or bugged, like the newer user folders under the windows user files are not complete or at all supported here.

It should work like this, with the mzp.run looking something like this:

name "Test"
version 1.00

run "install.ms"
drop "install.ms"

clear temp on MAX exit
clear temp on reset

Make sure you have a install.ms (or whatever name) in the mzp archive. From there on you have access to all the user folders like userIcons, userScripts to name 2 important ones. Using the user folder also avoids admin required rights or win Vista+ restrictions.

To access the MZP archived other files from the install.ms file I found a hacky way that works: I scan within the autodesk temp folder (usually same as the windows temp folder for apps to use) for the MZP filename as a folder.

Within the textools setup.ms there is a function that returns that folder by a.) scanning for a name match and b.) with several temp folders caused by the same MZP files takes the latest ones. The function is as follows:

function setup_textools_find_MZP_url =(
	local url = sysInfo.tempdir as string;
	local folders = getDirectories (url+"mzptmp*");--temporay MZP folders
	
	local _mathchUrls = #();--store possible matches and have them sort by date later
	local _matchDates = #();
	local _pCnt = 0.0;
	for f in folders do (
		_pCnt+=1.0;
		--find the right folder and file from theh MZP archive
		local  has_folder= getDirectories (f+"TexTools");
		local  has_mzp= getFiles (f+"mzp.run");
		
		local p = _pCnt / folders.count* 18.0;
		--setup_textools_update p ("scan "+f);
		
		if (has_folder.count == 1 and has_mzp.count == 1)then(
			local _date = getFileCreateDate has_mzp[1];
		
			append _matchDates _date;
			append _mathchUrls f;
		
			print("matching foldert: "+(getFilenamePath f)+" tcreated: "+_date as string);
		)
	)
	
	if (_mathchUrls.count > 0)then(
		--found some urls that match our footprint, now sort by date and pick the latest
		local _new = amax _matchDates;--the latest date item
		local _indx = findItem _matchDates _new;
		local final_url = _mathchUrls[_indx];
		print(_indx as string+".ttnewest "+final_url);
		return final_url;
	)else(
		return "";
	)
)

Once you know that folder its rather easy to scan for all the subfiles and copy them to the user folders all without admin rights required.

drag and drop to the viewport should be easy to understand for anyone. No need to explain what the maxscript listener is.
Thats why launching one installer maxscrript is easier in the end, the mzp.run is just used to bind the drag and drop behavior to a script to execute. From there on you have more freedom and control.
Not with my method, just make sure that the MZP files are still in the system temporary folder. With that you can test the local isntall maxscript and see if it can access the temp folder. Once you have done it its easier afterwards to change it for other mZP packages.
Again this can be addded to the isntall.ms sscript for example just like textools by showing first a floater with a isntall and unisntall button. Check out the textTools install.ms in the MZP for sample functions to collect lists of former files to remove including the windows temp folder (as max does not always sweeps them)

The whole installer script is in the TexTools...mzp:
http://www.renderhjs.net/textools/TexTools_3.20.mzp

Oh and recently I was thinking about adding changelog.txt display into the setup that is included as textfile within the mzp file and displayed in the setup floater in a textfield.

Mark Dygert · Apr 2010

Thanks guys, you rock! That's just the nudge I needed to dig back into MZP. I think you're both right after its set up its not such a pain to maintain.

The weird thing is I have both of your tools installed but forgot how they got there. I thought it was a custom installer with both.

Thanks for the mountains of help! I've got some reading to do!

commander_keen · Apr 2010

I made a floating toolbar that some people at work use. After installed it starts with max on startup and all the source files are in an external directory which is set up with version control.

Its a button based toolbar so you make a simple button def which either executes from the button def or links to a larger script or script chain. Another good option is to make a floater with a list of all scripts in a dir or dir tree (zero work do get your scripts to show up for the other users).

I think this is the best way to go because working with individual scripts that all need to be installed and configured in different ways is super annoying.

Mark Dygert · Apr 2010

I have a working mzp system now, what a journey that was. You guys have some great ways of getting things where they need to be. I hope you don't mind but I hacked together a hybrid of both systems? I'm so glad I could use normal maxscript instead of copying everything with mzp.run I couldn't believe anyone could use that to make a robust installer/uninstaller, turns out it was exactly what I was looking for.

It's going to be a lot easier to maintain. Thanks again!

Keen if you're talking about what I think you're talking about (soulburn script lister?) then I think you've got a great idea, I'll have to give it a try.

monster · Apr 2010

I use source control (Perforce) to update everyone's machines at work.

When max is first installed, I have them run a Setup.ms script that changes the $UserScripts, $UserMacros, $UserIcons, and $UserStartup directories to a folder under the source tree.

From then on when the users get latest in Perforce they get any new changes I made.

Also, I set a plugin folder under the source tree, so that if our game exporter is updated, everyone gets the new exporter. You have to put a little logic in their by checking the version and 32/64 bitness of Max to set it to the correct plugin folder.

The only quibble with this is that the $UserStartup folder is evaluated after the other folders. So you need to fileIn to re-eval any macros that use your startup functions.

But IMO Autodesk should change the evaluation steps so that the $UserStartup is next after the regular $Startup, or at the least, before the other user folders.

SyncViewS · Apr 2010

Hey Vig, I'm glad you nailed it! And I'm totally fine with any hack you came up to, the code I published is there to be used. The only reason why I decided to mask my current code is because I found out someone tried repeatedly to rip off part of it and claim it as his own. But still I'm willing to help and explain how I made things work.

I was thinking about version control, if you like to take another step, you could use an ini file containing the current version number of each script installed. MaxScript has a fair amount of simple and handy functions to write and read those kind of information. You could read the ini file, if present, before the installation and run the installer accordingly, then update the stored ini file.

mLichy · Apr 2010

Sick, I'm going to look all this over and get myself a .mzp file if possible

. Thank a ton guys!

SyncViewS · Apr 2010

SyncViewS wrote: »

.mzp cons:
- Its a pain to zip everything and rename the file just to test install.
Yes, it is, definitely! No workaround

I've just found out the whole naming and renaming hassle can be avoided using 7-Zip. You can directly open the .mzp file to add, remove and update files while running tests. Very nice.

renderhjs · Apr 2010

SyncViewS wrote: »

I've just found out the whole naming and renaming hassle can be avoided using 7-Zip. You can directly open the .mzp file to add, remove and update files while running tests. Very nice.

so can winrar, just drag files and folders inside the mzp and it replaces existing files within it without asking.

Xoliul · Apr 2010

Couldn't you also write a little .bat script that automates zipping and renaming ?

renderhjs · Apr 2010

TexTools works for me in that way that I develop and fix scripts from a local directory (somewhere on the desktop, myDocuments or some usbDrive).
upon executing the main TexTools...ms script it imports all the other scripts (for every tools and macroscript) using fileIn ... and because the last file I executed was that main TexTools file the 3dsMax last recent directory is set to that folder and so if I fileIn the other script files maxScript first searches for that last recent folder, that is if I use a relative url like just the filename.

In other worlds I can just work local in a relative space which is really convenient. Only when I wrap files up for a new release for other people I have to update the MZP file and redrag all those files into it.

One tricky thing was the setup installer I wrote for texTools as it depends on the system temporary folder and thus a chain reaction caused by the MZP behavior - but since it is now rather stable it doesn't take that long either extending or changing it. Anything from within that sub folder TexTools can always be evaluated from any extracted folder.

SyncViewS · Apr 2010

I always work in local folders outside 3ds Max directory structure and keep every path defined through custom "symbolicPaths". In this way I can archive copies of the whole develop folder and have every path working just by changing one line of code.

The mzp thing comes in the way only when I need to release a new version and test the installation. To prepare the files for shipment I got a script that replaces the symbolic paths with the final ones, then strips every unneeded part from the code, like empty lines, whitespaces, comments and so on, linearize it and encrypt, quite handy.

cw · Jun 2011

monster wrote: »

I use source control (Perforce) to update everyone's machines at work.

When max is first installed, I have them run a Setup.ms script that changes the $UserScripts, $UserMacros, $UserIcons, and $UserStartup directories to a folder under the source tree.

From then on when the users get latest in Perforce they get any new changes I made.

Also, I set a plugin folder under the source tree, so that if our game exporter is updated, everyone gets the new exporter. You have to put a little logic in their by checking the version and 32/64 bitness of Max to set it to the correct plugin folder.

The only quibble with this is that the $UserStartup folder is evaluated after the other folders. So you need to fileIn to re-eval any macros that use your startup functions.

But IMO Autodesk should change the evaluation steps so that the $UserStartup is next after the regular $Startup, or at the least, before the other user folders.

same sort of thing here.

we have mapped drive as perforce root, a single .ms file gets distributed to people and it loads in the scripts in precisely the correct order of our choosing etc. Restarting max after getting latest updates everything.

I have found that there are a minimum of 3 required stages for loading scripts -

1: all your shared functions, libs etc.,
2: scripted plugins which depend on stuff in 1, and
3: macroscripts which rely on 2, or 1.

With this method of control over loading files in your chosen order it is trivial to get things evaluated in the correct order.

Anyway, blathering now.

renderhjs · Jun 2011

because this thread is getting again some recent attention I wanted to point out that Herman a buddy from scriptspot wrote this maxscript manager that can wrap MZP setups for you:
http://www.norman3d.com/MaxScriptManager/
I think it deserves some attention as he put a lot of effort into the details that goes into distributing scripts like updates, managing them, uninstalling,...

video:
http://www.youtube.com/watch?feature=player_embedded&v=QuesnDk6sf4

Kwramm · Jun 2011

My biggest gripe with MZP - there's always people who don't get it. "drag into the viewport? what do you mean? can you help me? ooooh it's really that simple??" .... or.... "mzp? what I'm supposed to do with it? uhh no I didn't read the mail / readme that came with it"

I'm not sure how installation can be any more simple, but this always seems to happen. Maybe something called setup.exe is more foolproof.

renderhjs · Jun 2011

thats why people like me or Herman created gif animations like these:
v3.0_install.gif

Autodesk didn't promote the MZP archives themselves so well nor did the community in the past- but hey maybe things will change someday.
I am actually more allergic to exe and mse (encrypted) files

Slum · Jun 2011

renderhjs wrote: »

I am actually more allergic to exe and mse (encrypted) files

I have nothing to contribute to this thread, other than YES OMG FUCK MSE!!! I hate when I'm looking for little tips here and there, find something neat on scriptspot, and it it's encrypted. Argh - whywhywhywhywhy? If you dont't want people "stealing" your script, maybe you just shouldn't have released it. There's no practical reason to ship .mse other than paranoia and arrogance.

Ace-Angel · Jun 2011

renderhjs wrote: »

because this thread is getting again some recent attention I wanted to point out that Herman a buddy from scriptspot wrote this maxscript manager that can wrap MZP setups for you:
http://www.norman3d.com/MaxScriptManager/
I think it deserves some attention as he put a lot of effort into the details that goes into distributing scripts like updates, managing them, uninstalling,...

video:
http://www.youtube.com/watch?feature=player_embedded&v=QuesnDk6sf4

About Norman's Script, I couldn't get it work on Max 2012. I basically installed it, setup a few scripts including the GoMax and kicked off for lunch.

When I came back and started it up, it told me that there was an update for GoMax, which was strange since I had the latest version already, but not giving it much weight, I clicked Yes, and after a couple of seconds it tells me it failed to download file in local directory.

After that, the installation of my other stuff doesn't work (it flat out refuses) and no matter what I tried to debug, it kept on telling me to update with error, followed by 'locking' of the Manager.

I know I should be asking the author for what up with this issue, but clearly it's something that I'm doing wrong because Max 2009 and 2011 are in the same boat for me.

Before I start poking Norman, did any of you guys by CHANCE happen to trip on this issue? I watched the tutorial, and followed it to the letter, but I still couldn't get it to work.

Also, almost forgot, after the update fails, it doesn't show Norman's repo anymore, and if I right click on local drive scripts, the one that have the option of "Start" don't work anymore.

Cheers and cioa.

Nysuatro · Jun 2011

My roommate made this tool for creating maxscript projects and installers and ...
Just check out his website. He is currently working really hard on it to release it on of these days. http://sven.fraeys.be/mspm/

Norman3D · Jun 2011

Ace-Angel wrote: »

About Norman's Script, I couldn't get it work on Max 2012. I basically installed it, setup a few scripts including the GoMax and kicked off for lunch.

When I came back and started it up, it told me that there was an update for GoMax, which was strange since I had the latest version already, but not giving it much weight, I clicked Yes, and after a couple of seconds it tells me it failed to download file in local directory.

After that, the installation of my other stuff doesn't work (it flat out refuses) and no matter what I tried to debug, it kept on telling me to update with error, followed by 'locking' of the Manager.

I know I should be asking the author for what up with this issue, but clearly it's something that I'm doing wrong because Max 2009 and 2011 are in the same boat for me.

Before I start poking Norman, did any of you guys by CHANCE happen to trip on this issue? I watched the tutorial, and followed it to the letter, but I still couldn't get it to work.

Also, almost forgot, after the update fails, it doesn't show Norman's repo anymore, and if I right click on local drive scripts, the one that have the option of "Start" don't work anymore.

Cheers and cioa.

About GoMax notifying you of an update... I think it has nothing to do with MaxScriptManager. The other day I got the same message, I then realized my server was down, and because of a bug in GoMax it believes there is an update available when this happens lol.
Just drop me a PM and we can look into whatever problem it is your having with MaxScriptManager.

I think the main problem with MZPs is that there is no way of knowing what is going on when you are installing a script, or even before you install a script. I'd like to know what it's going to do. Encrypting the install script doesn't help either.
Perhaps it should be similar to when you are installing an extension for google chrome. The browser lets you know what information the script has access to before you install it.

Here are some other issues, some of them you have mentioned already.

- Users don't know how to install MZPs. Even drag & dropping seems to be an issue.
- No install/uninstall guidelines to follow. This means, there is no universal method of installing and uninstalling a script.
- You often have the issue with certain internet browsers when downloading a MZP file it gets renamed to ZIP. This can actually be fixed on the server's side by adding MIME types. But still this issue is not documented in the Maxscript Help.

Regarding the OP's post I would simply create a MZP with a "silent" install. No user input, unless it is needed. Submit the MZP to perforce, and make sure to create a startup script as well, that gets the latest MZP from Perforce and runs it.
Regarding version control, there are a lot of ways you could do this. You can have a INI file locally with the local script version and another INI file in perforce with the latest version, compare them on 3dsMax startup and if they are different, get and install the MZP.

If your script is some sort of toolbar for artist, it would also help to add a button automatically to the Main Toolbar. Even the task of finding the button in the Customize User Interface can be frustrating to some. And hey, if it can be done automatically, why not?

Maxscripts Use .mzp or .exe installer? What about version control?

Replies