import { creative_groups, creativeitems } from './generated/creativeitems';
export type { CreativeGroupEntry, CreativeItemEntry } from './generated/creativeitems';
/** One item as the item table names it. */
export interface ItemTypeEntry {
    /** The numeric id the client will know this name by. Negative for a block's item form. */
    runtime_id: number;
    /** Whether the item is defined by components rather than being one the client already knows. */
    component_based: boolean;
    /**
     * `Item Version` as `ItemRegistryPacket` carries it: 0 `Legacy`, 1 `DataDriven`, 2 `None`.
     *
     * A `DataDriven` item is one the client builds from {@link item_components}; a Bedrock
     * Dedicated Server sends 31 vanilla items that way (the bundles, the spears, the trial keys,
     * the apple). Most vanilla items are `None`, including 44 that are `component_based` and
     * still travel with an empty compound, such as the arrow, the cake and the music discs.
     */
    version: number;
}
/**
 * The item table: every name the client can be told about, and the number it travels as.
 *
 * The authority on the mapping - the client builds its registry from what we send, so
 * everything naming an item has to agree with this one file.
 *
 * Captured from a Bedrock Dedicated Server 1.26.51.1, not taken from a third party: the
 * server sends it as `ItemRegistryPacket`, so a client that can log in can simply record it.
 * `packages/client/tools/capture-server-data.mjs` is that client, and its output is
 * `jsp/required_item_list.json`. It stays under `jsp/` rather than moving to `resources/`
 * because a capture of the version this server targets is the thing nothing else can promise.
 *
 * The capture records no `version`. `utils/build.js` takes that one column from the
 * submodule's `runtime_item_states.json`, a dump of 1.26.50 at the same protocol, and refuses
 * to generate the table unless the two agree on every name, id and component flag. They do.
 *
 * The version matters more than it looks. Against the 1.21.40 table this has 240 names it did
 * not, and - the part that breaks quietly - **528 items whose number changed**. A server on
 * the old table does not fail; it puts the wrong number on the wire for a quarter of the
 * items it knows, and the client shows something else.
 */
export declare const item_table: Record<string, ItemTypeEntry>;
/**
 * Item name to its `Item Component Data`, as network NBT, for every item that has any.
 *
 * A Bedrock Dedicated Server sends 78 vanilla items with a non-empty compound: the 31
 * `DataDriven` entries of {@link item_table}, which the client cannot build without one, and
 * 47 foods that are not `component_based` yet carry their `minecraft:food` values anyway. Every
 * other item travels with the empty compound, and is absent here.
 *
 * From the submodule's `item_components.nbt`, a dump of 1.26.50 at the same protocol as the
 * item table. `utils/build.js` converts each item's compound from the on-disk NBT flavor to the
 * network one tag by tag, so a server writes the bytes to the wire as they are.
 */
export declare const item_components: Readonly<Record<string, Buffer>>;
/**
 * Item name to numeric id.
 *
 * Derived from {@link item_table} rather than kept by hand. The hand-written file this
 * replaced had 807 entries and predated the flattening: it knew `minecraft:planks` but not
 * `minecraft:oak_planks`, so it could name only 53% of the creative menu and none of the
 * rest. Anything it could not name fell back to an unrelated internal id, which is how half
 * the creative menu came to be duplicates of the wrong item.
 */
export declare const item_id_map: Record<string, number>;
/** A vanilla block the client only knows if the server declares it. */
export interface BlockDefinitionEntry {
    name: string;
    /** The definition as network NBT, exactly as a Bedrock Dedicated Server sends it. */
    definition: Buffer;
}
/**
 * The data driven vanilla blocks, and the definitions a client needs to draw them.
 *
 * Since 1.26.50 vanilla defines some of its own blocks in data rather than in the client -
 * the wool stairs and slabs, the concrete slabs - and a server has to declare them in
 * `StartGamePacket` the way it would a plugin's. Captured from the same server as the item
 * table, by the same tool; each definition is handed back to the wire verbatim.
 */
export declare const block_definitions: readonly BlockDefinitionEntry[];
export { creative_groups, creativeitems };
/**
 * Tag name to the items carrying it.
 *
 * A recipe may ask for "any plank" rather than name the thirteen, and this is the only place
 * that question has an answer. Typed by the question rather than by the file: a caller asks
 * about a tag name a recipe gave it, which is a string and not one of the 77 keys the JSON
 * happens to hold.
 */
export declare const item_tags: Readonly<Record<string, readonly string[]>>;
/**
 * Every actor type a client may be asked to render, as `AvailableActorIdentifiersPacket`
 * carries it: one network NBT compound holding an `idlist`, replayed verbatim.
 */
export declare const entity_identifiers: Buffer;
/**
 * The jigsaw structure rules, as `JigsawStructureDataPacket` carries them: one network NBT
 * compound, the payload of the packet a Bedrock Dedicated Server 1.26.51.1 sent. A client at
 * protocol 2193 refuses to join a server that has not sent this before `StartGamePacket`.
 */
export declare const jigsaw_structure_data: Buffer;
/**
 * The vanilla biome definitions, as `BiomeDefinitionListPacket` carries them at protocol 2193:
 * the whole payload of the packet a Bedrock Dedicated Server 1.26.51.1 sends, replayed verbatim.
 *
 * At 1.26.x the packet became a map of biome data plus a shared string table the entries index
 * into. An empty one is no longer enough - a client reaches the world-generation screen with no
 * biomes and gives up - so a server that generates any world has to send the real thing.
 */
export declare const biome_definitions_network: Buffer;
//# sourceMappingURL=index.d.ts.map