Please output what items to unload

[mrvn]

The yellow constant combinator on a LTN stop shows the expected train contents for each train. For loading this shows the items to load and how many. This makes it easy to program inserters to load the right amount. But for unloading the expected amount is 0 so nothing is shown for the item. Only the train composition is left. This makes it hard to build a station that both requests and provides items or requests multiple fluids (because of the rounding problem using train contents for pumps doesn't work directly).

My suggestion would be to output a signal of -1 for each item to unload. The unloading inserters could then be programmed to "anything < 0". Pumps could be set to "fluid < 0" so only the right pump activates. And the loading inserters (or pumps) would not get confused because they already have to stop when "yellow combiantor - train contents < 0".

[Optera]

That was how LTN for Factorio 0.14 worked.
Since 0.15 train stops provide train contents which is more reliable and ups friendly than lua scripted combinator outputs.

[mrvn]

Train contents is difficult to use because:

1) Filter inserters can only be programmed for so many goods. Beyond that you need a lot of combinators and set filter.
2) Filter inserters and stack filter inserters are more expensive then fast inserters and stack inserters.
3) A station might provide and request the same good requiring combining the train contents with the yellow constant combinator.
4) Fluids round down to 0 so pumps will stop early when using the train contents straight of.

I don't buy your argument that my suggestion would impact the UPS. The LUA script already sets the yellow constant combinator to output the train composition. Adding a -1 for every item type being unloaded would be a minimal addition once every time a train stops. I'm not talking about giving an accurate count of how much to unload, only what to unload. All unloading is until empty so there is no need for tick by tick updates. Just set the -1 when the train arrives together with the train composition and remove it when the train leaves together with removing the train composition (that part would actually be free as you already set an empty signal anyway).

[Optera]

The current method requires exactly 1 arithmetic combinator for loading and unloading any number of items.
The old method required adding a memory cell counting against the combinator output to stop unloading.

Loading lists always where and will be static. Updating the output with current train inventory is too expensive for a mod of LTNs scope.
For comparison IS performance drop becomes noticeable around 20 train/car sensors while LTN doesn't perform worse with several hundred stops and trains.

Speaking of IS, use it for controlling pumps according to fluid wagons.

[mrvn]

The current method requires exactly 1 arithmetic combinator for loading and unloading any number of items.
The old method required adding a memory cell counting against the combinator output to stop unloading.

And how would that one combinator look like for a station that requests X solid items and 6 fluids and provides Y solid items and 6 fluids where X, Y and the fluids may overlap (the worst case 1 wagon station)?

Loading needs "yellow constant combinator - train content" so you know what to load and when to stop. And unloading multiple fluids needs a memory cell or the last 0.4 fluids aren't removed. That makes 2 combinators already with nothing to prevent unloading goods you are currently loading.

Loading lists always where and will be static. Updating the output with current train inventory is too expensive for a mod of LTNs scope.
For comparison IS performance drop becomes noticeable around 20 train/car sensors while LTN doesn't perform worse with several hundred stops and trains.

Speaking of IS, use it for controlling pumps according to fluid wagons.

Do you actually read what people write?

I'm not talking about giving an accurate count of how much to unload, only what to unload. All unloading is until empty so there is no need for tick by tick updates.

It doesn't change how many combinator updates you make at all, only what you update when you change it to show the train composition anyway. A train that is supposed to deliver coal should show -1 coal for the duration of the stay no matter what is in the train car.

[Optera]

Loading = combinator - inventory
Unloading = inventory - combinator
I see no problem or complexity.

[mrvn]

Loading = combinator - inventory
Unloading = inventory - combinator
I see no problem or complexity.

Then the train requests 3800 copper ore. The inserters load 3802 copper ore, the other inserter unload to 3796 copper ore, the first load back to 3802 copper ore, the other isnerters unload to 3796 copper ore, ....

