## round up fluids reading train inventory

Post your ideas and suggestions how to improve the game.
JohnyDL
Filter Inserter
Posts: 512
Joined: Fri May 16, 2014 3:44 pm
Contact:

### Re: round up fluids reading train inventory

but it's not 99.0001 and 100 where it matters it's the difference between 24999.00001 and 25000. Or similar setups, if you're adding more than 1 tank together that's an error of upto 1 unit per tank, with fluids wagon the calculation treats the whole train as one thing but if you store 1m in tanks and connect them all together so you can open a station at fluid = 1million and you're as much as 400 litres short and being at 1m also means shut off the processes that make the fluid to save energy, you have a problem. The train is requested, the train sits in station train fills to 99.99% and it continues to sit there and since the train doesn't read full (it reads 399 short thanks to the rounding) and since it doesn't leave the station maybe the system you set up for starting the preparation of the next load doesn't start to run. Leading to the bug report
"My tanks read exactly 1 million fluid but when I put them in a train it only reads 999601 something is broken"

mrvn
Smart Inserter
Posts: 3368
Joined: Mon Sep 05, 2016 9:10 am
Contact:

### Re: round up fluids reading train inventory

Except for the examples given above there the difference between 99.1 and 100 is important.

Let me add another simple case: You enable the train station when the tanks have 75000 fluid and the train is set to leave when full. If you always round up the train station will activate at 74999.000001 fluids and the train will never get full and never leave. Same problem for loading as you have for unloading now.

The point of moving the problem from <1 to <2 is that checking for 0 is an important use case while probably nobody checks for =1. And even if they do the rounding error won't hurt them. There is no case with =1 where the tank isn't empty and can't be filled with something else. Or a train not leaving. If you check for =1 now then you are already prepared for that being a somewhat flexible amount, neither completely empty nor anywhere near full. So breakage should be minimal or non existent.

Optera
Smart Inserter
Posts: 2086
Joined: Sat Jun 11, 2016 6:41 am
Contact:

### Re: round up fluids reading train inventory

mrvn wrote:Except for the examples given above there the difference between 99.1 and 100 is important.

Let me add another simple case: You enable the train station when the tanks have 75000 fluid and the train is set to leave when full. If you always round up the train station will activate at 74999.000001 fluids and the train will never get full and never leave. Same problem for loading as you have for unloading now.

The point of moving the problem from <1 to <2 is that checking for 0 is an important use case while probably nobody checks for =1. And even if they do the rounding error won't hurt them. There is no case with =1 where the tank isn't empty and can't be filled with something else. Or a train not leaving. If you check for =1 now then you are already prepared for that being a somewhat flexible amount, neither completely empty nor anywhere near full. So breakage should be minimal or non existent.
Simple solution: Add one more tank and enable at 75001.

JohnyDL
Filter Inserter
Posts: 512
Joined: Fri May 16, 2014 3:44 pm
Contact:

### Re: round up fluids reading train inventory

Optera wrote:Simple solution: Add one more tank and enable at 75001.
If that's your attitude Optera; Simple Solution: use separate trains for each liquid. No need to change current behaviour at all.

Optera
Smart Inserter
Posts: 2086
Joined: Sat Jun 11, 2016 6:41 am
Contact:

### Re: round up fluids reading train inventory

JohnyDL wrote:
Optera wrote:Simple solution: Add one more tank and enable at 75001.
If that's your attitude Optera; Simple Solution: use separate trains for each liquid. No need to change current behaviour at all.
That solution in conjuncture with using wait until empty IS the only way to ensure fluid wagons are completely drained.
You apparently still fail to realize the whole point of this thread is that this is unsatisfactory and feedback for granular pump control should be made available.

JohnyDL
Filter Inserter
Posts: 512
Joined: Fri May 16, 2014 3:44 pm
Contact:

### Re: round up fluids reading train inventory

Nope I get why you made the thread I'm saying you can't be so dismissive of other people's points because they are just as pedantic/valid as your own. "There is a simple solution use it" is not a valid argument unless it goes along with "you're trivializing part of the puzzle".

Right now we're maybe 20 players reading and responding to this idea arguing over the fate of thousands of people's builds, blueprints and bases. What you are saying is a simple fix to your problem, has knock on effects that could break their builds.

Some dev promised fluid squishing which is good enough to solve the problem of tiny errors in the fluid dynamics of train tanks by deleting them so you lose a cycle of product maybe over the life span of a map, but you continue to argue that's not the solution you want. When actually there are equally simple ways to guarantee your train empty station will empty 100% of the train in a similar manner to the just add an extra tank you proposed for mrvn's loading problem your idea causes.

