Modules within Fantasy Grounds are the packages that hold any data that can be used within the tabletop. The modules only contain data, and do not contain any information on the game system or the user interface. Some common examples of modules are: player's handbook, GM guide, bestiary, setting guide, adventure, map packs, token packs, ...
At a technical level, data modules are a collection of XML, images and tokens to be used within an FG campaign. The XML within the module has no inherent interpretation, so the module needs to specify which ruleset(s) understand how to use the data in the module. Any images referred to by the XML data need to be included. Also, any tokens included are automatically added to the GM's token bag within the campaign.
The easiest way to create a data module for Fantasy Grounds is to export data records using the export interface available in most rulesets (but not all). To learn more about how to access and use the export interface, go to Using the Library and Activating Modules.
If you want more fine-grained control of how modules are built, you will need to edit the underlying XML module data directly. You can use a module export as a starting point for advanced editing.
At the moment, reference manuals and reference text entries are the only record types that require direct XML editing. If you are interested in directly editing your XML or making a tool to build XML for you, then please review the Managing Campaign Data topic.
For consistency in the ruleset Library interface, the module category should be one of the following:
Core (original publisher core rulebooks only)
Here are some best practices for building FG modules:
If you are using the export interface to create your modules, we recommend that you create a separate campaign for each module you want to create. This allows you to apply updates to the data and re-export an updated module more easily without having to worry about the module data being mixed with data for a player group.
Data for rulebooks should be read only, while data for adventures should be editable. This allows people to have the official rules always available with errata updates, but allows GMs to customize adventures as needed. Remember, records can always be copied within a campaign to create custom versions.
The one exception is that any included maps should not be read only, so that they can be used with tokens.
If you are building modules using XML editing, and you are not familiar with which data fields are required for a given record type, try creating a new campaign, creating a new record of that type, and looking at the db.xml file within the campaign. You will be able to see specifically which fields are created when data is added and edited.