Friday Facts #395 - Generic interrupts and Train stop priority

[layus]

Can we have parametrized train blueprints ? Like place a train blueprint, pick the iron ore item type, and have an extra iron ore train running ? Having all the trains in a big bag feels really odd to me.

This probably does not need anything from this FFF though :thinking_face:

[Shoco]

Any chance for electric locomotives?

[Justderpingalong]

Can we have parametrized train blueprints ? Like place a train blueprint, pick the iron ore item type, and have an extra iron ore train running ? Having all the trains in a big bag feels really odd to me.

This probably does not need anything from this FFF though :thinking_face:

Train groups take care of this issue for you.

[beetlman]

ah yeah finally

[Fiorra]

Good stuff.

Minor nitpick: most programmers have seen systems where the lower value is the higher priority. The train stop UI could use one of those blue question marks with a help text documenting both the order and the effects of priority, as written in the FFF.

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.

You can do something via circuitry. Interrupts can be based on signals: "On signal Iron > 0, go to Iron pickup, then Iron dropoff". You can also shut off provider stations when there's no demand.

Both of those are susceptible to a stampede problem, unless you mark the demand as satisfied the moment a train is dispatched toward the pickup.

Realistically, the system as presented will balance itself: yes, trains will go to an iron mine even when no iron ore is needed, but then the train will sit at the iron mine and block further pickups until there's demand. Just make sure you have enough trains, and put reasonable queue limits on your stations, and it will work fine.

Just had an idea whilst thinking about this: I'm currently playing a Space Exploration playthrough using LTN so whenever I see train stuff I try to imagine 'will this let me do what I do in LTN without needing LTN'? And stumbled upon a particular use case: Many of my trainstops accept multiple different items. For my sanity, I name the requester stations something like [item:requester chest][item1][item2][item3][item4] etc. The generalised interrupts are brilliant, they truly are: But how will they work with this setup? I believe the generalised interrupts work GREAT so long as your usecase assumes trains will only ever load 1 item and unload 1 item. But this is simply not true for most people. So given we're this close to an LTN/Cybersyn/any other similar mod like system, I wish we could just embrace it.

I've had mixed trains like that without LTN: for wall supplies, for the SE orbit mall, sometimes for cases where a full train is too much of a buffer. You'll need to specify the full schedule, but then it'll work. A dedicated train (or train group) is easiest, but if you prefer fully generic trains, then you'll be able to trigger that schedule via interrupt.

[layus]

Train groups take care of this issue for you.

Well, you still need to assign the group manually, which can be hard if the trains switches to automatic mode directly. So it works if train groups can be set using blueprint parameters . So many options

[layus]

Oooooh !

It all makes more sense if you consider trains filled with random items at, say, a unique mixed planetary landing pad, and then have these mixed trains deliver items at different stations. This explains why the interrupts do not wait on empty cargo, but on that specific item being 0. Trains can then proceed to drop other items to other stations. Of course, if the rocket/space station ships items that you do not have any station for, then you are in trouble. It's so much better than filter inserters and chains of filtered splitters

[JackTheSpades]

Given all these new changes, will we finally be able to change a train stop while keeping the wait conditions on it? It's really annoying when copying a train with a more complex condition set and having to delete the entire thing because I need a different train stop.

[FeistyCanuck]

I wonder how to make use of ‘any fuel’ signal for a generic refuel station. For coal, I probably want to go refuel when theres 10-25 coal, but for nuclear fuel I want to refuel when theres 0-1 fuels. Those ranges don’t overlap thus cannot work together as a general refuel interrupt

I think this is about fuel delivery, not refueling. As in coal for a furnace where ANY fuel will work. Or delivering fuel in bulk to a refueling station that will fuel other trains.

I'd hope a refueling interrupt would be based on % fuel level. If not then they need to adjust fuel stack sizes to be consistent.

[Qon]

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.

[coppercoil]

There are so many possibilities and nuances using trains. It's easy to miss some non-obvious trick, and many new players will wonder after a while: "is that even allowed???". I think all the train related stuff (short descriptions with links) should be collected to a single page so players will know there are more useful things to study.

[Zeroji]

