Friday Facts #395 - Generic interrupts and Train stop priority

[Qon]

Could there be a case where you need different priority for incomming and outgoing trains? If so, I guess it can be done via circuitery, but a separate slider would be much easier.

For a train to arrive you need a train to leave first if it's taken. If priority is lower to leave then trains will be stuck and effectively also lowering the input priority to the same. And if priority is higher to leave, then you are freeing up space for a train to arrive to a stop with low priority while trapping trains in other "actual" high priority stops. I don't see how this makes any sense to request. And you don't seem to see any point to it either so why request it if you have no use case?

[FunMaker]

Looks great! Loving this one. What i do not like, is, that the naming of train stations is bound to the product. In my games (with LTN) i name the stations after that, that is produced there and not which item drops there. This way i know where i have to go where a problem is. If error message state "Iron Plates Drop Off" this could be one in a million... But that is okay.

What bothers me a bit more (and that is till FFF#389) that you have do have one drop-off-station per product.

My Suggestion: Make it possible to use multiple names on one station (or name it "tags" of a station). Example:

Assume there are 2 Drop off stations:

Code: Select all

[1] with Tags
--- Iron Plate Drop Off
--- Copper Plate Drop Off
[2] with Tags
--- Iron Plate Drop Off
--- Coal Drop Off

Now assume a train that picks up Iron Plates:

1. Train has Iron-Plates and looks for all stations that have the tag "Iron Plate Drop Off"
2. Both stations are viable because they have the tag "Iron Plate Drop Off"

Now if a train picks up Coal:

1. Train has Coal and looks for all stations that have the tag "Coal Drop Off"
2. Only station 2 is a viable target, because station 1 does not have the tag

Additional: This way you could name stations like whatever you want, because the tags are used for target-matching and the names do not bother anymore.

Excuse me for not considering every consequence of my suggestion this but building stations dedicated to one product is such a bummer for me, that i had just to write down the first idea to conquer this problem.

[Tomplus]

Will it be possible to change the priority of a train stop from the circuit network?

ie. if the warehouse capacity level is at an defined level, we increase the priority, and if it changes, we decrease it.

[kwyntes]

So in 2.0, disabled trains stops will act as if they have 'Train limit = 0':

I'm not yet convinced that the new cool interrupt features allow us to completely control trains with circuits. The interrupts and the generic signals are very cool, but with generic signals only being able to take the signal type from inventory and not from combinators we can't tell trains where to go. And just signal type isn't enough, we would need a number that could be used to identify the station. Just type can't be programmed for arbitrary amounts of stops. This alone wouldn't be give us the power to completely control pathing, but we would be able to explicitly control what stop to go to at least.

This. Unless we name every station manually and add an interrupt for it, this system is still pretty much static.

Sure, this system works for basic resource distribution, but not for anything more advanced than that. We'd still need complex circuit-controlled intersections for proper generic mixed cargo systems for example.

And even with a way to route trains to stops dynamically, we might still need to design a whole central scheduling computer with combinator hashtables and whatnot, so it's not exactly making the game too easy either.

[tangent]

train blueprints set to auto has me wanting to build a train depot that deconstructs empty trains and builds/deploys them when needed.

[Phredward]

I'm wondering if there's a way to have an error handling train station. Add something to the schedule that indicates "if no path, try to go to station X as a last resort".

[FuryoftheStars]

Hopefully interrupts will fill the role of stop skipping? That was the one good thing of being able to disable the stations.

---------------------------------

I never used icons in stop names, making that a necessity sounds like a terrible idea

Same. Perhaps they'll do it by icon and localized name?

[Shuisman]

I never used icons in stop names, making that a necessity sounds like a terrible idea

I think this is needed because in multiplayer one player could in Spanish and the other in English. So 'iron' would then not work in e.g. Spanish… icons prevents this entire problem.

[Kadet123]

So in 2.0, disabled trains stops will act as if they have 'Train limit = 0':

I'm not yet convinced that the new cool interrupt features allow us to completely control trains with circuits. The interrupts and the generic signals are very cool, but with generic signals only being able to take the signal type from inventory and not from combinators we can't tell trains where to go. And just signal type isn't enough, we would need a number that could be used to identify the station. Just type can't be programmed for arbitrary amounts of stops. This alone wouldn't be give us the power to completely control pathing, but we would be able to explicitly control what stop to go to at least.

This. Unless we name every station manually and add an interrupt for it, this system is still pretty much static.

Sure, this system works for basic resource distribution, but not for anything more advanced than that. We'd still need complex circuit-controlled intersections for proper generic mixed cargo systems for example.

And even with a way to route trains to stops dynamically, we might still need to design a whole central scheduling computer with combinator hashtables and whatnot, so it's not exactly making the game too easy either.

So, you want to explicitly control exactly which station each train goes to? I'm having a hard time understanding why you'd want this. Wouldn't you rather not have to implement that level of detail, and let the base automate itself?

Even going as far as to say you want to explicitly control the pathing? Why? I mean, if you want to, you can technically already control a trains pathing by hooking the rail signals to circuit networks, and controlling which paths are available. I'm curious what advantage this would have.

[Ghulmeister]

these are all very good and important quality of life improvements. i am as always in awe at the dedication of the factorio devs.
somehow i get the feeling that factory-like genres tend to be run by a lot more passionate devs than any other genre that i have seen so far.
maybe because they are not "ez money" grabs, maybe because most of the factory-likes are being made by indie-devs, maybe because this genre is very niche... or maybe everything together.

anyways, i am currently looking forward to what you have in store for the combat-side of space age. the current enemies are fine, up the the point where they reach "peak" evolution. after that they stop becoming stronger and then just turn into "fodder". i hope space age will bring some post "peak"-evolution for our bitey friends.

[SupplyDepoo]

Everything here looks great, except the outright removal of train stop skipping. This, and the previous train FFFs have given me the impression that there is a push for a One True Way to play with trains: the megabase style with many same-named train stops. The more casual kind of train gameplay, with bespoke schedules, is taking a backseat and I don't know if it's intentional.

I think the game is more interesting when there are more varied strategies to play with (not just for combat, which everyone already agrees benefits from variety), and train stop skipping provided some neat solutions which it seems will mostly be erased from the game in favor of the One True Way.

Furthermore, the reasoning given for removing this feature does not feel justified, especially in light of these new changes just unveiled for 2.0. If players were using the train stop skipping as a tool to prioritize train stops, then in 2.0 they will switch to using the new priority system, and the issue of stuck trains will occur far less. So this feature removal is addressing a problem that is already addressed by the new priority feature. Removing the train stop skipping feature doesn't seem excessive to me.

The new train alerts will also make the problem less punishing anyway, because you will know about it faster and be able to fix it before it causes a chain of failures.

Devs, for your next playtesting sessions, please reinstate the train stop skipping logic just to see if the issue even occurs anymore, and if it doesn't, please leave it in the game. People who like to experiment with different play styles and who enjoy more casual-sized factories and not necessarily aiming for 10kspm, will appreciate it.

[SupplyDepoo]

Hopefully interrupts will fill the role of stop skipping? That was the one good thing of being able to disable the stations.

It works differently though. Interrupts is train-side logic, and the current skipping feature is train-stop-side logic. Not every usage of stop skipping can be replaced by interrupts.

[DucaDiMonteSberna]

Do the notification also jump you to the correct planet?

[POPISowyNumer]

I still think incorporating LTN into 2.0 would be cleaner approach

[Premu]

Everything here looks great, except the outright removal of train stop skipping. This, and the previous train FFFs have given me the impression that there is a push for a One True Way to play with trains: the megabase style with many same-named train stops. The more casual kind of train gameplay, with bespoke schedules, is taking a backseat and I don't know if it's intentional.

You still can use simple train setups with dedicated stops for dedicated train lines. You're not forced to use all these features, and for the first trains to setup it's likely not worth it. It's just once you get big you have the option to set up a far more efficient train system than before.

Furthermore, the reasoning given for removing this feature does not feel justified, especially in light of these new changes just unveiled for 2.0. If players were using the train stop skipping as a tool to prioritize train stops, then in 2.0 they will switch to using the new priority system, and the issue of stuck trains will occur far less. So this feature removal is addressing a problem that is already addressed by the new priority feature. Removing the train stop skipping feature doesn't seem excessive to me.

Priorities are a powerful tool, but they are complicated and need some good concept for anyone setting these up, especially in mega bases. So again offering a simpler less powerful and a more complex, more powerful alternatives is a good decision in my opinion.

[Fiorra]

That'd involve having to wire up every single station to the circuit network. Doable, but tedious.

That can be as simple as adding wires to a set of blueprints.

Also how do you plan to turn off the station when a train leaves the depot? I haven't seen the ability to do something based on trains inbound to a station.

Train stops provide everything you need for that, in 1.1.

Dedicated trains in an age of full on generalisation sounds inefficient.

Generalized trains are supposed to be simpler, not more efficient. Dedicated trains can reduce travel time, congestion, and improve fairness.

Look, a good game system is supposed to provide a reasonable and working baseline, but it's also supposed to leave room for optimizations and interactions for people who enjoy that. There's a reasonable tradeoff between a fully generalized system (easy to set up, but not optimized) and other solutions (more work, better trains). The easy solution isn't supposed to be the best.

The 1.0 system had unsolvable problems with fairness and stampede that lead to frustration. The 1.1 system gave us the tools to solve them, and now we have reliable setups for dedicated trains, 1:N, N:1 or N:N. The 2.0 system adds even more tools, and soon we'll have reliable generic trains.

I'm excited about interrupts not because they're a ready-made solution, but because they're a flexible tool to help me implement my own solutions. The new tools enable solutions that weren't possible before. Will I use generic trains? Probably not. Will I use interrupts? Probably yes.

You aren't asking for tools, you're asking for ready-made solutions to your specific preferences, and I don't think that's good game design. You already have the tools to do everything you ask for, both in 2.0 vanilla and in the mod portal. If there's something that the tools don't cover, that'd be interesting to know.

I never used icons in stop names, making that a necessity sounds like a terrible idea

That's about as necessary as it was before this FFF: not at all. Anything that can be done using generic interrupts can be done without them. Pretend that the "Any item" signal doesn't exist and you'll be fine.

But if you want generic interrupts, then predictable station names are the price you have to pay. And icons are the only language agnostic way to do so. For a feature that is entirely optional, I think that's an acceptable restriction.

I'm not yet convinced that the new cool interrupt features allow us to completely control trains with circuits. The interrupts and the generic signals are very cool, but with generic signals only being able to take the signal type from inventory and not from combinators we can't tell trains where to go.

We know that interrupts can read signals from the station the interrupted train is parked at, and this FFF mentions an "any signal" signal for the condition. You can totally make a train go to station "[A]" by sending the [A] signal to its train stop. If you run out of signals, you can start naming your stations "[A] 1", "[ B] 1", "[A] 2", etc, with the downside that you'll have to duplicate the interrupt for any number you use (unless they add a replacement for the signal's value).

