Can you explain how to override AYON_WORKDIR for a Host DCC, as the comment under work_root() method says “this can’t be called out of DCC”, however in Maya and Nuke implementations I can see it was used.
I’d like this function to be called before workfiles ui shows up so I can alter its path?
Can you elaborate why you want to expose it and what you’d want to alter it to?
The work_root as was implemented on the HostAddons at the time should be removed actually as far as I know since custom roots didn’t make sense the way they were implemented because they were only accessible from within the Host application itself - disallowing features like “Open with last workfile” and alike because it doesn’t actually know where the work directory may be.
Note: When updating anatomy make sure to update the projects you want to change. The “anatomy presets” do not update already existing projects, they are merely templates for the creation of new projects.
This does not add the myProject/scenes subfolders in the maya root - but does add the maya/ folder.
You can also set host specific templates if you really want to, by adding more work templates. And then setting them in your studio or project settings, at ayon+settings://core/tools/Workfiles/workfile_template_profiles
Hi !
I didn’t know the {app} token. I don’t have a usecase today, but for fun I just tried to add it in my Directory Template.
It correctly creates (if “Create First Workfile” is ON) and opens scenes with Blender. The folder tree is correctly created on disk.
But, in the Launcher, when you click on Explore Here, it does not open the directory that contains the workfile.
Instead, it opens the directory that is above the {app} token (wherever this token is placed).
It is understandable, as the Explore Here button cannot know which DCC we want.
Also, with Substance Painter, it successfully creates the folder tree, but when trying to create the workfile from inside Substance Painter (menu Ayon–>Work Files) it silently fails to create the file (nothing appears in the logs).
Odd - I’m pretty sure I’ve done most of my Substance Painter testing with {app} set. There shouldn’t be that much special about it. @moonyuet any chance you can reproduce?
Here are some more details, the problem is not only seen with {app] :
It only fails to save the Substance scene, if we try to save a version that was already known to exist by the database.
For example, a task was saved with workfile v1. Then I change the template to add the {app}, restart everything (Ayon and DCC), and I try to save again (automatically version 1). This fails.
But, if I create a new task, everything works all right with {app}.
Then I remove the {app} from the template.
But I can still replicate the bug in another task, by doing the same trick : delete all workfile versions (on disk, not on database), and try to save a version from the Work File gui (which happens to be a version that existed before I deleted it on disk).
I guess that somewhere the database says “this version has already been saved”, and refuses to do so (which seems a healthy behaviour), but it should display a message to tell the user why the save was not allowed.
Ah yes - that is confusing. Does it come with an error with stack trace in the Substance Painter console? If so, I’d say an issue ticket is valid for ayon-core. I’d personally feel that resaving it should be allowed and if there’s good reason not to - that it should auto-increment beyond it by default.
Yes, all my tests were done by editing the Directory Template.
You may have missed my message that explains that the problem is not restricted to {app}, but can be reproduced by removing version files on disk.
Sorry for misunderstanding. Did you encounter the same issue when you replicate this in other DCCs(like Maya, Blender etc)? If you talk about saving deleted versions of workfile not allowed in the workfile tools, the error should be hit across different hosts, not only in SP.
I slightly checked on the substance painter API. We are using the save mode with full which it will save everything in a new file. Slow but creates the smallest possible file.(as Substance mentioned in their written docs). There is also another mode, we can try to switch and see although I dont think it works to fix the issue. The mode can be changed to Incremental, which save only new or modified data. Fast but the file size is not optimal.
That sounds unrelated - I hardly feel this ‘issue’ should be due to something inside Substance Painter. Also, saving just ‘incremental’ also doesn’t sound like what we’d necessarily want to do. First off would be finding the reproducible case to see exactly when it happens.
Here is a more detailed list of steps, to reproduce it :
Do not launch Substance Painter yet.
For a task that already contains Substance Painter workfiles, manually delete all those workfiles versions on disk (but do not delete them from the database).
Launch Substance Painter on that task. On Ayon’s Work File gui, you see there are no workfiles. At that point, the scene was never saved, there are no files at all.
Try to save a version from the Work File gui (for example v1, which happens to be a version that existed before you deleted it on disk).
For me, it silently fails (nothing on Substance console and logs, and on Ayon’s admin console on debug mode).
Are we talking about the Published workfiles? Or the workfile entities that store the workfile metadata for the workfiles in your work area? I assume the latter? Since it refers nowhere to an action that should involve the published entities - but just to be completely sure what you’re referring to.
You assumed right, I am talking about the workfile entities that store the workfile metadata for the workfiles in my work area.
It does not involve publishing.