#Reservation "upgrade should be togglable"

1 messages · Page 1 of 1 (latest)

cerulean birch
#

Making this a thread because the general chat is far to active/random. I'd like to drill down on some pros/cons here.

Pinging @raven shoal and @woven spoke since you responded/reacted. If you have no further commentary feel free to leave the discussion.

I would be interested to know if other people encountered this problem in 1.1 as well.

I personally have not encountered this problem. Honestly, I view this as a problem with signaling or some aspect of top level design with a rail network. I can see how this situation could lead to confusion for newer people, and I think I can see some interesting use cases for the block reservation to make management of some systems better with this new feature, but I do not believe that this should be mandatory. It really should be a togglable option on the train station.

I'm also not convinced that it will help newer players that much because they don't understand train limits well/at all in the first place. I'd say that the majority of deadlock posts that I see in #train-help come down to incorrect signaling mixed with no limits on stations leading to large conga lines.

#

_ _
Sort of on topic. I think there is a large amount of room for improvement in the train tutorials. There should be some more advanced scenarios that demonstrate concepts like limits and how to use them, as well as weird signaling rules like "if trains can't fit betweeen two intersections, treat them as one large intersection and replace rails with chains". That's a very commong stumbling block for newer people.

raven shoal
#

I can definitely see how it could be a problem, and I think having it on by default would be good. However, I would really love being able to turn it down to improve throughput

neon loom
#

The problem occurs in tight ~~stations ~~ depots and stackers, sometimes you can get weird behaviour, it's not common and highly unpredictable, this would fix it.

#

This also wouldn't affect changeover time at all in stations with limits > 1 (the train waiting at the previous signal needs to wait for the block to clear anyway)

cerulean birch
# neon loom The problem occurs in tight ~~stations ~~ depots and stackers, sometimes you can...

the train waiting at the previous signal needs to wait for the block to clear anyway

I routinely have a rail signal slightly forward of the rear end of trains to segment the block so that I can have a train begin pulling into the track section leading up to a station while the current train is beginning to leave. If the exists are signaled correctly (and you have the correct top level design to prevent conga lines from making a huge loop and jamming), you can rely on the current train leaving soon™. It might not be instantaneous, but having the new train pull in and potentially parked partway into the station while the old train is clearing/waiting to clear is a good way to keep changeover times low without relying on making an enormous two train long stations.

My reading of this update is that this effectively breaks. I guess you can cudgel a fix together with circuits to temporarily set the limit to 2, but that's really clunky and unintuitive.

neon loom
#

You would never have the second train waiting there if the train limit wasn't set to 2 in the first place, and in basically every case a couple seconds won't make a difference to the overall trip time in the case you have the stations set to 1

cerulean birch
#

It's not overal trip time.

#

It's changeover time

#

For low stack size high throughput items that is the limiting factor, particularly when you're trying to grind out UPS optimizations and minimize inserter spam.

neon loom
#

Changeover time doesn't apply when the limit is set to 1, there will never be a train waiting to get to the station

cerulean birch
neon loom
#

So it is overall trip time in that case

cerulean birch
#

No

neon loom
#

The train has to come directly from the loading station, it can't wait at the unloader if the limit is set to 1

#

so you need to factor in the entire trip time once the first train leaves when the limit is 1

cerulean birch
#

Depots, or preunload stations nearby.

neon loom
#

so then the trip time from the depot, or you could just set the limit to 2 instead of using a preunload station

cerulean birch
#

The benefit of preunload stations is that you don't need 1 for every unload station.

neon loom
#

True, this is quite edge case though, and the benefits we're getting in terms of interrupts can save you train counts in other ways

cerulean birch
#

You can have 5 preunloaders servicing a dozen unload stations

#

and more importantly, they can be off to the side somewhere.

neon loom
#

although in the case that turnover time matters that much you might as well have one behind every station, using a limit of 2

cerulean birch
#

So you can deal with UPS optimization contortions

cerulean birch
neon loom
#

Practicality, this is quite edge case

cerulean birch
#

One of the more extreme ones, sure, but there are others.

#

Besides, I don't see why that matters.

I'm not saying that you can't come up with alternative solutions. My point here is that there is a demonstrable functionality regression if this system becomes mandatory.

neon loom
#

If it can be a simple toggle (in the station, I presume) I could see it, but it's such a small difference in timing overall I would be surprised if it even registers as a big enough issue unfortunately

#

Arguably we're losing a similar amount of functionality/timing with the larger turning radius of rails, but we got other benefits alongside it

#

different scales but similar issue

#

You'd have better luck joining in on the forums and building support there

coarse pecan
#

I think we need clarification on whether it’s the front of the train or the entirety of the train leaving the block

#

I read it as the latter, but if it’s the former then it’s not really as much of a problem

vivid stream
#

based on the stated goal, I assume the whole train

raven shoal
#

I assume entirety

coarse pecan
#

I don’t think it needs to be the entirety to solve the stated goal though

glossy hound
#

I can't fathom how you'd design a rail network where you'd have a train leaving a station that ends up staying there for long enough where another train arrives, and the rail network is designed to where this is actually a problem

raven shoal
#

I think part of it is that "Destination full" technically counts as having left the station

coarse pecan
#

The stated goal was “trains that can’t move and have destination full still take up the station”. If the front of the train leaves the block, by definition it can’t be waiting on destination full

#

If you have a deadlock then that’s a whole separate issue

glossy hound
#

why not just make it so trains that don't path to a station don't leave yet, and once it obtains a path that's when it gets removed from the count

raven shoal
#

that sounds fair tbh

glossy hound
#

the position of the train is a side solution that I feel we're getting distracted on, if it's only destination full trains that create the problem, then make destination full be part of the solution

#

@worldly stone probably should see this thread

warm sky
#

I had a situation where I had 1 train accidently stopped in manual mode on the tracks. This caused a pile up on the tracks right up to a mine. But even though there was a train still in the station, the mine kept requesting new trains. And the trains wouldn't enter the mine's stacker but would wait outside. And then the train decided to switch its destination to a different mine, but would fail to reach it because there was still the pile up in the way. Then because a slot had opened up, the mine requested yet another train to go to it. Repeat. So 1 station which WAS full kept requesting more and more trains until it had requested all the trains of my entire base, and they were all stuck there.

So a minor problem which should have only disabled 1 mine but left the others running, instead caused my entire train network to fail.

With this change, the train stopped on the tracks would stil have disabled the mine, but the mine wouldn't have kept requesting trains when the train stopped at the station wasn't able to leave yet.

vivid stream
#

that paragraph said nothing about destination full. this is what it says:

The problem is that once the train decides to leave the station, it instantly clears the reservation of the train limit, while still physically blocking the stop. This lets another train start its journey toward the stop, while there might not be enough space to wait without blocking the mainline.

coarse pecan
#

I do think that it’s a problem that can be solved with better rail and station design, but also that the current proposed solution in the FFF isn’t adequate

raven shoal
#

I do agree with "the current solution is not the correct solution for a plurality of players"

#

I'm not sure what the correct solution is, though

raven shoal
#

it will be considered as having left the station regardless

glossy hound
#

I feel like if a train has a path to another station, the chances of it actually blocking the one it's currently in for long enough to make other trains back up are very low and can easily be designed around

coarse pecan
#

The destination full is simply the most egregious and easily recognizable instance of why a train would be stuck there

vivid stream
#

that's not how i read it tho, i read it as the train leaves the station and has a valid destination, but there is traffic on the mainline so it sits and waits

raven shoal
#

that's another possibility

glossy hound
coarse pecan
vivid stream
#

if it's destination full then it hasn't left the station yet, isn't that currently the case in 1.1?

coarse pecan
#

It feels like an artificial problem introduced by doing something silly by having only a static limit of 1 and trying to have a no buffer/high throughput station

raven shoal
#

if it's destinationfull1destinationfull2 then it frees up the train limit because it left

glossy hound
#

if they want to build so compactly and have a limit higher than 1, then they can use circuitry to control it

raven shoal
#

(unless that changed)

coarse pecan
#

I agree that it’s solving a problem that should not exist

vivid stream
glossy hound
#

you can do this in vanilla right now by reading a signal and lowering the limit by 1 there's a train still in the station

#

and if people actually do have this problem, then they can do that to fix it

coarse pecan
#

If you’re using dynamic limits the usual way, then the limit would automatically be lowered by 1 by the inventory transfer from the train to the station dropping it below the threshold

#

Not saying that’s the only way or the right way to solve the problem, but is a non issue for the most common circuit control method

glossy hound
#

I will say in my years of helping people with trains, I have never come across this as a problem somebody had to solve

warm sky
glossy hound
#

yeah, I saw

#

I've been here

coarse pecan
#

That feels like conflating another separate problem into the mix

glossy hound
#

I feel like that's a flaw very specific to your system, not even sure how you'd request literally every single train in vanilla

warm sky
#

I mean the way it mechanically happened is:

Station limit of 3 with enough space for 3 trains

