Working with trains is a pain in the..

[ssilk]

What the OP points to, is that if you have many trains waiting, laying new tracks becomes a pain. Because I don’t have that problem ... even with 200 running trains, in a 300 Kilometer large train network, I can use the trainlayer mod without seeing a difference in ups. It’s only the waiting trains, that make this problem.

So this problem is a special case and a quite simple solution would be to have a mod, that turns off all trains, that are currently waiting. It could be smart: when the player puts a track or signal into the hand (or enter raillayer train), and the number of waiting trains is above some limit, the mod can begin to stop the trains. When he puts the tracks out of hand it can restart the trains. Doesn’t look very complicated.

Does the train system have separate networks for tracks that aren't connected? If so then:
...

The wiki lists all situations, where a train tries to recalculate it’s path, and of course different networks doesn’t matter in this calculation, cause the last change could have connected two separate networks.
https://wiki.factorio.com/Railway/Train_path_finding

With these rules you might be able to think about how many trains are involved to be forced to recalculate their paths and how to change that. I recommend using the debug mode (see also wiki) for that; there are some useful debug options that can help you with that.

Because changing that rules (by making them more clever) will introduce many bugs as side effects, because the system is very complex - as you might see due to the number of rules involved. So there is a very low chance that this will be changed.

[mrvn]

What the OP points to, is that if you have many trains waiting, laying new tracks becomes a pain. Because I don’t have that problem ... even with 200 running trains, in a 300 Kilometer large train network, I can use the trainlayer mod without seeing a difference in ups. It’s only the waiting trains, that make this problem.

So this problem is a special case and a quite simple solution would be to have a mod, that turns off all trains, that are currently waiting. It could be smart: when the player puts a track or signal into the hand (or enter raillayer train), and the number of waiting trains is above some limit, the mod can begin to stop the trains. When he puts the tracks out of hand it can restart the trains. Doesn’t look very complicated.

Does the train system have separate networks for tracks that aren't connected? If so then:
...

The wiki lists all situations, where a train tries to recalculate it’s path, and of course different networks doesn’t matter in this calculation, cause the last change could have connected two separate networks.
https://wiki.factorio.com/Railway/Train_path_finding

With these rules you might be able to think about how many trains are involved to be forced to recalculate their paths and how to change that. I recommend using the debug mode (see also wiki) for that; there are some useful debug options that can help you with that.

Because changing that rules (by making them more clever) will introduce many bugs as side effects, because the system is very complex - as you might see due to the number of rules involved. So there is a very low chance that this will be changed.

If you had a train network ID on every rail and train then the game would know when 2 separate networks have been connected. In that case the network with fewer trains should be relabeled to the other network and all trains in both networks are candidates for checking their path. Only to those trains the existing rules would have to be applied.

[Ghoulish]

I'd really appreciate some feedback from Wube on this matter.

This exact issue has seemingly not come up before (if it's regarding these forums and Koub can't find it..). For me this issue is quite a big problem, I've shown what happens every time I work with track in my factory. The generally low UPS doesn't matter as you do get used to it, it's the pretty big drop that happens every time any track is added or removed that is.

No one believed me when I made this thread - until I proved it - so there is clearly misunderstanding in exactly how the train pathfinding system works. There is also no mention of disconnected track on the Wiki. Before this thread I think it is fair to say that the general assumption with track was that disconnected track would not have an overly negative impact on UPS - but that is clearly not the case, it doesn't matter if the track is 100% isolated or you sever paths to a junction, the UPS drop is very noticeable.

If someone at Wube would please take the time to explain it, and give their thoughts on whether or not it is viewed as an issue?

[ssilk]

