[0.18.22 / 1.13.1] Several trains at the same depot problem

[mmmPI]

Depends... I'm not planning dynamically increase penalties, just increase it once, globally and only one. So, theoretically there is no performance issues. In usual cases i don't need to increase penalties so much, just rise it enough to cover all train park.

I meant "increase over and over" during your testing, when you fiddle with the value to see if it has an impact. The higher the penalty the more susceptible a train is to ask for a computationnal heavy solution = a far far away depot.

If you set it to 5 time the normal value even once and for all. This could make several trains regularly try to find a very long path, as their standard behavior. Which could impact performances. If you increase it by a 1000 and you add 10 trains, it creates a exponential situation over time, where each single added train would require more computation for free path being asked and each computed path will require a longer period of the path-finding algorithm being active because of the deeper search. I think it can have performance impact as a potential effect. Not saying this would be immediate or visible, it depends on parameters, but performance is one thing that will most likely be impacted, a little or heavily depends on the setup. Worst case being that ALL trains would ask a 7000 rail longer path research, everytime they move, find nothing, and behave as if the penalty wasn't added while still requiring extra research.

(that's just an expectation)

And seems there is some sort limits in pathfinding calculations. If all potential pathes took more than X segments or exceed Y penalties threshold, then stay with previous path. And adding to one of variant 6k extra penalty points pushes this limit further away. Or maybe somthing similar. =)
Even in such awful setup, i don’t think it’s necessary to add too much to allow trains find a free depot.

I think the test you show are not really example how of the system would behave "normally", instead it's an initialization at full scale, followed by a complete stop. If the flow was distributed over time like when the factory is functionning, you wouldn't have those problems as there would be free room in the depot that the trains could find instead of resigning to need the penalty to find further away depot. (but beware congested network has all sort of penalty added due to trains located between signals, trains arriving at signal, trains leaving blocks and so on.)

Maybe in normal condition you wouldn't need the penalty provided at least 1 or 2 trains are on their way instead of waiting at the depot, or those stuck trains would repath as soon as a train leaves a depot, thus not blocking anything long enough to be a problem.

In other setup, you may have this penalty counted several time for 1 single path, if you have a serie of train at a station all in a row. ( station 1 to station 10 for example). If a train arrive from the station 10, and wants to go to station 1, but there are 9 trains waiting at station between those, then the penalty will be multiplied by the number of trains. The "closest path" would be maybe 100 rails + 9*(1000+added penalty). Which also makes me worry as what would be the consequences of increasing the limit.

1) Chance, what you meet a train on station w\o another station in schedule, when you playing without LTN, is going to zero and pathfinder is not setted to handle such cases by default. So It looks like this option was originally added for use with LTN-like mods;
2) As a consequence of the first reason - different players may built different setups of their depots. And this settings may vary for each of them;

1) i have to disagree, you can play without LTN but still enable/disable station with circuit network, i do that most of the time, this means i have plenty of trains at a loading area full of material waiting for any unloading station on the map to open, when buffer of material drops under a threshold. Before the unloading open trains don't move because they don't have a station open on schedule. In this case the pathfinder is behaving nicely. Addind a penalty for my particular case would not yield different result, but would cost more computationnal power if trains start "looking further away" instead of just queuing behind the immobilized train.

2) i still think it's the other way around , the limit is (supposedly) fixed, and players have to design their depot accordingly, else the depot itself is the problem. If you propose this function in the mod,to me it means that you implicitly encourage players to solve a design problem by keeping the design the same and just spending more computationnal power to deal with it. However if this function was existing in base mod it could also be used to "reduce" the penalty, in some (rare) cases where trains require lots of CPU usage in 1 tick to find a path, you could prevent them from "looking too far away".

[ZlovreD]

If you set it to 5 time the normal value even once and for all. This could make several trains regularly try to find a very long path, as their standard behavior. Which could impact performances. If you increase it by a 1000 and you add 10 trains, it creates a exponential situation over time, where each single added train would require more computation for free path being asked and each computed path will require a longer period of the path-finding algorithm being active because of the deeper search. I think it can have performance impact as a potential effect. Not saying this would be immediate or visible, it depends on parameters, but performance is one thing that will most likely be impacted, a little or heavily depends on the setup. Worst case being that ALL trains would ask a 7000 rail longer path research, everytime they move, find nothing, and behave as if the penalty wasn't added while still requiring extra research.

Ok let's test it...
Both screenshot with idle (left) state and when all trains on route (right) few minutes. Game speed x18.

default settings train_in_station_with_no_other_valid_stops_in_schedule set to 1000

1000.png (1.31 MiB) Viewed 1368 times

train_in_station_with_no_other_valid_stops_in_schedule set to 7000

7000.png (1.19 MiB) Viewed 1368 times

I don't think Pathfinder works with all possible paths. Most likely he chooses the best (in his opinion) from the pair of the first possible ones. And he reaches the paths of 7000 if there are no alternatives.
By the way, repathing not occurring if train waiting at regular signal. So if you can minimize amount of chain signals it could help with performance a lil bit.

