old LTN discussion thread

[Optera]

Hello,

as i was one of the people who burned for this mod instead of some combinator contraptions i now tried to play with it and setted up a simple coal delivery route.
It works plently.

Now i want to set up a liquid route for Py's Creosote.
My depot has two logistic stops called Depot for solids and Depot for liquids and i scheduled the trains for each station.

How can i different if the provider/requester station needs a liquid or a solid train?

Greetings steinio

You need RailTanker for liquid transport. Once installed LTN will pick a train with rail tanker for liquids by itself. Just hook the storage tanks up to the LTN-stop as you would do with chests for items.
If you need to see how it's done download the demo from OP.

PS: I don't recommend mixing tanker with normal cargo wagons. While LTN itself should have no problem dispatching mixed trains (leaving either tanker or cargo wagon emtpy), the station design needed to service mixed trains can be a real headache.

[Anson]

1- no transports until requester has less than 10k ore
2- when transports start, they are done with 2k delivery size
3- transports continue until there are 30k ore
4- transports don't stop when (after a few transports) the amount is back between 10k and 30k

best effort = true
item = -30k
min shipment size = 20k

Will start a 20k order when item is lower than 10k. Best Effort will split the order in multiple shipments filling up all but the last train.

1- yes: transports start at 10k
2- is this fixed now, or (when using best effort) could there be shipments of less than 2k per train if providers are not full enough?
3/4- no: this will start a new order only when the amount is below 10k again, including the current order. thus at the end of the current order the amount will be anything between 10k and 30k, but almost certainly not above the desired threshold of 30k.
summary: you achieve something similar, but still not the same

... to specify exact patterns (bitmasks) for engines and wagons, but that would probably be much too complicated to implement, to understand, and to use, ...

but I wonder who even makes use of the current encoded composition signal?
Feeding a binary encoded signal for valid trains is way above the combinator knowledge of most players.

just what i said/meant
the current use of the encoded signal is probably mostly to copy your blueprint for refueling engines and emptying all other wagons.
other uses are more complicated than necessary 95% of the time, with an additional 4.99% that can be solved with the new min and max train lengths.

discussion about separating depot into refueler-stacker-depot

By outputing the encoded train composition LTN already allows for a more versatile and complex refueling system than smart trains.
I can see how a single refueling station would be less effort than having one at every depot.

there are two aspects to refueling: when to refuel, and how to refuel.
LTN is absolutely superior when it comes to "how to refuel", by exactly matching inserters with engines, etc.
but how do you decide "when to refuel" with LTN ? i think this is not done at all, and instead you rely on trains being refueled automatically at the depots. and thus you need to have all the refueling setup at every single depot stop. when you have 20, 50 or 100 trains, it gets quite complicated to set up a stacker with 100 depots, 100 refueling setups and 100 wagon cleaning setups.

My reasoning against dedicated refueling is this. Most networks need to remove left over items from trains somewhere. Best place to do that is the depot as all trains will go there. That means you end up with a unloading mechanism at every depot so it's just a matter of adding some more inserters and chests to add a refueling system.

that might be true, but i consider this "fixing the symptoms instead of fixing the problem".
trains shouldn't have some "leftovers" that need to be cleaned, either by having dedicated stations for single item types, by loading a little less than full loads (not leaving items in the hands of inserters), etc.

also, refueling wouldn't be done like SmartTrains "on demand only", but be a forced step, simply separating the existing depots into refueler, stacker and depot. if still necessary, the cleaning of wagons could be done together with refueling at the refueler stop.

my main motivation was the 20-train-depot that i had built. it required 20 depot stops (with 20 refuelers and 20 unloaders), causing long paths from the depots to a common exit of this stacker-depot, etc. and when i tried using only 1 or 2 depot stops with a stacker in front of it, i was told that that wouldn't work since all waiting trains would get timeouts on their orders because an order is only finished by returning to a depot.
by separating the depots into refueler and depot, and having orders valid from depot to refueler, it would leave lots of options what to do with trains in between refueler and depot, how to stack them, how to route them so that they can wait right in front of the depot, etc.
currently, it is not even possible to have two trains on a single track with a single depot. the second train could timeout while waiting behind the train that is already at the depot.

Having dedicated refueling station(s) begs a lot of questions:

-- Is this even a feature that will be used by a majority of players?
if the refueler stop is done similar to the depots (with a logical signal), people can simply put refueler signal and depot signal on the same station and do everything as they do now. but by putting it on separate stops, imho it would be very easy (to understand and to use) to send trains from the depot to pickup and drop station, then end the route at the refueler and stack trains somehow afterwards. how many people would use the system probably depends on how many trains people have, and how big their depot-stackers would be in comparison to a simple stacker in front of a small depot setup.

-- Is it really less effort to ensure all possible stations and depots are reachable from the
-- refueling station than stamping down some chests and inserters in existing depots?
(existing depots? I am thinking about how to design networks, not necessarily updating old networks. and by putting logical signals "this is a refueler" and "this is a depot" on the same station, nothing should change for existing setups)

by setting up a refueler (maybe with 2 or a few lanes), followed by a stacker (any layout) and then the depot (maybe 2 or a few lanes), reachability would be no different than it is now. it only would eliminate the need to build a giant depot with enough lanes for *all* trains.
if all trains are identical (eg all L-CCC), the most simple "stacker" would be to have 1, 2 or 3 lanes and the trains waiting behind each other with normal signals to separate them. currently, they each need a separate stop, and each of them needs to be reachable from the network, as well as the network needs to be reachable from each of them. this is a lot more difficult to setup, requires a lot more space, and probably is slower too because of longer pathes that the trains have to travel.

-- How would LTN ever know which refueling station to use?
the same as for depots now: a logical signal says "this is a refueler" or "this is a depot"
i do NOT suggest anything like SmartTrain's refueler method.

btw: i just see that i never have tested how LTN currently behaves when there are several depot stops (marked with the logical signal) but different names. also not tested whether and how depot stops can be used for different train lengths (not at all? eg: do i have to build all twenty depot stops for the max train length of 10 engines+wagons when there are mostly 17 LC trains and only 3 LLL-CCCCCCC trains?)

-- Are we back to using backer names and allow only one specific naming scheme for
-- for refueling across all possible forces?
similar to currently sending trains to different depots:
either not necessary, or at least not more difficult than it currently is.

-- Why build a stacker in front of the depot?
you assume that a stacker consists of several parallel lanes, each for a single train only, each accessible from the network (through some "spaghetti" when done for lots of trains), each train able to directly go to the network (through some "spaghetti" when done for lots of trains).
this eliminates all other kinds of more simple and more complex stackers, eg a single (or very few) lanes where trains wait behind each other.
having a simple depot (1 or a few lanes) directly at the main track sends them into the network quickly, while trains from the stacker behind it can slowly refill that final real depot

-- Just plant a LTN-stop at every stacker rail. :roll:
how do you do that in the simplest form of having one lane where two trains wait behind each other?

suggestion - LTN already before blue science

