Machine Inventory Manager

The Machine Inventory Manager is a tile entity added by Steve's Factory Manager. This block controls the use of every other block in this mod by use of commands. Each command has a different function but can be divided into a few main categories: Condition, Group and Trigger, Input and Output, and Others.

Commands
There are many commands the player can use in the Machine Inventory Manager. It is highly suggested that the player check the user preferences and adjust them to their liking. Above the user preferences in the GUI is a delete command to remove unwanted commands.

The standard command is usually comprised of these elements in this order:

Trigger → (Flow) → (Condition) → (Input) → (Crafting) → Output

Input is mandatory when dealing with items or liquids.

The other commands can be grouped in four categories:

Create Condition

 * One Input, Two outputs: True and False
 * Inventory: Chooses which inventory to check for condition.
 * Target: Checks designated side for the item variable. Example: To check Furnace fuel, the player must check from the side.
 * Item: Designates item variable to check for.

Create Liquid Condition

 * One Input, Two output: True and False
 * Tank: Chooses which tank to check for condition
 * Target: Checks designated side for the liquid variable. Example: To check Furnace fuel, the player must check from the side.
 * Liquid: Designates liquid variable to check for.

Create Redstone Condition

 * One Input, Two output: True and False.
 * Redstone Nodes: Chooses which block to check for redstone condition.
 * Sides: Checks designated side from which the redstone signal comes from.
 * Strength: Check designated redstone signal strength needed; can be inverted.

Trigger
Trigger commands are required as without them no functions will run. There are three different modes: On Interval, Redstone Controlled, and Block Update Detector.


 * On Interval: Interval: Perform function every X seconds, where X is an integer. Allows for a single output.
 * Redstone Controlled: Interval: Perform function every X seconds, where X is an integer
 * Redstone Receiver: Designates redstone receiver the player has selected
 * Redstone Sides: Designates side of the receiver to select; Analog Redstone: Analyze for redstone signal strength above a threshold (can be inverted).
 * Four different outputs: On Low/High Pulse/Signal, Self Explicit.
 * Block Update Detector: Interval: Perform function every X seconds, where X is an integer


 * Update Detector: Designates detector player has selected.
 * Update Sides: Designates side of updated block to be selected
 * Update Block: Designates what to look for in terms of ID and metadata.
 * Five different outputs: On Low/High Pulse/Signal, Self Explicit, and On Block Update.

Create Flow Control
There are two different modes: Collector and Split.


 * Collector
 * Any trigger inputs causes an output to occur; two or five inputs, one output.


 * Split
 * One trigger causes outputs to occur; one input, two or five outputs.

The Split mode has two sub-modes: Sequential and Split.


 * Sequential
 * Each branch from the Flow outputs are executed sequentially, as if they were a single long chain merged one after another.
 * Branches are executed from left to right. If a branch has an Input command that aren't completely fulfilled with Output commands in the same branch, the items that haven't been moved yet are still marked as eligible for moving in following branches.


 * Split
 * Each branch from the Flow outputs are executed separately, without affecting the others. Unlike in the Sequential sub-mode, items that are marked for moving in one branch are not carried over to the others.

The Split sub-mode has two options:


 * Use fair split
 * When enabled, items marked for moving before entering the split point are evenly split for each branches. Without this option, some branches may take one more item so that all the items which are marked can be potentially moved.


 * Include empty pins
 * When enabled, the amount of items marked for moving before entering the split point are divided by the number of output pins of it, regardless of whether those pins have commands or not. Without this option, items are split among only pins that actually have commands.

Create Command Group
Creates a group which is a sub page of the main page. It is helpful in keeping command trees compact and providing more space for the player to work with. It does not have any input or output commands by itself.

Create Group Node
This command has two modes: Input and Output. Input will let a trigger into the group from an external source while Output will send a trigger outside the group. This is used in conjunction with Command Group to trigger groups from an external source.

Input and Output
Input commands will take the item/liquid out of the container and place it into the system. Output commands will take the item/liquid out of the system and into the container.