I can tell you what they would say: This is not easy to fix. Because it is exactly this problem, as described in the wiki-article above. It can be optimized, but for the price of adding a even higher complexity to a very complex problem. As wube I would always try to avoid to fix this problem, because it is a rare case (sorry, but that's the facts). And the best would be not to answer, because of that.

And in my eye as player I would say it is a mistake to place hundrets of kilometers of unused rails with thousands of junctions with many trains waiting. Reduce junctions to a minimum. Remove unused rail parts. Organize trains, that they don't need to wait. Problem fixed. See this as a part of the game.

Hope I didn't bug you.

[mrvn]

I can tell you what they would say: This is not easy to fix.

I truely can't believe that. It's a solved problem. Theoretically and Practically. The electric network has such IDs. The fluid system has such IDs. Even belts have segments that are basically the same and they merge and split constantly as items are added and removed.

[ssilk]

I can tell you what they would say: This is not easy to fix.

I truely can't believe that. It's a solved problem. Theoretically and Practically. The electric network has such IDs. The fluid system has such IDs. Even belts have segments that are basically the same and they merge and split constantly as items are added and removed.

Which problem is solved? The rail network has no such IDs because it makes no sense. Think of places where a train cannot drive to, even if connected to the network. This is different to power.

And there is no "automatable" way to solve the problem, that your rail-network is just "too big". Any A* algprithm will need some time to find an optimum if you have hundreds of switches from A to B. And it must be reacalculated for driving or waiting trains every time you place/remove a track, because otherwise it is like if you follow your car-navi, even if a street on your path was meanwhile closed.

As said: Reduce complexity of your rail-network, not blaming the game for your design decisions.

[mrvn]

I can tell you what they would say: This is not easy to fix.

I truely can't believe that. It's a solved problem. Theoretically and Practically. The electric network has such IDs. The fluid system has such IDs. Even belts have segments that are basically the same and they merge and split constantly as items are added and removed.

Which problem is solved? The rail network has no such IDs because it makes no sense. Think of places where a train cannot drive to, even if connected to the network. This is different to power.

And there is no "automatable" way to solve the problem, that your rail-network is just "too big". Any A* algprithm will need some time to find an optimum if you have hundreds of switches from A to B. And it must be reacalculated for driving or waiting trains every time you place/remove a track, because otherwise it is like if you follow your car-navi, even if a street on your path was meanwhile closed.

As said: Reduce complexity of your rail-network, not blaming the game for your design decisions.

The problem of having entities that form a network with an ID and joining and splitting them as entities are added or removed is a solved problem.

And that won't make A* run any faster for any train. The point is to not even run A* where not needed.

In the extreme at the moment when I add a rail in the blueprint lab surface all waiting trains on nauvis are re-pathed. That's totally stupid. Trains can never ever cross surfaces. That's like having the car-navi in Budapest recalculate your route because road was closed in New York.

[ssilk]

And that won't make A* run any faster for any train. The point is to not even run A* where not needed.

Well, there are situations in the wiki, that seems to be possible to optimize under some circumstances. But they are rare and as I already said: You add eventually more overhead to check if you are now in this special situation and don't need to run the router over all trains: That will optimize your current situation in your current game, but will make it slower for all others. And it adds a lot of compexity to already complex code.

And from a professional view: As long as it is not clear, that an optimization is really needed (You seem to be the only?), me as programmer would say always no to that change, because it is not clear what is expected. From whom? I cannot test it. If I programm something, which cannot be tested I made a big mistake.

In the extreme at the moment when I add a rail in the blueprint lab surface all waiting trains on nauvis are re-pathed. That's totally stupid. Trains can never ever cross surfaces. That's like having the car-navi in Budapest recalculate your route because road was closed in New York.

Ah, good point.

Maybe it's because theoretically tracks of different surfaces can connect? I'm not sure if it is possible with a mod, but the data-structure allows it.
And that is also needed somewhere in the future, when we will eventually maybe perhaps get tunnels or bridges.

[mrvn]

In the extreme at the moment when I add a rail in the blueprint lab surface all waiting trains on nauvis are re-pathed. That's totally stupid. Trains can never ever cross surfaces. That's like having the car-navi in Budapest recalculate your route because road was closed in New York.

Ah, good point.

Maybe it's because theoretically tracks of different surfaces can connect? I'm not sure if it is possible with a mod, but the data-structure allows it.
And that is also needed somewhere in the future, when we will eventually maybe perhaps get tunnels or bridges.

Oh yes, please, please, please, show us how or add that option to the modding API.

If you check how many requests for tunnels and bridges there are you will get a feeling how many people that would make happy.

[Serenity]

There is a train tunnel mod. Kind of a prototype though:
https://mods.factorio.com/mod/traintunnels

[mrvn]

There is a train tunnel mod. Kind of a prototype though:
https://mods.factorio.com/mod/traintunnels

Last I checked that's not connecting train tracks to other surfaces. Instead you have to add train stops to the schedule and it teleports the train when it arrives at the stop for the tunnel entrance.

[Ghoulish]

I wanted to bring this issue up again. As it's truly a problem for me. I also wanted to get clarification from those familiar with the topic as..

* (pronounced "A-star") is a graph traversal and path search algorithm, which is often used in computer science due to its completeness, optimality, and optimal efficiency.[1] One major practical drawback is its O( b d ) O(b^) O(b^d) space complexity, as it stores all generated nodes in memory. Thus, in practical travel-routing systems, it is generally outperformed by algorithms which can pre-process the graph to attain better performance,[2] as well as memory-bounded approaches; however, A* is still the best solution in many cases.[3]

.. it's complicated! Firstly the UPS impact when adding or removing track is clearly exacerbated by the games average UPS, if you aren't already pushing your hardware / don't have a great deal of track or trains - then you wont have this issue. Everyone reading this will encounter it if they stick with one factory, resolve any issues they encounter and keep expanding, guaranteed, that's what Factorio is about, and that's regardless of how high your pc's specification is. It's a deal breaker for me in its impact that it has in my factory, especially as designing / rebuilding track is something I enjoy doing.

I wanted to talk about any possible solution, from a optimal redesign to something that could be more easily integrated or changed within the current framework.

It's a solved problem. Theoretically and Practically. The electric network has such IDs. The fluid system has such IDs. Even belts have segments that are basically the same and they merge and split constantly as items are added and removed.

I have a few questions regarding this proposed solution.

~What would the impact be on UPS if the trains were using a system similar to the electric network IDs? Do we get any UPS back per se by changing?

~How would it effect the pathfinding in an Explain like I'm 5 way?

~This would allow track tunnels and bridges, right? Can't recall another game to use trains so extensively yet not have either.

~If we had track IDs, and I built my junction as in an above post, would that still mean a big UPS hit? Or will the IDs allow smooth sailing?

~What would happen when two big rail networks were connected which used IDs? Would the following repathing mess be better with IDs or without? Explain why.

~Is this really worth doing?

Beyond those questions might there be something that would require less of an extensive rewrite which could be done to lessen the impact adding or removing track has to UPS?

We'll all encounter this problem to some degree if we all keep building. In every single factory built (which pushes the hardware/limits) At some point this issue will become apparent. I really hope Wube are willing to look at this, as my factory is nothing remarkable, ColnelWill, the guy how coined the megabase phrase, has 16 line track across parts of his base. So nothing I have could really be considered truly excessive or mega. I hope somewhere in this there is a solution, regardless of how long it takes to arrive.

[mrvn]

I wanted to bring this issue up again. As it's truly a problem for me. I also wanted to get clarification from those familiar with the topic as..

* (pronounced "A-star") is a graph traversal and path search algorithm, which is often used in computer science due to its completeness, optimality, and optimal efficiency.[1] One major practical drawback is its O( b d ) O(b^) O(b^d) space complexity, as it stores all generated nodes in memory. Thus, in practical travel-routing systems, it is generally outperformed by algorithms which can pre-process the graph to attain better performance,[2] as well as memory-bounded approaches; however, A* is still the best solution in many cases.[3]

.. it's complicated! Firstly the UPS impact when adding or removing track is clearly exacerbated by the games average UPS, if you aren't already pushing your hardware / don't have a great deal of track or trains - then you wont have this issue. Everyone reading this will encounter it if they stick with one factory, resolve any issues they encounter and keep expanding, guaranteed, that's what Factorio is about, and that's regardless of how high your pc's specification is. It's a deal breaker for me in its impact that it has in my factory, especially as designing / rebuilding track is something I enjoy doing.

I wanted to talk about any possible solution, from a optimal redesign to something that could be more easily integrated or changed within the current framework.

It's a solved problem. Theoretically and Practically. The electric network has such IDs. The fluid system has such IDs. Even belts have segments that are basically the same and they merge and split constantly as items are added and removed.

I have a few questions regarding this proposed solution.

~What would the impact be on UPS if the trains were using a system similar to the electric network IDs? Do we get any UPS back per se by changing?

The impact would be twofold:

1) When you place a blueprint with 1000 rails then you don't get all trains repathing 1000 times even though the rails don't even connect to anything.

