Data Driven Fires

What are they

Data Driven Fires (DDFires) are Fire objects registered via a data pack rather than a mod. Note that the Soul Fire'd mod must be installed for DDFires to function.
DDFires offer a more user-friendly, faster, and easier way to register a Fire from another mod by using a data pack rather than requiring an extra mod.
This method is beneficial because data packs can be easily added to any world (new or existing) and are synchronized across all players by simply reloading the data pack or joining the world.
However, DDFires come with limitations: they can only register Fires from other mods and cannot include custom enchantments or damage sources.

Note that, since Minecraft 1.21, custom enchantments can be registered via data packs.
For custom Fire enchantments, refer to the dedicated wiki page.

Data pack structure

For a comprehensive guide on creating a data pack, refer to this guide.
Specifically for a DDFires data pack, it must be located in the datapacks/ folder of the world and must have the following structure:

datapacks >
  your_data_pack_name >
    pack.mcmeta
    data >
      soul_fire_d >
        fires >
          JSON files...

For details about the pack.mcmeta file, check out this section of the data pack creation guide.
Ensure you replace your_data_pack_name with the actual name of your data pack, keeping all other names unchanged.

JSON Files

The JSON files are the core content of a DDFires data pack. Each JSON file can register Fires for only one mod.
The structure of a JSON file is as follows:

{
  "mod": "mod_id",
  "fires": [
    // List of Fires of the "mod_id" mod to register
  ]
}

As mentioned, a DDFires data pack can only register Fires from another mod.
Note that Fires registered via mods take priority over DDFires.

DDFires

A single DDFire is represented by a JSON object, structured as follows:

{
  // The only required field - must match the fire's name within the mod's code
  "fire": "fire_id",
  // Float, defaults to 1.0
  "damage": 1.0,
  // Boolean, defaults to false
  "invertHealAndHarm": false,
  // String or null, must be a valid ResourceLocation, defaults to "mod_id:fire_id_fire"
  "source": null,
  // String or null, must be a valid ResourceLocation, defaults to "mod_id:fire_id_campfire"
  "campfire": null
}

For a detailed description of these fields, see the Fire Properties and Fire Components sections of this wiki.

Here are examples to register Cryptic Fire and Boric Fire from BYG:

{
  "fire": "cryptic",
  "damage": 3.5
  // Source and campfire take their default values: "byg:cryptic_fire" and "byg:cryptic_campfire"
}

{
  "fire": "boric",
  "damage": 3.5
  // Source and campfire take their default values: "byg:boric_fire" and "byg:boric_campfire"
}

The complete JSON file to register both BYG fires would look like this:

{
  "mod": "byg",
  "fires": [
    {
      "fire": "cryptic",
      "damage": 3.5
    },
    {
      "fire": "boric",
      "damage": 3.5
    }
  ]
}