Closed ldmoser closed 3 years ago
Hello!
I see you've closed this bug but please allow me reply. Unfortunately it's a symptom of the dynamic knobs framework requiring knob names before connecting to the server to know which knobs of the model to create. We've investigated different ways of doing this, such as connecting sooner, or creating fixed dummy placeholder knobs, but we couldn't find a way that worked reliably 100% of the time.
Hello Dan, thank you for following up. I have silently closed three issues because I was unaware we did not have the latest version of this project installed in our facility. The latest version do have the custom knob which serializes the contents of all dynamic knobs and in my brief tests it does recover their contents when I load the Nuke script, as well as when I create groups or use copy-and-paste. So I decided to remove these tickets. I haven't tested and used much since then, so based on your answer it seems that I will still hit some problems here and there, ey?
Whenever I save a Nuke script with MLClient nodes and then load that Nuke back, I get errors messages: "MLClientXX.YY: no such knob". Where YY is the custom attribute in my ML model.
As a result all the fields go back to their default value, including the input that specifies the path for the pre-trained model..
Is that behaviour expected? Is there something I can do to avoid losing information? Or perhaps can you fix on your end?
Thank you!!