2) When you have stations with the same name but not on the same rail network then they wouldn't get included in any path finding.

This would also mean trains don't wake up and show "no path" when the target station isn't on the same network. E.g. because you are still building and haven't connected the local rail network to the main one yet.

~How would it effect the pathfinding in an Explain like I'm 5 way?

Only effect there is point 2 above. Stations on different networks would be ignored for path finding.

~This would allow track tunnels and bridges, right? Can't recall another game to use trains so extensively yet not have either.

No, nothing to do with that. Actually in a tunnel/bridge all the rails, inside and out, would be in the same rail network. The train can drive through there.

~If we had track IDs, and I built my junction as in an above post, would that still mean a big UPS hit? Or will the IDs allow smooth sailing?

While building the junction no UPS hit would occur as long as it doesn't connect to the existing rail network.

But once you place a rail that connects the (partial) junction to the main rail network the UPS hit comes in. If you build smart you build the junction with a rail missing at the edges so it doesn't connect. Then when it's all build place the connecting rails and you only get the UPS hit for those few only.

~What would happen when two big rail networks were connected which used IDs? Would the following repathing mess be better with IDs or without? Explain why.

That depends. Is there a third large rail network? Because everything in the two networks you connect has to be worked through, just like now. But any other network would not be considered. The saving would be in the parts not connected.

