Train Limits can Soft-Deadlock when Incoming and Outgoing are Both Full

[mmmPI]

The biggest point is consistency imo. A train station should either be occupied ( T > 0, and C > 0) or not (T = 0, and the departing train is not counted towards C)

That would be the most straightforward for a player to understand. But the current implementation i think is easier to use.

When T=0 but C=1 the inserters and pumps aren't active anymore. This is desirable because if you make your train leaves when iron >75 you expect the train to leave with less than 2 stacks of iron, not a quantity that depends on how many times it took for that train to find a destination.

that's not the best example of functionnal use i admit it's the first visible difference i had in mind when considering changing the current implementation so that T stays at 1.

The other change would not be to make T stays positive until the train actually leaves, but to remove C when the train has fulfilled its condition. And in this case the problem is that you can have 2 trains at the same stop while the limit is 1: the train that hasn't found a destination and never left, and the new train that arrived because C was removed due to the previous train fulfilling its condition, ( in this case it would break the no signal possibilities ).

Considering the 2 the least troublesome would be to keep T=1 as long as the train hasn't actually found a next destination. But in this case it wouldn't prevent the soft deadlock. (it wouldn't be enough to change 'just' this to solve the problem it would also require the 'pairing' algorithm).

[Amarula]

Nice discussion:)

Yes really good discussion...
I encountered this soft deadlock the very first time I tried out the then brand-new train limits. I renamed one of my iron outposts to Iron+, one of my iron customers to Iron-, and set one train to the new route. That worked as expected, so I updated a second train to Iron+, Iron-, and voila both trains soon sat showing Destination is Full! So from the very beginning, I understood that the number of stations N always had to be greater than the number of trains, maximum N-1.
I found it very easy to tell if this was might be the problem when Destination is Full started flashing, just click on the train stop: it very conveniently tells me how many stations have that name (Iron+ [27]), and how many trains have that station in their schedule (Trains with this stop: 54)... N.B. all my loading zones have train limit of two rather than one, so N = #stations x train limit, not just #stations.

Until (and if) there is a fix to automatically resolve the deadlock, it would be helpful to have some way to inform players that this deadlock can happen, and how to tell if it has.

[asheiduk]

This is something different i'm not talking about missing signal, just in the case where you don't use signal. in this case train don't crash when you use the train limit system. because only 1 train can be at a train stop with a limit of 1, never 2.

There would be 2 trains at the same train stop if you allow a train to "unregister" with "destination full", the stuck train and a potential arriving train that would crash into the first one. ( or wait outside the stacker if you use signals).

My mental summary so far:

• You talk about exactly zero signal systems but with multiple trains and all stations set to "limit 1".
  I don't believe this is of real concern. The "Hello Trains!" loops have only one train and start from there with signals really fast. Besides: This kind of system is possible "only" since 1.1.
• Stackers would be a real problem.
  
  Especially the kind with one entrance, then a fan out, then a "waiting" train stop with limit=1 in each branch, then a union of the branches with one exit. Each branch/train stop can serve different products. If one "unregistered" train cannot clear the train stop and one additional "registered" train is waiting to reach that stop the entrance for all other trains would be clogged. The stacker would have to be redesigned with branches long enough for two trains although the limit for the train stop is one.

That's a pity because I'd like to have the T vs C-signal idiosyncrasy resolved. But not for the price of the stackers.

[mmmPI]

My mental summary so far:

• You talk about exactly zero signal systems but with multiple trains and all stations set to "limit 1".

Yes, as one example.

The "Hello Trains!" loops have only one train and start from there with signals really fast.

not sure what you mean here.

Besides: This kind of system is possible "only" since 1.1.

True, it is "only" possible since the limit is implemented. It was not the purpose of the limit in the first place, but the implementation allowed those designs as a (lucky) consequences (imo).

[*]Stackers would be a real problem.

