I’m going back through some of the old scripts I’ve done and trying to optimize some things. In this script, I have a lot of repeated processes for a collection of parameters. Basically, all this is doing is taking doors placed in the model and defining a default value for all the yes/no parameters that come in as a null or “gray checkbox.”
What I want to do is take all of the nodes inside one of the green groups and make a custom node. I thought I had this working with this:
But I think I have something wrong with lacing, or something along those lines. In my testing, I pass in 88 doors, but the output passes back over 7000 of them and when it’s done it does not set the params properly. In the custom node, it should leave the param value as-is if it’s not blank/null/gray. Instead, it changes it to true/checked no matter what (when the default value is set to true).
My only guess as to what’s happening is the node isn’t properly parsing when given a list of elements instead of a single element. If I pull the nodes from the custom nodes and run them on a single selected door, it works.
Any thoughts?
Thanks!
Matt
You changed what your graph is doing when you created the custom node. Now you’re using an If node to return either a single boolean or the list of original values from the parameter. The node is probably having troubles with the inconsistent list lengths. You’re also forcing list structure in the inputs when you probably don’t need to (unless you’re expecting sublists, in which case it would still be easier to handle with list levels or lacing in the graph).
Remember, Dynamo will automatically iterate through lists. You don’t need to specify data structure unless it’s required for the logic flow. All you really need to do is select the elements in a group and use Edit > Create Custom Node. Then you can add a new boolean input for 0 or 1.
All of that being said…
This really is just a list management issue. There’s no need to create multiple groups / custom nodes for each parameter when the logic is essentially the same. You can get the same thing by supplying a list of parameters and a matching list of values for each condition. I would suggest attempting to combine all these functions. If you wanna give that a shot we can certainly help.
Ah, I see what you mean. The IF is returning the entire list of values if the == is false.
The data structure came in automatically when I used “Create Custom Node” from the context menu. Truthfully, I have no idea what that var[]..[] notation means! 
I knew there had to be a way of combining all of this back when I did it, but couldn’t wrap my head around it and what I had “worked.”
I’ll give the combining a shot!
Thanks!
@Nick_Boyts
This seems perhaps a bit convoluted, but it does work. Where can I trim the fat?
This is what I would do:
What you’re essentially wanting to do is set a default value for parameters that haven’t been set yet. So I’d start there, by defining the default value for each parameter. You want your list of defaults to pair up with your list of actual values. Cross-product lacing is already doing this for you, but typically I’d suggest using list levels so that you can force the correct structure yourself. With your list structures matching, all you have to do is apply the condition to check for empties ("") and return the default value if they exist. This is easiest with the codeblock shorthand formula for If, but can be done with the standard node as well. The If function requires equal lists, so we have to duplicate the default values for each element first. That’s it!
Thanks, @Nick_Boyts
I think this is basically what I’ve done, I just have an extra filter to not process doors that have all values already filled in. The reason I did the filtering was to hopefully make it faster not having to iterate through each door reassigning/setting params to the values they already held.
I’m not used to the new look of Dynamo, are you using lacing or list levels anywhere? I see the GetParamVal doesn’t say AUTO, but do you have it set to cross product? That’s what I was doing. Only way I could get it to give me the full structure.
You’d still have to do another list of repeated items for the param names before doing the set params, right?
I do like the simplicity of the code block at the end with the conditional instead of the == and If blocks in mine. But I needed to “spell it out” so I could use the bools in the filtering.
Thanks!
Yup. Nothing wrong with your graph. I just wanted to show you a more simplified version.
It’s good to be thinking about this, however writing boolean values to an element is fast. In my opinion, not having to split lists and deal with all the extra nodes for this condition is worth the tiny bit of extra time to re-write values that don’t need changed.
Not in this example. The GetParamVal node is just a codeblock I wrote to represent what you should be expecting from that node. With actual elements you would have to use lacing or list levels.
You can if you want a more simplified list structure, but you shouldn’t have to if you use the appropriate list levels. (I would highly recommend looking into list levels as they make handling your list structures much simpler and allow you to reduce the number of nodes in many situations.)
1 Like
I have a very basic understanding of list levels and lacing (I’m using both in my script), but I find I still have to experiment to get what I want. It’s not immediately intuitive to me as to which option to choose for a given scenario.
Ah, so that’s why GetParamVal looked so weird! I was thinking, dang, the new Dynamo looks so different! LOL!
