Friday Facts #395 - Generic interrupts and Train stop priority

[Qon]

Quick question about the priority system. Are they soft priorities, such that X task is given some kind of bonus multiplier to its priority? Or are they hard priorities, such that do all 51s first, then do all 50's next, then do all 49's next, etc.?

The way it works, is that the priority of a train stop has two effects:

1. When searching for a destination, trains will prefer a higher priority train stop.
2. When trains are trying to leave a stop, trains at stops with higher priority are dispatched first.

Hard. "prefer" isn't really the most informative word, but the priority system is the only control we have for priority so it would be silly if trains could ignore our explicit decisions. It would be useless. Well if other influences like path length had a limited effect (like add at most 10 priority) or were also controllable with some factor then we could still remain in control of the game with a soft priority. But the point of a game is to play it, not try to play it but the game ignores your input and decisions and plays itself.

A hard priority system is very predictable, but I think it misses out on the player's intended behavior.

A hard priority system follows the orders of the player. A soft priority system is a system which by definition will ignore the players intended behavior. Just set your priorities correctly and dynamically if fixed priorities is not aligned with your intended behavior.

You run into silly scenarios, like the player pushes a priority up 1 point, which causes every single train to abandon every other task and perform the +1 priority route. "Do all 51's", then all the 50's, 49's and 48's are left with absolutely nothing.

If your set your train limits to something sensible then the high priority tasks will run out as long as you have enough trains.
As it is now, if all trains are only giving schedules to serve the ore route, no train will do anything else as well. So you need more trains if you want to dedicate some of them to some route, just like before. But now you can use 1 schedule for all trains. And you can raise priority dynamically or use interrupts for specific stops to handle having very few trains to serve a vast amount of locations appropriately.

I think that with "priority", players mean something more like a weighted round robin system. Consider something like "Do X 3 times, then Y 2 times, then Z every once in a while". Everything is given a guaranteed chance to work, while the priority determines how many "cards in the deck" the action gets to have. Higher priority means more copies of that card, increasing the odds of the action occurring. So when a player sets 100 priority, they mean to send twice as many trains as the 50 priority route. The station does get more traffic, but it does not break the entire network in the process.

Wrong.
But if you count how many trains have arrived and divide by your intended "soft priority" and set that as priority to the stops, then you basically get just that. Since priority will then equal out when stops have received the weighted number of trains you wanted. This implementation works, but it builds a flawed system so don't do it anyways.

[Qon]

I'm guessing we'll be able to set stop priority with some logic,

Why guess when the FFF related to this thread answers the question?

[Necronium]

Quick question about the priority system. Are they soft priorities, such that X task is given some kind of bonus multiplier to its priority? Or are they hard priorities, such that do all 51s first, then do all 50's next, then do all 49's next, etc.?

A hard priority system is very predictable, but I think it misses out on the player's intended behavior. You run into silly scenarios, like the player pushes a priority up 1 point, which causes every single train to abandon every other task and perform the +1 priority route. "Do all 51's", then all the 50's, 49's and 48's are left with absolutely nothing.

I think that with "priority", players mean something more like a weighted round robin system. Consider something like "Do X 3 times, then Y 2 times, then Z every once in a while". Everything is given a guaranteed chance to work, while the priority determines how many "cards in the deck" the action gets to have. Higher priority means more copies of that card, increasing the odds of the action occurring. So when a player sets 100 priority, they mean to send twice as many trains as the 50 priority route. The station does get more traffic, but it does not break the entire network in the process.

A train network wants to run at max efficiency, but at the same time it also wants an element of fairness to all the demands of the system. I don't think both elements always see eye to eye, so it's a tough thing to balance.

How priority works is explained by FFF itself and it is very simple:

The way it works, is that the priority of a train stop has two effects:

When searching for a destination, trains will prefer a higher priority train stop.
When trains are trying to leave a stop, trains at stops with higher priority are dispatched first.

I dont think that changing very simple concept of how priority works now to something that isnt priority is good idea. If I want station to be prioritized I want it to be prioritized always not when there is some strange rule to it. If I want to make smething like this there is CN for setting up priority for station that let other be served first.

[mergele]

That trains go to "no path" and dispatch a warning when their next destination is disabled is I think to much.
If the stop doesn't exist, fine, makes sense. But if it is disabled it has been done so via circuit network for a reason.
For example I have made a setup where a supply train automatically supplies all outposts with generic building materials and keeps them topped off. Most of the time it sits at base waiting for a outpost to request supplies. With this change it would be a constant blinking warning hazard and require laying global circuit connections (going against the whole idea of making it easy to pop up new outposts).

[Tertius]

For example I have made a setup where a supply train automatically supplies all outposts with generic building materials and keeps them topped off. Most of the time it sits at base waiting for a outpost to request supplies. With this change it would be a constant blinking warning hazard and require laying global circuit connections (going against the whole idea of making it easy to pop up new outposts).