For example placing an extra tank at your station and preventing a train coming to unload unless there is space for all of its contents. And preventing your train from leaving the station by delaying it with circuit conditions for an extra tick after it reads zero so the 0.49999 that could potentially be in the train actually gets pumped out.

Optera
Smart Inserter
Posts: 2086
Joined: Sat Jun 11, 2016 6:41 am
Contact:

### Re: round up fluids reading train inventory

JohnyDL wrote:Nope I get why you made the thread I'm saying you can't be so dismissive of other people's points because they are just as pedantic/valid as your own. "There is a simple solution use it" is not a valid argument unless it goes along with "you're trivializing part of the puzzle".

Right now we're maybe 20 players reading and responding to this idea arguing over the fate of thousands of people's builds, blueprints and bases. What you are saying is a simple fix to your problem, has knock on effects that could break their builds.

Some dev promised fluid squishing which is good enough to solve the problem of tiny errors in the fluid dynamics of train tanks by deleting them so you lose a cycle of product maybe over the life span of a map, but you continue to argue that's not the solution you want. When actually there are equally simple ways to guarantee your train empty station will empty 100% of the train in a similar manner to the just add an extra tank you proposed for mrvn's loading problem your idea causes.

For example placing an extra tank at your station and preventing a train coming to unload unless there is space for all of its contents. And preventing your train from leaving the station by delaying it with circuit conditions for an extra tick after it reads zero so the 0.49999 that could potentially be in the train actually gets pumped out.
There are however arguments why rounding is preferable to squashing fluids:
• It takes more calculations to squash fluids than to change rounding
• Rounding does not partially destroy products potentially messing with production statistics, timings asf.
• Also the argument that has been brought up against rounding: some players will have to change their circuit logic. Which is not valid as the logic keeps changing and evolving constantly.

JohnyDL
Filter Inserter
Posts: 512
Joined: Fri May 16, 2014 3:44 pm
Contact:

### Re: round up fluids reading train inventory

It's not particularly computationally expensive to do either, rounding, floor and ceiling are all built in functions and I'd guess all about the same cost give or take a cycle so I can see that being an argument but to use one rather than another near zero is an if statement which relatively speaking costs a lot

Whereas I imagine the code for squishing to be already if statements "if fluid type == tank fluid type" being the first test "or tank contents == 0" being the second well it's just as expensive in that case to "tank contents < 0.5" with no associated cost.

You lose products to belts and its not a problem, I mean no-one seems to care that a splitter merging 2 lines will always lose 1 or 2 items to the empty line, or that sometimes you have to take items of one type down an assembly line where they aren't needed, maybe not literally destroying them but messing with production statistics on the same scale as squishing fluids.

And yes the logic does change and evolve, I agree but using ceiling rather than round/floor might not just effect fluids, 50/7 in arithmetic combinators rounds to 7 but would ceiling to 8 so using divide and modulo as part of larger builds would be screwed up beyond anything we've seen so far to "not designed behaviour" if people expect floor or anticipate round throwing a curveball at them like that into builds would be a major headache. And most would consider it a bug not a minor change to the logic of circuit networks.

Optera
Smart Inserter
Posts: 2086
Joined: Sat Jun 11, 2016 6:41 am
Contact:

### Re: round up fluids reading train inventory

JohnyDL wrote:It's not particularly computationally expensive to do either, rounding, floor and ceiling are all built in functions and I'd guess all about the same cost give or take a cycle so I can see that being an argument but to use one rather than another near zero is an if statement which relatively speaking costs a lot

Whereas I imagine the code for squishing to be already if statements "if fluid type == tank fluid type" being the first test "or tank contents == 0" being the second well it's just as expensive in that case to "tank contents < 0.5" with no associated cost.
What I meant was that checking every pipe, tank and tank wagon for fluid and removing residue when filling is more expensive than having the current system with math.ceil instead of math.round.
Not only does squishing require more operations, it'll also have to be applied to more entities.

If we start nitpicking math.floor and math.ceil will always be faster than math.round. Round is nothing more than return math.floor(i+0.5 ) or return math.ceil(i-0.4).
You lose products to belts and its not a problem, I mean no-one seems to care that a splitter merging 2 lines will always lose 1 or 2 items to the empty line, or that sometimes you have to take items of one type down an assembly line where they aren't needed, maybe not literally destroying them but messing with production statistics on the same scale as squishing fluids.
I've played with someone whose OCD was worse enough he was bothered by items stuck in splitters so he never used 2to1 splitter merging. He also used more resources building his ratio perfect layouts than they ever saved
And yes the logic does change and evolve, I agree but using ceiling rather than round/floor might not just effect fluids, 50/7 in arithmetic combinators rounds to 7 but would ceiling to 8 so using divide and modulo as part of larger builds would be screwed up beyond anything we've seen so far to "not designed behaviour" if people expect floor or anticipate round throwing a curveball at them like that into builds would be a major headache. And most would consider it a bug not a minor change to the logic of circuit networks.
Only the initial double to int conversion, namely output of tanks and train stops, needs to be changed.
Rounding shouldn't even effect the integer arithmetic logic circuit network uses. Integer divisions will always just truncate the result.