After 2 minutes of this the train finally leaves leaving copper ore in the hand of the loading insertes. Then the next train comes requesting 3800 icon ore. It gets loaded 6 copper ore before going into the same loop. 2 minutes later the trains drives some copper ore to the iron ore smelter breaking that.

Next train is tin ore so that gets iron ore and breaks. Next comes silver and that breaks.

Oh the fun this will be.

Similar for fluids: As mentioned fluids round down to 0 at 0.4 leaving fluid in the tank because the pump deactivate early. Fluids can't be removed at the depo. You can't even detect the 0.4 fluids left because they round down to 0 so the tank looks empty to the circuit network. So the fluid wagon keeps going to the next station, can't pick up any fluid and then either keeps driving around doing nothing or unloading the wrong fluid at a station that only expects one fluid (and just pumps without circuits).
And what fun this will be with the wrong fluid in pipes and tanks all over the place.

[Optera]

Did you check my universal station?
It prevents exactly this with only 1 additional combinator.

[mrvn]

Did you check my universal station?
It prevents exactly this with only 1 additional combinator.

So much only needing one combinator. Now it's up to 3 and it still needs a fourth for fluids.

Also: If you know about exactly this problem then why do you suggest a broken solution?

[Optera]

I will not change how LTN displays loading lists.
The current way of displaying loading lists has the same complexity, 1 combinator, for loading and unloading stations while the 0.14 way needed a memory cell for unloading.

[mrvn]

If you don't want to add such a trivial feature that is your right.

But please stop repeating outright falsehoods. As you acknowledged yourself above a loading and unloading station needs more than one inserter. And unloading fluids still needs a memory cell (due to the way the game rounds fluids, nothing you can do there) as mentioned above too. I never suggested going back to the 0.14 way so why do you keep bringing that up?

I hope you change your mind like you did with the network ID.

[Optera]

I never suggested going back to the 0.14 way so why do you keep bringing that up?

Showing items to unload as negative values is exactly how loading lists where displayed in 0.14. To work with that you need to count items moved by inserters, a memory cell and a signal inverter resulting in 3 combinators for a simple unloading station which wouldn't work for fluids.

And unloading fluids still needs a memory cell (due to the way the game rounds fluids, nothing you can do there) as mentioned above too.

LTN never merges fluids exactly because they are rounded stupidly and i had to use wait until empty instead of wait until fluid = 0.
When using 1 station per fluid this allows the use of dumb pumps without any combinator required, which I highly recommend until we get proper working filter pumps.

I hope you change your mind like you did with the network ID.

I added network id since I was presented a valid use case that would benefit a majority of players without breaking any existing designs.
All i see in this thread is rambling about returning to a deprecated display method that was only used in the first place since stops didn't output inventories.

[mrvn]

In case you change your mind I'm talking about the following trivial change to LTN:

Code: Select all

diff --git a/LogisticTrainNetwork_1.7.4/control.lua b/LogisticTrainNetwork_1.7.4/control.lua
index 731a9fc..0e76917 100644
--- a/LogisticTrainNetwork_1.7.4/control.lua
+++ b/LogisticTrainNetwork_1.7.4/control.lua
@@ -1688,13 +1688,13 @@ function UpdateStopOutput(trainStop)
               if c.condition.comparator == ">" then --train expects to be loaded to x of this item
                 inventory[c.condition.first_signal.name] = c.condition.constant + 1
               elseif (c.condition.comparator == "=" and c.condition.constant == 0) then --train expects to be unloaded of each of this item
-                inventory[c.condition.first_signal.name] = nil
+                inventory[c.condition.first_signal.name] = -1
               end
             elseif c.type == "fluid_count" then
               if c.condition.comparator == ">" then --train expects to be loaded to x of this fluid
                 fluidInventory[c.condition.first_signal.name] = c.condition.constant + 1
               elseif (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] = nil
+                fluidInventory[c.condition.first_signal.name] = -1
               end
             end
           end

Changing those 2 lines is all it takes and solves the unloading problem for both solids and fluids making unloading not need any combinators at all. There is no change in UPS or code complexity.