MultiBlock

# Feature Overview
Kind: MultiBlock
Extendable: no
JSON based: no
JSON config: yes

"MultiBlock" is an additional data compound a FVTM Block can hold.
It contains data for the Block to be functional.
And as the name states, it allows you to place compounds of Blocks!

As usual a few examples can be found at GEP.

Here are some fields you can or should fill out in the "MultiBlock"
Json Object entry of the Block config:

• Inventories - optional, json object, to define inventories in the block compound
  available types as of now are item, fluid and energy (not implemented),
  you can define them as follows:
  "inv_id": "type-capacity" or "inv_id": "type-capacity-optional_data"
  for example (taken from GEP Smeltery):

  "Inventories":{
      "input": "item-9",
      "tank": "fluid-128000-lava",
      "output": "item-27"
  },

  • the element id will be the inventory id, must be an unique id in this block
  • the first part of the value is the inventory type
  • the second part of the value is the capacity (note that fluids are 1000mB = 1 bucket)
  • the third part is optional, in case of fluids it is the accepted fluid id
    and in case of items, it's a ContentFilter ID,
  • remember the value separator is a hyphen (-)
• Blocks, required, json array, a list of the blocks this multiblock compound
  is composed of. Example from GEP Smeltery:

  "Blocks":[
      [ "gep:smeltery_tank", 0, 0, 2 ], 
      [ "gep:smeltery_body", -1, 0, -1 ],
      [ "gep:smeltery_tank", -1, 0, 0 ],
      [ "gep:smeltery_core", 0, 0, 0 ],
      [ "..." ]
  ],

  • the first entry in the array is the block-id/regname, should be a block of the
    MULTIBLOCK type of FVTM, any other can cause unexpected behavior
  • the second, third and forth entry is the x/y/z position relative to the center
    the center being at 0, 0, 0, please note you also have to specify the multiblock in question at position 0, 0, 0 in that array
  • the fifth entry is optional, it is the "facing" of the to be placed block
    it can be either of north, south, east, west
  • it is advised sub-blocks to be own configured blocks of the multiblock type
    but no "MultiBlock" config entry, remember to add "MultiSubBlock": true
    if it's expected to have a TileEntity though!
  • on that note, yes, sub blocks do not need to have tile entities at all,
    and unless specified as such they will not have them
  • if you want a sub-block to have an accessible inventory by pipes,
    it does need a TileEntity
  • the core block always has a TileEntity, this cannot be changed
• Triggers - optional, json array, a list of "triggers" to tell the block
  what to do when a player interacts with it, you can either open an inventory
  or redirect it as specific call into the BlockScript (if the multiblock
  has one assigned). Example:

  "Triggers":[
      {
          "block": [ -1, 1, 1 ],
          "hitbox": "NORTH",
          "target": "open",
          "type": "script"
      },
      {
          "block": [ 0, 0, 2 ],
          "target": "output",
          "type": "inventory"
      }
  ],

  • the block array is the block position relative to the core, as specified
    in Blocks earlier, FVTM handles placing rotations automatically
  • hitbox is optional, if missing the whole block is regarded as trigger, otherwise only the specific side, this imples the configured block is facing
    NORTH and the facing is to be setup relative to that, FVTM handles ingame rotation
  • type - type of the trigger, valid are inventory or script, inventory
    type trigger will open an inventory, the script one will call the script (if any)
  • target - if the type is inventory - the inventory with that ID is opened (GUI)
    if the type is script the call is redirected to the script with this value
• Access, optional, json array, similar as trigger, but for inter-mod access
  (e.g. pipes, hoppers, forge capabilities and so on), Example:

  "Access":[
      {
          "block": [ 0, 0, 2 ],
          "target": "output"
      },
      {
          "block": [ 0, 0, -1 ],
          "side": "SOUTH",
          "target": "tank"
      }
  ]

  • block is the same as for triggers
  • side almost like hitbox for triggers, but accepts only side values
    (aka north, west, south, east, up, down), if left out
    this "access" is counted as whole-block (all sides)
  • target the id of the inventory to be accessed
• Script - optional, class adress of the Script (class extending BlockScript)
  for this multiblock, default implementations for general use are available:
  • CraftBlockScript - to create basic and advanced automatic machines
  • //TODO
• ScriptData - optional/depends on script, custom json data to be passed to
  the script, may differ on script, not always same, not always required possibly.
• Tickable - optional, default false, if this multiblock compound should have a
  tickable core TileEntity, beware every such core block will tick every server tick.