Qon wrote: ↑Sun Jan 28, 2024 6:31 pm
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.
Qon wrote: ↑Sun Jan 28, 2024 6:31 pm
bobucles wrote: ↑Sun Jan 28, 2024 4:13 pm
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.
Qon wrote: ↑Sun Jan 28, 2024 6:31 pm
bobucles wrote: ↑Sun Jan 28, 2024 4:13 pm
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.
Qon wrote: ↑Sun Jan 28, 2024 6:31 pm
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.
Qon wrote: ↑Sun Jan 28, 2024 6:31 pm
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.
Qon wrote: ↑Sun Jan 28, 2024 6:31 pm
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.