Factorio Forums

TL;DR

Add extra penalty rule for recently used stations with shared names.

What ?

Add a penalty rule for a trainstop that has recently been used so more stations can be served with higher probabilty

Why ?

after asking on the forum and doing some testing i noticed that a trainstop with a shared name and limit set is favorited due to location over the others if not enough trains can cover all the other trainstops (due to wathever, slow loading, refueling etc etc)

my idea is to implement an extra penalty rule for a station that has been recently used and that penalty value would drop down over time.
so eventually that station becomes again the most perfect route but all others had a chance to get materials.

this would give other stations more chance to also be served.

So many questions without answers.

If every train stop would be served really fast, all of those train stops penalty would increase unbounded making the trains pathfinder to at some point to visit the whole rails network "because maybe there is a way to avoid that penalty" causing some increased performance penalty.
.. and trains pathfinder is not implemented in a way that allows adding penalty on the goal itself.
How large should be that penalty? how fast or how slow should it decay?

For me this is a clear "do not implement"

the penalty should only be aplied once. when the station gets revisited it should just reset to the penalty starting value.
so the values wont keep increasing, just resseting.

for the value i dont know for sure. but the devs probably have a formula for that determine the best value.

i dont understand what you mean by "not allowed to add a penalty on the goal itself" signals are also temp goals along the route with a value that the pathfinder reads to determing the penalty.

so why would it not be possible for a train stop?
imo its already a part of the penalty system. as it reads if there is a train or one on the way there depending the limit at the station.

tell me if i'm wrong but the whole idea from the limit/shared names is to have more trains be able to visit more likewise stops.
but if one gets better values all the time its kinda pointless unless i flood the system with to many trains just to be sure all stops are coverd 100% of the time.
otherwise we are back to a single train for a single purpose between two or more fixed stations.

and fyi, rejecting before getting more answers to your questions is kinda strange.

You can implement such rules with simple timers for each station by circuits. Just start a combinator-timer, when a train arrives, that sets the number of trains for that station to zero (or whatever), and after some time bring that value back to “normal”. Sounds to me like a similar mechanism.

To your question with penalty: the game cannot add a penalty to the end-point of a route. I admit, that this looks like a weak argument. But we cannot know, how that is implemented in detail, and the https://de.m.wikipedia.org/wiki/Dijkstra-Algorithmus we know that is used here doesn’t.

What also looks like a better idea, is that we have “signals or signs”, that can add penalty to a train path, when passing. The latest thread about that:

viewtopic.php?f=6&t=90836 Train Filter Signs


Rejecting a post so early by a dev might also be a sign, that there are other plans...

Isn't this exactly what train stop limits are for?

Kyralessa wrote: Tue Jan 19, 2021 7:18 am Isn't this exactly what train stop limits are for?

No. Train stop limits were implemented because of the train horde behavior when there were multiple trains in a rail network and when a single request train stop would open, all of those trains would rush through half of the map, first train would arrive, train stop would disable and all trains except one would have to go back. The train horde issue was not easily solvable using in game mechanics (like by using circuit network) because all of those trains would repath at the same tick leaving no time for circuit logic to react. Primary thing behind the trains limit is the trains counter which is updated immediately when one train repaths so when another train also repaths in the same tick, it may see given train stop as full even if the previous train repathing in the same tick saw it as available.

ssilk wrote: Tue Jan 19, 2021 6:46 am To your question with penalty: the game cannot add a penalty to the end-point of a route. I admit, that this looks like a weak argument. But we cannot know, how that is implemented in detail, and the https://de.m.wikipedia.org/wiki/Dijkstra-Algorithmus we know that is used here doesn’t.

Code for trains pathfinder is kind of available but it is not a recent one. In that code nodes are related to rail segments, total penalty of a node has to include everything up to end of a rail segment but not including the penalty of a train stop because that node will also be used for expansion, and at the same time when a node is checked for a possible path (when it has train stop in one of its ends) when there is and end, it is returned immediately - because of that even if i would add a penalty to a goal train stop, it would not be effective because either first train stop visited would be returned anyway, or it would cause not only the train stop penalty to increase but also of all the paths that would be forced to go through that train stop while avoiding it. It is possible to implement with some marker nodes inside of the heap so the penalty of that node would be equal to the penalty of the path + penalty of a train stop so the nodes expansion could continue and only when all other paths would have higher penalty than total penalty to already found train stop + its penalty, then it would be returned. I am simply not willing to implement unless there would be a good reason to add that.

LoneWolf_LWP wrote: Tue Jan 19, 2021 1:42 am so why would it not be possible for a train stop?
imo its already a part of the penalty system. as it reads if there is a train or one on the way there depending the limit at the station.

