Programmable splitter

[ssilk]

The many questions about splitters brought me to the idea to request a Lua interface for a splitter, which can "decide" which input item is put on which output belt AND lane.
Perhaps the abstraction can be very high, so that the most calculations could be done in C++. But in general there are in maximum only about 1500 decisions per minute (25 per second). I think this can be handled in Lua up to a high number of such splitters.

[FreeER]

I think this can be handled in Lua up to a high number of such splitters.

hm...I'm not so sure since I believe that the lua is pretty much single threaded. while it might work for those only using a single custom splitter mod, would it work equally well for people using dytech/fmod/treefarm as well? Obviously I'm trying to consider the use of many splitters in a single save, not just a few

If done slightly differently (the splitter is given the function in the prototype, not changeable in-game)...I have to wonder if it would be possible to generate a C++ function during loading of prototypes from a string passed through lua (such a string could be checked to prevent using of OS methods, etc), since the vast majority of splitters would work the same way the entire time, if so this would counter the speed loss that is 'unavoidable' with lua...
not sure how easily such could be achieved even for simple functions like: if (entity.name.equals("iron-ore")) { //put on output[0]} else {put on output[1]} (output[0/1] used so that it's not limited to just 2 outputs of left and right)....

[ssilk]

Something like that. Yes. Another useful example: if input is on lane 0 then output on belt 0 any lane, if input on lane 1 then output on belt 1 any lane. I think to something like a routing/filter, a configuration, no real Lua (or only for very limited cases, e.g. tests or so).

Or more such very specialized stuff. Just that the players, that want that now, will see, what is really working and useful and what not.

[GotLag]

My suggestion would be giving splitter-type entities a list of input and output zones (like pickup and insert positions on inserters). Each input zone has a list of which outputs it can dump items in, and each output zone has a setting telling it how to resolve congestion (give one input priority, take turns).
Using this schema, the standard splitter has four inputs (left to right, A, B, C, D) and four outputs (1, 2, 3, 4). A and C output to 1 and 3, B and D to 2 and 4, and in the event of congestion the priority is "A, B" for outputs 1 and 3, and "C, D" for outputs 2 and 4.
You could then have settings for inputs that tell them how to split items between their various outputs (even, output only to the highest-priority unless it's full), or outputs could have an option to only accept from alternating inputs.
A single-belt splitter (each side of the input belt going to a separate output belt) would simply have one input zone covering each side of the incoming belt, matched to an output zone 90° to that side, with priority being irrelevant.

My ideal would be to combine this with a GUI to make a smart splitter, that allows the player to select side priority and output distribution modes in-game, so you could for example set a splitter to send all items down one side and only use the other side as overflow, or set it to alternate its output between left and right input. Or to only take input from the left side when the right side is empty. Or even change operating mode depending on circuit network inventory.

Does that make sense to anyone else?

[ssilk]

I would let the interface completely open. This is some kind of experiment and maybe someone comes with a really new useful thing.

[robhol]

I'd like to add my support to this one, and perhaps add another idea - mine would be for a general "item flow entity" (an imagined abstract class for anything like an underground belt, a splitter, etc.) and which would just be able to process incoming items and redirect them. Obvious ideas for extensions include those, counters, sorters, switches and so on.

Lua's comparative slowness doesn't really need to be much of an issue: the Lua API can, at least for many use cases, be used to just define the rules and let the C++ engine handle the rest.

For example, instead of defining an event that lua can hook into and do the logic, you could make the 'superclass' of these entities contain a list of routing rules in entities.lua or something. More advanced rules than "lane b on belt a goes to lane y on belt x" would still require some custom logic. You could, I suppose, make a structure that supports more conditions, but for maximum support (ie. close to arbitrary rule sets), it could become quite hairy...

Of course Lua itself can be compiled, but I'm not sure how much faster that'd be. I imagine it's not a lot of performance to be gained.

[ssilk]

I would mean this is the first working example:

www.factorioforums.com/forum/viewtopic.php?f=14&t=3657