Wishes
Post your wishes about Graphisoft products: Archicad, BIMx, BIMcloud, and DDScad.

Unified Project File Type; including PLN, PLA & PLP

Anonymous
Not applicable
In keeping with my pattern of BIG ideas I have a new suggestion.

I would like to see the unification of the PLN, PLP & PLA file types.

This is really a shorthand way of saying that I would like to see the consolidation of opening/signing-in to a project into a single standard process and a related improvement in the handling of libraries.

First; the combination of solo with shared projects.

A single procedure to open/sign into a project offers several advantages:

1. It is only necessary to teach/explain one proceedure for opening and saving files. I presently have to explain (and write standards for) two different ways to access a project depending on whether it is shared or not. It is not always easy for people to understand the distinctions. Just today I had to explain that closing the file and quiting ArchiCAD doesn't mean one is signed out of the project. I know this is a newbie kind of issue, but any office of more than few people (and some withe less) will always have some relatively new users around.

2. People become accustomed to a single standard way of working, increasing efficiency in work habits and reliability in file organization and maintenance.

3. Administrative controls can be set up as a standard practice so that whether someone is working solo or on a shared project the same protections are available to prevent casual changes in layering, pen or other office standards. (Auto-login could be set

4. Multiple backups and local drafts become a standard operating procedure on all projects, shared or not.

5. Open/sign-in can be kept simple by offering options to sign into part of the project (as in TeamWork), open with full access (with privledges to change everything), or open the entire project without access to the attributes etc.

I'm sure there is more but I am getting too tired.


Merging the PLA into the Standard Project File Type

The new unified project file would always contain it's own project library. Now that it is possible to read library parts directly from an archive this seems like the logical next step.

The file would initially load only the lbrary parts contained within itself greatly speeding up the library loading process. Additional (external) libraries are loaded as reference libraries available for browsing in the library manager. One a new part is placed in the project it is automatically added to the internal set.

The program (AC) alerts you if the part from the reference library are different from the installed parts and provides the option to update either way or not at all. This protects against undesired changes from updated or revised library parts.


This is all for now...
I am falling asleep.
21 REPLIES 21
Thomas Holm
Booster
OK Tom, as i said I can't comment much on the Teamwork issue, but I'm pretty sure a 'live' .pla would help our project management a long way.

I'm not saying libraries should go away. As Matthew suggested, there has to be routines for exchanging old library parts. I'd see it as great benefit if those routines were open and optionally manageable, not going on behind the scenes as now.

Since I'm constantly switching between versions, not only generations like AC10 and AC11, but also their respective INT and SWE varieties, and some additional libraries as well, there are so many things that can go wrong - and do go wrong. I also have to cooperate with colleagues that may be a version behind which adds up.

Of course management is needed. But sometimes it adds so much unnecessary overhead that I'd appreciate if I could choose when to manage and when not!
AC4.1-AC26SWE; MacOS13.5.1; MP5,1+MBP16,1
Anonymous
Not applicable
Wow, Tom. I'm kind of surprised. It doesn't seem that you really understand what I am proposing. Properly done the unification would dramatically reduce the time I (and I assume others) have to spend on support and documentation, as well as provide much more robust, consistent and comprehensive management tools.
TomWaltz wrote:
I thought it was a bad idea then and I think it's a bad idea now.

Archives are just that: archives. You're not supposed to edit them.
Archives are files stored to backup media not a file format. The PLA often doesn't even work as an archive by itself since it can't incorporate macros called by parameter strings.
PLP files make it readily obvious that a file is shared. No one can try to open with any other way than signing in.
There are certainly simple ways to indicate that a file is shared without requiring a different file format.
It makes no more sense than making MOD, GSM, and BPN files all the same as well.
This is a silly argument, but thanks for the strawman. MODs are (effectively) assemblies - at least as good as we've got for now. GSM are (generally) components. Their current form and function could not be consolidated in any sensible way (unless perhaps you have some suggestions that haven't occurred to me). Perhaps in some future grand unification all the files become some form of assembly, superassembly, or subassembly each forming components of those above them in the continuum from a screw to a city, but I don't see any near term use for this except perhaps as material for a PhD thesis.

