Following from the discussions about Map Editor, the new Infinity Mode mod, etc, I have been thinking about what new 'infinity' entities would be most useful.
Ideas like an infinity wagon could have their uses. However in my view there is one entity which would surpass those in usefulness, and would be a major boon to individual design testing:
Modify the existing Infinity Chest such that it can accept a circuit signal which, when received, triggers its "refresh" action.
When so configured, the infinity chest would not automatically refresh/remove its contents every tick, but only when the specified signal is received.
Ideally: also allow this trigger to be passed via Lua API, allowing modded use of this trigger without the mod needing to create a circuit network and pass a circuit signal.
Providing the ability to control when the infinity chest's refresh action is triggered will allow for more easily replicating and testing designs without requiring additional infrastructure, for example trains.
Example: I am testing bot-based smelting setups. Ore is brought in by a loading train, and plates are removed by an unloading train. The frequency of train arrival can impact on the throughput of the bot setup. Therefore I have implemented real trains, on a loop:
- ore unloading train pulls into the station full of ore; unloads into passive providers; leaves, and goes to another station which uses Infinity Chests to reload that ore. Then it loops back to the start.
- plate loading train comes in empty, is loaded with plates via requester chests, then goes to an unloading station which trashes that ore by unloading into Infinity Chests set to "Remove unfiltered items".
With my proposed ability to trigger the refresh action of an infinity chest, I could test these designs without requiring this real train infrastructure. And it would make it a lot easier to test various permutations of simulated train throughput.
- I would replicate the cargo wagons using infinity chests.
- On the ore unloading side, each wagon would be represented by 12 infinity chests; 11 set to provide 166 ore, the 12th, 167 (= a total of 2000 ore, 40 slots worth).
- On the plate loading side, again I would have 12 infinity chests, each set to "remove unfiltered contents".
- I would then monitor the contents of the loading/unloading infinity chests in a circuit:
- On the ore unloading side, I would monitor all the chests, waiting until all have a contents of 0. At that point, the simulated ore unloading train is empty.
- On the plate loading side, I would monitor each set of 12 chests, waiting for their combined total to be 4000 plates. Once all sets of 12 wagons had 4000 plates in, the simulated plate loading train is full.
- Once these conditions are met, my circuit would then wait a certain number of ticks - simulating the time it takes for the existing train to leave, and a new one to arrive - and then fire the "reset" signal to all infinity chests. This would be done separately for loading vs unloading, ie allowing the 'loading train' to finish and leave before a new 'unloading train' arrives.
With this relatively simple setup, I could replicate any train throughput I like, including simulating long delays before new trains arrive, or two trains arriving back to back. I would need to do some real-world testing first to see the appropriate timings, but once I had that data, I could program my circuit with the appropriate timings to replicate any situation.
I believe this relatively simple change to the infinity chest would allow for much more sophisticated testing, and could reduce the need for special-use entities such as an infinity wagon.