I’m storing an array of points in an attribute library:
[Point3d(216, 0, 0), Point3d(348, 0, 0), Point3d(348, 132, 0), Point3d(276, 132, 0), Point3d(276, 48, 0), Point3d(216, 48, 0), Point3d(216, 0, 0)]
However, I’m noting that when I move the group with this attribute library the points are updating to reflect that translation. How do I make the points so that they are static and do not get updated when the entity is moved or rotated?
I suppose I could switch to an array of arrays: [[1,2,4],[216,0,0],[348,0,0]]
What do the points represent? A position inside of the group in its own coordinate system or a position in the coordinate system it is placed in? For the latter it is very handy that the positions updates when you move the entity, but sadly the behavior isn’t documented so people can get quite surprised by it. If you want to define coordinates relative to the inner coordinate system you can save the attributes to the ComponentDefinition object or possible even the Entities object.
I decided to switch to the nested array system above. It seems to work fairly well and it doesn’t update on me.
ideally, you should store the absolute minimum number of chars…
so if your array isn’t retrievable from the component definition, it would be better still to flatten it first…
ary = [[1,2,4],[216,0,0],[348,0,0]]
store = ary.flatten
# => [1, 2, 4, 216, 0, 0, 348, 0, 0]
retrieve = store.each_slice(3).map(&:to_a)
# => [[1, 2, 4], [216, 0, 0], [348, 0, 0]]
although this may seem like a minor saving, there are threads on SketchUcation showing disproportionate file bloat caused by verbose attributes…
they do not need to be ‘human readable’ as your only code needs access…
I do tag any of mine with my namespace ‘JcB_<Extension_Name>’ so end users can choose to later purge them if desired, e.g. before sharing a flat copy of the file…
john
I suspect bloating attributes have duplicated data, embedded images and other media and cached data that could really be calculated on the fly, not an abundance of control characters.
With regards to bloat, I’m a big advocate of small file sizes and keeping things lean and mean but in this case I don’t think the savings are really enough to worry about. There will only ever be one such array for any foundation assembly and most models will have one or two assemblies per file, so I think this is manageable.