Factorio Forums

Twinsen wrote:It's not as simple as rounding up.

If I round up soon there will be a flood of complaints from a different group of people saying that their storage tank logic no longer works, because there is 0.00001 fluid in their storage tank that they can't pump out. Or similar problems to this.

Please don't bring in different issues. If pumps can't 100% empty a tank or fluid wagon that's an issue with the fluid mechanics.

Having no indication in circuit network when minuscule fractions block a tank is more of an issue than some setups having a +-1 error that could easily be fixed.

Optera wrote:

Twinsen wrote:It's not as simple as rounding up.

If I round up soon there will be a flood of complaints from a different group of people saying that their storage tank logic no longer works, because there is 0.00001 fluid in their storage tank that they can't pump out. Or similar problems to this.

Please don't bring in different issues. If pumps can't 100% empty a tank or fluid wagon that's an issue with the fluid mechanics.

Having no indication in circuit network when minuscule fractions block a tank is more of an issue than some setups having a +-1 error that could easily be fixed.

+1

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)

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

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.

Surely giving the pumps a little delay and the train a little inactivity works?

Train has 100 of fluid A (and other stuff)
Signal goes through a few combinators as delay
Pumps get turned on
Train has 0.4 fluid and internally fluid A = 0 is satisfied, (but there's still activity)
Signal is 0 goes through delay by the time reaches pumps fluid A is truly 0
Pumps stop
Train gets a whole second of inactivity
Train leaves empty

JohnyDL wrote:Surely giving the pumps a little delay and the train a little inactivity works?

Train has 100 of fluid A (and other stuff)
Signal goes through a few combinators as delay
Pumps get turned on
Train has 0.4 fluid and internally fluid A = 0 is satisfied, (but there's still activity)
Signal is 0 goes through delay by the time reaches pumps fluid A is truly 0
Pumps stop
Train gets a whole second of inactivity
Train leaves empty

This will fail if the tanks are just full when pumps reach the final 0.5l.

don't enable the station unless there's enough space in the tanks to unload a full train's worth is easy enough to do so I don't see that as a potential issue Optera and even if the tanks are full the pump has an internal fluid buffer that could/would fill up to so even if there was a rounding error on the tank you'd have space for 25099 fluid not 24999 fluid

Why not round up when below 1? Only change the behaviour for outputing 0. The argument that the network should only read 0 if it is truely empty is sound.

I did run into the same problems with train stations unloading fluids. My solution adds 2 combinators: One decider combinator connected with a green wire to the train stop (read train contents, read train ID), a green wire connecting output to pumps and a red wire connecting output to input and set to "T > 0: output each". The second is a arithmetic combinator connected with green wire to the decider combinator input to input and output to output and set to "T * -! = T".

This is sort of a latch. When a train comes in it adds the contents of the train on every tick preserving the fluid type in the tank even if it later rounds to 0. When the train leaves it resets to 0. The arithmetic combinator is just there to remove T from the latch. This way the pumps can be set to "fluid type > 0" and will pump until the train leaves. Sadly this only works for unloading but not for stations that do both loading and unloading.

I don't think changing the logic so things act differently at different times is useful but outputting a X=0 signal rather than making the signal evaporate when it hits 0 would be better I think.

JohnyDL wrote:I don't think changing the logic so things act differently at different times is useful but outputting a X=0 signal rather than making the signal evaporate when it hits 0 would be better I think.

+1

There's no such thing as an X=0 signal in this game. The signal not being there is exactly the same thing as it being zero.

torne wrote:There's no such thing as an X=0 signal in this game. The signal not being there is exactly the same thing as it being zero.

EXACTLY that's why I suggested it as the change I mean in any other programming language there's X=NULL which is distinctly different from X=0 we in effect have the first but not the second.

JohnyDL wrote:

torne wrote:There's no such thing as an X=0 signal in this game. The signal not being there is exactly the same thing as it being zero.

EXACTLY that's why I suggested it as the change I mean in any other programming language there's X=NULL which is distinctly different from X=0 we in effect have the first but not the second.

Or in LUA terms X=nil vs. X=0.0

C, ruby, python, java, hell even JavaScript call it null :p lua is weird
I suppose askii calls it \0 or NUL or \x00 and Unicode is U+0000 But they aren't programming languages

JohnyDL wrote:C, ruby, python, java, hell even JavaScript call it null :p lua is weird
I suppose askii calls it \0 or NUL or \x00 and Unicode is U+0000 But they aren't programming languages

LUA is bizarre. I don't know any other script language that start indexing at 1.
However Lua does know nil https://www.lua.org/pil/2.1.html

Neither of this has anything to do with the inherent information loss when rounding from float fluid values to integer though.
It is very unlikely the circuit network will ever implement nil and 0 in the near future. My suggestion of always rounding up would be a quick fix to discern 0.1 from 0 that wouldn't break any existing systems nor cost performance. Actually it would be slightly faster to always round up than to round mathematically correct.

Except if you have people who rely on fluid in tank being 0 to say turn on their cracking, suddenly any non-zero amount would lock up the system even 0.0000000000001 fluid which might happen if there were systems with quite a lot of pipes and storage but only one tank reading the average level of a system

JohnyDL wrote:Except if you have people who rely on fluid in tank being 0 to say turn on their cracking, suddenly any non-zero amount would lock up the system even 0.0000000000001 fluid which might happen if there were systems with quite a lot of pipes and storage but only one tank reading the average level of a system

I started this exactly because you can't detect if a tank, tank wagon or stationary, is really empty.
0.4 will be reported as empty while the fluid inside will block any other fluid.

With the proposed change setups with fluid = 0 will keep working the same, just start a few ticks later when tanks are truly empty instead of having 0.4 residue is left.

And 10 days later someone else will report a bug because the circuit network told them their crude oil tank had 10000 crude oil, so they tried to cycle their basic oil processing refinery 100 times, convert the heavy oil to lube and expected to load 3000 lube on their lube train. Except the refinery only cycled 99 times, hence they will report a bug.

Note I'm not saying that this shouldn't be addressed somehow, but always rounding up will just mean players will report a different bug. It does nothing to actually change the loss of precision.

But if there are rounding errors and there are always rounding errors then the static tanks having microscopic amounts in and stopping the processes Might break things. My suggestion above was turn in when fluid < 1 but 0.0000001 registering as 1 doesn't work or if it some how did you just move the problem to <2, <3, <n and it breaks other things in other places

Sure it will move it to the point where you can't discern between 99.01 and 100, but who cares!? Practically all circuits will work correctly with that.
Discerning between 0 and 0.01 is what's important with Factorio's fluid mechanics.