New system for elevated ways (inc. half height and uneven terrain)

[PJMack]

As requested in another forum post, the piers are now discounted in cost when building a parallel one.  The discount is fixed 50% as I would need to request an increment in revision number to make the setting changeable such that it is saveable. 

While at it, I also fixed a bug that occurs when loading a file with a pier that is no longer in the pakset, as well as adjust the display order so fields are no longer drawn on top of piers.  I also merged my pier_system branch, with jamespetts' pier_system branch which as been recently merged with the master branch.  I did need to fix make and cmake configurations which were somehow lost during the merge.

[jamespetts]

Excellent, thank you for this. Unfortunately, I get merge conflicts when trying to merge this with the latest master; I think that the problem is the recent merges from Standard.

I should be grateful if you could look into this so that I can test a fully merged version - thank you.

[PJMack]

It should be fixed now.  It was from a recent merge with standard in bauer/hausbauer.cc.

[jamespetts]

Thank you for this. I have incorporated this into my pier-system branch and this now compiles. Unfortunately, I am now getting crashes on attempting to generate a map: I get assertion failures at line 3576 in simcity.cc followed by an access violation crash if I ignore them and carry on. The assertion line appears to relate to road building. I have not changed any city building code, so I can only infer that the issue has arisen somewhere in the merged code on the piers branch.

I should be grateful if you could look into this. Thank you.

[PJMack]

Apparently I did not do a good enough job merging bauer/hausbauer.cc.  It should be fine now.

[jamespetts]

Apparently I did not do a good enough job merging bauer/hausbauer.cc.  It should be fine now.

Excellent, thank you for that: this now appears to be fixed.

I have had some time to test this to-day. The new concrete and wooden elevated way supports do look good - I like the way that the concrete type transitions between different sorts of supports depending on its height.

However, I have encountered some anomalies. First of all, the brick arch structure seems to be corrupted at heights > 2:



The same appears to be so of the stone structure:



Also, it appears possible to build a road or railway on an aqueduct, which I am sure should not be possible:



There are also some complex issues with height. See the below for a reference:



The maximum starting height that I can set in the tool menu is 8 for all piers, and all will build with this height set. However, it is possible to add a large number of additional layers by building an elevated way support over another such structure already at height 8, giving in effect height 16. This cannot be done for a second time. However, starting on high ground and moving over lower ground, heights in excess of 16 can then be reached.

It is evident that many elevated way supports could simply never have been built to these heights: the concrete types have legs that are evidently impossibly spindly at this height, and the wooden type would clearly have collapsed under its own weight at these towering altitudes. Can we not have pakset specified height limits for the piers that are made clear in the tooltips, and enforced in the starting height, crossing heights and when moving over lower terrain?

Thank you again for your work on this: it is much appreciated.

[PJMack]

First of all, the brick arch structure seems to be corrupted at heights > 2:

Not again...  Since the wood and concrete piers are working, I do not think this is the same issue as before.  Re-merging with master did not cause the issue to occur on my machine.  I checked the log files for github's automated build and there are no compiler warnings for the pier system code.  (Other than pier_desc_t::get_above_slope, which is not used in this scenario.  Also the warning given is completely incorrect and suppressing it would have performance implications.)  I also checked again with Valgrind.  If a third person could verify this, that would be helpful.  Also, I don't suppose you could send me generated assembly for pier.cc and pier_builder.cc (MSVC "/FAsu" flag)?

Also, it appears possible to build a road or railway on an aqueduct, which I am sure should not be possible

I had not thought this to be possible either until I found that the River Cart Aqueduct was converted to a railway viaduct in the 1880s.  I am not sure, however, of the details or the practicality of such practice.

The maximum starting height that I can set in the tool menu is 8 for all piers, and all will build with this height set. However, it is possible to add a large number of additional layers by building an elevated way support over another such structure already at height 8, giving in effect height 16. This cannot be done for a second time. However, starting on high ground and moving over lower ground, heights in excess of 16 can then be reached.

It is evident that many elevated way supports could simply never have been built to these heights: the concrete types have legs that are evidently impossibly spindly at this height, and the wooden type would clearly have collapsed under its own weight at these towering altitudes. Can we not have pakset specified height limits for the piers that are made clear in the tooltips, and enforced in the starting height, crossing heights and when moving over lower terrain?

