Upgrading from 5.x

Most of 6.0.0 is additive: stage files written for 5.x load unchanged, and legacy spellings are still read. Two things do change, and one of them changes the meaning of files you already have.

The settings files moved

Before 6.0.0 the settings lived in config/historystages-client.toml and config/historystages-common.toml, split by who owned the value rather than by what it does. They are now config/historystages/settings/visual.toml and gameplay.toml, split by subject. → Config Files

Nothing needs re-entering. On the first launch of 6.0.0 both old files are read and every setting is carried into its new home. The old files are renamed to historystages-client.toml.migrated and historystages-common.toml.migrated and left in place, so the originals are still there if anything looks wrong.

The migration writes a summary line to the log, and the config editor shows a one-off notice the first time it is opened afterwards.

Two settings were removed rather than moved, because nothing in the mod ever read them: lockScrollWhileResearching and showDependencyScreenInPedestal.

The carry-over is not permanent

It is kept until 6.3. A pack skipping straight from 5.x to a later version than that will have to set its options again.

trade is a new action, and it applies to old files

unlock_actions stores the actions that stay free, so an action that did not exist before is locked in every file written earlier. An entry somebody narrowed to ["use"] in 5.x gates trading as well from 6.0 onwards.

That is the intended reading — a narrowed entry means "only this" — and there is deliberately no migration for it. But it is worth a pass over narrowed entries before shipping an update.

Two smaller consequences:

• The result slot of a trade window is judged by trade rather than by pickup. An entry that allowed pickup in order to allow trading has to say trade instead.
• A stage made entirely of narrowed item entries now fits about 544 of them in one network payload rather than 581.

Recipe locks in individual stages are kept now

Before 6.0, a recipes entry written into an individual stage was stripped out at load time. It is now kept and gated at the stations that know who is standing at them — crafting table, the player's 2×2 grid, stonecutter, smithing table.

So an individual stage that carried recipe entries which previously did nothing will start doing something after the update. → Recipes

A spawn lock no longer implies an attack lock

Until 6.0.0, gating an entity's spawning also stopped players hitting it. That coupling is gone. A stage that relied on it now leaves the creature attackable — list it in attacklock as well. → Entities & Spawns

Locked recipes are hidden from the vanilla recipe book

They used to stay visible and simply refuse to craft. hideLockedRecipesInBook is on by default; turning it off restores the old behaviour. → visual.toml

Scripting has a proper API now

The old ForgeEvents.onEvent form with the event class name as a string still fires, so existing scripts keep working — but the class moved in 6.0.0, from net.bananemdnsa.historystages.events.StageEvent to net.bananemdnsa.historystages.api.stage.StageEvent. A script carrying the old string needs the new one, and nothing will tell you it does not match.

HistoryStagesEvents cannot go wrong that way, and reading and changing stage state is possible from a script for the first time. → Scripting

Four commands are gone

/history global info, /history global list, /history individual info and /history individual list were removed. They printed a text dump of a stage definition that the editor shows better. A script or a quest reward still calling one hits a syntax error.

The two temporary-stage info commands stay — they show runtime state nothing else can. → Commands

What 6.0 added

Not a changelog — that lives with the release. This is the short list of things that did not exist in 5.x, so you know what is now worth reading:

Fluids	Gate the fluid, not the bucket.
Merchant Trades	Single offers, professions and merchant levels.
Zones	Areas drawn out of shapes, with a barrier and an overlay. Beta.
Spawn rules	A spawn entry carries a phase, eight conditions and extra biomes.
Scripting	KubeJS and CraftTweaker can read and change stage state.
Addon API	Other mods can register their own locks, requirements and editor tabs.
Recipes	Per-player recipe locks at the stations that know who is standing there.
Dependencies	Item-tag deposits, and requirements on the researcher's own individual stages.
Stage Modes	Triggers that unlock a stage from player and world state.

One thing to expect in an old world: stages unlocked before 6.0.0 have no recorded unlock time, and the Stage Graph background uses that timestamp. Until something unlocks again, the deepest stage in the tree decides the background once. → Stage Graph

Things that did not change

• Stage file format — everything from 5.x loads.
• Stage ids and unlock records.
• The legacy lock_actions, flat structures arrays, and unlock_dimensions spellings are all still read.

See also

• Versions & Platforms — which mod version runs on which loader, and which wiki version documents it.