Factorio Forums

So, are diagonal tracks bad for UPS or not ? (You wouldn't use such a huge stacker in a normal base...)
Or are they required for his design due to pathfinding costs ?

My personal opinion is to abandon the shared stacker for the base unload stations. Instead have one stacker for iron, another for copper, and another for stone etc. Then all the iron unload stations can branch off a single rail line from their stacker. That way you can add a waiting bay right before the first branch to the first iron unload station. That gets the waiting trains as close as possible to their unload stations, and reduces the delay between a train leaving an unload station, and another train arriving. Unless you have a lot of iron unload stations, it also eliminates the need for multiple exit lines from the stacker, and hence any need for lane changers.

BlueTemplar wrote: Fri Aug 23, 2019 7:38 am So, are diagonal tracks bad for UPS or not ?

Jeez. Not everything is about UPS. They are simply very space efficient. The tracks are very close together and easy to merge. If everything is perpendicular to each other it needs more space

BlueTemplar wrote: Fri Aug 23, 2019 7:38 am So, are diagonal tracks bad for UPS or not ? (You wouldn't use such a huge stacker in a normal base...)
Or are they required for his design due to pathfinding costs ?

I have heard diagonal tracks are "worse" than straight tracks for "performance", I am not sure it has to do with UPS, i thought it has to do with the rendering/sprite aspect, that is diagonal train are composed of more sprites, or the sprites are bigger something like that maybe i'm wrong though .

( It has always seems very minor to me, you don't purposefully design a base with all diagnoal tracks if you wish to optimize, but if you had such base and you'd redo the whole train network, the gain would be too small to notice in my experience, i had never seen the train pathfinding taking much times per cycle in a situation that would solely be caused by diagonal rails, 90% of time it is because of the pathfinding and structure of the network ! )

Diagonal tracks allow for more compact stacker than vertical or horizontal, from experience.

I would use such big stacker if i ever need 40 blue belts of the same material in one place but most of the time my whole factory don't consume the 108K per minutes of material, and if it grows this big, usually i have dedicated line, iron for steel, iron for plates, iron for circuits, and those can have their own unloading station, not all branching from the same unless it's the aim of my game since it's a challenge, compared to just using ploping a copy of the first medium-sized station as i did for outpost.

The stackers should be able to receive all rolling trains if for example you stop production, you don't need iron, all the trains would back up in one place, near the unloading, if you don't have a big enough stacker for all trains, they will start to pile up, and end up blocking the main network. In my example I considered that ALL iron train should have room to park after the "station entrance".

This also means the further away the ressources, the more train you will need to maintain a continuous flow the bigger the stacker is needed in case they all stop at one end.

All train also have room to park in their oupost were they all depleted, in my design, i used a different outpost name, so trains are dedicated to their iron patch. They do not seek the closest iron outpost and wouldn't end up all jamming the same but only wait in their parking place.


The thing that was made to ease the pathfinding, was to use a station before the stacker, both an entrance for the unload and for each outpost. This makes the trains only consider the main network for long distance, and consider the many many parralel lane only as a short single step. There is only 1 way to get to the entrance, then many many ways to do a small step throught the stacker , and then only 1 way for long distance, and then many many ways to do small step again.

I see that like a GPS that would recalculate the whole road when the parking lot you wanted to use is taken. That's bad, you calculate the road to the place you want to go once, like the entrance of the city. And only then you'll try to find a parking lot or adapt to city's traffic, this is a "second path", not one big.

After further experiment on the save increasing inserter stack size, the station can be adapted but the bottleneck comes from 2 other aspects : The outpost are too close to each other, the trains merging/leaving would leave gaps in the continous flow of trains and the distances are too small for them to normalize before arriving at the station entrance, if you add more trains it only creates traffic jam they don't have enough room to slow down nicely and accelerate back.

The LLCCCC trains have hard limitations, there is a maximum number of them that can go through one rail track using the optimal speed/braking distance to maximize the number of wagon that can go through the entrance of the unload in 1 minutes. [20 trains per minutes = 80 wagon = 160 K iron = 3 sec per trains] you can't triple that easily given the cap on train speed, and the distance between 2 trains that increase with their speed.


Then you dispatch them in unloading lane, and recombine the flow of train at the end. The station with some tweaks can handle the maximum flow of LLCCCC trains that the network can provide, after that to increase throughput it's about changing the fuel type, or changing everything to use different trains , or using more than 1 entrance lane because one can't just move the outpost in real game .

ah, this makes allot more sense now. Thanks

mmmPI wrote: Thu Aug 22, 2019 4:05 pm Thus i used the wiki-rules to make the trains think the outer lane is shorter than the inner lane, because the outer lane has less signal and the pathfindind of trains consider that each signal "cost" some distance ( this is why i linked to the wiki , for understanding how train behave in this portion it's difficult without !).

I don't believe that regular signals, only circuit-controlled signals, and only when they are set red by the circuit condition, add to the cost of a path. Specifically, the game treats them as having a high cost (1/2 what an unrelated station costs) because it can't know what the condition for turning green is. So, it assumes that the wait time could be real high, and any other path is going to be better most of the time. A circuit wired signal that is not red won't cause the trains to avoid the path.

You can add "please don't" cost by putting a station on the path, though, since trains hate to pass through stations that are not in their schedule. A neat trick is to name it " ", as in, a single blank space. Then the station won't show up in the list when you are editing schedules and stuff. I assume it trims whitespace, then because the remaining name is the empty string, skips it: empty string is used to represent invalid destinations such as destroyed stations.

I could be wrong about the cost, of course, so I'd love a pointer to exactly where it talks about regular signals increasing cost?
Alternately, if it doesn't work at some point, there is a trick to solve it, I guess?

Wiki says you are correct. Only circuit disabled signals give a penalty. (1000 tiles).
Neat trick, a ghost station. I use a double signal in big stackers. Wire the back one to be red when front one is red.
Wiki entry about pathfinding

slippycheeze wrote: Fri Aug 23, 2019 9:13 pm

mmmPI wrote: Thu Aug 22, 2019 4:05 pm Thus i used the wiki-rules to make the trains think the outer lane is shorter than the inner lane, because the outer lane has less signal and the pathfindind of trains consider that each signal "cost" some distance ( this is why i linked to the wiki , for understanding how train behave in this portion it's difficult without !).

I don't believe that regular signals, only circuit-controlled signals, and only when they are set red by the circuit condition, add to the cost of a path. Specifically, the game treats them as having a high cost (1/2 what an unrelated station costs) because it can't know what the condition for turning green is. So, it assumes that the wait time could be real high, and any other path is going to be better most of the time. A circuit wired signal that is not red won't cause the trains to avoid the path.

You can add "please don't" cost by putting a station on the path, though, since trains hate to pass through stations that are not in their schedule. A neat trick is to name it " ", as in, a single blank space. Then the station won't show up in the list when you are editing schedules and stuff. I assume it trims whitespace, then because the remaining name is the empty string, skips it: empty string is used to represent invalid destinations such as destroyed stations.

I could be wrong about the cost, of course, so I'd love a pointer to exactly where it talks about regular signals increasing cost?
Alternately, if it doesn't work at some point, there is a trick to solve it, I guess?

You are correct it is not distance cost that is added i thought it was as simple as that and wrote misleading sentence !

So why do my trains still go for the longer route instead of the shorter one ? Well good luck explaining it in details

It is not written something like " trains prefer to wait closer to the unload station even if the route is a bit longer compared to waiting further away because the short route is all blocked with chain signals " but this was my intended behavior. The pathfinding algorithm happens to repath the trains dynamically, in my setup which makes trains behave as i wanted because i fiddle quite a bit adding signal here , signal there, changing little portion of the rail here and there, for this i advised wiki-rules.

The outer lane is not made shorter by having less signal, it is a mix of when the train repath, and where they repath, and which speed they were going when repathing. 2 trains can be on the horizontal part at the same time, if so, they can't be seeking for the same station, else one would have waited at a chain signal. Yet one can still cross the way of the second one, in this case the second one will repath, and the outer lane would be the only availble spot for the train at the moment. ( i think something like that )

OR

maybe this rules also comes into play to make the lane look shorter : When the path includes a train currently arriving to a rail signal -> Add a penalty of 100. this is 100 rails, which is a lot if you have 3 signals that are yellow close together on 6 rails, they would cost 300 right ?, not sure about chain signal though i think it is the same and the rules was written using rail signal as a generic term including them.

In such a setup, when you use the debug menu to show train repathing using F4, you will see many many repathing it will hardly explain what is happening, if you make visible the path the train is following, it doesn't explain why it is changing or choosing one over another you need to look outside of the game to understand, such as in the wiki , it can also help debunk mistakes in pedantic posts, try for yourself do not trust the words

slippycheeze wrote: Fri Aug 23, 2019 9:13 pm

mmmPI wrote: Thu Aug 22, 2019 4:05 pm Thus i used the wiki-rules to make the trains think the outer lane is shorter than the inner lane, because the outer lane has less signal and the pathfindind of trains consider that each signal "cost" some distance ( this is why i linked to the wiki , for understanding how train behave in this portion it's difficult without !).

I don't believe that regular signals, only circuit-controlled signals, and only when they are set red by the circuit condition, add to the cost of a path. Specifically, the game treats them as having a high cost (1/2 what an unrelated station costs) because it can't know what the condition for turning green is. So, it assumes that the wait time could be real high, and any other path is going to be better most of the time. A circuit wired signal that is not red won't cause the trains to avoid the path.

You can add "please don't" cost by putting a station on the path, though, since trains hate to pass through stations that are not in their schedule. A neat trick is to name it " ", as in, a single blank space. Then the station won't show up in the list when you are editing schedules and stuff. I assume it trims whitespace, then because the remaining name is the empty string, skips it: empty string is used to represent invalid destinations such as destroyed stations.

I could be wrong about the cost, of course, so I'd love a pointer to exactly where it talks about regular signals increasing cost?
Alternately, if it doesn't work at some point, there is a trick to solve it, I guess?

I actually wish signals would alway add a small cost (like 1) so trains would prefer the paths with less junctions.

As for stations named " " not showing up: Is that something new since we have temporary stops? Maybe the temporary stop use stations named " " so the train station menu filters them out?

That blank trick was new to me as well. Good to know.

mrvn wrote: Mon Aug 26, 2019 10:26 am I actually wish signals would alway add a small cost (like 1) so trains would prefer the paths with less junctions.

This is a good feature request, and should be pushed to a top level post asking for nothing but this change.

Uh, though, a cost of one will vanish almost instantly into the noise: a standard LLCCCC train has a cost of either 47, or 23.5, end to end. (I still don't know if rails count on the 16x16 rail grid, or the 32x32 tile grid, but I presume the former -- and thus the lower of the two costs.)

Anyway, point is: most junctions pass through, like, maybe five or six signals total, so you barely increase the cost compared to moving around: most likely two carriages worth of rail, totaly. You would probably need to raise it to a cost of 10 (so, 50 rail lengths, or the size of a full train buffer for my LLCCCC example), or more, before things would even begin to notice.

It isn't zero cost, it just fades way, way too fast into the cost of simply moving along the rails. The only reason their base cost of 1 does much of anything is that keeps their price quite close to zero compared to any obstacle -- and that means path is dictated almost exclusively by things like passing through stations, or stopped trains, and very little by distance. Only in the most extreme cases (eg: run all the way out to a mining outpost a minute travel away, U-turn there, come back) does distance begin to be a real factor.

mrvn wrote: Mon Aug 26, 2019 10:26 am As for stations named " " not showing up: Is that something new since we have temporary stops? Maybe the temporary stop use stations named " " so the train station menu filters them out?

Nope. You can demonstrate this yourself, should you wish, by scheduling a train to a station, then renaming it to "single space character", and watching what it does on automatic mode.

I'm pretty sure this is just a confluence of individually good decisions interacting. Details follow, if you bored enough to want my reasoning. Apparently I'm bored enough to write it out or something.

In your train schedule an invalid station (eg: destroy a train stop the train was scheduled to go to) is represented by a name of "empty string".

Meanwhile, humans often stick extra whitespace on the start and end of strings when they name stuff. Copy-paste is especially bad for it, but it happens for lots of reasons. So, it is good, routine practice to strip whitespace on human input to get the meaningful name -- especially because people would expect "A" and " B" to sort "A,B", not " B,A", which not stripping the character would cause.

It is also hard to write validation rules for valid and invalid names. No matter what you do, someone gonna complain when they don't understand why " A" or "A " are invalid names -- especially because they can't *see* that trailing space, so as far they concerned it was "steel-processing-plant" that you declared invalid. I'll admit, I first found this using a mod to rename the entity, and assumed it was lacking validation that the standard UI did. I was wrong -- the standard UI is happy with that single space too.

Finally, people tend to do silly things in code, so having your listbox skip empty strings makes a lot of sense -- and probably double-so in the train schedule case, since that is a valid semantic meaning to an empty string, "invalid station".

So ... take a single space character which satisfies the validation code for station names ("no empty strings"), strip whitespace giving you the empty string, and then omit empty strings in the listbox and, boom, you have this behaviour.

slippycheeze wrote: Mon Aug 26, 2019 6:24 pm

mrvn wrote: Mon Aug 26, 2019 10:26 am I actually wish signals would alway add a small cost (like 1) so trains would prefer the paths with less junctions.

This is a good feature request, and should be pushed to a top level post asking for nothing but this change.

Uh, though, a cost of one will vanish almost instantly into the noise: a standard LLCCCC train has a cost of either 47, or 23.5, end to end. (I still don't know if rails count on the 16x16 rail grid, or the 32x32 tile grid, but I presume the former -- and thus the lower of the two costs.)

Anyway, point is: most junctions pass through, like, maybe five or six signals total, so you barely increase the cost compared to moving around: most likely two carriages worth of rail, totaly. You would probably need to raise it to a cost of 10 (so, 50 rail lengths, or the size of a full train buffer for my LLCCCC example), or more, before things would even begin to notice.

It isn't zero cost, it just fades way, way too fast into the cost of simply moving along the rails. The only reason their base cost of 1 does much of anything is that keeps their price quite close to zero compared to any obstacle -- and that means path is dictated almost exclusively by things like passing through stations, or stopped trains, and very little by distance. Only in the most extreme cases (eg: run all the way out to a mining outpost a minute travel away, U-turn there, come back) does distance begin to be a real factor.

Customize the cost with the value of combinator signals ?
P.S.: I guess that you can do that by enabling/disabling dummy stations ?
Still, not very granular considering the space taken, and the 2k cost... (and the visual clutter ?)

slippycheeze wrote: Mon Aug 26, 2019 6:24 pm

mrvn wrote: Mon Aug 26, 2019 10:26 am I actually wish signals would alway add a small cost (like 1) so trains would prefer the paths with less junctions.

This is a good feature request, and should be pushed to a top level post asking for nothing but this change.

Uh, though, a cost of one will vanish almost instantly into the noise: a standard LLCCCC train has a cost of either 47, or 23.5, end to end. (I still don't know if rails count on the 16x16 rail grid, or the 32x32 tile grid, but I presume the former -- and thus the lower of the two costs.)

Anyway, point is: most junctions pass through, like, maybe five or six signals total, so you barely increase the cost compared to moving around: most likely two carriages worth of rail, totaly. You would probably need to raise it to a cost of 10 (so, 50 rail lengths, or the size of a full train buffer for my LLCCCC example), or more, before things would even begin to notice.

It isn't zero cost, it just fades way, way too fast into the cost of simply moving along the rails. The only reason their base cost of 1 does much of anything is that keeps their price quite close to zero compared to any obstacle -- and that means path is dictated almost exclusively by things like passing through stations, or stopped trains, and very little by distance. Only in the most extreme cases (eg: run all the way out to a mining outpost a minute travel away, U-turn there, come back) does distance begin to be a real factor.

The use case I had in mind is having parallel tracks. The outer track constantly splits of to stations and merges back in (2 signals per station at least). Every so often there is an exchange between the inner and outer track (same signals on both tracks). Trains should prefer the inner track to some extend so the outer track has more space for trains leaving a station.

Maybe I can put a little wiggle / bulges into the outer tracks so it actually has a longer distance than the inner track.

I like this idea because putting a little wiggle in the rails would mess with my OCD.

mrvn wrote: Thu Aug 29, 2019 10:21 am

slippycheeze wrote: Mon Aug 26, 2019 6:24 pm

mrvn wrote: Mon Aug 26, 2019 10:26 am I actually wish signals would alway add a small cost (like 1) so trains would prefer the paths with less junctions.

This is a good feature request, and should be pushed to a top level post asking for nothing but this change.

Uh, though, a cost of one will vanish almost instantly into the noise: a standard LLCCCC train has a cost of either 47, or 23.5, end to end. (I still don't know if rails count on the 16x16 rail grid, or the 32x32 tile grid, but I presume the former -- and thus the lower of the two costs.)

Anyway, point is: most junctions pass through, like, maybe five or six signals total, so you barely increase the cost compared to moving around: most likely two carriages worth of rail, totaly. You would probably need to raise it to a cost of 10 (so, 50 rail lengths, or the size of a full train buffer for my LLCCCC example), or more, before things would even begin to notice.

It isn't zero cost, it just fades way, way too fast into the cost of simply moving along the rails. The only reason their base cost of 1 does much of anything is that keeps their price quite close to zero compared to any obstacle -- and that means path is dictated almost exclusively by things like passing through stations, or stopped trains, and very little by distance. Only in the most extreme cases (eg: run all the way out to a mining outpost a minute travel away, U-turn there, come back) does distance begin to be a real factor.

The use case I had in mind is having parallel tracks. The outer track constantly splits of to stations and merges back in (2 signals per station at least). Every so often there is an exchange between the inner and outer track (same signals on both tracks). Trains should prefer the inner track to some extend so the outer track has more space for trains leaving a station.

Maybe I can put a little wiggle / bulges into the outer tracks so it actually has a longer distance than the inner track.

Wiggles'd actually do it just fine, I think. As long as every place you could use the "slow" lane had a consistently higher length than the "fast" lane it'd apply right. ...which finally makes me realise that, if signals had that weight, they would also work for the fast/slow lane build. I don't *think* a weight of 1, or even 10, would be enough to substantially change pathing around/through intersections though.

We should probably move to testing, though, rather than speculating, at this point. My assumption is that since the train establishes the full path to the destination every time it calculates one, small cost changes would fade away the same way only very long rail runs will end up influencing the path decision, short path costs are dominated by the big ticket items -- stations, trains blocking lanes, etc. Most of those cost between 5 and 50 full chunks worth of rail distance.

mmmPI wrote: Fri Aug 23, 2019 12:02 pm

BlueTemplar wrote: Fri Aug 23, 2019 7:38 am So, are diagonal tracks bad for UPS or not ? (You wouldn't use such a huge stacker in a normal base...)
Or are they required for his design due to pathfinding costs ?

I have heard diagonal tracks are "worse" than straight tracks for "performance", I am not sure it has to do with UPS, i thought it has to do with the rendering/sprite aspect, that is diagonal train are composed of more sprites, or the sprites are bigger something like that maybe i'm wrong though .

According to this : https://mulark.github.io/tests/test-000 ... 00026.html i have to correct previous statement.
The in-depth tests indicates that the UPS are better with non-diagonal tracks.