FicsIt-Networks
FicsIt-Networks copied to clipboard
Panakotta00
Feature Request: Modes for splitters and mergers
It would be a really handy feature to have some kind of ability to switch modes on the splitters and mergers to allow items through from a specific input or to a specific output without having to explicitly handle the item transfer in the code. For example you could call
splitterFoo:setMode(1)
which would put the splitter into "vanilla" mode where it would act just like a vanilla splitter then you could call something like:
splitterFoo:setOutput(0, false) which would "turn off" the 0 output allowing items through output 1 and 2 but not 0. All of this could be happening without having to explicitly handle each item.
Would this be something anyone else would find useful? Right now we have a lot of control over the splitters and mergers but many times I find myself not needing or wanting that much control. Instead, many times I really need to just control which output the splitter uses.
For me also. It's rare that I need an item level control. Right now I feel like I'm using to many computer ticks to transfer individual items. I wouldn't mind being able to just set ratios or tell it that the next N items need to be diverted to the output buffer.
I find the best solution would be to be able to enable and disable specific in and outputs for constant item throughput (maybe with configurable rate ?) but also be able to manual transfer single items (like it is now). I also rarely need control over every single item, but i need it in some cases (My sorting and item routing system for example receives orders which include the exact item count).
You can do all that in user code and in fact, the proper place for it is in user code. That is to say, what you asked for is all user code related, not low-level functionality related. The basic set of required low level functions to do what you want exist it just remains for you to actually write the user code to do it. You have raw control over the item transfers, build your code library up so you have the functions/systems you want. It didn't take me long to write a simple class that handles a block of an arbitrary number of mergers as a single unit to fetch X number of Y items. My use case is central-storage transferring to train platforms where the train itself tells the system what to load in each cargo wagon (station platform) so it's all directed from any start point (storage) to any end point (platform).
You can do all that in user code and in fact, the proper place for it is in user code. That is to say, what you asked for is all user code related, not low-level functionality related.
The issue is performance.
Handling transfers at the item level can be expensive on performance if handled in user code. The code has to go through a translation layer before it runs, which can be an expensive task on low end Gaming PCs.
Considering the simplicity of this feature request and the impact on performance, I don't see your justification for "proper place" and I don't see why this shouldn't be added.
The issue is performance.
That's actually the main reason I even consider to implement this. Ease of use indeed is not, as there is much other stuff people would say that it makes life easier. Prominent example is the lack of a buffered file I/O. Because the intention is to have this stuff in "user space" through an Lua OS. But signals are indeed quite heavy, a lot less heavy than calling a reflected function (not in a polling context even), but handling that still might be heavy depending on the amount of splitters you want to manage. A single splitter is easy to handle, and some more too 900 items/min are 15 items/s which is easy for the lua runtime as it runs with, i think, 1000 lua instructions per frame. Execution is parallel to other factory works (not rendering tho), so on a multi core system (like every system out there) you should be handle many more than just 1 splitter... but if we think of SF scale... not enough performance xD
