Not sure if that would work for you guys, but we maintain the main deadline plugin code in subversion here. The official thinkbox versions are in a branch, while our customized versions are in the trunk. Whenever a new version comes out, we commit that into the branch then merge the codebases. So far its been the easiest way to maintain our changes.
Although, some of the refactoring that you guys have been doing in the 3dsmax submission scripts can look scary in an svn merge 
Hey guys,
thanks a lot for that input. SVN/Git is basically what i was having in mind when thinking about how to deal with things like this. Honestly though, i think it’s “shooting at sparrows with cannons” as we say in Germany 
when it comes to something as simple as wanting to change a setting like this. Also, we’re a small facility. Not saying that the know-how isn’t there but every additional thing like this adds some ‘not too welcome’ overhead. I understand Ryan’s concerns regarding a global override as it’s absolutely true that not all processes will benefit from this. We never had any issues with processes running on ‘low/idle’ but i’m sure there are some out there which will not like it. If i could choose i think the ideal case - at least from my point of view - would be this:
The checkbox in 2) should most likely be checked by default - people dealing with a setting like this will most likely/hopfully know what they’re doing, so out of the box you’d have the same behaviour as just now but also more flexibility.
Just to give you some info why i was expecting this to work differently: with Backburner all the processes that the Backburner Server (the equivalent to the Deadline Slave) launches will inherit the priority from the Server process. We were launching this on all the machines by “start /low …server.exe” which was a very easy and convenient way of influencing and controlling this.
As a more general and kind of related question, what is actually the recommended way for dealing with customizations? It feels a bit cumbersome to me going the SVN/Git way to deal with this. Shouldn’t or actually isn’t it possible to just wrap the submitters, plugins,etc. into our own submitter scripts that just load/import the actual python modules and we can pass certain values that way? Sorry if this question seems a bit unusual, it’s because a) i’m not a professional Dev/Programmer and b) haven’t gotten to the Python docs yet.
Btw., 3) also reminds me of always wanting to state that it’s not always perfectly clear and intuitive to me where to look for a specific setting. E.g. there are the “Pulse Settings” in the “Repository Options” and then there’s the “Pulse Panel” where you can also configure Pulse-related settings. I think i know that you probably want to separate the general settings from the machine-specific ones but it somehow feels quite cluttered to me.
Sorry if i was a bit elaborate and drifting away from the initial subject with this post but all this (i.e. Deadline) is still fairly new to me and there are a lot of questions/thoughts/ideas about it every day
Cheers,
Holger
Hi Holger,
We can put the idea to expose process priority on the wishlist, but I’m not sure where it will fit on the roadmap (I would consider it a lower priority item). While the issue has come up a few times in the past, it has always been resolved by simply changing the setting in the plugin itself. The main reason we went with a scripted plugin system was so that end-users can tweak and customize the out-of-the-box plugins to meet their needs if necessary, and while it might start with simply changing the process priority, you might choose to customize things more and more as you become more familiar with the system (ie: custom submission scripts to streamline the submission process).
The solutions that Mike and Laszlo proposed are the typical way studios handle customizations. As you start writing your own code, you’ll want to version-control it, and back it up, and version control systems like Git are ideal for this. They also allow you to compare what’s changed with each release so that you can merge them with your changes properly.
With regards to the location of the settings, we appreciate the feedback. Typically, if it’s a global setting, you’ll find it under the Tools menu in the Monitor, and then item-specific settings can be found in their respective panels. We wanted this consistency between panels in hopes that it becomes more intuitive as you get used to it. With Pulse, for example, Deadline 7 is the first version to offer individual Pulse settings. We wanted these to be in the Pulse Panel because this is how the slaves panel has always worked since Deadline 1, so our hopes was that if you were familiar with the slave panel, you’ll easily figure out how to use the pulse panel. Now obviously it’s different if you’re coming from a different render manager, but I just wanted to provide the reasoning behind our decisions.
Definitely keep questions/thoughts/ideas coming in! Deadline’s development has always been about listening to our users!
Cheers,
Ryan