Thanks for reminding me. I think I said I'd move it to a pure red/green tech, but somehow forgot about that. It will use a lot of red/greens and while at it i might also add some of bobs science requirements if you use that. :twisted:

I'll start using that immediately when loading my map the next time
(using angels+bobs, already researched most red/green techs, and still barely have setup smelting, circuit generation, etc)

[thelordodin]

A bug:

Attempt to perform arithmetic on global 'stopIdStartIndex' (a nil value)
control.lua:224

Tried to investigate:
stopsPerTick is also nil.

Repeatable.
When happens: placing my first Logistic Train stop in an existing game.

Everything works in new game in creative mode.
So it seems there is a problem with init, and not a compatibility issue.

I'm ready to give any additional info to fix the problem.

[Optera]

A bug:

Attempt to perform arithmetic on global 'stopIdStartIndex' (a nil value)
control.lua:224

Tried to investigate:
stopsPerTick is also nil.

Repeatable.
When happens: placing my first Logistic Train stop in an existing game.

Everything works in new game in creative mode.
So it seems there is a problem with init, and not a compatibility issue.

I'm ready to give any additional info to fix the problem.

Thanks for the report. Fixed in 0.8.1

[Optera]

is this fixed now, or (when using best effort) could there be shipments of less than 2k per train if providers are not full enough?

What do you mean by fixed? This always was a core feature.

summary: you achieve something similar, but still not the same

Right you end up with 20k in storage. It would even work with best effort off btw

the current use of the encoded signal is probably mostly to copy your blueprint for refueling engines and emptying all other wagons.
other uses are more complicated than necessary 95% of the time, with an additional 4.99% that can be solved with the new min and max train lengths.

If you calculate like this that leaves 0.1% use for another encoded signal.
Until I hear a lot of players asking for encoded train access restriction I won't implement it. Should it become a feature, min/max train length would be removed as redundant.

there are two aspects to refueling: when to refuel, and how to refuel.
LTN is absolutely superior when it comes to "how to refuel", by exactly matching inserters with engines, etc.
but how do you decide "when to refuel" with LTN ? i think this is not done at all, and instead you rely on trains being refueled automatically at the depots. and thus you need to have all the refueling setup at every single depot stop. when you have 20, 50 or 100 trains, it gets quite complicated to set up a stacker with 100 depots, 100 refueling setups and 100 wagon cleaning setups.

my main motivation was the 20-train-depot that i had built. it required 20 depot stops (with 20 refuelers and 20 unloaders), causing long paths from the depots to a common exit of this stacker-depot, etc. and when i tried using only 1 or 2 depot stops with a stacker in front of it, i was told that that wouldn't work since all waiting trains would get timeouts on their orders because an order is only finished by returning to a depot.

It's more complicated to stamp a working cleaning/refueling Depot BP 100 times than 10 times?
You can create one depot per train composition, which allows for very stupid cleaning/refueling. My megabase needs at most 12 L-6C-L ore trains for 2 rockets/min, no idea why you would need 100 in one depot.

My 16 Track Ore Train Depot

16 track Depot

2017-01-01-17-48-38-8544255.jpg (695.19 KiB) Viewed 8854 times

Compared to how long they take to get to the outposts the time it takes them on the main line is really neglect able.

by separating the depots into refueler and depot, and having orders valid from depot to refueler, it would leave lots of options what to do with trains in between refueler and depot, how to stack them, how to route them so that they can wait right in front of the depot, etc.
currently, it is not even possible to have two trains on a single track with a single depot. the second train could timeout while waiting behind the train that is already at the depot.

if the refueler stop is done similar to the depots (with a logical signal), people can simply put refueler signal and depot signal on the same station and do everything as they do now. but by putting it on separate stops, imho it would be very easy (to understand and to use) to send trains from the depot to pickup and drop station, then end the route at the refueler and stack trains somehow afterwards. how many people would use the system probably depends on how many trains people have, and how big their depot-stackers would be in comparison to a simple stacker in front of a small depot setup.

by setting up a refueler (maybe with 2 or a few lanes), followed by a stacker (any layout) and then the depot (maybe 2 or a few lanes), reachability would be no different than it is now. it only would eliminate the need to build a giant depot with enough lanes for *all* trains.
if all trains are identical (eg all L-CCC), the most simple "stacker" would be to have 1, 2 or 3 lanes and the trains waiting behind each other with normal signals to separate them. currently, they each need a separate stop, and each of them needs to be reachable from the network, as well as the network needs to be reachable from each of them. this is a lot more difficult to setup, requires a lot more space, and probably is slower too because of longer pathes that the trains have to travel.

the same as for depots now: a logical signal says "this is a refueler" or "this is a depot"
i do NOT suggest anything like SmartTrain's refueler method.

btw: i just see that i never have tested how LTN currently behaves when there are several depot stops (marked with the logical signal) but different names. also not tested whether and how depot stops can be used for different train lengths (not at all? eg: do i have to build all twenty depot stops for the max train length of 10 engines+wagons when there are mostly 17 LC trains and only 3 LLL-CCCCCCC trains?)

The API for train schedules and pathing is very limited.

• There is no way for me to determine which refueling station is "in front" of which depot.
• Train Schedules only know stop names while LTN internally uses UIDs. Trains find their way back to their starting depot because i save the name. If you place two stops with the same name and sent the depot signal to only one, trains might go to the one that is not a depot, time out and wait there forever.
• Trains don't discern between different forces when trying to go to station name xyz. Any station with the same name across different forces potentially breaks LTN as it would break manually edited schedules.

Given the limitations mods have to work with, the most sane way to add refueling stations is to do it like SmartTrains refueling station.
Dynamically adding the refueling station with matching train length and most stored fuel at the end of the schedule only if remaining fuel is below a configurable threshold.

If you name them differently you can have one depot per train configuration. trains will always return only to their starting depot.

-- Why build a stacker in front of the depot?
you assume that a stacker consists of several parallel lanes, each for a single train only, each accessible from the network (through some "spaghetti" when done for lots of trains), each train able to directly go to the network (through some "spaghetti" when done for lots of trains).
this eliminates all other kinds of more simple and more complex stackers, eg a single (or very few) lanes where trains wait behind each other.
having a simple depot (1 or a few lanes) directly at the main track sends them into the network quickly, while trains from the stacker behind it can slowly refill that final real depot

-- Just plant a LTN-stop at every stacker rail.
how do you do that in the simplest form of having one lane where two trains wait behind each other?

LTN is intended to have trains parked in the depot. With your setup you will get delivery time outs.
Space needed is basically the same between storing trains back to back and next to each other. Space is something factorio has in abundance anyways.

[Anson]

What do you mean by fixed? This always was a core feature.
Right you end up with 20k in storage. It would even work with best effort off btw

"core feature": yes, that's why i was wondering how you want to achieve the goal to have only trains with minsize delivering the ore, and end up with 30k+ ore, with the settings "besteffort=true", "item=-30k" and "minsize=20k".
"end up with 20k": no, in the end (after delivering 20k), there may be any amount between 10k and 30k, not less than 10k since then another order for 20k would be given. and not more than 30k since start was at 10k and order was for 20k. and delivering always 2k chunk would not be possible with besteffort true.
goal 1 (start at <10k) done, but goal 2 (always deliver 2k batches) failed, and goal 3 (end up with 30k+) also failed.

