The International Simutrans Forum

 

Author Topic: Terrain alignment, bridges, tunnels and elevated in relation to existing ways  (Read 459 times)

0 Members and 1 Guest are viewing this topic.

Online Freahk

  • Devotee
  • *
  • Posts: 1307
  • Languages: DE, EN
We had a discussion about issues with PROW routes, especially in cities.
The main issue for the trouble is the algorithm used to detect diversaries, which does not actually implement what it's meant to do: Ensure that connections in between cities are not broken nor drastically worsened by players and all city buildings remain connected to the road network either.

However, there is another effect that makes this behavior much worse: It's often required to temporarily cut such routes, e.g. to upgrade bridges or to replace a level crossing by a bridge.

Freddy and me had a brainstorming on stephenson-siemens about a very simple idea: if the problem is the need to temporarily cut such routes, why don't we allow such actions without the need to temporarily cut these?

What came out is the following:
We do already have terrain alignment tools, bridge tools, tunnel tools and elevated way tools. these do have some rather restrictive requirements to use them.
The terrain alignment tools will only work on entirely empty terrain and, in case of artificial slopes, on dead-end ways.
Bridges and tunnels can only start at either dead-end ways or entirely empty terrain.

These could be adapted to work on existing ways.
The terrain alignment tool would then raise or lower all ways touching that corner, cascading to further tiles, as it does already.
The artificial slope tools would adjust the way and create proper slopes on adjacent tiles, if posible.
The bridge tool would allow the construction of bridges in the same place as existing ways, replacing the way on ground level by a bridge on a higher level.
Same for tunnels, though these do already require a slope, otherwise the tool had to dig a hole first. Might be an option either, but could just be made by using the adjusted terrain alignment tool anyway.

So far the brainstorming, I hope I reproduced this properly from mind.

Further thoughts:
-Things that remain uncovered is "pushing" non-straight road under the earth.
-Further "undoing" a bridge or tunnel to become flat road on ground level is not covered either. Simply dragging ways abobe won't work, as this action used already.
-Elevated ways are entirely uncovered in the abobe thoughts, although building an elevated road into a hole, so the way on top of it is on ground level has its use cases just like crossings on an elevated level have their use, which bridges cannot achieve.
-Non straight roads cannot be moved into a tunnel this way.
-The trouble of building half slope bridges in cases where a flat bridge would be built could be solved by the terrain alignment tool applied to bridges either.


Any comments on this?

Apart from obviously the coding effort, I do only see one downside:
Such adjustments don't require the construction of diversions at all. It was discussed elsewhere that this is desired behavior, because bridges in the real-world don't get built in a single day either.
I do generally agree with this opninion but I do not agree this works in a proper way with the current, local PROW diversion system. Real-world diversions are not neccessarily local, in fact real-world diversions in case of larger railway or motorway construction works are usually rather non-local.
Weightening these circumstances, I would highly prefer way construction works that do not require a temporary diversion.
As discussed elsewhere, such diversions in cities do frequently require the destruction of whole quarters, which is much more unrealistic.

Offline Vladki

  • Devotee
  • *
  • Posts: 3439
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
I think that there is a bug in the diversion length check, which causes false positives. Roads cannot be cut, even if suitable diversion is available, and no houses get disconnected. If this check works right and diversion length is set high, it should be possible to build such things even now.  However I tried to create a debug sample but was not sucessful.

Online Freahk

  • Devotee
  • *
  • Posts: 1307
  • Languages: DE, EN
I think that there is a bug in the diversion length check, which causes false positives
That's indeed another issue but even when working, towns around rivers or hills do often have very long stretches of unconnected roads where even a rather hight max diversion number won't work.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 20266
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
There are several complex issues here. First of all, if there is indeed a bug in the diversion checking system, I should be grateful if somebody could, in a separate thread, post a bug report with a reliable reproduction case.

Secondly, there is the question of being able to modify terrain under existing roads. In reality, one cannot raise or lower a road. One would have to dig up the road, build up or dig out the terrain, and then build a new road (and the same for railways, canals, etc.). In theory, one could implement a system that is intended to simulate these three steps in a single step for player convenience. That is not a problem from a player interaction perspective, but, in order not to unbalance the game, it would be necessary for this to be properly costed: the cost of doing this would need to be the cost of demolishing the road, raising/lowering the land, and then rebuilding the road. This cost would have to be charged where, and only where, ways were moved; where ways were not moved, this would not be charged. This additional charge would then have to be communicated to the player clearly before the player operates the tool. There is then the question as to whether to charge the base way cost only, the base way cost plus the forge cost or the base way cost plus some fraction of the forge cost for this operation. Again, this will need to be communicated clearly to the player in advance.

This is complex for plain ways, but for bridges and tunnels, it is fantastically complex. In reality, it will be impossible in most cases to change the elevation of one end of a bridge without totally demolishing and rebuilding it. The need to do this would need to be calculated and the cost displayed to the player in advance of taking action. There is then the question of what type of bridge or tunnel to use when the type currently in use is not available; something at least as good in every respect would have to be required for any public right of way, and the same for the way on/in the bridge/tunnel.