Create Input/Create Output
This requires:
 * One input
 * One output
 * Inventory: Chooses which inventory to check.
 * Target: Designates which side to check.
 * Items: Selects item to take or insert.

Create Liquid Input/Create Liquid Output
This requires:
 * One input
 * One output
 * Tank: Chooses which tank to check for.
 * Target: Chooses which side to check for.
 * Liquid: Chooses liquid to take or insert.

Create Redstone Emitter
This requires:
 * One input
 * One output
 * Emitters: Chooses which emitters to emit to
 * Sides: Designates side to emit to
 * Output: Designates mode of transmission and signal strength
 * Pulse: Toggles the firing of a pulse; rate of firing is configurable

Create Auto Crafter
This requires:
 * One input
 * One output
 * Crafting: Uses a crafting grid interface where the player replicates the crafting components needed to create an item.
 * Priority: Determines if crafting happens before moving the item or after.
 * Excess Inventory: Selects inventory used in case of overflow or secondary output, items will drop in the world if the excess inventory is full.

Items are moved directly from one block inventory to another
One might think the Input command moves items from a block inventory to a temporary storage inside the Machine Inventory Manager, and the Output command moves items from the temporary storage to another block inventory. This is not actually the case. The Input command merely marks a block inventory as eligible for pulling items from, and the Output command directly moves items from such inventories to the output target. The distinction becomes important when the output target cannot accept all the items that have been pulled with the Input command. In this case only items that can be successfully moved are taken from the input source. The remaining items are left behind even if they are whitelisted in the Input command. The same goes for Liquid Inputs/Outputs.

The Flow command controls the program flow and the item/liquid flow at the same time
The Flow command may look like a control flow in the programmatical sense. That is, it can be misunderstood as only used for controlling the flow of a program. In fact it is not only that. The Flow command also controls the flow of items and liquids. Items and fluids marked for moving before entering the Flow command are split or merged at the Flow command, depending on its mode. One thing that can easily go wrong is that the Split mode is Sequential by default, i.e. Input commands in one branch from a Split node can affect Output commands in the other branches in this sub-mode.

Programs cannot have a persistent state
Unlike usual programs, does not have a state that are persistent between each invocation of the program. That is, there is no native way to save some data in one invocation and load them in later invocations. However, one can simulate persistent states by using dedicated item storages as "persistent memory":


 * Items in chests can be thought as "save data". Putting items in, or removing items from a chest can be seen as data writes. Observing items in a chest with the Condition command can be seen as data reads.
 * Alternatively, the can be used as a set of 6 boolean variables, having one boolean state for each side. This is especially useful because the state of the Redstone Emitter does not change until they are updated using the Redstone Emitter command, and the state even persists between chunk reloading and server restarts. Also note that the Redstone Condition command can read the redstone signal from not only the  but also from the Redstone Emitter, which eliminates a necessity of using receivers just to observe the state of the emitter.

Timed trigger can be overclocked with the help of an external clock source
The interval that can be set to the Trigger command is one second at minimum, which means programs can usually run at most once every one second. However, the trigger can be overclocked with a faster redstone clock, a, and a redstone-controlled Trigger with a chain of commands hooked up to its On high pulse output. But there is a caveat to this method (see below).

Programs are executed from the beginning to the end in a single game tick
When a program is triggered, the entire chain of commands are evaluated in the same game tick. This can be problematic if it is a large program consisting of hundreds of commands in total, and if the trigger is overclocked with a fast external clock. Such programs can easily cause a server lag, especially if there are many such programs in loaded chunks. In that case some lag reduction measures need to be implemented:


 * Fail early
 * Before evaluating expensive chains of commands, use some conditionals to see if it is really worth running the rest of the program, and if not abort the execution. This can reduce the commands to be evaluated in the normal case.


 * Don't overclock the trigger too much
 * Think twice before using a 1 tick clock as a trigger. If a 5 tick clock suffices, use a 5 tick clock.