So i have an otl/hda with some nodes inside.
It has a PythonModule section in which a callback
that attempts to set a parameter of one of the
nodes within its network.

for n in hdfNodes: n.parm('txasnFile').set(txfilePath)

While working on the otl (open for editing) everything works as expected.
When i match to current definition, I start getting these permission errors:


Traceback (most recent call last):
File “<stdin>”, line 1, in <module>
File “opdefDriver/io_CmptPublish?PythonModule”, line 26, in setTxFile
File “/home/prisms/builder-new/Nightly10.0/dev/hfs/houdini/scripts/python/hou.py”, line 17088, in set
return _hou.Parm_set(*args)
PermissionError: Failed to modify node or parameter because of a permission error. Possible causes include locked assets, takes, product permissions or user specified permissions


It seems to me that an otl should have the liberty to set parameters on nodes
in its own network whether its locked or not. Am i overlooking something?

just noticed this.. gonna check my type is correct.

Sets the parameter value at the current frame.

Raises hou.TypeError if the type of value does not match the type of this parameter. Raises hou.PermissionError if this parameter is not writable.

Why not make the nodes whose parms you want to modify be editable?

im not familiar with how to do that. explain!

Are you saying that if i have an otl with nodes in it,
the parameters of which i would like the top level
otl to control (like channel references but via hom)
I have to tag all the subnode parameters i want my
otl to modify as editable before i can change the
values therein?

that seems like weird overhead. If this is a permissions
thing, allSubChildren() of a node should give permissions
to the hda that contains them.

As of 9.5, there was a feature added that allows you to specify nodes inside an asset to be editable. This allows you to create assets that wrap say the Comb Sop for fur tools. These nodes you can modify (parms, interactively like Edit, children nodes if it's a subnet, etc) and the changes are stored locally in the hip file. You can add editable nodes using the chooser on the first page of the Operator Type Properties. If you wish to have a callback on something that will change parameter vales inside of a locked asset then this is the only way you can do it.

I'm not quite sure what it is you are up to, but it would seem easier to me to just have all the parms you need to change referencing a parameter on your top level asset and just change it there though without the need to manually change parms inside.

i have a dso inside and otl that has a parameter
that runs some logic whenever a particular field
is not an empty string.

The otl wrapper basically clears and sets this
parameter value based on some top level control.
It would be great to have the otl wrapper leave
the expected value in this field, and have a toggle
in the dso that only uses that value if on, But i
thought to try and avoid doing this at the dso
level and experiment with hom. The solution was
clean until i hit this permissions issue.

Is there a way to set parameters to be editable
with hom before you set them and then set
them to be uneditable again?

sdugaro
Is there a way to set parameters to be editable with hom before you set them and then set them to be uneditable again?

The only way you can change if a node is editable is through changing the list of nodes in the Operator Type Properties or through whichever section that a data is stored in the HDADefinition. However, you can't change either of these without changing the actual asset definition itself. That's just how assets are. If they are locked and not set as editable you can't touch.

If a node is editable the closest you could probably come is to lock the parameters if you are afraid of an artist diving into the asset and changing things.

ok, i guess the best chance im going to have at making the most of what i already have
(prior to discovering this permissions/enabling/locked_child_hdas thing)

is to simply have a channel reference from this internal hda parameter field
to some invisible dummy parameter in the top level otl, and have the hom
callback code i have tweak that parameter instead.

Im sure that an hda has permission to change its own parameters! :!:

That's how I would do it.

Unfortunately assets don't have any ability to modify their own internals other than by using Editable Nodes. I suppose it could be an RFE but the idea kind of goes against the fundamental idea of assets in my opinion.

yeah, i agree in principle.

I guess i just got excited when i was able to do this on an open otl.
I thought it was going to be possible to do everything i wanted in
the hdas Python module, instead of going through all the traditional
labour of setting up all the channel references in interior hdas.

sdugaro
Im sure that an hda has permission to change its own parameters! :!:

No :!: …

The whole point of HDAs is so that one can change the contents (or definition) of it and maintain the values of the top most parameters. If it was allowed to change the values of the parameters inside, then those values would be lost when the HDA definition was updated. The node inside whose parameter value was modified might not even exist by that time.

You can make a node inside be an “editable subnode” in order to change parameter values. However, you will lose the flexibility of ever having those nodes be updated.