other uses are more complicated than necessary 95% of the time,
with an additional 4.99% that can be solved with the new min and max train lengths.

If you calculate like this that leaves 0.1% use for another encoded signal. :P

hehe, even 0.01% only :-)
that's why i think that min and max length are needed (to get those 4.99%),
but the result is good enough without more encoded signals, etc.

It's more complicated to stamp a working cleaning/refueling Depot BP 100 times than 10 times?

yes. not the depot itself, but all the connections that are needed for each depot stop, eg the need for bots to fill the coal chests for the trains, roboports between the many rails, or belts that need space. all this often can't completely be included in blueprinbts. also look at all those crossings, splits and merges between your depots and the mainline, for the few trains that you have.

My megabase needs at most 12 L-6C-L ore trains for 2 rockets/min, no idea why you would need 100 in one depot.

because i like trains :-)
in openttd, i sometimes used LC trains (or even trains where the engine+wagon were one unit instead of separate L-C), and here i might use something similar, eg when distributing production of green/red/blue circuits, etc to separate "towns", or when handling dozens of ores and fluids/gases with angels+bobs.
of course, you can reduce the network, and you might even be able to do it with no trains, but i want the option to play one way or another, and not be forced to do it in only one "correct" way.

Compared to how long they take to get to the outposts the time it takes them on the main line is really neglect able.

it's not only the time to leave the depot when there is a single train, but lots of trains which share the area between depots and mainline cause jams and that adds up in time.

Train Schedules only know stop names while LTN internally uses UIDs.
Trains find their way back to their starting depot because i save the name.

save the name? or the UID?
does that mean that trains ignore their schedule and go to a specific depot even when there are several depot stations with the same name ? and if they are smart enough to go back to their own depot, why would they be able to go to another station with the same name as you wrote next:

If you place two stops with the same name and sent the depot signal to only one, trains might go to the one that is not a depot, time out and wait there forever.

Any station with the same name across different forces potentially breaks LTN as it would break manually edited schedules.

i don't play much multiplayer, and none yet with big bases and trains. i didn't know that, but i would consider it to be a bug in factorio since it opens lots of possibilities for enemies and griefers.

if you name them differently you can have one depot per train configuration.
trains will always return only to their starting depot.

important to know!!!
is that documented somewhere ?

this would also mean that i really need to have as many depot stops as i have trains ?
and if i setup a new train and have to send it to a depot, to which depot will it go (factorio rule: nearest depot with that name, right?) and where will the other train go that wants to return to its own station that is now blocked?
i think I'll have to reload the old testmap and watch closely which train goes back to which station ...

Why build a stacker in front of the depot?
Just plant a LTN-stop at every stacker rail. :roll:

the above rule that i just learned (return to your own depot) changes a lot of my reasoning. it makes some suggestions invalid (eg that a refueler can simply be separated from the depot, trains can end their route at a refueler instead of their own depot, etc), and it also opens lots of new possibilities if used properly.

btw: which train is sent from its depot to do a delivery when a new order is just created ?
does LTN look at the distance between the provider station and the nearest depot?
that would allow having at least one depot in front of each outpost (provider) for faster pickup, and trains from somewhere else doing the delivery when the train is still on its last tour ...

the simplest form of having one lane where two trains wait behind each other?

LTN is intended to have trains parked in the depot. With your setup you will get delivery time outs.

that was the whole point why i wanted to separate refueling from the depot. simply using the refueler as a waypoint near the depot so that trains can do routes between depot and waypoint, and not time out.

[Optera]

What do you mean by fixed? This always was a core feature.
Right you end up with 20k in storage. It would even work with best effort off btw

"core feature": yes, that's why i was wondering how you want to achieve the goal to have only trains with minsize delivering the ore, and end up with 30k+ ore, with the settings "besteffort=true", "item=-30k" and "minsize=20k".
"end up with 20k": no, in the end (after delivering 20k), there may be any amount between 10k and 30k, not less than 10k since then another order for 20k would be given. and not more than 30k since start was at 10k and order was for 20k. and delivering always 2k chunk would not be possible with besteffort true.
goal 1 (start at <10k) done, but goal 2 (always deliver 2k batches) failed, and goal 3 (end up with 30k+) also failed.

I made a test scenario just for this. Using the values i wrote earlier, the requester always ended up with ~20k.

It's more complicated to stamp a working cleaning/refueling Depot BP 100 times than 10 times?

yes. not the depot itself, but all the connections that are needed for each depot stop, eg the need for bots to fill the coal chests for the trains, roboports between the many rails, or belts that need space. all this often can't completely be included in blueprinbts. also look at all those crossings, splits and merges between your depots and the mainline, for the few trains that you have.

My megabase needs at most 12 L-6C-L ore trains for 2 rockets/min, no idea why you would need 100 in one depot.

because i like trains
in openttd, i sometimes used LC trains (or even trains where the engine+wagon were one unit instead of separate L-C), and here i might use something similar, eg when distributing production of green/red/blue circuits, etc to separate "towns", or when handling dozens of ores and fluids/gases with angels+bobs.
of course, you can reduce the network, and you might even be able to do it with no trains, but i want the option to play one way or another, and not be forced to do it in only one "correct" way.

Compared to how long they take to get to the outposts the time it takes them on the main line is really neglect able.

it's not only the time to leave the depot when there is a single train, but lots of trains which share the area between depots and mainline cause jams and that adds up in time.

I thought you like trains? Designing insane complicated, unrealistic high throughput networks is half the fun of OTTD.

Train Schedules only know stop names while LTN internally uses UIDs.
Trains find their way back to their starting depot because i save the name.

save the name? or the UID?
does that mean that trains ignore their schedule and go to a specific depot even when there are several depot stations with the same name ? and if they are smart enough to go back to their own depot, why would they be able to go to another station with the same name as you wrote next:

If you place two stops with the same name and sent the depot signal to only one, trains might go to the one that is not a depot, time out and wait there forever.

Any station with the same name across different forces potentially breaks LTN as it would break manually edited schedules.

i don't play much multiplayer, and none yet with big bases and trains. i didn't know that, but i would consider it to be a bug in factorio since it opens lots of possibilities for enemies and griefers.

if you name them differently you can have one depot per train configuration.
trains will always return only to their starting depot.

important to know!!!
is that documented somewhere ?

this would also mean that i really need to have as many depot stops as i have trains ?
and if i setup a new train and have to send it to a depot, to which depot will it go (factorio rule: nearest depot with that name, right?) and where will the other train go that wants to return to its own station that is now blocked?
i think I'll have to reload the old testmap and watch closely which train goes back to which station ...

Trains can't ignore the schedule or skip stations (feature is promised for 0.15).