Enforcing trains limit is not implemented through pathfinder penalty system. If it would, i would have to add an infinite penalty and the only thing i would get would be "if all train stops are full, train is still choosing a train stop and going there" - if the penalty would be infinite, pathfinder would still be able to find a path and i would have to have an penalty gate where some paths would be decided as "ok, this penalty is too large, just ignore the result" that would give a performance penalty (running trains pathfinder on the whole rail network) for a useless work. Limits are enforced by not adding train stops at all to the goals vector so the trains pathfinder is unable to find a path to that train stop. This has some nice properties like allowing to skip running the pathfinder if there are literally 0 possible goals, and it helps with heuristic as it does not have to guide the search process into the train stops that will not be reachable anyway.

LoneWolf_LWP wrote: Tue Jan 19, 2021 1:42 am and fyi, rejecting before getting more answers to your questions is kinda strange.

Its not that i am rejecting it "because of coin flip". Train stop limit is to solve issues when there are more trains than train stops. If there is only 1 train and multiple train stops there is no need to use the trains limit except maybe setting trains limit to 0 instead of disabling train stop as setting the limit to 0 will not force repath of trains that are already on the way.
Large part of Factorio is problem solving, sometimes you have to make a little belt spaghetti to add one extra belt, sometimes you have to create one large build to get more stuff produced and sometimes you have to create some combinator contraption to control trains. This particular problem is solvable by at least 3 different approaches: 1/ using unique train stop names and having train with schedule like "load stuff, go to A, load stuff, go to B", 2/ having a map wide circuit network where there is a signal that points which train stop should be enabled at the given point in time and when train visits the train stop it pulses to the circuit network which increments the signal causing another train stop to open, 3/ by having some combinators local to each train stop, when a train arrives it clears the counter and that disables train stop and when the train leaves the counter gets reenabled and when it reaches certain value a train stop opens again.

Lets see if the idea would be implemented as suggested: there would be a penalty to be choosed and i do not know about any good approach to choose a proper value here. Too small and the train would not visit some train stops that are farther than the others by a distance equal to that penalty. Too large maybe would be ok but that always comes with a cost of increased pathfinder running time. What about the sustain time or the delay: if it would be set to 1h in a network with short distances and fast trains would look like this: train visits every train stop once (as designed) within first minue and for the remaining 59 minutes it is only serving stuff to the closest train stop because all of those train stops have the same extra penalty +RECENTLY_VISITED. After 59 minutes the penalty of those other train stops gets cleared and they are visited once and another 59 minutes of single train stop being exclusively targeted. What if that decay would be set to 1 minute and the rails network is large? Train goes to the closest train stop, unloads here, train stop gets penalty, train goes back to be loaded and in that return period the penalty already decayed so the train will again choose the same train stop as its goal. Lets assume the penalty would be added every time a train visits a train stop so it avoids the issue of the first case where the train would for 59 minutes only deliver stuff to the closest train stop. This is exactly what i mean by the "unbounded" penalty where it could be added multiple times. Now if the decay would be set to 1h all those train stops would be visited roughly equally but their penalty would be increasing unbounded. If there would be another train stop that was disabled for the whole time and it would be enabled it would get all the "not yet delivered" deliveries because its penalty would be so low that it would be the best candidate for the train to choose even after couple of deliveries as it would be skipped only when the penalty would become equal to the penalty of other train stops.

Because of existing solutions using in game mechanics, this topic for me reads as "player has a problem in a problem solving game, player does not want to solve the problem so requests devs to solve it for them". Because the suggested solution is only solving an issue of particular player and the solution itself is in no way robust (would need a lot of weird numbers and they would be only appropriate for cetrain rail network sizes with certain throughput - it is a clearly "do not implement". I am not rejecting this idea too early, i simply tought about it and because of all the issues it would create while not really solving anything i decided it is not worth it.

Ty,

for you detailed explenation

boskid wrote: Tue Jan 19, 2021 10:00 am
Because of existing solutions using in game mechanics, this topic for me reads as "player has a problem in a problem solving game, player does not want to solve the problem so requests devs to solve it for them". Because the suggested solution is only solving an issue of particular player and the solution itself is in no way robust (would need a lot of weird numbers and they would be only appropriate for cetrain rail network sizes with certain throughput - it is a clearly "do not implement". I am not rejecting this idea too early, i simply tought about it and because of all the issues it would create while not really solving anything i decided it is not worth it.

It just felt like the train shared named system missed something due to 1 station getting more attention and I noticed it ingame.

It's not that i dont want to solve the problem. I like sovling problems. And I already got the solution.
I now just have to get it somehow in a circuit, have not messed around with those to much yet.