ScriptCenter - Take back control of your maxscripts!


#1

For the past month, Jonathan de Blok and myself have been working on a new open-source project for 3dsmax. We’re quite excited about it, and we would like to share that with you guys. So let’s get right to it:

Currently, there are many issues with installing and maintaining MaxScripts:
-installing scripts is a hassle, uninstalling is even worse.
-no update push notifications
-most scripts have to be added to the user interface manually
-no easy syncing between workstations

Our objective is to address these issues by creating an in-max script browser. With it, we aim to ease and unify the way we use scripts in 3dsmax. The tool will provide a way to browse and install scripts, (automatically) track and install updates and completely uninstall any script with the click of a button. We call this the ‘ScriptCenter’.

The basic architecture of the system looks as follows:

The ScriptCenter gets the information about scripts from a file we call the ‘Script Manifest’ (or SM). This is a simple, human-readable file with things like the script’s name, author, description, etcetera. As a developer, you create a manifest file and put that on your webserver. A user points the ScriptCenter to the location of this manifest, and it will take care of everything from there.

An easier way for a user to get to a script is by browsing a repository (or repo for short). A repository is no more than a collections of links to SMs, and can be created by anyone. The repository is designed in such a way that there is only a single location for a SM, making it easy for the developer to update his/her script:

When publishing simple macroscripts that only have a single file, the script manifest and the script itself is all you need. However, for more complex scripts, we provide a tool to make a nice installer, called the ‘SCPacker’. This provides a way to wrap your script in a unified installer which can be run both by the ScriptCenter as well as standalone in just minutes:

SCPacker Preview on Vimeo

Back to ScriptCenter. There you’ll enter the URL of a Repo and all the SMs (or a subset for big Repos, more on that later) will be loaded. Remember that these are only small meta-data files and not the actual script files. Once the SMs are in it can display a nicely formatted list (think AppStore) of availabe scripts. You see a nice script and install it. It is then added to the local-repository, which is a list of installed scripts with the stored SMs, MZPs and installation logs for those scripts. These will be used again for uninstalling and update checks.
The locally stored SM is compared with the one placed online by the developer. If the online version is newer, the SC lets the user know an update is available, which can be installed with a single click. Optionally, this can be done automatically.
As a bonus this local repo is available on the network, so you can point other workstations on the LAN to this and get the exact same scripts that are installed on the ‘master’ workstation.

So, to wrap this up, the current state of the project: as you can see from the video about the SCPacker, the installer part of the project is coming along nicely. This also includes the basis for the ScriptCenter itself. There is still much work to do on the frontend for the ScriptCenter, which I will work on in the coming weeks.
We hope that you will be as excited about this project as we are, and it’d be great to get feedback, both from a user- as well as from a developer perspective!


#2

Oh and I almost forgot, it is an open source project, so you can check out the source over our on google code page: http://code.google.com/p/scriptcenter/


#3

And I want to point out that the installer can handle various UI placement methods and hotkey assignments as well.

Besides the easy install and update functionality, a system like this will make scripts more manageable in a professional pipeline across a whole studio.

For example when installing a new 3dsMax version you can use the SC to install all the scripts from the previous 3dsMax’s local repo with a few clicks. The same goes for a reinstall or for syncing scripts between workstations.

Also think about the benefits of an in-house repo, so everyone in the shop has easy and instant access to the developer’s latest tools and updates.

Like Pier said, some parts are still being developed so at this point any feedback or general thoughts about this project are very welcome!


#4

You rock! I need to take the time to read through everything but it sounds great, and just some days ago I was hoping to find a solution for installing/managing script the easy way :slight_smile:


#5

Sounds awesome, I was just starting to look at doing something similar for in-house use.

Could you point at a manifest file in a local network, UNC path, and have it get files through there as well?

is it one manifest per script, or for a package of scripts can you have a single manifest file?

Do you think there would ever be a need for versioning? ie if I updated a script but it doesn’t work as well as the old, would it be possible to revert back to a prior version? I can’t say this would be a big need, I don’t know if I’ve run across this before, just something I was thinking of when reading your description.

VERY interested to see how this develops!


#6

Yes absolutely. Any valid URI should work. The same goes for links to a repository.

is it one manifest per script, or for a package of scripts can you have a single manifest file?
One manifest per script. If you’d like to ‘package’ scripts I guess the easiest thing would be to create a repository. There will of course be an editor for that as well. And I guess we could have a “install entire repository” option in the client.

Do you think there would ever be a need for versioning? ie if I updated a script but it doesn’t work as well as the old, would it be possible to revert back to a prior version? I can’t say this would be a big need, I don’t know if I’ve run across this before, just something I was thinking of when reading your description.
Yes, we didn’t mention this explicitly in the opening post, but there will be support for this. It would indeed be nice to have old versions and beta’s available next to the ‘latest release’. Another scenario where this would be useful would be scripts that have different versions for different 3dsmax versions. Or the 3dsmax compatibility might be limited as the script is updated.
The script manifest will take care of this by being able to link to multiple script/installer files (see first diagram).