1) i have to disagree, you can play without LTN but still enable/disable station with circuit network, i do that most of the time, this means i have plenty of trains at a loading area full of material waiting for any unloading station on the map to open, when buffer of material drops under a threshold. Before the unloading open trains don't move because they don't have a station open on schedule. In this case the pathfinder is behaving nicely. Addind a penalty for my particular case would not yield different result, but would cost more computationnal power if trains start "looking further away" instead of just queuing behind the immobilized train.

But does the train schedule already contain these disconnected stations? If so, then this is not the case.

2) i still think it's the other way around , the limit is (supposedly) fixed, and players have to design their depot accordingly, else the depot itself is the problem. If you propose this function in the mod,to me it means that you implicitly encourage players to solve a design problem by keeping the design the same and just spending more computationnal power to deal with it. However if this function was existing in base mod it could also be used to "reduce" the penalty, in some (rare) cases where trains require lots of CPU usage in 1 tick to find a path, you could prevent them from "looking too far away".

By "design problem" I prefer to understand inaccessible stations or improperly tuned signals leading to jamming. But in cases when i can manually lead a train to proper depot, but pathfinder cannot, i not sure what it is a design problem.
For now, when i planning depots i must keep in mind what pathfinder may not work as i wanted to and add detours and so on.
If or when the pathfinder is changed, then we will see. Could the problem in weights and penalties really be the reason in first place?

However if this function was existing in base mod ...

Not "if" https://wiki.factorio.com/Prototype/Uti ... th_finding

[mmmPI]

Ok let's test it...
Both screenshot with idle (left) state and when all trains on route (right) few minutes. Game speed x18.

I'm not convinced. It's not because i can boil water at 100°C in my kitchen that water always boil at 100°C. Even though for the train problem it means that in some cases there are not significant performance drops it doesn't proove there never will be. (depending on other parameter like increasing number of junction or loop in the network, speed of trains, number train actually crossing path of each other, and so on..).

The logic i use for the hypothesis of performance is very simple : if train find a longer path, it means this path has been calculated. It could be insignificant in many situations, maybe even most of them ; it's just the other side of the trade-off, "better decision at the end" but "spent more time thinking".

i need to learn something like "all path are calculated at first, some are just discarded afterward", then i could understand that there is no performance issue the long path was calculated all along, so it wouldn't represent additionnal computation to "allow" it , it would be different than "additionnal calculation" .

Also i wouldn't be able to understand it even if i could read the code

I don't think Pathfinder works with all possible paths. Most likely he chooses the best (in his opinion) from the pair of the first possible ones. And he reaches the paths of 7000 if there are no alternatives.
By the way, repathing not occurring if train waiting at regular signal. So if you can minimize amount of chain signals it could help with performance a lil bit.

yes , my point was the first pair of possible path would include almost automatically a penalty of 7000, so the pathfinding would reach further before concluding no alternative than if the penalty was 1000. Which depending on the complexity of the network, and number of trains may have an impact.

If train are waiting at regular signal but a station on their schedule open or close anywhere on the map, it would force a repath . In case of a LTN network where all depot(D) are always open and no station open/close though my objection doesn't apply.

But does the train schedule already contain these disconnected stations? If so, then this is not the case.

yes it does contain all station in schedule but they are disabled, i thought it would be considered with a parameter named :train_in_station_with_no_other_valid_stops_in_schedule
It can happen that a train stay at a station and that the only 2 station on its schedule are disabled. wouldn't it be a case of "train_in_station_with_no_other_valid_stops_in_schedule" ?

By "design problem" I prefer to understand inaccessible stations or improperly tuned signals leading to jamming. But in cases when i can manually lead a train to proper depot, but pathfinder cannot, i not sure what it is a design problem.
For now, when i planning depots i must keep in mind what pathfinder may not work as i wanted to and add detours and so on.
If or when the pathfinder is changed, then we will see. Could the problem in weights and penalties really be the reason in first place?

yes i meant problem like a math problem , or problem-solving puzzle, not like trouble, it's a "design exercise"

i would say if pathfinder cannot, you need to tell it how to with signals. It is a limited algorithm but heavily tested reliable and optimised, LTN adds new possibilities. Changing a parameter here and there too, but in those cases i would see it like you prepare some new tools because you have a precise idea about the shape of a wooden sculpture you want to make. Rather than the other way around, having just a saw (vanilla train system) and learning how to carve different shapes out of the wood using it with different methods. LTN would be a chisel ,allowing different shapes, but you may need/want others tool if those available aren't enough to make your idea work. I feel like being the guy only using saw and chisel, saying " i could have done that with my own tool too, no need for those fancy custom chip carving knifes you just made".


Also i don't understand your question about wieghts and penalties. I think the actual system relies heavily on this mechanism that might be tweaked but not replaced.
I wouldn't expect the train pathfinder logic to receive major changes so close to the release of the version 1. but i am not qualified to tell if this would be "major" or not .

Not "if" https://wiki.factorio.com/Prototype/Uti ... th_finding

again i was misunderstood/unclear x), i meant if it was a default settings in LTN that one could configure in the menu, ( it would give incentive) however it does exist in the game and some other mods make good use of it . I would have probably broken a few pieces of wood trying to understand how those tools function .