Listorder groupelements not the same

Packages
,
1

@Andreas_Dieckmann, others,

We’ve had a nice post how to get a mirrored state of a group (Group is mirrored (or not)), you created your own ‘version’ more robust etc. of it.

Now I’m running into this interesting dynamo/revit thing which will fail your script.

The fail is because the list order of items isn’t the same for the reference groups… or for some.
Since you use a counter to check the mirrored state of that specific instance, in my case it checks a wall. So original num=0 (a door), checked groups has num 0: door, door, wall, door, wall etc.
So SOMETIMES it’s ok, SOMETIMES the list order has changed and therefor compares the wrong item.

Now things get really interesting. -.-

I’ve created a simplefied version of what I experience.
the screencast should be explaining itself (can’t do voice / audio).

Any thoughts on how to further bulletproof your node?
Or how to prevent / ensure the list order is always the same.

BTW: removing the strange-order-groups results in a correct working GroupIsMirrored node (returning false/true)

2

Yesterday was one with testing, testing trying to recreate a changed-order-group.

  • changing parameters of an element in group: no impact
  • exchange of groups: no impact
  • exchange of elements in group: no impact
  • adding a new element to group is always at the end of the list

Finally I figured it out: exclude members.
So excluding a member of a group and “restore all excluded” afterwards adds those members to the end of the groupmemberlist.

In my case a familyinstance was excluded, so that messes up the group.ismirrored idea. :pensive: @Andreas_Dieckmann

So moving on from here, what other options would we have?

  • adding an dummy item to the group, test it’s mirror.state, do routine, remove dummy from group (we probably need a nasa-computer)
  • trying to figure out how to get the order correct?
  • unique members is tricky, since that is not always possible

Please feel free to jump in!

3

@3Pinter In order to make the node a bit more robust, an additional check could be added that verify that the familytype of the group members that are compared matches.
I’ll try to squeeze that into the next release.