Block Name Conflicts with "-Insert"

Rhino
, , , ,
1

Is there any way to force the “-Insert” command to keep the “model block” or “file block”, like the normal “Insert” command lets me do, rather than keeping both with a file name increment?

If I insert with the dialogue box, I can choose which block to keep. Example:

Can I access these options with the command-line only “-Insert” command?

Some background:

I’m using the -Insert command to load in a bunch of external files. (I actually have another script choose a whole bunch of these and have it run the command several times one after the other. Very fast and useful for parametric assemblies.)

Everything is working well - the blocks inside these files are also brought in “embedded” as I require for my application… but, identical blocks with identical names get defined twice

For example, let’s say I have two block assembly models to insert into my main model:
assembly1.3dm (this model has a block def inside it: “20mm Screw” & “05mm Screw”)
assembly2.3dm (this model also has a block inside it: “20mm Screw” & “10mm Screw”)
assembly3.3dm (this model also has a block inside it: “20mm Screw”)

I can import both of these with the command-line no problem, but afterwards, in block manager, I would see:
05mm Screw
10mm Screw
20mm Screw
20mm Screw 01
20mm Screw 02
assembly1
assembly2
assembly3

On large assemblies a lot of the time I save automating the process is wasted removing duplicate block definitions. I’d really like it to just override existing blocks.

I don’t mind if it’s an advanced option, a modified clone of the original -Insert command, Python or whatever. I just need to be able to import external files and have any blocks inside the file brought in as an embedded block without making duplicate block definitions in the block manager.

2

Hello- I’ll test - it may be that you can work around for now by running the command, setting the dialog as you like it - and checking the box for ‘Do this for all block name conficts’ then run the scripted version.

-Pascal

3

Hi Pascal,

Thanks for the suggestion. I have tried that already and the ‘Do this for all block name conflicts’ option seems to only remember the choice for all conflict on that instance of the Insert command running.

It’s not a persistent choice that is remembered or stored between running the Insert command the first time and the next. Or at the very least, it is not remembered by the -Insert command. And that’s probably for the best.

We use the Insert command as part of our process too and I don’t want our automated tools creating dozens of copies because somebody forget to set “remember” command after a normal Insert command an hour earlier.

Is the -Insert command RhinoScript? Can I create a duplicate command with a small change in how duplicate block definitions are handled?

4

Yeah, I understand, I think you should be able to do what you’re saying and I see it is broken. I’ll chat with the developers…

-Pascal

1 Like
6

Hi Wortley,
Looks like an oversight and this is the first time it has been reported here.

When a file is being inserted “real time” as block and there is block naming conflict, Rhino 6/7 will ask the user to relace the block, or create new one.

At the time that work was done in Rhino 6 development, the scripted -insert command was apparently not modified to include these changes.

We agree the -insert command should have conflict options available to set on the command line.
I will get that logged as a bug and let you know here when it is fixed.

The persistent setting will likely not be adopted since it was was tried in a beta of Rhino 6.
Testers reported that they wanted to be asked for each block.

Thanks for being this to our attention.
Sincerely,
Mary Ann Fugier

1 Like
7

Thanks Pascal and Mary Ann,

I appreciate you guys looking into it seriously! I would be thrilled to have the command work as described.

Looking forward to it.
-JB Wortley

8

Hi JB -

This issue was filed as RH-69709. When it gets resolved, this thread will be notified.
-wim

1 Like
9

Thank you Wim,

If there’s one thing I may request when implementing this:

Can we have the command always ask what to do with block conflicts, regardless of whether a conflict is detected or not?

This would be great for automation: A series of -Insert commands can then be scripted to run one after the other and not break if block name conflict is detected.

Alternatively, can we make it so that the block conflict dialogue is dead last in the command? This would allow most users to hand-pick their blocks as the command is no doubt intended to be used - but for scripting, a predetermined option can be tacked onto the end of the command every time just in case and would simply do nothing if no name conflicts were detected since the command already finished running.

If the name conflict dialogue is going to ask what to do for each and every block name conflict, can we also have the options “Keep Both for All, Keep Original for All, Keep Imported for All” ?

Sorry if this a bit of a weird ask. But to me, the biggest appeal of this command is the potential to make it a nice hands-off tool to automate and make design a bit easier.

Thanks again for looking at this.
-JB Wortley

10

Hi JB -

The scripted version of the command will have to provide access to all settings when the command is used. That’s how scripted commands work.

There aren’t any dialogs when using scripted commands.
-wim

11

There aren’t any dialogs when using scripted commands.

Sorry, by dialogs, I don’t mean dialog boxes. I mean the prompts.

The scripted version of the command will have to provide access to all settings

I understand and that makes sense. I was just thinking of having something like this, so that if users already know their choice, the exact command prompt order is predictable:

Command: -Insert
Name of block to insert ( File=No ): File=Yes
Name of file to insert ( File=Yes LinkMode=Linked Browse LayerStyle=Active ): LinkMode=Embed
Name of file to insert ( File=Yes LinkMode=Embed Browse LayerStyle=Active ): C:\Filepath…
Insert as ( Block Group Objects ): Block
For block name conflicts (AskForEach, KeepOriginal, KeepImported, KeepBoth) : KeepOriginal
Insertion point ( Rotate Scale ): 0,0,0
Scale factor <1.000> ( ReferencePoint XYZ Rotate ): 1
Rotation angle <0.000> ( AxisAlign ReferencePoint ): 0

