tbmcplugins.github.io/Block Logic blueprints

(copied from discord)
Building blocks of code

Many of these ideas [from before this excerpt] share core functions, and could themselves be products of a few more universal plugins.

The first one [of these universeal plugins], I'm gonna call BLOCK LOGIC

      - a plugin granting in-game users the ability to specify arguments in a block's data. 
      These are, in a sense, stored "block commands" with a syntax  similar to player commands.

            - each block has an array or "tree" of one or more event listeners, with subsequent 
            arguments specifying what to do on-event.

            - next, an ordered list of conditions to check for on-event. Are there such-and-such blocks adjacent
            to this one? Are there certain contents inside this block's inventory, arranged a certain way? Mobs or mob events nearby?
            Redstone signals of X strength from Y direction?

            - these conditions can then each lead to their own further tree of check-for conditions, or lead directly to an action, or
            return false, at which point the logic executor backtracks to test the next condition in the list

      Block "classes" are defined by players in-game (and passed to config) or edited directly into Block Logic's config file. 
      These classes are named, and then individual blocks need only store the name of their class.

      So, on-event, the plugin checks all classes for listeners to that event, then finds all loaded blocks tagged with that class.

      (To minimize hardware impact we can possibly specify how many blocks can be evaluated at once,
      or specify a cooldown before certain events may be "listened to" again)



we have a GLOBAL EVENT LISTENER, which, on-event, calls up all classes tagged to act on that event

a LOGIC PARSER that evaluates each called class's logic tree

a CONDITION LIBRARY defining all conditions and condition-evaluating procedures, which the Parser will reference. 
      Table of Contents listing all conditions by Name
      the coded conditions themselves, called by those names
            with accompanying code describing how to evaluate each condition, returning True or False to the logic parser

Finally we have a BLOCK ACTION LIBRARY, defining all actions a block can take.






All of this code can be built piece by piece in manageable segments, starting with the framework then adding to the LIBRARIES over time
:D