Finally, after a few hours of writing plugin almost from scratch, but now using example @kerrishotts provided as a base, it’s done. And now it works so much better and more smoothly - state keeps preserved, groups keep collapsed if they were collapsed. Applied same example for layer ordering. Also now have normal history states. Just amazing how one property can change everything.
But I’ve encountered some Ps bugs(?). Tested without a plugin, and it’s the same.
If empty transparent layer is selected and you create new adjustment layer, it overwrites tat empty layer. Bug? Feature?
If you have a layer group with a color and a layer (or a few) below that group and you want to make a group of the immediate bellow layer(s), this new group takes color of the group above (also all inner layers get that same color). Definitely a bug.
Thank you all so much for the help and patience with me
P. S. I’m not accepting @kerrishotts answer as a solution, because this is just a workaround to the initial issue with DOM
Didn’t check specifically, but my plugin now is based completely on IDs and it fell apart when empty layer, that my plugin watches, was replaced with that new one
Converting an empty layer to a text or adjustment etc assigns a new layerID.
If your script needs to target a layer that you created inside the script you have these options:
reference it by index (might need to count all new layers you add)
give it a name and reference it by this one (i think this is the best option - if you add layers in your script, why not give them a unique name. You can always set it to something else at the end)
do all operations on it while its still the target layer
let the batchPlay call finish and get the ID from it’s returned Descriptors (or via getter) → Problem: You’ll have more than one history step
navigate through the layer tree with next & previous layer refs, if you know the offset to the currently selected layer
We do investigate this visibility side-effect issue. I hope we will be able to ship a fix soon and keep visibility intact.
A similar issue is also present in ExtendScript DOM e.g. when you rename a layer that is not currently selected but a different layer is selected instead.
Yes… but that is only workaround because low-level AM code needs some conditions to make action happen. And those conditions are non-sense from automation perpective. There is no reason why non-selected hidden layer could not be renamed. Or why filter couldn’t be applied. Those condition are made for UI interaction but are also leaking into automation.