JohnyDL
Filter Inserter
Posts: 512
Joined: Fri May 16, 2014 3:44 pm
Contact:

### Re: round up fluids reading train inventory

Aren't floor operations faster (if you're taking it that far) because it's a truncate command (0 all digits) after a point. So a ceiling is a floor +1 as much as round is floor +0.5

Again you check the pipes anyway as part of the flow operations because pipes will push fluids when mixed based on pressure it only crushes when end of line < 0.5

I know what you mean about the CDO people sometimes

mrvn
Smart Inserter
Posts: 3368
Joined: Mon Sep 05, 2016 9:10 am
Contact:

### Re: round up fluids reading train inventory

Checking for 0 or <squid amount is pretty much the same. Only difference is in loading the constant to compare the tank/pipes current fill level with.

But on the note of squishing: I would love to have pushing instead. Say you have a pipe 10 pieces long filled with left over water. Now you connect it to a crude oil tank on one side. What I would like to happen is that the water gets pushed to the end of the pipe collecting in the last piece and the rest filling with crude oil.

Shia
Burner Inserter
Posts: 18
Joined: Mon Oct 23, 2017 10:11 pm
Contact:

### Re: round up fluids reading train inventory

Optera wrote:
Shia wrote:Maybe that is outdated but I have run some tests:

If the train is set to "Leave if Cargo Empty" then it will not leave even with 0.0 filled (as long as something is shown). It need's to be empty for real. (Which isn't the problem here)
That's true, but it won't help if you have 2 or more fluids loaded and want to measure if one of them is truly empty.
For Pumps I simply use one decider and one constant combinator (if you never fear "train 1")

Simply connect everything (station + constant + decider in + decider out + pump) => yes, short circuit the decider
Station: "Read Train contents" and "Read stopped train" (Description assumes that you stay with the "T" signal, but feel free to change it to something different unique)
Constant: T(-1)
Decider: T > 0 ; Everything(1)

Now the last signal (which is not "T") stays at at least "1" until "T" is below 2. (Until the train leaves, the fluid will be at least 1 even if the stations says 0)

