Friday Facts #395 - Generic interrupts and Train stop priority
Re: Friday Facts #395 - Generic interrupts and Train stop priority
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:
This probably does not need anything from this FFF though :thinking_face:
Re: Friday Facts #395 - Generic interrupts and Train stop priority
Any chance for electric locomotives?
-
- Long Handed Inserter
- Posts: 75
- Joined: Wed Mar 08, 2017 3:34 pm
- Contact:
Re: Friday Facts #395 - Generic interrupts and Train stop priority
Train groups take care of this issue for you.layus wrote: ↑Fri Jan 26, 2024 1:28 pmCan 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:
Re: Friday Facts #395 - Generic interrupts and Train stop priority
ah yeah finally
- Attachments
-
- lv_0_20240126152828.mp4
- (281.59 KiB) Downloaded 106 times
Last edited by beetlman on Fri Jan 26, 2024 5:07 pm, edited 1 time in total.
Re: Friday Facts #395 - Generic interrupts and Train stop priority
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.
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.
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.
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.Justderpingalong wrote: ↑Fri Jan 26, 2024 12:13 pmThe 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.
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.
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.Justderpingalong wrote: ↑Fri Jan 26, 2024 1:25 pmJust 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.
Last edited by Fiorra on Fri Jan 26, 2024 1:39 pm, edited 1 time in total.
Re: Friday Facts #395 - Generic interrupts and Train stop priority
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
Re: Friday Facts #395 - Generic interrupts and Train stop priority
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
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
-
- Inserter
- Posts: 48
- Joined: Sat Jun 01, 2019 10:50 pm
- Contact:
Re: Friday Facts #395 - Generic interrupts and Train stop priority
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.
-
- Manual Inserter
- Posts: 2
- Joined: Fri Jan 12, 2024 11:47 pm
- Contact:
Re: Friday Facts #395 - Generic interrupts and Train stop priority
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.ccw18 wrote: ↑Fri Jan 26, 2024 12:45 pmI 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'd hope a refueling interrupt would be based on % fuel level. If not then they need to adjust fuel stack sizes to be consistent.
Re: Friday Facts #395 - Generic interrupts and Train stop priority
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.So in 2.0, disabled trains stops will act as if they have 'Train limit = 0':
My mods: Capsule Ammo | HandyHands - Automatic handcrafting | ChunkyChunks - Configurable Gridlines
Some other creations: Combinassembly Language GitHub w instructions and link to run it in your browser | 0~drain Laser
Some other creations: Combinassembly Language GitHub w instructions and link to run it in your browser | 0~drain Laser
-
- Filter Inserter
- Posts: 494
- Joined: Tue Jun 26, 2018 10:14 am
- Contact:
Re: Friday Facts #395 - Generic interrupts and Train stop priority
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.
Re: Friday Facts #395 - Generic interrupts and Train stop priority
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.
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.
-
- Filter Inserter
- Posts: 463
- Joined: Tue Jun 28, 2016 2:07 pm
- Contact:
Re: Friday Facts #395 - Generic interrupts and Train stop priority
A steering wheel icon for manual mode + stopped without driver would be great!
-
- Long Handed Inserter
- Posts: 75
- Joined: Wed Mar 08, 2017 3:34 pm
- Contact:
Re: Friday Facts #395 - Generic interrupts and Train stop priority
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.Fiorra wrote: ↑Fri Jan 26, 2024 1:38 pmYou 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.
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.Fiorra wrote: ↑Fri Jan 26, 2024 1:38 pmI'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.
- husnikadam
- Fast Inserter
- Posts: 111
- Joined: Mon May 21, 2018 1:56 pm
- Contact:
Re: Friday Facts #395 - Generic interrupts and Train stop priority
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.
Re: Friday Facts #395 - Generic interrupts and Train stop priority
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.
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.
Re: Friday Facts #395 - Generic interrupts and Train stop priority
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.
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.
-
- Fast Inserter
- Posts: 126
- Joined: Fri Sep 14, 2018 2:06 am
- Contact:
Re: Friday Facts #395 - Generic interrupts and Train stop priority
I never used icons in stop names, making that a necessity sounds like a terrible idea
Re: Friday Facts #395 - Generic interrupts and Train stop priority
Nice new additions. I'm looking forward to get my hands on 2.0 so i can update all my blueprints.
Re: Friday Facts #395 - Generic interrupts and Train stop priority
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
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
My mod(s): Brake Squeal