Hello,
We’d like to modify our MayaBatch UI to expose more attributes. We use Perforce and all our developers have their own source code repo.
Is it possible to have Deadline look at a specific directory under a programmer’s repo, instead of (or in addition to) the default plugins directory
to get/read the MayaBatch set of files? (.options,.params,.dlinit,.py,etc)…so that the development would not affect all our other users out there
who are rendering and picking up the default MayaBatch files in the main Deadline repo…
We thought this was possible,…but we’re having a devil of time making Deadline point to another folder to get these files…
Is this even possible? or must all development take place in the main Deadline repo in order to show up in Deadline Monitor ?
If so, is there documentation for how to do this? and/or can someone describe or elaborate about how to accomplish?
We’re using Deadline 6.1 and Maya2014 in Win64 environment…
Btw,…I am aware that in the ModJobProperties window, under Environment, top line custom plugin directory,
but modifying this doesn’t seem to change anything…as our custom modifications don’t show up…
There is a “custom” directory in your repository path, where you can duplicate application plugins, event plugins, submission scripts, etc - just ensure they are placed in the corresponding directory. If the script/plugin files you place in the custom directory are exactly the same name as the ‘shipping’ versions in the ‘normal’ directories, then the custom version will take precedence. So, if you were just to temporarily re-name the files to something slightly different, then they could co-exist in the custom directory. Although, this is no different, than if the files existed in the ‘normal’ directories, you can be rest assured we won’t overwrite any of the files in the custom directory if you run a repository installer upgrade or downgrade. We do backup the custom directory to the “backup” folder just to be useful.
At no license expense, you can setup another deadline repository alongside the existing production version. This could be a ‘local’ version installed on a developers machine or a network version for wider use. This would effectively ‘sandbox’ your development team and therefore do no harm to production.
I take it to mean the “custom” directory in the Deadline repository,…(as opposed to our Perforce code repositories).
So if I’m understanding you correctly,…you seem to imply that new, custom plugins must be developed in the custom directory
in the Deadline Repository and no where else…is that right? They can’t exist in another directory somewhere in another source code tree?
If that is so,…and assuming I slightly renamed MayaBatch.options to MayaBatch_B.options,…if there’s a coding error in MayaBatch_B.options,
won’t that adversely affect all other render users? possibly causing all their jobs to fail ? Which is obviously what we’re trying to avoid…
If that’s not true,…how do we point Deadline to look into another directory that may be located in a arbitrary directory somewhere ?
Is it really true there’s no way to develop custom code/plugins unless they are “live” so to speak?..that would be a real shame if that’s true…
I’m sure you realize what we’re trying to do,…develop off-line so that coding errors don’t bring the queue to a screeching halt…thereby causing mass hysteria
Hey again Mike,
One of my co-workers here asked me to clarify a couple of important points that I misunderstood or wasn’t clear on,…
We are indeed able to pass along to Deadline in a job submission, a path to a code tree (outside of the Deadline tree)
where customized versions of MayaBatch (and others) are located,…and indeed Deadline is correctly loading these.
What we’re unable to accomplish,…is modify the actual UI elements in, for example, the ModifyJobProperties Window->MayaBatch sub-window
For example,…if I goto the Deadline Repository->plugins->MayaBatch, open MayaBatch.options in a text editor, and modify line 3
from:
Label=Scene Filename
to:
Label=Scene FilenameX
then run Deadline Monitor, open ModJobProperties Window->MayaBatch,…I’ll see that “X” in the UI Label…
However, if we try to do the same thing from a custom plugin location (using a “Z” instead),…the “Z” does not show up in the UI Label.
So while later on I’ll be adding code to expose Maya/Arnold attributes,…right now, as an initial step, we’re just trying to modify the UI Label of the ModJobProperties window
from a custom plugin, located in a directory not in the Deadline tree,…and not having any success,…
Any thoughts or suggestions?
This isn’t currently supported as we could be crawling unknown number of file paths looking for the correct file to effectively use as our UI creation mask, if this was exposed. It would also mean we would need to handle the situation of file conflict when 2 or more of the same file exist outside of the Deadline eco-system. Presently, we only consider our default location and the custom location. The custom location overrides the default location if the file is present in this directory.
I would recommend my previous suggested option #2 and setup a completely separate deadline repository ‘dev’ branch. I sense you are worried about touching any element of production and this would be the safer route to go as it sandboxes your developers. There are added advantages such as, it could be an area for sysadmin’s to see the effect of making a global change to a deadline repository setting prior to production deployment, you don’t need to rename any development branch plugins, event plugins, etc. As the names are the same, it’s easier to setup a source control ‘branch’ in SVN, GIT, etc. When ready to test, it’s also easy to bulk move/reconfigure a couple of slaves or more, to point to a different Deadline repository path, pick up the ‘new’ plugin code, see how it works in the rest of your pipeline environment, without jeopardising the stability of the other slaves. If your happy with the initial test, keep scaling with more nodes OR commit to deploying your updated/customised plugin into the “/deadline_repo_path/custom/” directory. Bear in mind, that as we continue to enhance/change the ‘shipping’ versions of our plugins, scripts, etc - that your ‘custom’ directory based plugin/script will remain untouched by us - HOWEVER, if the above approach is taken with a GIT/SVN branch, then it makes the ‘merging’ of our updated future code into your custom branch a lot easier to manage from a ‘developers’ point of view as as ‘code merge’ is a daily activity for these guys
By taking the above approach, UI labels in the *.options file, etc will all work in your ‘dev’ repository. You can also ‘open’ up Deadline UI permissions a little bit more to give your developers more freedom in the ‘dev’ branch if required.
Couple of questions about Mod Job Properties window/UI in Monitor,…
Whereabouts is the python code that handles/creates/displays this Modify Job Properties UI ?
we’ve added some custom entities and attributes to this list,…is there any way we can specify a checkBox, instead of comboBox ?
the exposed attribute groups/sections we’ve specified seem to be added in alphabetical order,…is there way to turn alphabetizing off ?
(This is the sections themselves, not the items within each selection, whose order can be control is “Index=”,etc.)
See here: thinkboxsoftware.com/deadlin … -_Optional
The *.options file creates the UI for each [KEY] you have in your plugin info job. See the section above regarding the *.param file, for all the options that are available with regard UI design.
Sorry, we don’t currently support a checkbox in the UI but if you set the “Type=Boolean”, it will create a drop-down list containing “True” & “False” only, which provides the same functionality.
Order per section or as you have discovered by item can both be controlled. See the link above and this link for more info: thinkboxsoftware.com/deadlin … -_Optional
Essentially, you should use:
CategoryIndex - This determines the control’s order under its category. This does the same thing as Index.
CategoryOrder - This determines the category’s order among other categories. If more than one CategoryOrder is defined for the same category, the lowest value is used.
We’re making a custom MayaBatch plugin to expose more Arnold attributes…
When opening ModJobProperties window, when we click on MayaBatch in the left hand list window,
then we see all of our newly added properties on the right, right?
But it’s a lot of information,…our supe is asking if there’s anyway to present this window with all
the Categories *collapsed". There is a RightMouseButton pulldown that will collapse/un-collapse all these,
but is there anyway to make them collapsed as a default ?
Sorry, there’s no way to make it a default at the moment, although this does sound like a good idea. ie: make the dialog remember whether all parameters are expanded or collapsed between sessions of opening the dialog, which would then work between selecting different jobs as well. I’ll add it to the wishlist.