~Is this really worth doing?

If you player with multiple surfaces with trains on them and conveniently name all your station that need burnables "Fuel" the difference would be huge. Or during construction. I have blueprints with 10000 rails and this would save up to 10000 repathings of all trains as I understand it when building that.

Beyond those questions might there be something that would require less of an extensive rewrite which could be done to lessen the impact adding or removing track has to UPS?

We'll all encounter this problem to some degree if we all keep building. In every single factory built (which pushes the hardware/limits) At some point this issue will become apparent. I really hope Wube are willing to look at this, as my factory is nothing remarkable, ColnelWill, the guy how coined the megabase phrase, has 16 line track across parts of his base. So nothing I have could really be considered truly excessive or mega. I hope somewhere in this there is a solution, regardless of how long it takes to arrive.

I think adding train network IDs would be a rather simple extension of the current code.

I believe changing the pathing for trains to A* could have a bigger impact though as it affects every repathing while the ID mostly affect building rails. Doing both would be cummulative, fewer path findings during build and faster when needed.

[PyroFire]

It's a solved problem. Theoretically and Practically. The electric network has such IDs. The fluid system has such IDs.
Even belts have segments that are basically the same and they merge and split constantly as items are added and removed.

You're so very, very wrong it almost hurts to see it, and i'm actually questioning myself if i'm reading your posts correctly.
Understandable though, it's not a simple problem and a complicated subject.

No search algorithms are needed for belts or the electric network, and the fluid system has unique behavior with pipe adjacency -- none of them really use or need any kind of searchable pattern of any description, not even close to the likes of A*.

Electricity is simple point-to-point with a bit of balancing math. Not even comparable to rails, not at all.

Fluids aren't moving anywhere with any kind of intention, they are following a sort of "fluid pressure" based on the pipes next to them. These networks only change on pipe/entity built (and fluidboxes touch).

And belts can be pre-cached so that a single unbroken chain of belt can act like a single belt, so to speak, and only really needs to check where the end of the belt lane is (items included). Belt "networks" only change on entity built. It's perhaps the most complicated one so far, but it is absolutely nothing compared to trains and we still don't need a search algorithm.

Comparing rails to any of these other network types is simply nonsensical and irrelevant - they are not relatable in any meaningful way.

The only other reasonably comparable .. comparison, would be how biters and other units navigate the world (like biters avoiding water -- and we've all seen how "good" they are at that).
Looking at mods, another example of something that would need something of a search algorithm is something like how starcraft lays creep - it "searches" outward from the central position for the closest tile, within range, that isn't already creep.

Interestingly, target finders can also be compared, sort of how an artillery turret procedurally scans through chunks over time to find a nearby target -- It won't neccessarily be the actual closest biter nest, but it gets close enough - it will target the biter nest that was "closest" in terms of chunk scans.

Although i agree with the idea of adding some optimization to the trains so that trains don't path on networks that fundamentally don't connect to eachother, as the devs stated, it's adding complexity to an already complicated system, and as Ghoulish too states...

I wanted to bring this issue up again. As it's truly a problem for me. I also wanted to get clarification from those familiar with the topic as.. A*.. it's complicated!

I've written A* before.
It involves math so far beyond your understanding it is hard for me to describe it using just words because it relies on what is essentially an infinite loop, and needs some existing knowledge or experience of how code works.
It's like trying to explain what "great circle distance" is -- you really need an image to illustrate what the math is actually doing, and what we're actually dealing with here.
But first....

The impact would be twofold:
1) When you place a blueprint with 1000 rails then you don't get all trains repathing 1000 times even though the rails don't even connect to anything.
2) When you have stations with the same name but not on the same rail network then they wouldn't get included in any path finding.