I like the "no path" / "destination full" icons, they look great on trains, could you just add a "manual mode" indicator? Sometimes I accidentally switch a train to manual and then it's not obvious why iron isn't coming in

Regarding the generic interrupts, I'm not sure I love the showcased implementation, often my trains will be called "[iron-icon] iron drop-off" to have the fanciness of the icon, but the readability / searchability of text. Would it be possible to implement a basic wildcard, for example "[any-item] *drop-off" would match anything starting with the generic interrupt's item and ending with "drop-off"? I don't know if that would hurt performance, probably not for <1000 unique train stop names.

[IronCartographer]

I like the "no path" / "destination full" icons, they look great on trains, could you just add a "manual mode" indicator? Sometimes I accidentally switch a train to manual and then it's not obvious why iron isn't coming in

A steering wheel icon for manual mode + stopped without driver would be great!

[Justderpingalong]

You can do something via circuitry. Interrupts can be based on signals: "On signal Iron > 0, go to Iron pickup, then Iron dropoff". You can also shut off provider stations when there's no demand.

Both of those are susceptible to a stampede problem, unless you mark the demand as satisfied the moment a train is dispatched toward the pickup.

Realistically, the system as presented will balance itself: yes, trains will go to an iron mine even when no iron ore is needed, but then the train will sit at the iron mine and block further pickups until there's demand. Just make sure you have enough trains, and put reasonable queue limits on your stations, and it will work fine.

That'd involve having to wire up every single station to the circuit network. Doable, but tedious. 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.

I've had mixed trains like that without LTN: for wall supplies, for the SE orbit mall, sometimes for cases where a full train is too much of a buffer. You'll need to specify the full schedule, but then it'll work. A dedicated train (or train group) is easiest, but if you prefer fully generic trains, then you'll be able to trigger that schedule via interrupt.

Dedicated trains in an age of full on generalisation sounds inefficient. What I was more looking for was a way to make a train look for a stop that simply contains a certain rich text icon + a string. This would be an incredibly elegant way of marking trainstops.

[husnikadam]

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.

[grzybk]

And yet another mod gets integrated to the base game, but in an even better form. Not that I'm complaining, this looks awesome

One suggestion that I would make, if rich text starts having actual functionality, then it should be more discoverable. As it stands it's a very niche thing that's kind of clunky to use, but it really should be just as easy as crafting an iron gear.

[Straugh]

Laying down new trains via a blueprint works, but it really doesn't go far enough. We can think of blueprints as recipes. This game is all about automation.

Imagine if the train, cargo wagons, inventory, configuration, logistic components, schedule, etc could be assembled and inserted as a unit onto the tracks. If the cargo is locked down, that configuration is also automated. Based on circuit conditions, the train can be automatically dispatched.

As trains and cargo wagons could be upgraded to a higher tier, there can be a condition that sends an old train to be retired. If there are too many of a train, same thing. This is similar to how you can upgrade your robot tiers. Old trains can be scrapped for parts.

This concept can be applied to any vehicle: spidertrons, tanks, rockets, etc. The factory decides based on a condition whether something should be built, And how it should be configured. Manually managing this is opposite of what we can automate via roboports.

The storage concept where we lock down what is allowed in a chest/wagon should be able to be named and reused. This is just a blueprint/recipe that the storage item can pick from. If we can do that, we can also use circuits to control it. This concept can be applied to anything that supports configuration in that we can name it and reuse it.

Last bit hinted at was logistics. Higher tier vehicles should have logistic capabilities. Robots, batteries, roboports, etc are something that can be inserted into the vehicle prior to them being dispatched.

Again, this is all about the automation. The factory must grow.

[burninghey]

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

[ElderAxe]

Nice new additions. I'm looking forward to get my hands on 2.0 so i can update all my blueprints.

[Nexusuxen]

I feel like there could be room for a "No path" interrupt. Should a train not have a path to its next stop, it may be helpful to be able to order it to travel to a dedicated waiting area. A train stopping on a busy rail line due to not having a path could cause massive problems.
Or, an option to skip the train stop if there is no path - a little check mark next to each stop for this behavior would be a simple implementation!

Mostly skimmed with the power of find-in-page, and it's been a while since I've read #389 in depth, so forgive me if this is already a thing or would be redundant