hmm found another bug, or maybe it has something to do with the plugin Block_Edit_New, but I think this worked before perfectly fine..
When I have a group and use VaBeam from curves, when I “close” the group the Beams disappear.
When I use a block instead, the Beams move like you see in the videos.. and get converted to blocks, when I insert these blocks to the their position they stay there so it has smth. to do with the vaBeam-Element and not with a block
Is there a possible fix? working without Block_Edit_New is something I don’t want to think of..
The bug in the second video might be related to the coordinate system of the ARQ object itself. Here’s a more straightforward example: when you use boxmapping, the influence of the boxmapping isn’t calculated based on the relative position between the box and the object, but rather on the relative position between the box and the WCS origin. This is another annoying bug.
Hi @Sebastian_Wimmer excuse the late reply on this issue.
In your file there are a couple of blocks, but no beam. I’ve tried to run the vaAddInterferences command between a beam and an extrusion, and everything works fine. Can you check it again? I’m using VisualARQ 3.5 rc1 (VisualARQ 3 - Version 3.5 RC1 released)
@Sebastian_Wimmer how are you making these menus appear on top of the group? are you using a third-party plug-in to edit groups? I suspect the issue reported here might have something to do with some incompatibility between VisualARQ and that plug-in.
In your second video, correct me if I’m wrong, you have all these curves inside a block. Is that right? and you are creating the beams from the curves inside that block. I’ve tried it and it works fine on my end. Can you try it again with the 3.5 version?
sorry due to an injury I had to step back for a while.
Yes this happens with a plugin, (as stated “Block_Edit_New: Block Edit New | Food4Rhino - you should def. try it)
Sadly I do not know what happens internally, maybe some sort of ID problems.
I have to admit, I really don’t want to work without the plugin anymore - so if you have a hint on how to get it working, this would be much appreciated.
we are getting closer it seems. @slodka you are partially right - it works now with groups which is a great thing! but it still struggles heavy with blocks as you can see here in the next two small clips:
DESCRIPTION: I made two VA profiles, grouped them and blocked them - grouping works but blocking gets rid of the VA “column” tag and thus you can not change the parameters in a VA way.
Clip2:
When I copy VA Elements into the block: (yes the Elements will change into regular blocks but nonetheless..) the coordinates of the copied blocks change AFTER I save, when I do this with a regular block the coordinates will not change.
so BlockEditNew improved quite a lot - unfortunately there seems that something happens with the VA Objects internally that they move positions. It would be great if someday we are able to block VA Objects with this handy plugin and keep their parametric-state. In addition on the front of rhino, it would make all the difference if someday we would be able to have groups inside blocks that will not explode after saving and being able to dimension things inside a block and still keep the history “dynamic” the dim has outside a group.. dreams it seems..
I think the remaining issues should be related to Rhino or ARQ itself. The new version of BlockEditNew is compatible with Rhino’s built-in BlockEdit, so any further block-related problems are likely more underlying ones. However, you can also send your questions to the plugin’s author—they are happy to receive new issues and try to resolve them.
@Sebastian_Wimmer I could reproduce both issues you report here when using the BlockEdit plugin.
If you use the native Block Editor in Rhino, these problems don’t happen. We need to investigate if this is something that needs a fix from our side, or from the BlockEdit plugin developers.