How to handl fluids at depot?

[Optera]

uid trains are set to wait until empty. But they are also set to wait only 200s. So any setup that can't unload the train fully will quickly send a train with left over fluids back to the depot. A problem for stations for multiple fluid wagons. I've had stations designed for 5 fluid wagons and buffer space for 2 million fluids send back trains because the tanks across the station where at different levels with one end of the train having full tanks.

Seems like an incentive to come up with a better fluid station design to me.
Asking for LTN to fix imbalanced fluid station problems is like asking to make mining drills aware if they clog burners with ore because some belt was placed wrong.

200s simply wasn't enough time for fluids to move from tank to tank so the last fluid wagon could be pumped empty despite plenty of space still left over in adjoining tanks. The transfer speed tank to pipe to tank is too small so I now balance tanks using circuit logic. I'm probably not the only one that runs into that problem.

Default stop timeout is 2min (7200 ticks). I never managed to have a train stuck in a station longer than that.
If it's too short for you you can change it to anything you want in options - mod settings - map - Stop timeout. Setting it to 0 will disable it. Somehow that info seems to have gone missing from the tooltip.

I noticed slight imbalances due to fluid mechanics in my oil unloading station too.
Ample buffer storage and 4 pipes with 1500l/s throughput each to the main storage make it work. As a complete rework of the fluid system is on the horizon I'm not going to do much to accommodate the current messy system. Maybe it will even round fluids in a useful manner.

2018-09-17-11-20-19-8885058.png (871.58 KiB) Viewed 3978 times

[mrvn]

uid trains are set to wait until empty. But they are also set to wait only 200s. So any setup that can't unload the train fully will quickly send a train with left over fluids back to the depot. A problem for stations for multiple fluid wagons. I've had stations designed for 5 fluid wagons and buffer space for 2 million fluids send back trains because the tanks across the station where at different levels with one end of the train having full tanks.

Seems like an incentive to come up with a better fluid station design to me.
Asking for LTN to fix imbalanced fluid station problems is like asking to make mining drills aware if they clog burners with ore because some belt was placed wrong.

200s simply wasn't enough time for fluids to move from tank to tank so the last fluid wagon could be pumped empty despite plenty of space still left over in adjoining tanks. The transfer speed tank to pipe to tank is too small so I now balance tanks using circuit logic. I'm probably not the only one that runs into that problem.

Default stop timeout is 2min (7200 ticks). I never managed to have a train stuck in a station longer than that.
If it's too short for you you can change it to anything you want in options - mod settings - map - Stop timeout. Setting it to 0 will disable it. Somehow that info seems to have gone missing from the tooltip.

I noticed slight imbalances due to fluid mechanics in my oil unloading station too.
Ample buffer storage and 4 pipes with 1500l/s throughput each to the main storage make it work. As a complete rework of the fluid system is on the horizon I'm not going to do much to accommodate the current messy system. Maybe it will even round fluids in a useful manner.


2018-09-17-11-20-19-8885058.png

That station is similar to my design except it's size. I have 2 rows of tanks.

Now imagine what happens when your oil consumption is low but for some reason you need lots of crude oil barrels. E.g. you just placed a new requester chest for crude oil barrels. The first tank is sucked dry, the last will still be full and a gradient in between. When the next train comes the first fluid car can be emptied but the last will take forever.

You station design is in danger of exactly the same failure I had.

[Optera]

You misread the picture.
The assembler empties oil barrels. I only use barrels to ship pumped out residue from the fluid depot back to the refinery. So far this assembler has emptied less than 100 barrels.

If this was a proper unbarreling station I'd have designed it very differently.

Sidenote, that is only the unloading buffer consisting of my 100k mk2 tanks leading to the real 3.2Ml storage though those 4 pipes. It's designed to pump oil to the storage faster than trains can deliver.
So no, I don't think this station will ever run into similar problems as yours.

[mrvn]

Sorry, misread it indeed.

So throw away 1000 crude oil barrels while your secondary oil storage is full. Now the first tank is full and the last empty. Still enough space to request another train. But then the first fluid car can't be unloaded.

When playing BOBs + Angles mods with the multitude of fluids something like "throw away 1000 crude oil barrels" is actually likely to happen as you refactor parts of the factory for new recipes or scale things to new levels.

Obviously you can design your station to cope with that. But that assumes you plan for it before hand. Usually you only know about it after and then you have a fluid train at the depot.

Why are you so against handling user failures in LTN?

[Optera]

Why are you so against handling user failures in LTN?

Different design principals. I made LTN to power my train based megabases and save ups. I estimate LTN consists of around 90% of code doing actual work since i omitted frills like ui or sanity checks.

Error handling costs performance. I had to write code handling (almost) any user mistake. It consisted to 90% of error handling. Writing error handling code is not fun and it would also ruin my intention of actually saving ups by using LTN over vanilla trains.

Now you could say, "it's just a small feature and it wouldn't use much performance" to which I say "with the first link the chain is forged".
If it's a feature that is well thought through and can be implemented without any performance impact I'll gladly add it. (e.g. Schedule circuit conditions)

Speaking of schedule circuit conditions. That option allows you to control trains more granular. A red signal causes trains to get stuck in a stop while green forces them out.

[mrvn]

Why are you so against handling user failures in LTN?

Different design principals. I made LTN to power my train based megabases and save ups. I estimate LTN consists of around 90% of code doing actual work since i omitted frills like ui or sanity checks.

Error handling costs performance. I had to write code handling (almost) any user mistake. It consisted to 90% of error handling. Writing error handling code is not fun and it would also ruin my intention of actually saving ups by using LTN over vanilla trains.

