Datapack Basics

A guide to setting up your workspace for Cold Sweat's data system and some important data structures

Cold Sweat has several data systems in place that allow developers or modpack creators more granular control over the mod's config settings. These systems provide advanced functionality that is not accessible through the traditional TOML files.

Workspace Setup

Data files for Cold Sweat are stored in data/<yourmod>/cold_sweat/* where "yourmod" is the ID of your mod. If you are making a traditional datapack, this can be anything.

So far, there are 4 categories of data: item, block, world, and entity. Each of these are a dedicated folder within the datapack directory. These directories support using sub-directories for organization.

Data-driven JSON configs can also be put in the mod's config folder in the game directory: config/coldsweat/data/*. These allow users to use the more advanced JSON system without having to make a datapack.

Notes for 1.16:

Mods for this version must define Cold Sweat data in /data/cold_sweat/configs/*.

World datapacks (in the datapacks folder in world files) are not currently supported, but users can define custom settings in the config/coldsweat/data folder as in other versions.

Notes & Important Constructs

This section contains some miscellaneous information about various aspects of Cold Sweat's config system. Interacting with most of these features is optional.

Required Mods

All JSON configs in Cold Sweat have a "required mods" field that allows for configs to be conditionally loaded depending on what mods are present in the current instance. If any of the required mods aren't met, the config is fully prevented from being parsed, at the first step of the loading process.

This can be useful if the config contains IDs for items, blocks, etc. that belong to a particular mod that might not be present.

If the JSON contains mod-specific data and the mod(s) are not added to required_mods, Minecraft will attempt to parse the file anyway, and the missing data will likely cause Minecraft's data loading process to fail entirely.

The format for required mods is very simple:

{
  "required_mods": [
    "toughasnails",
    "create",
    "etc"
  ]
}

Required mods can also use a negatable list, allowing conditions to be inverted, meaning the config will only load if a mod is not present:

{
  "required_mods": {
    "require": [
      "create",
      "thirst"
    ],
    // If Tough as Nails is present, this config will not be loaded
    "exclude": [
      "toughasnails"
    ]
  }
}

Negatable List

A negatable list is a collection of requirements and exclusions that can be used in place of most conditional parameters in Cold Sweat. Using them, it is possible to perform multiple checks at once, or utilize exclusions to define conditions in which the check should fail.

Fields that support negatable lists will usually be labeled as such, but it is safe to assume that any "requirement" (item, entity, block, NBT, etc.) is probably negatable.

Minimal example:

{
  "require": [
    // A list of checks that must pass for this requirement to succeed
  ],
  "exclude": [
    // A list of checks that FAIL this requirement if they pass
  ]
}

For example, here is a negatable list of entity requirements:

{
  "entity": {
    // -- Requirements --
    "require": [
      // requirement 1: must be on fire and have some NBT data
      {
        "flags": {
          "on_fire": true
        },
        "nbt": {
          "SomeBooleanTag": 1
        }
      },
      // requirement 2: must have regeneration 2
      {
        "effects": {
          "minecraft:regeneration": {
            "amplifier": 1
          }
        }
      }
    ],
    // -- Exclusions --
    "exclude": [
      {
        // exclusion: can't be wearing an iron helmet
        "equipment": {
          "head": {
            "items": [
              "minecraft:iron_helmet"
            ]
          }
        }
      }
    ]
  }
}

Optional Parameters

By default, a negatable list of requirements will succeed if:

• At least one requirement passes

• None of the exclusions pass

However, it is possible to change this behavior using two optional parameters:

• require_all ALL requirements must pass for the list to succeed. If one requirement does not pass, the entire list will fail and exclusions will be skipped.

• exclude_all ALL exclusions must pass for the list to fail. If one exclusion does not pass, the rest of the exclusions will be ignored.

{
  "requirements": [], // List of requirements
  "require_all": true,
  "exclusions": [], // List of exclusions
  "exclude_all": true
  // Both of these parameters are "false" by default
}

Default Configs

The file names of some of Cold Sweat's default JSON configs start with the word "default". This makes them have the lowest possible priority in the config loading process, so other configs can override them. For example, the default temp region file uses this so that user-defined temp regions will always have priority.

Prefixing your own configs with "default" will have the same effect, so it's typically not advisable to do this unless that's your intention. Note that many configs support stacking multiple entries, such as those for insulation. For them, this mechanic does not apply.