The BPN on the other hand could quite easily be eliminated in favor of the present Teamwork function of maintaining a folder of recently saved project files. Why should solo projects be limited to only the last saved version as a backup?
Library management requires that: MANAGEMENT.

Old parts may not work on new versions. Continuing to load them forever is just asking for problems. At some point, you will have to revise objects for current usage.
Old parts generally do work in newer versions. (I often grab stuff from my old libraries that still do the same useful stuff they did ten years ago.) They just lack the new features. In any case what I propose does not in any way prevent updating library parts to newer versions. In fact it facilitates it with better MANAGEMENT tools.
This entire idea sounds like one giant workaround. Instead of fixing any problems it just makes do with the ones we have.
I don't see you offering any better proposals. I believe that this does eliminate many of the problems we already have while also opening opportunities for improvements and features which would be difficult to implement otherwise.

"One giant workaround" sounds like an oxymoron to me. Workarounds are all the little bubble gum and bailing wire solutions that slowly accumulate into an inconsistent and chaotic mess that is embarrassing to explain to new users. I'll take one giant workaround in place of myriad little ones any day.

I would love to go into great detail about just how this would all work, but convincing you is not that high on my list of daily priorities. Unless Graphisoft decides that my ideas are worth more than they are presently paying for them ( ) I will have to stick mostly to the stuff that pays my bills and leave this stuff to my odd idle moments.

BTW, Tom, I take it you haven't voted on this one yet
Anonymous
Not applicable
Great idea, Mathew! Esesential!
Jere
Expert
I work in a small office with only three licenses so I'll admit I don't understand the impact on library management. I agree with Tom's view on the pla files; that part doesn't sounds like a good idea. If every project had localized libraries, what happens when ArchiCAD's main library is updated? Would there not be many duplicates of library files stored in different project locations?

On the flip side, I really like the idea of streamlining the opening/saving. Rather than have a separte sign-in procedure, it would be nice to just 'open' a file, shared or not.
ArchiCAD 26-5002; Windows 11; Intel i7-10700KF; 16GB RAM, GeForce GTX 1660
Anonymous
Not applicable
Jere wrote:
If every project had localized libraries, what happens when ArchiCAD's main library is updated? Would there not be many duplicates of library files stored in different project locations?
It's true there would be duplication of the parts stored within the projects and their counterparts in the reference/source libraries. This is why my proposal would require good library management tools. I envision something akin to file sync software (Chronosync is a good example on the Mac, I forget the names of the ones I've used with Windows). This would provide a list of all the parts in use in the project and their counterparts in the reference libraries, show which (if any) have changed, and provide the means to update one the other or neither.

There is already a duplication of parts in the current PLA system but there is no convenient way to manage these duplicates. I have also seen many problems with managing libraries (people are not always careful how they store and link their libraries and often have multiple copies scattered about their servers and workstations). This system would go a long way to help correct both of these problems.

Imagine a common scenario: A project started in one version to be converted to the new release.

