Block Name Conflicts with "-Insert"

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.

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

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?

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

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

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

Hi JB -

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

1 Like

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

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

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