This would work, but I'm pretty sure you would simply be replacing one problem with another and you also don't really solve the problem.
Why not only make the check when both sides of the rail are connected to something? This may have more desirable results with less work.

It is my guess that "rail network ID's" as you described it, would reduce the performance for everyone by a linear amount and improve performance exponentially (better performance for bigger factories).
And reminder, this is only in the circumstance of having e.g. 100 trains siting in a station on automation waiting for its next station to open while you are placing a rail segment.

~How would it effect the pathfinding in an Explain like I'm 5 way?

A* search algorithm, in a nutshell.
The math to calculate shortest path between nodes (or points) on a grid.
https://en.wikipedia.org/wiki/A*_search_algorithm

A* is used due to its simplicity and reliability for most applications.
You heard me, due to its simplicity.

The dots are color-coded based on their distance from the goal.
You could consider each single step as costing $1, and the walls as making a single step costing $5.
Interesting how this could lead to situations where the shortest path is through a waiting train -- but the potential issues are acceptable.

The effect it has for you is that you need to build smaller networks and use less roundabouts.
End-to-end trains may be better.
Train dropoffs to transfer between rail networks may be another idea.
Build less stackers maybe.

"Cheap and nasty"


"The somewhat, but not neccessarily cheaper, but also more complicated Goal-Distance shortest path (used by trains)"


"Literally used commercially to deploy rail networks and chart real train stations across the USA"


And then on top of that, consider train signals and how must those be calculated?

Also if you want anything to come of these thoughts and your raised issues with your save, i suggest posting your save so wube can test

tracks of different surfaces can connect?

OMG

YOUR LUAS.

GIVE, PLEASE????

[ssilk]

Maybe your misconception is that train tracks are a graph, not a map?

A segment connects to two other segments:

Code: Select all

==========1><2==============================2><3===================

So a path from segment 1 to 3 the algorithm looks, which segment connects to 1 and is in direction of 3. The A* calculates that in three steps. So this is normally very, very fast.

So far so simple.

It gets complicated if you have switches.

Code: Select all

========1><2=================2><4==================2><5=====================
                 \\                  //
                   <3==============3>

The network needs to calculate here if going over 3 is shorter, even if that makes totally no sense for you/me.


So in general we can say: Every time you have a switch, the number of possible pathes doubles. Well most pathes can be eliminated, because they cross the former path or they lead into the wrong direction (This is done by the A*). But the general rule is to double the number of pathes every time you make a switch.

This is also the limiting problem: It's not the size of the network, nor the length, it's just the number of switches between two points. If you have 10 switches between Start and Target you multiply the effortith factor 1000 (more or less) for the worst case.

So if you built a network, which has no "main route" (a fast lane route with low number of switches) the A* needs to calculate for every route all possible paths, especially if you have a "rectangle" train-network, so that there is no "shortest" way.

[mudcrabempire]

I can't really join the discussion on the technical side, since I am not familiar with that stuff, but allow me to make a conceptual contribution.

As I understand, this whole thread is about a specific code optimization to improve the performance of the game in one particular area. But as, I think, one of the devs said in one of the FFF's, if you raise the bar for one aspect of the game, a new one will simply take the place of "most computationally demanding part of the game". Naturally, the devs are working on it to push the limits as far as they reasonably can, but in the end, there will always be limits and there will always be players who run into them (and complain about them).

I'm not that far (yet), but to me, this is not a problem. It's just Factorio. Factorio is about building a factory in such a way that in can handle whatever problems you decide to throw at it. The arguably ultimate challenge is to build the largest factory possible without running into hardware issues.

