Factorio Forums

This is not a big bug, but still.
How to reproduce:
1, build a train with fluid wagon and fill it with crude oil (I tried crude oil, probably doesnt matter what you fill it with)
2,Build a station, set the leaving condition of the train to fluid count: empty
3, Pump out the crude oil.
4, watch train leave even though it has 0,8 crude oil in it

Only one part of the wagon was empty, other two had 0,4 crude oil in them.(screenshot)
Is this a bug or is the fluid count rounded down so 0.8 was considered 0 and train left? Not sure so posted it.

Signals only work in integers, therefore anything < 1 is considered empty.

Loewchen wrote:Signals only work in integers, therefore anything < 1 is considered empty.

Oh this damned fluids.
What happens if i fill water in the wagon after that?

Greetings, steinio.

PUSH

Why is this on not a bug?

This damned fluid behavior is so annoying.
What should we do with an unempty rail tanker with 0.1 liquid?

Get this sorted out!

steinio wrote:PUSH

Why is this on not a bug?

This damned fluid behavior is so annoying.
What should we do with an unempty rail tanker with 0.1 liquid?

Get this sorted out!

Use the 'inventory empty' condition if you want the train to leave when its empty

Klonan wrote: Use the 'inventory empty' condition if you want the train to leave when its empty

This workaround is not usable if you have a train set to unload only part of it's contents.
e.g. have a train picking up lubricant and sulfuric acid to distribute it to 2 different stations.

Schedule checks for fluid contents should always round up.

what happens if you multiply the signal by 100,000?
Would that work?

BenSeidel wrote:what happens if you multiply the signal by 100,000?
Would that work?

0.1 is rounded to 0, 0*100k = 0.
I have no idea if circuit signals would actually round 0.6 up. Pumps are now so powerful it's hard to get them to leave anything between 0.5 and 0.9 in a tank.

Optera wrote:

BenSeidel wrote:what happens if you multiply the signal by 100,000?
Would that work?

0.1 is rounded to 0, 0*100k = 0.
I have no idea if circuit signals would actually round 0.6 up. Pumps are now so powerful it's hard to get them to leave anything between 0.5 and 0.9 in a tank.

Yeah, for some reason I thought that the rounding happened as the signal entered the combinator, not as it left the storage tank. But now I think about it I realise how stupid that sounds.
The only solution is to simply not use floating point numbers in computer software.

BenSeidel wrote:The only solution is to simply not use floating point numbers in computer software.

The only solution is to round to int according to application.
This application is especially simple since there is no case where rounding down is required. No one cares if a train set to leave at fluid >= 75k leaves at 74999.1, but if a train set to fluid = 0 leaves a 0.9 that's a problem.

Related suggestion thread:

viewtopic.php?f=6&t=49274 round up fluids reading train inventory

Optera wrote:

BenSeidel wrote:The only solution is to simply not use floating point numbers in computer software.

The only solution is to round to int according to application.
This application is especially simple since there is no case where rounding down is required. No one cares if a train set to leave at fluid >= 75k leaves at 74999.1, but if a train set to fluid = 0 leaves a 0.9 that's a problem.

Can't find the original thread, but it rounds that way because of the UI rounds. People were setting conditions that tested for full tanks, such as "crude oil = 2500" and it was never true, due to the rounding issues, so the rounding was changed to what it is now. It hasn't been an issue because checking if something is empty is fine, because the tanks didn't get disconnected. It would still play havoc with pumps in some extreme cases though.

BenSeidel wrote:

Optera wrote:

BenSeidel wrote:The only solution is to simply not use floating point numbers in computer software.

The only solution is to round to int according to application.
This application is especially simple since there is no case where rounding down is required. No one cares if a train set to leave at fluid >= 75k leaves at 74999.1, but if a train set to fluid = 0 leaves a 0.9 that's a problem.

Can't find the original thread, but it rounds that way because of the UI rounds. People were setting conditions that tested for full tanks, such as "crude oil = 2500" and it was never true, due to the rounding issues, so the rounding was changed to what it is now. It hasn't been an issue because checking if something is empty is fine, because the tanks didn't get disconnected. It would still play havoc with pumps in some extreme cases though.

The last change to rounding of fluids in circuit network I recall was when I reported Combinator displays inconsistent values on mouse over.

However with fluid wagons and stops reporting train contents requirements for circuit network have changed. I'd gladly take a minor discrepancy between mouse over and circuit network if it means I can discern if that wagon is truly empty or still has a 0.01 residue locking it to that fluid.

Rounding to next full integer wouldn't break existing setups either. A condition = 2500 would just trigger a bit earlier on 2499.1 instead of 2499.5

BenSeidel wrote:

Optera wrote:

BenSeidel wrote:The only solution is to simply not use floating point numbers in computer software.

The only solution is to round to int according to application.
This application is especially simple since there is no case where rounding down is required. No one cares if a train set to leave at fluid >= 75k leaves at 74999.1, but if a train set to fluid = 0 leaves a 0.9 that's a problem.

Can't find the original thread, but it rounds that way because of the UI rounds. People were setting conditions that tested for full tanks, such as "crude oil = 2500" and it was never true, due to the rounding issues, so the rounding was changed to what it is now. It hasn't been an issue because checking if something is empty is fine, because the tanks didn't get disconnected. It would still play havoc with pumps in some extreme cases though.

Hi,

the thread was this: viewtopic.php?f=11&t=24558 but the point was not the displayed value but the wrong rounding - the same groundhog as every day.

But why should the developers listen to the users, they just decided to multiply fluids by 10 - what a wonderful idea...

Optera wrote:

BenSeidel wrote:

Optera wrote:

BenSeidel wrote:The only solution is to simply not use floating point numbers in computer software.

The only solution is to round to int according to application.
This application is especially simple since there is no case where rounding down is required. No one cares if a train set to leave at fluid >= 75k leaves at 74999.1, but if a train set to fluid = 0 leaves a 0.9 that's a problem.

Can't find the original thread, but it rounds that way because of the UI rounds. People were setting conditions that tested for full tanks, such as "crude oil = 2500" and it was never true, due to the rounding issues, so the rounding was changed to what it is now. It hasn't been an issue because checking if something is empty is fine, because the tanks didn't get disconnected. It would still play havoc with pumps in some extreme cases though.

The last change to rounding of fluids in circuit network I recall was when I reported Combinator displays inconsistent values on mouse over.

However with fluid wagons and stops reporting train contents requirements for circuit network have changed. I'd gladly take a minor discrepancy between mouse over and circuit network if it means I can discern if that wagon is truly empty or still has a 0.01 residue locking it to that fluid.

Rounding to next full integer wouldn't break existing setups either. A condition = 2500 would just trigger a bit earlier on 2499.1 instead of 2499.5

In that case, you should be able to "round to even", or embed the "greater or less than" with each appropriate rounding method. Either would solve the edge cases. I know its not a simple conversion, but it should be do-able. The other quick fix (this may still bugger with a few things), is to have the fluid count be made an integer by passing 100* (or 10*) fluid to the circuit network so it is still detected below a threshold?