"Filled Region: BackSplash" has been renamed to "BackSpash 38" to avoid conflict

[josh.hafel]

I am working on a multifamily project and each unit is its own RVT file and I am loading them in as model groups (so that I can use the attached detail groups for specific drawings such as furniture can be turned on and off depending on scale) It has been working great except for each time I edit and reload the model I get the message:

"Filled Region: BackSplash" has been renamed to "BackSpash 38" to avoid conflicts with the existing element"

but at the same time, other filled regions such as "Solid - White" are not giving the same error.

How can I either consolidate these to be the same Region so that I can delete the duplicates and/or how can I load in a group and just replace the pattern like it prompts me to with casework families?

[nathan.chapman]

Are you changing the filled region within the group edit mode?  Example creating a new type?  You will get this warning if adding/modifying them within the group edit mode.  Change outside and add to the group.

Regards,

Nate

[josh.hafel]

The region was created in the UNIT file so it can be turned on and off as an attached detail group. It is then being brought into the parent file when I import.

I get what you are saying, that this would create a new type each time. My question is though is why are other families that are created in the UNIT file (such as casework, doors, lights, etc.) default to using the parent file's Family, but it makes duplicates for the filled regions (which filled regions are also a family according to the project browser) Look at the attached because I am not sure if that will make sense to other people. It is just annoying to have 40+ "different" types that are the exact same thing.

I want revit to do this with filled regions of the exact same name.

[barthbradley]

That would annoy me too. I don't understand why it is happening to you though. 

So what you are saying is that each time you use Load as Group to Replace an Existing Group, Revit duplicates the Group's Filled Regions?  

...You know, you're using some different terminology between your two posts.  Could you walk us through your precise workflow?  

[josh.hafel]

Yes, you summed it up perfectly, but I'll walk you through in more precise detail.

The project is a multifamily project. There is a single "parent" file that houses the shell of the building, and each unit is it's own file separate from the parent file. (i.e. Unit A1.rvt). In the UNIT file, we will place in things such as furniture, annotations, etc. Then we insert the UNIT file into the parent file as a model group so that the furniture and annotations are brought in as attached detail groups that we can turn on and off. When we make and edit to a unit and reload it or bring in a new unit, certain families (such as filled regions) are being duplicated to "avoid conflicts". I would rather Revit just replace the unit file families with the one the parent file already has loaded like is does with doors, casework, walls, lights, etc (this is in my previous post)

I know that was probably too detailed, but I hope this helps

[barthbradley]

---

@josh.hafel wrote:

I know that was probably too detailed, but I hope this helps

---

No, not too much.  What version?  

[josh.hafel]

It's in 2019

[ToanDN]

Do BackSplash and BackSplash 38 have an identical definition?

[josh.hafel]

Yes. They are identical 

[ToanDN]

Do this test:

- Save an unit to a new file and Transfer Project Standards from the parent file, choose Fill Patterns and Fill Region Types only, save the file

- Insert this new file in you parent file and see if the duplication still occurs

[josh.hafel]

That didn't work for me, I just gave up on this issue. What I ended up doing is just making a wall hosted family and applied the pat file to the family. Rather than using an annotative filled region. I can't turn it on and off with attached detail groups, but I can hide the family if I need to. Regardless, its better than having 40+ Duplicates. Thanks for the help though!