I’m trying to generate our AssetIdentifier parameter from several other parameters.
I’m new to Revit and Dynamo, but have used Maya in the past, so my old dependency graph knowledge has helped a bit.
Can anyone de-bug the attached and let me know where we are going wrong?
The output should be BEL-LFT-03-03.16-00001 etc… but it’s listing them vertically (as highlighted), instead of for horizontally in the String.Join preview.
I think I’ve found a solution by combining info from several another threads. Adding a List Create, List.Transpose, List.Join and finally a List.Flatten sorted it. I’m not sure it’s the most elegant way to do it, but it works. -
It’s a bit frustrating as without these extra nodes, I’ve seen other threads where examples of what I did before has worked as intended. Maybe its a revit 2022 thing though…
First up: Revit 2022 is a big problem, but the problem is not making Dynamo run incorrectly. The problem is that you are using an unsupported and insecure Revit version. You need to upgrade a year (or more if the job will still be active in 9 months).
Onto your issue.
One Element.GetParameterValueByName should suffice - study up lacing and list levels by reviewing those sections in the primer.
Start by gathering all your parameter names in a single list. Wrapping the current code block lines in square brackets ([ ]) and replacing all of the ; with , should do the trick there.
Then wire that into the ‘name’ input of ONE Element.GetParameterValueByName node and set the ‘element’ inout to be @L1.
Now you should then be able to get rid of the other Element.GetParameterValueByName Nodes, the List.Create, List.Transpose and List.Join nodes, but double check the list structure.
Only because someone hasn’t brought it up correctly. I have this conversation with it is a ‘project requirement’ team once a quarter. I have yet to have a team not update, unless they were working in a black site (no internet connection/USBs - data doesn’t come into the project by any means other than user clicking, and no way to get data outside the project either), which is the only way to mitigate the risk. The discussion usually goes like this:
“No one can buy a license for just one year, so we all have access to a supported build. The time to upgrade should be less than an hour total work per office. There are unpatched security vulnerabilities which all offices involved are at risk for by not updating. As we are interlinking files a breach for firm A becomes a breach for everyone, and none of us will know until we are all ransomed out of our system. As such I think we should upgrade on Friday. Any objections?”
I might get someone who thinks updating will take a lot longer than an hour, which results in a discussion around upgrade processes and tools therefore. Usually things instantly turn to a debate around ‘which version should we go to’, which takes up 20-30 minutes as everyone lists the pros of progressively newer builds relative to the ‘tools we didn’t maintain and would lose if we go that far’.
I should note, that I appreciate this might not be your place to drive that discussion with the correct stakeholder. But you have a obligation to your company to make the person who is in that position aware they need to do so.
