Jacobo Sanchez de la Villa

tamte
that's really an odd behavior and you should probably submit it as a bug as it's rare that something downstream that's only reading the attribute would affect upstream behavior in this way

i reported the bug , but its not a bug:
This is the answer from side FX :

Hello,

Our developers comment:
You CANNOT animate the number of multiparms using the multiparm field. This includes driving it from geometry attributes, etc. This may appear to work where it can statically resolve a constant value, but cannot work as soon as you end up with a for each loop where it varies during execution.

Native Verb-based nodes that have multiparms can be overridden with the Parameter Override option, where the parameter override is built by a vex wrangle to override the multiparm. Attached shows an example building such an override for the Add SOP.

best company ever , in only 24 hours they send me an answer.

I upload the file , if someone wants to know the workaround

Thanks!! I will report the bug to sidefx

tamte

Jackatack
...
So i create in the hda scripts an On create . with this script :

node = kwargs["node"]
node.parm("cutsModule").setExpression('detail(0, "nModules", 0)')

it works fine without error messages . But the behavior with the caches its extrange. I don´t know why , if its for kwargs
...

this is the correct way to set expression on parameter during onCreated callback

you'll need to elaborate more on what you consider strange behavior
did it not create the correct expression on the parameter?

that being said having Multiparm count depend on attribute is a very bad idea so you don't really want to do that

since at any opportunity when during cooking of the expression the geo is not available (like when opening the scene in Manual or disconnecting the input or temporary error in input geo, ...) you will get 0 which will reset the multiparm instances and then even if at later time it gets the right value all the multiparm instances will be at default

My intention is for a building made up of modules to be able to attach an HDA that allows each module of the building to be subdivided independently.

I thought it would be convenient for those multiparms to appear automatically depending on the number of modules.

I wouldn't mind if it returned to the default setting when disconnected.

The strange behavior is:
If I have 7 iterations (modules) and I attach the HDA, it correctly generates 7 multiparms.
The problem arises when I change the number of iterations. Instead of adding or removing multiparms, it causes the foreach to bug out, even if I reset each node.
It doesn't return a correct value until I disconnect the HDA or delete it, and then reset the cache of the foreach node.

I don't know if it's a bug or something that hasn't been thought through properly.

I have uploaded a .hip file and the HDA in case someone wants to reproduce the error/bug or can tell me what might be going wrong.

Best regards and thanks a lot for the response!!