I agree, but I think it's because since liquid/gas is divisible they decided to let it flow in variable decimal amounts. Probably not the smartest idea I'd think. I don't see the benefit of letting fractions of liquid pass, unless they are binding it to framerate which it seems that they are. I just realized that they do this for overclocking probably. I'd bite the bullet and go double or round up.
@erickv2739 they absolutely can not round up. Rounding up can be just as bad if not worse, due to byproducts existing. The rounding up errors would make it impossible to efficiently deal with the byproducts, you'd have to always assume there's going to be more than there is. I really don't see the issue with using only integers, even for over clocking, when it's supposed to be 1.5/min, you can simply fractionationalize the seconds, pick a frame that 1 whole m³ is sent out. Just make sure over clocking can only use rational numbers, and there will always be a whole number multiplier to remove the decimal.
We learned that double is more expensive than float. So what do you expect from int, which doesn't have decimals, so you also have to store the info of how many digits you need to move the decimal point. And now imagine that with long, which has even more bits. 😊 Why not use strings and do the calculation digit by digit how a student would do it on paper. 🤓
I think they went a bit too far on fluid simulations... Yeah backflow and such are a problem in real life but in the game imo it's just a bit frustrating to deal with and plus will cause problems... I mean talking about fluids cavitation is a problem, shockwaves on opening or closing valves, with gases you have backpressure and so on, those are not implemented in the game and that's a good thing ! What about just simplifying the whole thing like you consider a pipe on it's full lenght, calculate the height difference between in and out for headlift, calculate input rate vs output consumption and treat the rest like a conveyor belt just voiding anything above max rate of the pipe ? Imagine how frustrating it would be if when we had a slope on a conveyor belt items could randomly start to roll back and cause inballance ? As for this particular problem, how necessary is it to have decimal precision on flow rates ? I'd say use an int and round up and be done with it ?
You know, on this topic: I was marveling the other day about the shadow cast by the space elevator. I was probably 2km away, and the shadow was slowing passing over me. What struck me was it was moving perfectly smooth. No jittter or jumping at all, which you expect for these kinds of things.
why not just represent the values as integers representing ml? the math can be much faster and the precision remains constant across all values. a single unsigned int32 would more than cover any reasonable value a pipe or tank could hold while taking the exact same space as a single precision float
the only caveat I can see is that if you have 100 units going into a 3-way split you'd have to balance the rounding (to 34, 33, 33 - really not hard) instead of doing a naive rounding that would result in 33, 33, 33 and you'd lose a liter but even then you could still be super lazy and just round up and do 34, 34, 34 and let the system gain an extra 2 liters... would still be better than messing around with floats
Take the floating number and round it up to 600, beyond the range of error. Fluid is infinite anyway, some minor addition to the pipe won't harm gameplay. Fixing the bug will improve gameplay for people who want 600 in that pipe.
in the outer wilds example... the high distance issue with float coordinates is well known and also relatively simple solutions are well known pretty sure in their case they didn't care because that wasn't really a priority and that was probably the RIGHT decision to not care
in outer wilds its not completely solved, but the origin is always at the player so anything you can see will have good enough precision for it to not matter
why not have lower numbers behind the scenes? instead of 300 and 600 (mk1/mk2), do 30 and 60 for example. If it's for realism, you can always just multi by 10 when the player is viewing them (actually checking the pipes). Viewing will be more costly but most of the time we aren't viewing them..
Similar tiny backflows and flow hiccups actually can happen in real pipe networks and can cause backups and "chugging" if you don't use pipes and pumps with a bigger potential flow capacity than what you need. Especially in drainage situations where you aren't using pumps! Could you just change the pipe capacities to 320 m3/min and 620 or 640, so there's a bit of leeway, that compensates for the bug? Yes, it would make the floating point issue happen slightly more often, but wouldn't it also leave room so that it at least keeps the fluid flowing in the right direction when it does? Instead of backing up the whole system? With that, adding in fluid buffers could still balance out the rounding down and rounding up errors to average about 600? Alternatively I suppose you'd have to code a function to pro-actively imbed in the fluid calculations that would check whether the value of the float goes up a digit EACH TIME there's a calculation, and then if it does, deliberately round it in an alternating pattern so as to never exceed 600 but make sure... yeah sounds like a huge math headache and a lag machine. I don't envy you this bug to fix. But if you ever find a fix for it or an easy workaround that works for most uses, it'll make pipes in the game way more fun!
The pipe network could be broken down into three (four) steps, but at the cost of the water level being a visual thing: 1: Check if the network has enough head (pump power) to reach the destination 2: Calculate if input >= output 3: Calculate bottlenecks, i.e. Calcuate if any segments need to exceed 600 for the output to run at 100% and adjust the water output evenly between the things that require it 4: calculate the whole gravity based water filling shenanigans that exist currently, but only for visuals and with less precition
Can you just have everything divided by 2 (pipes and belts) for calculations and just multiply it back by 2 for display? if we do not have that bug for values of 300, so we would only get 597 showing it for player, but everything calculated correctly under the hood?
that would help to some extent, but a much much much better solution is to avoid floating points when possible... in the case of fluids you can just pick a minimum unit to be "1" can be 1 milliliter or 1 liter and just round (in favor of the player) any calculation that results in a partial value (e.g.: potentially from overclocking)
This doesn't actually change anything. Multiplying all values by 2 has the effect of increasing the exponent by 1. The significand will be exactly the same as it was before, and so you'll get exactly the same rounding behavior. The real problem is that we're trying to add too many numbers together, not that we're trying to go to 600 instead of 300.
perform dynamination of values and balance in recipes. for example, you can reduce all liquids by 3 times and have 100 and 200 liters per minute mk1 and mk2, respectively. you can even enter mk3 for 400 liters and the error will not be so big
Integer math is typically much faster than floating point math, which is one reason why “fixed point” exists. Another reason is to eliminate floating point rounding errors such as those apparently causing this bug. Fluid loss caused by floating point rounding is always a nuisance in games with fluids, pipes, and automated crafting. This can be quite noticeable in Factorio, especially with all the fluid stages involved in metallurgy when using some mods. 59.999 molten iron left in the machine when the recipe requires 60 to make that last plate, for example. 😡🤨
Floating point math in modern CPUs is multiple times faster for things like division and other more complex operations. For the easier operations like add, subtract and multiply, the performance will be very similar. Either way, it highly depends on the architecture, available instructions and type of calculations. And this is comparing integer math, _not_ fixed point math. I'm sure fixed point decimals will increase the complexity drastically.
why are the pipes not pressure based instead of having air in them? seems like less calculations would be needed for each pipe then, idk im not a coder. the pipes are frustrating
The bug is simple. If you use mk1 pipes, you get the full 300 fluids/min. If you use mk2 pipes, you'll never get 600 fluids/min. Takeaway: don't use mk2 pipes, ever.
Should you then maybe simulate water flow at a lower level? In goes N water pumps at X, out goes M times Y. Any too little supply then lowers the production of all those buildings equally. Then simulate all the pipes from there. Show throughput, not amount.
My question is why is this a problem for you but not for other factory games like Factorio that push a ton more through pipes than Satisfactory does? If you can 'barely' do 600, maybe you should rethink how you are handling fluids overall.
In the real world you always leave a safety factor for margin of error … this is not unlike the real world when strange turbulent phenomena happen… just leave it as it is and let people adjust to it
