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.

[Christophe Fortineau]

Try to apply the "SOE operations" and "roof wall connection" preferably only in the master file

[Lingwisyer]

Out of 6 variations, this is the only one that has this issue...

While workable, applying a SOE to a hotlink requires setting the entire hotlink as a target which can sometimes produce undesirable results. In this case though, the duplication of the wall is causing other issues with wall connections unrelated to the SOE.

Applying a roof-wall connection in a host would not work due to elements not being editable(?)



Ling.

[Ignacio Azpiazu]

How is the duplicate getting generated? If it is an element from the story below getting saved or published into the module for the story above or the other way around (thus turning up in both modules) uncheck 'include elements from other stories shown' or something like that when publishing. The cloned element getting saved into 'the other' module would not be getting SEOed, and fortunately that would be warning you here of the duplicate you might not notice otherwise.

[Lingwisyer]

The duplicate wall appears to be that of the wall being SOE'd. Single story content module, story to story offset.



Ling.

[Ignacio Azpiazu]

Lingwisyer wrote:
The duplicate wall appears to be that of the wall being SOE'd. Single story content module, story to story offset.

The duplicate will not generate by itself. It can be duplicated already on the source file, perhaps with different elevation links to story (one unlinked, the other linked, overlapping in space), and you are not seeing it there, but it suddenly becomes visible when the module gets placed somewhere; or one of them is in a hidden layer but getting published nevertheless as part of a nested module; in these cases both walls are in the same module. Or it is being generated when a single element gets published twice into two different modules (because 'include elements in other stories showing in this one' is checked), and the one getting published into 'the other' module loses the SEO in the process (which is what I would suspect); in this case each wall is in a different module. (And we are assuming no wall got accidentally copy-pasted/exploded from the module into the host file.)

[Lingwisyer]

Site Model - Building Model - Balcony Module

The walls in the balcony module are not linked to a top story. Layer combinations are the same between the building model and site model. Other building models that use a modified balcony module, which is the same content, just duplicated and offset, do not have this issue.

single element gets published twice into two different modules

Only 1 module file is being used.

loses the SEO in the process

I did think this might have been what has happened, but only 2 of the 3 SOE operations applied to the wall are lost. They are all applied in the building model. Wall-Slab and Wall-Beam has been lost, but Wall-Wall has been retained.



Ling.

[Ignacio Azpiazu]

Lingwisyer wrote:
only 2 of the 3 SOE operations applied to the wall are lost. They are all applied in the building model. Wall-Slab and Wall-Beam has been lost, but Wall-Wall has been retained.

If you mean there are SEOs created in the host file between local and module elements, I think that is a bad idea. Any revision/redirection in the module, or replacement in the elements in the module, or in the local elements interacting with the modules, will kill them. In the rare situations where a SEO between a module element and some external element is absolutely needed I create a dummy SEO element on the module-creation file, and make sure the SEO layer is part of the module export layer combination. It is a duplicate, and manual work, but bulletproof, idiotproof, and easily traceable-debuggable.

[Barry Kelly]

I am not quite following exactly what is happening here but is it a case of Priority Based Connections rather than SEO?
PBC will take place first and then the SEO will apply.

Are the material properties (strengths) correct in your module files but different in the host file?

Barry.

[Lingwisyer]

PBC will take place first and then the SEO will apply.

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

I create a dummy SEO element on the module-creation file

How does that work? Objects within a hotlink are "uneditable" and hence cannot be used as operators...




Ling.