Train "leaves" (but not really - it's still stuck at the station). Train limit is 2/3 so another train gets requested. Train can't enter stacker (since space for 3 trains). Train that is stuck outside the stacker "leaves" to go to an alternative station with the same name, except not really because the train is still stuck. Train limit is again at 2/3. Repeat

coarse pecan
#

The fail safe there is that the station buffer should fill up eventually

#

And stop increasing the limit

#

Right, so having a rail bypass would have solved the issue

glossy hound
#

what do you mean by "except not really because the train is still stuck"

coarse pecan
#

Any number of other design choices would have solved the issue

glossy hound
#

are there other stations actually available?

warm sky
#

There was a pile up on the tracks leaving the mines caused by a train accidently left on the tracks in manual mode

glossy hound
#

would it have been solved by removing the manual train

warm sky
#

which meant trains couldn't leave the mine

coarse pecan
warm sky
#

yes: removing the manual train did solve the problem; the issue was not that the mine was disabled (which couldn't be avoided given the circumstances), the issue was that the mine requested all trains of my network

glossy hound
#

then I fail to see the issue, it didn't cause a meaningful deadlock

#

if the problem was caused by leaving a manual train in the network, and removing it solved the problem, then it's fine

warm sky
#

How is ALL trains of my network stuck at 1 single mine not a meaningful deadlock?

shy stone
#

i believe what hes saying is that in re-pathing because hte manual was blocking the route, it was giving up its claim. so another train went to take the claim and got to the same manual train and repathed again. repeat for all trains

glossy hound
#

because it fixed itself after you removed your mistake

shy stone
#

but it was human error that caused the spiral in teh first place. simply removing the manual train would have them all self-sort as normal

warm sky
#

Expected behaviour from messing up 1 mine's rails: that 1 mine is disabled.

Not expected behaviour from messing up 1 mine's rails: the entire network is disabled

shy stone
#

there is a joke in that 'the smarter a system is, the dumber it gets'

robust falcon
#

This is the design that maybe can deadlock in 1.0, I guess?

image.png
warm sky
#

Expected behaviour is that the mine requests only up to its train limit in trains (in this case 3), so 3 trains get stuck, but not any more

glossy hound
#

this problem was not caused by the train limit becoming available from a train leaving, it was caused by you leaving a manual train on the tracks causing a deadlock. in your specific scenario, the train originally stuck because of the train was still in the station, and this problem technically would be solved by the proposed train limit restriction, but the overall problem is not prevented, because if you had a little hit of space after the station, it wouldn't even be using the new feature and the problem's source is still the manual train

shy stone
coarse pecan
#

Having a train in manual on a mainline would also cause the same kind of deadlock

#

(Eventually)

warm sky
#

No, the new feature would absolutely have fixed the entire problem. The crux of the issue was a station with a train limit of 3 requesting more than 3 trains.

robust falcon
#

🤔

coarse pecan
#

Right, but what level of “we’re going to protect against someone doing something silly and in the process break a number of other valid things for everyone else” is this going to go to?

formal hollow
robust falcon
#

I think I can make a POC deadlock design, but it's weird AF

raven shoal
glossy hound
#

which immediately cleared up once you removed the manual train

robust falcon
#

...
I see a more simple one now
Basically it's a dead end station that will break if if's not signaled correctly?
Still weird

glossy hound
#

this new feature is not meant to solve your (as a generic player) stupid mistakes, no offense, it's supposed to solve something that could happen automatically, at least that's what it sounds like

warm sky
#

If one planet has rails randomly getting destroyed, than this problem could happen to anyone

glossy hound
robust falcon
glossy hound
robust falcon
warm sky
#

The only thing you need to replicate the problem is:

  1. a station with a given train limit of x and enough space for x trains
  2. an alternative station with the same name somewhere in the network
  3. the tracks leaving the station get disabled in some way
glossy hound
#

would the alternative station also have a limit

warm sky
#

In this case it did, but it is not necessary to replicate the problem

coarse pecan
#

Well it’s an important distinction if it means the difference between 3 more trains and literally your entire network

glossy hound
#

because eventually, all of the station's limits should fill up and the trains attempting to go to the original station would not be able to repath

#

if it didn't have a limit, then it truly would send out all of your trains

robust falcon
#

engithink
I have another idea how to cause a deadlock
Make it 10 parallel stations with a single exit rail, and make 10 trains leave that stations at once

#

That will cause them to request 10 trains that may cause a deadlock?

vivid stream
#

stations can request trains now?

robust falcon
#

As the stations are still waiting to be freed from the leaved train

robust falcon
vivid stream
#

ok

warm sky
#

Look; all I'm saying is that the expected behaviour from a station with a train limit of 3 is that it should stop requesting trains once it has 3 trains.

glossy hound
#

expected usage of a rail network is to not leave manual trains out to block other trains by accident

#

it does stop requesting trains once it hits 3, your scenario just didn't allow it to ever hit 3

#

actually, it did hit 3, many times, each time a train was requested, they just repathed away causing it to go back down to 2

#

there was never more than 1 other train going to the station at a time

vivid stream
#

instead of setting a train limit on the actual train stop, you could put a dummy train stop in the block immediately before it and control that stop's train limit instead, to achieve the eager approach behavior in 2.0

warm sky
#

That's how it works in game, but it is extremely counter-intuitive that the train in the station doesn't actually count as being at the train station or counting as part of the train limit.

glossy hound
#

hypothetically, let's say that you extended the length of your stations but kept the stop in the same spot

#

allowing trains to completely "leave" the train stop, but still get stuck on your manual train

#

now the new system wouldn't prevent anything, in fact it would cause more trains to be stuck

warm sky
#

I don't need to imagine, that's how it was. The new system would have a few trains be stuck, but not all the trains of my base, because once the station would be full, it would stop requesting every train of my base, and then the trains would avoid the disabled section of tracks (since they have no reason to be pathing into it anymore) and take an alternative route around.

glossy hound
#

I'm still not sure how you're getting the idea that it's requesting every single train in your base

warm sky
#

Because that's what happened?

glossy hound
#

eventually, but not all at once

warm sky
#

Every train of my base ended up stuck waiting outside this one mine with a train limit of 3

glossy hound
#

and what were the train limits on all of the other stations

#

also 3?

warm sky
#

yes

glossy hound
#

were they static limits? or did they change based on the chest contents

warm sky
#

no, just regular static limits

glossy hound
#

then that is also something that contributed to this problem

warm sky
#

If you're going to say something like "not all trains, all but 3 trains", then fine, all but 3 trains

vivid stream
glossy hound
#

and I just want to clarify: was the manual train also blocking the entrance to this station

warm sky
#

no, but it was blocking the path that trains would have to take if they didn't enter the station

glossy hound
#

okay, so it was on the main line blocking the station exit (and also the main line, implied)

coarse pecan
#

So what I was saying 15 minutes ago about having a station bypass would in fact have also solved the issue

warm sky
#

Regardless, expected behaviour is:

error in the railway causes trains to be stuck at 1 particular stop in the network outside a mine
-> trains can no longer leave mine
-> mine eventually has 3 trains and a train limit of 3 so stops requesting trains
-> all other trains avoid the disabled mine to head to other (still functioning) mines, and also do not path into the disabled section of tracks, preferring to take a detour (just from basic pathfinding)

Instead, what happened was:

error in the railway causes trains to be stuck at 1 particular stop in the network outside a mine
-> trains can no longer leave mine
-> mine eventually has 3 trains and a train limit of 3 but KEEPS requesting trains
-> all trains of the entire network get themselves pathed into the disabled section of tracks
-> no trains

glossy hound
#

error in the railway causes trains to be stuck
fixing the error instead of treating the symptoms also solves the issue

warm sky
glossy hound
#

a rail going past the station

warm sky
#

I mean, I did have that?

coarse pecan
#

Then you shouldn’t have had a problem

#

Train stuck, other trains behind it repath -> they take the bypass and go around

#

If you had a bypass then something (probably signaling) was also wrong

warm sky
coarse pecan
#

Why do you have so many trains stopped on the tracks?

robust falcon
warm sky
robust falcon
#

Here
Not quite deadlock because it has no crossing but almost is a one

vivid stream
robust falcon
coarse pecan
#

How did a train get stuck in manual there?

warm sky
#

I was making trains with bots and forgot to put it into automatic mode

vivid stream
coarse pecan
#

Stance has not changed that egregious user error outside of normal operation isn’t a valid use case for the proposed kind of protection

glossy hound
#

why are they repathing to other stations then, it seems like maybe one or two trains fit after/in the station, then there would be 3 after it trying to go in

coarse pecan
warm sky
#

There is enough space for 3 trains in the station (1 actually at the station, 2 in the stacker) so I set the train limit to 3

coarse pecan
#

Don’t let trains path somewhere that goes through a manual train, essentially. Which sort of already happens but implies the penalty might need to be higher

glossy hound
#

it's literally 7000 lmao

warm sky
glossy hound
#

that's not what it is here

#

that's only for trains in automatic stopped at a signal

#

manual trains have a flat 7000

warm sky
#

Yes: the train stopped at the signal has an infinite penalty for continuing along the route they were going, but only 7000 for going to a manual train, so they pick the manual train

#

since 7000 is less than infinite

glossy hound
#

so this problem only occurs once you've had this manual train blocking the station for 69,000 ticks (not joking, that is the number), which is almost 20 minutes

warm sky
#

I mean yeah, I play factorio for more than 20 minutes

raven shoal
#

... nice?

vivid stream
#

are you guys talking about 1.1 stuff or are you hypothesizing about the 2.0 generic LTN-like system?

glossy hound
#

20 minutes leaving a manual train in the middle of your rail network next to a station, while also not having many trains path to it in that time otherwise they would just fill out the limit, and having it be the only path for same named stations with point A and point B being on either side of the train

vivid stream
#

because I think I'd need to see the 2.0 stuff or have it in my hands to be able to say for sure if the reservation upgrade is good or not

glossy hound
#

also with static limits and not even any form of dynamic control on the limits

#

and that could be solved by removing the offending manual train

#

I think it's safe to say that this is a relatively niche issue that you have experienced

#

doesn't make a strong case for the feature to exist imo

warm sky
#

Is this kind of diagram really that rare for a random mine in the network?

glossy hound
#

not particularly, but the circumstances surrounding it are

#

if you had these connections with a second rail, or a network with multiple paths, then this wouldn't have happened anyway

image.png
#

or, you know, don't leave a manual train unsupervised in an apparently crucial spot in your network

warm sky
#

It wasn't a "crucial spot", it was 1 random mine; I had plenty of others. And there was absolutely no need for any train to take this section of track unless it was specifically going to or coming from that mine. There was nothing else of interest in this bit of the network.

coarse pecan
#

You’re telling me you don’t just watch the map to watch the trains go?

#

Heresy

vivid stream
#

the good news is:

  1. the old tricks could still be accomplished (differently) in 2.0
  2. the code change is probably relatively simple to remove the feature
  3. if it's niche, there will not be much resistance to changing it after 2.0 drops if there is enough feedback from the few people who want it removed
    so I'm not sweating it
warm sky
#

The way I discovered the problem was "why is my research slowing?" -> "why is yellow science dropping?" -> "why is LDS not being produced?" -> "why is copper low? I still have plenty of mines?" -> WHY ARE ALL MY TRAINS STUCK WAITING OUTSIDE THIS 1 RANDOM MINE?

glossy hound
#

this has the same energy as "oops I rotated a belt and now my factory is broken, why didn't factorio give me a solution for this"

#

like if you don't want that problem, don't use a system that allows it to even happen in the first place

#

do you still have the save where this happened?

#

I'm genuinely interested in seeing the pileup

warm sky
#

I do have the save, but at a different point, I don't think I have the pileup itself.

glossy hound
#

if it's truly that influential of a problem, I'm sure it can be replicated

warm sky
#

Just build a network with stations like this #1185263504618438777 message

And build your base with plenty of redundancy so that IN THEORY any local problem only does partial damage to the base but the rest can still keep going (mine gets destroyed by biters -> there are other mines; tracks get destroyed -> 1 block might not be useable, but there are other similar blocks, each with their own stations; etc.)
Then disable 1 piece of track somewhere

#

Actually wait, technically you have to disable it in a way so that the train pathfinding logic for going through it is not infinite.

dusty depot
#

I always assumed that "Destination Full" trains counted against the train limit for the station the train is waiting at ...

raven shoal
#

they do

#

I was wrong :)

dusty depot
#

Oh, okay!

cerulean birch
# warm sky The only thing you need to replicate the problem is: 1) a station with a given ...
  1. the tracks leaving the station get disabled in some way

If the tracks are destroyed, then trains can't path to that station entirely. This is purely because you had a dead train on the tracks somewhere.

I don't see how the new system would fix the issue that you are describing. The issue was trains being unable to even get to the station in the first place, no? The update would merely delay trains attempting to go there until the previous train had cleared the block, but if multiple trains were queuing up, that would still happen, and the same problem would still occur if too many trains were queueing up sufficiently far enough "forward" that they could never repath because they had pathed past a point of no return.

That last bit is the important part. That should not be possible in a "proper" system. I'd love to see a save file of this event if you have one.

warm sky
dusty depot
#

im not familiar with random's base but the developers apparently experienced a similar problem that "became more important" and presumably more common with new expansion features

warm sky
#

The new system would fix this issue because now when there are 3 trains at the station, the train limit is at 3/3 so no new trains path there

cerulean birch
#

There are never 3 trains "at" the station though????

warm sky
#

previously when there were 3 trains at the station, the train limit was 2/3, so new trains kept getting sent there

#

here "at the station" means "in the section of track that can contain 3 trains that is off the main line and whose purpose is to deal with trains using the station"

cerulean birch
# warm sky previously when there were 3 trains at the station, the train limit was 2/3, so ...

The trains that weren't at the station yet were the ones attempting to repath.

I'd really like to see a save file of this incident. It sounds like there's a topological issue with your design that didn't allow rerouting once crossing a "critical" threshold.

I mean obviously the "real" fix is to just get rid of the dead train. You said the system self corrected once that was resolved, so I don't really understand what the problem was in the first place? I'd argue it's generally expected that your system is going to seize up if you leave dead trains in random spots.

warm sky
#

It's expected that the 1 mine stops working, not the whole network

cerulean birch
#

I don't see how that logically follows

#

Fuckups with trains have cascading effects across the rail network.

warm sky
#

You would assume that trains should not path into a section of track with a stopped train. You would assume that trains should not path to a mine whose train limit is 3 and which has 3 trains in it.

cerulean birch
#

I'd asume that the train attempting to leave the station was able to do so.

#

That's the core issue here

#

It couldn't.

dusty depot
#

The point is not that you can't come up with alternative solutions. The point point here is that there is a demonstrable functionality regression if this system becomes disabled.

cerulean birch
#

I'd personally call this whole thing solved with a simple "train not leaving due to destination full doesn't free up a train slot" personally.

That seems really trivial and I can't think of a case that that doesn't fix, short of esoteric issues like what we're currently talking about, and those are all solved by fixing the actual issue.

warm sky
#

Point is:

Having a station with a train limit of 3 request more than 3 trains is incredibly unintuitive. You would expect a train limit of 3 to mean no more than 3 trains in this location.

#

Yes: you can fix it, but only if you specifically knew that train limit of 3 doesn't mean 3 trains it means 4 trains in some cases

cerulean birch
#

I don't agree with that. If you have trains trying to repath and getting stuck in dumb locations, they can pile up in bizarre emergent ways.

That's just pathfinding. Make sure they don't get stuck and you don't have a problem. Trains should not leave a station unless they can reasonably be sure that they're going to completely clear it.

warm sky
#

For example, easiest fix is to have the train limit be 2, despite having space for 3 trains.

cerulean birch
#

_ _
I do agree that the destination full (which is sort of a subset of the issue you're talking about) can lead to bizarre behavior

#

and that should be addressed

#

but in your specific case the problem was that the train attempting to leave could not clear

#

Fix that

#

If that isn't fixed, yeah, your network is going to do Weird Shit™.

#

The fact that the network self corrected once the problem you had was resolved indicates, to me at least, that everything was more or less functioning as it should. The sole caveate I can think of is the destination full behavior.

warm sky
#

Trains should not leave a station unless they can reasonably be sure that they're going to completely clear it.

Sorry but exactly what did you mean by this?

cerulean birch
#

A train should not begin to move from a station unless it can reasonably guarantee that it won't leave it's ass-end hanging in the station and blocking it

warm sky
#

My trains didn't move

#

You seem to have misunderstood the problem

coarse pecan
#

We understand the problem

cerulean birch
#

If the destination full thing is adjusted, that solve that type of problem.

warm sky
#

They didn't move. They were still AT the station. Yet they didn't count as being part of the train limit

coarse pecan
#

We simply think it’s a self-imposed problem that doesn’t need a guardrail against because taking two seconds to look at the map is all you need to fix it

cerulean birch
warm sky
#

Expected behaviour is that a station with a train limit of 3 that already has 3 trains at it should not request any additional trains.

The actual output not matching expected behaviour is a problem.

warm sky
# cerulean birch The trains that weren't at the station yet were the ones attempting to repath. ...

Also 1 more thing:

that didn't allow rerouting once crossing a "critical" threshold.

One more key point you seem to have missed is that trains COULD reroute, and it was in fact this mechanic that meant that all trains in the network ended up at that 1 mine. Because the trains that arrived kept rerouting away from it, allowing more trains to come. If rerouting wasn't a mechanic, then there would have only been 4 trains stuck waiting at the mine, not my entire network.

cerulean birch
#

Now you're just arguing about semantic phrasings.

warm sky
#

I'm not, wtf did you mean by rerouting if not the mechanic whereby a train reroutes to a different station than the one they were going to?

cerulean birch
#

Bro... the trains got stuck because they didn't have usable paths past the obstruction because you left a dead train on the tracks.

glossy hound
#

that's what we've been trying to emphasize the whole time

#

don't do the stupid thing, and you won't get the stupid result

cerulean birch
#

I do agree that some form of this system could be useful.

#

The current implementation proposed in the FFF seems really aggressive though.

glossy hound
#

and sure, mistakes happen, but when the problem clears itself away when removing the original manual train, I don't think it's worth presenting this as a case for the new feature as it is proposed right now

warm sky
#

Expected stupid result: the mine gets disabled; no trains use this route anymore.

Unexpected extremely stupid result which is bad game mechanics: the entire network gets disabled

cerulean birch
#

Unexpected behavior: Player blocks train tracks with a disabled train. Expected result. Bad stuff happens.

glossy hound
#

the mine isn't "disabled", you're just putting a blockade in the way

#

on the output

#

you had a very specific network design with a very specific scenario happen that caused a very specific problem

#

that is not a good case for the feature

warm sky
#

The network design isn't that specific.

glossy hound
#

at this point, I don't care

#

I would rather discuss the mechanic itself instead of your stupid example, no offense

warm sky
#

Train limit of x with space for x trains in a section which is off the main line. That's pretty common I think.

cerulean birch
#

Regardless.

I think a muuuuuuuuuch better way of implementing this is "Trains count towards the train limit until they cross the first signal after the intersection." That means that a train can shuffle forward a bit and still count towards the train limit, but if it gets stuck waiting at a chain signal (IE can't clear the station) it still count's.

that solves both the destination full behavior and this kind of thing, and it doesn't result in a meaningfull regresision because you can place a single rail signal right after the station to count as "clearing" immediately.

glossy hound
#

leaving a train in manual mode blocking an exit is not common

#

don't do that

cerulean birch
#

Btw, by crossing I mean, as soon as the tip of the train pokes past the signal.

#

I still think it should be optional, but that means very minimal feature regression in the vast vast majority of cases, and is actually preferable in many

glossy hound
#

if it was a checkbox on the station I think I would be fine with it

#

in the generic case, all it does is delay trains

#

in the case where it's useful, you either have too many trains or your station entrances/exits are badly designed

broken thunder
#

Honestly, I don't understand what problem this feature is intended to solve. All it seems to do is shift when a slot opens up from the current block to the one after it. A proper rail topology makes this a non-issue.

warm sky
#

It helps if the train doesn't actually enter the next block.

glossy hound
#

1.1 already does that

coarse pecan
glossy hound
#

destination full trains count towards the train limit still

cerulean birch
#

I'd like a checkbox to disable it, but I think "train pokes past the next signal after the station" is a better implementation in most general use cases where this could come up.

glossy hound
#

isn't that functionally the exact same as it is now

#

as soon as a train begins to move, it is no longer destination full-ing

#

which opens a slot

#

honestly this whole feature feels like it should be done with the circuit network because of how different station designs actually can be

#

you can do this in vanilla right now

warm sky
#

You can also do it as before in vanilla after the change with circuits. Just increase the train limit by 1 when a train is leaving

coarse pecan
#

My point way earlier is that the opposite should actually happen with dynamic limits

#

The inventory being added to the station should automatically drop the limit by 1 in the first place, so the train leaving shouldn’t be causing a gap in the limits

ocean adderBOT
glossy hound
#

there you go, the feature in vanilla

coarse pecan
#

Longbois

#

Having flashbacks to my speed control circuit that would force repaths without stopping the train so you can have almost perfect division at speed between two separate stations

warm sky
#

It looks like you guys are competent enough with circuits that you'll be able to get your things working even with the changes.

glossy hound
#

that is a bullshit argument

#

this circuit is so simple that if you actually have a problem with this feature, which is extremely unlikely, then it is doable now

warm sky
#

The issue was I wasn't even AWARE that a station with a train limit of 3 could request more than 3 trains.

glossy hound
#

it doesn't request more than 3 trains

warm sky
#

1st train gets requested and then tries to leave but fails (doesn't count towards train limit). 2nd train, 3rd train and 4th train counting towards the train limit. Total of 4 trains.

#

I was not aware this could occur, which is why I didn't even think to set up circuitry to fix the issue

glossy hound
#

you weren't aware that leaving a manual train unattended on your rail network would cause a backup

warm sky
#

I was aware it could break that 1 section it was in; not the whole thing

cerulean birch
#

Like.. I'm not trying to be flipplant with you here, but that is the core issue. You had a minor fuckup somewhere, and it cascaded outwards

glossy hound
#

nobody is arguing that the new feature wouldn't solve your problem
we're saying that the new feature is not necessary because the solution to the problem is so extremely simple that it does not need a new feature

cerulean birch
#

You fixed the fuckup, the problems resolved.

#

Seems to be working as intended to me?

warm sky
#

THe new feature just makes train limits more intuitive.

#

You set a train limit to 3. You can't have more than 3 trains.

cerulean birch
#

Again. You never had more than 3 trains. You had trains being unassigned and unable to leave because of a different problem.

glossy hound
#

I don't think you even understand your problem in the first place

warm sky
#

There were 4 trains assigned to 1 station. 1 of them at the station-building itself, 3 of them in the train limit of the station.

glossy hound
#

you never have more than 3 trains going to the same station at once

warm sky
#

I had 1 train AT the station building itself, and 3 assigned to its train limit

#

total of 4

glossy hound
#

it "requests" a third train, which repathed, and it is no longer related to that station in any way whatsoever, and now there are still 2 trains going to the station, so it requested a third train

#

and so on

#

never goes above 3

warm sky
#

which is bullshit, and therefore the devs are fixing it and making it not bullshit?

#

it is bullshit that a train that is sitting at the very train station building doesn't count

cerulean birch
#

Again, you had trains pathing away because of another problem.

glossy hound
#

you know what's bullshit? leaving a manual train out on your network unattended

cerulean birch
#

IDK why you refuse to consider the actual root cause of the problem as... the actual root cause of the problem. You fixed that and it fixed the problem..... sooooo????

raven shoal
#

blinks

#

what have I come back to

warm sky
#

I like the change and think it makes train limits more intuitive to use

glossy hound
#

random_strategy insists that the new feature would make a problem slightly less frustrating, but the aforementioned problem is leaving a manual train on the main line and causing a backup

raven shoal
#

uh...

glossy hound
#

simply do not do that thing and you will not have a problem in the first place

raven shoal
#

don't do that?

glossy hound
#

the new feature may have helped make less trains back up, but at the expense of making literally every other scenario worse

#

it is not worth it

warm sky
#

It helps in any situation where a train is unable to leave a station for whatever reason

glossy hound
#

and trains repathing away from it also get stuck

#

which is a very niche problem that can only happen when someone makes a dumb mistake

warm sky
#

Or apparently very common on one of the new planets

raven shoal
#

if you have a manual train somewhere, you made it manual. at this point, the game recognizes that you know better than the game what you want to do, and will let you do your thing

#

it's not the job of the game to work around what you want, if you tell it "don't touch this"

warm sky
#

Look: I designed based on the assumption that setting a train limit of x would mean that there would be no more than x trains at a given location.

This design philosophy turned out to be false, which then caused problems.

raven shoal
#

wait

#

hold on

#

do you just turn a train to manual to "disable" the station?

#

because... that's not how you disable a station

glossy hound
#

the design philosophy is true, you just don't know what it means when a train is "going to" a station

cerulean birch
#

No, they disabled a train after the exit from a loading station and it caused cascading issues outwards.

glossy hound
#

as soon as a train repaths away from a station, it is no longer associated with said station

#

it might be physically near it, but it's not counted for any of the internal systems

warm sky
#

No, the train was disabled because I wanted mroe trains in my network so I built about 30 trains at some far away corner of my base where they wouldn't get in the way (except of that 1 mine, but who cares), but I forgot to set 1 train to automatic

cerulean birch
#

You don't have a desginated building yard?

#

Near home base so it's convenient for bots?

glossy hound
#

in other words: you made a mistake, something bad happened, and it was fixed by removing the root of the problem

dusty depot
#

The point is that isnt the only instance of the problem, the devs also experienced this problem and it became "more important" with expansion features

glossy hound
#

and as I have pointed out, it can very easily be done with circuitry instead of forcing the "solution" onto every instance of a train station

warm sky
#

The devs literally asked "I would be interested to know if other people encountered this problem in 1.1 as well."

and the answer is yes: I have

glossy hound
#

alright so we're one for how many million people

cerulean birch
#

I mean... I've literally never encountered this problem before short of doing stupid things like leaving trains disabled, or having a chunk of track out of robo range resulting in nopath

warm sky
dusty depot
#

You also havent played the expansion

glossy hound
#

because of the very specific spot you left the train in, this happened

cerulean birch
#

I would genuinely like to know what the devs are trying to address with this because "I left a train blocking my mine and now it broke" just doesn't seem like an issue to me?

warm sky
#

The issue is "My train can't leave the station"

#

We don't know why the devs' trains can't leave the stations exactly, but it is apparently an issue that comes up

#

In my case, the train couldn't leave the station because of a stopped train.

glossy hound
#

no, the issue is "my train can't leave the station AND it's not because of destination full AND I'm using a static limit AND any trains that path to this station that end up repathing also get stuck"

dusty depot
glossy hound
#

???

#

j5, their problem is something completely different that happens to have it's effects slightly minimized from the new feature, not an actual thing that can happen with trains running automatic

warm sky
#

Maybe the devs have a massive 500 wagon long train passing by which means the train at the station can't leave for 3 minutes, which is enough time for another train to arrive behind, which blocks more trains and creates a complete deadlock for 5 minutes at a time.

raven shoal
#

who in their right mind would have a train with more than ~10 wagons

#

genuinely

glossy hound
#

people have done fairly large trains before

warm sky
#

Maybe the devs have problems with stations getting destroyed, which causes trains to have to repath a lot, and therefore lots of random stopped trains everywhere, and the station limit not being accurate caused more trains to join the deadlock.

glossy hound
#

long distance ore trains, megabase direct insertion stuff

raven shoal
#

eh, I suppose

glossy hound
#

plenty of valid reasons to have trains that are 20, 30, 40 wagons long

#

maybe there's some valid reason for this new feature to exist, but until they actually show us real examples of it, I'm going to protest it

warm sky
#

The issue happens when a train is blocked from leaving for enough time that another train shows up behind waiting to get into the station even though there isn't enough space in the station.

glossy hound
#

your situation is not a real example. I'm sorry, leaving a manual train in a very specific spot is not a valid argument for this

#

I am personally not interested in discussing your scenario any further, it is simply a "do not do that"

raven shoal
#

no, @glossy hound, it's not "a valid argument". it's valid, but it's an incentive against it

#

if a train is set to manual somewhere, I WANT to know

#

if it needs to deadlock for me to find out, then good

glossy hound
#

lol, devil's advocate you might not notice the manual train unless there's a huge backup

raven shoal
#

if everything still works but suddenly I don't have coal?

#

yes

#

I'm going full pro-pileup

glossy hound
#

lmao

cerulean birch
#

That's the thing. It didn't even properly deadlock according to the guy complaining about this in the first place. As soon as they fixed the manual mode train, everything pathed corretly.

coarse pecan
#

I would love to see what scenario the devs had that made this change helpful

#

And I do think there are probably cases where it is helpful

#

I disagree on the precise implementation

#

The problem was solved in a way that invalidated other valid ways to do trains, when a simple alternative that works both ways is possible.

#

The simple alternative being to use the front of the train, not it’s entirety

glossy hound
#

I think it's a bit arbitrary, the current block vs the block after vs what about two blocks after

raven shoal
#

also showed what I think is a lower understanding of how trains work to begin with

glossy hound
#

the currently proposed implementation does not give you granularity

warm sky
#

If you really feel strongly about it, just set up some circuitry to mimic the old behaviour?

raven shoal
#

if you really feel strongly about it, just set up some circuitry right now to mimic the future behaviour?

glossy hound
#

it's the exact same circuitry as before, just worse

cerulean birch
warm sky
#

If you are not at the point where you would do circuitry to force specific behaviour, then the devs implementation is better because more intuitive - the train limit being x means that there will be no more than x trains at your station.

cerulean birch
# warm sky If you really feel strongly about it, just set up some circuitry to mimic the ol...

Old behavior can be important when megabasing to sustain throughput while minimizing repaths due to trains waiting around. You want minimal inserter counts on each wagon, and that means minimizing the changeover time as much as possible.

Circuiting things together introduces more laggy components. Yeah, a few hundred combinators in your base is pretty minor in the grand scheme of thing, but it's still a regression.

glossy hound
glossy hound
#

this is the third time I've had to tell you that as soon as a train repaths, it's no longer counted towards the train limit

warm sky
#

I KNOW

#

It's still at the station

glossy hound
#

then why do you keep saying that there are more trains at the station

warm sky
#

Number of trains at the station:

1 train is leaving or trying to leave
1 train is 1st in the train limit
1 train is 2nd in the train llimit
1 train is 3rd in the train limit

4 train AT the station. Train limit of 3.

#

And the fact that the train limit does not match the upper limit of the number of trains AT the station IS counterintuitive.

#

Problems occur when train number 4 arrives at the station before train number 1 has left.

glossy hound
#

the train leaving or trying to leave isn't at the station

#

it's not part of the limit

dusty depot
#

it is now

warm sky
neon loom
#

Here is the logic behind what I built. I have reverted it back to how I initially built it, before actually running into the issue. I also deliberately set this up, as I'm not going to wait potentially hours for it to happen again on it's own.

Each depot has a limit of 1, it follows intuitively that the station should not ever have more than 1 train in it.
Train A left the depot, and train C, seeing the limit open, rerouted to go to that depot. it happens that train B was trailing right behind it, and both were close enough and moving fast enough to reserve the block that train A needs to go through in order to clear room for Train C.

The key here is intuition, I expected it to be true that setting the stop limit to 1 would mean that there would only ever be 1 train in that loop. Which in practice isn't the case.
Expecting every player to know every possible outcome in every situation is quite silly, and not seeing this issue is really easy to do without more knowledge on how train limits work. Having this minor tweak to the limit behaviour makes the system more robust and intuitive, at the cost of some edge-case setups efficiency.

I still believe it should be default behaviour, but I also think a toggle 'immediately clear limit' or something similar on each station wouldn't go amiss to keep these edge-case uses.

image.png
coarse pecan
#

this is just loop saturation

#

with a slight twist

neon loom
#

The loop wouldn't saturate with the change

#

I didn't intuit that it could saturate, as the limit on the station was set to 1

#

I feel like you just looked at the picture and didn't read what I said

coarse pecan
#

I read what you said, then looked at the picture and thought "well that's a rail design issue that could happen in tons of different ways besides this one specific one that happens to involve train limit 1"

#

This is what happens when you cross input and output rails and allow trains to park on that crossing

#

The same thing could happen even without C trying to path to A

neon loom
#

Saying "well that's just a rail design issue" doesn't fix the problem. with the information I intuited, this situation couldn't occur.
I misunderstood how it worked and it caused the issue

#

The problem is if I set a limit on how many trains should be going to a stop, I should be able to know that there won't ever be more trains at/before the station than the limit

coarse pecan
#

I think we keep prescribing expected behaviors to train limits that I don't know were ever advertized

neon loom
#

Now that I've made this mistake, I won't make it again, but if the first time I ran into this issue was it deadlocking my first SA run when I haven't played that much of the game, it would suck

#

It's not about prescription, it's about how individuals understand it.
If the system says something, and people interpret that it means one thing, and others interpret that it means something else, that doesn't make either group incorrect by nature of those assumptions

coarse pecan
#

I don't think incorrectly assuming something makes you right. That's opening a massive can of worms

#

That's how wars start

neon loom
#

It doesn't, I'm saying just because you make an assumption doesn't mean that assumption is wrong

#

You could assume that it works as it does in 1.1 and you'd be right now and wrong in a year

coarse pecan
#

The correct assumption for everything regarding trains before train limits were introduced was that if the train isn't physically at the train stop, it was not associated to that specific train stop until it arrived there. Now with limits and reservations, trains are sort of associated with a train stop before they arrive there, and definitely when they are parked and waiting at the stop, same as before limits. Having trains also be associated with a stop after they've cleared their wait condition is an entirely new thing that breaks the previously correct knowledge about how trains work, regardless of stops.

#

assuming that "just being in the same block as the station means you're associated with that station still" does not reflect any previous train behavior

neon loom
#

Trains didn't have associations with stops before arriving, now they do. Trains don't have associations with stops once they've cleared their wait conditions, soon they will.
I don't see the issue with train mechanics changing to be more stable and intuitive

vivid stream
#

and the new reservation change does not change the fact that a train could get stuck en route

#

if you had short trains you could easily have a block after the station and before the merge into the mainline, long enough to fit a departing train that could get stuck in the same way, making that train no longer count toward the stop limit, even with the new change

#

so the change only fixes a very narrow set of cases, and that doesn't seem worth it

vivid stream
#

trains stop at signals all the time while en route

neon loom
#

It's equally arbitrary that trains stop counting towards the train limits as soon as they clear their wait conditions

#

It makes more sense that it counts while it is still occupying space in the station

vivid stream
#

hm, ok that kinda makes sense to me too

#

but this reduces the throughput :/

#

I think it's a minor point, but the workaround in 1.1 to achieve the new behavior is simpler than the workaround to negate that change would be in 2.0

warm sky
# vivid stream IIUC the first train being stuck at the station was totally incidental due to a ...

If there was a block after the station before the merge onto the mainline, then yes a train could get stuck there. However, this isn't a problem because this train is not blocking the main line. The train that can block the main line is train number 4 arriving at a station that can only fit 3 trains before train number 1 has managed to leave. This is the train that is getting removed with the change.

#

As previously discussed, the set of all cases where this problem occurs are exactly those where train number x+1 arrives at the station before train number 1 has managed to leave, ending with a situation with x+1 trains at a station that is only designed to handle x trains. There being more trains at a station than it is designe to handle means trains waiting on the main line blocking it, which then has negative impacts on your train network.

vivid stream
#

it's rare though that the first train still wouldn't have left the station by the time the x+1th train arrives

#

and if chain signals are used, the blockage should easily resolve itself

neon loom
#

I'm keen on a toggle on the station, 'remove from limit on routing' or something. But the default should be the option that reduces the risk of deadlocks, not the one with higher throughput imo

chrome juniper
#

Unable to re-read this full thread, and it seems to be a few points presented in a myriad of ways. First, the new version would not have made a single difference in the mine being disabled and all the trains getting stuck there. The instant an train is switched to automatic every feature of the automatic system is disconnected. In this case, under the new system, the train switched to manual would have cleared its reservation and the pileup would have commenced anyway. Manual trains don't have "reservations", and have no interaction with the train stop, including the ability to receive circuit signals or for the station to read contents or anything else. The mess created could have been avoided in any number of ways, but the reservation change in 2.0 is not one of them.

#

I'm unable to test it at this time, but I think a train which is ready to leave yet has a Destination Full status is still "at" the station and is still counted in the limit for that station. If correct, the reservation change in 2.0 will not make a difference there either. I'm rather fuzzy on precisely what the current situation is and how it will change in 2.0. Perhaps in messages I've skipped, or in other places, it has been clarified as to what is the "trigger" for releasing the reservation, then and now. Absent that, I am thinking that in 2.0 the reservation is released when the final car of the train has left the block with the station in it. That, however, is a radical change from everything else I understand about trains and how they deal with blocks.

#

Using signals, as an example, if a rail signal is green, the train will enter the block, and potentiall stop at the next signal. There is nothing I know of in the train logic where the train will not enter that block unless the last car will also clear the signal. My understanding of train behavior is that they look at signals as lines to cross or not based on the nose of the lean loco, and nothing else matters.

#

My confusion from the FFF description would be missing if the text had indicated that the train stop released the reservation, or opened the slot in the limits, once the train cleared the block. The stop can see the block and could implement logic based on block status. The train, however, doesn't currently even "know" about the block behind the engine, let alone at the end of the train, however far that might be.

#

The rest of the folks here have much more time designing, and using, rail systems than I do. I suspect that the devs are as far beyond most as most are beyond me. That leaves me in a pickle. I cannot see how the problem being "solved" can exist with a good design, or at worst, how a design change wouldn't fix it without the need to change the game's logic. That of course, would imply that the devs cannot do a good train design, and that doesn't sit well with me either. Therefore, I have to presume I don't fully understand the problem and the solution.

warm sky
chrome juniper
#

How? The stopped train was not in the limit then and will not be in the limit in 2.0.

warm sky
#

That's literally what the change is? A train that is trying to leave but has not cleared the block containing the station will count towards that station's train limit

chrome juniper
#

The train in manual mode doesn't exists as far as the network is concerned.

warm sky
#

the train leaving was in automatic.

chrome juniper
#

Oh. The manual train was blocking the exiting train?

warm sky
chrome juniper
#

That, then, gets into my fuzzy on how it's implemented. As it stands now the train has no awareness of its tail, and don't know or care if it has exited a block. The train stop does know if the block is clear or not.

glossy hound
#

how are you still on this

chrome juniper
#

Making the loco aware of the last wagon, and which block that is, so that it can release its reservation once that wagon is clear, is a significant change to the internals as I understand them.

#

I'm on this to attempt to understand the problem the devs had, and what the solution implementation looks like.

glossy hound
#

I would also like to see what prime the devs had

#

random_steategy's problem is self inflicted and not a good example

#

the more you talk about it, the more it detracts from the original point of the thread

chrome juniper
#

In my mind the solution would make sense if the statement had been that the station released the reservation. The "train", however, makes it all muddy in my attempt to understand the solution.

warm sky
#

OK you probably don't want to read through everything but the TLDR is:

Previously, if the train limit was x, you could have a situation where you had 1 train leaving the station, and x trains in the station's train limit arriving at the station. So in the rare situation where train number x+1 arrived at the station before train number 1 had left the station, the station would have x+1 trains, despite being designed for x trains (as its train limit implies). And then having x+1 trains at a station that is only designed to handle x trains meant there was a train blocking the main line trying to enter the station, which can cause problems.

We do not know what the devs were doing to have train number x+1 arrive at the station before train number 1 had left the station, but it was apparently common enough.

chrome juniper
#

I think that the manual train issue would have caused the same issue, even if the solution in 2.0 would have prevented the original issue.

#

The blockage at the green "x" would have caused just as many issues. And the logic of changing destinations while at a chain signal would have still caused a pileup, just delayed onset by 30 seconds.

glossy hound
#

for clarification, the station still doesn't have x+1 trains actually going to it that count towards the limit, the one leaving just got stuck and wasn't able to leave the track surrounding the station

#

it's not associated with the station anymore, it might as well be a manual train

chrome juniper
#

My vision of the implementation in 2.0 is that the "train" clearing the block is the lead loco, not the full 100 cars.

warm sky
#

Can we stop with the useless semantics? A train that is occupying the station's block (and is therefore preventing other trains from entering the block) is at the station.

glossy hound
#

useless semantics can cause long arguments and many misunderstandings about what you actually mean

chrome juniper
#

Taking the text " the train will only give up its reservation once it leaves the block with the train stop" to refer to the loco making and clearing reservations, I think that it addresses the case where a train, not on dest full, has selected, and is ready to launch toward, its destination, but the block ahead of the station is red. If that block is green, and the next is red, the train will move to the next signal and stop. I believe that at that point it will have, in 2.0, released its reservation, even if the remaining 50 cars are in the stop's block.

glossy hound
#

there's a demo in the pins of doing this in vanilla, chin

warm sky
#

I assume it's when the rail block is free. What if the train has several locomotives? What if the loco is at the back?

chrome juniper
#

I don't give a hoot about semantics, only game mechanics. So far in everything with 1.1 the only part of a train that counts in the automation of the network is the lead loco. Signals care about the wagons, but only the signals.

glossy hound
#

just nobody makes trains with wagons in front so that was an assumption

chrome juniper
#

I don't even think it's the first rolling stock. A train with a single loco in the center will stop with the loco at the train stop, not the lead wagon.

glossy hound
#

no it won't

chrome juniper
#

So, for signals and stops, the leading edge of the train, no matter what kind of stock, is the "factor"?

glossy hound
#

yes

dusty depot
#

blocks arent empty until the trailing edge of the train leaves them, so signals care about the trailing edge

glossy hound
#

I assume they meant stopping at things

#

signals also care about the front of the train because they turn red as soon as they pass in front of it

#

in fact, I think it's safe to say signals care about the whole train

chrome juniper
#

Signals care about every wheel. The train only cares about, near as I can tell, the leading edge.

dusty depot
#

I'm really confused what you mean by "the train" caring about things

cerulean birch
chrome juniper
#

Place 2 chain signals close followed by 2 rail signals close. Add a cargo wagon after the 4th to make it red. Place a station past the cargo wagon. Add a 1-3 train before the first chain. Both chains will be green and the first rail will be green, the 2nd rail will be red. Send the train to the stop. It will enter the block guarded by the first rail while blocking both chain-guarded blocks. The chain rule of don't enter unless you can exit isn't followed by the train for all wagons, only the leading edge.

cerulean birch
#

You're allowing trains to enter into a series of segments without guaranteeing that they can clear those areas.

#

Replace some rails with chains and this could not occur

chrome juniper
cerulean birch
chrome juniper
#

How then, under 2.0, are we to think that the train, unaware of it's lenght until now, knows when its final car has cleared the station block.

glossy hound
#

by "train" logic do you just mean like when it decides to go

#

that's not really dependent on a specific location, that's just how trains work

#

I guess it checks the signal in front of the train, but that's because the front of the train happened to (potentially) stop there

chrome juniper
#

When it decides to go, when to stop, and where to go. Nothing so far has indicated any "awareness" of the full train's wagons in the automation system. (Signals are a different technology and not part of the automation.)

warm sky
vivid stream
#

look at it from the train stops point of view

#

since we are talking about train limits which are a train stop feature

chrome juniper
#

And, under the 1) and 2) above, if the FFF had said the station cleared the reservation I would have no questions. They said the "train" releases the reservation.

glossy hound
#

train stop most likely gets it's information from the connected rail, which also has ways to get how many trains are in it's current block

vivid stream
#

the train stop can easily look at the block it's in

#

it doesn't matter if the train releases the reservation or the train stop does, the whole train limit thing is magic anyway (implementation is not magic of course)

chrome juniper
#

My whole problem with understanding the operations, and implementation, are based on the choice of words in the FFF. I don't think they give information with intentional misdirection.

#

The "train" gives up "its" reservation. Not the stop clears the slot or limit or whatever.

#

I'm thinking, in an anthropomorphic sense, that the implementation is that the train is ready to leave, has selected a destination and route and then "decides" to leave. In 1.1 that is when it releases the reservation, even if the next signal is red. In 2.0 it keeps that reservation until the next signal is green and it can actually leave the station. I don't think that in 2.0 it will hold the reservation until the last car has completely cleared the station's block.

warm sky
#

I always imagined it was the train stop itself that held the reservations. That is how it can do stuff like check if the total number of reservations is less than the train limit.

vivid stream
#

in my mind the train gives up the reservation, but the train stop doesn't have to decrement the train count until it sees the block cleared

#

in other words train count ≠ reservations

chrome juniper
#

That could be the implementation

warm sky
#

There's probably like, 2 way pointers. The train stop has a list of pointers to some trains. And the train has a pointer to the train stop.

chrome juniper
#

The FFF, on its own, lacks the clarity for me to decide how it will work. In practice or implementation.

warm sky
#

Realistically you would need both connections to deal with the situation where 1) the train stop gets deleted 2) the train gets deleted

