How SeedCrackerX commands work on the client
SeedCrackerX registers its command tree on the client through Fabric, so the server does not need the mod installed.
Current source registers the root literal /seedcracker and attaches render, finder, data, cracker, version, GUI, and database subcommands. Because these are client commands, they can work while connected to a vanilla server as long as your own Fabric client loaded SeedCrackerX. A server plugin with a similarly named command is unrelated and may behave differently.
If every /seedcracker command is unknown, treat that as an installation problem. Confirm the launcher started a Fabric profile, inspect the active instance mods folder, and read the Fabric log for an incompatible Minecraft range or missing dependency. If only a specific subcommand is unknown, compare your installed mod version with the command documentation because older builds used /seed and did not expose the same tree.
SeedCrackerX commands for bits, clear, and restore
The data group controls the observations feeding the current TimeMachine search.
Run /seedcracker data bits after a structure is detected. The first message reports collected base information against the normal target of approximately 32 bits. The second reports liftable information against approximately 40 bits. The values are displayed as integers, while the internal model can use fractional information based on each structure feature's placement offset.
Use /seedcracker data clear when moving to another world, correcting a wrong Minecraft version, or deliberately restarting after bad data. The reset clears pillar data, structure and biome observations, candidate sets, block-update work, and active finder outlines. The hashed seed is intentionally retained by the current source in some reset paths, so a full reconnect may still be appropriate when changing server or dimension context.
The restore command loads saved structure entries for the current server address or single-player world. Each saved line contains a structure name and chunk coordinates. Restore only data belonging to the same world and compatible generation version; an old structure file from another server can make every candidate fail.
SeedCrackerX commands for structure finders
Finder commands change what new chunk packets are scanned; they do not retroactively scan every loaded block unless you reload.
The source groups finders into STRUCTURES, DECORATORS, and BIOMES. Individual types include buried treasure, desert pyramid, End City, jungle temple, monument, swamp hut, shipwreck, pillager outpost, igloo, Trial Chambers, End pillars, End gateway, dungeon, emerald ore, desert well, warped fungus, and biome sampling. Defaults favor modern structure finders while several legacy decorator finders and biome sampling begin disabled.
After changing a category or individual finder, run /seedcracker finder reload to rescan chunks within the current render distance. Reloading can be CPU intensive because each enabled finder may construct several orientation or neighboring-chunk checks. Enable only the data sources relevant to the selected Minecraft version, especially when an older decorator implementation is documented as outdated.
- Keep End pillars enabled when you intend to use the pillar-seed route.
- Use structure finders as the main collection route on Minecraft 1.18 and newer.
- Enable biome sampling only when candidate structure seeds exist and the world-seed stage requests more biome information.
- Disable outlines separately if rendering affects performance; finder collection and rendering are different settings.
- A finder marked ON can still produce no result if the template, biome, dimension, or version check rejects the observed blocks.
SeedCrackerX commands for version, debug, and render
The version setting changes the feature definitions used to test structure positions.
Use the GUI for ordinary configuration because it presents supported versions and finder toggles together. The direct version subcommand is useful when documenting or reproducing a setup, but the supplied version must exist in the bundled seedfinding library. Changing the version reinitializes every feature definition, including spacing, salt, and supported structure behavior. Clear incompatible observations after a change.
Debug mode exposes intermediate pillar, structure, and hashed-seed information in chat or logs. It is useful when a search finishes with no result, repeatedly requests more structures, or appears stuck before world-seed recovery. Debug output can be noisy, so capture only the relevant section and disable it after diagnosis. Render commands affect colored cuboids around detected structures and do not change the mathematical constraints already stored.
SeedCrackerX commands and database privacy
Opening the database and submitting a cracked multiplayer seed are separate behaviors.
The database command opens a public Google Sheet used by the mod community. At startup, current source can also download a CSV mapping server addresses or hashed seeds to known world seeds, allowing an immediate lookup before a local search. This lookup is why a result can appear without collecting new structures on a previously recorded server.
Database submission is disabled by default. When enabled, a successful crack on a non-local server with more than ten online players can post the server address, dimension, seed, configured version, username or anonymization flag, and related hash data through a Google Apps Script endpoint. Review server rules and privacy implications before changing that option. SeedCracker Guide does not access, mirror, or query that database.
Route SeedCrackerX problems by symptom
Start with the visible symptom and use the smallest command set that can separate installation, detection, data, and search failures.
SeedCrackerX is a Minecraft Java Edition client-side Mod for Fabric. These commands run in the client after the mod registers; they do not make a server plugin, Paper configuration, custom generator, or anti-cheat environment compatible. Keep the Minecraft generation version, dimension, and world data together, and use the in-game bit output rather than a browser estimate as the final authority.
The full SeedCrackerX usage guide explains the collection workflow. The routes below are a command-first index for a seedcrackerx not working report.
Unknown command
Symptom: The client returns Unknown command for /seedcracker gui or another documented command.
Possible reason: The active profile is not the matching Java Edition Fabric instance, the JAR is missing, duplicated, or incompatible, or an older build uses the /seed prefix. A server-side command with a similar name is a separate implementation.
Check: Inspect the active instance's mods folder, Fabric Loader log, Minecraft range, dependencies, and installed release. Confirm that the command is being entered in the client with the mod loaded.
Recommended command: Run /seedcracker gui after restarting the intended Fabric profile; check that build's documentation for /seed gui only when using a pre-2.13.1 build.
Next action: Install one matching official release asset and reproduce the command in a permitted test world. Compare the log with the official issues without treating one report as a confirmed universal bug.
No structure outline
Symptom: A structure is visible in the world, but no finder outline appears and no new observation is reported.
Possible reason: The global cracker, finder, or outline renderer is off; the chunk is not loaded; the dimension or generation version is wrong; or the blocks do not match the supported template. Rendering and collection are separate settings.
Check: Use the GUI to verify the current version, dimension, cracker, finder, and outline settings. Confirm the mod detected the structure in the current world instead of relying on a map coordinate, and account for custom generation or server-side changes.
Recommended command: Run /seedcracker finder reload after changing finders, then /seedcracker data bits to check whether an accepted observation changed the totals.
Next action: Test a fresh supported structure in the same permitted world. If it remains reproducible, record the exact version, dimension, finder, and sanitized log for the official issue tracker; no universal template or server compatibility is promised.
Normal bits are sufficient but liftable bits are not
Symptom: The normal value looks sufficient, but the liftable value shown by /seedcracker data bits remains low.
Possible reason: Normal and liftable bits are different progress values. A normal-only structure, duplicate, rejected template, or rounded calculator estimate cannot be counted as the missing liftable information.
Check: Read both in-game values, verify the accepted finder outline, and confirm that the Minecraft version, dimension, and world match. The structure bit calculator is a planning estimate, not a replacement for the client output.
Recommended command: Run /seedcracker data bits after each new detection and /seedcracker finder reload only after finder settings change.
Next action: Collect a supported liftable structure and follow the liftable-structures guide. Do not add data from another world to make the displayed total reach a target.
No results appears immediately
Symptom: A search reports no results or zero candidates immediately after it starts.
Possible reason: Wrong generation version or dimension, false detection, cross-world data, incompatible restored coordinates, or stale observations can create contradictory constraints. An immediate zero is not by itself proof of a release-wide bug.
Check: Compare every observation with the current world, dimension, version, and structure template. Review recent restore actions and the normal/liftable values before collecting more data.
Recommended command: After locating invalid data, run /seedcracker data clear; use /seedcracker cracker debug ON for a short trace and /seedcracker finder reload after correcting finder settings.
Next action: Recollect from the same permitted world and submit sanitized version, dimension, data, and log details to the official issues if the clean case still fails.
The search keeps running
Symptom: The client stays in a search phase for a long time or the candidate count changes slowly after the displayed threshold is reached.
Possible reason: Pillar, lifting, biome, and upper world-seed stages can be expensive. Hardware, candidate count, evidence quality, and a request for more data affect duration; a threshold is not a time guarantee.
Check: Read chat and logs for the active phase or a request for structures, hash, biomes, or pillars. Do not infer failure from elapsed time and do not clear data just because the search is slow.
Recommended command: Use /seedcracker cracker debug ON for one reproducible diagnostic run and disable it after capturing the relevant output. Use /seedcracker data bits only when the client is responsive.
Next action: Let the phase finish or collect the exact requested evidence in the same world. For a repeatable stall, attach sanitized logs and release details to the official issue tracker; completion time is not guaranteed.
The crack cannot finish on a Paper server
Symptom: The Fabric client loads and commands respond, but detection or the final crack cannot finish on a Paper server.
Possible reason: Paper settings, plugins, proxies, custom world generators, anti-xray, or anti-cheat can change or hide the deterministic evidence received by the client. A client-side installation does not mean that the server allows the mod or that the environment is compatible.
Check: Confirm the real generation version and dimension, ask the operator for permission, inspect server/plugin context, and compare a permitted vanilla or local test. Do not bypass server rules or anti-cheat.
Recommended command: Record /seedcracker data bits and use /seedcracker cracker debug ON for a short sanitized trace. No command can guarantee Paper compatibility.
Next action: Stop when analysis is not permitted; otherwise report the exact permitted setup to the official issues. Keep one server report separate from a confirmed project-wide bug.
Candidates look wrong after changing worlds
Symptom: Bits, candidates, or the next search request looks wrong after switching single-player worlds, servers, dimensions, or generation versions.
Possible reason: Old observations, candidate state, hashes, or saved coordinates are still active. Minecraft version, dimension, and world data cannot be mixed.
Check: Identify the current world/server and dimension, compare the configured version with the world-generation version, and mark all pre-switch observations as suspect.
Recommended command: Run /seedcracker data clear before collecting in the new context, then use /seedcracker gui to verify settings and /seedcracker data bits after fresh detections.
Next action: Reconnect when the server or dimension changed, keep records separated, and use /seedcracker cracker debug ON only for a clean reproduction. Check the official issue tracker with sanitized evidence if the anomaly remains.
Restore produces an incorrect result
Symptom: After /seedcracker data restore, the bits or candidates do not match the current world, or the restored search returns zero candidates.
Possible reason: Restore reuses saved structure entries; it does not verify their world, dimension, version, or template. A record from another server or generation release can be internally valid but wrong for the active context.
Check: Verify the saved source, structure names, chunk coordinates, server/world identity, dimension, configured version, and release. Compare the state with /seedcracker data bits before mixing restored and new observations.
Recommended command: Run /seedcracker data clear when the source is not exactly compatible. Use /seedcracker data restore only for same-world, compatible-generation records and /seedcracker cracker debug ON only to capture a reproducible mismatch.
Next action: Rebuild from current detections, keep private addresses and seeds out of reports, and consult the official issues. A bad restored result alone does not prove the release is broken.