There is then the question of the relationship between this system and the existing diversion system. The existing diversion system (with fixes as necessary if any mis-counting be found) will need to be retained so far as I can tell, as this proposed system would deal only with raising/lowering terrain along the existing course of routes, yet players may wish actually to modify the course of routes in some cases, e.g., to move a road to accommodate a station or airport.

On top of all that, there is the great complexity discussed briefly by Feahk in deciding what actually happens with every possible combination of terrain modification being applied to every possible combination of ways on a tile, taking into account crossings, ways beneath elevated ways, ways with stops on them, ways with tunnels beneath the tiles, ways with intersections, ways with slopes beneath, tiles with slopes, elevated ways, tunnels and intersections all on the same tile, and tiles with bridges passing above that should be unaffected by earthworks beneath, distinguishing them from tiles with bridges passing above that will be affected by earthworks beneath).

I can imagine this being a project of truly gargantuan scale to implement properly: dealing with separating which bridges should be affected by earthworks beneath their spans and which should be unaffected alone would be a huge amount of work, requiring complex re-coding of the way in which bridges are set up and possibly extensive work in every pakset.

Offline freddyhayward

  • Devotee
  • *
  • Posts: 431
  • Languages: EN
On both the technical and balance aspects, raising and lowering plain ways, including tunnel and elevated sections, is quite possible, and in fact already implemented for dead-end sections. In this case, ways are moved with the slope with no additional charges. I have experimented with expanding this feature to junctions and straight-line sections. Bridges and tunnel entrances are a separate matter, and one i agree would be far more complex.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 20266
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
On both the technical and balance aspects, raising and lowering plain ways, including tunnel and elevated sections, is quite possible, and in fact already implemented for dead-end sections. In this case, ways are moved with the slope with no additional charges. I have experimented with expanding this feature to junctions and straight-line sections. Bridges and tunnel entrances are a separate matter, and one i agree would be far more complex.

Allowing free terraforming of roads at dead-ends is not correct behaviour; I expect that it has not been documented as a bug and investigated hitherto because allowing this only at dead ends is unlikely to have significant balance implications.

Online Freahk

  • Devotee
  • *
  • Posts: 1307
  • Languages: DE, EN
Allowing free terraforming of roads at dead-ends is not correct behaviour
You might have missunderstood.
The alignment itself is not free. There is simply no additional costs on top of that.
However, I agree the correct behavior would be charging the same costs as if the road was removed, the terrain aligned and then built afresh.

In reality, one cannot raise or lower a road.
In reality, for example level crossings are often removed by
1. placing bypass signs
2. shutting down the old route
3. building an underpass or a bridge
4. re-openening the road via the bypass or bridge
5. removing the remaining part of the old route.

That's a lot of micromanagement and in addition, the second point is not even posible at all in simutrans in very many cases.
About realism, it is much more unrealistic if players are forces to kill half of a city quarter just to build a bridge, so imho the best compromise we can come up with is actually merging all that involved micromanagement into a single step.

For sure, costs have to be paid accordingly, so internally
1. remove the way paying the removal cost and refunding the land value, just as any other destruction of ways does.
2. align the terrain at the usual terrain alignment cost
3. build the new way as usual, paying way construction costs as well as forge costs.
I don't see any problems here.

Communitcating these costs should indeed be done, but that's a more general issue I suspect.
In standard, aligning terrain around deep water can quickly run companies into bancruptcy because the slopes cascase down the water.
In extended, it's not that bad because we are not allowed to do such alignments, but it's the same with slopes around steep hills. A single missclick can quickly cost 100k either without any warning, so such a warning and confirm system should generally be prefered, wherenever the cost exceeds the cost of the used tool by a lot, whatever that "a lot" means is up to detailled discussion, but in any case that warning is a feature on its own imho.


There is then the question of what type of bridge or tunnel to use when the type currently in use is not available
In any case the one that was last selected in the menu.
That's just the consistent behavior to bridge and tunnel construction as-is.
We may want to add another type of highlighting to the menu, so we get a secondary and primary highlighting of way tools.
Theprimary highlighting shows the currently active tool. The secondary highlighting will show the previously selected way, bridge, tunnel and elevated way, so there will be (up to) 4 secondary selections at the same time.

Enforcing something "at least as good" is not always possible, as normal ways do not have a maximum weight, where bridges do have such.
The current system does not do this either! Players can build a detour, then a low weight bridge and finally remove the detour again without any problems and as mentioned before, I cannot imagine of any (practical) system that will make obstruction of other players impossible.
This is and will always be up to the community to be kind and non obstructive to each other. In the worst case it is up to moderation or administration to intervene here.
Again, allowing immediate upgrades does not add new ways to obstruct other players. It just cannot fix the existing ones either.

