I’ve written a clustered definition that sets up some layers with colors, linetypes and materials. It is in the same definition file as a bunch of other clutsers that have much longer definitions. This is it. It is activated by a Button that has a False status excepted when pressed, when it is True momentarily.
When I open the file with my definitions, this particular definition runs - partially - and sets up some of the layers, but in the wrong order. None of the other four or five much longer and more complicated clusters in that file run on their own. When I delete the partially created layers and hit the Button to activate it runs perfectly and does what it is designed to do. It is so simple, it is puzzling.
So:
why does this one cluster auto-run, and incorrectly at that?
But intriguing enough to convince me to hack something similar. Unfortunately for you that doesn’t reproduce the behaviour you see and correctly creates layers when, and only when, requested.
My initial thought is that something could be briefly triggering the switch on startup, so what happens if you open the document with the switch disconnected - does the misbehaviour stop?
Well, that’s interesting. I disconnected the Button, leaving the Cluster with no input at all. I saved the file and closed Rhino. I reopened rhino and the file and the cluster ran anyway, automatically, partially, and with the layers in the wrong order. This is a one-component definition. What could possibly be happening?.
I’ve found the problem. Deelpy imbedded in a cluster within a cluster in a definitiion elsewhere within the same file there were some Human Bake components that had their activation inputs internalized to True, that I had neglected to wire up to the Activate button driving the rest of everything. They were firing as soon as the file was opened and that was creating the mysterious layers.
