Storage
-------

Storage is accommodated with two nodes, Storage Unit and Storage Indexer.
Storage units can be interacted with like a basic chest, each with 32 slots,
and visually join together when placed adjacent to each other. Units are
generally accessed via indexers, which action all adjoining units as a
single storage block. Multiple indexers can action a single storage block.

Only the owner can dig or access the form of the locked versions.

Unowned indexers can only access unowned units. Owned indexers can access
units of the same owner or unowned units.

UI
Search - top left.
List - left.
Channel - digilines channel of indexer.
Input - middle.
Output - top right.
Filter - center right.
Player inventory - lower right.

When the UI is accessed the storage is scanned, and its contents are
displayed in the list. The list contains the following columns:
Item button - pressing will place one of these items from storage into the
				  output.
10 button - pressing will place 10 of the item.
<stack> button - pressing places a full stack.
Count - the total number of this item in storage.
Description - description of the item.

Note that the 10 and stack buttons may vary in number or not appear
depending on the requirements of that item.

The form does not update while open. A request for more items than in
storage will only deliver the amount in storage.

Terms can be entered into the search field, and when enter is pressed or
the Search button is pressed, only items whose description contains these
terms are shown in the list. That is if they match any of the space
separated terms.

Any items placed into the input are placed into storage. If the filter
is clear all items are accepted. If the filter contains items only these
items will be accepted. Any items not accepted or that do not fit into
storage are placed into the output.

When items are placed into the filter a copy is used and the item returns
to where it was taken from. When items are removed from the filter they
are disposed of.

Hoppers placed to the top or sides of an indexer will feed items into the
input. Hoppers placed below an indexer will take items from the output.
Note, when a hopper from the hopper mod is used to place items into the
input, if the player that placed the hopper leaves the game the input will
not be pulled into storage.

Pipeworks tubes can push items into the input, and pull items from the
output.

Every 20 inputs the storage is consolidated to minimize fragmentation.


Digilines messages

"output <item> <count>"
or
{
	action = "output",
	item = "<item>",
	count = <count>
}
	Moves the item/s to the output. If count is omitted defaults to 1. If
	the requested amount is greater than in storage, only the stored amount
	is moved. If the requested amount is greater than a full stack of the
	item a full stack is moved.


"inventory"
	Sends a digilines message with it's own channel in the following form:
	{
		action = "inventory",
		inventory = {
			<items>
		}
	}
		The inventory key is an indexed list of items in storage. Each item
		entry is a table with the following keys:
		{
			name -- string, the name of the item, as <mod>:<name>
			description -- string, description of the item, same as in UI
			count -- number, the total number of this item in storage
			custom -- true if a custom item (has metadata), false if not
			pallet_index -- string if the item has a pallet index, otherwise nil
			id -- string, unique id of the item in storage
		}
			The description is derived from the short description, if none
			then the description, and if none then the item's name, as
			<mod>:<name>.

Note: When sending output messages the simple item name, as <mod>:<name>,
will work for most items, but not for custom items. With custom items, or
to play it safe, use the table form of the output message and set the item
field with the id field for the item from a returned inventory.
