Friday Facts #395 - Generic interrupts and Train stop priority

[Trific]

Now the only question is if I will manage to finish my Seablock megabase with the train stop priority circuits before 2.0 drops.

[Trific]

Very nice changes. However, what if I want my train stops to have names like [item="iron-plate"] Iron Plates / Unload and not just [item="iron-plate"] Unload ? Is there a way to generalize item name, not only icon?

So many similar icons in mods, you can't just use the icon.

[Trific]

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.

You could have a token that renders the localized name for players to read, but the underlying token is what trains use. Many mods have very similar icons for stuff because they have so many different products.

[Qon]

I'm not yet convinced I can "totally make a train go to station "[A]" by sending the [A] signal to its train stop." with the information provided. That sounds like you extrapolated based on wishful thinking.

From the FFF:

We also have similar signals for 'Any Fluid', 'Any Fuel' and 'Any Signal'.

The keyword being "similar", meaning that they share the characteristics spelled out in the FFF right above the quote.

Yes, like I said, you can't uniquely identify each stop if there are 10k stops and 300 signal types, since the 'any signal' takes the type of some signal, but not the value.
Value checks would allow 2^32 unique stop "names" configured already with just a single signal in the name. With multiple signals in the name the system becomes nicer to use (I can have [X][Y] signals in name without having to combine the coordinate into 1 value which would be convenient).

The value checks seen in the screenshots are about things like items in cargo, which is irrelevant. I want a check on the value of potentially targeted stops. The signal types wouldn't have any relation to the cargo the train carries anyways.

Also, it seems the 'any signal' is only available in schedules/interrupts, not in stop names. From what I've seen so far. So it's just not a system that can be dynamically configured by signals at all. I still need to name all stops.

I'm not sure if you're interested in discussing the theoretical capabilities of the system, or if you intend to build an actual base with it. The theoretical power of the "Any Signal" is identical to your suggestion, just requires more lookup tables. If it's about an actual base, then I'd be curious to know what you intend to build with it.

I'm interested in both. I'm making a self-building factory and have made a programming language for the purpose of controlling it. Production cells already have ID values, based on coordinates at the moment. The cells have small processing cores taking instructions on wires to calculate if they are within an addressed area or addressed state so that they can be configured to only accept further input (and then write to their memory) and send output (to report state back to main computer) if they are addressed.
Working with signal types instead of values is very limiting and exceptionally annoying as well. Doesn't seem fun to build and would limit the factory's growth to like 10x10 cells. I already have like 6 wires between each cell wall, to each of the 4 neighbors, NSWE (red+green for coordinates, red+green for global IO, red+green for local IO between the neighbors). Since signal types communication requires all signals I can't just transmit that on the global IO wire pair so I need an additional global wire for just that to avoid interference.

So I'll use PE Stringy Train Stops Redux mod to actually rewrite schedules and train stop names instead since the vanilla system is just not made for signal configuration. Also I don't really need dynamic control of trains to have a useful system, I just need dynamic configuration and then spawn and configure trains and stops to write-once setups with as many trains are needed between stop, similarly to how trains work in vanilla now. Then re-configuring schedules and stop names multiple times would be something I do as a stretch goal.

[Trific]

I see that train blueprints now undergo a state transition once fully constructed. This is a thing I desperately want for more general blueprints: some kind of combinator which sets a signal when the blueprint containing it is fully constructed.

I have the issue that I really need for some of my combinator stuff not be connected to the global network until it is fully constructed, or it can send out false data that snarls stuff up. Also train stops not built (or at least accessible to trains) until their circuits controlling them are fully built. Right now I'm stuck manually doing certain stuff in stages.

[Gemma]

Does this also mean we will be able to set "any item except X"?

[thislooksfun]

If a train is told to go to a disabled stop, it will enter the 'Destination full' state and wait until it is enabled.

I don't like this actually. One of my current bases has a "building train" that fills up with materials and buildings for outposts and expansions at my main base then makes its way out to the outposts to drop off the requested materials and pick up trash to bring back. But to aid in efficiency I set it up to be a loop of different stations that get taken out of the schedule when they're not needed. That way one train can start in the depot, go to station 1 and pick up trash, skip station 2 since it's currently idle, drop furnaces off at station 3, drop solar panels and accumulators off at station 4, then make its way back to the depot. With this change I now have to either set up more trains (which stresses my base since each train holds a lot of resources, or have the train go out and back way more frequently than it needs (depot -> station 1 -> depot -> station 3 -> depot -> station 4). Being able to dynamically skip stations is a really useful tool for setting up systems like this.

[SupplyDepoo]

Reason one, I've seen enough posts from players where this caused problems, and the usual answer is: don't disable the station, set the limit to 0, and it'll work as expected. If disabling does the same as setting the limit to 0, those posts disappear, and those players are happy.

Reason two, if I can disable a train stop instead of setting the limit to 0, that'd make some of my circuitry easier.

If your only reason to keep it is about spacebar-heating, that's not a strong argument.

