Join our discord community

Forum breadcrumbs - You are here:ForumPrism: Generalmaya script path append
Please or Register to create posts and topics.

maya script path append

PreviousPage 3 of 3

after some test, I ran into the same problem you got about the wrong path being appended to maya_plugin_path and the rest, it seem that when using the loadModule command, the basepath used for the relative path is the path of the last module that have been loaded instead of being the .mod file.

it can either be a bug or maya, or maya is simply not designed to have a .mod use a relative path to define the root of the plugin folder (the relative path is designed to specify different folder inside the plugin root himself).

problem with maya plugin is that the developer usually implement them the way they want :

for exemple, installing yeti require you to extract their plugin somewhere and then edit the .mod file yourself to point to the extracted directory

other plugin come with installer that automatically setup the path inside the .mod to point to the right directory.

 

ultimatelly, that would mean that if prism have to inject such plugin himself to maya, then the user will have to edit these .mod file manually first to accomodate prism, or have prism parse and edit them by replacing every path, and hope for nothing to break in the process.

some .mod file can be complicated, as an exemple with the ornatrix plugin :

+ MAYAVERSION:2015 Ornatrix 2.2.5.17957 Ornatrix
plug-ins: 2015
[r] scripts: scripts
PATH +:= bin
PYTHONPATH +:= bin
MTOA_EXTENSIONS_PATH +:= 2015/extensions
ORNATRIX_ARNOLD_PROCEDURAL_PATH := 2015/procedurals/OrnatrixProcedural.dll
+ MAYAVERSION:2016 Ornatrix 2.2.5.17957 Ornatrix
plug-ins: 2016
[r] scripts: scripts
PATH +:= bin
PYTHONPATH +:= bin
MTOA_EXTENSIONS_PATH +:= 2016/extensions
ORNATRIX_ARNOLD_PROCEDURAL_PATH := 2016/procedurals/OrnatrixProcedural.dll
+ MAYAVERSION:2016.5 Ornatrix 2.2.5.17957 Ornatrix
plug-ins: 2016.5
[r] scripts: scripts
PATH +:= bin
PYTHONPATH +:= bin
MTOA_EXTENSIONS_PATH +:= 2016.5/extensions
ORNATRIX_ARNOLD_PROCEDURAL_PATH := 2016.5/procedurals/OrnatrixProcedural.dll
+ MAYAVERSION:2017 Ornatrix 2.2.5.17957 Ornatrix
plug-ins: 2017
[r] scripts: scripts
PATH +:= bin
PYTHONPATH +:= bin
MTOA_EXTENSIONS_PATH +:= 2017/extensions
ORNATRIX_ARNOLD_PROCEDURAL_PATH := 2017/procedurals/OrnatrixProcedural.dll
+ MAYAVERSION:2018 Ornatrix 2.2.5.17957 Ornatrix
plug-ins: 2018
[r] scripts: scripts
PATH +:= bin
PYTHONPATH +:= bin
MTOA_EXTENSIONS_PATH +:= 2018/extensions
ORNATRIX_ARNOLD_PROCEDURAL_PATH := 2018/procedurals/OrnatrixProcedural.dll
PRMAN_EXTENSIONS_PATH := 2018/extensions

I think prism shouldn't handle dynamically load plugin into maya this way, and probably be simply setup to add environement variable automatically to either windows/linux, or edit the Maya.env to add a set of predefined path. and not try anything fancy. or you're never gonna see the end of it.

 

here is a nice maya plugin with a free version :

https://www.ngskintools.com/

but again, remember that a lot of plugin are never built the same way, and their folder structure may vary a lot.

I agree with SciMunk, (though I'm a bit on deep water here, not knowing the technicalities of this part of Maya) I think it would be too much to make it work for big plugins like Ornatrix, because they are so complicated, and you need to install in a very specific way to make it work on a server - and need the license server also set up that way. It would be super awesome if it worked, and the same with redshift, but just saying that I guess it's not first priority because of the complexity.

I would say the most important thing to have is the ability to automatically load mll's from scripts that have custom nodes that the animators need to read in order to use the rigs, like tx_stickyController, mGear, braverabbit weightdriver and ngSkinTools to name a few. So again, not the whole user interface, just loading the custom nodes so that all the scenes open and run fine.

I tried the rehash function, but it didn't change anything. I think it's only for mel scripts.

Simple .mll files work without problem in the next version. Place them in \00_Pipeline\CustomModules\Maya\plug-ins and everyone has access to them, since Prism adds the path to the MAYA_PLUG_IN_PATH and MAYA_SCRIPT_PATH.

For the case that someone wants to place a plugin in the Prism project, which requires a .mod file I added a new button in the Prism Settings dialog. When the Prism Settings get opened in Maya, in the DCC apps tab under Maya there is now a button which adds the \00_Pipeline\CustomModules\Maya\ folder of the current project to the Maya.env file. You can place different .mod files in that folder, but Prism also creates a default .mod file. After a Maya restart these .mod files get read by Maya. But again, this button is only needed for plugins, which require a .mod file and not for simple .mll plugins. I don't know if anyone will ever use this, but now it's there ?

Uploaded files:
  • You need to login to have access to uploads.

That's fantastic Richard, thank you!

I just updated the prism install with the latest version from the repository, does that one have this feature added?

No, but I just pushed the version with that feature to GitHub. So you need to update again, but you can do that with one button click like I described in the MAYA: Simple Reference Option thread.

Works like a charm!!! The sticky mll loaded automatically from the prism project 🙂

Is the 'add current project to maya module path' button gone? I can't see it in the latest version. And the '00_Pipeline\CustomModules\Maya\plug-ins' is not added to the env file anymore. Did you change the way Prism set this up?

No I didn't changed anything. The "add current project to Maya module path" button is only visible when you open the Prism Settings inside Maya. But you only need this button if you plan to use .mod files. Even without using this button Prism appends 00_Pipeline\CustomModules\Maya\plug-ins to the Maya plugin path. Prism doesn't write anything to the env file, but it modifies the MAYA_PLUG_IN_PATH environment variable during runtime. Does it not work anymore to place the .mll file in the folder?

Ah, I see, that explains it. I was looking for the path in the .env file. Then it must be the .mll file that I tried to add that didn't work. Thanks for the explanation!

PreviousPage 3 of 3