Weird Bug With Alternate SG configs

#1

Feel free to move this to pipeline integration, but I feel this is more of a general SG engine, or SG desktop issue.

So this is a little difficult to test, but if a new SG user is created and the user is placed on an old project that has multiple pipeline configurations it seems that the engine(nuke) doesn’t fully initialize with all required variables after the context is switched from project to shot (after SG file-open, open comp)

Then if that same user launches the same project but with the primary config, he then has no errors on any secondary configurations.

I’m curious what might run under a Primary config, that is not firing under secondary configurations during first run.

This is nuke-engine 0.12.3; Bootstrap version v1.5.4 (shotgun desktop); Core v0.18.169

PS: I can send logs for tk-nuke and tk-desktop but i’d prefer emailing them privately.
-Ross

#4

Hi Ross

That is a bit odd. Can I ask how both configurations are setup, are they both centralized or distributed?

I think we’ll probably need to see the log, in which case feel free to either pop a support ticket in with the log or message me directly.

Cheers
Phil

1 Like
#5

Hey Philip,
I sent you a message on these forums about this issue.

I did forget to include that this is a centralized config, shared core config, where 2 of the 3 secondary pipeline_configurations are sharing the same core, and the 3rd has a unique core.
-Ross

1 Like
#9

Hi Thanks for sending over the extra details.

I think this is a bug we’ve seen before.

You have a sandbox config with a shared core, and it’s sharing the core with the primary config.
It seems that during the automatic context switching (which occurs even if you save or open with our app), it attempts to run the following:

tk = tank.tank_from_path(new_path)

Now, this actually returns a sgtk instance that belongs to the primary config instead of the sandbox config. It then uses this incorrect sgtk instance to attempt to gather the context from the path. At which point it seems that if you don’t have the folders created on the primary config, or maybe just not synced then it will not be able to gather the context.

So there are a bunch of workarounds here

  1. Create the folders on the primary config (as you’ve been doing already.)
  2. Turn off automatic context switching on the engine.
  3. or Localize your core to your sandbox config.

I’ve linked up our internal ticket to this thread so we can keep track of how many people have hit this.

Thanks
Phil

1 Like
#10

Thanks for taking a look at this Philip,

Is there a specific tank command that gets run that allows the Primary config to function correctly? That I could possibly inject into a core hook?
Whats most odd is that this isn’t a new project, or new configs for that project so there has to be some sort of initializing command that I can run on a new desktop/user setup.
I definitely want to keep the option of having extra configs to implement large changes, with the option of just swapping certain artists back to the old tested working config if things go awry.
If not it’s not a big deal ill just have any new users first launch the Primary, and then switch, easy enough, just go to remember that fix :D.

Thanks again Philip, always helpful!
-Ross

2 Likes
#11

Ah I see, yeah if artists are using them as well, I can understand it becomes a bit more of a problem.
Well I suppose you could run sgtk.synchronize_filesystem_structure, but that would need to be run in the primary config, so thats not so easy if you’re working on a different config. Also if any new entities get created, their folders would need to be created in the primary config as well.

The problem goes away though if each of your config’s has its own localized core. I would say localizing the core would be an easier fix, than trying to devise a way to sync the cache and create the folders in the primary config regardless of the config you are working in.

3 Likes
#12

You did it!
as soon as you said “new entities created” also triggers this problem… I remember I saw a similar issue when I first tried this approach artists were getting context none on new assets when trying to create “new files” under the secondary config… and i fixed it with exactly synchronize_filesystem_structure but after I created a tk from project path. So i’m running tk.synchronize_filesystem_structure()

I have an injection point before users can interact with shotgun, but after it initializes so I think that’s how i’ll solve the nuke issues too.

I think i’ll go that root for nuke as well, gosh I didn’t even think it was the same issue… since it was presenting differently…
Thanks man!
-Ross

2 Likes