Registry sync and vanilla clients
Status: Implemented for blocks and items: mod content is vanilla-backed, so vanilla 26.3 clients (and Celestial clients without the mod) can join a modded server and see the base blocks and items. Fallbacks for other content types (entities, block entities, menus, particles, effects), per-state remapping and the
vanilla_clientsmanifest switch are Planned.
A Celestial server with CLight mods can let unmodified players join, the way Paper-style servers work. This page explains which content reaches vanilla clients and how mod blocks and items look to them.
What a vanilla client receives
| Content | Reaches vanilla clients? | Why |
|---|---|---|
| Data-pack registries: enchantments, damage types, paintings, jukebox songs, trims, banner patterns, variants | Yes, as-is | Vanilla syncs them in the configuration phase |
| Recipes, loot, advancements, tags, functions | Yes | Server-side data; tags are synced by vanilla |
| Commands | Yes | The command tree is sent per player, with vanilla argument types |
| Text, titles, sounds (vanilla sound events), container menus | Yes | Vanilla packets |
| Mod blocks and items | As their base | See below |
| Mod sounds, textures and models | Only with the mod’s resource pack | The server sends sounds by id; a client without the pack has no sound for it |
Mod blocks and items
There is no separate remapping step: mod content is vanilla content in the world.
| Content | Field | In the world and for vanilla clients |
|---|---|---|
| Block | cl_block_desc.vanilla_fallback (else copy_properties_from, else stone) |
That block’s default state in chunk data and block updates. Celestial clients with the mod draw the mod’s model at the positions the server sends over clight:blocks. |
| Item | cl_item_desc.vanilla_fallback (else copy_from, else paper) |
That item with custom_data, item_model "<id>", item_name and max_stack_size. A vanilla client shows the base item’s look with your name, or your model when it has the mod’s resource pack. |
The server-side logic stays your mod’s: a “ruby trader” with fallback minecraft:barrel still opens your menu when right-clicked by a vanilla client, and drops what its loot table says.
Choosing good fallbacks
- Match the collision and shape. The client predicts movement against what it sees; the base block also defines the real collision today, so pick one with the shape you want.
- Match the light. A vanilla client lights the world from the base block; set a base with similar light emission if light matters.
- Match the interaction class. A block that opens a menu should fall back to a block that does too (barrel, chest), so the click feels right.
- Items: pick an item with the same use animation and stack behaviour (food for food, a tool of the right tier for a tool): the base item’s behaviour is the item’s behaviour.
Movement on mod blocks
The server simulates mod block properties (friction, speed_factor, jump_factor), and Celestial clients with the mod predict the same. A vanilla client predicts against the base block and is corrected by the server now and then, like a little lag. Pick bases close to your properties if many vanilla players will use the server.
Testing with a vanilla client
Run a local Celestial server with the mod, join with a vanilla 26.3 client (or a Celestial client without the mod), and check that the blocks, items, menus and commands behave as expected.
Planned
Fallbacks for entity types, block entities, menu types, particles and effects; per-state block remapping once blocks have states; per-connection remapping for clients without the mod; a vanilla_clients: "deny" manifest switch that refuses vanilla clients; hosting the mod’s resource pack for vanilla clients from the server.