Changelog

Unreleased

• Fixed: lockdown.deny-join only blocked a player from moving into a locked world (teleport/portal) — it had no effect on a brand-new connection logging straight into a locked world, since that path never fires a teleport or portal event. Deny-join now also blocks at login: if the server's default world is locked, a joining player is kicked at AsyncPlayerPreLoginEvent with the same MOTD-style message, instead of connecting successfully and only then triggering vanilla chunk generation.
• Removed: the web dashboard entirely (/fwg web start|stop, the fastworldgen.web permission, and the web config section). It added an HTTP listener and a chunk-rendering map for a secondary use case most installs never touched; status/progress is still fully available via /fwg status.
• Default config.yml retuned for high-performance hardware (dedicated/bare-metal or a well-resourced VPS with cores and fast storage to spare): higher chunks-per-tick-batch, max-chunks-per-tick-batch, regions-per-batch, and max-inflight-chunk-tasks for more concurrent throughput, and a higher max-loaded-chunks to keep more generated chunks resident. Raised max-area-edge-blocks and max-chunks-per-plan so large pre-generation runs don't hit the safety ceiling. Every changed value is commented in the file with the memory/throughput tradeoff it carries and guidance to scale it back down on smaller hardware.

FastWorldGen 1.2.1

• Fixed: the web dashboard's map could render as a solid, near-black "nothing here" area with no visible distinction between generated and ungenerated chunks. The placeholder color for an ungenerated chunk was a dark gray almost identical to the map's own background. Ungenerated chunks/regions are now colored red.

• Fixed: the map's initial view used a fixed default zoom/center regardless of the world's actual generation area, which for a large world border or a small requested radius meant opening to either a tiny speck or an almost entirely red screen. The dashboard now opens zoomed to fit the active generation plan's bounds (falling back to the world border only when no plan exists, and ignoring an unset/default-sized border so it doesn't zoom out to effectively nothing).

• Fixed: the map container was a wide rectangle rather than square, distorting the map relative to the world's actual (square-ish) shape. It's now rendered at a 1:1 aspect ratio.

• Fixed: chunks that were already generated on disk would often not render at all unless a player happened to load them in-game first (e.g. by walking nearby), and a dashboard tile request could hang indefinitely instead of completing. The root cause was a self-deadlock: loading a not-yet-resident chunk for rendering was waited on from inside the very main-thread task that chunk load's own completion needed to run on, so it could never finish on its own. Chunk loads are now dispatched on the main thread but waited on from the request's own thread, and are performed strictly one at a time (never dozens or hundreds at once) with a per-chunk and per-request time budget, so a tile request always completes promptly; any chunks it doesn't get to in time are simply picked up on the next automatic refresh.

• Fixed: loading a chunk for map rendering could call into a Paper API path (getChunkAtAsyncUrgently, via World#isChunkGenerated) that blocks the main thread pumping the server's own chunk-load queue, which during an active generation job (region I/O already saturated) could stall the entire server tick loop for several seconds at a time ("server has not responded" warnings). Rendering now uses a non-generating, non-blocking chunk load instead, since the on-disk region-file scan already confirms the chunk exists before a load is ever attempted.

• Added a yellow outline around the chunk range currently being fetched/rendered, so it's clear the map is actively loading data rather than appearing frozen or broken.

• Redesigned the dashboard's visual style: a cleaner, Google Material-inspired light theme (replacing the previous dark/glowing look) with a proper mobile-responsive layout (the stat grid, map controls, and About panel all adapt down to phone-width screens).

• Fixed: /fwg wand and /fwg continue (and in principle any subcommand) could silently fall through to the usage/help message for a non-op player in-game, even when that player held the specific permission node the subcommand checks for in code (e.g. fastworldgen.wand). Cause: plugin.yml set a blanket top-level permission: fastworldgen.status on the /fwg command itself. Bukkit enforces that gate before onCommand runs at all, so a player without fastworldgen.status specifically was rejected by Bukkit itself — independent of whichever subcommand permission they actually had. Console was unaffected because ConsoleCommandSender bypasses permission checks entirely, which is why the bug only showed up in-game. Removed the top-level permission; every subcommand already enforces its own specific permission node in code.

FastWorldGen 1.2.0

• Added self-healing configuration: on every plugin enable and every /fwg reload, config.yml is compared against the plugin's bundled defaults/schema. Missing keys are restored, keys with the wrong value type are reset to their default, and keys that aren't part of the schema at all are removed. A timestamped config.yml.bak-<epoch-ms> backup is written next to config.yml whenever a repair actually changes something, and a summary of what was repaired is logged to console.

• Removed: Custom Generation scripting entirely. This drops the /fwg script subcommand (run/list/cancel/status), the fastworldgen.script permission, the embedded Mozilla Rhino dependency, the scripting config section, the scripts/ folder, and docs/SCRIPTING.md. Everything else (planning, start/pause/resume/cancel, the wand, the web dashboard) is unaffected.

• Added update checking: on enable, FastWorldGen asynchronously queries Hangar (hangar.papermc.io/firesmasher/FastWorldGen) for the latest release and compares it against the running version. Result is logged to console in color; if an update is available, operators (and fastworldgen.admin holders) get a colored chat notice shortly after joining.

• Added the wand: /fwg wand give hands out a named Blaze Rod; left-click sets position 1, right-click sets position 2 (WorldEdit-style, clicks are cancelled so nothing breaks or places). /fwg wand save <name> fills a vanilla Structure from the selection and writes it to data/structures/<name>.nbt. Also adds /fwg wand pos1|pos2|info|clear.

  • New fastworldgen.wand permission (defaults to op, included in fastworldgen.admin).
  • Selections capped at 2,000,000 blocks and must stay within a single world.

Requirements: Paper 1.21.11, Java 21+.

FastWorldGen 1.1.0

• Added /fwg continue [world] to explicitly re-plan and continue a saved job after a restart, instead of that only happening automatically when another command triggered it.
• Memory: regions are now streamed as compact bitmasks instead of per-chunk objects during planning, and generated chunks are unloaded once a configurable number stay loaded at once (safety.max-loaded-chunks), bounding memory growth on large-radius jobs.
• Default config and built-in fallbacks retuned for a 4 GB heap / 2 CPU cores: lower chunks-per-tick-batch, max-chunks-per-tick-batch, max-inflight-chunk-tasks, max-loaded-chunks, and regions-per-batch, with adjusted MSPT watermarks. Requirements: Paper 1.21.11, Java 21+.

FastWorldGen 1.0.0

Initial release.

• Plan-first pipeline: /fwg plan shows total chunks, existing chunks, chunks to generate, and region count before any generation happens.
• /fwg start begins generation immediately after planning; works with just a world name (uses a configurable default radius) or explicit radius/bounds + optional center.
• Existing chunks are skipped by default; pass --fresh to force regeneration.
• Work is grouped into 32×32 chunk regions and batches, ordered for spatial locality.
• Adaptive throughput throttles generation based on live server tick time (MSPT).
• /fwg status shows live progress, speed, ETA, region/batch counts, and MSPT.
• Detailed logging: per-region and per-batch completion lines as generation runs, plus a full summary (chunks generated/failed, elapsed time, average speed) when a job finishes.
• /fwg pause / /fwg resume / /fwg cancel, all graceful — in-flight chunk operations are allowed to finish rather than being interrupted.
• Job state survives server restarts; the world is re-inspected on startup rather than trusting stored progress.
• Full permission set, all defaulting to op.

Requirements: Paper 1.21.11, Java 21+.