Currently the typical practice is to unload the old library, load the new one and hope that all the parts you used in the project have counterparts in the new one, and that the parameter settings will all work properly with the revised ones (most parts in the library don't change significantly from one version to the next). Missing parts can generally be fixed by loading the subset library that is typically released with the new version.

The Unified Format with embedded parts and the library manager would allow you to see explicitly which parts are missing from the new library, which ones are updated and to chose individually or collectively what to do about it. In most cases it would probably be just a click to update the project parts from the Reference Library. I would also expect an option to lock the reference libraries so that they wouldn't be updated without proper authority.

To develop a proper spec for this would require studying a wide variety possible workflows and, obviously, more time than I can afford to spend on it, but I don't see any serious obstacles to making it work well in all scenarios.
Thomas Holm
Booster
I think this post is quite to the point. We all struggle with migration issues when upgrading. This should be made much simpler.
AC4.1-AC26SWE; MacOS13.5.1; MP5,1+MBP16,1
March_ Bruce
Booster
I have suggested to the powers that be that with all the talk of intelligent objects that maybe we now have the resources to create a single cumulative object library, with parts that are intelligent to 'respond' with the appropriate nested code to whatever archicad version is loading them...

Legacy file management & efficiency are often touted in archicad however the 'inconvenient truth' in my own humble world is that none of this really works very well & the overhead of interoperability undermines much if all of the reuse of information - the worksheet feature acknowledges the inability of BIM to deliver contract documentation & the lack of PM support in v10 would seem to illustrate where the mindset of the company is at...
Rob
Graphisoft
Graphisoft
I have suggested to the powers that be that with all the talk of intelligent objects that maybe we now have the resources to create a single cumulative object library, with parts that are intelligent to 'respond' with the appropriate nested code to whatever archicad version is loading them...
Bruce,
I agree but this would require much more powerful GDL code base which I think is unnecessary. The overall goal should actually be moving from coding as such to more graphic tools. Secondly it would be a huge overhead to program an internal interpreter that would allow for 'degrading' a code to earlier versions. In fact I think it would not be possible at all in some cases (SEO, movable hotspots etc)
::rk
March_ Bruce
Booster
So does anyone know ArchiCAD 12 subset library options if one needs to migrate a project?

There are no notes posted as to what works that I could find & no notice from within v12 'Check for Updates...' or other obvious links to either information or downloads:

http://tr.graphisoftus.com/welcome-LibArchives.asp
http://www.graphisoft.com/support/archicad/downloads/

I find 'abandoned' objects (such basics as a dining room table, quarter sphere sconce, etc) from 6 prior versions of ArchiCAD (to v6.5) are regularly essential.

Thanks!

ps. I agree with Matthew that improving the basics like finding a way to simplify the library mess would be for me one of the biggest improvements, along with harmonizing & completing all the features that seem arguably still 'in progress' - why the search option was removed from the library manager* or we still need to use SEOs to modify a stair-in-slab opening edge material (two of many) is beyond me...

*http://www.archicadwiki.com/GUID#GUIDinArchiCAD12
owen
Newcomer
Rob wrote:
I agree but this would require much more powerful GDL code base which I think is unnecessary. The overall goal should actually be moving from coding as such to more graphic tools.


Yes a good graphical editor really is a must - I don't know why Graphisoft still haven't shown any intention of doing something about it. If done properly it could make ArchiCAD incredibly powerful compared to what it is today for parametric design. ArchiCAD's modeling capabilities need to step up before they get left in the dust, and when they do anything that the AC engine is capable of creating should be accessible via this graphical object editor. Although I agree the goal should be moving to graphical editing, the editor should also provide for working in both 3D and code views - a split view would be ideal, so you can see the effects of working in one mode 'live' in the other. But all this has been done to death and seems to be falling on deaf ears...
Rob wrote:
Secondly it would be a huge overhead to program an internal interpreter that would allow for 'degrading' a code to earlier versions. In fact I think it would not be possible at all in some cases (SEO, movable hotspots etc)
Agree it is not really feasible to include a converter but you should be able to save back to earlier versions if you want to and run the risk of it not working. I have mistakenly edited an object in AC12 several times when running AC11 in parallel - there is no recourse other than your backups. This is completely ridiculous when I know for certain all the code is actually AC10 compliant.

What this new editor should have is some form of code validation check with AC Version options highlighting code that is not compatible with the selected version.
cheers,

Owen Sharp

Design Technology Manager
fjmt | francis-jones morehen thorp

iMac 27" i7 2.93Ghz | 32GB RAM | OS 10.10 | Since AC5