@Gijs
Maybe we start by a common situation. I have toiletdoorA that is repeat through out the project, I use it on the several toilet blocks of my building1 of which there are several different layouts blocks. it is also on building 2 and 3. The door should never change its name in any of the buildings and also not is the combined file of the three buildings.
It currently does already work like that. When updating a file with toiletdoorA, which already exists in a combined file, the block name conflict dialog box will ask me if I want to add it as a new named instance, replace with the new block or keep the current. Typically by convention (1), we replace with the new block (2). The default option (3) is the worse of all and when the dialog does not appear that is what provokes the renaming.
- In Rhino 7, when you open a file with a linked block that needs updating, it asks you if you want to update, if you say yes, the Block Name Conflict dialog box comes up (this doesn’t happen in Rhino 8 - it should!).
- When you edit a file that is linked in your file,
BlockManagerwill highlight that the linked file is newer, when you update it, the Block Name Conflict dialog box comes up. - When you double click a linked block, on returning to the file, the Block Name Conflict dialog box does not comes up
Rhino should check if the updated file has blocks that are already in the scene and pop the Block Name Conflict dialog box if that is the case. It would 100% solve the problem.
Please note that this issue occurs even if you accidentally double click a linked block and return to the main file without saving!
To bring the example two or three posts above further, because I realized I had not reach one point that I reached in an actual example in my working files.
After that sequence, create a file called ‘2nd Child.3dm’ and insert embedded and linked only on ParentA. the second time you BlockEdit Parent A, and close it (even without saving), 2nd Child is renamed, even though it is not on ParentB and is only in Grandparent through ParentA itself. The reason being that since there is no Block Name Conflict dialog box, it took the default option for all the blocks in ParentA irrespectively if they were repeated in the main file or not.
You multiply this by several blocks per generation and quickly you have chaos. This should really be taken in consideration as a big problem.
N
Notes
(1) it would be really good that this would be scriptable or there was a way of changing the defaults to avoid unnecessary mistakes. Wish: remember the last Block Name Conflict choice - Rhino / Rhino for Windows - McNeel Forum
(2) Typically, we replace with the new block. If it the wrong option is easily fixed because it keeps the same name. The only bad option is the default because it is not easily fixed.
(3) Add a new named instance is the default and never ever have we used this, it is super annoying that . Wish: remember the last Block Name Conflict choice - Rhino / Rhino for Windows - McNeel Forum