A roadmap for the future Event System in Interactio, an in-world crafting mod for Minecraft 1.16+. Feel free to add comments of your own because I have no idea what I'm doing, feedback is appreciated.

• Event Phases
  • [ ] BEFORE: Predicates to check whether a given recipe can start
  • [ ] TICK: Events / Predicates used for ticking recipes, as well as recipes with batch crafting
  • [ ] AFTER: Events to perform after a recipe has finished crafting
• Event Types
  • Predicate (returns a boolean that determines whether to stop the recipe)
    • Example 1 - Recipe has to be done at Twilight
    • Example 2 - Recipe needs a lit campfire block
  • Event (basically just a Recipe Consumer, doesn't affect Recipe Behaviour)
    • Example Syntax - Spawn Particle
    • Tick Event - basically just Event + when it should happen
• List of Events:
  • Events:
    • interactio:particle - Spawn particles in-world
    • interactio:consume_fluids - Consume one (or multiple connected) fluid source block(s) around the recipe anchor point
    • interactio:set_block - Set a block at a certain position around the anchor
    • interactio:damage_anvil (Special case of set_block ?) Damage the anvil used in this recipe
  • Predicates:
    • interactio:time_range - Check whether recipe is crafted during a certain time frame
    • interactio:dimension - Check whether recipe is being crafted in a certain dimension
    • interactio:biome - Check whether the recipe is crafted in a certain Biome
    • interactio:weather - Check what the weather in the dimension is for the recipe
    • interactio:rule_test - Check whether the block affected by the recipe matches a rule
    • interactio:anvil_damage (Special case of rule_test?) Check whether the anvil used has at most sustained a certain amount of damage
    • interactio:logic - might be multiple types, used for AND, OR, NOT, XOR , etc.
• Full Example Recipe:
• Thoughts on structure
  • We could maybe use codecs? This system is largely inspired by rule tests, which have a dynamic registry for rule test types (the event types listed above) and are handled using Codecs, which the type provides
  • Since I don't like just using Map<String, Whatever> (not to mention those aren't particularly thread-safe), should the Event Types and such maybe be stored in a Vanilla or Forge Registry?
  • As shown in the example, since the JSON structure would likely be quite generic, I am considering even moving the recipe serialisers to Codecs, and / or having just a single base serialiser structure that individual recipe types could then add on to further