Output combinator only returns the query. When delivery, returns -1. …

[dvilker]

…Can be disabled for backward compatible. Disabled by default.

Now the Output combinator is introducing some confusion. It reflects the request, but it also reflects the contents of the train that arrived at the supply station in the same way.

I'm proposing a fix for this issue and a setting to allow legacy games to be played.

[dvilker]

https://github.com/Yousei9/Logistic-Train-Network/pull/245

The fix in the code is the same. But the motivation is different. My motivation is that the Output combinator doesn't lie. This will help, among other things, to deal with a jam in the inserter (it won’t solve it, but it will help). Now the output combinator works quite unpredictably. Why he gives away the contents of the train is not clear. And it is not clear why this might be necessary. I proposed a solution that will not break existing games, but will make the work of the combinator more understandable and logical.

[0ptera]

The output is always showing the expected train content on departure. It works for loading, unloading and depots equally. How is that illogical?

This pull request doesn't contain any reason to change a behavior that worked for the last 3 years.

[dvilker]

Thank you for your attention.

If an empty train arrives at the supplier's station, and something is hanging in the inserters, then it gets into the train BEFORE updating the output combinator.

And as a result, when the output combinator is updated, there is already unnecessary goods on the train. And this unnecessary product is reflected in the combinator.

If you remove this signal, then unnecessary goods can be unloaded from the train. This greatly complicates the multi-goods loading station.

[dvilker]

I suggested a solution that can be customized. In order not to break existing games.

[dvilker]

Now we have to make filters. As a comparing combinator [ >= 72] -> []. Therefore, getting a signal from the train seems illogical.

[0ptera]

As fix to inserters stuck holding items that could work indeed.

I'd simply make a map setting changing providers to treat all cargo outside the loading schedule as unwanted. The whole reason LTN doesn't already do this by default is so LTN trains can be abused to also deliver unscheduled cargo.

[dvilker]

The output is always showing the expected train content on departure.

By the way, this is a bit untrue. You have -1 for liquids at the unloading station.

When I did this PR, I paid attention to this and in PR I did the same for cargo. I found it very logical.

Please make some kind of compromise. Let's call it "I'd simply make a map setting changing providers to treat all cargo outside the loading schedule as unwanted.". I am ready to make all the necessary changes to the PR so that you just have to accept them.

[dvilker]

Thanks a lot!

There remains a small discrepancy. At unloading stations, the signal is -1 for liquids, and 0 for cargo.

[0ptera]

There remains a small discrepancy. At unloading stations, the signal is -1 for liquids, and 0 for cargo.

Those are different issues on different cargo types at different stations:

• Item Provider: Inserter sticking items into wagons before scripts have a chance to process the additional cargo
• Fluid Requester: Circuit network rounding 0.4 down to 0 resulting in circuit controlled pumps leaving residue inside tankers

I see no reason to mix those together.