Belt neighbours
Posted: Sun Jun 16, 2019 7:27 pm
Neighbours method for all four types of transport belts
What I mean by this:
Check if the current entity can actually output into the forward entity
Check if the neighbour entity can properly input into this (ie: no pushing into the hood of a belt-to-ground or side of a splitter)
It doesn't have to be whether both input lines can reach, just if at least one can input/output.
It should return a table of either inputs and outputs, or all entities with some sort of indicator of whether each entity is an input or output to the current entity.
If possible, the ability to call neighbours.input or neighbours.output individually to only receive those specific tables without running the entire neighbours method and getting both tables.
A use example would be
For entity type transport-belt or belt-to-ground
The table property input gives an array of up to three entity references, or an empty table
For these two types, it's only possible to output to a single entity, so either an array with a single entry (for similar functionality as the splitter), or a singular entity reference, much like the current neighbours method behaves on a belt to ground.
With splitters, there's only two outputs and/or two inputs.
The table property input gives an array of up to two entity references, or an empty table
The table property output gives an array of up to two entity references, or an empty table
The loader type would return the input and output like any of the above, with one being the entity its dropping items into or extracting items from, and the belt it's pushing to/from.
The biggest thing here is that these types of entities are very different from pipes and anything with fluidboxes. It simply cannot act the same.
- splitters
- transport-belt
- belt-to-ground
- loaders
What I mean by this:
Check if the current entity can actually output into the forward entity
Check if the neighbour entity can properly input into this (ie: no pushing into the hood of a belt-to-ground or side of a splitter)
It doesn't have to be whether both input lines can reach, just if at least one can input/output.
It should return a table of either inputs and outputs, or all entities with some sort of indicator of whether each entity is an input or output to the current entity.
If possible, the ability to call neighbours.input or neighbours.output individually to only receive those specific tables without running the entire neighbours method and getting both tables.
A use example would be
Code: Select all
entity.neighbours ->
{
input = {}
output = {}
}
The table property input gives an array of up to three entity references, or an empty table
Code: Select all
neighbours.input ->
{
LuaEntity,
LuaEntity,
LuaEntity
}Code: Select all
neighbours.output ->
LuaEntity
or
{
LuaEntity
} The table property input gives an array of up to two entity references, or an empty table
Code: Select all
neighbours.input ->
{
LuaEntity,
LuaEntity
}Code: Select all
neighbours.output ->
{
LuaEntity,
LuaEntity
}
The biggest thing here is that these types of entities are very different from pipes and anything with fluidboxes. It simply cannot act the same.