AWS Thinkbox Discussion Forums

just wondering

Just out of curiosity, after upgrading deadline why are the settings made in submit dialogues not kept?
I use the import settings option via the monitor, which does let me keep all the slaves etc.
But the submit settings of eg. max are not kept.

It would also be great to be able to transport the monitor settings when updating the a deadline version.
Somehow the monitor (on the outside) doesn’t seem to have changed much, but the DL8 layout files are not compatible.

Starting with the submission settings here, they’re not kept I think because there is a purposeful separation between core and integration. The core code purposely doesn’t know a thing about the integration plugins, and for the most part that division is kept almost the whole way though (you’ll even see that in the job info files; “job info” is core, “plugin info” is integration).

There isn’t a hard standard on where sticky settings are supposed to go (I mentioned last week that some live in the scene files, some live in the “settings” folder). To get the import working correctly, we would have to force a standard on this one so I’ll discuss this with the head of integration and see if we can go down that path going forward. I think importing as much as possible is a good idea, but we’ll see where a good internal discussion goes.

As far as Montior settings, that’s unfortunately a Qt thing. We ask Qt to serialize the UI for us, and we re-load that data for your saved layouts. That’s great until the framework changes how they serialize those bits and we upgrade the core libraries. I don’t think we’ve actually changed the format that much since Deadline 6, but I do know that the serialization format doesn’t seem to stay consistent.

thanks for that elaboration, much appreciated :slight_smile:

I think in this increasing world of automation these things pop out where’s a long time ago you’d just be happy with something new that worked :slight_smile:
I noticed it at some point also with the beta, it’s almost too interrupting too ‘quickly’ update deadline as you feel you can’t continue where you left off.
In the perfect world there would be this awesome all inclusive auto update feature that’s fully customizable that would start the slaves, update them and just be done with it :slight_smile:

I absolutely agree with you there. The hard part is when we make changes to the underlaying data model. The major releases are where we really shake things up and it would be hard to have both the old data format and the new data format running at the same time.

Privacy | Site terms | Cookie preferences