mmmPI wrote: Sun Jan 19, 2025 1:05 pm
raven2cz wrote: Mon Jan 06, 2025 5:50 pm
From my perspective, it’s a system without feedback, and such a system will never function properly.
I disagree with this from your original post, as i said it's not the case that such system lack feedback or can't function properly.
I agree with that. It's not clear why you (@raven2cz) insist on implementing a train concept that doesn't work out in the end. The concepts that have been shown, for example by me, simply don't have the flaws you claim they have. I don't understand what you mean with these flaws, because I don't encounter them. The system you took over from Hares is kind of a toy (sorry Hares), because it's inherent low throughput and big rail footprint. It isn't able to handle high throughput with single stations. If you are satisfied with that, you haven't really exhausted the train system. It's much more capable than that. Keep in mind: the one single important goal for trains is throughput.
The system I outlined with the concept the game engine directly supports is:
- simple
- efficient
- maximum throughput
- error resistant
- scalable
- easy to manage
Let me explain (again), why it is like this:
It's
simple, because it works without circuits.
It's
efficient, because it has a minimum amount of buffering (buffer chests just needed for unloading stations), uses all available space (all stations are occupied with a train all the time, so no space wasted) and has a very low latency, since stations are empty only for a few seconds until they continue to load or unload a train. Instead of keeping a loading station empty until the buffer chests contain enough to fill a train and then call a train, you can just call the train immediately and load the train directly. You save the transfer time from buffer to train, and you save the space where the empty train has to waits before it is allowed to proceed.
It's
maximum throughput, because full trains are waiting in front of unloading stations all the time, so an unloading station that becomes empty only has a few seconds (5-10) until the next train arrives. You're able to continuously unload with blue, even with green belts and never see the station run empty.
It's
error resistant, because trains that somehow got mixed content isn't being sent to a loading station but instead to all the unloading stations that unloads the content from that train. Trains with undeliverable content end up in the depot, where you see it and can take manual action. You can even automate an action by emptying the train into active provider chests and let the logistic network of the base consume what it got. Only recommended for small leftover cargo.
It's
scalable, because if the ever growing factory needs more material, and there are not enough loading stations any more to satisfy demand, you see this with the waiting areas in front of the unloading stations. If there are no trains of a certain material in the waiting area, there is a lack of that material and you need to build more loading stations. With every loading station, you also add a certain amount of additional trains.
It's
easy to manage, because you set it up once, then just occasionally add a station and trains. All the stations are built independently from each other, no circuit wires. The only communication between stations is the train limit and the priority.
If an implementation isn't like I wrote, it isn't implemented properly and you need to improve it. Interrupts can be tricky.
For now, I disagree with your opinion. As I said, there are plenty of systems with interrupts, but without proper error handling, it will fall apart. Most commonly, you'll notice a flaw in your system when you add another consumer (or two) and then increase, for instance, research to create higher consumption. That’s a pretty good stress test.