Blueprinted train stations take their train limit from existing named stations, not the blueprint values

[Ecnassianer]

I have a parameterized blueprint with a train station in it. The train station name is set by a parameter that takes an item type. The train limit is set to 0 and the Enable train limit and Set train limit checkboxes are unchecked.

02-21-2025, 10-37-54.png (400.56 KiB) Viewed 740 times

When I try to use the blueprint and select an item type with no existing train stations, the blueprint will create a station with no train limit set.
When I try to use the blueprint and select an item type with existing train stations, the blueprint will create a station with a train limit set to whatever the lowest existing train station's limit is set to.

I shared this blueprint with someone else and they were able to repro it on their map.

I expect the train limit that is set in the blueprint to always be applied to the product of the blueprint, rather than shared with a random station in my map.

Here is the blueprint I'm using:

Trainlimit.txt

(6.34 KiB) Downloaded 14 times

Logs:

factorio-current.log

(18.91 KiB) Downloaded 13 times

A save game where I can reproduce it:

BuildingAdventure.zip

(4.71 MiB) Downloaded 17 times

[boskid]

Welcome on forums.

I have mixed feelings about this because i am not sure why would you need a train stop without limits while there are other stops with limits set. Behavior you see is actually a feature that was added in 2.0 because train stop limits play important role when using interrupts and some of the schedule wait conditions.

Issue this feature is trying to prevent is that some players when building train stops tend to first rename train stop into correct station name and then configure the limit but this usually causes all the trains going for that station to try arrive into that train stop causing an instant congestion around the train stop that is still being configured. This is even more relevant when trying to have a generic trains with interrupts as there may be multiple trains just waiting to depart when a station with given name just appears and train stop has no limit set.

This specific sequence of actions that we considered bad is detected when train stop is renamed while having no trains limit set and having it not set by circuit network. Having the limit forced in that case to the lowest value of a limit (or to 0 if any of those stops has limit set by circuit network) is the most conservative solution to prevent having wild horde of trains as dealing with it is way more painful.

Only debatable point in here is that this was originally intended to only happen when manually renaming a train stop but it seems to also apply to blueprint placement. However given that this would create the same issues with parametrized blueprint placement, i am far more likely to say this is working as intended and put it into Not a bug because this has simple (but slightly ugly) workaround - you can set a limit to some huge value of 1000000 if you want a no limit behavior. Not having this feature can cause the original issue to reappear when placing a blueprint that was not setup for operation with train stop limits while the station name selected by parameters is one that relies on the limits being set.

I will keep this in Bug reports until a decision is made if this works as intended or if blueprint rename should be excluded from this feature.

[Ecnassianer]

I can see how the horde of trains would be a problem. But on the other hand, it took me an hour tracking down why this blueprint was behaving the way it was, and a trip to Discord to figure out why the limit was causing my trains to get tangled and not lining up in my stacker. With a lot of trains and few stations, the train limit causes the trains to block each other. Unchecking the limit causes all my trains to go the places I expect them to go.

I admittedly don't understand all the implications of a train limit, I was assuming you just set that to how many slots you have in your train stacker, and different stations can have different sized stackers, so it's not clear to me why using the limit set by the station with the lowest limit is useful, rather than just using "1" every time.

However, this behavior is even more mysterious because the name of the station is parameterized in my case, so depending on what material you choose, you can get no limit or a limit set to any number (based on what the other stations have a limit set as) all from the same blueprint. The fact that a secondary field gets silently set by a parameter that it is unrelated to is not a great experience. Perhaps the solution is to make the train limit setting more explicit? Like a dialog that prompts you to set it manually in the case where other train stations have limits? Something that at least points to the fact that the blueprint is setting a value that is different than what it was copied from.

[robot256]

i am not sure why would you need a train stop without limits while there are other stops with limits set.

This is common in non-interrupt-driven systems when the number of trains in the system is properly balanced and distance/path penalty is used to enforce priority. It's true that Limits and Priority can be used for this instead.

