If I send changes to a group from SketchUp and receive them in Revit, Revit duplicates those groups with the same name. This happens if I only move the element in SketchUp, or if I don’t make a change but resend the same information to the stream. Revit will duplicate the group and place the new group in the same position as the SU model relative to the origin. In order to match the SU file I have to delete the older copies of each group after every “receive” from the Revit connector. Is this normal?
I’ve tried to “ignore” elements that already exist but get the same result.
SU Pro 2022
Speckle 2.3.14 (I’ve tried to download 2.7 but the installer only installs this version)
Also, I receive this error when receiving the SU data in the Revit connector:
A group has been changed outside group edit mode. The change is being allowed because there is only one instance of the type.
Hey @jabarig ,
Thanks for the report, it sounds like the Revit connector is not picking up correctly pre-existing elements, I’ve logged it here: Block Conversion not checking for pre-existing instances · Issue #1522 · specklesystems/speckle-sharp · GitHub
It should be a relatively simple fix so we can hopefully include it in 2.8!
Am I installing the latest version of Speckle correctly? If I download the installer from this url https://speckle-releases.netlify.app/ the app installs version 2.3.15.
Is 2.7 not available for Windows?
Hi @jabarig ,
You are doing things correctly: the version of Manager is not the same as the version of the connectors.
Once you open Manager you should see all the available connectors with their versions:
Hi @jabarig , I just merged a fix for this issue - it should be available with our upcoming 2.8 release
Just a note that currently, groups in Revit will only be ignored/updated accordingly if they have been previously received. If there is a group of the same name already existing in a file that hasn’t been received prior, you’ll have to continue manually deleting that copy. Unfortunately there wasn’t a quick and easy fix for this, but we will probably refine this behavior in the future!
Thanks so much @clrkng! I sincerely appreciate it