I see the behaviour you describe, but when I click Accept the settings are updated so I’m not quite sure why the changing internal name is a problem. However, it is true that without a DSI file it’s not clear how to apply a layer stack to a different material zone (the layered image preset acts as a Materials preset, affecting named surfaces, rather than a shader preset, affecting selected surfaces).
Richard, thanks for your reply.
The problems, in a nutshell, are twofold:
1) Access to a defined layer setup can’t be easily scripted. The internal name is a ‘moving target’ since every time you tweak it, the name changes. Ergo, tweak a given layer setup, and now be compelled to edit any and all script references from the previous internal name to the new internal name. Bottom-line is regressive time-savings over the previous behavior, effectively discouraging increased LIE scripting automation.
2) As stated above, every time you tweak it, the name changes. But not only does the name change, the old name sticks around. Now imagine a world where we can’t edit documents, only move forward with incremental revisions. For some documents with only a few revisions, that may work OK, But for others, with dozens or hundreds or thousands of revisions, managing the incremental copies will quickly get overwhelmingly cumbersome.
Such is my workflow now with these incremental layer sets—overwhelmingly cumbersome! Granted some services like Dropbox manage the incremental copies ‘behind-the-scenes’, but the ‘current copy’ paradigm is maintained for the user at the front-end.
However there is a simple fix—just allow users to edit the ‘current copy’ of a layer set, instead of a spawning and forcing edits on a clone.
Thanks for your time and consideration.
Shall I write a bug report?