Archicad Monolithische Migrationsbibliothek (Duplikate)

[SB - ASTOC]

Mit Blick auf die nächsten Jahre und den Laufzeiten von Projekten werden wir vermutlich nicht umhinkommen für ältere Projekte die Archicad Monolitische  Migrationsbibliothek zum Einsatz zu bringen, um ggf. mit der BIMcloud oder Programm-Versionen kompatibel bleiben zu können.

Testweise ausprobiert führt leider dies zu dem Ergebnis, dass zum Teil Texturen aus dem Oberflächenkatalog, UI-Bilder oder andere Sub-Elemente als Duplikate auftauchen, da diese entweder gleichlautend oder identisch mit Namenszusatz "27" sind.

Kurzum, es wäre hilfreich, wenn die Elemente, welche mit den 29er Bibliotheken identisch und dort enthalten sind, nicht in der Migrationsbibliothek implementiert wären. Alternativ wäre ein unmittelbares Löschen von Migrationselementen im Bibliotheken-Manager schon ein unterstützender Schritt, da diese derzeit unveränderbar als *.lcf vorliegen. Die lassen sich zwar über den Download in Ordner konvertieren, jedoch müssen dann manuell lokal gelöscht werden.

... und nun?

@Anja_ASTOC 

@Lukas Oelmueller 

[runxel]

Hallo Stephan, zwar vertrete ich auch die Meinung, dass die gesamte Bibliothekenfrage und wie sie von GS "gelöst" worden ist, ziemlicher Murks ist – und dazu gehört auch der Fehlgriff die alte Bibliothek "Migrationsbibliothek" zu nennen. In gewisser Weise der eigenen Logik folgend allerdings eine fast zwangsläufige Entscheidung. Bislang, also vor der Einführung der sog. Globalen Bibliothek, sind in der Migrationsbibliothek ja immer nur zwei Arten von Ojekten gelandet:

Das waren zum einen sog. temporäre Migrationsobjekte, die sicherstellen dass beim Öffnen alles korrekt übernommen wird, und zum anderen die Objekte, die, aus welchen Gründen auch immer, nicht mehr weitergeführt worden sind, aber die man trotzdem noch in migrierten Projekten weiter verwenden wollte.

Schaut man sich die LCF der anderen, alten Versionen an, sind die auch viel kleiner als die 27er Migrationsbibliothek – diese ist nämlich vollständig; der komplette Inhalt der Bibliothek, wie man sie kennt, ist darin enthalten.

Und es gibt einen weiteren wichtigen Unterschied (aber der ist eher für die GDL-Profis hier spannend): Der Migrationsstatus steht nicht auf "veraltet". Der würde nämlich ein Platzieren der Objekte verunmöglichen.

Insgesamt denke ich jedoch, dass das von dir beschriebene Problem gar keins ist.

Welche Anreize bestehen denn, die alte, sog. monolithische Bibliothek zu verwenden?

Projekte, die in der einer Version vor der 28 gestartet worden sind, und nicht migriert werden sollen müssen natürlich die alten Bibliotheken weiterhin verwenden.

Die alte Regel, dass Objekte immer nur vorwärts, aber niemals rückwärtskompatibel sind, gilt mit der Einführung der globalen Bibliothek jedoch nicht mehr! Das z.B. vor wenigen Tagen hier im Forum angekündigte Bibliotheksupdate kann auch in der 28 verwendet werden.

Die Ausnahme bildet hier die HKLSE-Bib, die war, ist, und bleibt auch in Zukunft immer nur mit der aktuellen Version verbandelt.

Da die neue Bib im .libpack Format nichts weiter als ein Wrapper mit ein paar zusätzlichen JSONs um die bekannten LCF darstellt, ist auch nicht zu befürchten, dass die BIMCloud hier Schluckauf bekommt und sonst wie Probleme bereitet. Archicad kann auch weiterhin im übrigen problemlos mit beidem gleichzeitig gefüttert werden.

Bei mir habe ich meine Büro-Bibliothek als LCF gepackt und lade sie ganz normal dazu – funktioniert wunderbar.

Nebenbei: Wie schon in anderen Threads hier mehrfach erläutert bringt dem Büro auch die Verwendung des .libpack Formats überhaupt keine Vorteile, und es ist auch von GS so nicht vorgesehen.

An der Beschränkung, dass an einem Projekt nicht unterschiedliche Archicad-Versionen arbeiten können, hat sich ja nichts geändert, ich sehe also gar keinen Fall, in dem es nötig wäre, die monolithische und die globale Bib gleichzeitig nebeneinander zu betreiben.

[SB - ASTOC]

Danke für Deinen Input.

Ich sehe dass etwas anders, denn durch die Monolthische Migrationsbibliothek braucht man die (Migrations-) bibliotheken der früheren Versionen nicht mehr in einzelne BIMcloud-Ordner ablegen und mit einer alles abdeckt, dass reduziert den Verwaltungsaufwand. In früheren Migrationsbibliotheken entstanden keine Duplikate mit der jeweils aktuellen Bibliothek, weder Elemente des UIs, Add-ons, Werkzeuge oder Oberflächenkataloge - also es ist ein Problem der fehlenden Bereinigung und der Übersichtlichkeit der Anwender:Innen. Zudem ist es jedem Büro selbst überlassen, ob es langlaufende Projekte aus älteren Versionen in die aktuellste aufgrund der Features konvertieren möchte.

[runxel]

Das Thema hatte ich etwas kurz gefasst, aber die Bezeichnung als "Migrationsbibliothek" ist einfach falsch (aus meiner Sicht; aus GS' Sicht wie beschrieben fast folgerichtig, weil es alles beinhaltet, was nicht fortgeführt ist.... was einfach mal eben alles ist).

Wenn man nun jedoch die monolithische Bibliothek einfach als das sieht, was sie eigentlich darstellt – den eingefroren Zustand vor dem Systemwechsel zu .libpack und die letzte Bib mit Nummer im Namen – dann sieht die Sache anders aus.

Da es überhaupt gar keine echte Migration zwischen ≤27 ↔ danach gibt, ist es auch insofern für mich keine "Migrationsbibliothek" in dem Sinne.

---

@SB - ASTOC  schrieb:

Zudem ist es jedem Büro selbst überlassen, ob es langlaufende Projekte aus älteren Versionen in die aktuellste aufgrund der Features konvertieren möchte.

---

Korrekt, und GS selbst rät davon ab, bei laufenden Projekten zu migrieren und diesen Systemwechsel zu vollziehen. Sie geben auch explizit keinen Support für diese Situation. Damit hat sich ganze Thema ohnehin erledigt.

Der Wechsel zur globalen Bib ist eine Zäsur, man kann nicht zweigleisig fahren. Daher sollte es nicht dazu kommen, dass plötzlich doppelte Elemente auftauchen.

Aber vielleicht verstehe ich von außen Euren spezifischen Use Case nur nicht.