Module or Hotlinked file, which is best?

[Nervynerv]

Currently working alongside other architects on a file that consists of one Massing plan, I've integrated other buildings as Hotlinked files to improve collaboration, not sure if saving files as modules beats directly including a file as a hotlink in terms of management and performance.

Let me know if you have an answer or further resources on module optimization.

Many thanks.

Operating system used: Windows 11

[Nervynerv]

Linking this which provides some insight:

https://community.graphisoft.com/t5/Project-data-BIM/Hotlink-manager-pln-or-mod-Is-there-a-differenc... 

[Barry Kelly]

Yes I like Djordje's post there.

For small 'parts' (rooms) I use MODS.

For full buildings I use PLN as you can document each building on its own but link all of the layouts in the master file if you want to.

Just be sure with a PLN that you don't leave 'rubbish' (text and elements) around your model as these will show up in the hotlink.

Barry.

[Gordana Radonic]

I would advice to start with linking directly .pln or Teamwork file, and if you experience any performance issue you can always change hotlink source and introduce an extra step of saving a .mod file. 
I've been seeing complex and large files working perfectly fine with hotlinking teamwork projects.
We've tried to document behaviors and best practices of working with hotlinks in the Hotlink Management workflow guide. With your active subscription/SSA you can download this material for free: https://learn.graphisoft.com/visitor_catalog_class/show/34423. 
We've also made a shorter summary in this article: https://community.graphisoft.com/t5/Project-data-BIM/Hotlinked-Modules/ta-p/303819.
These materials might come useful.

Kind regards, Gordana

[Ignacio Azpiazu]

I don't like linking PLNs/TW files at all, and very much like publishing story modules (with their specific layer combination: such as “Bldg-to-Site MOD” layer combination) into module folders (“Bldg-to-Site MODs” or “Bldg MODs” or “Bldg3 MODs”), and placing them on the host file from that folder because that way

- one has full control of when the transferred information needs to be updated (it does not become “outdated” with every save in the source file, but only when one publishes these mods from the source file) (in this respect similar to good old PMKs)

- if not part of the “Bldg-to-Site MOD” (or “Unit-to-Bldg MOD”, etc.) layer combination, the same layer can contain different information in the unit, building, site files, for producing building-level drawings from the Bldg file, unit-level drawings from the Unit file, site-level drawings from the Site file, without having to multiply layers; good for annotation, dimension, auxiliary such as SEO operator layers, etc., and sometimes even model layers (like: some building shell elements that reside in the building file, but you still want to show some content for in the units file in order to produce the unit-level drawings);

- more rarely used, but still nice (again similar to PMKs): you get folders with solid packages of data for the modules, which you can replace and redirect at any time, for backup, project variations, changes of mind, whatever; or you can have several “source” files with project variations publishing to a module folder, and replacing each other in the “blgd-to-site mods” folder with links still working, as long as you keep naming and locations consistent. 

[danielk]

Yeah, I also just link the PLN/TW file by default, especially for hotlink sources on negative stories or files dedicated to creating modules. But in a lot of cases I end up in a situation where in the source PLN there are a lot of references and other elements that I don't want to transfer, so I end up publishing mods, because those can be limited to the visible elements. Also, like mentioned above, you have more of a "version control" with published mod files.

[Erwin Edel]

Our workflow has a module 'workspace' off to the side of the main model. We 'pin' these elements on a workspace renovation filter to hide them when not needed. If we want to change a module, we can use trace and reference to see it in relation to the rest of the model. Unpin the elements, make changes, use marquee tool to select the elements and save and overwrite the module file. We don't have to manage attributes over multiple files.

The pinning and unpinning gets tedious, but opening a seperate AC session tends to take longer.

In place editing that is fool proof (breaking and saving again can lead to problems if you don't save everything back that should've been there) would be preferable, but for us this is the least worst solution.