octoturge
2b7e0e090d
Extends ChunkAdapter with readSections() (reads non-empty 16x16x16 sections via the chunk's ExtendedBlockStorage array, skipping fully-air ones for free) and DeltaSink with onChunkDirty(), additive to Phase 1's column-based readChunk()/onDelta — 2D column tracking is unchanged. BackendConnection grows sendSections(), base64-encoding each section's 4096-entry char[] (char, not short, since short would overflow for any blockId >= 2048 — see SectionData's javadoc) into the wire protocol's new "sections" message, mirrored in MCMapper-Backend's matching commit. MCMapperMod now tracks dirty chunks (not just dirty columns) and, on the same flush tick as column deltas, re-reads and resends full section data for any chunk touched since the last flush — same "current state, not a diff" approach as columns, at chunk instead of column granularity. Verified against a live MCMapper-Backend instance: a known half-solid section sent through this exact code path round-trips to a mesh with exactly 24 vertices / 36 indices at the backend's mesh-serving endpoint, matching the worker's greedy-mesher unit tests for a uniform section.
MCMapper-Mod
Thin, version-independent Forge/NeoForge client for MCMapper-Backend. Streams delta block updates out to the backend instead of rendering the map on the MC server itself (the Bluemap/Dynmap resource problem this project exists to avoid). Full architecture and phased delivery plan lives in the backend repo's planning docs / was tracked during design in Claude Code's plan mode.
Repo layout
common/— loader-agnostic Java: protocol types, config model, and the interfaces (ChunkAdapter,ChatBridge,BackendConnection) each leaf implements. Not a compiled dependency — pulled in as source per leaf (seecommon/README.md).forge-1_12_2/— primary leaf, MC 1.12.2 Forge. First implemented; this is the actual driving use case (an Enigmatica 2 modpack server). Builds with legacy ForgeGradle 2.3 via anatawa12's Gradle-7-compatible fork (seeTHIRD_PARTY_NOTICES.md).forge-1_7_10/— MC 1.7.10 Forge. Second priority. Builds with legacy ForgeGradle 1.2, same fork family, one Forge-tooling generation further back.neoforge-26_1/— MC 26.1.2 (NeoForge, assumed). Lowest MVP priority. Structurally scaffolded, not yet wired into the default build (seesettings.gradle).
Version targets and priority
- MC 1.12.2 Forge — highest priority (Enigmatica 2)
- MC 1.7.10 Forge — also a priority
- MC 26.1.2 — lowest of the three MVP targets
Fabric support is an explicit future phase, not part of the MVP.
Building
Both legacy leaves share one root build, on Gradle 7.6 / JDK 8 (pinned via
org.gradle.java.home in gradle.properties — see settings.gradle for why):
./gradlew :forge-1_12_2:build
./gradlew :forge-1_7_10:build
The first build downloads Minecraft/Forge artifacts and MCP mappings from Forge's Maven and can
take a while / needs network access. neoforge-26_1 is not yet buildable from the root — it
needs Gradle 8+ and JDK 17+ (ModDevGradle), incompatible with the legacy leaves' toolchain
within one Gradle invocation; see settings.gradle's comment for the workaround until Phase 10
gives it a proper isolated build.
Configuration (Phase 1: forge-1_12_2)
On first server start the leaf writes config/mcmapper.cfg with defaults. Set:
backendUrl=ws://<backend-host>:3000/ws
serverToken=<token from MCMapper-Backend's `bun run seed`>
then restart. With those set, the mod connects to the backend, backfills already-loaded
overworld chunks, and streams event-driven column deltas (block place/break) in batches every
deltaFlushIntervalTicks (default 20 = 1s). No periodic reconciliation sweep yet (Phase 7),
and only the overworld — other dimensions and forge-1_7_10/neoforge-26_1 land in later
phases. The WS client and JSON encoding are hand-rolled (no third-party dependency) — see
common/src/main/java/.../ws/SimpleWebSocketClient.java and .../json/MiniJson.java for why.
Attribution
See THIRD_PARTY_NOTICES.md.