round up fluids reading train inventory

[Ralfinator]

We are also having a lot of trouble with this in our base. We have a single train stop where trains where 3 different liquids arrive (controlled by LTN but that's actually not terribly relevant), and we need to enable only the right pumps. Sadly, the pumps shut off before the tank is empty, due to the rounding.

Given that the devs see problems with always rounding up, I am not sure what the best solution here would be. Some ideas:
- Somehow make it so that containers can never contain fractional amounts of liquids.
- Have a setting at the train stop / fluid tank that controls rounding up vs down.

[Koub]

Or add a way to control fluid flushing by circuit network. This has been requested when fluid flushing was added, and would probably address your issue (with a systematic flush whenever a train leaves the station for example).

[Edit] : viewtopic.php?f=6&t=86216

[darkfrei]

Why fluids cannot be integer as items?

[mrvn]

We are also having a lot of trouble with this in our base. We have a single train stop where trains where 3 different liquids arrive (controlled by LTN but that's actually not terribly relevant), and we need to enable only the right pumps. Sadly, the pumps shut off before the tank is empty, due to the rounding.

Given that the devs see problems with always rounding up, I am not sure what the best solution here would be. Some ideas:
- Somehow make it so that containers can never contain fractional amounts of liquids.
- Have a setting at the train stop / fluid tank that controls rounding up vs down.

Actually that you are using LTN helps avoid this problem. Some while ago I wrote a patch for LTN so the yellow constant combinator on the LTN Stop outputs a -1 signal for any fluid to unload. If you connect your pumps to the yellow constant combinator (not the train stop) and set them to '<liquid> != 0' then they will do the right thing for unloading.

Note: works for loading too if you always request full fluid wagons. Partial loads still need an arithmetic combinator.

[mrvn]

Why fluids cannot be integer as items?

Because the math for moving liquids through pipes would become verry rough if it had to limit itself to integers. An output of 50 liquid for example would not even travel 10 pipe length because it takes 55 units to maintain a one unit gradient for that length. Fluids wouldn't get far enough and be stop-and-go like a traffic jam on a highway.

[Optera]

Why fluids cannot be integer as items?

Because the math for moving liquids through pipes would become verry rough if it had to limit itself to integers. An output of 50 liquid for example would not even travel 10 pipe length because it takes 55 units to maintain a one unit gradient for that length. Fluids wouldn't get far enough and be stop-and-go like a traffic jam on a highway.

With the current unfinished/broken fluid mechanics.

Oxygen not Included for example has more robust and easier to understand fluid mechanics that would work perfectly fine with integer numbers.

[ptx0]

Why fluids cannot be integer as items?

Because the math for moving liquids through pipes would become verry rough if it had to limit itself to integers. An output of 50 liquid for example would not even travel 10 pipe length because it takes 55 units to maintain a one unit gradient for that length. Fluids wouldn't get far enough and be stop-and-go like a traffic jam on a highway.

With the current unfinished/broken fluid mechanics.

Oxygen not Included for example has more robust and easier to understand fluid mechanics that would work perfectly fine with integer numbers.

Same with Satisfactory's pipe mechanics.

[Ralfinator]

Actually that you are using LTN helps avoid this problem. Some while ago I wrote a patch for LTN so the yellow constant combinator on the LTN Stop outputs a -1 signal for any fluid to unload. If you connect your pumps to the yellow constant combinator (not the train stop) and set them to '<liquid> != 0' then they will do the right thing for unloading.

I had in the past checked that combinator to see if it would output the requested amount on an LTN requester (similar to how it does the same on an LTN provider, so I thought that would make a lot of sense -- not just for fluids), and it did not -- I saw no output at all from the yellow combinator. I just tried again, still no luck. Are you sure that patch is working? This is with LTN 1.13.10.

[mrvn]

Actually that you are using LTN helps avoid this problem. Some while ago I wrote a patch for LTN so the yellow constant combinator on the LTN Stop outputs a -1 signal for any fluid to unload. If you connect your pumps to the yellow constant combinator (not the train stop) and set them to '<liquid> != 0' then they will do the right thing for unloading.

I had in the past checked that combinator to see if it would output the requested amount on an LTN requester (similar to how it does the same on an LTN provider, so I thought that would make a lot of sense -- not just for fluids), and it did not -- I saw no output at all from the yellow combinator. I just tried again, still no luck. Are you sure that patch is working? This is with LTN 1.13.10.

https://github.com/Yousei9/Logistic-Tra ... e.lua#L466

Code: Select all

            elseif c.type == "fluid_count" then
              if (c.condition.comparator == "=" and c.condition.constant == 0) then
                --train expects to be unloaded of each of this fluid
                fluidInventory[c.condition.first_signal.name] = -1
              elseif c.condition.comparator == "≥" then
                --train expects to be loaded to x of this fluid
                fluidInventory[c.condition.first_signal.name] = c.condition.constant
              end
            end

The code is still there and it worked for me before. Maybe some of the mod settings are relevant? Check the schedule for the train that it contains a "fluid_count = 0" condition and play with the options a bit.

[Ralfinator]

mrvn you are right -- I have a rail signal right next to the train stop and it is all covered by the train stop graphics, so I accidentally connected the wire to the signal instead of the combinator. There is a "-1" on the combinator, so we'll start using that now instead of our horrible contraption of 40 arithemtic combinators chained to form a "delay line".

Thanks for the help and sorry for the confusion!