When reading the documentation and code comments prior to starting this, I found a comment noting the maximum height above ground that the graphics system can handle correctly.  I thought that height was eight tiles, though that comment could have been before the tile heights were halved. 
When doing the initial planning, I had set aside a variable for maximum height for a per pier basis, but put that feature on the back burner as I did not think it was critical.  I can add that feature if needed.
For the graphics scale, a single tile is 6 meters tall, so 8 tiles would be 48 meters, no taller than the Millau Viaduct, Goat Canyon Trestle, or Göltzsch Viaduct.

[PJMack]

After giving it more thought, the anomaly does appear similar to the one before.  I put an assert statement in pier_reader.cc to detect if the deprecated makeobject-extended crept back in.

I also added the missing code for height limitation.  "max_altitude" is height above the ground: 0 is no restriction, numbers greater than 15 reserved for future use.

[jamespetts]

Apologies for not having had time to look into this for a while: I have been preoccupied with a number of other matters.

I am currently staying with my parents and using my Linux machine. However, I notice that we now have a merge conflict in hausbauer.cc when merging with the latest changes on the master branch. I should be grateful if you could look into that so that I can test this further. Thank you.

[PJMack]

I fixed the merge conflict and added the instructions while at it.  The github auto tests for MSVC no longer work as discussed elsewhere in the forums (something to do with github updating to a new virtual server instance?).

I also pushed a pakset update that deprecates some of the old bridges and adjusts some of the old graphics.  I am still working on setting the prices.

[jamespetts]

Thank you for that: merge conflict confirmed resolved. I confirm that I am now able to compile and test this successfully again. I have pushed my merges to my pier_system branches for both pakset and code.

Current observations are as follows.

(1) The height limit has been implemented so far only for the "El" type support (we will need a clearer name for this in due course). However, this is not very transparent to the player: there is nothing in the tooltip about this height limit and attempting to build at maximum height (4 tiles) and then drag over a lower area produces inconsistent results: half a tile lower, it will still drag (but it is then impossible to build a new support starting at the same height), but trying to drag over anything more than half a tile lower will result in it failing with "cannot find valid route", without giving the player any clue that the issue is height. We do need to have more consistent behaviour with the height limit and also a system for communicating this clearly. Nonetheless, a height limit is definitely a major advance.

(2) Related to the question of height limits, there remains inconsistent behaviour with the starting height dialogue: it remains possible to build the supports higher than the maximum starting height of 8, making it impossible to build a support to match the height of that already built. I would suggest modifying the behaviour such that the maximum number in the dialogue is always equal to the height limit, and that there be an implicit height limit for all piers whose height limit is not specified in the .dat file (perhaps whatever the maximum possible height limit is).

(3) It is still not obvious from the tooltip which supports can support intersections: so far, only the concrete, brick and stone piers seem to support intersections, but this can only be worked out by trial and error.

(4) Intersection behaviour is also somewhat arbitrary; it seems that it is possible for two support types to intersect where only one has the property of being able to intersect so that, for example, a wooden and a concrete support may intersect even when two wooden supports may not. Was this intentional? If so, may I ask the reason for this?

(5) It is still possible to build railways, etc., on top of aqueducts. I note that you refer to a source suggesting that this was done once; are you able to give any more details? I am not sure whether this is plausible in the majority of cases. If anyone else has any information on this, that would be most helpful.

(6) I cannot reproduce the corrupted graphics problem on my Linux machine, and I am away from my Windows machine at present. I will re-test this after I return to my Windows machine, when I get a chance.

(7) I think that the best way of handling the menus is ultimately to move the elevated way support icon from being a main toolstrip icon in its own right to being a member of all of the way building toolstrips (rail, narrow gauge, canal, road, etc.) that are compatible with any of the elevated way supports in the pakset. This is because I think that it is confusing for players to have to look in two different places for tools to build transport infrastructure. Players would expect to find all of the tools for building bridges and bridge like structures together, rather than in different places. What I would suggest doing is modifying the icon that you currently use to add the letter "E", indicating that these are elevated ways, to make this consistent with the old integral elevated way types, which will be more familiar to most players, and should also be clear to new players.