Path finding in factorio works entirely different from OTTD.
When starting towards station xyz trains look for a route to the nearest free stop with the name xyz. Repath seems to only be called when
a) tracks are broken
b) they stand at a chain signal for x seconds
c) they come to a red circuit controlled signal (this is abused by fake chain signals to force trains instantly into a free stacker instead of waiting at block signals)
It may also be called every x seconds while they travel, but i couldn't reliably test this so far.

btw: which train is sent from its depot to do a delivery when a new order is just created ?
does LTN look at the distance between the provider station and the nearest depot?
that would allow having at least one depot in front of each outpost (provider) for faster pickup, and trains from somewhere else doing the delivery when the train is still on its last tour ...

LTN goes over all trains in all depots, filters for matching length and cargo type (fluid/item) and will pick either the first found train (usually the one waiting at the depot for the longest time) with just sufficient cargo space or otherwise the largest available train.
You can't make one depot service only certain stations, but you can narrow down which trains are used by train and delivery size.

[exofact]

What does it mean when every depot or station I place has a grey 1 signal on the output combinator?

In my setup I have one depot station with a constant combinator connected to the input lamp. I am outputting -4000 stone from the combinator. If I understand things correctly, that means the depot is constantly requesting 4000 stone. I have a second station that has chests connected to the input lamp, with a 28000 stone signal. The output combinator on both stations has a grey 1 signal. The train has the depot as its destination, in automatic mode, and the lamp turns blue when it arrives. The train never departs the depot to go get the stone. The train is without pathfinding issues when using regular stations in place of the LTN stations.

[Anson]

I made a test scenario just for this.
Using the values i wrote earlier, the requester always ended up with ~20k.

then you proved yourself that it didn't meet the goal of ending up with 30k+
your parameters only guarantee to end up with anything between 10k and 30k, and depending on the setup (production, usage, etc) it may be near the goal of 30k (never reach the goal of 30k+), or (like in your setup) only 20k.

a bit offtopic - designing insane networks is half the fun in ottd

it's not only the time to leave the depot when there is a single train, but lots of trains which share the area between depots and mainline cause jams and that adds up in time.

I thought you like trains? Designing insane complicated, unrealistic high throughput networks is half the fun of OTTD. :lol:

pathfinding is different, and for those "insane networks", i use conditional orders (conditions in factorio train schedules are only a minor part of this) and waypoints (no refueling stations in LTN :-). i also use presignals to direct trains to lanes, use the depot buildings as stackers, use other tricks like invisible depots, autoreversing trains, etc, which all are not available in factorio. but i think that some "do" and some "don't" also apply, eg the disadvantage of blocking entire areas in front of or behind stations by using path signals in ottd, or by using no signals (because there is not enough space to place them) in factorio.

Train Schedules only know stop names while LTN internally uses UIDs.
Trains find their way back to their starting depot because i save the name.

if you name them differently you can have one depot per train configuration.
trains will always return only to their starting depot.

does that mean that trains ignore their schedule and go to a specific depot even when there are several depot stations with the same name ?

this was a bit confusing and from it, i understood the opposite of what is true and what i originally thought.

to clarify : trains do not "find their way back to their starting depot", but have the depot name in their schedule and thus (by normal factorio game mechanics) find their way back only to their depot-group (to any "random" depot with the same name).

When starting towards station xyz trains look for a route to the nearest free stop with the name xyz. Repath seems to only be called when
a) tracks are broken
b) they stand at a chain signal for x seconds
c) they come to a red circuit controlled signal (this is abused by fake chain signals to force trains instantly into a free stacker instead of waiting at block signals)
It may also be called every x seconds while they travel, but i couldn't reliably test this so far.

very useful info about repathing.

this also explains what i noticed and didn't understand: train routes to a train stop being changed only when the train was almost directly (at a chain signal) in front of a depot stop that already was no longer free for some long time (probably x>60). it also explains why some trains were sent on a long detour when a direct short route was temporarily blocked, and then not rerouted to the (in the meantime) free direct route.

let's see how stackers can be improved with that, or repathing be forced at a split that can send trains on a long detour, etc ...

btw: which train is sent from its depot to do a delivery when a new order is just created ?

LTN goes over all trains in all depots, filters for matching length and cargo type (fluid/item) and will pick either the first found train (usually the one waiting at the depot for the longest time) with just sufficient cargo space or otherwise the largest available train.
You can't make one depot service only certain stations, but you can narrow down which trains are used by train and delivery size.

very useful info again.

this would be some kind of "round robin" for selecting among all matching trains !? nice.
and there is no priority for depots and for requesters ?
couldn't the same be done for requesters and depots too ?

maybe the current parameters "provider priority" (which is ignored on requester stations and on depots) could be renamed to "priority" and be applied to all three ? with such a priority for depots, a big stacker could be split into several groups: the trains at some lanes would be prefered, and trains from lesser desirable lanes are only chosen when no more matching trains are available at higher priority lanes. and with such a priority for requesters, deliveries (using round robin) would be done first to the requesters with highest priority, then (when there is no more demand from them) to the next highest priority requesters, etc ?

btw: the newest versions of LTN have besteffort false ?
although this might be confusing when existing setups work differently now, i think that in the long run it will be nicer for most people, matching their expectations about "min delivery size", and having no automatic unexpected "optimizations" which start sending all trains with small amounts, etc ...

[Anson]

What does it mean when every depot or station I place has a grey 1 signal on the output combinator?

there are three output signals of the train stop's constant combinator:
grey signal: short circuit detection
train composition: position of wagons & locomotives in parked train (all stops)
items to load (positive) and unload (negative)

if users make bad wire connections and there is more than one color signal on the lamp (eg a color signal of their own, or this grey signal), this is detected and the lamp should turn red to indicate a "wiring or signal error".

In my setup I have one depot station with a constant combinator connected to the input lamp. I am outputting -4000 stone from the combinator. If I understand things correctly, ...

you misunderstood or mistyped something ...

there are two types of stations: depots and requesters/providers.
depots are the "parking spots" for trains, and LTN finds them because of the "this is a depot" signal you have to send to their input lamp. the amount to request (negative amount) or provide (positive amount) is sent to the lamp of all non-depot stations.

thus the minimum LTN-network has three stations: a depot, and one each of provider and requester station.

quote with some correction

In my setup I have one (non-depot) station with a constant combinator connected to the input lamp. I am outputting -4000 stone from the combinator. that means the station is constantly requesting 4000 stone. I have a second station that has chests connected to the input lamp, with a 28000 stone signal. The train has the depot (a third station with the "this is a depot" signal) as its destination, in automatic mode, and the lamp turns blue when it arrives. The train neverimmediately departs the depot (the third station in the setup) to go get the stone from the first station and deliver it to the second station, and then automatically returns to the depot, turning that lamp blue again.

[exofact]

Aha! Thank you.

[ssilk]

I have a question: How can I make this working?

Screen Shot 2017-02-08 at 18.31.32.png (2.01 MiB) Viewed 8798 times