Especially the kind with one entrance, then a fan out, then a "waiting" train stop with limit=1 in each branch, then a union of the branches with one exit. Each branch/train stop can serve different products. If one "unregistered" train cannot clear the train stop and one additional "registered" train is waiting to reach that stop the entrance for all other trains would be clogged. The stacker would have to be redesigned with branches long enough for two trains although the limit for the train stop is one.
[/list]

That's a better example than my example of network with 0 signals. The problem with 0 signals is crash, but it's an edge case. The real deal is the 1-too-many trains happening making it 2 trains for 1 stop despite limit staying at 1 or 0.

This is the case where you attempt to resolve the soft-deadlock by allowing 1 train to move. Then it all unfold, the problem being that the rule needed to choose which trains you pick to move first to unfold the whole deadlock are complicated to establish => the algorithm that would "pair" trains.

That's a pity because I'd like to have the T vs C-signal idiosyncrasy resolved. But not for the price of the stackers.

I think another way to see it is to consider the signal T is emited for pump and inserters in relation with cargo wagons (train presence for material transfer). Whereas the signal C or N are intented for train pathfinding/routing ( incoming train, train limit ). They are not exactly emited at the same time because they serve different purpose. There can never be a signal T if the limit or incoming trains were 0 all along. But it is possible that the incoming trains or train limit is positive but there is no signal T.

Now is there a train present at the location ? Well for another train it depend on C so it can anticipate that a slot is reserved and not move, but for inserters or pumps, they look at T because even if there is an actual train at the location it doesn't mean the train is stopped, or that interaction is supposed to happen. Only when T is present you know the train is at the station because of its schedule .

[ssilk]

Hm, what Nilaus describes in his video is not nearly a bug. He is just ignoring, that any transport system similar to the trains in Factorio can deadlock at any time, if you add too much trains. If he reduces his setups just by one train, the systems keeps working, but because in Nilaus games everything must be nice and perfect he insists on doing it wrong.

It has nothing to do with the train limits, it's kind of a basic physical principle that if you push N trains in a system of N stations limited by 1 train, that this will lead to problems. Or to describe it with other words: If you have a circular system in only one direction, containing two buffers (=train stops) with a limit of one entity inside, you cannot add more than 1 entity into that system without danger of getting deadlocks.

