Klaas Nienhuis
With 3ds Max 2014 Autodesk introduced a new channel to distribute scripts: the Autodesk Exchange Store. This store already existed for other Autodesk software but is new to 3ds Max.
To get your script up there, it needs to be put through some sort of approval process and you need to fill in a bunch of information. I won’t go through that here, it’s pretty straightforward. However, I’d like to describe two three four things I’ve experienced when setting up scripts for the store.
Installation
The scripts from the exchange store use their own installer. The guys at Autodesk set this up for you. The installer uses a single new location to put your scriptfiles in: #publicExchangeStoreInstallPath. This is typically here: “C:ProgramDataAutodeskApplicationPlugins”. If you’re used to install your scripts with an mzp-installer and install your scriptfiles to several locations, this is a big deal. The installer from the exchange store doesn’t know about #plugcfg, #userscripts, #startupScripts or any other system directory. There’s just one location your files are in now: #publicExchangeStoreInstallPath. If your script depends on accessing files on these other locations, you need to figure out another way to get to them instead of using the system directories.
In my scripts I use a specific folder structure relative to the main script. I avoid using direct or symbolic paths to system directories by using getSourceFileName() on the main file. This gives me location of the file which is being executed and by using the methods from the pathconfig struct I have everything I need to get to my files whether they’ve been installed by my own installer or by the Autodesk installer.
Please not that you can use the system directories for files created after the script has been installed. If you’re storing presets, gui-settings or other files while the script is running, you can put these wherever you want outside the installation folder.
Updating
Most of my more recent script use an auto-updater. It downloads a new version of the script if available and installs it. At the same time it cleans away the older version. However, my installer installs to the #userscripts folder and doesn’t touch the #publicExchangeStoreInstallPath location. What would happen if a user installs my script from the exchange store and after a while updates it with the auto-updater? Right: he ends up with two instances of the script. The original script installed by Autodesk and the updated version installed in another place. This is a very bad thing.
This means that as a script developer, I need to take care of this situation. I have to disable my auto-updater and use the exchange store updater mechanism instead. At the same time I don’t want to maintain two versions of my script, which obviously is a pain in the ass to do. If a user decides to install two versions of the same script, he should at least be aware of it.
At the time of writing it’s unclear if the exchange store updating process has a way of notifying you if an update is available.
Version detection
It’s possible to differentiate between scripts originating from my own installer or the Autodesk installer without having to keep two versions of the script. After I’ve detected the origin of the script I can change the behavior of the script accordingly, such as toggling my own auto-updater. I’m using the following code for that:
if (maxVersion())[1] >= 16000 AND matchPattern (getSourceFileName()) pattern:((GetDir #publicExchangeStoreInstallPath)+"*") ignoreCase:true do print "Downloaded from the Autodesk Exchange Store"
Duplicates
You could distribute your script exclusively through the exchange store, however chances are big that you’re also using scriptspot, your own website and other channels to get your script out there. With my scripts, I can’t be sure which channel the user got the script from. I’ve written about the fact that the scripts install in different locations. This means that users might have duplicate versions of the same script installed. I can’t avoid this, but I have to prevent confusion. This can be done by changing the name for the script you submit to the exchange store.
When Autodesk compiles their installer of your script, they include a macroscript which is used to link the ui to your script. This macro contains a name and tooltip of the script. Make sure this is different than the macro you include with your own script. This will avoid confusion.
As an example, here are two macroscripts for my Augment exporter. One from my own installer, the other from the Autodesk installer. You can see that the name and tooltip of these macros differ.
Autodesk version
macroScript Augment_AutodeskExchange category:"Klaas Tools" tooltip:"Augment 2.03 AutodeskExchange" buttonText:"Augment" Icon:#("Augment",1)
(
fileIn blabla
)
My version
macroScript Augment category:"Klaas Tools" tooltip:"Augment 2.07" buttonText:"Augment" Icon:#("Augment",1)
(
fileIn blabla
)
2 Comments
Join the discussion and tell us your opinion.
Thx for the Info! Trying to get my stuff in there as well and you showed solutions to issues I didn’t even know I’d run into 🙂
Yes, it’s a bit underdocumented to say the least. I think I’ll also add a section about uninstalling soon (which isn’t too clean I must say).