What?
- train-interrupt-spoilable.png (26.45 KiB) Viewed 226 times
It should be also possible to select circuit parameter, therefore the selection box.
Why?
The idea behind train item parameter concept is to have generic trains that can transport any kind of items.But the limits of the interrupt system get exhausted if the network should also transport spoilable items.
There is no clean way of handling spoilable items; neither the spoilability nor the spoil time can be dynamically determined.
The problem
Generally speaking, one does not want to send off trains half loaded half empty, since this is both inefficient and also creates avoidable traffic unnecessarily blocking the rail lines.This works well, till spoiling entities came into play.
For spoiling entities, you don't want to wait too long. If the production hangs, you don't want the items in the train to spoil.
You want to send off trains, even if they might not be full.
If something spoils, you need to react better. For example, when not researching with Gleba science on Nauvis for hours, but a science pack got stuck in an inserter hand above the rails, the science will spoil. When you continue requesting it, this single spoiled science gets placed into the train with no possibility to completely fill the waggon. The train will deadlock till the next science packs spoil, and if you dispose spoiled packs before loading into the train, it will deadlock for ever.
Solution options
While the train layout might be the same, the requirements for spoiling and non-spoiling items differ.Workarounds exist, but I found no clean way to manage them except for splitting the system in spoilable and non-spoilable generic trains.
One might also want to differentiate between quickly and slowly spoiling items. For items spoiling in 4 minutes a 20 seconds wait might be the absolute maximum, while for items spoiling in 2 hours a 5 minutes wait might be acceptable.
This can split up the network even further, making handling of spoilable items in generic trains practically impossible.
This leads us to two possible approaches:
- While it is technically possible to dynamically determine the cargo type by counting the cargo items, this requires setting 3x rules for every spoilable item type that is intended to be ever transported. Changing the schedule wait conditions? Change 2x the number of item types the train can transport. This is not only inefficient, but also unmanageable.
- A constant combinator indicating by a signal that the provided items are spoilable and also the spoil time by the value of the signal. Since there is no "get spoil time" option on the selector combinator, no "spoil time of" variable in blueprint parametrisation (or similar), one needs to enter the spoil time each time manually, being a boring and error-prone solution.
This could be easily circumvented if also introducing a spoil time wait condition:
- train-interrupt-spoilable-2.png (5.82 KiB) Viewed 226 times
The returned value could be eg. the spoil time in seconds, (i don't know if the spoil time can be less than a second, probably round it up if it is less than one), and 0 for non-spoilable items.
Final thoughts
Spoilage is not always unwanted.Having generic spoilage detection could help in most situations, while leading to undesired behaviour in some specific situations.
Eg. the copper and iron bacterias are spoilable, but there is no hurry to deliver them before they spoil - it can be actually better to wait with the delivery till they get spoiled.
These are edge cases that could be solved by introducing some new engine level (or possibly mod-level) functionality (I don't know the modding interface), but I don't think that would be worth the code complexity, unless some mods introduce heavy use of similar mechanics.