Next we’ll import this other file which has a big line of tapering gems and prongs. Something of note here is that the objects in the file above originally came from this file with the complete set of gems. They were purged and then exported into a new file by themselves. Tapered Bead and Bright with Shared Prongs.3dm (3.0 MB)
I’ve got a theory, but I don’t know enough of what goes on behind the scenes in Rhino to know if it’s plausible.
The 1.50 mm gem group was made from the Tapered Gem file, so the objects in them have the same RhinoID. (I may bot be using the correct term here, but essentially a unique identifier that Rhino uses to track objects)
We array the gem group and then delete the parent prongs.
We import the tapered gems. Normally any duplicate objects get assigned a new RhinoID, but because the original prongs got deleted, the imported prongs get to keep their original RhinoID.
When we move/rotate those new imported prongs, Rhino thinks that this new prong is now the parent of all of those arrayed prongs in the file.
History updates the arrayed prongs to the new imported prongs.