Crafty Server Workflow

Status: Planned

This project should be deployed to Crafty as a prepared server, not assembled manually inside the panel.

Recommended Workflow

1. Build and test the pack locally
2. Build and test the dedicated server locally
3. Prepare a clean server root with configs, mods, scripts, and EULA-ready layout
4. Zip that server root
5. Import the zip into Crafty
6. Select the correct server root during import
7. Start once in Crafty and verify logs, port, and world generation

Why This Workflow

It is cleaner than trying to compose a modded server directly in Crafty:

• You control exact versions before upload
• You avoid missing dependency drift
• You get one reproducible server artifact
• Client and server can be versioned together

Client Distribution

The repo now has a real client-pack export path for CurseForge:

• Run python3 pack/scripts/export_curseforge_pack.py [--skip-build]
• The export uses pinned CurseForge projectId and fileId metadata from pack/modpack-lock.json
• It combines those pinned third-party references with tracked overrides plus the built ChonkyCraft jar
• The generated import artifact is written under pack/export/
• Import that zip into CurseForge on the client side

Local prep helpers still matter:

• python3 pack/scripts/bootstrap_local_profile.py <target_dir> --search-root <root> ... can scaffold a local profile-like directory for setup work outside CurseForge
• python3 pack/scripts/verify_client_instance.py <instance_dir> can verify a real local CurseForge instance before sync or server assembly

Honest boundary:

• The repo still does not vendor third-party client jars
• A real client pack still depends on CurseForge-side third-party mod distribution and external NeoForge mod acquisition

Crafty Notes

Current source-backed panel behavior:

• Crafty supports importing an already prepared Minecraft server as a zip
• During import, Crafty asks for the server root directory inside the archive
• First start will still require accepting the Minecraft EULA in the panel flow

Ops Rules

• Keep one stable world per milestone branch
• Back up before phase migrations that change worldgen or progression flags
• Do not mix experimental pack builds into the main shared server without a fresh export
• Record exact pack version in the server MOTD or an in-repo release note
• Treat 4096 blocks as the target effective radius for the first long-lived shared world
• Keep the target shape conceptually circular for planning and pregeneration scope, even though vanilla world-border enforcement is square
• The repo now has first-pass command support for both border setup and pregeneration, but the final shared seed should still wait for one more round of fresh-world tuning
• Default the serious shared world to level-type=chonkycraft:adventure so it uses the custom biome and ore preset instead of vanilla worldgen
• Treat the serious shared overworld as large-biome space and preserve the soft radial progression rule around spawn when tuning worldgen

Early World Radius Policy

Current project call:

• Early disposable test worlds can stay open and short-lived while core worldgen is still moving
• The first serious shared world should target an effective 4096 block radius from spawn
• Border enforcement now has a first implementation path through /chonkycraft world border ...
• Pregen now has a first implementation path through /chonkycraft world pregen ...
• The current intended world logic is soft progression, not hard rings: earlier ores and landmarks should be more reliable near spawn, stronger content should trend farther out, and deeper cave bands should still matter inside each horizontal band

Current Repo Scaffold

The repo now includes a first implementation pass for this workflow:

• server/scripts/assemble_server.py builds a Crafty-ready zip from a synced local CurseForge instance and a local NeoForge server base
• pack/scripts/export_curseforge_pack.py builds a CurseForge import zip for the client pack from pinned modpack-lock.json metadata, tracked overrides, and the built ChonkyCraft jar
• pack/scripts/bootstrap_local_profile.py is the local client-side scaffold helper for building a profile-like directory with mods/, config/, defaultconfigs/, and kubejs/, searching user-provided roots for baseline jars, copying only NeoForge-valid matches, staging the built ChonkyCraft jar plus tracked pack files, and writing a report of what is still missing
• server/scripts/bootstrap_base_server.py can create a clean local base server root from the official NeoForge installer instead of requiring a manual preinstall step
• server/scripts/prepare_shared_world.py can boot a prepared local server root, run ChonkyCraft shared-world preparation, and stop cleanly
• server/scripts/verify_server_bundle.py can verify either a prepared server root or an exported zip before import
• pack/scripts/verify_client_instance.py can verify the local CurseForge instance before sync or export
• server/templates/ holds tracked root-level files that should override the clean base server
• pack/export/ is the destination for generated CurseForge client-pack zips
• server/export/ is the destination for generated import zips
• the tracked server template now defaults the level preset to chonkycraft:adventure
• /chonkycraft world border ..., /chonkycraft world pregen ..., and /chonkycraft world prepare_shared ... now provide the first in-game shared-world preparation workflow

Current Shared-World Prep Example

For the first serious overworld test, the current intended path is:

1. Either prepare a real CurseForge instance and verify it with python3 pack/scripts/verify_client_instance.py <instance_dir>, or use python3 pack/scripts/bootstrap_local_profile.py <target_dir> --search-root <root> ... to assemble a local profile-like scaffold and inspect its missing-items report before you move into a real client instance
2. Create a clean local NeoForge base server root
3. Preferred local milestone path once it lands: run python3 server/scripts/bootstrap_base_server.py <target_dir> and use that root as <base_server_dir>
4. Assemble the server bundle
5. If you want the zip to already include a pregenerated shared world, run python3 server/scripts/assemble_server.py <instance_dir> <base_server_dir> --prepare-shared-world
6. Verify the prepared bundle with python3 server/scripts/verify_server_bundle.py server/export/<bundle_name>.zip
7. Otherwise import the bundle first, start the server once, and run /chonkycraft world prepare_shared
8. Watch the server log or /chonkycraft world pregen status until it completes
9. Back up the resulting world before opening it for regular play

This is still a local-development scaffold, not a final public pack pipeline.

Current Hardening Rules

• Server assembly now skips unknown extra client-instance jars by default instead of silently carrying them into the dedicated server
• Use --include-unknown-jars only after you have verified that the extra jar is actually server-safe
• The assembler now writes an exported JSON manifest next to the server zip so you can inspect exactly which jars were included or skipped
• The local shared-world preparation helper can now write a full preparation log and temporarily accept the EULA only for the local pregen run, then restore the tracked file state
• The current pack-validation hardening milestone is tightening local instance checks so Fabric or Quilt jars do not satisfy NeoForge baseline requirements by filename overlap alone
• The current local-client scaffold milestone adds pack/scripts/bootstrap_local_profile.py for local directory setup only. It can help stage a profile-like tree and report missing jars, but it is not a magic CurseForge registration step
• pack/scripts/export_curseforge_pack.py now gives the repo a real client-pack export path for CurseForge import, but it still relies on pinned CurseForge metadata rather than vendored third-party jars
• Honest boundary: third-party client baseline jars are still not vendored in this repo, so external NeoForge mod acquisition and CurseForge-side distribution are still required before real client play