I have a graph that worked up until the latest Revit 2024 (and presumably dynamo) update. Since then, the list structure seems to have changed (maybe the use levels option within nodes).
Regardless, I am almost positive there is a more efficient way to do what I was previously doing so I am going to distill this down to the basic essence and hope that someone here can maybe point me in the right direction.
I have a list of elements with nested lists of four specific parameters for each element (Elements Search Pool). I want to find specific elements in that pool using two of those parameters (Elements to Find). A proper match would have both parameters match at the same time. In our case, nested list 1 (Elements to Find) = nested list 3 (Element Search Pool) and nested list 2 (Elements to Find) = nested list 4 (Element Search Pool).
TLDR:
Is there a way to check multiple nested lists for a double match and return the proper index?
The biggest issue here is dealing with multiple sublists at a time. Logically, you’re just checking whether each sublist contains the items in your Elements to Find list. If both items are found (List.AllTrue) then you have a match.
However, to be more accurate, you probably want to check each item against a specific index in each sublist. In this case, it’s better to transpose (or use List.GetItemAtIndex) to get the sublists back to lists by parameter and check the specific parameter value against the specific item to find.
What you do also depends on if list order matters, and if so, respective to which list. You can use List.Contains to quickly check to see if a whole sublist from Elements to Find exists within a (index matching) sublist in the Search Pool, but it won’t tell you which Element it matches. (Example below.)
Another easy option for checking multiple parameters is just to concatenate all the values into one string and compare a singular item. You have multiple options here depending on exactly what you want.
That should work. You might try closing and reopening the graph.
This is where it would be easier to transpose your data and deal with the parameter lists instead though. Then you can join/concatenate everything into a single string and compare one value.
So this has turned into a bit of an interesting situation. I have been testing the same graph in 2023 and 2024 and I am seeing differences in the way the transpose node is working between the two.
What would cause something like this? Same exact elements in these lists. One shows as System.Collections.Arraylist and the others show as System.Strings as they should.
Nothing changed with that node as far as I’m aware. The Object.Type node just seems to be treating the array (sublist) as the object instead of the individual strings, but the array still contains string objects. We can’t really say what else could be causing the issue without you showing us side-by-side comparisons of the two versions. What issue are you having anyway? The structures and outputs still seem to be the same.
Well…I solved the issue. It was due to Orchid. Either the recent update to Revit 2024 or updating to the newest version of Orchid was the issue (I did both of those things around the time that this may have broken). In either case, removing the Orchid package fixed the issue.
To be clear, no Orchid nodes were used in the graph…simply having it installed was causing the issue. This may be due to a strange interaction between Orchid and Orkestra that is currently being looked at. I am copying @Mostafa_El_Ayoubi@erfajo into this for their information.
Hi there! I wanted to take a moment and offer some more information that seems to be leading to these kind of errors.
As zerotouch package authors, we use Nuget quite often. Nuget is a package manager for coding, and the dynamo team shares the binaries for dynamo on there.
Unfortunately, the dynamo team had a bad upload that included a newer binary in the 2.19 version. Orchid referenced that version and it resulted in these errors. (ProtoGeometry 3.0 was included)
So the team is aware and I hope they fix it soon because, to put it simply, it is unfair to single out a specific package for a mistake on the Dynamo team’s part.
Also, orchid has been updated to fix this. So if you get the latest you should be fine.it would actually be really helpful if you could test and verify for the team to see.
I didn’t mean to make it sound like I was blaming Orchid (or @erfajo) for the genesis of this issue. I probably could have phrased things better.
Unfortunately, the only way I could solve my issue was by removing Orchid. I just want others to be able to have this information available if they run into the same problem and also need to fix it. I have over 100 graphs deployed to my company via Orkestra and some of them are relied upon daily so problems like this require quick fixes and usually cause the greying of hair, lol.
Regarding the versioning of Orchid, I had updated it on Wednesday of this week but see that it was also updated yesterday. If the fix was implemented yesterday, then I will certainly redownload it and test it as soon as I have time (maybe tonight after my wife goes to bed).
Lastly, it isn’t said enough but thank you to all of the developers that spend thankless time creating these amazing packages. While I have been moving away from package usage as much as possible to limit potential issues, I still rely on them heavily. I don’t know how you all keep these packages working as well as you do with all of the changes that get thrown your way on a yearly basis.
@john_pierson Package Doge is still one of my favorite tools and has made updating graphs so much easier.
The new version 2.19.1.6264 is still having issues loading properly. I am unsure if it’s the same Nuget issue or not. I see references to Proto so maybe it is? I have attached the error below. I will also report this on the Orchid Github.
