Module - Overview

Overview

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.

Easiest Way

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.

Advanced Editing

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. It is not recommended to edit the XML directly unless absolutely necessary, since all future updates will need to be manual edits.

Categories

For consistency in the ruleset Library interface, the module category should be one of the following:

  • Adventure

  • Core (original publisher core rulebooks only)

  • Map Pack

  • Setting

  • Supplement

  • Token Pack

Best Practices

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.