Sometimes the perfect solution is not looking nice. In my practical work, the not so nice looking solutions have been often proved to be working much more reliable. It's just a human thinking pattern, that good solutions need to look nice. But as said, that's just a Nilaus-thing. [I really apreciate his videos, it's no wonder that he has some success with them, but I never would build my factories similar to his]

And the only thing that helps is make more buffer or less trains. In this case buffer depots are in my eyes the way to go. Well he has some good point with depots all around the place, which are time-consuming. But for that I can recommend Klonans mod
https://mods.factorio.com/mod/Train_Control_Signals
"If a Depot signal is found in the station name, the train will skip over the station if its next destination is open and has enough space."

I mention this, because this idea of jumping over stations leads us straight into some suggestions already made:

viewtopic.php?f=6&t=49214 Train Entry-Condition
viewtopic.php?f=6&t=64362 Dynamic train schedule
viewtopic.php?f=6&t=53792 train-stop id and train targets a train-stop by id
viewtopic.php?f=6&t=58057 Trains ignore stop if wait condition already met
viewtopic.php?f=6&t=59378 Train-side stop disabling and a toggle for station skipping
viewtopic.php?f=6&t=58646 Jump on train automation
viewtopic.php?f=6&t=25944 Train station skipping conditions
viewtopic.php?f=6&t=100426 Train Target by Order of Schedule (was: Dynamic train schedule)
viewtopic.php?f=6&t=89618 Trains need to skip unload stations when empty
viewtopic.php?f=6&t=83636 Do not stop the train at the station, if the conditions are already met
viewtopic.php?f=6&t=63837 Selective Station Enabling
viewtopic.php?f=6&t=50128 New Train-Schedule-Mode / Conditions instead of Train-Stop-Names / Remove Names from Train-Schedule
viewtopic.php?f=6&t=49444 Add "Next Station Enabled" to train wait conditions
viewtopic.php?f=6&t=53792 train-stop id and train targets a train-stop by id
viewtopic.php?f=6&t=59378 Train-side stop disabling and a toggle for station skipping.
viewtopic.php?f=6&t=51008 Train stops and schedule improvements

Far related:
viewtopic.php?f=6&t=70935 Improved Access to Train ID
viewtopic.php?f=6&t=71817 Add extra reservation factor to locomotives

Counter suggestion:
viewtopic.php?f=6&t=90505 is [Train] New wait condition to compliment v1.1 — condition to not skip stations

So there is a very deep evidence that many players see the need to control the order of schedule. In my eyes that is also the right way to go, because there is really nothing wrong with the current implementation of the train limits. It works perfect, it's just so, that humans cannot understand the difference between space and buffer, because in real physical world there is no difference between both (why does the train not just drive out of the station, there is enough space?), but which is the basic underlaying principles of Factorio it is.

[disentius]

I agree with your points in general. ssilk, but the "bug" is something else:

To clarify the "bug":
1. train wants to leave
2. there is no free station available. All destinations report x/x as trainlimit/train reservation.
3.The train has left the station (no "T" signal) yet the station counts the departed train toward the reserved trains in x/x

[ssilk]

Ah. Thank you. I admit I haven't read the whole thread.

Hm.
Not a bug.

The T-signal is cleared, to avoid further filling/emptying of train. But the train hasn't left the station yet, because to leave the station the pathfinder needs to find a free target. As long as that is the case it is correct (the safest) to keep the stop occupied.

And what should it bring? If I add another train it will fall into the same problem again.
(1 train more than stops? Or N more? dunno, haven't thought deep enough into it, but it surely will be the case at any time)

[robot256]

You can have an infinitely long sequence of N stations with N trains traveling them in order. All you need is ONE station in the route with a slightly longer entrance track and train limit=2 for it to never deadlock.

If your goal is to make all the trains move at the same time, conveyor belt style, that is a job for a global circuit network. You can easily detect when every station has no T signal, and change all the train limits to 2 for a single tick, for example.

Keep the internal game logic simple and predictable. Build the complicated edge-case handling for your particular system around it.

[ssilk]

You can have an infinitely long sequence of N stations with N trains traveling them in order. All you need is ONE station in the route with a slightly longer entrance track and train limit=2 for it to never deadlock.

Yes, what I said is valid for train limit of 1, of course. What counts is the size of the buffer you create with the sum of all buffers (stops summed trained limits).

BTW, you can achieve that also by increasing the train limit for a short time (1 tick shoud be eough). You need a global circuit network (I still recommend to use radio stations instead) that sums up all train limits and subtracks what's still left from that buffer size, and if you reach 0 you add 1 to the train limit of a random station (or all).

If your goal is to make all the trains move at the same time, conveyor belt style, that is a job for a global circuit network. You can easily detect when every station has no T signal, and change all the train limits to 2 for a single tick, for example.

I should read the whole text before I write and suggest exactly the same and most obvious things.

Why I really have been going into this thread is to point out, that this isn't a bug in any kind. It's a small issue from missusing the train limits and it's easily solveable.

[FuryoftheStars]

Why I really have been going into this thread is to point out, that this isn't a bug in any kind. It's a small issue from missusing the train limits and it's easily solveable.

I could be wrong, but I think robot256 was replying to the thread in general (vs you) and was essentially posting in agreement with you as well.

That said, I'm also in agreement with you and don't think we need to have something like the OP's suggestion done to the base game.

To me, a station is empty and ready to receive another when the train has actually departed, not when it's ready to depart. There's no guarantee that the train that's ready to depart is actually going to depart, because maybe its destination isn't done/ready yet. I don't need something unnecessarily traveling and then stopping and blocking up the rails when the station isn't actually ready to receive it yet.