Since there are no really disabled stations any more, there are no "no path" messages any more for stations that do actually exist. If you use the enable/disable functionality with 2.0, the train limit is set to 0 if you disable a station. And if all stations in a schedule are full (their remaining limit is 0), trains go to sleep. In 1.1, the purple "destination full" message, in 2.0 that new not flashing zZZ sleep icon.

You can already build that concept for supply trains in Factorio 1.1. Instead of disabling your supply stations, set their train limit to 0. It's either just one more decider combinator to output L=0 or L=1 or you already have one that creates such an output. At the base, if all supply stations are inactive with limit=0, you will see the purple "destination full" message instead of "no path". And that's already an improvement, because the red "no path" usually indicates an error, while "destination full" just indicates that there are currently just no destinations open.

[FuryoftheStars]

For example I have made a setup where a supply train automatically supplies all outposts with generic building materials and keeps them topped off. Most of the time it sits at base waiting for a outpost to request supplies. With this change it would be a constant blinking warning hazard and require laying global circuit connections (going against the whole idea of making it easy to pop up new outposts).

Since there are no really disabled stations any more, there are no "no path" messages any more for stations that do actually exist. If you use the enable/disable functionality with 2.0, the train limit is set to 0 if you disable a station. And if all stations in a schedule are full (their remaining limit is 0), trains go to sleep. In 1.1, the purple "destination full" message, in 2.0 that new not flashing zZZ sleep icon.

You can already build that concept for supply trains in Factorio 1.1. Instead of disabling your supply stations, set their train limit to 0. It's either just one more decider combinator to output L=0 or L=1 or you already have one that creates such an output. At the base, if all supply stations are inactive with limit=0, you will see the purple "destination full" message instead of "no path". And that's already an improvement, because the red "no path" usually indicates an error, while "destination full" just indicates that there are currently just no destinations open.

This only works, though, if you name all of your stops the same. If you don't for some reason, like you prefer having individualized names or add some other descriptor to the supply stop's name for where it's located (ex: Iron Mine 3 Supply), then this will not work.

[bobucles]

A hard priority system follows the orders of the player. A soft priority system is a system which by definition will ignore the players intended behavior. Just set your priorities correctly and dynamically if fixed priorities is not aligned with your intended behavior.

So what you're saying, is that priority is a useless system that causes more problems than it solves.
Interrupts already handle hard priority tasks. If X is needed, the train stops what it's doing and does X. That's exactly when a player needs hard priority.
Trains doing everyday tasks don't need that. They need to split their attention in every direction, and provide fair access to all the stations under their wing. There is no point in having 254 priority levels, if a +1 priority deletes all the stations beneath it. You may as well turn stations on or off, it does the same thing.

[Sander_Bouwhuis]

I have to say, although I've liked playing Factorio off and on for the last 5 to 10 years or so, I don't think I'll be buying the new DLC.
This game has become way too complicated. All the changes I see here are just for a very small amount of people who have a massive factory and understand how trains, train signals, bots, logic units etc work. I wish they would make the game bigger without a level of complexity where it takes ever more time figuring out HOW things work, rather then actually playing the game to make things work.

Maybe it's just me, so happy gaming to all the aficionados who have the time and patience to figure out how everything works.

[Qon]

A hard priority system follows the orders of the player. A soft priority system is a system which by definition will ignore the players intended behavior. Just set your priorities correctly and dynamically if fixed priorities is not aligned with your intended behavior.

So what you're saying, is that priority is a useless system that causes more problems than it solves.

Are you incapable of reading what I wrote, and that you quoted, or are you making strawmen with malicious purpose?
It causes no problems, because if you don't use it then it has no effect. For those that understand it it can be a convenient way to fine tune the workings of the factory. You are allowed to see the system as beyond your mental capacities and pass on using it if it would cause you more problems than it solves. It's good to know your limits.

Interrupts already handle hard priority tasks. If X is needed, the train stops what it's doing and does X. That's exactly when a player needs hard priority.

Interrupts tell you what stop name to go to, but it doesn't give priority to a specific stop among several with the same name. Interrupt adds something to a schedule temporarily, priority sorts which station to serve first among those that the interrupt could choose from.

Trains doing everyday tasks don't need that.

Not all factories are built the same, some even have modpacks that require more complex priority systems. In 2.0 SA is probably one such mod where priority is feature that is very useful. And they mentioned regular uses for priority in the blog post as well. Currently it is solved by not using trains, because trains have no priority system. Instead you unload from trains to "mixing stations" and then use splitters with input priority to only allow trains manually set to the schedule that includes the high priority mine to unload. But then you need enough splitters and belt throughput that all resources of that type can flow through these mixing stations to solve the problem "perfectly". (Or use bots which also has a priority system with passive and active providers.) And it introduces a lot of extra building of UPS eating extra loading and unloading and splitters when the good solution would be to just give trains a priority system in line with other logistics systems.

They need to split their attention in every direction, and provide fair access to all the stations under their wing.

