A few weeks back I started a new open source project together with Jonathan de Blok (jonadb) which aims to bring the way we browse, install, update and uninstall maxscripts to the next level. Part of this project is the creation of a generic installer for maxscripts. Since this part of the project is primarily targeted at developers, it would be great to hear your ideas. Hence this thread.
What do I want to achieve with this project?
In short: standardized script installation. I would like to see all maxscripts come with an installer which cleanly and effortlessly installs the script in the right place (e.g. userscripts). It should be equally easy to uninstall the script, without a mess being left behind. Creating an installer should be easy for a developer too. I would like to have a tool with which one can create a complete .mzp that takes care of installation and uninstallation, including a standard UI, in under 10 minutes.
The concrete goal:
A simple tool with a user interface allowing a developer to create an installer for his/her script. The installer will work based on ‘installer actions’ selected by the user, such as “copy directory”, “assign hotkey”, and so on. These actions function for both installation and uninstallation.
The current concept:
-General information about the script (e.g. name, version, author) is entered in a UI, then saved in a manifest file. This manifest will be packed in the .mzp and used to populate a generic UI.
-A number of “installer actions” are created in the tool’s UI, which define how the script is installed. These are saved in an installer configuration file, which is also included in the .mzp and used by the installer to install the script. These actions are used both for installation and uninstallation.
Currently, the available actions are:
- Copy a single file.
- Copy a directory. (target directory is a 3dsmax directory such as userscripts).
- Assign a macroscript to a hotkey.
- Run a maxscript (for any non-standard installation actions).
If you’re interested in the code that has been developed so far, take a look at the project’s google code page: http://code.google.com/p/scriptcenter/
So my question to you is: what would you like to see in an installer like this?
What kind of functionality and features would you expect it to have?
Are there any other installer actions that might be useful?
I’m using the nullsoft install system, with some additional mzp to create menu entries.
It’s free and very robust.
It seems to work well for my latest script: http://populate-3dsmax.com/
although I don’t have much feedback yet.
Previously I used mzp for file operations too, but since windows vista, this is problematic with UAC, security settings, etc.
Ohhh thank you so much, I was looking for this a few weeks ago and since I didnt want to use the nullsoft one I’ve abandoned the idea… I’ll use this one for sure! Thanks!
Yes there are ‘standard’ windows installers too of course. I can’t say that I’m fond of them for installing maxscripts though. It might work great, but to me it always feels like it could do much more than I would want it to. I much rather have the installer work ‘within’ 3dsmax.
It could be interesting to look at how nullsoft handles things though, and get some ideas.
Anyway, this installer is going to be part of a larger project which will ultimately get rid of the standalone installer altogether.
@Kameleon: cool If you have any specific requests or ideas, just let us know and we might be able to incorporate them.
Edit: Read this to fast. My old comment doesn’t apply. Hopefully I can help out as well.
Nice initiative!
-Johan
P.s. Any change you guys will be at EUE?
I think actually your blogpost you linked to addresses a similar problem that we would like to address. (Although not directly with this installer part, but it will be part of it).
You are very welcome to contribute, by providing ideas, feedback, or actual code.
P.s. Any change you guys will be at EUE?
I won’t be in the country then, but maybe Jonathan will attend?
Nice to see you on the speakers list there by the way!
Nice initiative!
Reminds me of this project, don’t know if it is still active though.
http://www.polycount.com/forum/showthread.php?t=82857
If you need an extra hand, i’ll be glad to contribute : )
Yeah we’ve been talking to Norman about that project when we found out about it.
If you need an extra hand, i’ll be glad to contribute : )
Cheers. Right now we’re mainly looking to establish a set of core features and get the basis going.
For the installer specifically it’d be great to hear any ideas and wishes from devs. So if there’s something that springs to mind, don’t hesitate to post it!
I like the “script feedback” post on your website by the way. I was thinking of providing something like that, perhaps in combination with a generic version of the crash report feature from the Outliner. But that might be outside the scope of this project
My main problem was/is distributing scripts/tools/icons/extra software etc etc. on all workstations. For this an installer is just not going to cut it. It won’t follow my conventions as a benevolent dictator of tools in our shop. The installer is great for one offs and outsourcing to freelancers and taking it to scriptspot and such. So if you want to tackle the problem I had and to some degree still have (no support for mr shaders yet), the installer is something I don’t really see fitting in the whole picture of a studio pipeline. I would first set some conventions on how scripts “should be made” or what tools to use (header data for example (what I do now) or a metadata tool that can service both the installer and the distribution tool).
Maybe the mzp can also be distributed in a studio situation without manually installing a script.
Some random thoughts,
-Johan
Im with you on this – installers suck. I’d rather see some sort of ‘service’ you log on to, check the scripts you need to use and fire and forget. Some sort of central repository that everyone can access and a ‘load, update & remove’ feature – essentially asset tracking for scripts. – Then its just a case of telling someone to log on and install a service – updates could be pushed automatically too on logging on.
hmm… isnt that the plugin manager…ish
As to .mzp’s – i edit them in notepad and remove anything zippish before running them. Usermacro’s are a pain in the ass alone without having to remove scripts your were just testing.
that’s exactly what i’m talking about. mzp is so simple for any beginner. they’re copying there everything found in forums and other resources – toolbar setup, hot-keys assignment, startup scripts, blah-bla-blah…
i can’t trust mzp because it’s so easy for developer to leave droppings there.
Yes you’re absolutely right there Johan. The installer is more aimed at providing artists (and everyone else using max) with a way to make sure scripts are properly installed. And to help in keeping 3dsmax clean when you no longer want the script.
As I mentioned, this installer is part of a larger project, which would take a much broader aim, managing updates among other things. And in that the installer will play a central role, only not as a standalone tool. I am designing the architecture with that in mind.
But more about that larger project later. I would like to get this installer up and running first.
Indeed, the installer is only half the plan, but should function standalone as well.
edit: I’m not sure I can attend the EUE either, I’ve got the date blocked for a vacation trip…
This is very cool! I look forward to seeing how this goes