But maybe then you're reaching a point where your bespoke train scheduling is better implemented using the lua interface

Everything here looks great, except the outright removal of train stop skipping.

To me, skipping disabled stations always looked like a mistake that was fixed by queue limits, but kept around for no other reason than backward compatibility. Queue limits solve every problem I've encountered in a better way than disabling did, and I'm glad they're matching the disabling behavior to the queue limit behavior.

In your post, you've skipped over an important question: which kind of setup actually needs the old skipping behavior? If you have a use case, one that isn't solvable via queue limits or interrupts, please do tell.

[gGeorg]

Can you add wildcard 'Any item' signal into regular combinator selection options ?
Reason: it is handy filter how to recognize/split virtual signals or a specific group.

Same for for 'Any Fluid', 'Any Fuel' and 'Any Signal'

Thanks.

[mmmPI]

I was already having trouble to picture the extend of the possibilities with the interrupts, at this point i have to say i'm completly lost, priorities and wild card item ? those are too much goodies for me to keep in mind without having some game experience to support it, (interactions with logistic group and filter combinator leads to imagination overflow). I'm enjoying it, it really feel like there are some things to discover, i don't mind having to learn how to do trains all over again with what feel like a whole new system that has much more possibilities, that feel the effort are worths it , not like a regression because it's difficult to do things that were easier before.

