Modo python code : adding newer versions

Deadline
1

It seems to be quite involved to add new versions to the Python code for modo in Deadline (e.g. separating 901 from 902). I wonder if this could be made easier / documented:

  1. Modo.param has to be tweaked to add a new section (e.g. [RenderExecutable902])

  2. The submitter has to be tweaked to add a new entry in the drop-down. Bear in mind that stepping away from the ‘Yxx’ format, where Y is a number, causes massive problems. Since we’re at version 9 (i.e. 9xx), there’s little room for maneuver. See (4) below for the implications.

  3. The submitter has to be tweaked to define the corresponding field of ‘formats’ to match the new entry in the dropdown. If you don’t do this, the submission dialog won’t come up and no error is shown. You have to look at a console to figure out why it’s complaining.

  4. Modo.py needs to be massaged heavily if you step away from the three character ‘Yxx’ format - it’s liable to break spectacularly because it’s not been well designed.
    In the case of RenderExecutable902, I ran into trouble when I tried 902 instead of 9xx (it evaluated the same as 9xx and things went wrong) or 10xx (which turned into the same as 1xx and as that wasn’t defined, the code blew up elsewhere).
    The annoyance here is reported in a separate thread, but it’s made worse by the varying use of an integer cast or a string depending on the function in question. It took a while to figure out why RenderExecutable10xx was being turned into RenderExecutable1 and then a game of cat and mouse to find all the repeated cases of similar code that were blowing up in different ways in this file.

In general, there’s no exception handling in the Python code, so errors are not reported in a useful way to the user/tinkerer. That’s a little unfortunate.

It would be helpful to have some overall guidance, unless it’s not intended for users to hack these files around.

2

Hello,

In general we only support plugin entries for the major versions of Modo, 9xx, 8xx, etc, simply because in most software supporting a minor version, which we would expect a 901 vs 902 to be, would lead to a very cluttered plugin config and would use a lot of developer time for very little change between minor versions.

As for documenting hacking of the plugins, that is not something we document as it is not something we can support, due to the many complications that opening such a door would bring from a support aspect.

Regarding errors, many of our plugins have error handling, including the Modo plugin, but if there are errors you are seeing that are not being caught, please let us know. If we know the cause of an error, though, we do try to explain it, or at least identify the cause of the failure by printing the last few lines of the log before the failure.

One thing some people do to have something like what you want is to put the primary one in the actual entry, which can be submitted from the integrated submitter, then using one of the unused entries in plugin config for the other version, which would have the job submitted from the monitor using the drop down for version.

I hope this helps.