chrome juniper
#

The pointers is code-level implementation, and I'm only going as deep as the engine-level abstraction. Not that it's invalid, just unhelpful for knowing how it "works" at the game-play level.

vivid stream
#

so far no dev has clarified it, but I assume they meant the whole train has to leave the block the train stop is in, or maybe it just has to clear the train stop itself with its behind

chrome juniper
#

I'm looking at it as the train gives up its reservation once it crosses the next signal, which could be just past the stop, or on the mainline after the merge. The stop could, indeed, still keep its count of the train until the last wagon has cleared the next signal.

warm sky
#

Once you have the 2-way connection it doesn't matter? You can implement a function for the train that simply asks the station "am I in your block?"

chrome juniper
#

Again, I'm taking that 2-way connection as being broken the instant the train takes motion.

#

The stop can still see if there are any wheels on the track in its block, without any communication with the train.

vivid stream
#

it would be weird if the nearest signal was 1000 tiles away and only once that was cleared would the train stop free up, or not?

chrome juniper
#

If my interpretation is close to correct, operationally, then I can envision a design where the problem to be solved could exist. Especially in terminal stations, which seem to be popular with WUBE.

glossy hound
#

I would like to emphasize that the problem can also very easily be solved with circuitry

chrome juniper
#

It can also be 100% avoided by having safe exit blocks.