There are other ways to make those people happy, which I already touched on: interrupts, the new priority feature, and better diagnostics (stuck train alerts, and maybe more). That is better than outright removing an interesting mechanic.

Learning from mistakes and mastering game mechanics is not spacebar-heating. It's enjoying the game. And some of that enjoyment is going to be deleted it seems.

[CrushedIce]

These are very nice additions!

I just hope that you don't get lost in these kinds of "minor" optimisations. For the average player it is probably quite difficult to learn all of that.

Did you think about adding a tutorial for the advanced train and circuit features? I think that could help if one can see how these features are intended to be used.

I'm writing this because to me, as someone who played about a 1000h over 9 years, but never went into real train megabases, it starts to get difficult to keep track of all these new features

[naahuc]

Love the new features, the generics will clean up the interrupts a lot and make custom ones more visible/easier to find in bigger modpacks.

The priority is basically the last thing missing for me after the train limits that keep me from dropping train logistics mods. Yes, it can be done in vanilla with lots of circuitry, but that overhead is just as bad as using a train logistics mod and equally annoying to debug.
Just one concern, if you could explain how exactly the priority is going to work in a future FFF, because I'm coming from the train logistics angle and the usual case there is sort of the other way around in logic flow, as in a station has a request, then a train is selected and dispatched to the highest prio/closest station. Whereas the 2.0 logic seems to suggest that we'd have trains waiting at Input stations and then getting sent to a Request station.

Leading me to the following questions:
- Is the prio only used for target picking or also used in source picking? So let's say we have 5 different stations supplying X at 50/40/30/20/10 prios, will a train go to the suppliers in order of priority, assuming all stations are open etc., and will the trains then leave the station in order of priority, so 50 first, then 40 and so on, or will that be left to the default shortest path first pathfinding again? So if the 20 prio station is closest and trains are available from all stations will the 20 prio station train be used or the 50 prio station train?
- As the 2.0 seems supply driven (in my mind), is it safe to assume, that given more supply stations than trains, the supply stations would get filled with trains in order of priority, even if there is no unload station having space to unload the trains? (don't have an issue with that, just looking for clarification)
- Sort of related to the previous point, how is the priority implemented? Is it an extra layer above/alongside the pathfinding or is it rolled into the pathfinding evaluation?
- Would it be possible to allow negative priorities (at least in the input field)? This is just personal preference but I like to set priorities for sink stations in complicated packs like py to negative values, as it makes it easier to distinguish them at a glance.
- This is not strictly my point, but something that came up in discussion, but would it be possible to visualize the priority on the train stop model, so it can be read at a glance when people start wondering why that specific station they're looking at is having issues. The use case mentioned was someone jumping into a MP map and messing with prios and then leaving.

[Qon]

- Is the prio only used for target picking or also used in source picking? So let's say we have 5 different stations supplying X at 50/40/30/20/10 prios, will a train go to the suppliers in order of priority, assuming all stations are open etc., and will the trains then leave the station in order of priority, so 50 first, then 40 and so on, or will that be left to the default shortest path first pathfinding again? So if the 20 prio station is closest and trains are available from all stations will the 20 prio station train be used or the 50 prio station train?

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.

[Illiou]

I love how the trains in the video cut each other off so comically

[Aikonn]

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.

Since train is moving, you cannot send signal to it. but ...
... what if whole connected rail network would act as one big entity, that you could read/write signals from/to. Then any train could read such signal and include it in interupt condition.

[Hares]

Very nice changes. However, what if I want my train stops to have names like [item="iron-plate"] Iron Plates / Unload and not just [item="iron-plate"] Unload ? Is there a way to generalize item name, not only icon?

So many similar icons in mods, you can't just use the icon.

Yeah, that's my point.

[Dmytrozern]

Another train fact. Lovely!

Great improvements!

[bobucles]

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.

[ThePiachu]

Overall, this sounds like a good set of changes.

I guess it addresses my current biggest gripe with trains in Space Exploration mod - viewtopic.php?p=593810#p593810 that I'm not able to somehow implement priority based on last time a stop was visited by a train. I'm guessing we'll be able to set stop priority with some logic, so it should be possible to more evenly space out the item deliveries, nice.

Not sure how the generic trains will work with Space Exploration and its multi-level logistics, but that's probably not that pressing of an issue...

Initially I also thought it might be nice to have some sets of interrupts based on an item tag or some custom item grouping or even train length, but that might not be too important. Like people using biiig trains for transporting ore, smaller for plates and tiny ones for blue circuits. It might be useful to group trains by their size and same with train stops so you can have "generic 1-1-1 train", "generic 1-2 train", generic "2-8 train", etc.

[argbla]

I love you

[sOvr9000]

It would be nice if trains going to higher priority stations also had higher priority in pathfinding. Imagine if a bunch of lower priority trains at an intersection all stopped momentarily for a higher priority train to fly through without stopping. That would probably be difficult to implement, so it's just an idea.

[morhp]

I think a "skip stop if no path" option in the schedule would still be great to restore the old behaviour. If only for compatibility reasons with old savegames.