From what I've read, the issue discussed in this thread does not arise specifically due to hard code/hardware limitations. It arises because the factory was built in a way that puts a much greater strain on the hardware than necessary. My answer to this "issue" would be, that it doesn't make too much sense to complain about performance issues - the devs know about it and are working on it (although I suppose it's not too bad to report the issue, just to make sure). But in this particular case you simply ran into performance issues much earlier than you would have needed to, because you failed to beat the ultimate challenge of Factorio.

[PyroFire]

My answer to this "issue" would be, that it doesn't make too much sense to complain about performance issues - the devs know about it and are working on it (although I suppose it's not too bad to report the issue, just to make sure).

There's a reason this thread exists

But in this particular case you simply ran into performance issues much earlier than you would have needed to, because you failed to beat the ultimate challenge of Factorio.

So you're saying the player "failed" to overcome an "obstacle" (it's actually a technical limitation) that was not described, not shown, not apparent, not obvious, not illustrated and not referenced ingame and for all intents and purposes is completely invisible to the player.
How is that fair?
It'd be like saying you failed to contribute anything meaningful or valuable to this discussion because you didn't read the prior posts carefully enough.
We know that's not true - it's actually because you don't properly understand the issues being discussed so reading the posts more closely wouldn't have changed anything, much the same way that Ghoulish doesn't understand the practical problems when playing with a pathfinding algorithm (through gameplay mechanics). There is no failure on Ghoulish's part to have built his factory in such way that he breached said technical limits which he was not aware of, nor for making the report.

What's gotten us off-topic is that people don't understand what A* is and what it is used for, and in lieu of that knowledge have suggested adding "ID's" to rail networks so there is something to check against whether to update the trains or not as a solution. Sadly it's just not that simple.

I said this in an earlier post but it may have been missed in the wall, so i repeat;

Updating train pathing every time a rail is placed is very wasteful.
Instead, i suggest only running this update when a rail is placed which has another rail connected to both sides.
Placing a rail that is only connected on one side will never result in a train that previously couldn't path to a station to suddenly becoming able to path to its station.
It's a simple check to add, it adequately answers the issue with little to no downsides and there's practically zero work involved.
Though it is not perfect as it wouldn't quite hit construction bots under all circumstances because rails can be placed out of order which results in small sections of tracks 3 pieces long causing the lag frame to still happen, but it's a lot better than happening on literally every track piece.
Perfectly answers manually built tracks though - you only get the lag frame on just one track tile placement (when you initially branch off an existing rail).
And given how popular train stackers are (meaning it may not be as rare as one might like to believe), this seems like a pretty important optimization to discuss and consider.
It's really up to the devs from there if they consider this lag frame when placing rails as a bug or a "won't fix".

[netmand]

Sorry I'm not buying this as a need to change the way trains update in the base game.

Truly this update problem is one of scale. I can understand that after implementing a certain number of trains it becomes cumbersome to make design changes. Hardware improvements and mods notwithstanding, While this is an opportunity to improve the game, it doesn't improve it in a way that benefits the majority of players. You can't ask to change the basics of incorporating track into a running system because it's too cumbersome when your designs are both over-implemented and need constant adjustments.

I would give your system a maintenance window in which you make changes, so they are all stopped at one point so they can then be turned off like you've been doing. This will expose any fragility in your logistics but this too must be solved.

The other ideas/suggestions deserve their own posts.

[PyroFire]

Sorry I'm not buying this as a need to change the way trains update in the base game.

Did you read the thread?

There's a reason this thread exists

While this is an opportunity to improve the game, it doesn't improve it in a way that benefits the majority of players.

And given how popular train stackers are (meaning it may not be as rare as one might like to believe), this seems like a pretty important optimization to discuss and consider.

Looks like you didn't ;o

[netmand]

Sorry I'm not buying this as a need to change the way trains update in the base game.

Did you read the thread?

And given how popular train stackers are (meaning it may not be as rare as one might like to believe), this seems like a pretty important optimization to discuss and consider.

Looks like you didn't ;o

I disagree with the implication that "train stackers" make the topic more important. It may or may not be true that "train stackers" are widely used. In any case, use of them to the extent of affecting UPS and needing to "turn off" all trains is uncommon from my perspective. I haven't had any performance issues lately working with new and interesting track layouts while employing similar "stacker" designs on parts of my map.

It's like asking to raise all speed limits in the city whenever there is road construction, just after laying a six-lane road into it. There are better ways to approach and resolve these problems. Ones that players can take themselves instead of asking to alter the base game.

Maybe I'm still missing your point. Maybe you can expound upon it please?