cerulean birch
chrome juniper
#

Safe exit blocks are, however, decidedly non-compact.

warm sky
#

Don't you still need circuits then? To check if your "safe exit block" contains a train or not?

cerulean birch
#

Don't agree. It's just using chains appropriately

#

Don't overlap input/output.

#

Or use chains to push the inputs far enough away that they cannot possibly block outputs.

#

Also, this change doesn't even prevent issues. If you have a large exit block that can fit a train, you can still wind up with a similar situation. It just moves the problem around. Probabaly (almost certainly) makes it rarer, but it doesn't actually resolve all of the potential deadlock cases.

#

That requires correct signalling.. and correctly signaled tracks don't need this feature.

chrome juniper
#

Relative to the thread's mission, I think my understanding of the operations, removes the need for a toggle setting.

cerulean birch
#

_ _
There are absolutely use cases I can see where this feature is convenient when trying to squish things down or avoid a lot of extra circuit controlled sanity checks, but it really really should be optional.

#

I also think that it should be "train counts for train limit until it enters the next rail block after the station"

#

That is a much more reasonable default value.

#

If the train is entering the block after the station and not able to completely clear the train station... sorry.. that's on you. Buil a better system.

vivid stream
#

nah I think the question 'is the train still blocking other trains from reaching the stop' makes the most sense

