Factorio Forums

steinio wrote: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

Optera wrote:

Anson wrote: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.

... 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.

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:

thelordodin wrote: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.

Anson wrote: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?

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

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.

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.

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?)

• 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.

-- 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?

Optera wrote: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

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

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

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.

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

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.

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

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?
Just plant a LTN-stop at every stacker rail. :roll:

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.

Anson wrote:

Optera wrote: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.

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 ...

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 ...

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

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 ?

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 ?

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 wrote:What does it mean when every depot or station I place has a grey 1 signal on the output combinator?

long description in the OP wrote: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)

exofact wrote: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, ...

exofact wrote: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.

Anson wrote: 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 ...

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 ?

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

• 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

• 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

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

ssilk wrote: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?

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

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

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

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

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

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

Optera wrote:

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.

Optera wrote: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)

Anson wrote:

Optera wrote: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

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 wishes...

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 wrote:[
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

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

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

.... 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.

ssilk wrote:

Optera wrote:[
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 wrote:It was golden train, not yellow ... viewtopic.php?f=194&t=32255

Optera wrote:

currently, when all providers ...

Wrong. Round robin applies to requesters only.

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

Optera wrote:

My wishes...

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

Optera wrote:

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.

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

Optera wrote: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 wrote: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... :)

Anson wrote: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!

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.

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.