Now you could say, "it's just a small feature and it wouldn't use much performance" to which I say "with the first link the chain is forged".
If it's a feature that is well thought through and can be implemented without any performance impact I'll gladly add it. (e.g. Schedule circuit conditions)

Speaking of schedule circuit conditions. That option allows you to control trains more granular. A red signal causes trains to get stuck in a stop while green forces them out.

Yeah. But you said then you have to have signals at every stop. So to test this I would have to change every existing station. Not something I've been willing to do yet.

[Optera]

You have to activate "send to train" on every stop. I believe that can be done by changing the options on one stop, making a blueprint and stamping that over the others. Feeding the signals is optional.

Edit:
I just tested it on my base. Converting only took a few minutes with a blueprint. Mostly since all my stations are smart already.

As you can see the fluid train has a delivery, but can't leave until it is cleaned out.

2018-09-17-17-15-41-8826708.png (3.72 MiB) Viewed 3958 times

[mrvn]

1) Does turning on signals automatically remove the timeout or did you set your timeout to 0?

2) Why does it need send to train? (can't test right now) Do trains with a circuit condition in their schedule simply never leave when send to train isn't on? I would have assumed that without send to train the signal red is always 0. Sounds like something vanilla should fix.

[Optera]

1) Does turning on signals automatically remove the timeout or did you set your timeout to 0?

2) Why does it need send to train? (can't test right now) Do trains with a circuit condition in their schedule simply never leave when send to train isn't on? I would have assumed that without send to train the signal red is always 0. Sounds like something vanilla should fix.

1) It adds the circuit signal conditions on top of the time conditions

2) Yes it's a bit of an oddity with the base mechanics.
To have trains with a circuit condition in schedules like AND red = 0 work the stop has to be connected somewhere (even a wire to a pole is enough) and send to train enabled.

[nuhll]

why trains enter depot with fluids can have many reasons. You can have all stations perfect and still it can happen. And if it one time out of 1000.00000000 deliveries happen, (and you dont notice) all your stations are infected, you are so hard fugged...

I dont understand why you cant add a wait till empty to depot option.

You cant tell me it never happend to you.

It might happen when you build or rebuidl your network. Or let your personal train sit on the tracks, or a wrong signal, or or or or.

Its very arogant to say "You are to dumb to build stations gtfo".

For items we can easy unload and fix it by ourselfs, because train will wait until empty. For fluids this is not possible.

You should add something to help full trains from leaving the depot.

Luckly i found a manual solution, so i dont really care at this point, but since its your mod, you could provide a solution for it. My point is this is a missconcept in the mod. For items you gave us a solution, for fluids not.

[Optera]

I posted 2 solutions both within this thread. If you can't read well that's your problem.

[mrvn]

Sorry Optera but maybe you can't read.

Your solutions DO NOT WORK right. And for fluids they can't be automated.

It would be simple to fix if all trains had to be empty at the depot. Unfortunately that would break other use cases. For example some people have shown setup with barrels where trains at the depot would have empty barrels, exchange them for full barrels at the first stop and back to empty barrels at the second.

So everyone lets think about something that is simple to use and works for situations where you want goods/fluids left in the train and situations where you don't.

Idea #1: Add a signal to the Depot for "train must be empty". Or the reverse: "allow items in train".

[Optera]

I tested the provided options in my own 2kspm railworld and they did exactly what was requested. Prevent trains with residue from leaving the depot.

pre 1.8.2:

You have to activate "send to train" on every stop. I believe that can be done by changing the options on one stop, making a blueprint and stamping that over the others. Feeding the signals is optional.

Edit:
I just tested it on my base. Converting only took a few minutes with a blueprint. Mostly since all my stations are smart already.

As you can see the fluid train has a delivery, but can't leave until it is cleaned out.

1.8.2 fixed several bugs where trains where not removed from available trains.
Locking down depots by either disabling the stop or removing the Depot signal also works. Maybe you didn't see the patchnotes.

[mrvn]

I saw the patchnote about removing trains from the available list too late.

That makes the posted "solutions" work. It still a suboptimal solution since it doesn't allow automation. I still would like a solution that would clean up left over fluids automatically.

Only idea I have that would achieve that is to send trains with left over fluids to stations requesting said fluids. Something that would require a larger change in how trains are handled and schedules allocated. Lets see if someone else has a better idea.

[Optera]

Whatever you envision is not the optimal solution for everyone. Is mine? No, but at least I provided a solution that works well enough for all scenarios without making some setups unusable as yours would.

This whole thread is about a fail safe that should never happen.
Loading stations should only load the requested items/fluids and unloading stations keep trains until they are empty.

[nuhll]

Fact is that trains which have items in it can be automaticly cleaned bc trains will wait until there is no action.

If you would add a "dont leave depot before empty" option, and let it unchecked (standard), nothing for all users would change, and the users with bobs and other mods adding many fluids could use that option to be sure no fluids would infect all stations.

It would break nothing and would be a solution. And, i guess, relativly easy to add.

Best way would be ofc if we had a station or anythign which could completly destroy fluids.

If taht locking down work now (and as i asked this, it didnt worked (!!!)) its a workaround, atleast.

[Optera]

Fact is that trains which have items in it can be automaticly cleaned bc trains will wait until there is no action.

If you would add a "dont leave depot before empty" option, and let it unchecked (standard), nothing for all users would change, and the users with bobs and other mods adding many fluids could use that option to be sure no fluids would infect all stations.

An option doing exactly that is available since 1.8.0 in the form of Circuit Conditions.
Since 1.8.2 removing the depot flag or even disabling the stop also works to accomplish the same effect.

There is no reason to add a redundant option. Thread closed.