Issue this feature is trying to prevent is that some players when building train stops tend to first rename train stop into correct station name and then configure the limit but this usually causes all the trains going for that station to try arrive into that train stop causing an instant congestion around the train stop that is still being configured. This is even more relevant when trying to have a generic trains with interrupts as there may be multiple trains just waiting to depart when a station with given name just appears and train stop has no limit set.

I understand the issue but do not understand the logic used to go from "user doesn't learn to check Use Limit before renaming stop" to "limit gets silently set to an essentially random value when user interacts with a seemingly unrelated control or places a blueprint".

The fact is that the user experience is far better with inconvenient-yet-predictable behaviors instead of sometimes-helpful-but-opaque behaviors. (It's honestly what I loved about 1.1--the game didn't try to guess what you wanted, even if getting some results took several steps.)

If the goal is to make limit-based systems easier without regard for the experience of limit-agnostic players, then you should completely remove the option to disable the limit and always initialize it to 0. Then players who want unlimited stops will know they need to enter 1e6, blueprints will always contain a valid limit value, and no values will change for seemingly no reason.

[boskid]

The fact is that the user experience is far better with inconvenient-yet-predictable behaviors instead of sometimes-helpful-but-opaque behaviors. (It's honestly what I loved about 1.1--the game didn't try to guess what you wanted, even if getting some results took several steps.)

If the goal is to make limit-based systems easier without regard for the experience of limit-agnostic players, then you should completely remove the option to disable the limit and always initialize it to 0. Then players who want unlimited stops will know they need to enter 1e6, blueprints will always contain a valid limit value, and no values will change for seemingly no reason.

1.1 and 2.0 are different because of interrupts. In 1.1 it was common to have a dedicated train stops for puckup and for drop and so a failure to set limit before renaming would at most create a horde of trains for that specific material. In 2.0 due to interrupts there exists couple of universal train setups where failing to set limit may cause all the trains scheduled for generic item pickup to arrive and that was considered to be too much - it was almost always followed by a save reload.

I think best solution would be to have train stops have default limit of 1 but this could cause breaking changes and so i will not apply it earlier than in 2.1. With default limit of 1 there would be no risk of the train horde when name is changed first. Just look at the history, current default of no-limit was for seamless transition from 1.0 without limits into 1.1 where train stop limits were introduced.

Even a default limit of 1 may be considered incorrect due to a different feature - trains keeping reservation until they are out of rail block of the departing train stop. In train networks without signals (one of stages when new players are still learning how to use signals) it could cause annoyance due to trains not arriving to a train stop because it is still reserved by the train that just left.

Its not a trivial change.

[robot256]

The fact is that the user experience is far better with inconvenient-yet-predictable behaviors instead of sometimes-helpful-but-opaque behaviors. (It's honestly what I loved about 1.1--the game didn't try to guess what you wanted, even if getting some results took several steps.)

If the goal is to make limit-based systems easier without regard for the experience of limit-agnostic players, then you should completely remove the option to disable the limit and always initialize it to 0. Then players who want unlimited stops will know they need to enter 1e6, blueprints will always contain a valid limit value, and no values will change for seemingly no reason.

1.1 and 2.0 are different because of interrupts. In 1.1 it was common to have a dedicated train stops for puckup and for drop and so a failure to set limit before renaming would at most create a horde of trains for that specific material. In 2.0 due to interrupts there exists couple of universal train setups where failing to set limit may cause all the trains scheduled for generic item pickup to arrive and that was considered to be too much - it was almost always followed by a save reload.

Thank you for the explanation! I did not really imagine that a "horde of trains" would be that much of a problem (and if it happened to me, I certainly would be tempted to abandon such a setup to avoid hordes in the future). But this only applies to particular setups. The reason there seems to be no good solution for handling other setups is because the current interface does not allow the player to accurately communicate their intent before the train stop becomes operational. Adding a *fixed* default limit of either 0 or 1 would make it so you no longer try to guess their intent, so I really like this idea and think it would be great to implement before 2.1.

