Block Logic blueprints
a plan listing all the necessary components to create Block Logic
This commit is contained in:
parent
84e7716a00
commit
840745092c
1 changed files with 48 additions and 0 deletions
48
Block Logic blueprints
Normal file
48
Block Logic blueprints
Normal file
|
@ -0,0 +1,48 @@
|
|||
|
||||
Building blocks of code
|
||||
|
||||
Many of these ideas share core functions, and could themselves be products of a few more universal plugins.
|
||||
|
||||
The first one, 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 class has an array or "tree" of one or more event listener tags, 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)
|
||||
|
||||
BUILDING BLOCKS FOR THIS CODE:
|
||||
|
||||
a GLOBAL EVENT LISTENER, which calls up all classes tagged to act on an event (from an INDEX OF BLOCK-ACTIONABLE EVENTS)
|
||||
|
||||
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
|
||||
with accompanying code describing how to evaluate each condition, returning True or False
|
||||
|
||||
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
|
||||
:D
|
Loading…
Reference in a new issue