CC2 Phase 0: scaffolding, colossalchests2 rename, CC1 teardown

[rubensworks]

Phase 0 of the Colossal Chests 2 implementation plan.

Summary

• feature/1.21-lts-v2 did not exist, so I created it as an exact copy of master-1.21-lts (no extra commits). All phase PRs target it.
• Renamed the mod to colossalchests2: mod id, Java package (org.cyclops.colossalchests2), resource namespaces, access widener, Gradle group and mod name. Per review, the CurseForge/Modrinth project IDs, display URL and update JSON URLs stay the same as CC1. The description is now "Chests that are quite colossal, and can be upgraded." (gradle.properties and README). git grep -P 'colossalchests(?!2)' has zero hits outside the changelogs.
• Removed all CC1 gameplay content: blocks, items, block entities, GUI, inventories, packets, renderers, advancement, recipes, loot tables, conditions, IronChest and CommonCapabilities compat, the invtweaks API stubs, non-English lang files. What's left is loader entrypoints, proxies, Cyclops Core wiring, build setup and CI. CC1 block textures stay for reuse later (silver dropped, since it's not in the D-5 table).
• JUnit now runs in loader-common against vanilla classes (neoForge.addModdingDependenciesTo(sourceSets.test) in multiloader-loader-common.gradle, which only loader-common applies).
• Chest-wide values are config options in GeneralConfig (category chest): baseSlots (27), maxSlots (81) and depthSize2 ... depthSize10 (stacks per slot by structure size, 4 ... 262144). Getters clamp them to the hard caps (81 slots, size 10, depth at least 1), because config ranges aren't enforced on load (see the Cyclops Core note below).
• Materials are data-driven, one file per material in its owner's namespace, so mods and datapacks can add materials without overwriting each other: data/<ns>/colossalchests2/material/<name>.json (upgrade slots, max size, blast resistance).
  • Upgrades will be items, and each declares its own values and per-material limits in data/<ns>/colossalchests2/upgrade/<name>.json (Phase 5). A new upgrade, from us or another mod, therefore needs no changes to material files.
  • Every field is optional with a default and unknown fields are ignored, so adding fields later never breaks existing datapacks. Nothing from these files is saved in the world.
  • ChestTablesLoader.fromJson builds the tables from loaded files; nothing loads them from datapacks yet (Phase 3).
• Game test harness: one shared test in GameTestsCommon, run on NeoForge, Forge and Fabric.

Validation

Criterion	Coverage
Builds on all three loaders	./gradlew build passes
JUnit in common	TestChestTables (5 tests): shipped material files equal the code defaults, missing fields fall back to defaults, unknown fields are ignored, out-of-range values are rejected. TestGeneralConfig (7 tests): depth for every size, clamping of slot and depth values
Game tests on all loaders	./gradlew runGameTestServer: "All 2 required tests passed" on Fabric, Forge and NeoForge (ours plus Cyclops Core's)
Mod loads as colossalchests2	clientdevbridge on NeoForge (script). Screenshot below

Per review, the clientdevbridge scripts are not in the code branches. They live next to the screenshots on the orphan branch clientdevbridge-screenshots.

Design deviations

• DESIGN.md and IMPLEMENTATION_PLAN.md are not added to the repo, as requested.
• dev/clientdevbridge/ is not in the repo, per review.
• Materials (and later upgrades) are datapack JSON, one file per entry, so other mods can add their own. Chest-wide values (slots, depth by size) and scalar options (maxItemsPerSlot, acceptNonStackables, magnet radius) are regular Cyclops config options instead.

Cyclops Core note

The chest options are marked ModConfigLocation.SERVER, but Cyclops Core (1.25.3, and still in the latest 1.30.0-1139) defines every property on the COMMON spec builder. ConfigHandlerNeoForge creates the per-location builder but passes the common one to onConfigPropertyInit. As a result:

• These options end up in config/colossalchests2-common.toml, not per world, and aren't synced to clients.
• The SERVER file is registered but empty.
• minimalValue/maximalValue aren't enforced, because properties use define rather than defineInRange.

The Fabric run shows the same (empty colossalchests2-server.toml). Fixing this is a breaking change for every Cyclops mod, so it is only fixed on master-26 (CyclopsMC/CyclopsCore#252). On 1.21-lts, CC2 lives with it:

• These options are global per instance, not per world.
• CC2 never reads them on the client; the server sends whatever the GUI shows.
• The getters clamp the values.

The options keep configLocation = SERVER, so they become per-world options without code changes once CC2 is on 26.

• clientdevbridge only supports NeoForge and Fabric. GUI validation will use NeoForge.

Stacking

Later phase PRs are stacked on this one. Until this merges, their diffs will include these commits.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RSz5r6eowhjNuANBjZE2v6

---

Generated by Claude Code

[rubensworks]

Sure the changes in this file will work, since this is common to all loaders?...

[rubensworks]

Yes. Despite the name, multiloader-loader-common.gradle is only applied by loader-common/build.gradle. The loader modules apply multiloader-loader.gradle and the per-loader scripts instead, and both of those only pull in multiloader-common.gradle. So addModdingDependenciesTo(sourceSets.test) and the JUnit dependency only affect the common module's test source set, which puts vanilla classes on its test classpath.

I checked this with ./gradlew build (common tests ran: 4 in Phase 0, 81 once Phase 1 is added) and ./gradlew runGameTestServer. Both pass on Fabric, Forge and NeoForge, and the loader test tasks are unaffected (NO-SOURCE).

---

Generated by Claude Code