Does LTN select a train from the nearest Depot?

[Achilleshiel]

Does LTN select a train from the nearest Depot?
Or will it pick a train at random from any depot?
Ignoring the train composition here, because i'm only running one type of train.

[mrvn]

The nearest from the list of suitable / optimal trains.

[Achilleshiel]

Is nearest defined as path length or as the crow flies?

[mrvn]

Afaik the later as the LUA script has no access to path lengths.

[Dune]

Afaik the later as the LUA script has no access to path lengths.

Now that the devs have added train paths in schedules, is this now available?

[eduran]

Not really. The path only exists when a train is actually moving to a station. You would have to pick a train at the starting station, add the destination to its schedule, set it to automatic, read the path and quickly restore the original settings before it moves out of the station.

[mrvn]

You could read out the value on every train-leaves event and update the internal as-crow-flies estimate. Over time the distances calculations would improve then.

I think this would help a lot in certain cases. I sometimes have depots near stations that aren't really connected to the depot. But since they are right next to each other LTN always picks trains there and sends them a long long way around to reach the stop.

[Optera]

You could read out the value on every train-leaves event and update the internal as-crow-flies estimate. Over time the distances calculations would improve then.

I think this would help a lot in certain cases. I sometimes have depots near stations that aren't really connected to the depot. But since they are right next to each other LTN always picks trains there and sends them a long long way around to reach the stop.

And how would you update the lookup table to changes in rail network?
At most the table can be wiped entirely whenever a rail is placed or removed, BUT the removal events are not always raised, e.g. when rails are implicitly removed by chunk/surface removal or when other scripts remove them.

[mrvn]

You could read out the value on every train-leaves event and update the internal as-crow-flies estimate. Over time the distances calculations would improve then.

I think this would help a lot in certain cases. I sometimes have depots near stations that aren't really connected to the depot. But since they are right next to each other LTN always picks trains there and sends them a long long way around to reach the stop.

And how would you update the lookup table to changes in rail network?
At most the table can be wiped entirely whenever a rail is placed or removed, BUT the removal events are not always raised, e.g. when rails are implicitly removed by chunk/surface removal or when other scripts remove them.

You could reset distance to as-crow-flies if they aren't taken for a long time. A decaying average should work. So every now and then you pick a bad one and the distance goes up again.

[Optera]

You could reset distance to as-crow-flies if they aren't taken for a long time. A decaying average should work. So every now and then you pick a bad one and the distance goes up again.

A terrible solution, producing unexpected results whenever players redesign their network.

I would have to check if LuaTrainPath.valid was invalidated when parts of it where removed.
Then at least no longer existing paths would be handled. However newer shorter routes would only be discovered by chance which still is far from ideal.

Overall it's too much hassle for what it's worth. LTN will use only linear distances until this is implemented:
viewtopic.php?f=28&t=67199

[mrvn]

You could reset distance to as-crow-flies if they aren't taken for a long time. A decaying average should work. So every now and then you pick a bad one and the distance goes up again.

A terrible solution, producing unexpected results whenever players redesign their network.

I would have to check if LuaTrainPath.valid was invalidated when parts of it where removed.
Then at least no longer existing paths would be handled. However newer shorter routes would only be discovered by chance which still is far from ideal.

Overall it's too much hassle for what it's worth. LTN will use only linear distances until this is implemented:
viewtopic.php?f=28&t=67199

I disagree with the "by chance" part. All distances would decay to as-the-crow-flies distance over time and the route can never be shorter than that. So newer shorter routes would be discovered in the time it takes for a cached distance to decay enough to be less than the new route.

I agree though that it is far from ideal. I'm not sure how your other topic helps that much though. Even if you can ask for the path between 2 stations you still have no way of knowing if that path still exists later of if the distance has changed. You would have to constantly check the path between every pair of stations and that's O(n^2). With 1000 stations checking one per tick would need 4.6 hours to verify all distances. That probably needs something that uses as-crow-flies as approximation and only computes the real distance for pairs that are real candidates in a delivery and caching the result for a while.