topic Re: Crapulous .mods within .mods behavior in Project data & BIM

Crapulous .mods within .mods behavior

Ignacio Azpiazu — Fri, 26 May 2023 07:03:44 GMT

I only noticed it recently, not sure if it's because it is a bug in 10 that is not present in 9 or 11, or because I just hadn't noticed.

Let's say you publish envelope or bathroom modules, and place those into unit plans plns which in term get published as modules that get placed into building plns.

Within Hotlink Manager in the building pln you have the option of choosing 'skip nested modules' for each of your unit plans. Problematically enough:
- if you 'skip nested', your nested panels or bathrooms will just not be there; this seems inconsistent to me with the whole module idea in which you are supposed to get only the elements and attributes that get published --give me those walls, regardless of whether they were built in the unit plan file or they got there riding a module;
- if you don't 'skip nested', the whole original nested module information will be there in the building pln, *including the elements in those layers that were not part of the publishing view for the unit plan*; the unit plan module is taking with it 'a hotlink' and not elements, which brings into the unit plan module a lot of elements and attributes in the bathroom module that you specifically left out when creating the unit plan module. Of course you also get all the Hotlink Manager 'file updated but go check nested' warnings etc. that the whole module idea should be getting rid of --I am specifically creating a new file in order to break the direct link between the host and the module creator.

This makes them behave almost like plns. Shouldn't publishing modules give you the elements and not include in the .mod created ad-hoc any 'hotlink' path information of any kind, shouldn't the .mod just ignore where the elements came from in the source file?

Re: Crapulous .mods within .mods behavior

Greg Kmethy — Thu, 24 Apr 2008 12:55:19 GMT

I have not checked it, but knowing ArchiCAD's logic, I don't think it's AC 10 specific. ArchiCAD cannot filter elements when you create a hotlink, only when you save a module. I can easily imagine that when you save the unit module, the hidden layers of the hotlinked bathroom modules are deleted, and they do not make it into the module file. However, when you update the bathroom modules in the unit modules (from the building plan) all the bathroom unit's layers get copied into the unit module. This seems inevitable, as the whole file needs to be opened to refresh the bathroom module - ArchiCAD can not filter out layers when creating/updating the hotlink.

Watch the file size of your unit modules. My bet is that they are small when you first publish them, but after you update them for the first time from the building plan, they grow bigger, as the layers of the bathroom units get -inevitably - copied into them.

Re: Crapulous .mods within .mods behavior

Ignacio Azpiazu — Sun, 27 Apr 2008 21:50:11 GMT

gkmethy wrote:
ArchiCAD cannot filter elements when you create a hotlink, only when you save a module. I can easily imagine that when you save the unit module, the hidden layers of the hotlinked bathroom modules are deleted, and they do not make it into the module file. However, when you update the bathroom modules in the unit modules (from the building plan) all the bathroom unit's layers get copied into the unit module. This seems inevitable, as the whole file needs to be opened to refresh the bathroom module - ArchiCAD can not filter out layers when creating/updating the hotlink.

Thanks for having replied to this. I haven't checked it yet, but the module-file-size-swelling-on-hotlink-update would explain a lot of what had looked as inconsistent behavior to me.

But if I am still confused. Why in a structure of
-building plan .pln
--unit plan .mod (published from unit plans.pln and placed in building plan.pln)
---bathroom .mod (published from bathrooms.pln and placed in unit plans.pln)
---wall panel .mod (published from wall panels.pln and placed in unit plans.pln)
---etc. .mod (you get the idea)
is the 'first-level' building pln having to look at the third-level modules, or be aware at all of whether the elements in the second-level unit plan .mod were generated by say wall elements that were local to the unit plan .pln or placed in there as part of a third-level wall panel .mod? The bldg pln should just don't care: 'ok they told me to place this package of walls-fills-objects-text-etc. that I am reading from file Unit_A1.mod in this story, with this story elevation and this rotation, with this master layer, and here it is; I couldn't care less about how these got into Unit_A1.mod, whether they are local to the pln that generated the module or were hotlinked into it, and if I tried to care I wouldn't be able to tell because Unit_A1 .mod doesn't know either and therefore can't tell me'.

I can sort of try to follow the explanation if we were talking about hotlinked .plns, in which you are keeping live links between three level of active pln files let's say. But these are .mods, saved/published every time as modules with some specific visible layers only. The bunch of elements (walls, slabs, fills) brought in as a reference with the .mod into the building plan should be a self-contained package, a package of elements with no hotlink to lower-level mods (or for that matter, lower-level plns).

It would be nice if the 'nested modules' could be turned on/off during *production* (saving/publishing) of the .mods, perhaps, and that would actually be a nice toggle for daily working purposes too; once created the .mod should not have hotlinks within it. Otherwise, if I followed your explanation correctly, you just lose control over the content of the second-level mods and first level plns, control over the content being the whole purpose of .mods to begin with.

Re: Crapulous .mods within .mods behavior

Ignacio Azpiazu — Mon, 09 Jun 2008 14:12:40 GMT

The crapulous behaviour is gone when trying the same files in 11 (1210). When you open the .mod files they don't contain hotlinks, even when the elements they are made of had been parts of hotlinked mods in the mod publisher file, no matter how many times you update. Which is the way everything is supposed to work.

There may be some mysterious checkbox somewhere that was triggering the weirdness, like some 'Skip Nested Modules' in Hotlink Manager that has some undesired impact on the unrelated publishing, etc.