I think best solution would be to have train stops have default limit of 1 but this could cause breaking changes and so i will not apply it earlier than in 2.1. With default limit of 1 there would be no risk of the train horde when name is changed first. Just look at the history, current default of no-limit was for seamless transition from 1.0 without limits into 1.1 where train stop limits were introduced.

Can you describe what this would break any more than the current behavior?

This bug report was posted because the current behavior already breaks existing blueprints. I don't see how changing the *on-built* behavior again to a more predictable result would be any worse, and it still shouldn't change existing built entities. If you are going to alter existing blueprints, you should do it during the migration process in a predicable manner that the user can verify in a sandbox game/JSON editor before placing it. The main reason the current behavior is so frustrating is because it makes the result of placing a blueprint dependent on the state of other entities elsewhere on the map.

The other option, of course, is to not alter blueprints at all. If someone wants to copy a blueprint from an un-limited system and use it in their limit-critical system, I think it's totally reasonable that they would place blueprint->horde of trains->oops, I'll fix blueprint first->reload/reset. But this still leaves the matter of users being confused when the train limit changes after they rename a stop.

The current behavior does not achieve its stated goal for manual renaming when the player destroys all the existing stops named "A" with limit set (so that trains are stuck in no-stop-exists), and builds a new stop, renames it "A", and doesn't realize that the limit won't be set automatically unless there is another stop with the same name and a limit already built, so they get a horde of trains.

The limit-copying behavior is also deceptively similar to the way train groups and logistic groups work, so I would not be surprised if someone sees it do that and mistakenly thinks that changing the limit of one stop will update other existing stops with the same limit. Without a Tips & Tricks entry about Train Limits in general, these are all reasonable assumptions by the player.

Even a default limit of 1 may be considered incorrect due to a different feature - trains keeping reservation until they are out of rail block of the departing train stop. In train networks without signals (one of stages when new players are still learning how to use signals) it could cause annoyance due to trains not arriving to a train stop because it is still reserved by the train that just left.

Its not a trivial change.

The philosophical point I want to stress is that the only "incorrect" behavior in a game like this is one that the player does not expect after a short amount of research or experimentation. Behaviors like the one in this post, that are not documented and take substantial time to both discover and understand, are the definition of a bug in my opinion. I appreciate the desire to make it easy for new players to make things that "just work", but it's not a reasonable requirement to place on yourself that they should be able to play the game in multiple different ways without ever touching the train limit setting box. Devs can't possibly guess what the player is thinking in every single case, and it's hard on both devs and users when you try.

It seems like a very reasonable progression for players to

• place train stop (auto-limit=1)
• make one train, just works
• make two trains, sometimes stuck
• "oh, this box says train limit is 1, I will change that".

Thanks for your work and your insight as always.

[Klonan]

Thank you for the feedback, and the thoughts on the feature,
You can find some of our reasoning in the Friday facts here: https://factorio.com/blog/post/fff-403

I think the behavior is working well, this is the first discussion on the feature, so I think that most players are happy with the logic to safeguard against the train limit mistakes.

We can have further discussion, however this is working as intended, and is not a bug,
So I will move this topic to ideas and suggestions

[robot256]

Thanks for the link to the FFF. If that's all the thought that went into it, then it would indeed seem to be a hastily-created feature for a particular playstyle that's easy enough for others to work around. Normally I would expect that sort of thing to be an optional setting or a mod.
 
Now that this is in Ideas & Suggestions, how about adding a way to communicate this behavior to the player in game? Such as having a message appear before you click Confirm?

02-25-2025, 08-05-08.png (49.71 KiB) Viewed 399 times

But this is impossible when the limit is being set based on a parameterized station name in a blueprint. So implementing a more predictable way to import old blueprints is still the topic of discussion.