Wrong, and contradicted by FFF #395. Read it.

There is no point in having 254 priority levels, if a +1 priority deletes all the stations beneath it. You may as well turn stations on or off, it does the same thing.

Wrong.
First, It's 256 priority levels, not 254.
You can reduce limits/turn stops off to make your own priority system. But then that just means the player has to implement their own priority system with combinators and add a global circuit circuit network. Then the player has to gradually enable stops according to the priorities to force trains into high priority stops first. With 256 priority levels this takes several seconds to roll through all priority levels (but this very naive approach doesn't work, more on that later), and one such contraption is needed for every unique stop name. This isn't just beyond your capacity (unless you are admitting to trolling), it's beyond most players capacity.

Also, having more priority levels is useful. If you have 3 priority levels for 3 stops (each with limit 1) and 2 trains, the trains will serve the top 2 stops and ignore the lowest. This is one of reasons you can't just disable any stop that doesn't have top priority. And if you later add a 3rd train all three will be served, so disabling stops would give a vastly different result. Even constant priority here gives flexible results that adapts to the amount of available trains. And interrupts are one such feature which takes trains on/off a schedule dynamically. If you have 3 trains, but suddenly one takes a refueling break, then that is effectively one train out of commission and the other two trains will behave just like before you added the 3rd train, again ignoring the bottom priority.

And disabling train stops is not enough either to implement priority manually, since priority is not just used for selected destinations, but also for which train to allow to leave from stops with low or high priority. And for that you need circuit conditions in the schedule to stop trains from attempting to leave conditionally on your own priority system.

To loop through all exit priorities and then all arrival priorities 2^8 x 2^8 = 2^16 = 65536 ticks, or more than 18 minutes for all combinations, if done optimally and all priority levels utilized (or without data and without assumptions). This is because if you have try the same priority for both exit and arrival priority then you only really check for the highest of either. If you had a 40 priority destination and a 50 and a 60 priority for stops with trains trying to go to the destination, then you wouldn't be stopping either train when the "test" priority level sinks to 40 where the first destination opens.

So instead you would have a computer ask all stops what their priorities are and if they want to send a train or receive one. And then you separately find highest exit and arrival priority, and then only allow those, and then repeat this process. This requires that you implement some form of communication protocol that can answer the question of which stop has the highest priority for each type of stop name and train status (arrival/exit). This could be made to solve which stop to enable and train to exit in under a second. I have made similar systems before.

The built in priority system can do all this in a within a single tick for all trains at once, with no information sent via circuits at all, no configuration for matching signal types to stop names, and trivial for the player to use. It's vastly different.

[bobucles]

It causes no problems, because if you don't use it then it has no effect. For those that understand it it can be a convenient way to fine tune the workings of the factory. You are allowed to see the system as beyond your mental capacities and pass on using it if it would cause you more problems than it solves. It's good to know your limits.

"Don't use it" is not a compelling argument for a system. It is a compelling argument against a system, in fact it is the best argument against a system that can possibly exist. Don't defend a system by telling people they shouldn't use it, you're playing for the wrong side.

They need to split their attention in every direction, and provide fair access to all the stations under their wing.

Wrong, and contradicted by FFF #395. Read it.

FFF #395 states that trains can now operate in a very general purpose mode that services an entire system. That's exactly the kind of complex network that priority systems are meant to help organize. These are very powerful tools with a lot of responsibilities to deal with, and that's exciting. It's also a system that needs to be well protected against breaking, or players will be flying between planets all the time trying to diagnose and fix them.

Currently there are very powerful tools to help organize train networks. Stop limits, parking lots, and interrupts all look like they will solve many problems down the line. Priority doesn't look like a problem solver. It looks like a problem maker.

There are many other colony management type games that incorporate hard priority systems, and they tend to work out very poorly. That's because colony games have a wide general purpose priority system, filled with many life threating priorities. A colony can not drop anything and everything to perform a +1 task, because neglecting the lesser jobs threatens the life of the colony. Generic train jobs are fulfilling a very similar function. Everything under their umbrella is important, and abandoning any one role is the same as neglecting an essential life support task. Some tasks are more important than others, but they're not SO much more important to amputate everything else. They just need a little push in the right direction, a little bit more time on the schedule, a little less odd jobs and a little bit more critical jobs to keep things running smoothly. That's the kind of priority a generic train needs to work with.

There is no point in having 254 priority levels, if a +1 priority deletes all the stations beneath it. You may as well turn stations on or off, it does the same thing.

Wrong.
First, It's 256 priority levels, not 254.

Priority 0: Do not, not ever. A hypothetical priority level that probably doesn't need to exist, just turn a station off.
Priority 255: Player command. Ignore all other tasks on the network and make it happen.
These are not true priorities but more like player overrides that automation wouldn't have access to. If automation did get a hold of them, they wouldn't be player overrides any more.

You can reduce limits/turn stops off to make your own priority system. But then that just means the player has to implement their own priority system with combinators and add a global circuit circuit network. Then the player has to gradually enable stops according to the priorities to force trains into high priority stops first. With 256 priority levels this takes several seconds to roll through all priority levels (but this very naive approach doesn't work, more on that later), and one such contraption is needed for every unique stop name. This isn't just beyond your capacity (unless you are admitting to trolling), it's beyond most players capacity.

Also, having more priority levels is useful. If you have 3 priority levels for 3 stops (each with limit 1) and 2 trains, the trains will serve the top 2 stops and ignore the lowest. This is one of reasons you can't just disable any stop that doesn't have top priority. And if you later add a 3rd train all three will be served, so disabling stops would give a vastly different result. Even constant priority here gives flexible results that adapts to the amount of available trains. And interrupts are one such feature which takes trains on/off a schedule dynamically. If you have 3 trains, but suddenly one takes a refueling break, then that is effectively one train out of commission and the other two trains will behave just like before you added the 3rd train, again ignoring the bottom priority.

Average Players... don't really care about this. They want a train system that just works. If they're tweaking values that aren't part of a circuit network, there is some level of expectation that it won't immediately break their trains. Advanced stuff, breakable stuff, clever stuff, that belongs in circuit networks. Normal UI stuff, things that anyone can play with, it should just work and not be too much hassle.

And disabling train stops is not enough either to implement priority manually, since priority is not just used for selected destinations, but also for which train to allow to leave from stops with low or high priority. And for that you need circuit conditions in the schedule to stop trains from attempting to leave conditionally on your own priority system.

To loop through all exit priorities and then all arrival priorities 2^8 x 2^8 = 2^16 = 65536 ticks, or more than 18 minutes for all combinations, if done optimally and all priority levels utilized (or without data and without assumptions). This is because if you have try the same priority for both exit and arrival priority then you only really check for the highest of either. If you had a 40 priority destination and a 50 and a 60 priority for stops with trains trying to go to the destination, then you wouldn't be stopping either train when the "test" priority level sinks to 40 where the first destination opens.

This is really starting to sound more like 2 flavors of priority. The first priority is stations who want trains, and the second is stations who want to get rid of trains. That actually... might be a good idea.

An ore stop might want more trains on its schedule because it keeps filling up. That's a reasonable priority request. But there are also stations that the player wants to run at high throughput. The priority is not on summoning trains- they're always busy- but rather the priority is to get rid of their trains as quickly as possible. At the same time a player doesn't want to wait 5 minutes for a taxi because the frontier mining train has +1 more importance than the -1 train which is 5 seconds away. Summoning a train from the frontier is not important, even if that train has a high demand for more ore hauling.

Of course, exit priority is something that parking lots DO solve and they solve pretty well. When a train goes idle it can find a parking lot, it seems to be a very doable part of the scheduling system. I'm not quite convinced that exit priority is an essential thing.

So instead you would have a computer ask all stops what their priorities are and if they want to send a train or receive one. And then you separately find highest exit and arrival priority, and then only allow those, and then repeat this process. This requires that you implement some form of communication protocol that can answer the question of which stop has the highest priority for each type of stop name and train status (arrival/exit). This could be made to solve which stop to enable and train to exit in under a second. I have made similar systems before.

The built in priority system can do all this in a within a single tick for all trains at once, with no information sent via circuits at all, no configuration for matching signal types to stop names, and trivial for the player to use. It's vastly different.

Very compelling points, but I don't think you're going to win this argument, and this is why:
Factorio favors robust systems. The priority system you describe is not robust. It is an amputation system that operates via breaking train stops at the slightest provocation. Consider someone who gets tired from lifting weights, so their feet fall off. That sort of system is not robust.
Players are meant to fly off world and have their systems at home work... reasonably well. If a single numerical change has so much power to shatter the train network, then it is not working reasonably well.

Now, you might have an argument that an extremely complex, heavily modded train network could break if trains do not perform their tasks in a very specific, particular sequence. It's certainly a complicated scenario that can exist. A priority system can't really deal with that, no matter how hard or soft it is. High priority breaks the sequence, and low priority breaks the sequence all the same. A very specific train sequence is a job for circuit networks.

It really does not take much foresight to see how priority systems will play out on the factorio forums.

-Why doesn't my train system work?
- Did you set sensible priorities?
- Uh, yes, I set 51 and 49 for things
- Those are not sensible values. Please follow this simple guide to handling train priority: <Error: character limit exceeded, post 1/578>
- Oh wow, what a helpful and insightful community! *never touches it again*

Enjoy seeing this thread repeat itself every month.

Of coruse, a soft priority system can already perform hard priorities. Set low priority to 1 and high priority to 254. Ta daa, you now amputate the network to attend to the essentials.

Edit: Anyway, I think it'd be better to describe soft priority as scheduling, rather than priority. Operating systems have to deal with scheduling as part of their core function; simply abandoning a process completely breaks that process. True priority is something that is very rarely needed in factorio, and it shows that train networks have been very robust despite not having a hard priority system over the years. If trains are moving, and if trains are taking pretty efficient routes, then the network is working well enough. What is important is scheduling how much effort to place into various parts of the train network, who needs trains NOW, and who can wait for them. Good luck describing the scenario where an active train stop never wants to be serviced by trains because its neighbor is slightly more important. If a train stop doesn't want to be used, it gets turned off.

Edit2: Solving a scheduling puzzle with hard priority is very much like trying to work a square-slot screw with a Philips-head screwdriver. It works, kinda, it can get the job done. But it never feels right and you always wonder if there is a better tool for the job.

[argbla]

I have to say, although I've liked playing Factorio off and on for the last 5 to 10 years or so, I don't think I'll be buying the new DLC.
This game has become way too complicated. All the changes I see here are just for a very small amount of people who have a massive factory and understand how trains, train signals, bots, logic units etc work. I wish they would make the game bigger without a level of complexity where it takes ever more time figuring out HOW things work, rather then actually playing the game to make things work.

Maybe it's just me, so happy gaming to all the aficionados who have the time and patience to figure out how everything works.

I understand your pain, brother. When I was told I could be anything I wanted, I decided to be the first rocket scientist to become president of the world. But, it just doesn't seem to be in the cards anymore.

There I was, the industrial military complex in one hand, and pharmaceutical mega-conglomerate in the other, when I found this factory building game. I became addicted, and my plans fell by the wayside. I kept telling myself I'd pick up the pieces starting tomorrow, but tomorrow was always another day away. Before I knew it, a mysterious man going by the name "Kovarex" had bought me out of my holdings! Now the fate of the world seems to be in his hands. Alas, the factory must grow.

[morsk]

I will use priority so malls and power-related builds aren't starved of resources. And it will be nice to adjust module production as sometimes above science, sometimes below.

[argbla]

I have to say, although I've liked playing Factorio off and on for the last 5 to 10 years or so, I don't think I'll be buying the new DLC.
This game has become way too complicated. All the changes I see here are just for a very small amount of people who have a massive factory and understand how trains, train signals, bots, logic units etc work. I wish they would make the game bigger without a level of complexity where it takes ever more time figuring out HOW things work, rather then actually playing the game to make things work.

Maybe it's just me, so happy gaming to all the aficionados who have the time and patience to figure out how everything works.

But actually, don't allow comparing yourself to others rob you of the enjoyment of puzzling things for yourself. The joy of curiosity is in how much we do not comprehend. I'm sure your thinking is along the lines of "no matter how hard I try, I'll never have this all figured out". Thankfully, you don't need to figure it all out! It's just game. Move at your own pace and maybe you will surprise yourself. In truth, the rest of us are in the process of mastery as well.

The modern world places us in a horrible position where we are made to compare ourselves as individuals to all others. A great game of all vs all, disguised by notions of equality and fairness, even meritocracy. Turns out none of those things are as important as loyalty, as being a part of a coherent whole, capable of valuing you for who you are at a more fundamental level than raw utility. Nothing that lasts is accomplished alone, yet here we are asked to pretend this atomization is virtuous, so long as it is in service of the secular, and awfully selective, god of tolerance. Curious, isn't it?

Anyway, the factory must grow.

[Qon]

It causes no problems, because if you don't use it then it has no effect. For those that understand it it can be a convenient way to fine tune the workings of the factory. You are allowed to see the system as beyond your mental capacities and pass on using it if it would cause you more problems than it solves. It's good to know your limits.

"Don't use it" is not a compelling argument for a system. It is a compelling argument against a system, in fact it is the best argument against a system that can possibly exist. Don't defend a system by telling people they shouldn't use it, you're playing for the wrong side.

I'm not saying the system shouldn't be used. I'm saying that people who can't fathom its uses and are unwilling to learn how to use it shouldn't use it. You said it was causing more problems than it solves. Well if you use it incorrectly to cause more problem than it solves, then you shouldn't use it (incorrectly). Either learn how to use it or don't use it. Any tool can be used incorrectly to cause more problem than it solves. That doesn't mean that the tool is bad and suggestions to stop hitting your thumb with the hammer isn't an argument against the existence of hammers as a tool.

And it sure sounds like you are planning to hit your thumb with the hammer (hard priority) because it doesn't work like glue (soft priority).

They need to split their attention in every direction, and provide fair access to all the stations under their wing.

Wrong, and contradicted by FFF #395. Read it.

FFF #395 states that trains can now operate in a very general purpose mode that services an entire system. That's exactly the kind of complex network that priority systems are meant to help organize. These are very powerful tools with a lot of responsibilities to deal with, and that's exciting. It's also a system that needs to be well protected against breaking, or players will be flying between planets all the time trying to diagnose and fix them.

However with generic schedules and 'One big bag of trains', it can happen that all the trains are busy moving around advanced products and nothing is there to direct trains to the mining outposts, especially as the mining outposts are normally far away on the periphery of the base.

Your soft system is more likely to break in a catastrophic way. If you don't have enough trains to service both high and low priority stops, then the factory should stop low priority tasks and go into survival mode. If I don't have enough trains for all stops, I prefer that trains do high priority tasks like transporting fuel to my power plant instead of trying to also supply labs with science packs and neglecting the power further. I rather have no science production for a while so that I can add more trains when my attention turns back to my mismanaged planet, instead of finding that the entire planet is lost because the few trains that could barely keep the factory power going wanted to go sightseeing and do some relaxation with low priority tasks.

Priority is meant to avoid "fairness". Fair access for all is the opposite of a priority system.

Currently there are very powerful tools to help organize train networks. Stop limits, parking lots, and interrupts all look like they will solve many problems down the line. Priority doesn't look like a problem solver. It looks like a problem maker.

There are many other colony management type games that incorporate hard priority systems, and they tend to work out very poorly. That's because colony games have a wide general purpose priority system, filled with many life threating priorities. A colony can not drop anything and everything to perform a +1 task, because neglecting the lesser jobs threatens the life of the colony. Generic train jobs are fulfilling a very similar function. Everything under their umbrella is important, and abandoning any one role is the same as neglecting an essential life support task. Some tasks are more important than others, but they're not SO much more important to amputate everything else. They just need a little push in the right direction, a little bit more time on the schedule, a little less odd jobs and a little bit more critical jobs to keep things running smoothly. That's the kind of priority a generic train needs to work with.

If you plan to use priority incorrectly...

Higher priority stops with limits that reduce to 0 when the amount buffered is enough to last a while will naturally let lower priority tasks get trains assigned to them. But if you don't have enough trains to get the throughput required to ever catch up with the demands of all tasks, scheduling tasks "fairly" so that lower priority tasks aren't completely neglected just means you death spiral faster. The issue is lack of trains, and a priority system can't completely solve the issue of too few trains. But it can at least choose correctly to neglect that which isn't necessary for immediate survival. Sounds like you used the priority system wrong in the other colony survival games as well then.

There is no point in having 254 priority levels, if a +1 priority deletes all the stations beneath it. You may as well turn stations on or off, it does the same thing.

Wrong.
First, It's 256 priority levels, not 254.

Priority 0: Do not, not ever. A hypothetical priority level that probably doesn't need to exist, just turn a station off.
Priority 255: Player command. Ignore all other tasks on the network and make it happen.
These are not true priorities but more like player overrides that automation wouldn't have access to. If automation did get a hold of them, they wouldn't be player overrides any more.

Just admit that you are wrong. This is just embarrassing for you. Even if you plan on not using 0 and 255 with circuits the priority levels still exist. And if 0 and 255 aren't used then now the priority levels 1 and 254 are the lowest and highest available. Same argument can be used to not use these either in that case. And so on.

And priority 0 is not the same thing as turning it off, it is just lower than 1. It has no special meaning, unlike 255. There's no point in avoiding 0, even if I could agree that it can make sense in some situations to reserve 255 for manual interactions.

You can reduce limits/turn stops off to make your own priority system. But then that just means the player has to implement their own priority system with combinators and add a global circuit circuit network. Then the player has to gradually enable stops according to the priorities to force trains into high priority stops first. With 256 priority levels this takes several seconds to roll through all priority levels (but this very naive approach doesn't work, more on that later), and one such contraption is needed for every unique stop name. This isn't just beyond your capacity (unless you are admitting to trolling), it's beyond most players capacity.

Also, having more priority levels is useful. If you have 3 priority levels for 3 stops (each with limit 1) and 2 trains, the trains will serve the top 2 stops and ignore the lowest. This is one of reasons you can't just disable any stop that doesn't have top priority. And if you later add a 3rd train all three will be served, so disabling stops would give a vastly different result. Even constant priority here gives flexible results that adapts to the amount of available trains. And interrupts are one such feature which takes trains on/off a schedule dynamically. If you have 3 trains, but suddenly one takes a refueling break, then that is effectively one train out of commission and the other two trains will behave just like before you added the 3rd train, again ignoring the bottom priority.

Average Players... don't really care about this. They want a train system that just works. If they're tweaking values that aren't part of a circuit network, there is some level of expectation that it won't immediately break their trains. Advanced stuff, breakable stuff, clever stuff, that belongs in circuit networks. Normal UI stuff, things that anyone can play with, it should just work and not be too much hassle.

Priority system doesn't "immediately break their trains". You can break trains by giving them all the same schedule and not allocating any train to some stops already. It still sounds like you are trying to use priority system incorrectly, with limit 1000 on the highest priority stops or just a single train to service all stops or something else ridiculus and then blame priority for not automagically fixing your glaring issues regardless of how you configure priority values or enything else. "It should just work": Worst idea ever, take some responsibility for what you create. It should be possible to fail, otherwise it is not a task worth playing with. A tool that can't be used incorrectly is not a tool because it has no power to achieve anything, the thing is then irrelevant. A game you can't play incorrectly is not a game, it's just a video.

And disabling train stops is not enough either to implement priority manually, since priority is not just used for selected destinations, but also for which train to allow to leave from stops with low or high priority. And for that you need circuit conditions in the schedule to stop trains from attempting to leave conditionally on your own priority system.

To loop through all exit priorities and then all arrival priorities 2^8 x 2^8 = 2^16 = 65536 ticks, or more than 18 minutes for all combinations, if done optimally and all priority levels utilized (or without data and without assumptions). This is because if you have try the same priority for both exit and arrival priority then you only really check for the highest of either. If you had a 40 priority destination and a 50 and a 60 priority for stops with trains trying to go to the destination, then you wouldn't be stopping either train when the "test" priority level sinks to 40 where the first destination opens.

This is really starting to sound more like 2 flavors of priority. The first priority is stations who want trains, and the second is stations who want to get rid of trains. That actually... might be a good idea.

An ore stop might want more trains on its schedule because it keeps filling up. That's a reasonable priority request. But there are also stations that the player wants to run at high throughput. The priority is not on summoning trains- they're always busy- but rather the priority is to get rid of their trains as quickly as possible. At the same time a player doesn't want to wait 5 minutes for a taxi because the frontier mining train has +1 more importance than the -1 train which is 5 seconds away. Summoning a train from the frontier is not important, even if that train has a high demand for more ore hauling.

Of course, exit priority is something that parking lots DO solve and they solve pretty well. When a train goes idle it can find a parking lot, it seems to be a very doable part of the scheduling system. I'm not quite convinced that exit priority is an essential thing.

This is the 3rd time I'm saying this, exit priority is a thing already. I've said it to you before:

Quick question about the priority system. Are they soft priorities, such that X task is given some kind of bonus multiplier to its priority? Or are they hard priorities, such that do all 51s first, then do all 50's next, then do all 49's next, etc.?

The way it works, is that the priority of a train stop has two effects:

1. When searching for a destination, trains will prefer a higher priority train stop.
2. When trains are trying to leave a stop, trains at stops with higher priority are dispatched first.

So instead you would have a computer ask all stops what their priorities are and if they want to send a train or receive one. And then you separately find highest exit and arrival priority, and then only allow those, and then repeat this process. This requires that you implement some form of communication protocol that can answer the question of which stop has the highest priority for each type of stop name and train status (arrival/exit). This could be made to solve which stop to enable and train to exit in under a second. I have made similar systems before.

The built in priority system can do all this in a within a single tick for all trains at once, with no information sent via circuits at all, no configuration for matching signal types to stop names, and trivial for the player to use. It's vastly different.

Very compelling points, but I don't think you're going to win this argument, and this is why:

The priority system by Wube isn't fragile, your argumentation is.

Factorio favors robust systems. The priority system you describe is not robust. It is an amputation system that operates via breaking train stops at the slightest provocation. Consider someone who gets tired from lifting weights, so their feet fall off. That sort of system is not robust.
Players are meant to fly off world and have their systems at home work... reasonably well. If a single numerical change has so much power to shatter the train network, then it is not working reasonably well.

Now, you might have an argument that an extremely complex, heavily modded train network could break if trains do not perform their tasks in a very specific, particular sequence. It's certainly a complicated scenario that can exist. A priority system can't really deal with that, no matter how hard or soft it is. High priority breaks the sequence, and low priority breaks the sequence all the same. A very specific train sequence is a job for circuit networks.

You only have to turn stops off if they can't receive or provide enough to unload/fill a train for high priority stops to let go of trains and allow low priority tasks to be completed as well. And the low priority tasks will get as many trains as the high priority stops can afford to not use. Or set some train limit to less than infinity and don't have an absurdly low amount of trains and you won't even have to do disable stops.

It really does not take much foresight to see how priority systems will play out on the factorio forums.

I'm living it right now.

Of coruse, a soft priority system can already perform hard priorities. Set low priority to 1 and high priority to 254. Ta daa, you now amputate the network to attend to the essentials.

Then you have 2 priority levels and are back at implementing your own priority system with combinators if you want more levels, so that you can dynamically flip stops between low/high like I described before, instead of off/on.

Good luck describing the scenario where an active train stop never wants to be serviced by trains because its neighbor is slightly more important. If a train stop doesn't want to be used, it gets turned off.

It's not that the lower priority stop should never be visited. It's that it should never be visited when the higher priority stop can fulfill the same thing.

A reason was already provided in the blog post:

Another motivation here was the situation of decommissioning old stations. We want the trains already at the stop to "Get out of here", but often times they would just sit and go "Well my destination is full".

You don't want to turn off your all your shiny new mines. The old mine with just a trickle of product should get higher priority but be turned off when there's not enough to fill a new train. Turning off all the high throughput mines cripples your factory completely since now the one slow mine needs to supply all of the ore by itself. And turning off a stop when it is not ready to fulfill a train load/unload is a local and simple decision. Turning off stops because other stops have higher priority requires data about other stops on the surface, and it is again a very complicated reimplementation of the priority system by Wube, but with combinators.

Priority to the slow old mine means that trains can take ore from both the old and the new mines so that you have enough ore coming in to your base, while still making sure the old and slow mine isn't neglected.

[Aapjuh]

Nice!

Probably going to use a train limit based on missing content with a circuit clock per station that counts upward increasing priority for that station overtime (say prio 1-100, or 1-100 for low and 50-150 for high prio stations).

[EvanT]

The generic item parameter is such an elegant way of simplifying the orders. Though as with the last time you've shown this, there's still 1 issue: Trains are dispatched based on what is available to pick up, not based on what is needed to be dropped off. It'd be cool if we could somehow create something like this. That would complete the train rework for me. But this is already damn good.

If you have a general circuit network along all the stations you can put the number of available and needed trainloads on it.
e.g. All Iron mining has a total of 10 trainloads, all smelting needs 8 trainloads to be full. So in total there are 2 trainloads in the system.
If you do that for all the station you have a useful indicator what is really needed (the item with the lowest trainload count, especially if the number becomes negative (more needed than is available))
If you transmit that network to the train you should be able to configure the interrupts so the train goes to the station which product is needed the most.

Or a lot simpler: set the station priority according to the the number of needed trainloads.

[Svip]

It seems to be that Qon and bobucles are talking past each other, not particularly well at describing what the priority system does.

So let's chalk up some scenarios.

Scenario 1:
Train stations A and B (there are no other stations named A and B).
We have train 1 that travels between these two stations.

In this scenario, changing the priority of either station (from 0 to 255) has no impact, since there are no other choice. Changing the train limit to 0 (disabling) of either station will cause the train to sleep.

Scenario 2:
Train stations A and two B (we call them B1 and B2 for clarity). B2 is further away than B1.
We have train 1 that travels between these two stations.

In this scenario, train 1 will always prefer B1, since it is closer. But changing B2 to a higher priority than B1's, now only B2 will get serviced.

Scenario 3:
Same as scenario 2 but with 3 trains.

In this scenario, trains 1, 2 and 3 will always prefer B1, since it is closer. If we - like above - change B2's priority to higher than B1's priority, only B2 will get serviced. However, if we change the train limit of B2 to 2, trains 1 and 2 will service B2 while train 3 will service B1 (despite having no train limit).

When they write "prefer" stations with higher priority, they only mean in scenarios that don't have other restrictions (such as train limits or no paths). Scenario 3 could also have been solved with train limits alone (giving B1 a train limit of 1), but once your base has hundreds if not thousands of train stops, train limits becomes harder to reason about, and priorities become a nice simply blunt instrument to override the default calculations where necessary.

[Fiorra]

In this scenario, trains 1, 2 and 3 will always prefer B1, since it is closer.

Distance isn't calculated based on rail length alone, see https://wiki.factorio.com/Railway/Train_path_finding

When there are trains waiting at B1, there's a penalty added to the distance to B1, and the next train may prefer B2. The only way to keep this builtin balancing is to leave the priorities alone. The better optimization is to set queue limits dynamically based on buffers, to guarantee that trains don't arrive at empty chests.

I imagine the most common use for priorities is in mods where we prefer to grab ores from infinite sources (e.g. core miners) over ore patches, or prefer to take items from byproducts over dedicated production - fixed priorities are much more intuitive than placing empty stops along the way to mess with the pathfinding.

There may be some value in dynamically setting the priority based on the local buffers, the trains en route and maybe other factors. I'm sure people will come up with smart (and slightly overengineered) circuitry to make use of that.

Or maybe there's an upcoming SA mechanic where it's useful. We'll see.

[picklock]

I will use the new priority system of the train stops controlled via circuits to balance my train stops to the smelters. Balancing will be much easier for me with the new priorities at the train stops.

[Trific]

A hard priority system follows the orders of the player. A soft priority system is a system which by definition will ignore the players intended behavior. Just set your priorities correctly and dynamically if fixed priorities is not aligned with your intended behavior.

So what you're saying, is that priority is a useless system that causes more problems than it solves.
Interrupts already handle hard priority tasks. If X is needed, the train stops what it's doing and does X. That's exactly when a player needs hard priority.
Trains doing everyday tasks don't need that. They need to split their attention in every direction, and provide fair access to all the stations under their wing. There is no point in having 254 priority levels, if a +1 priority deletes all the stations beneath it. You may as well turn stations on or off, it does the same thing.

I expect it will be like it is with train limits. If you have a bunch of priority 50 stations, and bump one up to 51, then trains will be allocated to the 51 station until its train limit is reached, and then further available trains will continue to be allocated to priority 50 stations.

I don't see how interrupts handle hard priority tasks between stations of the same name.