Problem summary:
GSVs in a Read node's file-path can fail to evaluate when the Nuke script is Saved/Autosaved
Customer reported version:
Nuke 16.0v1
Customer reported platform:
N/A
Steps to reproduce:
1) Launch Nuke and navigate to Edit > Project Settings...
2) Switch to the Variables tab and create a new Variable named "test" (or similar)
3) Enter a valid file path for media on your machine into the Value, such as C:/tmp/plate.mov
4) Create a Read node, and set its file knob to the GSV: %test or %{test}
5) Create a Write node
6) View the Read node by selecting it and pressing the "1" key
7) Navigate to File > Save Comp As...
8) After the file is Saved, observe how the Read node now returns a No such file or directory error:
Expected behavior:
When a File is saved, GSV values in file paths should continue to evaluate.
Actual behavior:
If a Read node has GSVs in its file path and is connected to a Write node, saving the Nuke script will cause the GSV to no longer evaluate and the same issue seems to occur whenever an autosave is triggered. The problem only appears to happen if the Read node is being Viewed, and won't occur if while Viewing the Write node.
However, it is not necessary to View the Read node itself, as viewing a Merge or TimeOffset node also seems to produce the same results:
This seems to occur if any element of the Read node's file path uses a GSV, like in the following additional examples:
test = C:/tmp/plate.mov | file knob = %{test}
test = C:/tmp/ | file knob = %{test}plate.mov
test = tmp | file knob = C:/%{test}/plate.mov
test = mov | file knob = C:/tmp/plate.%{test}
test = plate | file knob = C:/tmp/%{test}.mov
Workaround:
Adding a secondary unconnected Write node in the Nuke script seems to resolve the issue:
Reproduced by Support in:
Nuke 16.0v1 - Windows 11, macOS 14 Sonoma
Nuke 15.2v1 - Windows 11
Earliest version tested:
Nuke 15.2v1 - This feature (GSVs) did not exist before this version
