Foundry VTT module.json for Token Packs

What module.json actually does

module.json is the manifest Foundry reads to identify a module. It can describe an id, title, version, compatibility, authors, and other package metadata. For a system-agnostic media module, its job is to register the package cleanly while the token files remain reusable assets.

The manifest should not claim a game system dependency when the archive only contains media. Actor document schemas differ between systems, so a generic token pack should not ship fabricated Actor JSON or compendiums that only work in one ruleset.

{
  "id": "example-token-pack",
  "title": "Example Token Pack",
  "version": "1.0.0",
  "compatibility": {
    "minimum": "13",
    "verified": "14"
  }
}

Use a folder structure people can inspect

Folosa packages transparent animations under assets/tokens and static fallbacks under assets/static, alongside module metadata and human-readable notes. The exact names matter less than consistency between the archive, manifest, README, and import instructions.

folosa-token-pack/
  module.json
  README.md
  LICENSE.md
  NOTICE.md
  assets/
    tokens/
      character.webm
    static/
      character.webp

Keep filenames portable: use predictable ASCII names, avoid accidental duplicates, and make animated and static variants easy to pair.

Separate media delivery from Actor creation

A module can make assets available without creating Actors. Manual users can place the module under the Foundry user data modules directory, enable it, and assign the WebM path to a Prototype Token. This stays independent of D&D, Pathfinder, or another game system.

Folosa Bridge handles the other path. After a task completes, it verifies the compatible WebM and PNG assets and creates an Actor using document types available in the active system. This runtime creation is more reliable than placing one guessed Actor schema in every downloaded media module.

Match the manifest to the archive

Validate the ZIP by extracting it into a clean temporary directory, parsing module.json as JSON, and checking every documented path. A ZIP that downloads successfully can still be unusable if its top-level directory or paths are wrong.

Install manually or use Bridge deliberately

For manual installation, extract the package so its module folder sits directly inside Foundry's user data modules directory, restart or refresh Foundry as required, enable the module, and follow the included import notes. Keep the original ZIP as a recovery copy.

Bridge is preferable when a GM wants the website account, credits, task history, generation, verification, and Actor import connected. It does not make the system-agnostic ZIP obsolete; the archive remains useful for manual handoff and long-term storage.

FAQ

Does module.json contain the animated token itself?

No. It describes the module. The WebM and static images are separate files referenced or documented by the package.

Should a generic token pack include Actor compendiums?

Only if it deliberately supports a specific game system and validates that system's schema. A system-agnostic media module should avoid invented Actor data.

Can Folosa Bridge use an older website task?

Compatible completed website tasks remain available for deliberate import, while newly created Bridge tasks can auto-import after verification.