Factorio Forums

For example, suppose a train is set to visit two small ore outposts with the condition "full inventory OR 5 seconds of inactivity". If it visits the first outpost and fills its inventory completely, it's already certain that the condition will stay true for the 2nd outpost and it'll leave immediately. In those conditions, it's a waste of time to go all the way over there and it should skip that station and go straight for the next one.

TL;DR:

A train should skip a stop it is set to skip if it already fulfills the wait conditions of that station right when it is departing.

Background:

A few years back, I was inspired by other circuit-based train managers to create my own, one that deploys the minimum number of trains between available pickup and drop-off stations to satisfy demand. It being vanilla-compatible meant that I was able to use it in environments that lacked a more robust manager, like LTN. At the time, I was faced with two problems that I did not find to have a sufficient circuit solution:

1. If there were multiple available stations providing or requiring the same resource, the trains did not have a way to sufficiently tell which station was actually available for however many trains, leading trains to sometimes horde a singular station that did not need that many trains heading towards it.
2. There was no way to have a train prioritize a station over another station, say, to consume a particular ore patch first or deal with a byproduct of a process before falling back to that resource's main supply.

My point with all this is that eventually there was a vanilla change that solved the first issue, that being the addition of train stop limits. A simple, yet elegant solution that only required a small change in wiring to what I had already constructed to tell the station to only accept as many trains as it claims to support. While there were technically workarounds to this issue prior to this change (by exploiting train signal pathfinding penalties), it was not perfect, and the addition of train stops had the added bonus of properly limiting depot stations to a single train at a time.

My aim with this proposal is to provide a similarly elegant solution for the second issue. As it stands, I could name the station I would like to prioritize a different name and order it earlier in the train's schedule than the other stations set to the same resource, and set its wait conditions to be the same as the non-prioritized station. This technically works... to an extent. The problem is that the train will then schedule itself to head over to an open, non-prioritized station even if that station too requires or is capable of supplying trains of its own, leading to a full train wasting time pathing to a supply station only to immediately move on from that station as soon as it realizes it is already full, similar deal with empty trains to demand stations. Even worse than this would be a train (as a result of having to path to a non-priority station after fulfilling its wait conditions at a priority station) waiting on another train sent to that station directly, essentially waiting on however much time it would take for the train at the stop to load/unload, only for the waiting train to head to that station, stop briefly, then move on with its schedule. Setting train limits by circuit condition in reaction to this phenomenon does not readily solve this issue, since it may neglect to account for other trains that are otherwise perfectly capable of fulfilling that station's request.

The Proposal:

When a train has fulfilled its wait conditions at a stop and is at the stage in its departure to evaluate the next stop to path towards, it should check, if the train is set to check for skips (for that stop or at all, more on this in the user interface section), if the train already fulfills the listed wait conditions for the next stop:

• If so, it will run the same check until it either gets to a stop for which it does not already fulfill its wait conditions, or it gets to a stop it cannot skip, in either case it will path to that stop.
• If the train would end up skipping all stops, it must evaluate the closed or train-limited stops in its schedule if it already fulfills their listed wait conditions:
• If there is at least one it cannot skip or has wait conditions it does not already fulfill, the train will wait at its current stop until one such station opens up, and if not, it should have a message similar to the "no path available" floating text that conveys that the train will have no valid stations to path to as it effectively skips all of them (something like "no valid destination").

A train should not repath to a skipped station if it somehow no longer fulfills the skipped station's wait conditions during transit (passenger jumps out of the train, someone steals or places resources in the train during transit, etc.). The skip check should only be done when the train is about to depart from a train stop.

I imagine the closed train stop case will be the biggest technical hurdle.

User Interface:

I suspect that a major reason why prior proposals to solve this issue failed to gain significant traction was because of the complex presentation of such solutions to the end user. What I mean by this is that I found that prior proposals often take a sledgehammer approach to adjusting the train schedule interface to accommodate such changes: introducing programming control flow more complicated and verbose than basic logic, separate skip conditions that the train also checks on top of the wait conditions it already has for such a stop, ill-defined probability approaches that introduce fiddling with numbers and random chance to achieve the desired effect of prioritizing stations, you get the idea. My suggestion for the user interface of the train schedule to accomplish my proposal is straightforward, though it depends on the preferred approach:

• If this proposal were to be implemented such that each stop in the schedule may individually be set to skip if the conditions are already met, I suggest that shift-clicking or ctrl-clicking on the play/pause/closed button to the left of each station name either replaces the play icon with a different icon, or adds that icon in the corner of that button, that icon being the "track skip" icon (a play icon that has a vertical bar intersecting it perpendicular to the rightmost tip of it, in keeping with the theme of using media icons to represent these states). This skip setting may alternatively be placed as a separate button to the right side of the train stop name in the schedule, just to the left of the delete button. I personally would prefer this implementation, since it allows for further granularity on train scheduling, though I can understand this being a bit visually busy and potentially unintuitive.
• If this proposal were to instead be implemented such that the train either always does skip checks or not at all, this setting may instead be moved to a toggle switch in the same bar as the "Automatic/Manual" switch, denoted by something like "Skip stops/Don't skip stops", or using media icons akin to the ones present in the buttons next to the station names, with hovertext clarifying the toggle switch.

Unskippable Stations:

There are certain wait conditions that the train cannot already meet from all the way at its departure station, i.e., time passed, inactivity, and circuit condition. This, too, poses a user interface issue, though I do have suggestions on approaching this:

• For the per-station implementation (the former), the track skip icon may be crossed out or otherwise unselectable, with either hovertext clarifying which of the three wait conditions are preventing it from being selected, the wait condition having a similar crossed-out track skip symbol next to it denoting that it is explicitly preventing the station from being skipped, or both.
• For the per-train implementation (the latter), simply having the crossed-out track skip symbol next to the corresponding wait condition, the train stop name, or both, would suffice.

Conclusion:

This may very well all be null and void, depending on plans already laid out for trains for 1.2 and onward, but the ability to significantly extend the functionality of trains using minimalist approaches has proven to both be popular and powerful with the addition of train limits for train stops, and I imagine this skip functionality or something like it would produce a similar effect, in being able to have prioritization for train stops without resorting to either clunky, incomplete circuit approaches or mods that may either extend the scope of trains far beyond what is necessary to sufficiently manage such a case or are otherwise unavailable in a multiplayer setting.

Way too much text for me to read through right now, but can you boil down for me on how a train skipping a station where all conditions are met will solve the below problem if you can't get the new train limits to do this?

AvengerStar wrote: Mon Feb 06, 2023 5:55 pm There was no way to have a train prioritize a station over another station, say, to consume a particular ore patch first or deal with a byproduct of a process before falling back to that resource's main supply.

FuryoftheStars wrote: Mon Feb 06, 2023 7:13 pm Way too much text for me to read through right now, but can you boil down for me on how a train skipping a station where all conditions are met will solve the below problem if you can't get the new train limits to do this?

AvengerStar wrote: Mon Feb 06, 2023 5:55 pm There was no way to have a train prioritize a station over another station, say, to consume a particular ore patch first or deal with a byproduct of a process before falling back to that resource's main supply.

Let's say you have a couple of supply stations tied to the same resource, but you would like to use up the resources of one station before the other. You would ideally want to send the trains to the higher priority station first before sending trains to the lower priority station. It's just as valid, however, that both stations are able to supply a certain amount of trains without downtime. The amount of trains that the station may supply without downtime is essentially bound to the stop's limit.

With this, you're faced with a dilemma: in order to handle priority with train stop limits, you would essentially have to subtract however many trains in transit taking from priority directly from the count of either available stations in the network or from the lower priority station itself, both of which would arbitrarily reduce the effective throughput of the network for that resource as fewer trains would deploy.

