How your game server checks every content row as it loads, what it does with a bad one, and where to see and fix what it found.

When the Server Finds Broken Content

Your game server checks every row of content as it loads it: at start-up, on a full reload, and on every publish that patches a few rows. Most content reaches the server through the editor, which already refuses bad values when you save. But content can also arrive through an import, an older editor version, or a direct database edit — and that content never went through those save checks. The server catches it, and a bad row never stops your world from loading.

Where to see it#

Server log — each problem is written once, as
[ContentCheck] mob_definitions "wolf" loot_table: row 2 drops missing item "pelt" (dropped), followed by one summary line after every load (content load: 3 content problem(s) — 1 skipped, 1 clamped, 1 dropped, 0 kept). A problem that is still there on the next reload is not logged again.
Server status — open your server's /status address. contentProblems shows how many problems were found, split by what the server did and by table. If you send your admin key with the request, it also lists the first 50 problems with their table, id and reason.
Kept items — keptItems on the same /status address counts player items the server could not load and therefore left alone: missingDefinitions (how many deleted or missing items players still hold copies of), waitingForDefinition (how many copies are waiting for their item to come back) and waitingForBagSpace (how many are waiting for a free bag slot). With your admin key it also lists which items. The server log names each missing item once per start. See what happens to items players already own.

How to fix what it finds#

Open the server's /status with your admin key, or read the [ContentCheck] lines in the server log.
For each problem, open the editor named by its table (mob_definitions → Database → Mobs, quest_definitions → Database → Quests, npc_shop_stock → Database → NPC Shops, zone_core_events → the map's event, common_event_definitions → Database → Common Events), and find the row by its id.
Fix the value or link the problem names, then save.
Publish (or let the editor sync). The server reloads, checks again, and the problem disappears from /status.

What the server does with each problem#

What it says	What it means	What you should do
skipped	The whole row was left out: a row with no id, a spawn rule whose monster party (or resource node) no longer exists or has no existing mobs, a shop stock row that sells or asks for a deleted item.	Re-link it to something that exists, or delete it.
clamped	A number was pulled back into range: a loot chance above 1, a max quantity below the min, a stack size of 0, a mob with 0 HP, a negative ability cost or cooldown, a negative spawn count, a respawn under 1 second, an objective count of 0.	Set the value you actually want — the clamp is a safe floor, not a guess at your intent.
dropped	One broken entry inside the row was removed: a loot or yield row for a deleted item, a monster party member whose mob is gone, a quest reward item that no longer exists.	Pick a new item or mob, or remove the entry.
kept	Loaded unchanged, because the game already copes with it — but it will misbehave. A quest objective aimed at a missing mob, item or recipe (it can never complete); an ability applying a deleted status effect (its saved copy is used); a Call Common Event aimed at a common event that doesn't exist (it is skipped when it runs); a field that doesn't match the editor's rules.	Fix it — these are the problems players will actually notice.

Gotchas#

A skipped row stays skipped until you fix it. Deleting a mob that a monster party uses can quietly switch off every spawn rule that uses that party; /status shows exactly which rules went.
Map events are not shape-checked here — only their Call Common Event targets are. They can be very large, and the editor checks them when you save and publish.
Only the first 50 problems are listed, but the counts always cover every problem.
Problems are checked after every reload, so a count that doesn't go down after you publish means the fix didn't reach the server — check that the publish finished.
Project Health finds most of the same broken links before you publish — see Project Health.
There is no feature flag — the checks always run.

When the Server Finds Broken Content

Where to see it#

Server log — each problem is written once, as

[ContentCheck] mob_definitions "wolf" loot_table: row 2 drops missing item "pelt" (dropped), followed by one summary line after every load (content load: 3 content problem(s) — 1 skipped, 1 clamped, 1 dropped, 0 kept). A problem that is still there on the next reload is not logged again.

Server status — open your server's /status address. contentProblems shows how many problems were found, split by what the server did and by table. If you send your admin key with the request, it also lists the first 50 problems with their table, id and reason.

Kept items — keptItems on the same /status address counts player items the server could not load and therefore left alone: missingDefinitions (how many deleted or missing items players still hold copies of), waitingForDefinition (how many copies are waiting for their item to come back) and waitingForBagSpace (how many are waiting for a free bag slot). With your admin key it also lists which items. The server log names each missing item once per start. See what happens to items players already own.

How to fix what it finds#

Open the server's /status with your admin key, or read the [ContentCheck] lines in the server log.

For each problem, open the editor named by its table (mob_definitions → Database → Mobs, quest_definitions → Database → Quests, npc_shop_stock → Database → NPC Shops, zone_core_events → the map's event, common_event_definitions → Database → Common Events), and find the row by its id.

Fix the value or link the problem names, then save.

Publish (or let the editor sync). The server reloads, checks again, and the problem disappears from /status.

What the server does with each problem#

What it says	What it means	What you should do
skipped	The whole row was left out: a row with no id, a spawn rule whose monster party (or resource node) no longer exists or has no existing mobs, a shop stock row that sells or asks for a deleted item.	Re-link it to something that exists, or delete it.
clamped	A number was pulled back into range: a loot chance above 1, a max quantity below the min, a stack size of 0, a mob with 0 HP, a negative ability cost or cooldown, a negative spawn count, a respawn under 1 second, an objective count of 0.	Set the value you actually want — the clamp is a safe floor, not a guess at your intent.
dropped	One broken entry inside the row was removed: a loot or yield row for a deleted item, a monster party member whose mob is gone, a quest reward item that no longer exists.	Pick a new item or mob, or remove the entry.
kept	Loaded unchanged, because the game already copes with it — but it will misbehave. A quest objective aimed at a missing mob, item or recipe (it can never complete); an ability applying a deleted status effect (its saved copy is used); a Call Common Event aimed at a common event that doesn't exist (it is skipped when it runs); a field that doesn't match the editor's rules.	Fix it — these are the problems players will actually notice.

Gotchas#

A skipped row stays skipped until you fix it. Deleting a mob that a monster party uses can quietly switch off every spawn rule that uses that party; /status shows exactly which rules went.

Map events are not shape-checked here — only their Call Common Event targets are. They can be very large, and the editor checks them when you save and publish.

Only the first 50 problems are listed, but the counts always cover every problem.

Problems are checked after every reload, so a count that doesn't go down after you publish means the fix didn't reach the server — check that the publish finished.

Project Health finds most of the same broken links before you publish — see Project Health.

There is no feature flag — the checks always run.