thanks ivanisavich
I was thinking about similar approach too. But it doesn’t solve one of my issues that I want to have simple.
To load and execute this DLL (loader) you have to specify “system path” anyway for every machine in advance.
I have in my package some .NET dlls, and load them on-the-fly (which is not a problem and they don’t need a system path(s)). Also I have some another “loaders” in the package those load icons, default textures, shaders, macros, etc.
But with the most recent framework I avoid loading anything on-the-fly, and try to delegate all to the MAX.
Another problem is to load custom DLX … hmm… I don’t see a way to load my MXS extension plugin after max startup. It might be specific for my plugin content but… it’s how it is.
Not sure I understand what you mean, but it’s worth noting that loader I mentioned does all the loading of other DLLs right in the LibInitialize call during startup, with direct calls to LoadLibrary. So initialization of secondary DLLs happens during the initialization of the loader itself when Max starts, not on-the-fly later if the class is needed by max.
But MAX has to know where from to load this DLL, right? The path has to be specified as Third-party paths or use one of defaults. Do I miss anything?
Currently the installation and updating looks this way:
- I wrote my own “Installer” on C# (the main reason for C# was that I just comfortable with C# coding).
- I have a batch file in the package which runs installer with some keys (for default user the keys are always the same, but it give a way to customize installation if necessary)
- I have archived package which is all my tools, shaders, textures, icons, plugins, etc.
I need to update only this Package. Different studios use their own way to update it, but in theory the Perforce should be used.
MAX must be closed. Version of MAX specified by the Package. That means one package to every version of MAX.
The Installer founds all MAX directories and ini files I need. Also it finds the current user.
The Installer deletes all old versions of my tools, old system and user paths to my old versions.
It sets new paths, extrudes the Package content to user’s local directories, and optionally runs the MAX.
There is an option to just Clean everything (delete all about the tools and related paths).
That’s kinda it
No, you are correct. Machines must know where the loader is, even if it’s put in their local plugins folder. The reason for using the loader is solely to avoid file locks when updating plugins on a network share. Its purpose is not simply to automate the process of loading plugins in general.
got it.
That’s one of the reasons for me to put whole package to the local machine.
So, there is a step – specify a system path (3rd-party) for every machine. That’s what some my clients found complicated