( We do have an anomaly when an elevated way support ends on a diagonal and a way is continued over it: the alignment of the last tile of the way does not match the alignment of the last tile of the elevated way support. See this screenshot for an example:



(9) Dealing with legacy bridges is complex. Currently, we have, e.g., "Brick arch viaduct", which can only be built for a tile or two. This is likely to confuse players greatly. I suggest that these legacy bridges preserved for their ramps only should be renamed to "...ramp", e.g., "Brick arch viaduct ramp".

(10) The stone arch viaduct does not seem to retire. May I ask why this is?

I should note that I have not yet checked/tested the prices, which I intend to do when everything else is ready; and I note in any event that you have not finalised these.

Thank you as always for your work on this.

[PJMack]

To answer your responses:

(1) The height limit is only applied to the "El" as the happened to be what I was using to test the height limit code, and it was the only one, at least to my eyes, where the supports looked too thin for heights that could reasonably by expected for a player to find practical.  For the algorithm itself, I was going for simplicity; the height is measured from the lowest point on the ground tile to the point on the ground.  I will look into adjusting the error message.  For the name, I did use a more local term that probably could change, but what to, I am not sure.

(2) I will look into this.

(3) The reason only those three types support intersections are that those are the three types where I could find real world examples of intersections, and I did not want to add more graphics than needed for realistic and balanced game-play.  As for indication to the user, a simple solution would be to add "J" to the icon.

(4) This is somewhat intentional.  I had intended for concrete, brick and stone to all intersect with each other, however as a side effect, connections can be made to wooden piers as well.  There is a way to fix that if desired.

(7) This is not a bad idea.  I should note that I had originally intended to also allow certain piers to support buildings (such as the supermarket overpass on the Mass Pike) hence I had considered the system to be more general that simply transportation infrastructure, however until that feature is implemented, I can see why moving the menu is a better idea.

( I had noticed this, however as the situation would be unlikely to arise except during construction, was no worst than the some anomalies of the previous elevated system, and would be a difficult fix, I did not think it would have been worth the effort.

(9) I will adjust the names then.

(10) This may be a discussion for another post, however since the technology to build stone arch bridges has not been lost, I see no reason to prohibit a player from building one in the modern era.  It would no longer be the most economical bridge to build, but a play may still want to build one as a status symbol for for aesthetic purposes.  Likewise, none of the other pier types (except a few pier blocks) have retire dates, however the economics are such that as technology progresses, it no longer becomes advantageous to use the older styles.

[jamespetts]

Thank you for your prompt responses. I shall respond in correspondingly numbered paragraphs below.
(1) We definitely need height limits on all the piers, I think, or else we get anomalies like this:

As to the names, we can finalise all of these in due course; but we do need clear and consistent naming.
(3) Adding a "J" to the icon may well help to an extent, but more will be needed, since it is not obvious to a new player what "J" means here. I suggest adding something to the tooltip.

(4) I strongly suspect that any reason that would be sufficient to prevent wooden elevated way supports from intersecting with other wooden elevated way supports would also prevent wooden elevated way supports from intersecting with concrete, brick, etc. elevated way supports, so I do suggest that this be changed.
(7) If and when you do implement using these as supports for buildings, you can always simply add the menu icon into the toolstrip of whatever menu is used for constructing the buildings.
(8) Noted - if this is a difficult fix, it is probably not an efficient use of your time.
(10) We do need retirements, I think. We can say the same about every object in the game, but it would be silly for players to have the option to build steam engines in the 21st century, for example; retirements reduce menu clutter, remove options that no player would ever sensibly want to take, and represent the fact that it is usually not, in fact, practically possible to use very obsolete technology, either for economic or regulatory reasons. Thus, we need to retire things as soon as they are replaced by something unambiguously better in every way, or something that in real life meant that the previous type were never built at all.

[jamespetts]

Incidentally, I should note that I am just about to merge in some changes from Standard, including changes that will affect the revision number, so you will need to update the revision number on this branch and be prepared to resolve any possible conflicts shortly.

[PJMack]

I added " (Limit %d tiles above grade)" to the tooltip and adjusted the height selection dialog to max out at the maximum height.  I could not find a easy way to return any verbose error messages in the auto building as it uses what is effectively a hyper-dimensional route finding algorithm.  Each dead end path would have a different reason for it, and trying to keep track of them all would be detrimental to performance. 

I just pushed the new prices for the piers and bridges.  The pakset adjustments below (numbers 1,4,7, and 10) are on my TODO list.  I am still debating the best way to go about (3).

As for savefile revision number, I am actually yet to need to change it, only the sub-revision number of the pier node in the pakset (which is unique to this branch). 

[PJMack]

I added the height limitations, disallowed having other piers cross a wooden one, and adjusted the naming of some of the bridges. 

For the menu, I hit a snag.  A sub-menu can only be linked to a single menu button.  This means either messing with the menu code, creating several identical menu bars, or leaving it as is.

As to the retirement dates, that may be a topic for the historic accuracy vs balance sub-forum, however unlike introduction dates, there is a wide grey area on when the infrastructure is obsolete.  Steel and Wooden bridges/viaducts are still being constructed in North America, and the longest span stone bridge opened in 2001 in china.  How do we want to define the obsolescence dates?

[PJMack]

I added "(Allows Junctions)" to the tooltips of piers that support junctions.  This does require a rebuild of makeobj-extended and rebuild of the pakset.  "(Allows Junctions)" is a translation defined in the pakset for the string "(PierTooltipA0)".  The reasoning for this is to allow a pakset designer to define extra tooltips if desired (currently two for auto tool build menu items and two for manual pier block menu items). 

I merge the pier branch with master.  I would consider the coding to be complete assuming the brick and stone arch anomalies described below is simply the result of an old makeobj-extended.  For the pakset, the only thing left are setting the retire dates for both masonry type piers (the other types are still in use) to, unless anyone has other opinions, sometime in the late 1940s.  Reducing the default alter land cost would help the balance as well, however for existing games, it would need to be changed manually.  A cost of around 1000¢ should be in the right range.

[PJMack]

For the pakset, the only thing left are setting the retire dates for both masonry type piers (the other types are still in use) to, unless anyone has other opinions, sometime in the late 1940s.  Reducing the default alter land cost would help the balance as well, however for existing games, it would need to be changed manually.  A cost of around 1000¢ should be in the right range.

These too are now complete.

[jamespetts]

Excellent, thank you very much for your work on this. Apologies that I have not had time to investigate this sooner.

This is now ready for incorporation, I think, and, indeed, I have now incorporated this into the master branch. This is really excellent work, and all of the work that went into refining this and improving it over the year or so that this has been in gestation has made this just right for Simutrans-Extended.

I have been making some minor alterations: I have put all of the names of the pier types into sentence case without capitalising all the nouns, I have renamed the "El" to "iron girder" and the "iron viaduct" to "iron lattice", and I have added the automatic pier building tools to all of the specific way type menus (although one refinement that would be good at some point is to exclude all the non-aqueducts from the water menu).

I have also amended the tooltip text in many cases to improve clarity, both in code and pakset, and added some missing English translations.

Testing shows that this does appear to work appropriately with existing saved games (I have tested this just now with the January 1938 Bridgewater-Brunel saved game from earlier to-day).

This is a real advance for Simutrans-Extended - thank you for your work on this.

[Matthew]

This is a great new feature and it opens up all kinds of possibilities. Thank you so much for your work on this, PJMack.

However, I am struggling to get my head around one aspect of the way that slopes have been set up. The following screenshot introduces the language that I am using to make my point


I have built a concrete viaduct from the western (top left) corner of the screenshot, on top of a long north-south slope. Since slope tiles are counted as being at the bottom of the slope, the way on the viaduct is one level about ground level: I call this +1. This wasn't possible under the old elevated system, so this new feature has saved me tens of thousands of Simucents, yay!

At the eastern end of the viaduct, the way must drop down to ground level (0). At the bottom right of the screenshot, I have built a concrete bridge, which automatically includes a +1 to 0 slope. But I can't build an east-west bridge slope over naturally north-south sloped tiles (e.g. on the tiles shaded in red).

I can get around this with some landscaping. But in trying to work around it, I noticed that all the slopes in the Elevated Way Supports Advanced Submenu are either +2 to/from +1 or a are 'steep' slopes that go +3 to/from +1. There don't seem to be any +1 to/from 0 slopes. This surprises me. It seems to run counter to all the other aspects of the elevated way system, where each element is no more than a single X/Y/Z element long. I wonder if I am missing something about the way elevated ways work. Is the omission of +1 slopes intentional or am I somehow muddled, please?

[PJMack]

I have built a concrete viaduct from the western (top left) corner of the screenshot, on top of a long north-south slope. Since slope tiles are counted as being at the bottom of the slope, the way on the viaduct is one level about ground level: I call this +1. This wasn't possible under the old elevated system, so this new feature has saved me tens of thousands of Simucents, yay!

At the eastern end of the viaduct, the way must drop down to ground level (0). At the bottom right of the screenshot, I have built a concrete bridge, which automatically includes a +1 to 0 slope. But I can't build an east-west bridge slope over naturally north-south sloped tiles (e.g. on the tiles shaded in red).

I can get around this with some landscaping. But in trying to work around it, I noticed that all the slopes in the Elevated Way Supports Advanced Submenu are either +2 to/from +1 or a are 'steep' slopes that go +3 to/from +1. There don't seem to be any +1 to/from 0 slopes. This surprises me. It seems to run counter to all the other aspects of the elevated way system, where each element is no more than a single X/Y/Z element long. I wonder if I am missing something about the way elevated ways work. Is the omission of +1 slopes intentional or am I somehow muddled, please?

There was an early attempt to allow slopes from, as you put it, +0 to +1 or +2, however it was determined quite quickly that the coding and pakset design for such would be quite complicated.  As the bridge system had this functionality, and the previous elevated way system used it, it was decided that continuing to use bridges for was acceptable.

As far as use of landscaping, the costs in Pak128.Britain-Ex were intended to be such that for most elevated way types building embankments (outside of cities) 2 tiles high is cheaper than building an elevated way 2 tile high.  This is true for brick and stone elevated ways.  For wood and iron, elevated ways, initial construction is cheaper than landscaping however they have high maintenance costs making them more costly in the long term (about 50 in-game years for wood). 

The concrete elevated ways are the exception.  Pak128.Britain-Ex costs are modeled on real-world costs in Britain for the year 1900, which was long before pre-stressed concrete was invented and all attempts at inflation adjustments lead to anomalous results.  Also costs for landscaping likely would have changed over the 20th century, which Simutrans-Extended currently has no mechanism for.  There are plans for a project to overhaul the cost and maintenance system to allow costs to be broken down into subcategories (such as labor and materials) and to change over time.

[Matthew]

There was an early attempt to allow slopes from, as you put it, +0 to +1 or +2, however it was determined quite quickly that the coding and pakset design for such would be quite complicated.  As the bridge system had this functionality, and the previous elevated way system used it, it was decided that continuing to use bridges for was acceptable.

Thank you explaining this. It's a pity from an aethestic and realism point of view, but I can well believe that just wasn't worth the effort. I can already see you are putting that time into other new features instead, which shows the wisdom of your decision.

Also, I think adding "brick arch ramp" to the way menus is a really helpful way to hint to newbies that ramps are built separately, so well done whoever thought of that.

As far as use of landscaping, the costs in Pak128.Britain-Ex were intended to be such that for most elevated way types building embankments (outside of cities) 2 tiles high is cheaper than building an elevated way 2 tile high.  This is true for brick and stone elevated ways.  For wood and iron, elevated ways, initial construction is cheaper than landscaping however they have high maintenance costs making them more costly in the long term (about 50 in-game years for wood). 

The concrete elevated ways are the exception.  Pak128.Britain-Ex costs are modeled on real-world costs in Britain for the year 1900, which was long before pre-stressed concrete was invented and all attempts at inflation adjustments lead to anomalous results.  Also costs for landscaping likely would have changed over the 20th century, which Simutrans-Extended currently has no mechanism for.  There are plans for a project to overhaul the cost and maintenance system to allow costs to be broken down into subcategories (such as labor and materials) and to change over time.

Again, thank you for explaining that the results I got with concrete are a special case. I know James made a monster post about pakset balancing a few months ago, but I have not sat down and read it because I think I will need a whole afternoon to take it in.

I also have an extension request.

With traditional bridges, we get a separate line in the info window displaying the bridge maintenance costs:



Elevated ways haven't had this maintenance cost breakdown in the past, but have you thought about adding them now that supports are clearly separated from track?

[jamespetts]

Somebody has made a Youtube tutorial about the new bridge system:

[wlindley]

Aha! Somehow I had misunderstood how to get things started; now it makes sense, even if it is not quite convenient or obvious how to make everything exactly.