old LTN discussion thread

[ssilk]

Drain fluids into omni barrel, but then you could just as well use omni barrel instead of RailTanker

Yes, I think that this will be fixed in 0.15, too. I search just for a solution for now.
I never realized that the steam engines didn't suck all liquids off. Sounds like a small bug/issue.

And I have an idea, cause the general problem of insufficient space at the requesting station will remain, no matter what (and that made me a lot of other problems that wasn't so fun to solve).

The idea is, that if a train runs into a timeout - cause it could not be unloaded or other reasons - the train will target a "maintenance station". A logistic train stop, just like the depot, but with a new "maintenance" signal. There they could be "maintained" - whatever that means. In my case: unload until really empty, cause if a train is not really empty it could cause a lot of problems.

The point of the maintenance stop is, that they don't have a timeout. A train waits here forever until you feed in a "continue" signal. Maybe the stop can provide a continue signal in the output after the default timeout (which you just need to feed into the input again. But it will not continue automatically!
If he continues he will go to the next depot.

"Other Reasons" could be:
- if the train has not enough fuel left. Maintenance station could refuel. You don't need to built refuel at every depot which is sometimes also quite difficult if you don't have coal nearby. (You need to supply each depot with fuel)
- if you want to take out some trains, reconfigure them or do other things at a "central place".



This "continue" signal is also an interesting thing. Cause I still run sometimes in problems when all trains go to the same depot. The devs want to fix this problem, but I think it is also a logistic problem. And if I would be able to say to a train "continue" with a signal and at the same time I remove the depot signal the train would be forced to find another depot.

So I can create a sensor based on train signals that looks, if too many trains waiting in front of a depot and trigger the "continue" while removing "depot". Which would effectively reduce the queue.

[Optera]

And I have an idea, cause the general problem of insufficient space at the requesting station will remain, no matter what (and that made me a lot of other problems that wasn't so fun to solve).

The idea is, that if a train runs into a timeout - cause it could not be unloaded or other reasons - the train will target a "maintenance station". A logistic train stop, just like the depot, but with a new "maintenance" signal. There they could be "maintained" - whatever that means. In my case: unload until really empty, cause if a train is not really empty it could cause a lot of problems.

The point of the maintenance stop is, that they don't have a timeout. A train waits here forever until you feed in a "continue" signal. Maybe the stop can provide a continue signal in the output after the default timeout (which you just need to feed into the input again. But it will not continue automatically!
If he continues he will go to the next depot.

"Other Reasons" could be:
- if the train has not enough fuel left. Maintenance station could refuel. You don't need to built refuel at every depot which is sometimes also quite difficult if you don't have coal nearby. (You need to supply each depot with fuel)
- if you want to take out some trains, reconfigure them or do other things at a "central place".

Very good points.
That's why I set depots to have inactivity = 2s. Coupled with encoded train composition it's fairly simple to turn depots into such maintenance stations.

To put cleaned out items back into the network my provider/requester from a previous post and ample storage does the trick, it also makes depots become independent of local coal/solid fuel.

2017-03-24-10-40-14-9776976.jpg (521.92 KiB) Viewed 9257 times

This "continue" signal is also an interesting thing. Cause I still run sometimes in problems when all trains go to the same depot. The devs want to fix this problem, but I think it is also a logistic problem. And if I would be able to say to a train "continue" with a signal and at the same time I remove the depot signal the train would be forced to find another depot.

So I can create a sensor based on train signals that looks, if too many trains waiting in front of a depot and trigger the "continue" while removing "depot". Which would effectively reduce the queue.

Do you mean they don't pick free spots in the stacker?
I never had trains not filling stackers when using chain signals or circuit controlled signals from before the first switch down to the first waiting bay.

From what I've seen trains won't move from their parking position (even when deconstructing their current stop) unless they have a 2nd stop in their schedule to go to.

[ssilk]

That's why I set depots to have inactivity = 2s. Coupled with encoded train composition it's fairly simple to turn depots into such maintenance stations.

Yes, I saw that and I made a similar construction (still thinking, that you don't need universal stations, just 3 to 5 different types), but that doesn't guarantee, that the train is empty. And once the train is not empty it is possible that this causes a real logistic brainfuck, cause it unloads at a station an item, that is never thought to be unloaded (cause it just requests one item). The wrong items are moved onto belts and block the whole factory, just cause 20 items are wrong. You get a slowly dying factory. Well, you can say "Use filter inserters to unload", but why? It requests only this items!

And the same is with the liquids: Once emptied the wrong liquid into a nearly empty pump they block the whole factory. Have fun to find that. And there is nothing you can do against it.

This "continue" [...] would effectively reduce the queue.

Do you mean they don't pick free spots in the stacker?

Well, my base is very, very big and so I build depots about every 2-4 kilometers. I cannot build a depot every 2-3 kilometers, that is able to hold the complete fleet of logistic trains. But they try to find the next way to a depot and if they need to decide between 1 kilometers and 4 kilometers they all take the one kilometer depot.

I never had trains not filling stackers when using chain signals or circuit controlled signals from before the first switch down to the first waiting bay.

That is not the problem.

From what I've seen trains won't move from their parking position (even when deconstructing their current stop) unless they have a 2nd stop in their schedule to go to.

Awwww... ... well, perhaps we can wait until 0.15 and see then, how this will behave, but I think there is not much change. It's basically the same problem as with the logistic bots that they tend to stack at some roboports only. But we need to be able to distribute the trains equally over the map and LTN should try to choose the nearest train if possible and "refill" the waiting position at that depot.

[Optera]

That's why I set depots to have inactivity = 2s. Coupled with encoded train composition it's fairly simple to turn depots into such maintenance stations.

Yes, I saw that and I made a similar construction (still thinking, that you don't need universal stations, just 3 to 5 different types), but that doesn't guarantee, that the train is empty. And once the train is not empty it is possible that this causes a real logistic brainfuck, cause it unloads at a station an item, that is never thought to be unloaded (cause it just requests one item). The wrong items are moved onto belts and block the whole factory, just cause 20 items are wrong. You get a slowly dying factory. Well, you can say "Use filter inserters to unload", but why? It requests only this items!

And the same is with the liquids: Once emptied the wrong liquid into a nearly empty pump they block the whole factory. Have fun to find that. And there is nothing you can do against it.

Nothing except always using filter inserters for loading and unloading.
Multi item providers also need a way to unload incorrectly loaded items (until 0.15 allows count perfect loading)

Well, my base is very, very big and so I build depots about every 2-4 kilometers. I cannot build a depot every 2-3 kilometers, that is able to hold the complete fleet of logistic trains. But they try to find the next way to a depot and if they need to decide between 1 kilometers and 4 kilometers they all take the one kilometer depot.

Every few km seems a bit excessive.
As you see having the same name on separate depots can't work. Trains will always try to go to the nearest even if a few km down the line slots are free.
There's no way LTN could change that without starting to rename stops, which I won't do since it's an ugly hack.
Once the api provides pathfinder data and allows sending trains to a specific stop unit_number it might be worth thinking about something like that.

[ssilk]

Nothing except always using filter inserters for loading and unloading.

Again: What's with the liquids? Ain't gona work.

Multi item providers also need a way to unload incorrectly loaded items (until 0.15 allows count perfect loading)

Maybe you don't understand me. I think there are always situations, where something can go wrong with LTN, which are even by a "profi-player" not foreseeable.
And I don't want to make the stops super flexible, cause that just makes problems with the loading and calculating the right amount of items to order. Making the provider/requesters more intelligent means, something ugly can happen.
(for example I tried to understand your LTN Provider from last page, but I even couldn't find out how to load that thing).

As you see having the same name on separate depots can't work. Trains will always try to go to the nearest even if a few km down the line slots are free.

That is exactly, what I want to avoid, cause that is some kind of micromanagement that is hard to maintain if you have more than 30-40 trains.

There's no way LTN could change that without starting to rename stops, which I won't do since it's an ugly hack.

Of course. That's not what I had in mind... I'm not sure, what I had in mind, so I think I shut up here...

BTW, if you are interested: I posted the save in viewtopic.php?f=5&t=42939&p=251338#p251338

[Optera]

BTW, if you are interested: I posted the save in viewtopic.php?f=5&t=42939&p=251338#p251338

As I said, there's nothing I could do to make that work. Train pathfinding just can't handle what you built there.
Either make one big central depot or rename the small depots and assign certain trains to those.

Your signaling needs improving.
trains from west constantly blocked the crossing between your depots, trains from south constantly blocked the crossing going NE.
- Always have at least one train length between junctions so left turning trains don't block tracks.
- Block signals should only be used as entry point for blocks where trains can park without blocking other tracks, use chain signals for everything else.

[ssilk]

BTW, if you are interested: I posted the save in viewtopic.php?f=5&t=42939&p=251338#p251338

As I said, there's nothing I could do to make that work. Train pathfinding just can't handle what you built there.
Either make one big central depot or rename the small depots and assign certain trains to those.

I slept over it and meanwhile I see that identical. I hope for an improvement with the named thread or 0.15.

Your signaling needs improving.
trains from west constantly blocked the crossing between your depots, trains from south constantly blocked the crossing going NE.
- Always have at least one train length between junctions so left turning trains don't block tracks.
- Block signals should only be used as entry point for blocks where trains can park without blocking other tracks, use chain signals for everything else.

Haha, that part of the factory was the first one, my first attempt was to have only LCC-trains. That was in December. I thought it is a good example of growing design.

But when you wait about 15 minutes the jam will dissolve by itself and reappears at the iron smeltery. So seen the design of that station is not so bad, cause it doesn't deadlock, even when completely jammed.

[gridstop]

Is it possible to have it not recalculate requests while a train is actively unloading? I found that if I put ANY logic between the chests & the input lamp, I get weird behavior because LTN seems to keep track almost tick-by-tick as items are unloaded from the train, but that the input didn't react fast enough, so I often get extra little orders appear while the train is unloading.

What I'm doing and why:
I'm trying to allow a requester to have different minimum delivery sizes for different items. So I can have a min request of 1-5 for expensive, rarely requested items, and for higher throughput items min request sizes of a few hundred or similar. For example, an outpost that gradually burns through piercing ammo while very occasionally needing a few replacement turrets or light oil barrels.

I came up with using a small register to store the request (sent in in a single tick pulse) and feed it to the LTS, and then when the train arrives the inserters pulling it out pulse their hand contents which get subtracted from the register. From the train stops perspective it should behave the same. A negative number pops up and holds its value, then when the train unloads it decreases with the unloads until it goes back to zero. Yet somehow I get weird extra orders of like 8-16 items that pop up while the train is unloading, even though the request is monotonically decreasing. So even a single combinator delay between the unloaders and input light causes it to place extra orders?

I've had some luck by suppressing the request signal to the light whenever the loco signal is present, but it seems more complicated than it should have to be.

[Optera]

Is it possible to have it not recalculate requests while a train is actively unloading? I found that if I put ANY logic between the chests & the input lamp, I get weird behavior because LTN seems to keep track almost tick-by-tick as items are unloaded from the train, but that the input didn't react fast enough, so I often get extra little orders appear while the train is unloading.

What I'm doing and why:
I'm trying to allow a requester to have different minimum delivery sizes for different items. So I can have a min request of 1-5 for expensive, rarely requested items, and for higher throughput items min request sizes of a few hundred or similar. For example, an outpost that gradually burns through piercing ammo while very occasionally needing a few replacement turrets or light oil barrels.

I came up with using a small register to store the request (sent in in a single tick pulse) and feed it to the LTS, and then when the train arrives the inserters pulling it out pulse their hand contents which get subtracted from the register. From the train stops perspective it should behave the same. A negative number pops up and holds its value, then when the train unloads it decreases with the unloads until it goes back to zero. Yet somehow I get weird extra orders of like 8-16 items that pop up while the train is unloading, even though the request is monotonically decreasing. So even a single combinator delay between the unloaders and input light causes it to place extra orders?

I've had some luck by suppressing the request signal to the light whenever the loco signal is present, but it seems more complicated than it should have to be.

Your register seems over-engineered to me.
All I do for having multiple items in different quantities and delivery sizes is add one decider combinator per item between storage and lamp.

At this stop i want used air filters delivered at 200 and the rest at 10k

2017-03-26-07-43-18-1723868.jpg (83.17 KiB) Viewed 9188 times

Left Constant Combinator holds total desired items * -1
Right CC has the control signals (Delivery Size signal should be <= the smallest x)
Decider combinators use item < -x = item count, where x is the delivery size

[Helex288]

Hi all, currently i'm frequently having the issue that LTN is spamming the notification corner.
Anyone know why this is happing so i can prevent it?

Note: i have stations supplying the produtcs and they all worked and they suddenly it starts spamming it.

Sorry if this has been answered before.

BTW, i really love this mod!

LTN issue.png (3.9 MiB) Viewed 9177 times

[steinio]

renaming a stop resets lamp to green and triggers another delivery fixed in 0.9.5

This seems not to be fixed, because renaming train stops causes a new delivery to the new name.
I guess because of this it's not mentioned in the changelog and only in the to do list.

Greetings steinio

[zobytwo]

Hi all, currently i'm frequently having the issue that LTN is spamming the notification corner.

I've got the exact same issue too. It keeps spamming as long as there is at least one idle train and at least one unmatched demand. I can provide a savegame if required.

[gridstop]

Your register seems over-engineered to me.
All I do for having multiple items in different quantities and delivery sizes is add one decider combinator per item between storage and lamp.

I do tend to over-engineer things, it is true.

The problem is if the min request size is small enough that that much might be consumed while the delivery is in progress. In that example, if you order 10k red circuits, but if the train takes a minute to go get the circuits and deliver them, and you use 200 circuits in that time, you'll get another order of 200. So if the disparity is large it's a problem. Say I want to order light oil barrels in quantity 20 because I hardly ever go through a barrel and I don't like stockpiling too much, but I order bullets in quantity 500, if I use another 20 bullets while the first train is delivering, I'll order a train for 20 bullets.

Basically my register takes your method but lets us account for deliveries that have already been placed. So we know 10,000 red circuits are coming so we realize we're only at -200 not -10200, and keep sending -10000 to the LTS instead of -10200. If we somehow consumed another 10k before the delivery, it would instantly jump to -20000.

[Sicarius]

The problem is if the min request size is small enough that that much might be consumed while the delivery is in progress. In that example, if you order 10k red circuits, but if the train takes a minute to go get the circuits and deliver them, and you use 200 circuits in that time, you'll get another order of 200. So if the disparity is large it's a problem. Say I want to order light oil barrels in quantity 20 because I hardly ever go through a barrel and I don't like stockpiling too much, but I order bullets in quantity 500, if I use another 20 bullets while the first train is delivering, I'll order a train for 20 bullets.

I was thinking the same thing when I saw that decider combinator workaround.

What I would like to see is a signal for minimum % delivery. eg. don't send a delivery unless I am below, say, 50% stock of any individual item. Would work great for those items where ratios in the recipe are really high (like blue underground belt with a 20:1 ratio of gears to red underground).

[Sicarius]

EDIT: Also, has anyone got the "Ignore Minimum Delivery Size" condition input working? I have mine set on the provider, as the first post indicates, but a train is never dispatched to the provider, unless I increase the request to above the "Minimum Delivery Size" condition

Deliveries are only generated when requesters fall below min Delivery Size threshold.
Best Effort and Ignore min Delivery Size change which providers are eligible.

I feel like my understanding of "Ignore min Delivery Size" is incorrect.

I though that it would mean that a delivery would be dispatched to top up a requester if a provider had "Ignore min Delivery Size" set.

Are you saying it actually means that if a requester drops below Min Delivery Size, it will schedule a delivery from the "Ignore min Delivery Size" provider even if it does not have enough to satisfy the minimum delivery?

[Light]

The problem is if the min request size is small enough that that much might be consumed while the delivery is in progress. In that example, if you order 10k red circuits, but if the train takes a minute to go get the circuits and deliver them, and you use 200 circuits in that time, you'll get another order of 200. So if the disparity is large it's a problem. Say I want to order light oil barrels in quantity 20 because I hardly ever go through a barrel and I don't like stockpiling too much, but I order bullets in quantity 500, if I use another 20 bullets while the first train is delivering, I'll order a train for 20 bullets.

I was thinking the same thing when I saw that decider combinator workaround.

What I would like to see is a signal for minimum % delivery. eg. don't send a delivery unless I am below, say, 50% stock of any individual item. Would work great for those items where ratios in the recipe are really high (like blue underground belt with a 20:1 ratio of gears to red underground).

If you're requesting 1,000 copper plate with a minimum delivery size of 500, then when you have under 500 copper plate at the requesting station it will make a delivery of what's missing. This essentially acts as a buffer to prevent the station from drying out. Setting a request of 5,000 with min delivery of 2,000 will always ensure at least 3,000 of that item is at the station at all times, which is useful if the train is far away and it's eating supplies very rapidly.

[Optera]

renaming a stop resets lamp to green and triggers another delivery fixed in 0.9.5

This seems not to be fixed, because renaming train stops causes a new delivery to the new name.
I guess because of this it's not mentioned in the changelog and only in the to do list.

Edit: That's not what's written in the changelog.

0.9.5
- lamp shows status "active delivery" (yellow) reliable after changing stop name or removing train during delivery
- stacker depots no longer trigger delivery time out warnings

Are you saying it actually means that if a requester drops below Min Delivery Size, it will schedule a delivery from the "Ignore min Delivery Size" provider even if it does not have enough to satisfy the minimum delivery?

Exactly. It will still rank providers by number of deliveries, provider priority, number of available items.

The problem is if the min request size is small enough that that much might be consumed while the delivery is in progress. In that example, if you order 10k red circuits, but if the train takes a minute to go get the circuits and deliver them, and you use 200 circuits in that time, you'll get another order of 200. So if the disparity is large it's a problem. Say I want to order light oil barrels in quantity 20 because I hardly ever go through a barrel and I don't like stockpiling too much, but I order bullets in quantity 500, if I use another 20 bullets while the first train is delivering, I'll order a train for 20 bullets.

You could try using truncation of arithmetic combinators to get custom delivery size stepping.
(missing items / desired delivery size) * desired delivery size
bullets with 50 missing: 50/500=0, 0*500=0
barrels with 23 missing: 23/20=1, 1*20=20

What I would like to see is a signal for minimum % delivery. eg. don't send a delivery unless I am below, say, 50% stock of any individual item. Would work great for those items where ratios in the recipe are really high (like blue underground belt with a 20:1 ratio of gears to red underground).

The idea is nice, but LTN has no way of knowing how much 100% are. It takes two inputs per item to calculate current percentages.
current% = currentCount/maxCount*100
I have no idea how I could implement a 2nd input without utterly confusing players.

[Sicarius]

What I would like to see is a signal for minimum % delivery. eg. don't send a delivery unless I am below, say, 50% stock of any individual item. Would work great for those items where ratios in the recipe are really high (like blue underground belt with a 20:1 ratio of gears to red underground).

The idea is nice, but LTN has no way of knowing how much 100% are. It takes two inputs per item to calculate current percentages.
current% = currentCount/maxCount*100
I have no idea how I could implement a 2nd input without utterly confusing players.

Yup, I derped that one. I forgot that the request is subtracted from the buffer with both connected to the lamp so it doesn't see the absolute value of the request.
The only way I can see to do that without adding a second input would be to be able to set your requests on the green constant combinator built into the logistic stop.

[Optera]

0.9.11 - New message filter handling
A lot of players seem to have problems setting message_filter_size to reasonable levels when using bobs or angels.
Messages are now suppressed for message_filter_age (default 5min) before showing up again. message_filter_size was removed.

[XOffshore]

At least 0.9.7 and 0.9.9, not tested with 0.9.11.
I had a strange situation in which no iron-ore deliveries were in place. After some reconstructing I finally figured out that one of iron-ore providers had accidentally been set up with provider priority signal = 100 (and no other stations had this signal at all). But this station also had 2 more conditions: it had no connection to the rail network and also had min/max train length set to 2 (but all other trains in my network are 3..5). I cannot post a test savegame (that state already lost), but can someone confirm this (buggy) behavior?