DC-128 + DC-129: client modpack scaffolds (Java .mrpack + Bedrock .mcpack) - #6
Conversation
…k .mcpack Two parallel client-install pipelines, kept in one PR because they share the client/ + scripts/ + dist/ shape. DC-128 — Java .mrpack: - client/mrpack/manifest.toml pins 11 mods + 3 resource packs to specific Modrinth version IDs. Bumping is one-line; nothing is cached locally so every build pulls fresh URLs and checksums from the Modrinth API. - scripts/build-mrpack.sh resolves manifest → modrinth.index.json (with per-file path / hashes / downloads / fileSize) and zips into dist/daemoncraft-<version>.mrpack. First build: 14 files, valid formatVersion: 1, fabric-loader auto-resolved to current stable via the Fabric meta API. - README covers install path, what's bundled, the "shaders are NOT included" policy, version-bump procedure. DC-129 — Bedrock .mcpack: - client/mcpack/manifest.json (format_version: 2) with stable header + module UUIDs and min_engine_version: [1, 21, 0] (covers all 1.21.x Bedrock clients). - texts/en_US.lang + languages.json carry pack name and description. - pack_icon.png — 256×256 brand-colour placeholder (569 bytes), generated procedurally via stdlib (struct + zlib + crc32). Replace with real art before public release. - scripts/build-mcpack.sh zips into dist/daemoncraft-bedrock-<version> .mcpack, excludes README.md so Bedrock doesn't see junk in the archive, refuses to ship if pack exceeds the 10 MB Geyser join-timeout budget. Both packs are intentionally minimum-viable: they confirm the install / delivery path works end-to-end. Texture overrides (Bedrock) and a custom UI pack (Java) need designed assets and land separately. dist/ added to .gitignore — built artifacts, not source. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Review — DC-128 + DC-129 client modpack scaffoldsClean MVP. Two minor notes. Note — Particular mod deferredREADME correctly documents that Note — build script network dependency
Nits
No blockers. LGTM. |
Audit follow-up. The build script needs Modrinth API access; reviewer asked for an offline workaround note for developers with flaky connections. Documented: - The live-API path's network dependency (~15 requests per build, 30 s timeout each, ~300 req/min unauthenticated rate limit). - The overrides/ pre-fetch path: drop jars into overrides/mods/ and RPs into overrides/resourcepacks/ to ship them verbatim and skip Modrinth App's download step at install time. - The honest limitation: even with overrides/, modrinth.index.json generation still queries the API. True air-gap requires hand-authoring the index file. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
|
Thanks for the review — both notes addressed.
LGTM ack noted — ready when you are. |
Re-review — PR #6 (DC-128 + DC-129 client packs)Audit follow-up addressed.
LGTM. |
Implements DC-128 (Java .mrpack) and DC-129 (Bedrock .mcpack) from the DC-124 epic. Independent of PRs #3/#4/#5 — this PR only adds new files under `client/` and `scripts/`, no overlap with their diffs.
Both packs are intentionally minimum-viable: they confirm the install / delivery path works end-to-end. Texture overrides (Bedrock) and a custom UI pack (Java) need designed assets and land in follow-ups.
DC-128 — Java client `.mrpack`
Two known gaps from the original task list:
DC-129 — Bedrock client `.mcpack`
Test plan
🤖 Generated with Claude Code