Archicad 28 introduces a new library format: library package, which can be used in a more flexible way than the previously used library container files (.lcf). This article shows you how to create a new library package from scratch or upgrade your existing libraries.

This workflow relies on the LP_XMLConverter.exe provided by Archicad (or used from the Library Developer Toolkit) and optionally the newest version of the GDL extension for VSCode.

Converting to hsf

The first step is to have the library parts themselves. This workflow doesn’t describe creating those, but we provide an example library for trying these steps if needed: Library Package Example

Your goal is to have your library in hsf (HSF source format) so you can run several commands on it to generate the necessary additional files with the LP_XMLConverter. This document explains how the library package technology has impacted library formats: Library File Format Changes for Library Packages

This article describes how to convert from any starting library format to hsf. If you already have your library in hsf, continue to the next step.

Upgrading .lcf files to .libpack

Library packages have many aspects that differentiate them from a .lcf. Most of these are optional, but if none is implemented, it functions the same as a basic .lcf. Read more on these differences here: Using Library Packages of the User Documentation

Editable parameter defaults

Setting Library Part Defaults section of the User Documentation provides an overview of the user-side workflow and a general description of this function, while Creating parammapping.xml and MappingDefinition.json focuses on the development aspect of the process.

Once you have created your MappingDefinitions.json file, you can proceed to the next step. When everything else is finalized, you will need to incorporate these files into the library package (refer to the Packaging the Library section).

Additionally, you must reference MappingDefinitions.json in the localizationData.info file. For further details, please consult Libpack info Files.

It is also necessary to manually include MappingDefinitions.json in the pathNameTable.json files (Note: The filesystem in VSCode’s GDL Add-on cannot add it as it is not part of hsf).

Translation for library part strings

With library packages, you can change the language of your library inside Archicad: Changing .libpack Language section of the User Documentation. For this to work, you have to create dictionaries and include them in your library packages.

Dictionaries are grouped into three categories:

• symbolStrings.po

  • Used for strings inside library parts (the strings you use inside your library parts – script strings, parameter descriptions, and values, library part keywords and descriptions)

• filenames.po

  • Name of each library part

• foldernames.po

  • Name of folders in which library parts are structured inside Archicad

This section handles the creation of symbolStrings.po. Filenames and foldernames require the creation of pathNameTables, so adding them is discussed later (see Translation for folder and library part names).

Creating symbolStrings.po

After you have created your symbolStrings.po files, you can proceed to the next step. When everything else is ready, you will add these later to the library package (see the Packaging the Library section).

You will have to refer to all used symbolStrings.po files in the localizationData.info file. Read more about this in Libpack info Files

Alternate folder tree in the settings dialog

Library Package technology also allows for creating alternate folder structures for library parts (also mentioned in Changing .libpack Language section of the User Documentation). These virtual paths are defined via pathNameTable.json files. Read more about creating and handling these files here: Creating pathNameTable.json

After you have created your pathNameTable.json files, you can proceed to the next step. When everything else is ready, you will add these later to the library package (see the Packaging the Library section).

You will have to refer to all used pathNameTable.json files in the localizationData.info file; read more about this in Libpack info Files

Translation for folder and library part names

As noted, you can also create translations for library part names and folder structures. For this to work, you need the pathNameTable.json file(s); see their creation in the previous section.

Read this article on how to generate fileNames.po and folderNames.po files: Creating fileNames.po and folderNames.po

After you have created your fileNames.po and/or folderNames.po files, you can proceed to the next step. You will add these later to the library package when everything else is ready (see the Packaging the Library section).

You will have to refer to all used fileNames.po and folderNames.po files in the localizationData.info file. Read more about this in Libpack info Files

Package info files

Lastly, you must create package info files(s) based on what you have added to your library package. package.info is always required, and if any functions marked with “optional” were added (most likely they were; otherwise, you could still use a simple .lcf file), localizationData.info is also needed.

See how each of these files is formatted in Libpack info Files.

Packaging the library

It is time to assemble your library package. Follow the instructions in Conversion Between Library Formats to see how to convert your hsf back to .gsm and then .lcf. At that point, you have to add your generated additional files manually (check if all the files are included in the pathNameTable file(s)!) and finally create the library package.

The final product should be a single library package file and, optionally, one or more corresponding Mapping Value Tables (see more in Creating parammapping.xml and MappingDefinition.json).