We have this case with tk-houdini, but I’m pretty sure it happens in other engines.
When a file is opened, _on_file_change_timeout tries to initialize a new toolkit and context from the file name. When that fails, the current engine is destroyed, which incapacitates the user to take further action.
For example, it is a common case that you want to open a file from outside the pipeline, and save it in the pipeline. This becomes impossible when the engine is destroyed, because workfiles does not start, either (or anything in the Shotgun menu).
Would it be nice if the engine remains as is? I understand that the current context may not correspond to the file opened, but it seems to enable the user more?
@philip.scadding @jfboismenu
I’m more than willing to send a pull request, if I know this sounds sensible.
Edit: also none of the errors along the chain is logged in Houdini’s message log/stdout. Not sure why, could not fully trace the exception handling. I see that the list of detected pipeline configs is empty, but there is no error message logged anywhere. Seemed like the TankError got printed in a couple of places.
1 Like
Hi Mois,
this might be because automatic_context_switch is enabled (it is by default).
If you turn it off you should get the workflow you are looking for.
Cheers,
Francis
Well, I still want context switching when opening a pipeline-controlled file. But I want to be able to open an external file without the engine being destroyed.
I personally agree, I think a warning saying you’re opening a file from outside your pipeline, the context can’t be changed automatically would be good, but still keeping the engine live, I’m not sure how others feel about that. This question has come up plenty before.
As it stands there isn’t a way to have auto context changes enabled without it disabling the engine when a non-pipeline file is opened.
A PR is always welcome, though I can’t promise anything.
Around the logging, it sounds like there might be a bug/unintended behaviour. Are you able to give concrete repro steps that we can try on our end to reproduce the issue?
[Edited]
As it stands there isn’t a way to have auto context changes enabled
but there is, just remove cur_engine.destroy() from the timer handler (I linked above) and you’re set? Seems to be working in tests here.
To reproduce these problems, open any file outside the pipeline.
In tk-houdini.log you can see
2021-01-29 10:49:26,987 [15580 DEBUG sgtk.core.pipelineconfig_factory] Executing sgtk.from_path factory for 'z:/user/mmoshev/particleAlpha.hip'
2021-01-29 10:49:26,990 [15580 DEBUG sgtk.core.pipelineconfig_factory] Associated pipeline configurations are: []
2021-01-29 10:49:27,530 [15580 DEBUG sgtk.core.pipelineconfig_factory] Associated pipeline configurations are: []
but no errors.
Then I added a line to print the caught TankError in the timer handler right after:
2021-01-29 10:49:27,530 [15580 ERROR sgtk.core.log] The path 'z:\user\mmoshev\particleAlpha.hip' does not belong to any known Toolkit project!
1 Like
Sorry I meant there was no official supported way without modifying the engine. But yes, that would do it.
I see what you mean on the logging, I think this was probably by design, as it’s not actually an error as such, the user is allowed to open a file outside Toolkit, but the integration just won’t work.
Alright, I was just wondering why the engine would not support that 
Seems like a common enough case?
Did anything happen on this? We’re hitting into this issue too. Should I just go ahead and fork our engine or is there a fix in the works?