We would like to have Assets that are company wide. Currently, in Shotgun Loader, you are only able to see things that are under the specific project. Is there any way to allow either seeing/loading things in Loader from another project? Or maybe having a Global Asset class?
The feature of/trouble with zero-config is that it’s just that – you can’t really modify the way it’s configured (beyond the few bits that live inside Shotgun like the Software entity). And the workflow in Phil’s document requires you modifying the configuration for the Loader app to have a separate tab for your shared assets. So, unfortunately, you can’t achieve this without having an advanced setup for your project.
Thanks for the info. That post is really help. To clarify, the Zero Config based on tk-config.basic?? If so, does basic have the necessary function for me to add the values specified in your original link adding Loader definition, or does only Advanced Config (default2) support that?
So “Zero Config” was a pre release name we used for what then became the basic integrations. We don’t use the name “Zero Config” any more, and hopefully it’s not in our documentation anywhere.
But to clarify they are the same thing: “Zero Config” = “basic intergrations” = `tk-config-basic".
Yes you should be able to make the same change to the basic integrations, you will find the loader settings here:
Thanks again Phillip. Everyone in the Flame community knows it as Zero Config. And now the next question. Where do I put this for Flame as there is no apps.yml for that? Although there is SG Loader in Flame.
Ah! Sorry I didn’t realise this was Flame. OK that changes things a little.
So Flame actually has it’s own config called tk-config-flameplugin and whilst it is possible to take over this using the same method as described in my earlier link, the config is actually hosted privately so I’m not sure on the intended method for getting to it.
Also whilst it would be possible the modify the loader settings, I don’t know Flame well enough to know if it makes sense to be able to import stuff from another project in a Flame context. You will know that better than me I suspect.
What I’ll do is reach out to our Flame experts, and find out where you can get the config from. I’m certain it is cached locally somewhere on your machine, I’m just not sure where.
Also do you only use the Shotgun integrations with Flame, or do you also use them with other software at your studio?
OK thanks for confirming. The reason I’m asking is you won’t want Maya and Nuke to suddenly start using the flame config as well. Again it is possible to get it set up in such a way where Flame will use a custom flame config and Maya and Nuke can use the standard config, I’ve helped someone else set that up in the past, I just don’t remember all the details right now. I’ll write up a step by step guide once I know more.
I just watched the “Shotgun Toolkit Webinar: Cloud Configurations and Multi-location Workflows” video, and I should be able to do basic.flame in the PluginID field. Is the plugin your referring to this:
Nice! Yep I think that is pretty much all you have to do.
I just need find out how you can get hold of the flame config. I could of course send it to you, but I’d like to find a method where you can get it for your self, so you can get the updated versions when new versions of Flame come out.
OK so I’m told you should be able to find a copy of the config by following this /opt/Autodesk/presets/<flame_version_number>/shotgun/bundle_cache/app_store folder , e.g /opt/Autodesk/presets/2021.0.1/shotgun/bundle_cache/app_store.
You are correct about needing to set the basic.flame however there is another detail. If you have two PipelineConfigurations defined on your project, the Flame PipelineConfiguration entity must have the lowest ID.
This is because it will pick the first config called Primary with the lowest ID, and if you have another config already defined called primary using the basic.* plugin id, Flame would use that instead. So just make sure you you create your Flame PipelineConfiguration entity first.
Thanks for that… This just keeps getting more and more complex. Then the next issue, is how to support multiple versions of flame, we often have 2 different versions that we run. Would it be basic.flame.202X.X.X ??
OK I’m told that the latest config should be compatible with Flame 2018 and up, so you should be able to use the latest config across versions unless you are wanting to configure things differently for different versions.
Edit: the Flame config’s environment yml files are setup for different versions, so one config controls all Flame versions.
I am coming to this conversation late but wanted to pose another solution. In the past, I have done this in many ways. For example, at one shop we set up a dedicated custom non-project entity and built a suite of tools to register assets from the project into the vault. This solution required a lot of customization but worked nicely. In another instance, I set up a dedicated Project for global assets as is being discussed here in this thread.
However, over the last few months, I have been using the Beta Webhook platform and have found it to be very powerful. Furthermore, I have been dabbling with AWS Lambda and Serverless to manage the execution of the Webhook. It seems to me that you could add a Checkbox field to an Asset and or a Version labeled Global Asset. As a result of checking this field, a Webhook could be fired off to make a replication of the Asset entry in either a Custom Non-Project and or in a dedicated Asset project. The Webhook could also fire off a render job across the AWS domain to your local filesystem to replicate the resources in the right directories for future vault needs. If your really ready to drink the AWS Coolaide, you might be able to bypass a render job and use AWS Direct Connect to make your python Lambda worker actually do the copy actions.
All of this requires a bit of customization and Toolkit can be pretty squirrely setting up as a micro-service, however solutions like this are possible and can provide a lot of value for certain studio configurations. Just some thoughts.