This is my supply station in my central factory. It is thought to provide the outposts, that needs to be built, with the needed items. You see 24 different item types, for every wagon-space one.
The red circuit is, what it provides (plugged in the LTN-stop input) and the green the current order in the LTN-stop output. Which is part of what was requested from far, far away.

Everything perfect till here.

Here are my issues with this setup:
1. I put the inserters to filter-mode. But all it fills into the cargo-wagon are endless numbers of red belts. Which is first in the list of the orders. But I wonder, why it doesn't input all the other items of the green circuits. Does the filter inserter filters only one (the first) item-type?
2. The train is set by LTN to "leave after 2 seconds of inactivity". But even if no inserter puts anything into the train, the train doesn't leave after a minute. Eventually, because the other items are not filled in? Is that really like so? So this stop does not work, if I don't have for example blue belts?
3. How can I control how many items to insert. How to stop the inserters inserting? How to tell the train, that it should go leave now, even if I currently don't have enough of blue belts? (Cause it should not block this stop, it is much more important, that there is a constant flow of supply-trains, than a perfectly full loaded cargo. )

So is there anybody, who did such an setup (a supply train to bring many different items to somewhere else) already? All my solutions to this are more or less ugly.
How can I count, what is already inside the wagon (a vague idea to use the item-combinator)? How can I manage to insert all requested items at once? Where is eventually the mistake?

[Optera]

let's see how stackers can be improved with that, or repathing be forced at a split that can send trains on a long detour, etc ...

There was a post "the yellow train that doesn't know when to quit" abusing circuit controlled signals

this would be some kind of "round robin" for selecting among all matching trains !? nice.
and there is no priority for depots and for requesters ?
couldn't the same be done for requesters and depots too ?

maybe the current parameters "provider priority" (which is ignored on requester stations and on depots) could be renamed to "priority" and be applied to all three ? with such a priority for depots, a big stacker could be split into several groups: the trains at some lanes would be prefered, and trains from lesser desirable lanes are only chosen when no more matching trains are available at higher priority lanes. and with such a priority for requesters, deliveries (using round robin) would be done first to the requesters with highest priority, then (when there is no more demand from them) to the next highest priority requesters, etc ?

Giving requesters priority undermines the round robin system.
It should make no difference if a train from depot A or depot B is used. The way any train can be used for any delivery, there's no way for the player to determine if A or B would be closer.
I may or may not factor in distance from depot to requester/provider, currently it feels more like adding it would only weight LTN down. (Would be nice if the api for trains would provide a path length)

I have a question: How can I make this working?

Set up something akin to what I have in the 0.7.1 Demo Map as building provider. The demo version was a rough first prototype though.

Here's a more recent setup I whipped up for my live maps.

2017-02-08-19-24-50-8883491.jpg (489.93 KiB) Viewed 8796 times

Pros:

• It can service anything from L-C to L-3C only using the needed loading bays
  You can expand it up to 32 carriages (limit of train length that can be binary encoded)
• Usable as Provider & Requester at the same time
• Requests only slightly above the train request
• When the train leaves the requested items are returned to the logistic storage

Con:

• It has still a glitch where it can get caught in loading the same item in and out for a while until drones deliver a fitting size.
  To prevent that you can plug an arithmetic combinator with each-stacksize=each between either the loading or unloading inserters. It will however hinder the station to be universally used to load & unload.
  If 0.15 makes inserters grab the sent amount though, this setup should work flawless.
• too many combinators used as diodes or filters, which i couldn't yet get rid of.
• It's rather slow at loading/unloading
  could potentially be made into using 4 loading and 4 unloading inserters/wagon though

Blueprint

Code: Select all

H4sIAAAAAAAA/91abY+jNhD+KxEfqr7ACdu8JLrSX1BVVdV+Op2QD7yJVYJTY7abRvnvNYRsAjHGkN1kd+/LXpb4YeaZeWbs8aZslrEEZ7M42pFcUEFJEe12
OV6TyCoEx3S5Eo78kVn2hhXyOcuj3VPkAM/eRg7c2ynlJKl/LT+YLIRTF7oTF84nrgsmrpvKzERiJtIy8W0TnZvI5cTQTU2VqbmpFQPmVKzWRNDESdj6G82x
YPxCFJ98CeGeI3h2wnLBWRZ/Iyv8SBmPdiesWD5MawCp1wfKCxEXdJnjLNqJ7Ua+9pFyUWJpaGN9/dAhOFlZ+wq5EDgX8s022xCO6zdaP1o2K8WmHIO1r9Hy
g9HSli8WsL5GuyUnRPp2KCrbmKYRmFff/WJB9WMI7YTypKSi/rSv/h0pzNiSFjWBK1LIAJB/SvmTXLAIDix+8vcK7o7oa5aSmD3EJ7+B2gVO0q4D9tlHzzs3
GLQMluQmfzsPNJNGOjQvCO+11qnN1YddY/qzDZzgNF7hPK0yQ0gzi0jwkhi6FkrbFSELhlzs8809ReLkWqBx7TmdjbL51z9/cxLMl8z5Fy9Zfp7RrvzveoN5
pbLIiqye/OwycG00F2fBvEMA2+ZDZTTbCgM6hWH5ukfibDh7pGmPr5Wro4rc/E41zj0vcT+9ZomDrrbEteUE29UkaMXDhE//4/cM6Ol7xqK/Z5iI1ns7FRj6
as0iY832dUXvVZuijFArjcOJHQO9u4Yx6Kk+9+CdG0Zo0DAWL9Qw4LSGAT5+wwj19Q1pGsZibMrBt1PtkDrhEOhPOIOEuVe+3LAhIv0OAwXXHqLgq3YLaf55
DvvuVTXUu28JbVvfk9GaE9SYEupdVlBdO3133VSXCQbKv9dW+HadAiG98EF/p/BRi86UJFV+9XK5uMwcqOCygRlL5IjUGcXmI+FbsaL5skbcbKVdZS7iB87W
Mc0lzEHYhtnYnUWplB0OMH4Mlh4cGICPb4RA0ehV8r9aEEjSXZBq7diwT+6YqFc1F92mu39VMd35TmuL5WrCiDRnT9MQ3SJC8PYRguYRmvez73cncqrojVnf
H8q5RsrdwZqqgVc3A7lTCLZxDjR1rweUO29VVT3sd6orOBOiJSHbut7JUid3NTRPydPBU6Mqpx45dDkd8riurkqHBzZm4/Ycjcs4Pyvzysbxi3xUFkTCZ4zr
9nOXrvvBkLeKex9Xfe2zJikt1w7J5BMuMTYsI93z7WGbBhqahs/sgTJgE0aH9QUZGE7H93NUurjRWLRkDMJ2Zfe7qu6rDfVI13zzVF82g+GyPnH3dNZ1e7L/
5ztum+pE7CNSd8FioJVgpFSQJt7gYpCiUlUboXs9qRnFmAgQfXT9Qb9NX9BmbG6sv3Cc/sAt9AffqP4WOv1pjhTD+nNHd6r+cIOLs5K6qbXyZ2F8vjWQn/fR
1YfaDKG2GH1gqj40bnQQ3EJ84G2KT3/m14y3TOYxr0fqS89jVHgqZh9wVphSOzBq0R/XelP7qnoYjqyHC40AO/UQap6pT2wd9O4lgG3otenUwiAZr66c4PZT
CzB5rtQKkfqMdjGKMh4P2r0ocGTONqdy86R1dW32WCb6c8U/ve4lhx7u88TDgcALvTkK5P7iOPuwjTDAaWrihij0wBx6DQQ0hIDPED4K5qG7ALBBQIYI6BkB
BnMP+Z4fNAieIYJ3cgN5EIQhPBLhDyGs8VMz1shIvhSrkzcNQjCIINemJKNVF3UK+h8549RtQKo/K6RFLON+qPdmndRg8OcdSpdET2qojqlUkPXRTtUUZ3+a
lZ0KycyZ/ZVX7hQ4m/3eXMPNvpv9cbwpnX1fFnK3MKu9JPwHa/+ZE1HyfBZ/Jnn6P8f0cHlMLwAA

