Right now, positioning of immersives is done all in code. However, it would make sense to do it in JSON, as it's all pretty much static data. For rendering, it would be a resource pack, while for the data-driven parts, it's part of a data pack.

It's also very likely worth making a GUI builder for it. Although this would ideally be done in-game, it would be far easier to maintain as a web app. Would be opened as a separate issue if I pursue it.

Note that this wouldn't support all immersives, only ones where everything is slot driven (not enchanting tables or beacons, for example).

Note that in terms of rendering priority, we can use the built-in resource pack system, with ImmersiveMC being lowest priority. Conditions are checked highest to lowest priority, and the first match handles it entirely.

Example Data JSON Format (for the furnace/smoker/blast furnace)

{
    "conditions": [
        {
            "type": "block_entity",
            "block": "minecraft:furnace",
            "classes_up": 1
        }
    ],
    "immersive_type": {
        "type": "container"
    }
    "slots": [
        "0": {
            "slot_type": "input"
        },
        "1": {
            "slot_type": "input"
            "place_stacks": false
        },
        "2": {
           "slot_type": "output"
        }
    ],
    "output_callback": "com.example.some_mod.SomeClass#handleFurnaceXP",
    "default_render": `Rendering JSON Format Here`
}

Some explanations:

• conditions holds the list of conditions that must be met for the looked at block to contain this immersive.
  • type: Can either be block_entity or block.
  • block: The block to reference for the condition.
  • classes_up: Must be specified for block_entity, and specifies the number of class to traverse up from the block entity attached to block. In the example's case, we would look at the class of the block entity attached to furnace (FurnaceBlockEntity), then go up 1 to its superclass (AbstractFurnaceBlockEntity). This means any block that has a block entity that is an instance of AbstractFurnaceBlockEntity matches this condition. If this key is specified for a type of block, then we perform the same on that block's class. If not specified, we use the literal block ID instead.
• immersive_type specifies the type of immersive
  • type: Can either be container or world. If it's container, we simply store items using vanilla container methods. If it's world, this means we use ImmersiveMC's storage system.
  • slot_count: Specifies how many slots this immersive should hold. Only used for world type.
  • on_item_change: Function (see format for output_callback for how to specify this) that's run when an item is placed or removed from the immersive. Should be used for handling both input and output. Takes a List<ItemStack> representing the stack contents and a Player that is performing the crafting. The function's return type is void, however mutations to the list of items should affect the underlying storage. For world type only.
  • tick: Function that should run every tick client-side for potential updates to the immersive. Takes the same parameters as on_item_change, is only for world type, and is optional.
• slots specifies how each slot should behave. Below is the breakdown for any slot
  • slot_type: Can be "input", "output", or "storage".
  • place_stacks: Whether to place an entire stack by default on input.
• output_callback A name to a public static void function that takes an ItemStack and a Player. This should handle any extra things that happen AFTER the given ItemStack is given to the player.
• default_render: A default rendering to use if the client doesn't have one (such as a datapack stored with the world with a client joining without a resource pack). Follows the Rendering JSON Format below.

Example Rendering JSON Format:

TODO. This one is fun, especially because we should be able to handle things as complex as Shulker Boxes, where the orientation of both the player and Shulker Box matter. Also, light positions are important here, too!

At least for now, definitely scrapping the JSON system. Going with the ImmersiveBuilder system I added in 1.5.0 Alpha 1.

Removing this from 1.4.0. This is far too big of a change to do for 1.4.0 when it's already running a bit behind.

A request that honestly seems really useful and great to add is rotation for the slots themselves

Need to do some rethinking here. Allowing the datapack to call functions is horrible for security (the server can just send clients a malicious datapack), so this needs to effectively be redone.

That said, by limiting code in this way, a lot of flexibility gets removed that makes this system not that useful. May scrap the JSON system and just implement the API in #273

Re-opening. Obviously, we can't let code calls be made (what was I thinking?!), but adding a flexible system that gets close to ImmersiveBuilder-like functionality I think is the key here. Especially once #273, we should be in a really great state to add this.

Everything would be done in datapack, no resource pack.

Also, resource packs. We can grab the constants that we use from the resource pack.