I seem to have encountered a bug (or perhaps an undocumented feature?) as whenever I unlock an asset it immediately switches its definition to embedded even though my Asset Manager has the “Save Definitions of Unlocked Assets to Hip File” unchecked. This makes it rather hard to save changes to the original hda file, since the definition remains as embedded even after saving the node type or matching the current definition.

Not sure if it matters, but I am installing assets via hou.hda.installFile() rather than adding them to either the HOUDINI_OTLSCAN_PATH or HOUDINI_PATH.

So on further experimentation it seems that I have to unlock the asset (which switches it to embedded) and then choose the current definition of the asset either via the type properties editor or the asset bar in order for my changes to be applied to it. Maybe this was the way it was supposed to work, and I just remembered the process differently. If so then please consider this issue closed.

Personally I like this, as it prevents accidental changes to a global asset.

This is abnormal behavior. Something is definitely wrong.

Edit:
I noticed you have another post mentioning OpLibraries. This could be the cause. I would avoid OpLibraries, as they tend to break everything and are not well supported even by sidefx. At my studio we install hda using installFile() in a startup script, although we did look into OpLibraries and judged them too inflexible and difficult to support.

Is this behavior happening when using OpLibraries rather than scanpath?

Totally agree about not using oplibraries. I am actually doing these tests in order to move us away from them.

I did ensure no oplibraries were loaded and that the use oplibrary option was turned off in the asset manager. Same behavior as before.

I'll test this on my home computer to see if maybe it's being caused by some rogue studio code.

So I was able to test this at home, and you're right jsmack. Something about the studio's Houdini is messed up. I guess I'll have to decouple it from our internal code and try slowly hooking things back in to see what is causing it.

Found it. Someone had overwritten the functionality of the “Allow Editing of Contents” menu option and forgotten to document it. Thanks for putting me on the right path jsmack.

Oof, overriding built-in menu actions is pretty outrageous.