We would like to somehow report to the task what dependency its waiting for exactly (for a given frame).
Is there a way from the script dependency handling process to report a log to the task? That way we could on occasion put in an entry saying “dependencies x,y and z are missing”
Not at the moment. Perhaps we could consider extra info properties for tasks as well? Then you could inject whatever information you want into a task.
Yeah that might be handy! Then the script dependency checker could just add some note in there. We dont need any historical data in this case anyway, so a ‘current’ state is enough.
Although, updating thousand of task entries every minute might become a bit of a hog 
With that nice node view, its tempting to maybe just extend that somehow, like the node itself could contain some information?
Then i could split it into several scripts (one per dependency), and i would see one node per dependency. And if the node had a “progress bar” like ‘availability’ field, i could look at it and see, that ok, dependency X is only 50% done, while dependency Y is 100% done. Does that make sense?
Considered adding some of this as extra info attributes to the job, but it might not be that simple. We have 4 types of basic dependencies we special handle:
1.: regular file dependency: a cache that has a range (for example, xmesh, fume, prt). Anything that matches the #.extension naming convention, where # is the frame index:
If the current task frames are before the cache, its considered OK, ready to queue
If the current task frames are after the cache, the last frame of the cache needs to exist, otherwise its kept pending
If there is an intersection in the task frames / cache range, all the frames of the intersection need to exist
2.: vray irradiance cache dependency: similar to #1, but if the task range is after the cache range, thats also considered OK & ready to queue.
3.: single file dependency: essentially deadlines ‘asset dependency’ with frame dependency off: typically, TP caches. Single file, the whole job is dependent on it
4.: flowline dependencies: similar to #1, but the file pattern is different (looking for folders with a particular regex for the frame matching), and also has additional parameters (might require multiple samples to exist, and in some cases can ignore missing samples)
#1, #2 and #4 also have an additional artist settable “surrounding frames” property that can be set, which extends the required cache radius by a user defined frame value (so 1 would mean, the frame we are rendering and -1 / +1 as well).
The combination of all these and their properties give about 7 properties for each dependency… I think it might make it harder to maintain if we added all of them as extra info attributes to deadline, instead of just having a single xml file like right now (which is manageable for us).
So… i think maybe a better approach would be, if you guys made the dependency type a plugin customizable mechanism So we could just reimplement this 4 as individual deadline dependency plugins. v7? v8?
Instead of using ExtraInfo0-9, can you just use the arbitrary extra info properties? These are the key/value pairs that show up in the Extra Info page of the job properties, and you can set them using the ExtraInfoKeyValue# keys in the job info file:
thinkboxsoftware.com/deadlin … fo_Options
That really shouldn’t be any extra work or maintenance then writing to an xml file.
Maybe I’m missing something, but how is this any different than writing 4 different dependency scripts and assigning the correct one to each job?
Cheers,
Maybe I’m missing something, but how is this any different than writing 4 different dependency scripts and assigning the correct one to each job?
[/quote]
If it was fully customizable plugin based system, i imagine i could add whatever property to be displayed in the dependency node view, for each new type. Right now it just says “script” and its name.
Don’t know, maybe im just hung up on trying to utilize that dependency node interface. Seems like you guys are putting a lot of effort into it, but right now its completely useless to us since its just showing a single node of ‘scriptDependency’. We dont know what it is, what it does, what properties it has, what range it was cached at, etc.
I added a right click menu task script for people to test their dependencies and it works, but it seems like we are internally reimplementing what you guys are doing with the dependencies / node view, simply because that system is locked down.
i definitely want the node ui to become the HUB of workflow within Deadline. it’s just a question of time/resource sink
Hey Laszlo,
We already have all of this on the wishlist targeting Deadline 7. These apply to all dependency types, not just scripts:
We also want to add a test option for dependency scripts and requied assets in the Node UI for Deadline 7.
This will require refactoring how dependencies are stored in the job object, which is why it needs to wait for the next major release.
Cheers,
Thanks, didn’t realize it was on the roadmap already!