#

what has meaningfully changed when a train crosses the first signal? nothing really

#

it should be either tail end clearing the first signal or tail end clearing the stop

chrome juniper
#

My understanding of 1.1 operations is that as soon as the top train pulls out, even if it stops are the rail signal, it has released its reservation. In 2.0 it won't release the reservation until that signal is green.

image.png
cerulean birch
warm sky
#

(assuming correct signalling)

chrome juniper
#

Incorrect signaling is not a solution for game mechanics to solve.

vivid stream
#

you don't need the train to pass a signal for that tho, it already has a valid path when it departs the stop

cerulean birch
cerulean birch
#

rather than waiting at the signal

#

IE for traffic to clear

vivid stream
#

ok but then it might stop at another signal after that with its tail still blocking the stop

cerulean birch
#

If it's waiting at the signal you don't necessarily know if it can move out. If it's passed the first signal you can reasonably assume that it's going to be able to clear the block.

cerulean birch
vivid stream
#

not necessarily

chrome juniper
#

In my image, the train will advance to the signal, and does not have a path if it's red. It is still in the stop's block. If it can pass that signal it is, as far as the system is concerned, leaving the station.

cerulean birch
# vivid stream not necessarily

If you have a system that allows trains to enter blocks without being able to clear them, you are asking for a deadlock at some point.

chrome juniper
vivid stream
#

you normally have chain signals before crossings. if you only have merges, you normally don't need chain signals (unless it's a stacker)

warm sky
#

Case 1) Reservation clears as soon as train decides to leave -> can cause problems even with correct signalling (since the train doesn't need to pass by any signals for this to happen)

Case 2) Reservation clears as soon as train passes first signal -> only causes problems if signalling is incorrect (if a train passes a signal it should be able to leave the station)

Case 3) Reservation clears as soon as train leaves station block -> causes no problems

cerulean birch
#

case 3 reduces throughput

#

because it delays replacement trains

#

well.. "can" reduce throughput

vivid stream
#

if a train passes a signal it should be able to leave the station
you are assuming a station next to a mainline

#

but train stations can be far out from a mainline

cerulean birch
vivid stream
#

thus no crossings for a while

#

again, you don't need chain signals for merges. i know most players do it because of the "chain in rail out" rule but it's normally superfluous

cerulean birch
#

If it cannot totally clear out of the station, it should not enter that block. That should be the default design choice.

If you want to cut corners to boost throughput, are fully aware of the constraints imposed by violating some of those rules, and have safety measures put in place elsewhere, then fine, but the simple and safe way is to simply guarantee that a train cannot enter a block unless it can completely clear the preceding one.

chrome juniper
#

I think that the change is to enhance that rule.

cerulean birch
#

I take advantage of not needing chains, but I'm doing so by accounting for backups elsewhere.