The alternative approach is to rename the higher priority station to something else and route the trains first through that, which accomplishes the priority, but now has trains pathing through supply stations when they are already full, and those stations may also be actively supplying a train stopped there (ex. Coal (High Priority) may supply one train, Coal (Low Priority) may supply two trains, two trains with the same schedule are sent at the same time to these stations, one goes to the high priority station and loads up there, the other goes to the low priority station and loads up there. But because the low priority station accepts two trains, the train that just loaded from the high priority station will head to the low priority station and potentially have to wait however long the low priority train is taking to load from the station, only to briefly stop at the station, realize it's already full, then continue to the drop-off.)

A train capable of conditionally skipping a station essentially skips the step where it goes to the low priority supply station entirely, without disrupting the overall course of the train. Since such a train would do nothing arriving at the skipped station, no functionality is lost while both saving time in the train's pathing and maintaining the maximum possible load of the overall system.

Support, although the "seconds of inactivity" is problematic.

At least it'll work if you have to make "inventory full/empty" a condition - the FIRST condition for the station. If you don't want skipping, you simply make it the second, third etc. condition and the first "1 second waiting" if necessary. This behaviour might require maybe a bit of special tooltip explanation of course... On the other hand I'd get it, that a train skips a station if the conditions are already met. I've even already tried it, whether Factorio works that way...

AvengerStar wrote: Mon Feb 06, 2023 8:04 pm Let's say you have a couple of [...]

Apologies, I didn't want an explanation on the end goal. I already know what the end goal is, I understand this. What I'm looking for is how the train knows its conditions are fulfilled if the destination station does not (and thus unable to lower its train limit), or how decreasing the station limit doesn't help? The only thing I caught in there was this:

With this, you're faced with a dilemma: in order to handle priority with train stop limits, you would essentially have to subtract however many trains in transit taking from priority directly from the count of either available stations in the network or from the lower priority station itself, both of which would arbitrarily reduce the effective throughput of the network for that resource as fewer trains would deploy.

Which, afaik, is not how train limits work or something you need to be concerned with, unless I'm completely misunderstanding something.

FuryoftheStars wrote: Mon Feb 06, 2023 8:25 pm What I'm looking for is how the train knows its conditions are fulfilled if the destination station does not (and thus unable to lower its train limit), or how decreasing the station limit doesn't help?

The train stop limits, if not set to a constant, are defined by the circuit network. In order for a lower priority station to know that a higher priority station serviced a train, it would have to send some sort of interrupt signal down the rail network to that station. The thing is, if you've already defined that station's limits to be set to however many trains it can reasonably load, sending the interrupt signal to decrease that limit would decrease the amount of trains that could viably head to that station at that point in time. You're either limiting the amount of trains that can deploy based on however much the high priority stations may service, or you're purely defining the train stops limits to represent priority, which would lose the available supply/required demand functionality entirely.

You may certainly technically solve it this way, but the system load limit issue wouldn't persist from renaming the priority stations anyway. The train's schedule could have very simple commands like wait until full or empty cargo, which it could readily evaluate at any point in time, regardless of stop or point in the schedule. The destination station doesn't need to know that to function, it just needs to be open when it needs trains.

Ok, had to look this over with fresh eyes. And actually reading the very first post helped. Apologies, I was getting hung up on something that wasn't even mentioned but for some reason I thought it was. I understand now what is being requested and yes, I support this as well. +1

Interesting ideas...
I would prefer not to have any user interface, either the idea is implemented, and trains skip stops, or they don't. It is just a change to how trains work. If you don't want a stop to be skipped, you add one of the conditions like time passed or inactivity.

I would include passenger present/absent as being not known - how can you tell if the passenger is going to decide to jump off before the next stop? So the only criteria for skipping a stop would be the train contents - full, empty, item count, fluid count.

Of course this would be an amazing opportunity to add train fuel to the list of available conditions! Instead of item count, it could be fuel count, and if nuclear fuel >0 then skip the fuel station

Finally, I would have the result of determining that the conditions are already met be the same as if the next stop was disabled; the train logic would act the same way as far as deciding what to do, either to go on to the next stop in the schedule if there is one, or to stay where it is until the criteria are no longer met. This would not have the usual issue of disabled stations, namely trains getting stuck on the way to a station that gets disabled, because it only ever happens when the train is already at a stop.

Amarula wrote: Wed Feb 08, 2023 4:20 pm I would prefer not to have any user interface, either the idea is implemented, and trains skip stops, or they don't. It is just a change to how trains work. If you don't want a stop to be skipped, you add one of the conditions like time passed or inactivity.

Such is valid. I mainly suggested a UI change provided that leaving the current behavior as is in some form is desirable, though a similar effect would be accomplished by just having a zero second wait condition.

Amarula wrote: Wed Feb 08, 2023 4:20 pm I would include passenger present/absent as being not known - how can you tell if the passenger is going to decide to jump off before the next stop? So the only criteria for skipping a stop would be the train contents - full, empty, item count, fluid count.

The train wouldn't be able to tell, though the suggestion I proposed included the stipulation that the check should be made only when the train is stopped at a stop, never in transit, which is why I didn't include passenger states. Otherwise, you could argue the same about stealing resources from a train in transit, in which case the cargo conditions would also be prone to become invalid, making fluid related conditions the only realistically achievable skip conditions.

I don't think it would be found an utterly nonsense by the players, if a train would skip any station where the break condition is full/empty and the train is already full/empty. They'd even expect this if they think about how the train would behave.

So suggesting the following solution:
* it should only work with "cargo full/empty" conditions resp. "cargo" (item count) "</≤/=/≥/>/≠"
* those have to be the first condition
* only if combined with no other condition or "OR"-linked with the second
* "cargo full/empty" has to be calculated for the available space i.e. blocked slots ( -> red) have to be ignored

It might be extended e.g. for a "fuel empty" condition or similar if introduced. - "Player present" or "inactivity" won't make any sense of course.