In this way, a script or macro can run through all of the commands in a perfectly predictable way and people still have access to block by block prompts if desired.

My alternative would have been something like this:

Command: -Insert
Name of block to insert ( File=No ): File=Yes
Name of file to insert ( File=Yes LinkMode=Linked Browse LayerStyle=Active ): LinkMode=Embed
Name of file to insert ( File=Yes LinkMode=Embed Browse LayerStyle=Active ): C:\Filepath…
Insert as ( Block Group Objects ): Block
Insertion point ( Rotate Scale ): 0,0,0
Scale factor <1.000> ( ReferencePoint XYZ Rotate ): 1
Rotation angle <0.000> ( AxisAlign ReferencePoint ): 0
A block called “10mm Screw” already exists. Would you like to (KeepOriginal, KeepImported, KeepBoth, KeepOriginalForAll, KeepImportedForAll, KeepBothForAll) : KeepOriginalForAll

In this second example, putting the prompt last means that if no name conflicts are detected the prompt doesn’t need to appear. A script running over “KeepOriginalForAll” when the command is already finished will harmlessly enter it into the command line and it will execute nothing. If a conflict is detected however, it will work as needed and the command will end normally.

Personally I find the first option more logical, but will take whatever order you guys go with. I just want to be able to run this command reliably several times without user intervention.

-JB Wortley

12

Hi @wim,

Do you know of any progress on this by any chance? I’ve had a look at the issue tracking for this on the link you gave and it looks like Dale Fugier has taken over, but the only thing that has been logged since is that the issue type has been switched from Bug to Enhancement and a release target 8.0 has been set? Does that mean Rhino 8 - the next major release? (Is there even an open beta for that yet?)

I’ve been holding out on paying for a professional programmer to script something, since it looked like we could get an official fix out soon. We have tools based on this command and were hoping not to have to start from scratch on a new block inserting solution since you guys have recognized it as a missing feature.

I would love to hear back so I can work out what to do next. I just need to know what kind of timeframes I’m dealing with so I can work out the best solution for me and my team since the bottleneck of not being able to automate as planned is hampering our workflow and ability to grow.

-JB Wortley

13

Hi JB -

Starting with that one… WIPs and Betas are only available to holders of the current version of Rhino. At this point, Rhino 8 is in the WIP stage and can be used by anyone with a Rhino 7 license.

As you found out, RH-69709 is currently on the 8.0 list. At this point, only severe regressions from Rhino 6 and crashes are being fixed in Rhino 7. To me, this issue having been categorized as an enhancement makes it more likely that this will be moved to 8.x or future at some point.
Bottom line, if you need this feature now, you should probably look into having someone implement a solution for you.
-wim

14

Hi Wim,

I wasn’t aware Rhino 8 WIP was already out, but as you’ve mentioned, the reclassification of the issue means that it probably won’t get done until after full release, so no point to switch us over now.

If you know of any top notch C# or Python coders for hire on something small like this, let me know. I’ve got a guy on Fiverr who’s going to give it a shot, but not sure how much higher than my own skills I’d rank him at first glance. I guess we’ll see with this.

Thanks for the heads-up.

-JB Wortley

15

RH-69709 is fixed in the latest WIP

16

I am playing with the latest WIP and need the option to replace existing blocks. But the options we now have seem to only relate to the Nested Block Warning (Redefine/Keep both), but not the Block Name Conflict dialog box where there are 3 options?

I am looking for a way to Insert a file with Block Definitions and use the middle option (Replace with imported block) using Scripts.

No matter which option I chose in ResolveConflict, the imported blocks which already exist in the document get renamed upon import.

Can you confirm that the ResolveConflict options relate to the nested block warning or the block name conflict warning?

17

I don’t have an answer for your scripting question, but I did run into this problem and maybe someone would like to know what I did.

It happened to me because: I define small reusable items (e.g. screws) to be inserted as blocks in many files.
And I build a model by combining smaller parts, each from their own file.
So Rhino complained about block name conflicts very early on, e.g. when I combined two assemblies that used the same screw. The screw block had the same name in both of them.

As Ms. Fugler said above, testers liked to have this issue reported to them, during their tests. Well, each and every times I opened my model file I was being asked the question a dozen times, so I didn’t like it.

MY SOLUTION was… link everything. All of my blocks are now inserted in “Link” mode. Rhino reads the source file for each and every little block when I open a file. And Rhino, thank goodness, is smart enough to deduce that they’re the same block when they come from the same file at the same time. This wouldn’t happen with “embedded” blocks because the file location is either forgotten, or not trusted to be current.
One benefit of this approach, of course, is that the files are as small as possible - nothing is duplicated.

AND ANOTHER SOLUTION occurs to me. If you need to “embed” some blocks rather than “link” everything, then at the moment of insertion, quickly edit their name.
e.g. when you’re inserting “5mm screw”, change the name to “5mm screw, in window”.
That way the name conflicts won’t happen - but you will have embedded multiple copies of blocks, making your files larger.

David