On top of all that, there is the great complexity discussed briefly by Feahk in deciding what actually happens with every possible combination of terrain modification being applied to every possible combination of ways on a tile
Once the core idea of this feature is accepted, we can discuss this in more detail and I am quite sure we will find a consistent solution to this.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 20266
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
There is no problem with automating the micromanagement providing that the total cost to the player be the same as if the micromanagement were necessary and charged for at appropriate amounts at each individual step. I did understand that the terraforming itself was not free with dead-ends, but that only the cost of the road was not charged; this is still incorrect behaviour.

As to enforcing minimum bridge standards, if one is replacing a bridge that is a public right of way with another bridge, the bridge with which it is replaced will need to have no less a speed or weight limit, and the way on it no less a speed or axle load limit, than the bridge being replaced.

I agree that there are general issues regarding players not being adequately notified of costs; these are historical. However, we want to avoid adding any major new issues of this sort, especially in ways that will confound the expectations of people who have some experience with Simutrans, either Standard or Extended.

Offline Vladki

  • Devotee
  • *
  • Posts: 3439
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Raising or lowering a dead end road is the only way how to make slopes in tunnels (and a cheat for elevated ways). Charging for tunnel removal, terraforming and building the tunnel again will increase the cost of sloped tunnel tile to 3x of straight tunnel.

Weaker road is not counted as valid detour, and you will be not able to remove the original PROW.
See the report about detours bugs here: https://forum.simutrans.com/index.php/topic,20143.msg189292.html#msg189292

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 20266
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Raising or lowering a dead end road is the only way how to make slopes in tunnels (and a cheat for elevated ways). Charging for tunnel removal, terraforming and building the tunnel again will increase the cost of sloped tunnel tile to 3x of straight tunnel.

I had forgotten about that - there would have to be an alternative mechanism for this if we are to charge for this in that case.

Online Freahk

  • Devotee
  • *
  • Posts: 1307
  • Languages: DE, EN
Weaker road is not counted as valid detour, and you will be not able to remove the original PROW.
That is true. the point was about the bridge itself. A PROW route can easily be re placed by a bridge with a low weight limit, which might mess up other players routes.

About the information about the costs involved, I'd really like to split this out because this is, as noted, a much more general issue and considerations on how to implement such information properly is independant of the feature discussed here.

So, in principle we agree that merging this micoromanagement into a single step is a workable solution to the above mentioned issues?

So the fixed points I see so far are the following:
1. PROW ways will remain PROW, considering all of their limitations (i.e. do not downgrade in speed and axle load)
2. Costs of those changes are as much as removing the road, doing the alignment and then building the new way.
Please complete, if you see more of such points.

Further thoughts:
About 1) I do not think there is a workable solution that does further ensure no downgrades in maximum convoy weight can be made, because that would essentially disallow the construction of new bridges on PROW ways in general (normal ways do not have a maximum weight at all), e.g. to replace a level crossing by a bridge.

About 2) Vladkis comment is a good one. Anyways, in the first place I'd argue paying thrice for a single tile is not optimal but given slopes are usually only a minority in tunnels, the overall cost won't increase that drastically.
On the other hand, I see a rather simple solution to this: If players could build tunnel slopes immediately, they would do so. So why don't we simply consider new ways "temporary" for a fairly long amount of time, in which those can be aligned without charging destruction and re-construction costs. Any alignment would then again set the tiles state to temporary, so full height slopes could either be made by paying the full price of the alignment but only once the construction costs.

Another thing to consider about Vladkis comment is the cost to build tunnel slopes. In the real-world, it doesn't matter if a tunnel is drilled flat or with a slope, so the "terrain" alignment itself of tunnel tiles might come for free.
I must admit, that's not the whole story. In fact, it might make a difference if a tunnel is drilled straight or not, but that's by far beyond the simulation, as the most important factor here is the type of stone being drilled through. The slope by itself really is not a big thing.

Edit:
A new way to build tunnels (and maybe elevated ways) might also be a good thing, but I cannot imagine any such that does not involve an entirely new construction tool.
If you know roller coaster tycoon, I think their way of building tunnels and elevated ways/bridges (it's both the same there) is very comfortable and could work well in simutrans either, but as mentioned, it's a major new feature.

Offline Vladki

  • Devotee
  • *
  • Posts: 3439
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
@freahk, I have changed the diversion limit to 200 tiles (25 km) on stephenson-siemens.
Can you try some bigger city reconstructions to see if any of your proposals are still needed?
Because my feeling is that all you needed is a way to avoid the miscalculation of diversion limits.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 20266
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
So, in principle we agree that merging this micoromanagement into a single step is a workable solution to the above mentioned issues?

Yes, indeed, providing that this gives rise to no new economic exploits as discussed above.

Quote
Further thoughts:
About 1) I do not think there is a workable solution that does further ensure no downgrades in maximum convoy weight can be made, because that would essentially disallow the construction of new bridges on PROW ways in general (normal ways do not have a maximum weight at all), e.g. to replace a level crossing by a bridge.

One could have a system in which the minimum bridge weight of a bridge replacing something that is not a bridge must have a certain relationship with the maximum axle load of the way; so, for instance, suppose that the maximum axle load of the way were 2t and the way were a road; one might infer that road vehicles tend to have 2 axles, and require a bridge with a maximum weight of no less than 4t.