It’s a known bug that some dimensions to certain objects are unstable.
But once they’re no longer associated with the blocks I believe they are stable (if not, maybe someone will let me know). I’m not sure how to accomplish that with a dimension that’s been snapped to a block - and retain the dimensions editable node structure (so exploding is not an option.) Appreciate any ideas.
I don’t understand what you mean by unstable, but trying to see what you might be talking about I see that dimensions snapped to blocks don’t update with history.
That’s at least a place to start.
Thanks for the thought. The post evolved thusly: Dimensions between VisualArq blocks and curves rearrange themselves erratically and drastically, snapping to points in empty space without apparent logic, if any of the objects are altered in any way. I haven’t tried this for other types of blocks, but am told by the VisualArq dev team that this is an issue dimensioning all Rhino blocks, which would make it a general Rhino issue (which is why I posted it here.)
I’m still pretty unclear on the details of your problem. Who at the VisualArq dev team did you talk to about this? Maybe I can find out more from that person.
I’ve made some changes in the past weeks to fix a couple of dimension history update bugs, so the specific service release of Rhino will make a difference.
None of those fixes were specifically about blocks though.
Thanks for your attention to this, Lowell.
You can find the issue discussed, and a gif of it happening, here:
Thanks. I see that discussion.
I’ll be away from work for a few days, but I’ll see what I can figure out.
I’m wondering if there’s an update on this.
Blocks are useful, and dimensions are critical, but as of the date of this post 8 months ago any dimension snapped to part of a block was unstable.
Any update on the status of this issue?
thanks
Hello -it looks like VisualArq is part of this, at least at some point, is that still true? On the thread you linked above it appears to be fixed in SR9, but I guess it is not, for you, correct?
@enric … just fyi, in case you have a thought…
-Pascal
Thanks Pascal, but I’m pretty sure it’s a problem which cropped up with any dimension snapped to any part of a block. At the time of the OP we tested it and that was the consensus.
I don’t recall what Rhino version was active last fall, but I’m pretty sure the issue was still present at that time.
I haven’t tested it out at this point. After a few non-Rhino months I’m refreshing my memory about different issues and workarounds and hoping there’s been some movement on some of them.
Hello - OK… well, here at least, in the latest in-house build, and a simple example, I do not see the problem you describe, if that is any comfort.
-Pascal
The reason I haven’t tested it at this point is that it takes time for the bug to evince itself. A bit of zooming around, switching view types, maybe some saving and opening again… it could be over a half hour of use. It feels like a task for a beta tester.
Do we know if this was a documented fix in 6.9 as that post suggests? I"ll take it at face value if so.
thanks.
@fsalla answered this question in your other post.
FWIW, I couldn’t find a YT item in the system that specifically targets any of these threads, so I wouldn’t know. Perhaps Francesc or @enric knows which YT item this was.
Me neither. That’s why I am double checking.
Can we users register and sign into the bug-reporting system to be alerted on the progress of a fix?
Yes. You can also add comments and even file new bug reports and wishes in that system directly.