51 lines
2.4 KiB
Plaintext
51 lines
2.4 KiB
Plaintext
|
|
(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
|
|
|