[Anson]

1. I put the inserters to filter-mode. But all it fills into the cargo-wagon are endless numbers of red belts. Which is first in the list of the orders. But I wonder, why it doesn't input all the other items of the green circuits. Does the filter inserter filters only one (the first) item-type?

vanilla filter inserters have only 5 filter slots, and ignore the rest of the signals.
your inserters in the screenshot look white, thus are stack filter inserters and those have only 1 filter slot.

you can use combinators between the incoming signal and the inserter to filter from the whole "bundle" that single signal that corresponds to the chest and send only that matching signal to the inserter.

2. The train is set by LTN to "leave after 2 seconds of inactivity"

ONLY this condition ? or some other condition too (eg "belts>100") ?
"inactivity" is useful at the depot to wait until refueling or cleaning erroneous non-empty wagons is finished.
are you sure that this is the order for the provider stop or the requester stop ?
or did you only select the train and look at the first order which usually is for the depot ?

But even if no inserter puts anything into the train, the train doesn't leave after a minute.

see above: check whether you look at the correct station in the schedule.
i would guess that there is an order to wait for xx belts at the provider station and thus the train is still waiting.

3. How can I control how many items to insert. How to stop the inserters inserting?

that is done automatically.
orders are set to load until "amount > xx", and that works fine when using LTN for single types of cargo per train.

the bonus of inserters can cause them to "hang" with some items in their hand when the train is full and leaves. this is also the reason why the next train might get the wrong type of cargo from such a "partially done" inserter, maybe even causing that train to not be able getting the desired amount of items (because a wrong type is blocking a slot) and waiting forever or until timeout.
to debug, you might want to verify that you selected the correct station in the schedule and see what the orders are, and/or increase the level for messages to get more details when trains get their orders (in config.lua)

How can I count, what is already inside the wagon (a vague idea to use the item-combinator)?

i don't think that there is any option in the current version to check contents of train and chests, do some calculations yourself and then tell the train to leave. even when using another mod to look at the train contents, you wouldn't be able to send the "leave now" to the train. maybe on the next version of factorio, checking the contents will be possible, but the problem would be the same: how can LTN send a train to deliver some amount of item X from A to B, and then at station A be told otherwise by your own signals ?

How can I manage to insert all requested items at once?

i have no idea how "multi-loading" different cargo on a single delivery can be done.

[Anson]

There was a post "the yellow train that doesn't know when to quit" abusing circuit controlled signals

do you have a link ? i couldn't find such a post

and there is no priority for depots and for requesters ?
couldn't the same be done for requesters and depots too ?

Giving requesters priority undermines the round robin system.
It should make no difference if a train from depot A or depot B is used.

"undermining the round robin system" is exactly what i wanted :-)

currently, when all providers have the same level of priority, they are serviced (used for pickup) using round robin, but when another provider or several other providers have higher priority, they are serviced first (using round robin again?, but only among those providers with the same highest priority), and other providers are serviced only when no higher priority provider is able to provide items for a request.

my first wish: why shouldn't this apply to requesters too?
when all requesters have the same level of priority, they should be serviced (selected as drop target) using round robin, but when another requester or several other requesters have higher priority, they should be serviced first (using round robin again, but only among those requesters with the same highest priority), and other requesters should get deliveries only when no higher priority requester has unmatched requests.

my second wish: why shouldn't this apply to depots too?
when all depots have the same level of priority, a train for the next delivery should be picked from them (no round robin since the train is gone after selecting it, but maybe the "longest waiting train") but when another depot or several other depots have higher priority, only trains from those depots should be used first (randomly picking one of those trains in higher priority depots), and trains from other depots should be used only when the higher priority depots all are empty.

and yes, selecting a provider and/or selecting a requester would be completely independent of the train's depot.

in big setups, there might be some problem (i haven't carefully looked at it, whether there is such a possible problem at all), eg when the higher priority requesters and the higher priority providers can't be matched, and then a lower priority provider could be matched with a higher priority requester, at the same time that a higher priority provider can be matched with a lower priority requester. but there are solutions to those cases too, if you are willing to extend the principle of priorities to depots and providers and requesters.
eg: everything is sorted according to priorities. first the highest value for any priority is selected and matching is attempted. when there is no match, the "current priority" is reduced and matching is attempted again, etc, until either the "current priority" is 0 (abort with no match found) or until a match is found. more thorough thoughts only if needed :-)

there's no way for the player to determine if A or B would be closer.
... (Would be nice if the api for trains would provide a path length)

yes, what would the distance be? direct line (flying above water and forests :-) or path length (minimum length, random length, worst case length if best path is blocked, etc), and when there are speed limit signs on some route, what would the "length" be in that case (the time to travel) ?
but doing round robin or priorities (or a combination of both) doesn't necessarily need the path length. for the "desirable lane" in a stacker depot, users could specify a priority themselves, eg high priority for the lanes nearest to the mainline, and lower priorities for some lanes behind several merges, splits and crossings.

[Optera]

There was a post "the yellow train that doesn't know when to quit" abusing circuit controlled signals

do you have a link ? i couldn't find such a post

It was golden train, not yellow ... viewtopic.php?f=194&t=32255

currently, when all providers have the same level of priority, they are serviced (used for pickup) using round robin, but when another provider or several other providers have higher priority, they are serviced first (using round robin again?, but only among those providers with the same highest priority), and other providers are serviced only when no higher priority provider is able to provide items for a request.

Wrong. Round robin applies to requesters only.
Providers being exclusively used based on priority was fixed in 0.9.0. They are now picked in the following order: number of active deliveries, priority and amount of requested item.
Trains being picked seemingly round robin is a side effect of how lua parses the list containing available trains, but lua does not guarantee the list is always ordered this way and neither do I care if which identical train runs which delivery.

My wishes...

First of all I am not going to implement wild ideas. If you want a feature implemented think it through and present reasons of why and how it would improve gameplay not just for your own playstyle, but for others as well. Chances of me implementing something are directly are affected by how well thought through a feature request is.

Detailed answers to your wishes

