Workfiles 'cannot determine value for fields', using custom context

So I’m trying to incorporate the Element context into our schema. and I’m running into some issues I’m not sure how to resolve.

I have the actual schema folders all set up in the config OK. I’ve updated my templates. I’ve added an element.yml and element_step.yml and added both element and element step versions of things as appropriate. Workfiles is giving me a real issue though. It will happily save, and place the file (I’m in nuke for this, if it’s relevant) in the correct location. However workfiles then deactivates, as it apparently doesn’t understand the context it’s now in:

It will not be loaded: Context Comp, Element Man029 can not determine value for fields [‘Step’] needed by template <Sgtk TemplatePath element_work_area_nuke: elements/{sg_element_type}/{Element}/{Step}/work/nuke>

It just happily saved it into “elements/{sg_element_type}/{Element}/{Step}/work/nuke”, for which it understood the step (Comp in this case), so how is it that it can no longer understand that the Step is Comp (and therefore deactivates itself) when it literally just saved correctly, knowing that the Step was Comp? The whole elements Schema is based pretty directly on the Asset schema, and thats all working fine, so I’m really not sure what I’m missing here.

I’m guessing there’s something it doesn’t like about the schema in general, as after creating a new Element, running ‘create folders’ on that id, creates them in the wrong place (under Element, ignoring that they should be under Element/Step, and also not being the ones I’d expect made anyway!), but again if you create the Element and use workfiles to save, it will spool out all the correct folders and save the file in the correct place as per the template.

This is on my R&D config, and as such I’m changing the schema on something that already exists, so I was wondering if maybe it’s reading some old cached version for folder creation, but I trashed my Shotgun folders in appData (Roaming and Local) and that made no difference.

As far as I can tell, I’ve covered everything here: I want to use Toolkit apps with a different entity or custom entity rather than Assets and Shots

Any help greatly appreciated!

1 Like

what yml do you have in your folder schema at the {element} level to generate the step folders?

1 Like


Is this the one you mean? It’s just a copy of the one from the Assets section of the schema, which seems to work fine for Assets.

When I generate a new Element, I run create folders on it (via code) and it ignores the step and just builds 'publish, ‘reference’, ‘review’ and ‘work’ directly under the element itself - which the schema as above suggest shouldn’t really be possible, as they don’t exist there. I added the ‘test’ folder under the step to see when that gets generated, and it only turns up, along with the other folders under Step when I use workfiles to save the scene.

Do you have a step field for the Element entity, and is it populated when you run the folder creation?

I’m curious about why you are going about creating an element entity like this.; eg with its own tasks.
Wouldn’t it just be easier to update the writenode app to have a “element” profile, that uses custom element templates for the work and publish paths. You would then just need to create a new publisher plugin that would handle the creation of an element entity that could be linked to the Version created during publish.

1 Like

So, as it turns out, there isn’t actually a problem! It seems that Shotgrid maintains an intenral cache of the schema somehow, and that was conflicting with what it was reading in from my update. Restarting Shotgrid Desktop, suddenly it’s working fine!

To explain why I’m doing it like this, I inherited our Shotgrid setup some years back, and the guy who set it up before me had Elements set up in our Asset Library project, but that was purely to have versions saved onto them, it wasn’t set up as a file structure you could work within (or publish to). All the Elements we used up till now were added via a script automatically as versions. We are now ingesting a bunch of greenscreen work, which in theory we’d like to be able to save to the Element to work on and then publish the usuable frames onto the Element. This is something, now that it’s working, we can now do - although ironically it’s bene decided to do things differently and so there won’t be nuke files where the gusy work, there will just be frames that need publishing to the Element, so I’ll actually be taking a different tack for that, but at least the functionality is now largely there for the future!

2 Likes