cerulean birch
dusty depot
#

How hard would it be to build a circuit to increment train count when the train is leaving?

cerulean birch
chrome juniper
#

The system for the image above is designed so that a train pulling out, and not in the limit count, yet stopped at the rail signal does not cause a backup issue. The change in 2.0 would allow me to have a different feed to the stations, slightly.

coarse pecan
#

Again, my prior point is that the train count should already decrease when you’re adding the inventory to the station if you’re using a dynamic limit, so the problem as stated in that context doesn’t even make sense

warm sky
#

Apparently pretty easy according to codegreen (who made one that did the opposite, and called it simple)

vivid stream
#

for example if you have a bunch of parallel stations (top) and merging together toward the bottom, you need zero chain signals

tree.png
dusty depot
coarse pecan
vivid stream
#

so a train might clear the first signal, but then come to a stop on a second signal without having cleared the stop

coarse pecan
#

This whole situation is a bit of a Hyrum’s Law

vivid stream
#

in this case the reservation would be given up, but the train is still blocking the stop. therefore, the condition of passing the first signal with the front of the train would not be a guarantee

chrome juniper
#

The clear one and not the second implies that the first should be a chain not rail.

cerulean birch
vivid stream
#

but in this case you don't need this feature anyway

cerulean birch
chrome juniper
#

It a train can stop "here" and block "there", then "here" is not a valid rail signal position.

vivid stream
#

I'm saying in those cases where the feature makes a difference, simply passing the first signal is not a guarantee, but clearing the first signal (or the stop) with the tail end would be

chrome juniper
#

It is a guarantee if the signaling is correct.

cerulean birch
chrome juniper
#

Clear exit blocks are not just for junctions.

cerulean birch
#

Also, the thing I'm proposing doesn't have significant feature regressions if it's made mandatory/default.

#

while still giving you most of the benefits of the "train must fully clear train station block"

vivid stream
#

I think I agree, but if the devs deem it to be a common enough problem where this feature would help out less skilled players, the factor should be the tail of the train, not the head

cerulean birch
#

(assuming things are decently signalled)

cerulean birch
vivid stream
#

I don't mind either way, but I think clearing the tail end makes more sense than passing at the front

chrome juniper
#

I'm thinking that if my expectations are correct, then the toggle becomes pointless. The turning off, to revert to 1.1 behavior, would not improve throughput at all.

cerulean birch
chrome juniper
#

I would expect that in cases where you're worried about the speed that much you already have a signal there now.

cerulean birch
#

generally yeah

#

I mean it depends on if you have things coming from super far away or not, but I have.... zero cases where I'm doing things that can't put a signal there

chrome juniper
#

And, the train probably crosses that signal before it clears the tiny block you add to the rear of the train as well.

vivid stream
#

if there is a toggle it should be between the 1.1 behavior and the new behavior, I don't think we need a toggle (additionally) between front of train and rear of train

warm sky
#

TBH I still find the devs solution the most intuitive. It means that a train stop is identified with the rail block that contains it.

Another way of viewing the problem could have been that the station and the rail block disagreed on whether a train was present or not (the station said "no the train is gone; send in another train", but the rail block said "the train is still here; block trains from entering"). With the new change, the station now acts exactly the same way as its rail block

chrome juniper
#

I take the solution to be using front of train. Rear of train is a signalling issue and is the player's choice, or error.

cerulean birch
chrome juniper
#

Can I make an exit block too small to guarantee the tail clears the stop? Yes. Should I? No!

vivid stream
#

what issue does it solve exactly. because we already agreed that with proper signalling there is no issue to be fixed

#

the other thing is unexpected stuff like destroyed tracks and trains that were accidentally left in manual or ran out of fuel

cerulean birch
chrome juniper
#

It solves the case in my image. The train has "left" the station but stopped at the signal. In 2.0 it would still be counted as at the station until that signal is green.

warm sky
#

In an abstract sense, the issue is when a train arrives at a station before a train has finished leaving the station.

vivid stream
#

these things could happen literally anywhere past the train stop, and so the train's ability to move past the first signal doesn't guarantee anything, whereas the train clearing the station does guarantee that all incoming trains have space at the station and the stacker/queue

cerulean birch
#

You can say the same thing about intersections without train stops

vivid stream
#

destroyed track, forgotten trains, etc is not a signalling issue

cerulean birch
#

destroyed track would result in no path and it wouldn't move at all

vivid stream
#

but you could get x+1 trains coming to the station

#

which could then cause a deadlock, especially with terminus stations

cerulean birch
#

you could do the same without stations

vivid stream
#

which then requires manual or more tedious intervention to resolve

cerulean birch
#

no, just requires the track to be rebuilt

vivid stream
#

which is the best case for this feature imho

cerulean birch
#

you can cause the exact same scenario you're describing independently of there being a train station.

#

I don't see why you need special checks for train stations unless you also want special checks for rail blocks in general.

vivid stream
cerulean birch
#

if that can happen at a train station, it can happen on generic tracks

glossy hound
cerulean birch
#

signal your stuff correctly and it won't happen.

raven shoal
#

there are many ways to solve the issue, but I think this is not one of them

vivid stream
glossy hound
#

did you read what I replied to?

#

also, it should affect a train because the train is now leaving, there's a slot available for another train

chrome juniper
#

If the change requires that the entire collection of rolling stock clear the block before the train gives up its reservation, I don't particularly like it. If the change requires that the train be able to "enter" the next block before its reservation is released, I love it.

warm sky
#

Blocks already do affect trains half-way across the map? The train needs to pathfind its way to its destination, and each block along the way does impact that?

vivid stream
#

well I give up, I don't understand the problem exactly

cerulean birch
glossy hound
#

that isn't how pathfinding works number 1, and number 2 that's a completel different thing

#

we're not talking about pathfinding

vivid stream
#

to me there just doesn't seem much meaningful difference between a train leaving a stop and it crossing a signal 2 tiles after it

#

I don't think there's any rule that says that a train being able to pass a signal means that it should be able to pass it entirely in any amount of time

cerulean birch
vivid stream
#

but why should it? I mean we can equally assume that the signal won't be forever red

warm sky
#

Currently stations use different mechanics from rail blocks. With the change they now act the same. This is better and makes everything easier to understand.

cerulean birch
#

Honestly it might make more sense for you to jump into VC @vivid stream . I think you're missing some minor detail (or ascribing too much weight to one) and it's throwing off you're reading of what is being said. Probably faster to sort it out in VC, because I'm honestly not sure how else to convey the difference here. Sorry.

vivid stream
#

why do you make a different assumption for the first vs the second signal?

#

nah, I find it easier when things are written down, but I was multitasking before, so let me go back and re-read some stuff

vivid stream
chrome juniper
#

The bottom train is different in that it has a rail signal directly after the stop and the others do not. In 1.1 all 3 trains are no longer at the station, and have been removed from the limit. In 2.0 the top train has gone past the exit signal and is not at the station, in the network's view, and is removed from the station limit. The middle train, in 2.0, is still at the station and included in the limit. The lower train is no longer at the station, it has passed the signal at the stop and is holding at the second signal. None of the trains have cleared the block physically. (If I understand the operations of the solution given in the FFF.)

image.png
#

The guarantee of clearing the station is in that I have a safe exit block. Relative to the much earlier image, not the current one.

vivid stream
#

but what if there is another merge just out of frame above in that picture

#

using a signal

#

and it's red

warm sky
vivid stream
#

and there are 10 other trains merging in front of it

#

or a dead/forgotten/fuelless train

chrome juniper
#

The lack of a clear exit block is a design choice, and in my view design error. In neither case is it the responsibility of the game to compensate for the design.

vivid stream
#

so passing that first signal is no guarantee that the stop will be free in the next 5 seconds, or 30 seconds, or ever

chrome juniper
#

The guarantee is in the design, not the circuit.

#

The lower train, in the trio, is a bad design, and an example of how not to "do it."

cerulean birch
#

TL;DR. 3 cases.

Current system:

  • Isn't actually a problem if the top level design is correct.
    ** Can lead to weird emergent behavior if systems are not designed correctly (or you leave dead trains on your grid for some reason)
  • Provides the highest potential throughput.
  • Can be circuited to provided either of the other two cases.

Devs proposal (train doesn't leave until fully clearing block):

  • Reduces throughput
  • Is convenient for spaghetti builds or situations where you want to trivially guarantee non interference with multiple trains departing at once.
  • Is obtainable with circuits without the change
  • Doesn't actually fix anything if stuff is designed correctly.
  • Doesn't actually fix all edge cases that could cause deadlocks like this to occur (because it's a signalling problem)

My proposal (train is counted as leaving as soon as it noses past the signal after the station)

  • Basically the same as devs proposal, without meaningful degradation in throughput
  • Does have some potential issues with big piles of mergers not using chains and not guaranteeing a clear exit block (hint, default to not doing that.. if you need the performance, be aware of the risks, which you still have to do in the curren system)

The benefits of the nose past the signal system is that it gives you most of the intuitive benefits of a train still being stuck in a station without the performance degredations. The drawback is that stuff can still break... but it can still break even with the devs proposal... so I don't see a practical difference.

warm sky
#

You should also mention that with circuits any behaviour is obtainable from any starting default.

chrome juniper
#

My only issue with the TL;DR is that I'm not sure if #2 or #3 id the devs solution.

cerulean birch
vivid stream
chrome juniper
#

I think #3 is the solution and #2 is an incorrect reading of the solution.

cerulean birch
#

What makes you think that?

chrome juniper
#

Valid signal placement does not mean valid signal design

#

I think that because it fits with how they have, so far, dealt with trains and signals. The train being aware of its full lenght, and releasing the reservation only after the last car has cleared some rearward block is counter to everything trains do now.

cerulean birch
# chrome juniper I think #3 is the solution and #2 is an incorrect reading of the solution.

So we fixed it, so the train will only give up its reservation once it leaves the block with the train stop. I would be interested to know if other people encountered this problem in 1.1 as well.

"leaves the block"

It's not "leaving" it's "leaves", as in, is no longer in. All other instances of phrasing like that refer to the ass-end no longer being in the block. that's how signals are defined. Why would this be different?

cerulean birch
chrome juniper
#

It's different because it is not the signals or the stop making the decisions it is the train making the decisions.

warm sky
#

"being in a rail block" is an already existing mechanic, that is in fact central to how blocks function. I don't see why they would use something else.

vivid stream
#

hypothetically, if the distance between station #3 and the merge next to the orange circle is 100 tiles, it would be good to place a signal where the orange circle is, so a train pulling out of station #3 can wait closer to the merge in case a train pulling out of station #2 is pulling out in front of it

image.png
chrome juniper
#

The train will only give up its reservation
And, the train don't know if it is, or is not, clear of all cars in its length.

vivid stream
#

but if the train in station #3 is longer than 100 tiles, it would still block station #3

chrome juniper
#

If the train is longer than that block then the signal must be a chain.

vivid stream
#

normally it wouldn't need to be a chain though

chrome juniper
#

Valid signal, invalid design

vivid stream
#

there is no other reason to use a chain signal anywhere for merges like that

chrome juniper
glossy hound
cerulean birch
#

functionality wise this change seems to be turning tran stops into intersections

chrome juniper
#

Or, after a station

cerulean birch
#

or tryinng to

glossy hound
chrome juniper
#

I will not make an exit from a station which will not guarantee that the train has cleared the station.

#

I do not want a train to stop half in half out. Go or stay, but not both.

vivid stream
#

I can see how the train passing the first signal (just the front) would be a nice compromise between the train having to clear the first signal entirely and the 1.1 behavior. I just think that this whole subject is such a niche concern anyway that it probably doesn't warrant having three different options in the GUI. If there's going to be choice, I think it makes more sense to be a choice between 1.1 throughput-first behavior and the proposed safety-first behavior, than between 1.1 and a compromise, or the proposed behavior and a compromise.

chrome juniper
#

