eechelonsapi-1.20.1-1.1.0.jar
Curse Maven Snippet
What's new
Changelog for Enemy Echelons API 1.20.1
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.
[1.1.0] - 2026-10-29
Added
- Echelon configs, difficulty-name configs and exclusions can be loaded from datapacks (including a mod's own jar), alongside the existing TOML configs. They are re-read on
/reload.data/<namespace>/echelons/<name>.json- one echelon config. The id is the file's resource location, ex.mymod:deep.data/<namespace>/difficulty_names/<name>.json- one difficulty-name config.data/<namespace>/echelons/exclusions/<name>.json-{ "mods": [...], "mobs": [...] }. Every echelon config in the global registry (TOML and datapack) treats these as blacklisted, and an exclusion wins over every whitelist. Excluded mobs are left untouched (difficulty unset), so a mod's own custom registry can still apply to them.
- Keys are the snake_case forms of the TOML keys, plus an optional
load_order(default 99). - Datapack files are strict: an unknown key or a malformed value is logged as an error naming the file, and that file is skipped.
- With datapack configs present, the registry is rebuilt from the TOML configs plus the datapack configs, sorted by (load_order, id). TOML configs are never removed by a reload.
- Mobs that have already spawned keep their difficulty; a reload only affects new spawns.
replacenow works: a config withreplace = truetakes the place (and precedence) of every earlier config with the same id, TOML or datapack. Without it, configs with the same id are all kept, as before. This lets a datapack replace a TOML config by id, and a TOML file re-registered withoutclear()replaces its old copy instead of shadowing the change./eechelons dump(permission level 2) lists the global echelon configs in order of precedence with their source (toml or data), the configs left out (ex. replaced), the exclusions and the difficulty names, in chat and in the log.
Fixed
- Finding the config for a mob that isn't in any mob/mod whitelist no longer stops at the first config whose
modWhitelistdoesn't include the mob's mod. That config is skipped and the search moves on to the next one, so a whitelisting config no longer hides a later config or the catch-all. - A config with only a
mobWhitelistnow applies to those mobs only. Before, if the search reached it first, it was picked for every other mob too. - Blacklists behave as before: a mob blacklisted by the config that whitelists its mod still gets no modifications.
- The flying speed modifier was added under the movement speed modifier's UUID, so removing the flying speed modifier never found it. The values applied are unchanged.
- A mob wildcard, ex.
"minecraft:*", in a difficulty-name config's mob lists crashed while loading the config. It now moves to the matching mod list, as it does for echelon configs. An invalid mob id is skipped with a warning. DifficultyNameRegistryEntry.registerDifficultyName()threw a NullPointerException on an entry that had no names yet.- Rebuilding the echelon or difficulty-name registry (a reload, or a re-registration while datapack configs are loaded) no longer leaves it briefly empty for lookups on other threads. The new indexes are built off to the side and swapped in at once.
Changed
- None of the existing public API changed. Without datapack configs, the registries behave as in 1.0.1, apart from the search fix above. With the example
echelons_difficulty_config.toml, every lookup gives the same result as in 1.0.1.
[1.0.1] - 2025-11-20
Changed
- Fixed update.json not being parseable.
[1.0.0] - 2025-06-27
Initial Release.
All Relations
- All Relations
- Embedded Library
- Optional Dependency
- Required Dependency
- Tool
- Incompatible
- Include