I like the little things that i can understand, like the alerts on different surfaces, the train in automatic after blueprintint and the icon change, it makes me confident that the system will have some attention to details , same when reading you already played with the new system and added some little touch to adress your immediate feedback.

I disagree with the fact that it was janky before, it was already very good, this is just being perfectionnist, i'm not complaining about it, just disagreeing !

I hope because i'm not sure that the new system will be easier for people to use and not get unexpected results, it's hard to tell because the old one seems very familiar to me and i expect to mess up a lot with the new one at first, on the other hand i have no doubt there is more depth in the newer system

[Kadet123]

So in 2.0, we changed it so that these states are shown to the player with an icon drawn over the locomotive, and we added the train status to the GUI and tooltip.

I'm assuming "the locomotive" means the primary locomotive the train gets it's name from. But if it's a double ended train, like a 1-4-1 setup, that locomotive might be offscreen when you're at the station diagnosing issues.

I'd like to recommend drawing the 'no path' and 'destination full' icons on each locomotive, if that's not the case already.

[SupplyDepoo]

You still can use simple train setups with dedicated stops for dedicated train lines. You're not forced to use all these features, and for the first trains to setup it's likely not worth it. It's just once you get big you have the option to set up a far more efficient train system than before.

Priorities are a powerful tool, but they are complicated and need some good concept for anyone setting these up, especially in mega bases. So again offering a simpler less powerful and a more complex, more powerful alternatives is a good decision in my opinion.

