Ability to export graphs as closed node networks, so other users can utilize nodes in their graphs without having access to the inner workings of those graphs. (I.E. .sbsar files for Substance)
Justification
It will provide InstaMAT authors the ability to develop nodes that they can provide to others, without having to offer up access to all of the source code/nodes.
Implementation Details
Ideally it would be an option in the File menu. This may already be in the works, I know it was mentioned in a livestream that it was already a consideration, however its implementation would be a major boon for authors that intend to develop utility nodes for others to use.
Perhaps this would be a nice feature for the paid version. On the other hand, such solutions close access to the structure of the tool, which does not allow using it in commercial projects, as there is no possibility to modernize the tool for certain conditions. But if such “closed” tools will be free of charge, I see no reason not to do it. If you want a free implementation of the material, here is a closed access to the graph structure, if you want a paid one, here is an open functionality and change what you want. Objectively it is correct. Probably under the condition of changing the user agreement, it’s possible to do it. Again, closed tools that are no longer supported by the developer over time may cause bugs. If MAT changes something in its API and you stop updating your graphs, then the person who bought your product will be left without support in a year, and he will not be able to change the file himself. I will support you, but I think it is necessary to approach this problem comprehensively.
I understand the concern. I feel it maybe lies outside the scope of simply creating closed/compiled node functionality though? It sounds to me like your hesitancy isn’t really with how this would be implemented by InstaMAT, but rather the ecosystem that would evolve around it.
Right now I work with a team that uses SBSAR files I’ve created. I’ve opted for SBSAR so that there is zero chance they will accidentally alter source files and mess up nodes for the entire team. I think having this functionality would be tremendously useful for instances like this.
API changes potentially breaking things will be incredibly frustrating, I completely agree. Unfortunately that’s inevitable and I’m not sure what a catch-all solution to that would be? I think that’s the risk you take when buying 3rd party nodes that don’t offer open/uncompiled graphs.
Now that it’s cooked, the user can copy the IMP to his library in Documents/
Once loaded it will show up in the library and it can be used like any other node:
Cooking projects that reference a securely cooked library package project
If you cook a project that uses a node or project from a cooked package, MAT will not include that project in the project that is now being cooked. This is done to avoid leaking of data but causes a hidden dependency as a project that has a dependency on your cooked library package may not load if your cooked package that contains this dependency is not available in the user library.
Are there other ways to crack open a securely cooked library package?
I’m not aware of other ways to open/load/inspect/extract data from a package so I believe this is secure and implements the requirements.
