Hotlink Wall Duplicate

[Lingwisyer]

Hi all,

One of my hotlinked buildings has some odd things happening with some walls and their associated SOEs. These walls are part of a second hotlink. On the top floor, the wall, and other elements within this second hotlink, appear to be duplicating themselves. The duplicate is not cut by the SOE operations applied to the original.



Ling.

[Barry Kelly]

Lingwisyer wrote:
The operand is on a layer with an Intersection Group of 0 so all intersections are ignored.

Is the intersection group 0 in both the mod and host file?
I am just guessing here.

Barry.

[Lingwisyer · Accepted solution]

Figured out what the problem was...

It was to do with the Master Layer of the balcony module within the building hotlink. The top balcony was not on the Hotlink - General layer. This resulted in conflicts with layers regarding different design options. From this, I am assuming that the Master Layer of any nested hotlinks will change to match that of the host hotlink.



Ling.

[Ignacio Azpiazu]

Master layers will remain what they are. Nested modules will keep their own master layer defined in the module creation file, and be placed on the host file within a module which in turn has its own master layer, so you have two nested levels of control for visibility and publishing.

Nested modules are best broken when publishing modules, keeping file production structure hierarchic, and I can't think of a reason that would justify keeping their link live. They create opportunities for huge management headaches and element duplications.

Master layer is best kept to Archicad layer for all cases unless strictly necessary (a case being when you need to be able to turn off unit interiors for certain drawings, such as site plans, building RCPs, finishes, building sections), because they become a management pain for view, publishing layer combinations.

[Outdated: Keep away from SEOs, trims, merged connections between an element in the module and an element outside the module, they quickly become unmanageable. You can create and publish them within the module, if necessary using dummy objects, making sure the SEOing elements are published into the module. Intersections and collisions (wall-wall, beam-beam, wall-slab, wall-column, slab-beam, etc.) between module and local, or elements of different modules, will always be fine; drafting needs to be clean, and sloppy drafting (in the host file, in the module, or in the module placement) will immediately result in lost junctions when any element ends up 1/10000000000th of an inch off. For this reason it makes sense to keep a 'project geometry' layer, and showing it (even showing it only) for placing the modules and moving them around, and for troubleshooting drafting errors.]

[Lingwisyer]

What do you mean by a "project geometry layer"?

[Ignacio Azpiazu]

A layer where you draw the main geometry lines for the project (as you would on a drafting table; this is not the 'structural grid', which will change frequently during the design process, and which can get messed up during drafting/modeling), and which you can always show as a reference for placing new elements or for troubleshooting (a junction is not working: which element is off?) or for mirroring, multiplying, etc. Within the module you have lines or hotspots in that layer too. Showing that layer only on the host file makes it very easy to catch and fix even the tiniest module placement error, and hugely simplifies placing, moving, multiplying modules. The corresponding geometry lines & hotspots in the module creation file in turn help assure the modeler is aware of the building geometry elements he needs to relate to, and simplifies troubleshooting the module model when something doesn't work.
In a multistory building you can create it on a workshop story and publish it as module into all the stories above. You could also have it on a worksheet and trace-reference it from anywhere, but on the model it works better, and you can show it in 'drafting' layer combinations, etc.