As mentioned before, library packages contain more knowledge than a simple .lcf. For Archicad to read this additional data, we have .info files that define them.
package.info
This is the most essential file for a library package. It contains basic data about the package in XML format.
The format of the package.info file has to be the following:
<?xml version="1.0" encoding="UTF-8"?>
<Package displayName="Name displayed in Archicad" packageID="GUID of package" buildID="00000000-0000-0000-0000-000000000000" version="1" subversion="1" requiredACVersion="28" requiredACBuildNum= "1">
<LCFPath checksum="00000000000000000000000000000000" lcfPath="Filename of lcf.lcf"/>
<Dependencies>
<Dependency displayName="Dependency package name" packageID="GUID of dependency package" minSubVersion="0"/>
</Dependencies>
<LocDataPath>localizationData.info</LocDataPath>
</Package>
Some attributes are self-explanatory, but let us go over them in detail.
Package displayName
This is the name you will see in Archicad.
packageID
This is the unique identifier (GUID) of a package. Different subversions of the same package have the same packageID; however, a different (main)version requires a new packageID as well.
buildID
A unique identifier of the package, generated during build. Different builds of the same package result in different buildIDs.
version
Version numbering of the library package, usually starting with 0 or 1 as the first version. When you increase the version number, you should also generate a new packageID (the package name and version is the user-side equivalent of the packageID).
subversion
Subversion of the library version, usually starting with 0.
requiredACVersion
The minimum version of Archicad required to use the library package is 28 since library packages were introduced in that version. It is increased when the library package uses a new GDL feature that was unavailable in previous Archicad versions (such as a new library command, parameter type, library global, tool, library compatibility setting, etc.).
requiredACBuildNum
The minimum required Archicad build number to open the library package.
checksum
It is currently not used, but it can help identify different states of the .lcf files packed in the library package.
lcfpath
This is the path of the .lcf file packed into the .libpack, created during the build process. Usually, it is the package name with the .lcf extension.
Dependencies
The list of other library package(s) your library package relies on. If any of the library parts in your package uses any macros, subtypes or images from any other library packages, you have to list them here, otherwise it can not be guaranteed that all required packages will be loaded into Archicad. This part can be omitted if you do not have any dependency packages, but make sure you keep the empty tag so that the info file is valid. All dependency packages need to be referenced using three identifiers:
displayName
The name of the dependency package, given to it in its own package.info file. This name is displayed in the Library Loading Report if the dependency is missing.
packageID
The unique identifier (GUID) of a package, given in the dependency package’s own package.info file.
minSubVersion
The minimum subversion of the dependency package, required for the library package. The packageID (which changes for each .libpack version) and the minSubVersion describes a needed exact minimum state of a library package).
LocDataPath
Reference to the localizationData.info file if you have one. Read more on this file below. If you don’t have a localizationData.info file, remove this tag altogether.
localizationData.info
The file referenced in package.info under LocDataPath contains important data about your package so that you can have more than one localization. You can change this during Archicad runtime, see Changing libpack Language of the User Documentation.
This file is only mandatory if you have referenced it in package.info. However, the most important feature of .libpacks is its multi-language aspect, so we recommend using it to get the most out of your library packages.
The localizationData.info file is in XML format and looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<LocalizationData>
<MappingDefinitions>mappingDefinitions.json</MappingDefinitions>
<PathNameTables>
<PathNameTable language="INT" path="Localization/pathNameTableINT.json"/>
</PathNameTables>
<MappingValueTables></MappingValueTables>
<Dictionaries>
<Dictionary language="INT" type="fileName" path="Localization/Dictionaries/fileNamesINT.po"/>
<Dictionary language="INT" type="folderName" path="Localization/Dictionaries/folderNamesINT.po"/>
<Dictionary language="INT" type="symbolStrings" path="Localization/Dictionaries/symbolStringsINT.po"/>
</Dictionaries>
</LocalizationData>
MappingDefinitions
Reference to the mappingDefinitions.json file, created in Creating parammapping.xml and MappingDefinitions.json.
If you have no parammapping.xml files in your objects, you should leave them empty.
PathNameTables
Reference to the pathnametable files of each localization in your libpack. One pathnametable file can be referenced for more languages, but not vice versa. If you have no pathnametable files in your libpack, you should leave this empty.
You can read more about pathnametables, their purpose, and their format in Creating pathNameTable.json.
<PathNameTable language="INT" path="Localization/pathNameTableINT.json"/>
<PathNameTable language="GER" path="Localization/pathNameTableINT.json"/>
<PathNameTable language="SWE" path="Localization/pathNameTableSWE.json"/>
In this example, if the Library Localization Preferences (see in Changing .libpack Language of the User Documentation) is set to have INT or GER as the top priority, the pathNameTableINT.json file will take effect. In contrast, SWE, as the top priority, uses pathNameTableSWE.json instead. If any other loc code is set as the top priority, Archicad moves on to the next loc code until one of the versions listed in the localizationData.info file is found. If none of them is found, the first value in the localizationData.info’s list takes effect.
MappingValueTables
This tag became redundant (and does not work), as MappingValueTables are shipped with template files instead of being part of the library package itself.
Dictionaries
Reference to the dictionary files of each language in your library package. One file can be referenced in more than one language.
You can read more about dictionary files, their types, and format in Creating symbolStrings.po and Creating fileNames.po and folderNames.po.
Matching the applied dictionaries to the selected language version works the same way as for PathNameTables.
If you have no dictionary files in your libpack, you can omit this part.