Question: What if the provided items are not longer provided?

[ssilk]

Problem: Train stands for minutes, waiting for - let's make a simple example - trees. It wants to transport 258 trees. But meanwhile I had taken 50 trees for feeding my car for example. Now there are only 208 available. But the train still wants 258 and waits until timeout for that.

Other combinations of this problem is very thinkable: Best examples are, when the LTN-signal is generated from roboport. "All items we have available NOW, come and get it, if it is needed somewhere".
But when the train arrives the needed items are taken up by some production. (In that case the station is serviced by robots, not by belt or so.)

Is there a clever way to say: Sorry, you want trees, we brought you all we had, now say good bye and go to the requester. NOW.
?

I mean isn't it obvious: Provided items by station is lower than requested. Couldn't there be a signal like "If train is not filled within 30 seconds, then recalculate the trains request depending on CURRENTLY provided items."
?

[Optera]

How often do you remove items from providers while a train is en route to get items?

In normal gameplay this shouldn't happen often.
Forcing trains out of stations is already covered by stop timeout or circuit control. Once a train leaves a provider delivery list is updated to current train contents.
In the long run it doesn't matter if the wood requester gets a delivery of 258 or 208. It will just request another shipment a little sooner.

[ssilk]

This happens especially for supply-stations and is very often the case with a Logistic Provider/Requester (viewtopic.php?f=214&t=51073#p297648)

The setup is basically so: I create outposts with an included ghost-scanner (mod) and that shows the base supplier, how many items are missing in the outpost. Outposts can provide items, like trees. Or now unused material (unused miners, walls, lasers for example).

So the real need or provision is (more or less) always the roboport-signal minus the ghost-scanner-signal. Which can change during between train runs out of depot and arriving at the provider, cause the items in provider cannot be reserved in a useful way.

I don't know if a "Recalulate now"-signal would solve this kind of problem, but willing to test it out.
If wanted: I can create a save, that can show you the problem in detail.

[Optera]

I found Ghost Scanner to be fairly useless for the intended purpose of automatically building outposts with LTN and went back using pre configured constant combinators or blueprint reader.

The main problem with any LTN - logistic network interface is, items carried by bots vanish from logistic network inventory.
The only ways to somewhat mitigate this is to average readouts over 5-10 seconds or have thresholds above bot carry capacity.

As for Ghost Scanner itself, it might be more usable with LTN if it rounded up to full stacks to be used with stack thresholds.

[ssilk]

The main problem with any LTN - logistic network interface is, items carried by bots vanish from logistic network inventory.

I don't see that as problem: Items are requested. Lets say 1000 belts. First train brings 500. But meanwhile the second train brings another 300 and the last train brings another 300. Which is 100 too much, but as the station works also as provider then the next outpost it can take those 100 belts.

And well, I used preconfigured constants over years. With logistic provider the supply of such outposts is much, much faster, cause you don't need to request items, that you don't need or you request as much, as you need. Works fine for me and brings in most cases more or less exactly the wanted number of items. Exceptions are no problem, as it takes currently 5-10 minutes to build a base like this (compared to 30 minutes from the other method). And we speak here from outposts, which are about 1 minute full speed away.

[mrvn]

As for taking out 50 wood to fuel your car: Don't take items out of a station with yellow light (without adjusting the trains).

BUT: This problem also arises when you don't load count perfect.

The station has 800 wood. 400 woods are requested and a train scheduled. Someone else also requests 400 wood and a second train is scheduled. First train arrives and gets 404 wood. Second train arrives and gets 396 wood and waits.

In most cases the production of new items makes up for any such small incorrectness. Or you have the provider limit larger than the maximum amount that can be loaded (e.g. limit = 8k but reserved stacks makes the maximum 7.8k). But not always, like with wood that only appears when you deconstruct a forest.

So it's a more general problem than just player or bot interference.

Maybe LTN could check the provided count when a train arrives at the station and reduce it to the then available amount?

[ssilk]

Maybe LTN could check the provided count when a train arrives at the station and reduce it to the then available amount?

Hehe, that was the initial question:

I mean isn't it obvious: Provided items by station is lower than requested. Couldn't there be a signal like "If train is not filled within 30 seconds, then recalculate the trains request depending on CURRENTLY provided items."

So, when you set that new signal always to 1, then it is what you suggest.

[mrvn]

Maybe LTN could check the provided count when a train arrives at the station and reduce it to the then available amount?

Hehe, that was the initial question:

I mean isn't it obvious: Provided items by station is lower than requested. Couldn't there be a signal like "If train is not filled within 30 seconds, then recalculate the trains request depending on CURRENTLY provided items."

So, when you set that new signal always to 1, then it is what you suggest.

Or maybe make the schedule:

Code: Select all

    item >= 1000
    and inactivity > 2s
or 7200s passed
or inactivity > 30s

Actually I would remove the "7200s passed" timeout in favor of the "inactivity > 30s". That overall timeout leaves items in the hand of inserters breaking the next train. Or make it "7200s passed and 2s inactivity".

Note: LTN supports leaving on circuit signals (mod setting, default off). So one could add a little circuit logic making the train go when "provided * requested AND NOT train composition == 0".

[Optera]

Note: LTN supports leaving on circuit signals (mod setting, default off). So one could add a little circuit logic making the train go when "provided * requested AND NOT train composition == 0".

That's what I said in my very first reply.

Forcing trains out of stations is already covered by stop timeout or circuit control. Once a train leaves a provider delivery list is updated to current train contents.
In the long run it doesn't matter if the wood requester gets a delivery of 258 or 208. It will just request another shipment a little sooner.

Ssilks problem is resolved.
Feel free to continue to debate for the sake of debating.

[mrvn]

Note: LTN supports leaving on circuit signals (mod setting, default off). So one could add a little circuit logic making the train go when "provided * requested AND NOT train composition == 0".

That's what I said in my very first reply.

Forcing trains out of stations is already covered by stop timeout or circuit control. Once a train leaves a provider delivery list is updated to current train contents.
In the long run it doesn't matter if the wood requester gets a delivery of 258 or 208. It will just request another shipment a little sooner.

Ssilks problem is resolved.
Feel free to continue to debate for the sake of debating.

For the sake of debating

The first was more to say how to send the signal. But I made it to complex. The train composition are virtual signals so the buffer chest of the station should never emit those. You can't have a train position in a chest since it's not an item. So the circuit comes down to "provided * requested == 0". On the other hand with long trains or fluids that could overflow. So better to first reduce all counts with a decider combinator "each > 0 ==> each 1".
And then one can check for not (anything = 2).

provided --- "each > 0 ==> each 1" \
-
requested --- "each > 0 ==> each 1" /

[mrvn]

Note: LTN supports leaving on circuit signals (mod setting, default off). So one could add a little circuit logic making the train go when "provided * requested AND NOT train composition == 0".

That's what I said in my very first reply.

Forcing trains out of stations is already covered by stop timeout or circuit control. Once a train leaves a provider delivery list is updated to current train contents.
In the long run it doesn't matter if the wood requester gets a delivery of 258 or 208. It will just request another shipment a little sooner.

Ssilks problem is resolved.
Feel free to continue to debate for the sake of debating.

For the sake of debating

The first was more to say how to send the signal. But I made it to complex. The train composition are virtual signals so the buffer chest of the station should never emit those. You can't have a train position in a chest since it's not an item. So the circuit comes down to "provided * requested == 0". On the other hand with long trains or fluids that could overflow. So better to first reduce all counts with a decider combinator "each > 0 ==> each 1". And then the traain can leave on not (anything = 2) giving:

Code: Select all

provided --- decider "each > 0 ==> each 1"  \
                                              -- decider "anything = 2 ==> red 1" --- LTN Stop "red = 0"
requested --- decider "each > 0 ==> each 1" /

That actually doesn't look too bad.