Type Alias SystemDataWarning

SystemDataWarning:
    | { kind: "missing-position" } & ReturnType<
        typeof findBodiesWithoutExplicitPosition,
    >[number]
    | { kind: "unrecognized-type" } & ReturnType<
        typeof findBodiesWithUnrecognizedType,
    >[number]
    | { kind: "unknown-parent" } & ReturnType<
        typeof findBodiesWithUnknownParent,
    >[number]
    | { kind: "parent-cycle" } & ReturnType<typeof findParentCycles>[number]
    | { kind: "invalid-orbit" } & ReturnType<typeof findInvalidOrbits>[number]
    | { kind: "invalid-radius" } & ReturnType<
        typeof findBodiesWithInvalidRadius,
    >[number]
    | { kind: "periapsis-inside-parent" } & ReturnType<
        typeof findOrbitsInsideParent,
    >[number]
    | { kind: "embedded-in-parent" } & ReturnType<
        typeof findBodiesInsideParent,
    >[number]
    | { kind: "embedded-in-sibling" } & ReturnType<
        typeof findBodiesInsideSiblings,
    >[number]
    | { kind: "invalid-ring" } & ReturnType<typeof findInvalidRings>[number]
    | { kind: "invalid-belt" } & ReturnType<typeof findInvalidBelts>[number]

Every warning kind validateSystemData can produce, tagged with kind so a consumer (a host app's dev overlay, a unit test) can filter/group without importing each individual finder's own type. Some are data- contract checks (would this body's location/type only "work" because of a silent default? does its parent chain, orbit or radius even make sense?); some are rendering-legibility checks (is this body's real, correct position going to render occluded inside another body?); two check that ring bands and belts can be drawn as described — see each finder's own doc comment (dataContractWarnings.ts, embeddedBodyWarnings.ts, rings.ts, belts.ts).

Type Alias SystemDataWarning

Settings