WN's server config lives at config/warring-nations/wn-core-server.toml (a hyphenated subfolder). On the first boot after upgrading from an old build that stored it as a flat config/<file>.toml, WN migrates it automatically, but only if both files aren't already present. If you see both an old and a new file after an upgrade, WN leaves both alone and uses the new one, so check the old file for any values that didn't carry over and set them manually.

Config JSON under config/warringnations/war_types/ or config/warringnations/presets/<kind>/ isn't picked up until a reload: /war reload (war presets) or /wn preset reload (presets), or a server restart. A malformed file is skipped with a logged error, not a hard crash; check the server log for the specific file and message if a change isn't taking effect.

The treasury needs a registered EconomyCapability.INSTITUTION_ACCOUNTS provider (Impactor, Lightman's Currency, or Ultimate Banking System) to back the nation's own balance; a purely player-wallet mod like SG-Economy alone isn't enough. Check the startup log for a one-time warning if this mismatch applies to your setup.

Known, non-blocking UX gap under requireBannerApproval=true: reopening the banner painter after submitting a design shows the last approved banner, not the pending one.

chunkStrengthDecayRate exists as a config knob but has no gameplay logic behind it yet; it is inert regardless of value.

Check the startup log line ([wnsiege] loaded. Active target-mod modules: ...) to confirm the mod was actually detected; a mod id mismatch (a fork, a rename, a community port under a different mod id) means WN Siege never sees it as present. If it's listed as active, check that <section>.enabled is on, and general.enabled above it. If both are on and it's still not enforced, that specific action may be a documented gap rather than a bug.

This is the self-healing mechanism working as intended: a target-mod update restructured the exact method WN Siege's mixin depends on, so that module disabled itself rather than risk crashing the server. Check the server log for the disable reason; staff with warringnations.siege.staffnotify should have seen a chat warning at the moment it happened. Protection for that mod won't come back until WN Siege ships a compatible update.

Expected against any public WariumCE release; the integration is experimental and depends on an event that only exists on an unmerged upstream patch. It fails safe: the module disables itself with a log warning rather than crashing.

general.failOpenBeforeWnReady defaults to true, meaning alterations during the brief window before Warring Nations' own API has finished installing are allowed rather than denied, so the addon never hard-locks a starting server. Set it to false for a stricter (but occasionally noisier) startup if this window has been a real problem.

Check config/warring-nations/wn-siege-server.toml; the config moved there from the old flat config/wnsiege-server.toml location, and separately renamed some snake_case keys to camelCase. Both migrations are automatic and preserve existing values, but only run once, on first boot after upgrading. If both an old and a new file somehow already exist, WN Siege leaves both alone rather than guessing which is authoritative; reconcile them manually.

That's the crafted/replayed-packet gap Create's packet-protection module closes; confirm createPacketProtection.enabled is on.

A privileged intent the mod requested (MESSAGE_CONTENT, or GUILD_MEMBERS if roleSync.enabled) isn't toggled on for this application in the Discord Developer Portal yet. Toggle the matching intent under Bot > Privileged Gateway Intents; this is a hard rejection, not a soft warning.

Missing a base permission (View Channels / Send Messages / Embed Links), or a per-channel permission overwrite blocking it even though its role has every needed permission server-wide. Re-check bot permissions, then check that specific channel's own permission overwrites, not just the role.

The bot's own highest role doesn't outrank the role it needs to grant or create; Discord silently refuses the change with no error. Drag the bot's role above every role it needs to manage in the guild's role list. roleHierarchyWarning() / /debug bridge surfaces this.

The player authorized with a Discord account that isn't a member of connection.guildId; the guilds OAuth scope check fails the link silently rather than attaching to the wrong server. Confirm the player used the Discord account that's actually in your guild.

The channel is on the restrict-list (text commands only run in listed channels) or the ignore-list (text commands never run there), or the typed prefix doesn't match textCommands.prefix. Use /setup ignore-list / restrict-list, or /discord config get textCommands.prefix.

A nation-overrides.json (or gov-entity-overrides.json) entry references an id that no longer exists (typo, deleted since). The addon falls through to auto-create with a warning logged; fix or remove the stale entry.

The key is one of the handful captured once at startup (textCommands.enabled/prefix, relay.consoleFlushIntervalSeconds, linking.codeExpiryMinutes) or is deliberately not live-settable (secrets, connection identity). /config get <key> states when a change takes effect; a (restart)-marked key needs a server restart.

Warring Nations isn't installed, or is below the >=4.0.0 this addon's dashboards need. Check /debug mods (or the log at boot) for the installed WN version.

Check the startup log line Warring Nations BlueMap addon ready: wn-core=..., BlueMap=..., wndiscord=..., .... If wn-core reads "NOT FOUND", Warring Nations either isn't installed or hasn't finished loading yet; if BlueMap reads "not connected yet", BlueMap hasn't enabled its API yet (this is normal briefly at boot, and self-heals once BlueMap does).

Expected on a flat-only map (enable-perspective-view and enable-free-flight-view both false in that map's own config/bluemap/maps/<mapId>.conf). This is an intentional optimization, not a bug.

Values are read live, but only on the next rebuild pass. Trigger one by making any claim/nation/war/village change, or by reloading BlueMap; there is no separate "apply config" step.

Correct behavior: only claims belonging to an FTB Team that Warring Nations recognizes as a nation are rendered; personal and non-WN party claims are filtered out entirely.

If /nation color was never set (or set to pure white/black, FTB's unset default), a deterministic fallback hue is derived from the nation's UUID instead, stable across restarts but not player-chosen. Set a real color with /nation color to override it.

Confirm [features] warOverlay is true, and that at least one of that war's two nations' chunks actually borders the other's; the frontline only draws the contested edge, not the whole territory. If it's still missing, check the log for a rebuild-pass error.

Confirm [features] diplomacyLines is true and the layer is toggled on in the web app itself (diplomacyLinesDefaultHidden starts it off by default), and that both nations currently hold land in the same dimension; cross-dimension pairs are never drawn.

Confirm wndiscord is installed and its bridge core is actually running, [discord].warNotifications is true, and bluemap=<channelId> is set under wndiscord's own [channels].extra. An older wndiscord jar silently skips only the notification methods it doesn't have yet, without disabling the rest of the integration.

Those classes are compiled from local jars read from a sibling wn-core checkout (fileTree(...) in build.gradle), not a Maven dependency.