Hi @michaelvollrath !
Thank you very much for your reply and response via the .gh file!
I do think it is neat that one can directly ‘move’ and alter an existing RhinoObject this way, but at the same time I’m robbed of choice and flexibility in the matter. Before, I could also “move” by way of making-a-copy-and-deleting-the old, which incidentally is what ObjectTable.Replace Method (ObjRef, RhinoObject) does anyway!
If you look at the output of you array of cubes in your response however, they are all missing their UserText. You’d have to separately pass those on too!
I’m trying to avoid this kind of thing:
… where I wire every output of a ModelObject/-Layer to the input of another except for the few I want to modify.
I did at some point create a Cluster that does this the hopes of bypassing the issue, but it feels kinda clunky to manage.
… aand what’s more I don’t know what other attributes might not be accounted for.
For example, if I do go the route of passing every Output of the ModelObject and -Layer onwards and then bake, some attributes not accounted for by the current components get lost, like for example the “New Detail On” -property which was set to “Off” for the original layer. It ends up on the default mode “On”.
Because of this, I don’t know what other data and properties from the original Objects and Layers I’m losing along the way, which is kind of a bummer, as the “Pass-through” feature of these new components would be so awesome to use (as they are in EleFront)!
… so why not just use EleFront? As awesome as it is it’s never handled annotations and their style-overrides - especially in conjunction with Blocks - very well. I’ve been hoping that Native Rhino 8 Grasshopper functionality would at last come in and set everything straight, as I hope it yet will.
Here’s my response via .gh file as well, showing the “wiring nightmare”.
20240215_Rhino 8 Comparing EleFront 5 to Native Workflow_Response_01b.gh (60.4 KB)
I hope I don’t come across as unpleasantly sarcastic! I’m just having a bit fun 