Hi,

i've generated some small scripts i have as entries in the TAB-menu in the VOP contexts, however they are only valid in Vop-Sops and are invalid in any other VOP context. Looking trough the help on shelfs, i found the <contextOpType> thingy and for my tool definition i've set it to

<toolMenuContext name=“network”>
<contextOpType>Sop/vopsop</contextOpType>
</toolMenuContext>

but i've also tried

<toolMenuContext name=“network”>
<contextOpType>Sop/vopsop</contextOpType>
<contextNetType>VOP</contextNetType>
</toolMenuContext>

none of them works
however, just this:

<toolMenuContext name=“network”>
<contextNetType>VOP</contextNetType>
</toolMenuContext>


is working

tried several 12.1 builds and the latest production build of 12.5

any idea whats wrong ?

cheers!
Seb

you need to put there type of the operator that is allowed in the networks you want
so if your tool is part of your custom operator that you've already defined to be allowed only in vopsop then put it there
if not then find a vop which is
like importattrib is allowed only in voppop and vopsop so you can write
<toolMenuContext name=“network”>
<contextOpType>Vop/importattrib</contextOpType>
</toolMenuContext>
for your tool even if it has nothing to do with importattrib, that line is just saying allow my tool in networks where Importattrib VOP is allowed

Hi Tamte,

that makes some kind of sense, and it seems to work, … partly.

however is anywone ot aware of any VOP's that are only available in VOP-SOP's but not available in a VOP-Net SOP-Type.

I need to limit this tool just to VOP-SOP's

Seb

well I'm not sure if you can distinguish those 2 networks like that
since VOP Net Sop Type is essentially Vopsop, more like Vopsop definition (of which you then can create many instances) so it accepts exactly the same nodes as Vopsop

so now it depends on what your tool is doing since if it runs script that really needs to be called only from within vopsop SOP then you can test if the parent node is vopsop type or not and then either run the tool or not

EDIT: and honestly I don't know who uses VOP Net/Sop Type anymore (or any vopnet type) since HDAs are standard now and have much more advantages over storing definitions directly in file

Hi Tamte,

thanks for your input,
sure I can test if the tool is able to run or not, but giving a user a message, with ‘I cant be run here’ is not so useful as if the tool would not be there in the first place.

In regards to your edit:

I'm not sure how it would perform:
100x same VOP-Sops which probably get recompiled individually for each instance
vs
100 instances of a Vopnet/sop-type which probably just gets compiled once

but as i said, i have not benchmarked this case

cheers!
Seb

Infernalspawn
…
I'm not sure how it would perform:
100x same VOP-Sops which probably get recompiled individually for each instance
vs
100 instances of a Vopnet/sop-type which probably just gets compiled once
…
Seb

true, I haven't tested it either, but if you want to use your tool more times you will make it an HDA and I assume this is solved there, It would not be very efficient if houdini compiles code in every instance of locked HDA

for vopnet types I simply don't like that the definition is part of the scene so that's why I don't use them anymore and haven't seen anybody mentioning them for years

I also thought VOPNets are dead, but i had artist use it in a recent project, so they don't seem to be that dead after all

anyhow, thanks for your input!
Seb