Am I going mad here? I have a tree {X,Y}(Z). I want to insert an item after {-1,-1}(-1). I’ve tried so many ways but cannot do this? Insert item only works for lists, and GHPython does not handle trees at all logically (I cannot get it to read a tree to do a simple list.append(x) task!
I’m rather stressed about this! Is there an easy way I’m missing?
If you’re using negative indices you’ll always run into trouble. Either immediately because of a index-out-of-range exception or down the line because most logic expects non-negative indices.
You posted this in Grasshopper, not Grasshopper Developer. Is this a Python, a C# or a vanilla GH question?
Honestly, I just need it to work; ideally in native GH. Hopefully the image clarifies. I’m sure it is a simple task - however I am getting mighty frustrated that I cannot do it easily in either GH vanilla or Python! I’m sure this is user error.
the funny thing is, the moment you start to script in grasshopper, you actually don’t need much tree manipulation anymore (and you don’t want to solve these little Sudokus all the time). “DataTree” is a C# construct, you can call it from Python but it doesn’t feel pythonic. Although I believe Tree management will always be difficult within a visual programming language. So I don’t think DataTrees are bad implemented.
Yeah that is true… Maybe it would be useful for some gigantic urban planning projects with millions of data… but at that point you will have to use database in some other platforms than Rhino…so…
Sadly the scripting components are not great at providing tree features. In grasshopper proper data trees are stored inside a class called GH_Structure<T> with a type constraint on T for IGH_Goo. It was felt that that was needlessly complicated in scripting components, so a second tree class was created called DataTree<T> with no type constraints. What you really want is for tree operations to not mess with the data inside the tree at all, only with the tree layout itself. This is not possible in scripting components, since they will convert a lot of data types into simpler types, ditching a bunch of information along the way.
You can’t make it work for booleans and integers because null-states are lost when converting to a struct. You can’t make it work for Points, Curves and Breps because reference information will be lost.
Also more complex that it should have been. In GH2 this works completely differently, doubtless there will be new problems, but none of this double-bookkeeping/data-layering horse exhaust…