If you fear "train 1" (because this setup will not see this train because of the constant T(-1). simply plug in an arithmetic combinatior with (each + 1 > each) and use this output as your "station" for the signal (now train 1 will be 2 and it will still work)

hopefully that was helpful for you
You can't fix stops outputting 0 when there's still 0.4 fluid left with combinator contraptions.
We are talking about a loss in precision rounding from internal float to circuit network int here. Once lost you can't get back that information.
It is just a helper to empty out for real.

At which point do you "start" checking an 0.4 fluid?

The real problem is not fully "unloading" fluids. Just try this blueprint:

Code: Select all

(without rotating) Add some void to the left and a source to the right pumps. Also set the condition of the pumps to the correct fluid.
If the "0" constant combinator is turned off, the (lower) pump will will act only pump if a fluid is there (below 0.5 it will not)
Turn the "0" on and my "workaround" will act and the pump will be active like normal, but won't turn off until the train leaves.

Still: If you just want to complain about the fact that "0.4" is shown as "0" I can't help you in any way

But having workable solution for trains should cover about 95% of all problems...

I'd be happy to have a real "non-solvable-problem" from Optera. Just keep in mind that there are also problems like: https://support.microsoft.com/en-us/hel ... arithmetic.
That is not a problem for normal rounding, but always using floor may lead to a situation where it should be 0.999999 but the calculation gets to 1.00001 and because of your suggestion it will be 2. (I do know that this is not our problem here).
A better solution may be the possibility to have a "0" inside the network. like "0 Water" = "0.5 > water > 0" but then, you would need a solutions to check if there is "no water"... If you really want, you always are able to find a problem.

JohnyDL
Filter Inserter
Posts: 512
Joined: Fri May 16, 2014 3:44 pm
Contact:

### Re: round up fluids reading train inventory

mrvn wrote:Checking for 0 or <squid amount is pretty much the same. Only difference is in loading the constant to compare the tank/pipes current fill level with.

But on the note of squishing: I would love to have pushing instead. Say you have a pipe 10 pieces long filled with left over water. Now you connect it to a crude oil tank on one side. What I would like to happen is that the water gets pushed to the end of the pipe collecting in the last piece and the rest filling with crude oil.
I agree, I think pushing is the planned default only if the container can't be pushed empty and has <0.5 will it squish, at least that's my interpretation of what the devs said

Optera
Smart Inserter
Posts: 2086
Joined: Sat Jun 11, 2016 6:41 am
Contact:

### Re: round up fluids reading train inventory

Shia wrote:But having workable solution for trains should cover about 95% of all problems...

I'd be happy to have a real "non-solvable-problem" from Optera.
Except you didn't solve the original problem of reliably emptying only water from a train holding multiple fluids.
Currently the only 100% reliable method is limiting trains to 1 fluid per train and use wait until empty.
Using combinator contraptions or an inactivity wait condition can fail.

mrvn
Smart Inserter
Posts: 3368
Joined: Mon Sep 05, 2016 9:10 am
Contact:

### Re: round up fluids reading train inventory

Optera wrote:
Shia wrote:But having workable solution for trains should cover about 95% of all problems...

I'd be happy to have a real "non-solvable-problem" from Optera.
Except you didn't solve the original problem of reliably emptying only water from a train holding multiple fluids.
Currently the only 100% reliable method is limiting trains to 1 fluid per train and use wait until empty.
Using combinator contraptions or an inactivity wait condition can fail.
Using combinators you can reliably empty a fluid wagon. You can also split it in 3 and still reliably fill and empty it.
So the rounding is mostly an inconvenience.

EXCEPT: try to design a station where you unload one fluid and load a different fluid in the same train. E.g. a train with water comes in, you pump it empty and then you pump in steam instead. Not impossible but the logic gets a lot more complex and you need 4 tanks instead of 3.

JohnyDL
Filter Inserter
Posts: 512
Joined: Fri May 16, 2014 3:44 pm
Contact:

### Re: round up fluids reading train inventory

mrvn wrote:EXCEPT: try to design a station where you unload one fluid and load a different fluid in the same train. E.g. a train with water comes in, you pump it empty and then you pump in steam instead. Not impossible but the logic gets a lot more complex and you need 4 tanks instead of 3.
so long as there was no steam in the train to begin with turn on water pump if steam<=0, turn steam pumps on if water<=0, make sure that the water tanks are empty before the train can arrive with circuit network conditions and put the steam pumps turning on with a delay of some ticks so the water keeps pumping slightly longer than there's '0 water' in the train.

But you can't connect 2 pumps to the same train tank so emptying and filling at the same station should be a mute point.

torne
Filter Inserter
Posts: 272
Joined: Sun Jan 01, 2017 11:54 am
Contact:

### Re: round up fluids reading train inventory

You can't connect two pumps to the same train tank *at the same time*, but if you disable the emptying pump it will disconnect and allow the filling pump to connect instead; you can empty and fill at the same station this way, but the inability to detect small quantities of liquid makes it fiddly.

Zavian
Smart Inserter
Posts: 1417
Joined: Thu Mar 02, 2017 2:57 am
Contact:

### Re: round up fluids reading train inventory

I've re-read this thread, and come to the conclusion that the best fix I've seen suggested would be to change fluid measurements to special case the scenario where the tank/train has less than one fluid, (but more zero), round that up to one. That should solve Optera's problem, and seems unlike to break anything. (Sure, someone could have 250 tanks all wired together, read their contents by circuit network, decide that there is enough fluid to fill a barrel, switch on the pump to the barrelling machine, then wonder why the barrelling never finishes. But seems like a contrived example, and unlikely to actually be a problem in practice, and the alternative of always rounding up mean that this would break with only one tank).

Can anyone think of any other practical (and realistic) usecases where rounding <1 fluid up to 1 would be a problem?

JohnyDL
Filter Inserter
Posts: 512
Joined: Fri May 16, 2014 3:44 pm
Contact:

### Re: round up fluids reading train inventory

Yes detecting to so something different at 0<x<0.5 to do something different there rather than at any other time adds clock cycles for every tank and fluid wagon on the map every tick vs being consistent everywhere and taking fewer cycles.

So one way or the other it has to be and ceiling function vs round vs floor each break as many systems as they fix, with the exception that some problems have no benefit being in any of the methods. so why break what people have already made work for the 99% of cases where none is better than the rest or where the current is better than ceiling? In order to fix something for one specific problem that has multiple in game solutions already and that the devs have promised a force fix for when those fail.

Zavian
Smart Inserter
Posts: 1417
Joined: Thu Mar 02, 2017 2:57 am
Contact:

### Re: round up fluids reading train inventory

But if the performance bottleneck is memory latency or bandwidth, then a couple of extra cpu cycles per circuit connected tank/fluid wagon per tick might be completely irrelevant. The only way to tell for sure would be detailed benchmarking on a map with many circuit connected tanks/wagons.

### Who is online

Users browsing this forum: No registered users