I'm not a rail expert, but I don't think a clear exit block on a junction is always required to avoid deadlocks. Certainly strongly advised, of course. If and when not strictly required they do still improve throughput, and at a station they serve the purpose of throughput rather than deadlock prevention.

coarse pecan
#

it isn't always required

chrome juniper
#

My biggest issue is that while I have my interpretation of their implementation, I don't know with surety that how I think they did it is how they did do it.

#

If I'm correct, I like it. If I'm incorrect I not only don't like it, I'd rather it be reverted than toggled.

coarse pecan
#

Oh, maybe I misunderstood

chrome juniper
#

Revert it and provide a turtorial on how to not get into that situation is better than having it and making a toggle to pick, imho.

coarse pecan
#

You said clear exit block but I was thinking train-length exit block

glossy hound
chrome juniper
#

I have been using 'clear' when it should have been 'safe'. Yes, full length block.

glossy hound
#

it also makes throughput ever so slightly worse since all of your trains are waiting further back

#

a train waiting at a chain signal vs slightly further ahead at a rail signal won't change much

#

it's still "left" the station

chrome juniper
#

The slightly back is compensated by signals inside the length of the train parked at the stop. Their benefit is cancelled if the stop's limit isn't cleared until the train fully exits the stop's block.

coarse pecan
#

basically requires that you have trains of a specific length and design your network around that

chrome juniper
#

I think I see the problem the devs encountered, and have had it as well. My issue happened because of other failures in the network, which I knew were going to happen when I started doing them, so I didn't consider it a network failure. Still, I can see how a design could have that problem. I think their solution, as given, refers to a train being able to enter the next block after the stop's block. Whether or not that will also mean the full length of the train also clears the stop's block is a user controlled situation, not a forced one.

#

If a stop's exit block is not a safe exit block, I think the behavior of 1.1 and 2.0 will be indistinguishable. The train will still clear its reservation and the next train will still be unable to enter the stop's block.

glossy hound
#

how would the exit of a station be an unsafe block

#

too short where the butt sticks back into the station?

chrome juniper
#

My understanding of the nomenclature here is that a "safe" block is a block long enough to contain a full-lentgh train.

#

An unsafe exit block would be, then, one which is shorter than the train and result in a train stopped in it also being in the stop's block.

#

If that is not a correct use of the local terms, it is my intention for their use in this case.

vivid stream
#

hm, maybe the nose-past-the-signal version is not really a compromise between 1.1 and tail-past-the-signal, but an alternative to tail-past-the-signal with the same general benefit but different drawbacks, but also higher throughput potential, so overall might be better

#

the question for me would still be what are the specific drawbacks and how often do they occur in practice, and only the devs can answer that right now

#

as for making it an option, it could be choice between 1.1, nose-past and tail-past, or between only two of these

#

but it would need a good name and description

#

personally I feel like the train stop already has enough options, and figuring out a relatively simple solution with circuits can be nice too, so maybe it shouldn't be a feature at all

#

also I think most newbs will be using traditional schedules instead of LTN-like generic schedules, so this problem which apparently becomes so much bigger with generic stations according to the FFF wouldn't apply to most inexperienced players

#

but the devs encountering this problem so much while playing their own game makes you think

#

I mean the devs are not ones to shy away from using circuits from what we've seen

chrome juniper
#

Interestingly even though the devs have a bit of experience with the game and encounter many issues, which the also fix, it has been learned that the players will find multiple times as many things as the devs will. The players are hell on a game.

#

They, the players, ain't no easier on the mods than the main game either.

#

I just realized that if my interpretation of the change is correct, it can trivially be implemented with a single wire:
Connect a wire from the nearest signal to the train stop. Set the signal to "read". Set the train stop to "send to train". Add a wait condition of AND to all others with the setting of green signal > 0.
To simulate it using the "full train must clear" concept would be a bit trickier, though probably rather simple in its own right, I just cba to figure it out.

#

The circuit version is not 100% safe as per-tick changes can cause the signal to go red after the train launches but before it reaches the signal. Still, for a test-bed situation it's probably good enough.

cerulean birch
#

Circuit version can just use a dummy signal partway down the strain station to detect when the train passes far enough down.

#

It's clunky, but it's also a solution to what is realistically a reaaaaally niche problem that is easier solved with a top level design change.

warm sky
#

I have managed to recreate the issue - except this time without a train in manual mode. Entirely trains in automatic mode

image.png
coarse pecan
#

Looks like just normal loop saturation again…

warm sky
#

The train that is stuck is in "destination full" mode, which was caused by deconstructing the destination station while it was in transit, then recontructing it elsewhere

coarse pecan
#

Somewhere it couldn’t get to presumably?

#

That would work with any other train that has its destination removed

warm sky
#

no it could, it just never got rerouted to it because other trains kept getting routed there first

glossy hound
#

and how would the new feature help with this

#

this is once again caused by manual intervention

warm sky
#

with the new feature, this would only block the copper mine, NOT the entire section and it wouldn't grab all the trains from across the map.

#

You can't tell me that you've never deconstructed a station somewhere in your base?

coarse pecan
#

Very rarely once they’re actually in service, and still then never had a deadlock

#

Deconstructing a station that trains are actively pathing to is asking for problems

glossy hound
#

yeah, I disable the station and then deconstruct it

coarse pecan
#

Typically I’m not really deconstructing stations at all outside of mines that have run dry

#

Which wouldn’t have trains going to them anyway

#

If I’m deconstructing entire factories, I’m probably also getting rid of their trains

#

Or they’re on a generic schedule and already have a place to wait

warm sky
#

Crazy reroutes from trains in the queue

image.png
cerulean birch
warm sky
cerulean birch
#

Bro

#

That isn't guaranteed

#

You can create the same behavior with or without the fix

#

The "fix" just makes certain states marginally less likely. You're moving the breakpoint around a bit. It doesn't actually "prevent" that.

warm sky
#

Yes it is. Why would a train path into the traffic jam?

The only reason that trains ARE pathing into the traffic jam in the save is that the train limit of the station is at 2/3

#

despite the station being full

cerulean birch
#

All you need is for the departing train to get stuck in a position that arriving trains have a "point of no return" that they can't path out of

#

That can occur even without the train being in the station

warm sky
#

There is a 2nd condition: you need arriving trains

cerulean birch
#

becauase again the root cause of your problem is that you have a parked train fucking up your network

#

Either don't decon stuff with trains en-route or build pathfinding penalty stackers to give you some elasticity for doing stupid shit

#

Those actually address the root cause of the problem

warm sky
#

What if a biter 'deconstructs' a station?

#

If one of the planets is particularly hostile and does require rebuilding of a lot of stuff, then you want your train network to be robust enough that 1 small fuck up doesn't explode into the entire network being down. You want 1 small fuck up to stay localised, and then eventually go away.

cerulean birch
#

You can cause this fuckup with the fix in the FFF

warm sky
#

Do it then

cerulean birch
#

IDK why you refuse to accept that.

warm sky
#

Because the mechanics I use to cause it are abusing the fact that a station has more trains than it has blocks?

#

A mechanic which is exactly the thing they are removing?

#

You go ahead and prove it. Add those circuits to imitate the future behaviour.

All that will happen is you will have 1 train stopped on the tracks, 1 mine be disabled, and then all the other trains will path around the disabled station (since a stopped train has a pathfinding penalty) instead of pathing into it for no reason.

#

The rest of your network will continue to function just fine. You won't lose all your trains into this 1 single mine.

#

Look at this and tell me whether this is expected train behaviour. This section of the tracks contains 1 iron train at the iron station (train limit 3), 1 iron train which bugged out, and 12 copper trains all here because they tried to reach the copper mine (train limit 3)
https://cdn.discordapp.com/attachments/1185263504618438777/1185692596635439337/image.png?ex=65908948&is=657e1448&hm=2d01119d79d23ea420dabac124401a110ebabda8dd08abbb4394678884672590&

Normally you would assume that setting a train limit of 3 would mean there would be no more than 3 copper trains in this entire section of the network. No matter what happens. There is no reason at all for any more trains to go to this section. Only that's not the case...

dusty depot
#

I think it would be informative to do the same setup, but with some circuits to emulate the change

warm sky
#

Or I'll just manually lower the train limit by 1

cerulean birch
dusty depot
#

I'd like to see how it behaves with the change

cerulean birch
#

but other configurations don't necessarily behave differently.

#

or not meaningfully so

dusty depot
#

So if I understand correctly, we have

  • one setup that behaves worse (really long trains)
  • one setup that behaves better (the network above)
  • a myrad of setups that are not effected
  • the ability to change between them with a circuit or 2
cerulean birch
#

long trains aren't the only thing that behave worse

#

Anything where changeover time is important to minimize becomes much more complex.

#

That applies all the way down to 1-1 stubbies.

dusty depot
#

CCan you show a setup with 1-1 trains that performs worse with the change? It would be informative to show it performing well without the change and poorly with a circuit emulating the change

cerulean birch
#

Since UPS efficient designs tend to be very minimalistic, they tend to need short changeover times because they can't "get ahead" of the demand of the station very quickly.

cerulean birch
glossy hound
#

it's really not hard to imagine, just any setup where trains are unloading very, very quickly

cerulean birch
#

low stack size items being consumed at high rates would also trigger similar problems

glossy hound
#

like bot trains or doing the 4 blue belts per wagon thing I made

#

this is going to be even more easy to do with quality inserters having higher swing speeds

cerulean birch
#

yeah, if you're pushing to ludicrous belt amounts out

#

although if you're keeping the throughpt constant between versions the quality inserters actually help with it.

#

cause they reduce the unload time so you have more time to allocate to changeover to get the same throughput

glossy hound
#

well yeah, just if you're going for higher throughput

#

then it's even more important

cerulean birch
#

but they let you push to higher throughput values, and changeover becomes muuuuuuch more constrained in that context

#

yep, exactly.

dusty depot
#

so is that a regression then?

cerulean birch
#

the proposed change in the FFF is a regression in terms of mitigating changeover time

#

yes

#

It can be worked around, but it's clunky, and was not necesary before, so that's still a regression

dusty depot
#

just plop down higher q inserters

cerulean birch
#

which has been the argument being brought up here the entire time.

glossy hound
#

no, they're way more expensive and annoying to create

#

and DLC exclusive

cerulean birch
#

You can't twist this into not being a functionality regression.

#

It is. Full stop.

dusty depot
#

the point is high train throughput stations perform worse with the expansion, but you are given better tools. so it seems like its a wash. or these stations may even perform better

cerulean birch
#

The train changes apply as part of base

dusty depot
#

will you be playing on base?

glossy hound
#

the better tools don't even make the problem that much better, it's just slightly better

#

it's not a good enough thing to make the train feature worth it

cerulean birch
dusty depot
#

i its worse for some people. for other people its an improvement

glossy hound
#

it's not an opinionated thing

#

it objectively makes trains lower throughput

cerulean birch
#

Which is why the proposal was to make it a toggle.

glossy hound
#

whether or not people make trains with high throughput requirements is subjective

dusty depot
glossy hound
#

no, that's the point

cerulean birch
#

No

#

It does not improve throughput

#

it partially mitigates some edge cases from you doing stupid shit

dusty depot
cerulean birch
#

Don't do stupid shit.

glossy hound
#

that's not throughput

#

that is a blockage

#

which was caused from manual intervention

cerulean birch
dusty depot
#

i might argue that unloading too quickly is stupid shit. personally, i always include extra unload capacity to deal with train spacing

glossy hound
#

making a megabase and requirements for efficient design at high loads is not "stupid shit"

dusty depot
#

living your live and factory on razor thin margins is

glossy hound
#

I don't understand what point you're trying to make

cerulean birch
glossy hound
#

do you have opinions about the new feature or is your entire thing just going to be arguing for the sake of it

cerulean birch
#

So, what point are you trying to make.

dusty depot
#

its something like "please demonstrate that the edge case of high throughput is more important that the edgecase of clogged trains"

cerulean birch
#

_ _
Is your point that maximixing throughput potential and leaving a dead train on your tracks are somehow equivallent?

dusty depot
#