We're still going to have overall less strategic variety than if the train stop skipping was kept. There is literally nothing gained by its removal, as it says "disabled trains stops will act as if they have 'Train limit = 0'" so you can just set train limit to 0 if you want that, and leave station skipping for those who like it.

Right now we have basically two different paradigms:

1. simple schedules with unique stations, very easy to grasp
2. same name station schedule with station limits, easier to manage at large scale

There are different tricks for both of these to make them more efficient or more versatile. Station skipping is one of those things that gives depth and some extra challenge to both paradigms.

The new 2.0 stuff is just buffing the large scale megabaser play style so they don't even need to use the supposedly error-prone station skipping to create some kind of priority, while the more casual players are robbed of a cool mechanic and told to just use the new tools instead which will be much clunkier.

It's hard not to see this as something to funnel everyone into the same play style.

To me, skipping disabled stations always looked like a mistake that was fixed by queue limits, but kept around for no other reason than backward compatibility. Queue limits solve every problem I've encountered in a better way than disabling did, and I'm glad they're matching the disabling behavior to the queue limit behavior.

Good. If you don't need station skipping (especially when 2.0 drops), what's it to you if the feature was kept as an option?

In your post, you've skipped over an important question: which kind of setup actually needs the old skipping behavior? If you have a use case, one that isn't solvable via queue limits or interrupts, please do tell.

I'm not sure right now, but there will definitely be some things that just can't be done without stations being able to divert trains mid-journey (regardless of other stations).

It's just an unnecessary removal. Having it as an option would not decrease your UPS, or affect your play style in any way if you don't want it.