So as the title explains i have a weird bug with a Python script moving Rhino objects looping back to start of grasshopper script BUG!
Weird in that ;
if all objects are moved on various layers everything is fine,
if one or more objects are moved on the same layer that are inside and outside the boundary everything is fine
If one or more objects on different layers are inside and or outside the boundary it breaks as it moved objects on the second layer the amount of times that the list length is so fails.
I have looked into trying to add the Python code so after it has run it expires and doesn’t loop back to the start, but this had no effect and even using the buttons so it wasn’t automatically on didn’t fit the bug.
Note black boxes are in the file for visual refence they won’t be final design
Red Shift line is hard coded in the example to remove one of the variables to check, but this will also come from the script later.
import scriptcontext as sc
import Rhino
import Grasshopper as gh
if B:
sc.doc = Rhino.RhinoDoc.ActiveDoc
for ID in IDS:
Obj = sc.doc.Objects.Find(ID)
xform = Rhino.Geometry.Transform.Translation(V)
sc.doc.Objects.Transform(Obj,xform,True)
sc.doc = ghdoc
Updated Grasshopper script below to fix some of the redundancy pre python section of the grasshopper script. Moving Rhino Object Bug_01.gh (19.1 KB)
I am wondering if one workaround to this issue is putting everything onto a Temp layer moving them then putting them back on the right layers. But this seem like a lot of hassle for something that should be a simple fix but i have overlooked.
Is this rhino 7 or 8? 8 has a few more tools to deal with this.
There is a bit of a logic issue that may be happening. In Grasshopper a Move is actually a Copy. Because it is a functional language, the inputs should not be changed later in the definiton as the the solution. In this case each individual moved changes the inputs.
Yes, but not everything in the upper box would have been drawn when the first geometry is moved. I was locking the objects in my example so the Geometry pipeline would read them when i clicked the first button and unlocking them before pressing the second button.
Firstly to move all the Incoming geometry pts and curves down a shift line from the corner of the boundary box of the the pts data. As Rhino don’t like things miles away from 0,0,0 and this project is at a civil engineering scale.
Secondly and were i am having an issue is moving additional curves (previously locked at the start) that have since been imported at true location down this shift line.
As the end users are not competent Rhino/Grasshopper users i though would try and write a short script to help with the file setup on the rhino side.
That’s and interesting work around, the reason i hadn’t taken this route was the geometry being moved in the original file is very large so was trying not to move it with Grasshopper, then having to delete the copy, but i guess as i am referencing it in to create the boundary box, moving and re-baking it should be fine, i will give it a test.
The other option would be leaving the code is for the first move and justing doing the rebake for the simple geometry on the second move that breaks if i give objects on 2 layers to move.
This bug is still odd though how it only fails on the last variation, but not the others.
Weird in that ;
if all objects are moved on various layers everything is fine,
if one or more objects are moved on the same layer that are inside and outside the boundary everything is fine
If one or more objects on different layers are inside and or outside the boundary it breaks as it moved objects on the second layer the amount of times that the list length is so fails.
