Open kylerhenry opened 2 years ago
UnknownSerhan
commented
2 years ago Just use 5 chemical washers and 5 crystallizer, and cap the speed upgrades of the dissolution chamber on 5 so it never breaks.
Second thing you can do is 10 chemical washers and 10 chemical crystallizers with a max dissolution chamber.
kylerhenry
commented
2 years ago Just use 5 chemical washers and 5 crystallizer, and cap the speed upgrades of the dissolution chamber on 5 so it never breaks.
Second thing you can do is 10 chemical washers and 10 chemical crystallizers with a max dissolution chamber.
Yeah this works, but you lose efficiency on the washers (1 washer can feed 20 crystallizers at max). The point of this request is to avoid that.
Describe the feature you'd like
Issue: There is a logistical issue with many of the mekanism machines that use gases or fluids in which the said gas or fluid is evenly distributed among machines attached to the same tube/pipe. While this behavior is sometimes desired, there are many cases in which this leads to a small amount of material being left in each machine (see chemical crystalizer) that prevents further automation when a different fluid/gas is required. Currently, the two solutions to this problem are to create multiple processing lines for each unique material, or to manually empty the machines with a guage dropper.
Proposed solution: Add a button to machines that accept gases/fluids as an input to a recipe, which prevents any gas/fluid from entering the machine's internal inventory until the amount of that gas/fluid is a multiple of the amount required for the output recipe (input available mod(required amount)). This would essentially turn the input mode from a "streaming" approach to a "packet" approach.
Issue with proposal: Machines would have to gather state information from the connected pipe network to see how much material is available. This could lead to a race condition, where multiple machines allow input at the same time and the pipe begins transfer to all machines simultaneously, leading back to the same problem. An I/O manager would have to added, which is unique to each pipe network, that prevents this race condition by only outputting to one machine at a time; or alternatively, setting a unique buffer available to each connected machine.
Describe alternatives you've considered
1) This logic could be done on the pipe side. However, this would require the pipes to gather state information of each connected machine on the output, which could result in significant real-life processing overhead. Additionally, from an architectural point of view, having pipes be the decider of whether they themselves are in "streaming mode" or "packet mode" doesn't follow usual design principles, and would prevent other machines on the same pipe network from being in streaming/packet mode when desired.
2) A new type of pipe, called a "limiter" or a "packet provider", that transfers in discrete packets. Arguably this would be the simplest implementation, but could result in a similar issue when other pipe types are involved in the network. For example, if a gas is transferred first on a traditional pipe, which is then connected to a limiter pipe, each limiter would "allow" transfer simultaneously, creating another race condition.
Additional context
I think the above is detailed enough.