I have to ask a serious question here. Do you actually test these updates before rolling them out?
What kind of software company integrates a “feature” that overwrites a system-wide setting for another application, especially one that directly impacts Nuke users, and then provides no preference to disable or control it?
I opened Nuke and immediately realized our studio setup was no longer loading. Since the only thing I updated today was Topaz, I started digging through my environment variables. Sure enough, Topaz had added its own user-level NUKE_PATH variable, which overrides our system-level NUKE_PATH.
I deleted it, relaunched Topaz, and it immediately added the variable again.
This is not a minor inconvenience. This can break studio pipelines outright. Topaz should not be editing NUKE_PATH automatically, and there needs to be a way to disable this behavior immediately.
Just spoke with the devs on this, and they should be appending to the variable and not overwriting it.
Can you grab the installer logs to send over for them to review what is going on here? You can post them here or email them to me at help@topazlabs.com
I’ve already reverted back to Topaz 1.5 to fix the problem for the time being. That said, here is the issue:
A user-level environment variable with the same name as a system-level environment variable completely overrides the system-level variable for that user.
So if Topaz creates a user-level NUKE_PATH, Nuke reads only that path instead of our existing system-level NUKE_PATH. This is different from the main PATH variable, where system and user paths are combined/concatenated.
For Nuke specifically:
Topaz NUKE_PATH override:
C:\Users\Administrator.nuke\topaz_video_ai
Our existing system-level NUKE_PATH:
\hyphenate01\Scripts\nuke\startup
Because Topaz is creating NUKE_PATH at the user level, Nuke is no longer loading our studio startup environment. It is only prioritizing the Topaz user path, not appending both paths.
This is a major pipeline issue. Standard OFX deployment for Nuke is generally handled manually: we receive the OFX files, place them where we want, and configure our facility init.py and menu.py to point to them alongside the rest of our studio tools. We need full control over that process.
We do not want Topaz automatically modifying NUKE_PATH, especially with no preference to disable or control that behavior.
Please advise on how we can prevent Topaz from recreating this user-level NUKE_PATH variable.
Understood, thank you for that insight. Checking with the devs on this situation further to see what options there are and how they can address this in a patch update soon.
Glad to hear that 1.5.0 does not see the issue though. As soon as they confirm a workaround option for 1.6.0 or have an update patch I will follow up.
Thanks for the follow-up, Kyle. I look forward to hearing more from the dev team, but yeah, generally speaking, most Nuke users and studios implementing Topaz in their workflows will want the same control I am talking about. Support for customization via Python, TCl, and other scripting is one of the foundations that make Nuke so versatile, so I would highly suggest offering a separate deployable OFX download of Topaz for Nuke that doesn’t require the installer and leave it out of the “normal” standalone installer.
Thanks,
Travis