I believe this problem was demonstrated without dead trains

glossy hound
#

high throughput is not an edge case, it is a design decision

#

intentionally clogged trains are an edge case

dusty depot
#

I believe at least 2 people have said that they clogged their trains without intent

cerulean birch
#

Because they left dead trains or had bad signalling.... so... what's the problem?

#

like.. leaving a dead train is something you did.

#

You created that situation.

glossy hound
#

both of those instances were easily solvable issues, the new feature doesn't actually help solve the root cause, it just makes the fallout from them slightly better in very specific station designs

dusty depot
#

I think we can ignore the idea of dead trains as this has been demonstrated without them

glossy hound
#

okay, so we have 1 (?) person with a scenario where this helps

cerulean birch
#

You can demonstrate the issue with the feature.

#

Just need train(s) obstructing in such a way that trains en-route attempt to pathfind away to a different station, but are unable to do so.

dusty depot
#

I think we could say the same for high throughput -- its a very specific situation , and as is is slightly higher thoughput. throughput issues are easily solvable. add a 2nd station.

cerulean birch
#

Yes or no

dusty depot
#

if you want a setting go for it. but I'm not the one building the game. i do have issues with the way its being discussed

glossy hound
#

no offense, but you are directly contributing to that

cerulean birch
#

if you want a setting go for it.

Then why are you arguing.

glossy hound
#

and so are we

cerulean birch
#

The OP of this thread is literally "This should be optional"

#

Why are you arguing about it lmao

glossy hound
#

if you have an issue with how a conversation is going, make a ticket or a post in mod desk or something other than also contributing to said conversation in the same way

#

not to dogpile or be a hard ass about it

frozen orchid
dusty depot
#

How can a single person dogpile 2 people?

#

lol

glossy hound
#

kelvin and I were both kind of dogpiling on you

dusty depot
#

And franky, I didnt come into this thread today arguing anything. I just asked for a demonstration of the change so I could see it.

#

Then suddenly I needed to have a "point"

glossy hound
#

well, you were asking questions about our point of it being a bad thing to be forced onto people, seemingly with the intent of refuting it

#

in my eyes, that is a foundation of an argument

cerulean birch
dusty depot
cerulean birch
#

That's some "can't actually post an image macro, but this is close enough" stuff. Tone wise you've been looking to start an argument for the whole day.

dusty depot
#

I think its fair to ask the people claiming that a change will be disruptive to show evidence of it

glossy hound
#

we don't have the feature accessible

#

how are we supposed to do that

dusty depot
#

Right, but there's been circuits designed in this thread to emulate the change, I believe?

cerulean birch
#

The circuit condition can aproximate it, but it's not perfect because of 1 tick delays

dusty depot
#

Do you think those 1 tick delays will have a big negative change?

cerulean birch
#

realistically, unlikely

#

but it introduces an edge case that needs to be stepped through in slomo to verify that it's not occuring

glossy hound
#

if a train is waiting with destination full, it could potentially path before it happens

#

I'm also thinking of a design that does not have the 1 tick delay

#

but I am not home

cerulean birch
#

I've got a design that should break even with the fix, but not in the mood to build it atm.

glossy hound
#

I guess the current design is 2 tick because the rail signal signal change -> station is 1 tick and the decider is the second tick?

dusty depot
cerulean birch
#

especially when the conversation here has been so antagonistic. Why put in the effort to convince people that don't seem interested in listening?

That wasn't even the original point. The original point is that it's a throughput regression. Not sure why the onus should be on me to prove that you can still break things with the change. I don't care about that because you don't need this not to breakin the first place.

dusty depot
#

Well personally I think calling it a regression is agressive language that maybe rubbed me the wrong way. I feel that inserts the idea that it is a bad change as the premise.

cerulean birch
#

Thats.... literally what you call it though?

#

Like... what????

dusty depot
#

I dont super want to get into semantics but generally any change to the way trains work is going to negatively impact some setup. I'm aware you are pushing for a toggle but the form of "a subset of setup are impacted, therefore we need a toggle" doesnt really follow.

#

For example, if they were changing it from the new way to the old way, you could call it a "regression" because some setups would now get clogged. Therefore I dont think its a useful term

#

If the change made things worse or no better for every setup, I think regression is the right term for it. But here it seems more like a "sidegrade"

glossy hound
#

slightly different example, but imagine if they changed express belts to be 40 items/s again. if you made designs that don't use the "extra" 5/s, you don't care, right? but what about all the people who are using 45/s? it's a direct decrease, or "regression"

#

granted making belts 40/s doesn't really have an upside, but so far we really haven't seen much of an upside for the new feature either...

dusty depot
glossy hound
#

just vague language and easily preventable stupid examples, for lack of a better word, made by one guy

cerulean birch
#

Train unloader maintains throughput
patch is applied.
No longer maintains throughput.

glossy hound
#

software regression is a specific type of regression

#

perhaps there was no "less developed" state to return to, but I really don't think semantics about how a specific word feels is important
we all understand that less throughput means less, and that is an objectively worse thing even if it doesn't impact everybody

dusty depot
#

Okay, so the question is: "is the change less developed?" If the average state of factorio was worse, then yes. But if its worse for some setups and better for other setups, its less clear.

I think its clear this makes some setups worse, but other setups better. Therefore we need to weigh the different setups and weigh them by frequency and utility before calling it a regression. Calling it a regression inserts that conclusion into the way you talk about it

glossy hound
#

it's not better for some setups

frozen orchid
#

I honestly can't say I'm too convinced by the "my current design won't work anymore in 2.0" argument, as it is a major upgrade for a reason, so such breaking changes should be expected. There will be many other changes that already break the design either way too...

glossy hound
#

this is a relatively isolated thing, speckled

dusty depot
glossy hound
#

that setup was purposefully crafted to break

#

and is again easily fixed with like two button presses

frozen orchid
glossy hound
#

I can't imagine that trains and belts, a fundamental aspect of the game, are going to be changed much in how they function
trains still move on rails, belts still carry items, and both things still have a throughput limit

dusty depot
#

Further, we have developer's word:

But there was one little problem with the system, which could even cause traffic jams/deadlocks, and which was made much more important with the generic schedules.

The problem is that once the train decides to leave the station, it instantly clears the reservation of the train limit, while still physically blocking the stop. This lets another train start its journey toward the stop, while there might not be enough space to wait without blocking the mainline.
The developers of Factorio experienced this problem and added this change to improve their experience. So saying that no setup exists that this change helps seems extremely unlikely.

glossy hound
#

developers don't necessarily play the game in the most optimal way

#

I guarantee that some of the developers don't fully grasp correct signaling

dusty depot
#

I think the vast majority of people are playing the game as optimally or less optimally than the developers. So then, the vast majority of people will be helped by this change.

frozen orchid
#

The entire rail geometry is getting overhauled too, which may very well allow for more compact designs offsetting the cost though. I don't think you can focus in on just the individual issue when considering a major change like this

glossy hound
#

elevated rails are DLC only

#

this affects base as well

frozen orchid
glossy hound
#

and again, nobody is saying this feature should be reverted

#

only that it should have a toggle

#

I do not understand why there are some so adamant about defending the feature as if that was the point

dusty depot
#

Can you call me by name please? 🙂

glossy hound
#

it's not just you

cerulean birch
#

I still think that nose past the first signal is a reasonable enough compromise to avoid needing a toggle. If your train can't clear the station after going past the first signal, that's a pretty easy problem to understand.

Yeah it doesn't completely solve a case designed to break it, but again, that's a design/signaling issue. Short of the game reading your brain waves and magically figuring out what your intentions are, that line needs to be somewhere.

glossy hound
#

which is why I said some, not naming multiple different people

dusty depot
#

Well I'm the one here. Sorry, its minor, but it rubs me the wrong way when people talk past me like that.

glossy hound
#

I did not mean to offend with that

#

in fact I did think about it before sending but sent anyway hoping it would be understood

dusty depot
#

Sorry for misunderstanding you then!

glossy hound
#

no worries

frozen orchid
#

I personally don't care which way this goes, but I do think that building in a toggle for it is not warranted

glossy hound
#

why do you think a toggle is not warranted then

#

I'm curious as to what your reasoning is

frozen orchid
#

Because there's a cost to it. Both for implementing it and for maintaining and debugging issues around it. All for a very minor saving in UPS that 0.1% of the playerbase will reach, let alone care about.

dusty depot
#

Toggles make the game more complicated and confusing for people. Plus they need to be maintained by the developers. So they need to have a minimum amount of value to justify their existence.

glossy hound
#

a single boolean check is not that much of a cost though

frozen orchid
#

My time for verifying what it's set to every time someone has an issue with trains getting stuck at their station is though

glossy hound
#

that is a quite indirect issue honestly

#

2.0 is going to be way more complicated and confusing overall, I doubt something this small (as in the UI and implementation) will affect that too much

frozen orchid
#

I have never asserted it is a huge cost. Only that it is not worth the benefit

#

The cost of the new feature seems to be a slight reduction in throughput, but ultimately what's the effect of that? Slightly worse UPS? Slightly smaller megabases? There are too many confounding factors in 2.0 to even measure a result of this

#

I also don't believe that the mental load of needing to create new designs is an issue, because then you probably shouldn't update the game at all (also that's like the core gameplay loop)

neon loom
glossy hound
#

it's only a signaling issue because if you move the rail signal slightly forward where the butt of the train is no longer in the station you would have the same functionality but no deadlock

neon loom
#

Changing the signalling to fix the issue reduced the throughput of the adjacent tracks significantly, happens to be throughput is what started this whole discussion

glossy hound
#

you don't even need to change the main line

#

literally just move this signal

image.png
#

or place another rail signal midway through the station

#

throughput unaffected

neon loom
#

Indeed, but then a train wouldn't fit in between the two signals that A and B are sitting at, but this is entirely besides my point.

The Dev(s) almost certainly had a similar situation occur, thought 'why did this happen' and realised they made the intuitive assumption that having enough blocks in and behind a station for the full train limit would be enough to not back onto the main line

coarse pecan
#

It really feels like someone went “nah, instead of fixing the problem myself I’ll make the game change around me instead”

#

That’s the part that bothers those of us that are against it I think

glossy hound
#

and even if you did, the other suggestion I made also solves it

neon loom
#

No I don't, but it's what I wanted when I built it

glossy hound
#

this also prevents your issue

image.png
#

also, the thing I made in the pins would also fix it if you wanted to go the circuity approach

frozen orchid
#

Hmmm, signals in your train stops are not a recommendation I would make lol

glossy hound
#

why?

frozen orchid
#

I've seen some horrendous pathing as a result of that lol

glossy hound
#

only when it's a chain

coarse pecan
#

It’s worked fine for me?

#

I regularly do that as a way of micromanaging priority as well

#

Haven’t had issues with it at all

frozen orchid
#

Every block in the station counts as an occupied block, which can massively increase the pathfinding penalty to that station, sending trains across the map when they don't need to.

coarse pecan
#

That’s the point, yes

#

For what I was using it for anyway

glossy hound
#

so a train would path to an unoccupied station instead of an occupied one

#

I don't see the issue

frozen orchid
#

Unreasonably so

neon loom
#

it doesn't matter if changing it fixes my issue, the issue already occurred

I made an assumption, one that one of the Devs almost certainly made, and I reckon a lot of other players would make, which happened to be incorrect and lead to a deadlock.

If making the change reduces the chance of players running into the issue, you're saving some people the massive headache of an unexpected deadlock while they're not on the planet to fix it.

glossy hound
#

it's only 500 penalty, speckled

#

per block

frozen orchid
#

That easily adds up to a few km of detour if you put a bunch of signals in your station :P

glossy hound
#

for context, this is 250 rails, or 500 penalty

image.png
#

yeah, don't put a bunch of signals in your station

#

one is fine

#

if your network is so volatile where a train goes this distance extra (to another station that is less occupied) and that is a bad thing, I have some serious questions about your network

frozen orchid
#

lol

#

Have seen it happen, was a pain to debug

glossy hound