#7

That actually sounds pretty cool. I’ll have to check it out.


#8

Sounds fantastic! The UI management alone sounds like it would be worth me rewriting my stuff to suit…


#9

Actually, for developers there will be very little to no ‘rewriting’ required. For a simple script (i.e. single macroscript), all you’d need to do is create the script manifest through a tool we’ll provide.
For a more complex script that requires some installation logic, you’d have to pack it in an installer. So unless you’ve made your own installer, the code of your scripts won’t have to change at all.


#10

that sounds totally awesome and like it could revolutionize the way we - everybody - works and interacts with scripts.

I will definitely watch the progress you make and recommend everybody i know to do so. I hope you guys can achieve your goals. Would be great!


#11

I did a bit of work on this, changing the SCPacker interface to support multiple versions:


#12

Quoted for awesomness. I keep coming back and re-reading this thread to make sure I understand how it works as I think of other potential uses for it. I realized this then become the first step towards transferring a lot of my customization settings to a new version of Max. A lot of my upgrade pains come from having to reinstall all the scripts I run, and easily tracking/moving that to new installs will be sweet. Definitely let us know when you have something ready to test, can’t wait to see this.


#13

Thx! We are working hard to make it all happen, even as I write this. (By ‘we’ I actually mean Pier since he’s doing all the actual coding, I just think hard :slight_smile: )

Right now we’re discussing different options and interfaces for a unified developers tool. I think we’ll have some new screenshots to share in the next few days…


#14

Keeping eyes on, this sounds real interesting :slight_smile:


#15

Awesomeness is kinda what we’re going for actually. :slight_smile:

I’ve uploaded two small videos showing some more of the developer area:
Creating a repository
Setting up a toolbar
The second one (toolbar) is just to show some of the details we’re trying to get right from the start. I think that it is really important to get the tools to work as smoothly and effortlessly as possible. So I’m spending quite some time on little details such as the in-editor help section and being able to select the toolbar name from a previous action when adding buttons, instead of having to retype it. It’s just a little thing, but I hope that things like this will make it more easy to use.
I’m for example also thinking about doing a similar thing for the macroscripts, so that instead of typing the name, you just pick them from a list of files that will be copied with the package.

Tomorrow there will probably be a more extensive video showing more of the work that has been done on the dev area, so stay tuned!


#16

This is such a great idea. I really hope this gets momentum with script developers. With such an ease of use, and with so many benefits, there’s a good chance we’ll see some manifests along with our scripts. It’d be cool if this project were featured on ScriptSpot :smiley:

Also, the fact that it’s open source is crazy beautiful. Any systems admin who needs a little something different can dig in and create their customized version. And if there’s some nice code which they can share back with you, it’s all the better.


#17

If all goes well it will be more then featured :wink:


#18

Alright, I’ve been doing a lot of work on the developer environment over the past week. It is going pretty well, and things are starting to work quite smoothly. Creating a package can definitely be done in just a couple of minutes if you kinda know the interface.
To give an idea of the current state, I’ve made some videos:

  1. Creating a manifest for a simple script (i.e. a single macroscript)

    To ‘publish’ a script like this to the ScriptCenter, all you have to do is create a manifest for it, so that it can be identified and version-checked. You won’t have to worry about the installation, that will be handled automatically by the ScriptCenter.

  2. Creating a manifest and script package for a complex script (i.e. multiple script files).

    To publish a more complex script which requires installation logic to the ScriptCenter, you create a package. In here you set up the manifest and installation actions. As you can see, I create a complete installer + manifest in less than 3 minutes. Of course I knew exactly where I could find everything, but comparing that to what used to take writing hundreds of lines of code, the benefit is obvious.

  3. Updating a script package and exporting a new version.

    When you have created a script package and you update your script, it is ridiculously easy to push the update to the ScriptCenter. If you name your source folders with some thought, it is simply a matter of adding a new version to the manifest and exporting the new package.

edit: the video quality is a bit crappy, I’ll see if uploading an uncropped version will work better with Vimeo.


#19

Looking good!


#20

Cheers. The open source thing is a bit of an experiment for me. I think it’s not just nice from an altruistic point of view, but it also helps me to be more active in keeping the code clean and documented.
What also helps is that I’ve started doing TDD (Test Driven Development) recently, where you write tests before writing code. I hope that this will improve the code quality and so far my experiences with it have been really positive. The unit tests are of course available with the ‘normal’ code.

We would really appreciate more input by the way. It can really be anything, general ideas for features, or UI designs, etcetera. More concrete contributions in terms of code, or graphics would be great too of course.