Blueprint-Analyzer-Guide: Stückliste und Formanzahl

A blueprint file can be audited for identities, colors, bodies, joints, controllers, containers, and the dimensions of bounded block records. From those structures, an analyzer can build a bill of materials by identity and calculate a consistent structural shape total.

The accepted local corpus contains 1,155 blueprints: 462 version-2 files, 609 version-3 files, and 84 version-4 files. Across them are 1,888 bodies, 212,466 child records, 973 joints, 8,965 controllers, 53 containers, and 35 multi-shape blueprints. Testing all three formats matters because a parser proven on one sample can still fail on another version.

Each joint counts as one shape. A child without bounds counts as one shape. A bounded child contributes bounds x × y × z block units. The corpus totals 34,493,988 bounded block units under this rule. One record with a zero-length axis contributes zero, which is mathematically consistent and should be surfaced as a diagnostic edge case.

This total measures serialized structural units, not necessarily the number a player perceives as “parts.” A 10 × 10 × 1 plate is one child record but 100 block units. Reports should label both values clearly when showing record count and expanded unit count.

The game-side `getBlueprintCost` behavior is not present in the audited data path, so the analyzer must not invent an exact Survival placement cost. A UUID count or bounded block volume is useful for auditing structure, but converting it to current raw resources requires separate authoritative rules.

This boundary prevents a common SEO error: presenting a precise-looking material price derived from assumptions. Use the BOM to find what the blueprint contains, compare versions, spot unexpected identities, and estimate structural scale. Use current recipes separately when planning what to craft.

Color values are normally six-digit RGB; the corpus also contains two valid RGBA records. A parser that accepts only one format can reject otherwise usable blueprints. Controller and joint counts help identify creations that deserve closer inspection after a game update because their behavior depends on more than static geometry.

For troubleshooting, compare high-level counts first: format version, bodies, children, joints, controllers, containers, and unique identities. Then inspect the category that changed. This reduces a large JSON difference to the subsystem most likely to explain the visible problem.

Analyze a copy of the blueprint, confirm that every identity resolves, and inspect unusual dimensions or zero-axis records. Review stored contents separately. If the blueprint uses mods, record the dependency list and treat unresolved identities as compatibility findings rather than deleting them automatically.

After the structural audit, test the creation in a disposable world. A valid file can still behave differently because physics, logic timing, or a mod script changed. File validation and in-game validation answer complementary questions.

• Use BOM counts for identity and structure auditing.
• Keep stored container contents outside the shape total.
• Do not label expanded block units as exact Survival cost.
• Test controller- and joint-heavy creations in game after parsing.