Future: Evaluate Bedrock exporter feasibility for VoxelPlan targets

Context

CraftDAG's current export path is Java-first and schematic-oriented:

ComponentPlan
→ CraftDAG IR
→ VoxelPlan
→ .schem exporter
→ WorldEdit / Litematica / Java server workflows

This is the right near-term path for builder/server-owner validation, but CraftDAG should not be conceptually locked to Java Edition forever. The core compiler pipeline is already structured around an intermediate VoxelPlan, which could potentially target multiple export formats.

This issue records a future technical feasibility study for Bedrock-compatible export targets.

Core question

Can CraftDAG export VoxelPlan outputs to Bedrock-compatible structure/world formats without compromising the Java-first schematic workflow?

Candidate targets

1. .mcstructure

Likely first target to investigate.

Questions:

• What is the exact format requirement?
• How should block palettes and states be encoded?
• How should unsupported Java block IDs/states be mapped or rejected?
• How should block entities be handled?
• Can this be implemented as a separate exporter package?

Possible package shape:

packages/exporter-mcstructure

2. .mcworld / .mctemplate

A heavier target that packages structures into a world/template import flow.

Questions:

• Is this a MinePilot product concern more than a CraftDAG exporter concern?
• What world metadata is required?
• How should spawn point, preview world, and placement location be defined?
• Can a build pack be generated from multiple VoxelPlans/sections?

3. Official Marketplace-ready content packages

This is likely out of scope for CraftDAG core.

Marketplace-oriented content requires packaging, QA, metadata, store assets, legal/provenance review, and platform rules. CraftDAG may provide build artifacts, but should not own the whole Marketplace pipeline.

Recommended stance

Java-first implementation, platform-neutral IR, Bedrock-aware exporter roadmap.

CraftDAG should:

• keep VoxelPlan exporter-neutral where practical;
• avoid baking Java-only assumptions into ComponentPlan semantics where not required;
• support Java .schem as the primary production exporter for now;
• evaluate Bedrock export as a separate future package;
• avoid promising Bedrock parity before format/block-state compatibility is understood.

Technical risks

• Java and Bedrock block IDs/state models may differ.
• Some blocks may not map cleanly.
• Block entities/NBT/inventory data may differ significantly.
• Redstone behavior and orientation may not be equivalent.
• Version compatibility may require explicit target metadata.
• Existing material palettes may need edition-specific mappings.
• Test fixtures may require Bedrock-specific round-trip validation.

Proposed feasibility milestones

Stage 0: Research note

Create a short technical note covering:

• .mcstructure format basics;
• palette/state mapping approach;
• known unsupported block/state categories;
• block entity limitations;
• test strategy;
• relationship to current .schem exporter.

Stage 1: Minimal prototype

Export a small VoxelPlan containing only simple solid blocks to .mcstructure.

Candidate fixture:

small platform + room shell, no block entities, no redstone

Stage 2: Compatibility metadata

Add exporter warnings or metadata for:

• unsupported blocks;
• lossy block-state mapping;
• Java-only assumptions;
• Bedrock target version if needed.

Stage 3: Product handoff

Coordinate with MinePilot if a Bedrock export button, import guide, or world-template packaging becomes product-relevant.

Non-goals

• Do not replace the Java .schem exporter.
• Do not promise Bedrock parity.
• Do not implement Marketplace-ready packaging in CraftDAG core.
• Do not support arbitrary Bedrock add-on behavior here.
• Do not block current ComponentPlan/Java exporter work on this issue.
• Do not make ComponentPlan Bedrock-specific.

Acceptance criteria for future evaluation

When this becomes active:

• A technical note describes .mcstructure feasibility and risks.
• A decision is made whether to prototype packages/exporter-mcstructure.
• Block mapping strategy is defined explicitly.
• Unsupported/lossy behavior is surfaced as diagnostics or exporter warnings.
• A minimal fixture proves whether simple VoxelPlan export is practical.
• MinePilot has a corresponding product issue for Bedrock import/Marketplace route.

Related

• MinePilot Bedrock / official Marketplace product route issue.
• Current Java .schem exporter work.
• Future redstone/block-entity support issues.

Start by reading the VoxelPlan pipeline and current Java .schem exporter, then document the .mcstructure format, palette and block-state mapping, block-entity limits, and test strategy. Define whether a separate packages/exporter-mcstructure prototype is feasible and what unsupported or lossy cases require warnings. Done means the feasibility note and prototype decision address the listed acceptance criteria without replacing the Java exporter.