my first wish: why shouldn't this apply to requesters too?
when all requesters have the same level of priority, they should be serviced (selected as drop target) using round robin, but when another requester or several other requesters have higher priority, they should be serviced first (using round robin again, but only among those requesters with the same highest priority), and other requesters should get deliveries only when no higher priority requester has unmatched requests.

While I see some potential applications, they would only be very niche scenarios where you need to bypass round robin that don't warrant adding processing time.
Increasing production is easier done and has less overall udp drop.

my second wish: why shouldn't this apply to depots too?
when all depots have the same level of priority, a train for the next delivery should be picked from them (no round robin since the train is gone after selecting it, but maybe the "longest waiting train") but when another depot or several other depots have higher priority, only trains from those depots should be used first (randomly picking one of those trains in higher priority depots), and trains from other depots should be used only when the higher priority depots all are empty.

and yes, selecting a provider and/or selecting a requester would be completely independent of the train's depot.

I can't think of a single scenario where picking trains from one depot over another would be beneficial.

in big setups, there might be some problem (i haven't carefully looked at it, whether there is such a possible problem at all), eg when the higher priority requesters and the higher priority providers can't be matched, and then a lower priority provider could be matched with a higher priority requester, at the same time that a higher priority provider can be matched with a lower priority requester. but there are solutions to those cases too, if you are willing to extend the principle of priorities to depots and providers and requesters.
eg: everything is sorted according to priorities. first the highest value for any priority is selected and matching is attempted. when there is no match, the "current priority" is reduced and matching is attempted again, etc, until either the "current priority" is 0 (abort with no match found) or until a match is found. more thorough thoughts only if needed

There always are solutions, most of them require parsing through multiple lists which is increasingly costly the more stations & items exist.

yes, what would the distance be? direct line (flying above water and forests or path length (minimum length, random length, worst case length if best path is blocked, etc), and when there are speed limit signs on some route, what would the "length" be in that case (the time to travel) ?
but doing round robin or priorities (or a combination of both) doesn't necessarily need the path length. for the "desirable lane" in a stacker depot, users could specify a priority themselves, eg high priority for the lanes nearest to the mainline, and lower priorities for some lanes behind several merges, splits and crossings.

As I said, there's no way to get paths. The best mods can do is calculate linear distances.
Here again the benefits are far outweighed by the added processing costs.

[ssilk]

[
Here's a more recent setup I whipped up for my live maps.

2017-02-08-19-24-50-8883491.jpg

Pros:

• It can service anything from L-C to L-3C only using the needed loading bays

That is not needed and it makes also no sense in my opinion, cause what you want here is very, very fast and agile transport, which means: Small trains, LC or LCC at maximum.

[*]Usable as Provider & Requester at the same time

I didn't get it to run without that glitch. And after 1.5 hours I gave up to understand how this works. Not your fault. I think this is one of Factorios big, big fails, that it is currently hard to impossible to debug/re-engineer circuit network: you cannot follow the wires. I cannot see, where what is connected.
And BTW: This is also limited to 10 different items, cause the requester chest can only request up to 10 different items-types.

You can expand it up to 32 carriages (limit of train length that can be binary encoded)

BTW: I think it would make the position logic some simpler, if you use the signals [1] [2] [3] ... [9] [A] .... etc. to tell what is standing on which position.
For example for a LCCC train there are 3 signals:
[1] = 1
[2] = 2
[3] = 2
[4] = 1

Where the value 1 means Loco and 2 means wagon. 3 maybe is tank wagon.
And signal [0] contains the train-length (here 4). And after signal [9] it continues with [A], like hexadecimal numbers. So you can explain trains up to length of 36...
Enables much simpler logic also in this case.

[Optera]

[
Here's a more recent setup I whipped up for my live maps.

2017-02-08-19-24-50-8883491.jpg

Pros:

• It can service anything from L-C to L-3C only using the needed loading bays

That is not needed and it makes also no sense in my opinion, cause what you want here is very, very fast and agile transport, which means: Small trains, LC or LCC at maximum.

I wanted a truly universal station, able to be provider & requester at the same time, making full use of the train composition signal to showcase what is possible. I hope others will showcase even better station designs utilizing LTN.

[*]Usable as Provider & Requester at the same time

I didn't get it to run without that glitch. And after 1.5 hours I gave up to understand how this works. Not your fault. I think this is one of Factorios big, big fails, that it is currently hard to impossible to debug/re-engineer circuit network: you cannot follow the wires. I cannot see, where what is connected.

I made a tiny mod for myself replacing green wires with a more turquoise version so I can better see where the wires are. It's still a pain to follow connections, even when I designed something myself I often miss connections in this mess... There should be some form of "logic connection mode" showing at glance all connections and the signals on them, I bet you have a whole collection of requests for something like that.

To get rid of the glitch I thought about using a latch to switch between loading and unloading mode depending on loading signal signs. If I can make it work I'll update this post to include that design.

And BTW: This is also limited to 10 different items, cause the requester chest can only request up to 10 different items-types.

No, The requests are dynamic. It will request up to 10 different items at first. After an item is fully loaded the signal will be either 0 or negative making room for the next signal.

You can expand it up to 32 carriages (limit of train length that can be binary encoded)

BTW: I think it would make the position logic some simpler, if you use the signals [1] [2] [3] ... [9] [A] .... etc. to tell what is standing on which position.
For example for a LCCC train there are 3 signals:
[1] = 1
[2] = 2
[3] = 2
[4] = 1

Where the value 1 means Loco and 2 means wagon. 3 maybe is tank wagon.
And signal [0] contains the train-length (here 4). And after signal [9] it continues with [A], like hexadecimal numbers. So you can explain trains up to length of 36...
Enables much simpler logic also in this case.

This encoding would make those signals unusable for any other purpose and isn't very flexible.
My encoding shows every possible mod added loco or wagon with it's own signal and needs only 1 combinator in total to parse every position in 1 tick. See also XKnight's post here. In this particular station I'm using 1 combinator/position so I can have item and position signals on the same wire.

[Anson]

It was golden train, not yellow ... viewtopic.php?f=194&t=32255

thanks

currently, when all providers ...

Wrong. Round robin applies to requesters only.

sorry, i seem to have messed up when doing the copy&paste to clearly show how similar it would be for requesters, providers and depots :-(

They are now picked in the following order: number of active deliveries, priority and amount of requested item.

i already was wondering whether it was true or an illusion that trains at my three requesters (each with a different priority) would queue up and jam the mainline more rarely than on an older version of LTN ...
on the old version, quite often 5 trains were waiting at the first station (with high priority) and blocking any trains for the next stations. now they seemed to only prefer the first station a bit, but still not queue up too much before some trains are also sent to the next stations. thus the new internal logic seems to distribute trains and goods much more gracefully. nice!

My wishes...

First of all I am not going to implement wild ideas.

fair enough.

my second wish: why shouldn't this apply to depots too?

I can't think of a single scenario where picking trains from one depot over another would be beneficial.

that's how i got the idea to (optionally) use priorities and/or round robin everywhere :-)

in my stacker depot, i had 12+ parallel depot stops (all facing south). trains would enter the stacker area from the east using a single lane, select the next free depot, do a turn left into that depot, and wait to leave until it is their turn. when leaving, they would again turn left and leave the stacker area towards the east on a single lane.
for leaving, it appeared to me that trains would be selected according to their wait time or something similar, and thus trains from the last depots stops (furthest to the west) would be selected as often as other trains although trains on the east side should be prefered since they have a shorter path to the exit and don't block the entire exit lane all the time. this could be improved by not using round robin (or the waiting time) and instead give priorities to all stops, from highest towards the east to lowest towards the west.

when i tried to improve the system by having two groups of 6 stops each and thus let trains leave "in parallel" on two exit lanes, often 3 trains would wait on one lane and the other was empty. also this case could be solved by giving priorities from 6 downto 1 in each of the groups, sending both "6" trains first, then both "5" trains, etc.

and finally i didn't dare to have a main depot with some few stops which should be preferred, and a longer "depot overflow" route to some more depot stops more distant (eg because some lake or other obstacles give only enough space for a few stops). usually those main stops should be used only, and only when (rarely) more trains would be needed at the same time, trains from that other depotgroup would be called. also this could be solved by giving higher priority to the trains in the "near" stop, and lower priority to the trains in the "auxiliary depot".

impact on the ups shouldn't be too harsh when storing the trains not in an unsorted list or a list which is sorted according to "arrival time", but a list that is sorted according to "priority, arrival time". these additional calculations probably would be done only once every few/many minutes when a train arrives at a depot (completely unrelated to on_tick etc), and should consist of only one command to concatenate priority and arrival time, or a function call to insert the arrived train into the list instead of simply adding it.

There always are solutions, most of them require parsing through multiple lists which is increasingly costly the more stations & items exist.

true, and that priority (playability, ups, etc) is more important than the train priorities :-)

As I said, there's no way to get paths. The best mods can do is calculate linear distances.
Here again the benefits are far outweighed by the added processing costs.

that's also what i said :-) and besides the cost of doing the calculations, i doubt that any reasonably simplified algorithm (or even any at all) ever can imagine what the "best distance" will be, eg of two stops which are next to each other, but connected through a 20km long track around a lake ...

For example for a LCCC train there are 3 signals:
[1] = 1, [2] = 2, [3] = 2, [4] = 1
And signal [0] contains the train-length (here 4)
So you can explain trains up to length of 36... :)

[1] to [4] are 4 signals (not 3), LCCC should be 1222, and 1221 would be LCCL,
and [1] to [9], plus [A] to [Z] are 35, since you use [0] for the length :-)

when implementing it by using a constant combinator for output, i don't know whether the output would be limited to the 15 slots of a constant combinator, thus reducing the available signals to 15 or less (since some signals are used eg for the constant grey signal, or for the type and amount of cargo). I'll have to test this with the current version someday, using all available train mods to get a dozen or more different trains and wagons :-)
you also would have to keep records offline to stay compatible when new mods for new types of trains or wagons are published, and assign unique numbers for their new engines and wagons (easy when playing solo only, difficult when playing MP or exchanging blueprints). when using encoded signals, new types automatically can get new virtual signals (at least while less than 15 different engine and wagon types are used at the same time on a map)
also when doing logic with those signals, it's easier to simply add several encoded signals and know where any engines or any wagons are. to do the same with the unencoded system, you would need a set of comparisons (for the unique numbers) at every single wagon position.

[Optera]

i already was wondering whether it was true or an illusion that trains at my three requesters (each with a different priority) would queue up and jam the mainline more rarely than on an older version of LTN ...
on the old version, quite often 5 trains were waiting at the first station (with high priority) and blocking any trains for the next stations. now they seemed to only prefer the first station a bit, but still not queue up too much before some trains are also sent to the next stations. thus the new internal logic seems to distribute trains and goods much more gracefully. nice!

Glad to hear that change works well outside my test scenarios.

in my stacker depot, i had 12+ parallel depot stops (all facing south). trains would enter the stacker area from the east using a single lane, select the next free depot, do a turn left into that depot, and wait to leave until it is their turn. when leaving, they would again turn left and leave the stacker area towards the east on a single lane.
for leaving, it appeared to me that trains would be selected according to their wait time or something similar, and thus trains from the last depots stops (furthest to the west) would be selected as often as other trains although trains on the east side should be prefered since they have a shorter path to the exit and don't block the entire exit lane all the time. this could be improved by not using round robin (or the waiting time) and instead give priorities to all stops, from highest towards the east to lowest towards the west.

when i tried to improve the system by having two groups of 6 stops each and thus let trains leave "in parallel" on two exit lanes, often 3 trains would wait on one lane and the other was empty. also this case could be solved by giving priorities from 6 downto 1 in each of the groups, sending both "6" trains first, then both "5" trains, etc.

and finally i didn't dare to have a main depot with some few stops which should be preferred, and a longer "depot overflow" route to some more depot stops more distant (eg because some lake or other obstacles give only enough space for a few stops). usually those main stops should be used only, and only when (rarely) more trains would be needed at the same time, trains from that other depotgroup would be called. also this could be solved by giving higher priority to the trains in the "near" stop, and lower priority to the trains in the "auxiliary depot".

impact on the ups shouldn't be too harsh when storing the trains not in an unsorted list or a list which is sorted according to "arrival time", but a list that is sorted according to "priority, arrival time". these additional calculations probably would be done only once every few/many minutes when a train arrives at a depot (completely unrelated to on_tick etc), and should consist of only one command to concatenate priority and arrival time, or a function call to insert the arrived train into the list instead of simply adding it.

I can only vaguely imagine what that looks like. I force trains into the next free track of my 2x8 track depot with circuit controlled block signals instead of using chain signals. Usually I have trains being picked alternating between left and right.

when implementing it by using a constant combinator for output, i don't know whether the output would be limited to the 15 slots of a constant combinator, thus reducing the available signals to 15 or less (since some signals are used eg for the constant grey signal, or for the type and amount of cargo). I'll have to test this with the current version someday, using all available train mods to get a dozen or more different trains and wagons

That's why the combinators of LTN stops have 50 slots. If I ever get an index out of bounds error I'll up it to 100.

you also would have to keep records offline to stay compatible when new mods for new types of trains or wagons are published, and assign unique numbers for their new engines and wagons (easy when playing solo only, difficult when playing MP or exchanging blueprints). when using encoded signals, new types automatically can get new virtual signals (at least while less than 15 different engine and wagon types are used at the same time on a map)

also when doing logic with those signals, it's easier to simply add several encoded signals and know where any engines or any wagons are. to do the same with the unencoded system, you would need a set of comparisons (for the unique numbers) at every single wagon position.

increasing the integer is even simpler than the current way of adding virtual signals. It's getting problematic when you have multiple mods adding a lot of carriages. I can't support or do documentation for those signals anymore as every mod load order can be different (4 for one player might be from yuoki trains while for another it could be from creative mode).