The International Simutrans Forum

Simutrans Extended => Patches/pull requests for consideration => Simutrans-Extended development => Incorporated patches/merged pull requests => Topic started by: PJMack on October 06, 2021, 10:33:51 PM

Title: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on October 06, 2021, 10:33:51 PM
I have coded a new system for elevated ways that allows not only half-height elevated ways, but elevated ways on uneven terrain.  Such method involves an new object type pier and new ground type pier-deck where the ground is placed on top of a pier.  The system also allows the pakset designer to place restrictions on the ribi of ways both on the pier-deck and under it, as well as place restrictions on what types of piers can be built on others what other types and what types of piers can be placed on the same tile as another. 

This is still a work in progress, but is playable, although not all features are implemented yet (see details below).  The code in the pier_system branch on my fork of simutrans-extended (https://github.com/PJMack/simutrans-extended/tree/pier_system (https://github.com/PJMack/simutrans-extended/tree/pier_system)) with sample pakset material on the  pier_system_sample branch of my fork of pak128.britain (https://github.com/PJMack/simutrans-pak128.britain/tree/pier_system_sample (https://github.com/PJMack/simutrans-pak128.britain/tree/pier_system_sample)). 

There is one glitch with the graphics in that the images for the lowest piers (and any buildings on the same tile) are clipped, and am wondering if anyone has any ideas on the problem.  There are also some features not yet implemented, and a few that would need community discussion (for balance and preventing merge conflicts) before implementing

Status and pakset instructions is as follows:
Flat Decks on uneven terrain is completed.  There are three parameters for backimage, the slope of the ground, the orientation, and the season.  The slope of the ground is a two digit decimal as defined in slope_t.  If a particular slope is missing, a pier is not build-able on that slope.  The orientation (0 to 3) allows the user to build an asymmetric pier in any direction.  If the images for slope 0, orientation 1 is missing, it is assumed to be graphically 4 way symmetrical, else if slope 0 orientation 3 is missing, it is assumed to be 2 way symmetrical.  The season is not yet implemented.  Such parameters are available for the frontimage, but not required for functionality.
Two piers can occur on the same tile, provided that the bit fields in the 32 bit middle_mask are mutually exclusive.  Piers can be built on top of one another, provided that the base_mask bit field for the top pier is a subset of the support_mask bit field.  A pier can be placed on a way, provided that the way's unmasked ribi is a subset of below_way_ribi, and ways can be within a pier, provided that the reverse is true for all piers on the tile.  Likewise, to build a way on a pier deck, the ribi of the way is restricted to that of the above_way_ribi for the piers below. All masks and ribis are bitwise rotated along with the pier orientation (masks by 8 bits per rotation).  One additional mask sub_obj_mask, only partly implemented is whether piers could be build on buildings, and of what type.  For now, 0 means build of anything but attractions and townhalls, where 0xFFFFFFFF means do not build over any buildings.  It is planned to have a a corresponding mask for buildings for more fine grain control, however that would require modifying building descriptors, potentially making hard to fix merge conflicts for someone else.  Likewise four buildings on pier decks.  There are also other variables in the pier descriptor that have planned use, as commented upon in the descriptor header file.

One other question that remains is how to handle weight limits, as the pier would have to support not only the weight of ways, but the weight of other piers and the ways thereof?  I do have variables for future use in the descriptor for the weight limit and the weight of the pier itself, but that would not take into account dead load vs live load limits.  Also how would multiple vehicles and possible buildings placed on a pier be handled?

In the meantime, though I am not sure exactly how much free time I have, I plan on finishing more pakset examples, then continuing on with the minor features features to add, then possibly an automated dragging system for straight/diagonal sections of piers.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: prissi on October 07, 2021, 03:50:11 AM
If the pier is a way, then directional clipping is used to avoid artefacts from way going into next tiles. For that reason, elevated way using special ground tiles.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: Sirius on October 07, 2021, 05:20:25 PM
Quote from: PJMack on October 06, 2021, 10:33:51 PMI have coded a new system for elevated ways that allows not only half-height elevated ways, but elevated ways on uneven terrain.
This idea is awesome!
I just made CMake work with this branch here: https://github.com/irgend42/simutrans-extended/tree/pier_system

Currently, it feels a bit too complicated from players perspective, but I am quite sure this is subject to change.

A more automated construction tool is clearly desirable to solve this.
Considering this tool, it should not be the players responsibility to stack pier objects nor to decid whether and in which direction the pier should be passible underneath or not.
We might give an option to decide these details to the player, but there should be an automatic mode where the player doesn't have to care about this.
For example, he will simply drag the pier type like he would drag ways on flat ground and the tool will automatically fill the height difference with piers, considering and properly crossing potential objects below.
Surely, if there is no pier available in the  currently selected pier type that can cross those objects, construction will fail.

This does also affect the destruction of piers. When removing a pier object, automatically removing all pier objects down to the next non-pier object might be a good idea, so we can remove the whole stack in a single click, without automatically destroying the whole stack when there are multiple ways stacked on top of each other.
A way-removal tool might also be useful, so the construction can be dragged just like it was constructed.

Anyways, that's just my thoughts about such tools. You might have an entirely different idea.


A few more rather minor things I have noticed. I am aware that this is a very early state, so you might or might not already be aware of these:
Tracks cannot pass diagonally underneath two-tile piers.
Piers can be built a half-height above tracks, but ways cannot be placed on top.
There are no pier slopes (yet) You mentioned these will be implemented later on I guess.
There is no decoration of ways on top of piers (yet). You might need a waytype specific pier topping to make it look beautiful

That's my testing so far.



Let's get to the remaining questions
Quote from: PJMack on October 06, 2021, 10:33:51 PMOne other question that remains is how to handle weight limits, as the pier would have to support not only the weight of ways, but the weight of other piers and the ways thereof?  I do have variables for future use in the descriptor for the weight limit and the weight of the pier itself, but that would not take into account dead load vs live load limits.
This is indeed difficult as the effect of live load on the pier is non-trivial.
I don't think we have to simulate this physically preciese. There is a simplified, not physically peciese, live load system on bridges (and iirc on ways using axle load) already.
Bridges can be passed at lower speeds when "too heavy". A rather simple calculation is used to determine the speed when too heavy.

On piers (and then ported to bridges) we might maintain an "effective load limit", instead of dead load/live load.
Effective load of a single object depends on its mass and speed.
A sensible translation function calc_eff_load(speed, mass) is needed, where calc_eff_load is a continous function withcalc_eff_load(0, mass) == mass calc_eff_load(speed, 0) == 0
Then, we can handle requests to put a load on a structure by determining if there is enough effective load remaining to support that additional load.
If so, all right! Do it! If not, deny the construction! In case of vehicles, we then have to determine if the vehicle could enter at lower speeds. If so, let it pass at that speed. Otherwise it has to wait.



QuoteAlso how would multiple vehicles and possible buildings placed on a pier be handled?
A difficult one, which I cannot really provide an answer to.
Here are my thoughts, maybe this is a useful start to create something more sensible.

At first, we need to know about ways in the same pier stack. To do so, we can maintain an object shared by the whole stack of piers.
That object will maintain the remaining effective load the stack can support.
A vehicle entering (or reserving) a tile will check how much additional effective load the stack can bear.
Based on that information, it will either continue at full speed, reduced speed or wait until it can proceed.

The issue about this is deadlocks. If two vehicles drive in opposite directions at different heights, those might not be able to pass each other because of the weight limits.
Furthermore, this simple approach will only let one vehicle move if they can pass each other but one of them already "consumed" all of the remaining effective load.
An experienced player will ensure that such deadlocks cannot happen, but to new players this might be confusing.



Last but not least, all of these masks seem quite complicated in the first place from a pakset authors perspective, but I cannot imagine a simpler way that maintains the necessary level of control.
The sub_obj_mask doesn't seem quite sensible to me though. It should be the buildings responsibility to permit ways above or not.
There are two things to consider: Building clearance height, which can be roughly extracted per tile from buildings images. No building dats have to be touched to obtain this data.
As some buildings might request a higher clearance than the visual building height, an additional height attribute per building tile might be introduced to control this explicitly.
Currently, the decision if an elevated way can be built or not is based on the building level, which is not a good idea as some buildings are visually high although their level is low, so bridges sometimes just cut the roof :O

Back to sub_obj_mask I'd just use support_mask here in the same way as it is used on the piers. If the base_mask of the pier above matches, it's all right.
As we don't want to touch all buildings, it might be sensible to provide defaults in simuconf.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on October 08, 2021, 02:42:13 AM
QuoteIf the pier is a way, then directional clipping is used to avoid artefacts from way going into next tiles. For that reason, elevated way using special ground tiles.
The pier is not a way, but inherits obj_no_info_t.  The pier-deck inherits grund_t.  I did look at monorailboden_t and brueckenboden_t, however the main difference is that in this case, the pier is in the tile below the pier-deck.  I should also not the during development, when before pier-deck was implemented, the pier was visually fine.

Quote from: Freahk on October 07, 2021, 05:20:25 PMThis idea is awesome!
I just made CMake work with this branch here: https://github.com/irgend42/simutrans-extended/tree/pier_system
Thank You.  I cherry-picked the two commits into my branch.

Quote from: Freahk on October 07, 2021, 05:20:25 PMA more automated construction tool is clearly desirable to solve this.
I had intended (and have some descriptor variables prepped) for a system very similar to what you described, however such undertaking would be complicated (particularly for diagonals), and would like to make make sure that the manual building is working well before attempting such feat.  Even when such system is implemented, I would still like to leave the manual control for the players, as it may still be useful for their future planning and artistic side. 

Quote from: Freahk on October 07, 2021, 05:20:25 PMPiers can be built a half-height above tracks, but ways cannot be placed on top.
There are no pier slopes (yet) You mentioned these will be implemented later on I guess.
I just pushed the fix for these.  The former was a typo.  For the latter, I made it so that piers that can support ways check the such ways would not interfere with existing full height ways.
Quote from: Freahk on October 07, 2021, 05:20:25 PMThere are no pier slopes (yet) You mentioned these will be implemented later on I guess.
There is no decoration of ways on top of piers (yet). You might need a waytype specific pier topping to make it look beautiful
The slope is probably next on my list after finishing the (temporary?) graphics for the brick piers.  For the decorations, there are already hundreds of images per pier needed for the various ground slopes, I am not sure adding more is such a great idea, however if popular demand proves otherwise...

I did have somewhat similar thoughts on the weight, with the exception of the weight limits of the ways distributed to avoid deadlock scenarios.

The purpose of the sub_obj_mask is to allow some special buildings to coexist in with a pier, such as arch shaped buildings below arches (as found in the UK) or triangular shaped skyscrapers next to a diagonal pier.  As I neglected to mention earlier, it is a supplement to what would be a mirror of the existing systems for buildings vs bridges. 
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: Sirius on October 08, 2021, 04:04:16 PM
Quote from: PJMack on October 08, 2021, 02:42:13 AMThe purpose of the sub_obj_mask is to allow some special buildings to coexist in with a pier, such as arch shaped buildings below arches (as found in the UK) or triangular shaped skyscrapers next to a diagonal pier.  As I neglected to mention earlier, it is a supplement to what would be a mirror of the existing systems for buildings vs bridges.
Oh I see. sub_obj_mask represents the 3D shape ob the object, wherease support_mask and base_mask is about pillar positions, or locaions strong enough to support these, usually on a 2D plane.
In that case I don't see a difference in between sub_obj_mask and middle_mask , which both describe the 3D shape and should both be handled mutally exclusive.

What about using both, support_mask and shape_mask (just a renamed middle_mask) on buildings?
Basically, they are just like piers in this manner (or piers are just like buildings) They have a shape and they might not permit pillars to be placed everywhere.
shape_mask and support_mask might even be coded into a single 64 bit flag as (12x12x12)x(12x12)x4, so both have a grid of 12 possible positions in each direction.

Quote from: PJMack on October 08, 2021, 02:42:13 AMAs I neglected to mention earlier, it is a supplement to what would be a mirror of the existing systems for buildings vs bridges.
Apropos Bridges. The pier system has the potential to naturally merge elevated ways and bridges to become technically the same thing.
It makes viaduct bridges obsolete anyways. The only thing it does not cover is spanning bridges, i.e. ones that do not need any pillars below, but are restriced in length.
You might keep this in mind, although I suspect it might be rather complicated to integrate such bridges properly into the pier as it seems to require multitile piers.

This work is really quite awesome :)
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: Matthew on October 08, 2021, 09:19:23 PM
As Freahk said, this is awesome!

It is a great new feature for Extended, so thank you very much for contributing both the code and the graphics.

There are so many great points about this!:

Thank you so much for your efforts!

I don't have the technical expertise to comment on the code, but here is some feedback as a player.

Terminology and Restrictions

Quote from: Freahk on October 08, 2021, 04:04:16 PMApropos Bridges. The pier system has the potential to naturally merge elevated ways and bridges to become technically the same thing.
It makes viaduct bridges obsolete anyways. The only thing it does not cover is spanning bridges, i.e. ones that do not need any pillars below, but are restriced in length.

I see what you are proposing here, but there are important distinctions between the existing in-game elevated ways compared to in-game bridges. The bridges can be built over "high buildings" (e.g. factories; I am not sure exactly how this group is defined), but elevated ways cannot. Some simple tests suggest that piers cannot be built on attractions or town halls, but certain types of piers can be built on factories. In fact, this new system is so powerful that it enables players to build ways all over cities without buying the underlying land. This is totally contrary to how ways are constructed in real life. It is already the case that most players never build railways at ground level in cities from the moment that elevated ways appear, so I hope we won't remove what few restrictions there are.

And the existing, viaduct bridges are only obsolete if there is an automated mode for the simple construction of pier-based viaducts. I agree with both of you that an automated mode would be ideal, but what has been added is already a very useful addition to the game.

Another point is that "elevated" means means slightly different things to different people. PJMack, you are totally correct to say that this is a new system for elevated ways, as it allows players to place ways at a higher level than the ground. But an "elevated railroad|way" sometimes means something more specific: railways built above urban streets, most famously the Chicago El. The Oxford English Dictionary defines (https://www.oed.com/view/Entry/60415?rskey=WdfVUg&result=2&isAdvanced=false#eid) "elevated railway" as "a railway supported on pillars above the street-level" - which rather assumes that it is being built above or alongside a street, not through the countryside or over a river. So perhaps this feature could be called "viaducts" or "customizable viaducts" to avoid confusion?

Load limits

Everything said so far seems sensible, though I worry a little that if vehicles' ability to use a way depends on what other vehicles are on the same viaduct, then it has potential to cause sudden and unexpected changes in routing. But this is really not my field of expertise.

Graphics

The existing graphics seem "brighter" than any other brickwork in the pak, which is intended to simulate the grey, cloudy ambience of the British Isles. But in Simutrans development something is better than nothing! I am grateful that you have contributed graphics, PJMack, because it enables us to see how powerful and beautiful this feature is. As you say, hopefully these will be temporary until eventually we can convert the existing bridge textures for the new system. May I ask whether you are producing these images in a pixel editor or in Blender? If it's in Blender, then I might be able to help.

Economics

Coincidentally, for the last few weeks I have been collecting data about elevated railways (https://github.com/MatthewForrester/simutrans-extended/wiki/Elevated-railways-in-19th-century-British-Isles), because it seemed to me that elevated ways are currently far too cheap and perhaps also too early in pak128.Britain-Ex. I hope to post firm proposals for improving the pakset's balance soon, but I will need to rethink them in the light of this development. And in case I may make a separate thread so that this one can focus on this wonderful new feature.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on October 09, 2021, 02:49:57 AM
Quote from: Freahk on October 08, 2021, 04:04:16 PMThe only thing it does not cover is spanning bridges, i.e. ones that do not need any pillars below, but are restriced in length.
I neglected to mention that spanning bridges from pier to pier is actually working.  The caveats being that one of the piers needs to have the proper way on it, and is suffers from the same bug the the existing elevated ways (eg. sometimes needing to build a bridge on ordinary land first with the same tool).

Quote from: Freahk on October 08, 2021, 04:04:16 PMWhat about using both, support_mask and shape_mask (just a renamed middle_mask) on buildings?
I did think of this, but have separate masks would allow more flexibility for pakset authors with a negligible amount of extra coding for the mechanics.

Quote from: Matthew on October 08, 2021, 09:19:23 PMThe bridges can be built over "high buildings" (e.g. factories; I am not sure exactly how this group is defined), but elevated ways cannot
I did look into the this.  When deciding whether or not a bridge is build-able, the code only checks for obstructions so many (I think three) tiles below the bridge deck, otherwise the mechanism is the same in checking the "level" of the building against a threshold.  Such level threshold is not a perfect system, but I will probably code it into piers as well.

For graphics and economics, they are somewhat temporary and for demonstration.  I do use blender 2.93.3, using animation to take care of the several images, then generating the icons and tiling the files with a bash script calling imagemagick. 
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on October 09, 2021, 08:27:32 PM
Just a status update, sloped piers are now working.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on October 13, 2021, 08:10:59 PM
A pull request for both simutrans-extended and simutrans-pak128.britain have been submitted on github, as they are to the point where it is playable and relatively balanced.  For automation, a simplistic dragging system is in place for certain types of piers (straight, diagonal, and 4-way), where one would drag while placing the pier rather than clicking.  (There is a slight bug where an extra pier is created upon mouse release).  For the clipping issue, I managed to turn off the clipping for the pier-deck tiles, however this results in other odd clipping when piers are placed on trees or buildings, but is overall less noticeable.  As the existing elevated way system only has axle load limits, no per tile weight limits, the weight limits for piers is not implemented either.  As for cost balancing, for the pakset side of things the cost is a little lower than that of a brick viaduct bridge for a single height arch, with costs of arches, filled piers, and pillars adjusted by type.  This is assuming 125m per tile.  As no other pier types have been authored, for now the brick pier has no temporal restrictions on use.


As secondary (not to be a PR unless explicitly requested) branch of pak128.britain (https://github.com/PJMack/simutrans-pak128.britain/tree/pier_system_extras/piers/extras (https://github.com/PJMack/simutrans-pak128.britain/tree/pier_system_extras/piers/extras)), I placed the blend file and bash script used to create the brick piers.  Also in the directory is the lighting map for the blend file, and button image for the bash script, as well as the spreadsheet used to calculate each brick pier's costs.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: Sirius on October 13, 2021, 08:42:44 PM
So the PR is ready for incorporation into master?
About the blender sources, there is a repository specifically for blends: https://github.com/jamespetts/Pak128.Britain-blends
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on October 13, 2021, 09:33:59 PM
Quote from: Freahk on October 13, 2021, 08:42:44 PMSo the PR is ready for incorporation into master?
I believe so.  Granted, it is up to the main developers, if their opinions differ, then it would not be ready.
Quote from: Freahk on October 13, 2021, 08:42:44 PMAbout the blender sources, there is a repository specifically for blends: https://github.com/jamespetts/Pak128.Britain-blends
This is where things get tricky due to licensing and me not being a lawyer.  As the bash script uses an image (button.png) that is already part of pak128.britain (within another image), the artistic license implies that I can only reproduce such image as part of a modification for pak128.britain, unless such image is already in the public domain which unclear at this point.  Although it appears that the transfer of the file would be permitted from the github's terms of service, from what I gather, it would be restricted to reproduction within github.  Also as Pak128.Britain-blends does not have any license file, it can only be reproduced in accordance to github's terms of service unless granted by another license provided by the owner.  The conclusion that I came up with is that, unless whoever created the image information contained in "button.png" grants permission for it to be extracted from pak128.britain or it is confirmed to be public domain, the best way to keep the information in one place is to put it as a branch to pak128.britain.  Again, I am not a Lawyer, and am not qualified to give any legal advice.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: prissi on October 14, 2021, 05:54:05 AM
James is, but he is not here. However, large parts of pak128.britain-extended started from pak128.britain and there was quite some interaction for some time, so the license must be compatible, I think.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: Sirius on October 14, 2021, 12:25:24 PM
Briefly tested. There are a few things to note:

I noticed a serious issue related to land ownership. Piers can be placed on land owned by a different player. This might be desired so far.
When doing so, none of the players can remove the piers nor the tracks on that tile.

Secondly, the dragging tool is really useful. It saves a lot of time!
On the other hand, this makes a proper remove tool even more important as players can easily build huge pier structures, which will be a pain to remove afterwards.
For now, something as simple as removing the whole stack bottom-up or top-down when using the general bulldozer tool should be sufficient.

Thirdly, for some reason the code formatting CI check fails.

Might take a while until James pulls this in, so it becomes available in bridgewater-brunel nightlies.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on October 14, 2021, 05:18:11 PM
I have put the PR in draft mode to take care of the issues that have arisen.

Quote from: Freahk on October 14, 2021, 12:25:24 PMI noticed a serious issue related to land ownership. Piers can be placed on land owned by a different player. This might be desired so far.
This is deliberate as the current elevated way system allows elevated ways to be built on another players land.
Quote from: Freahk on October 14, 2021, 12:25:24 PMWhen doing so, none of the players can remove the piers nor the tracks on that tile.
This is not, I am working on a fix.
Quote from: Freahk on October 14, 2021, 12:25:24 PMthis makes a proper remove tool even more important as players can easily build huge pier structures, which will be a pain to remove afterwards.
For now, something as simple as removing the whole stack bottom-up or top-down when using the general bulldozer tool should be sufficient.
I will also be working on this.
Quote from: Freahk on October 14, 2021, 12:25:24 PMfor some reason the code formatting CI check fails.
I am not sure what is going on as this is the error recieved: error: pathspec 'pier_system' did not match any file(s) known to git.  As far as I can tell, the test bench is not retrieving the code from git properly.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: Sirius on October 14, 2021, 06:27:38 PM
Don't mind about the failed CI run, this is an isue in the configuration. I have already prepared a fix to this on https://github.com/simutrans/simutrans-extended.

In the meantime, you can fix this by running cleanup_code.sh manually.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on October 14, 2021, 10:19:51 PM
I believe I corrected the aforementioned faults and have updated the branch for the PR.

Piers can be deleted from the deck via the bulldozer tool, and holding control when clicking will result in the pier stack to be deleted (with the checks run on a per pier basis).  Also, ways on the same ground tiles as piers can now be deleted by the way owner.  Also the way owner has the privilege of removing the pier of the other player, provided that the pier is not load bearing (which would not be the case if the pier is still in use).  Also low piers can no longer be built on public rights of way, and trees are felled for pier construction.




Now the Upload Artifact (Cl) stage of the macOS (headless) check failed with error: Error: Create Artifact Container failed: getaddrinfo ENOTFOUND pipelines.actions.githubusercontent.com.  Does anyone know what the cause could be?
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: Sirius on October 17, 2021, 01:32:30 PM
Forgot to mention, this is now incorporated in simutrans/simutrans-extended
I could not reproduce the CI issue. Searching for this, it might have been a temporry issue with guthub.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: freddyhayward on October 19, 2021, 08:04:40 AM
Two issues in no particular order.
1. It is currently possible to 'raise' pierdecks using the all up slope tool. Doing so seems to change its actual location without changing its graphical location, allowing ways to be placed as if floating midair. It is impossible to delete these pier decks without first rebuilding lower pierdeck in its old location.
2. The system is very unintuitive to use. I'm sure you're aware of this and the range of things that could help, such as an automated mode. But ease-of-use should certainly be the priority going forward.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on October 19, 2021, 07:10:03 PM
Quote from: freddyhayward on October 19, 2021, 08:04:40 AMIt is currently possible to 'raise' pierdecks using the all up slope tool
I just fixed this and submitted an new PR to simutrans/simutrans-extended, and updated the PR to jamespetts/simutrans-extended.

Quote from: freddyhayward on October 19, 2021, 08:04:40 AMThe system is very unintuitive to use
I did try to make this as intuitive as I could for now, and I do plan on updating the help menu and packset documentation, but for now here is a summary:

As with station buildings, control click the tool icon to select the orientation.  For some piers, a rudimentary, but usable, dragging system is in place where one can hold the mouse button down to place piers in a straight or diagonal line (there is a known bug though, as explained earlier).  For where piers can be placed in relation with ways, it is up to the packset designer to use the ribi filters to make sure that if it looks like a pier would block a way, it blocks a way, and if a pier blocks a way, it looks like it blocks a way.  Likewise the pakset designer would use the masks to make sure that if it looks like a pier cannot fit or be supported, then it cannot be placed, and if a pier cannot be placed, it would not look to be possible to place it.  The remove tool will only delete a pier if it is not supporting anything else.  Holding control when clicking on top of a pier stack with remove tool will remove most of the stack, or as many non load-bearing elements as possible.

As for a fully automated mode, It will depend on how much free time I have for coding.  I would first need to fix the bug with the current dragging, as well as the fact that the snowline is not handled as of yet. I would like to complete more of the graphics as well.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: freddyhayward on October 20, 2021, 07:06:06 AM
Quote from: PJMack on October 19, 2021, 07:10:03 PMAs with station buildings, control click the tool icon to select the orientation.
This is quite inconvenient. Maybe it would be better to have a separate toolbar button for each direction as is the case with terraforming?
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: Sirius on October 20, 2021, 12:04:00 PM
I have noticed another thing which might or might not be intentional but somehow feels weird:
You can remove a single pier object by using the remove tool on the deck or on the ground below. When using ctrl+click, you have to click on the pier deck and there can be a notable lag.

Quote from: freddyhayward on October 20, 2021, 07:06:06 AMMaybe it would be better to have a separate toolbar button for each direction
That would make things even more complicated to players, as this would add very many buttons to the menu and some of them already are rather difficult to distinguish...
What would really help, in my opionion is to automatically select the proper pier and pier direction when dragging, Diagonals already do so partially when draging diagonals. For now, it might be a solution to build piers when either releasing the mouse button or the cursor is leaving the tile, so the tool could calculate the direction in that case. In case of diagonals this requires one further tile though.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: Sirius on October 20, 2021, 03:47:20 PM
I have now reviewed this PR on github.
Quote
- Successfully fixed: raise ground on the pier deck

- Critical Bug: The ground below the pier can be lowered, moving the pier object down, but leaving the ground on top in place.
The resulting invalid structre cause a (yet unreproducible) degfault on click.
In some cases the ground cannot be lowered when there is a pier on top.
Expected behavior: Do not allow ground adjustments below piers.

- Minor Bug: The menu icons will scale when zooming in/out in the simutrans world. These will immediately adjust to their original size after zoom. Other menu icons do not behave like this.

To anyone else interested in testing/reviewing this, you can checkout PRs to your local repository as follows:

git fetch origin pull/<PRid>/head
git checkout FETCH_HEAD


In this specific case:

git fetch origin pull/3/head
git checkout FETCH_HEAD


Alternatively, use GitHub Desktop or GitHub CLI
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on October 20, 2021, 05:58:59 PM
I fixed the issue with ground lowering, however I was also unable to reproduce the segfault.  Since the invalid structure would no longer occure, it may be safe to assume that whatever caused the segfault would not occure again.  (I did fix a similar segfault issue just before the PR was merged, as I noticed you mentioned it in another thread)

As for the minor bug with the glitching menu icons, I am not sure as to what the problem is, as the menu icon code is nearly identical to that for bridges.  The problem is somewhat intermittent on my machine (i7-10700K, integrated graphics), and despite using it for several hours, had not noticed it.  I just double-checked the code and found nothing obvious, but I will try to investigate further.


For having separate tool bars, I agree with Freahk that it may be too much for the use, as many look rather similar.  As for automatically selecting the direction while dragging, it is a possibility however, I am skeptical since it would assume that the user is skilled enough with the mouse to drag in the right direction for the first tile.  The eventual plan is to have both the existing system for where manual control is needed or desired, as well as a general purpose automated tool to build piers as ways are currently built.


In the meantime, I have created a new set of iron girder piers, which I have put in my pier_system_extras branch for now so others can preview it.  I am not sure if I am completely happy with the graphics, but it is functional, and I will create a PR after some more testing (and possibly a few tweaks).
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: Sirius on October 20, 2021, 07:41:42 PM
Thanks for the quick fix.
I have tested and approved the change. The critical bug seems to be fixed.
I'd like to get one further review and confirmation, so this can be merged in the normal way.

As this is an urgent fix, I will incorporate it within the next few days unless anyone objects.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on October 20, 2021, 10:19:20 PM
I found the problem with the menu icons.  It is actually a pakset issue.

As I am about 2.5 nines sure that the iron girder piers are functional, I created the PR for that, which includes the fix for the icons.  I can separate this into 2 PRs if requested.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: Sirius on October 20, 2021, 10:24:46 PM
I'll just start a quick review now.
Given you split the minor fix into a seperate branch, I might pull that fix in the fast way as it's just a very minor fix, otherwise I'll wait for a second approval.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on October 21, 2021, 12:12:51 AM
I just split the minor fix into its own branch and pull request.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: Sirius on October 21, 2021, 12:20:04 AM
Reviewed including the girders.
They feel way too weak, but that might be a matter of taste.

Incorporated the menu icon fix.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on October 22, 2021, 09:55:32 PM
I will admit I was having trouble getting the proportions to look right, given the 30x30 meter tiles.  If I had made the girders any thicker (they are about 2m) there would not be enough clearance to handle vehicles beneath, resulting in the deck needing to be three levels above a track.  The vertical posts (~75cm) also gave me trouble as they have to look proportional by itself, and touching the support to the adjacent tiles.  They also had to be thin enough that they still look correct despite the bottoms all being flat on sloped ground (I could not locate the original ground blend files).  I would not be too insulted if someone down the line redoes these graphics.

Also on my TODO list are concrete girder piers and wooden piers (stone arches and concrete arches would be a reskin of the brick arches), however I may need to add additional bits to the masks in order to add more than that.  Would it best to add the bits now or wait until the pakset graphics are ready to go with it?  Also, as there are no concrete arches in pak128.britain, were they used in the UK?



In the meantime I did find another bug, this time preventing elevated ways from being built over crossings.  I fixed the 1 character in the code and submitted a PR.



Addendum: the aforementioned TODO list is tentative, as the amount of free time I have could drop soon.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on October 24, 2021, 01:34:35 PM
Thank you very much indeed for this work - this is a very interesting project. My apologies most sincere first of all for not having had a chance to review this until now: I have both been very busy at work and preoccupied with a number of matters.

I have now been able to merge this code and test it briefly: I had to do some work to allow it to compile with Visual Studio that I use for development. I have pushed the merged pier_system branch into a branch of that name on my Github repository.

However, for the purposes of initial testing, I am not sure that I can actually find any piers to build. I had imagined that the pier system would directly and completely replace elevated ways so that the elevated sections themselves (the piers, as I had understood it) were separated from the underlying way in the same way as bridges are now so that the ways on top of elevated ways can be upgraded independently of the underlying structure, but it seems that existing elevated ways are unaffected (at least, I cannot find a specific change to their behaviour). May I ask where in the GUI that I should be looking for this?

Also, what the intention was as to how these would interact with existing elevated ways? Ideally, we would want graphics for the elevated ways to allow them to function as piers (if I have understood that term correctly) that are missing their way images and have a transparent part so that way images can be superimposed from the basic way image types, as is done with bridges.

I should note that I have not been able to merge in the "extras" to the pakset branch because this seems to give rise to merge conflicts - do I need these extras in order to test this properly? If so, I should be grateful if you could look into resolving the merge conflict.

Thank you again for your work on this - it is much appreciated. I have long wanted for the elevated ways to behave akin to how bridges have behaved since 2014.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: Sirius on October 24, 2021, 04:05:51 PM
Quote from: jamespetts on October 24, 2021, 01:34:35 PMMy apologies most sincere first of all for not having had a chance to review this until now
You don't need to appologise for this. Your effort on simutrans is very much appreciated, but definitely not mandatory!

Quote from: jamespetts on October 24, 2021, 01:34:35 PMHowever, for the purposes of initial testing, I am not sure that I can actually find any piers to build. I had imagined that the pier system would directly and completely replace elevated ways so that the elevated sections themselves (the piers, as I had understood it) were separated from the underlying way in the same way as bridges are now so that the ways on top of elevated ways can be upgraded independently of the underlying structure, but it seems that existing elevated ways are unaffected (at least, I cannot find a specific change to their behaviour). May I ask where in the GUI that I should be looking for this?
To clarify. The seperation from the underlying structure goes even further than that of bridges: Piers are not tied to a specific waytype at all. You can build tracks, roads or whatever on top as long as the constraints match.

Thus, you can find piers in the landscape tools.
If you can still not find them, did you compile the related pak128.britain-ex branch with the proper makeobj version?

Further, you might just try the simutrans/simutrans-extended branch. Everything is already set up over there and the nightly build system on that repository will even provide compiled binaries.
The CMake files have been fixed so windows builds will work properly (those built by github CI were broken before)  This was ported from standard.
As I do not use Visual studio, I am not sure if that' sufficient to build the game from VS. If not, I'd be happy to incorporporate the required changes (or you can do it by yorself, you are an admin of that repository)




Quote from: jamespetts on October 24, 2021, 01:34:35 PMdo I need these extras in order to test this properly?
You do not need extras. It seems like only the first commit of extras is relevant anyways as the others already are part of the commit history.
That one commit includes the blender sources.


Quote from: jamespetts on October 24, 2021, 01:34:35 PMAlso, what the intention was as to how these would interact with existing elevated ways?
Currently, it's an alternative to build elevated ways, but with an improved construction tool, it could replace elevated ways entirely.
The current interaction between these is that elevated ways cannout be built on top of piers and vice versa.
To be honest, I'd welcome the existing elevated ways being converted into piers if possible (i.e. the blendfiles are available), but I do not have any experience with this.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on October 24, 2021, 08:52:19 PM
I see Freahk beat me to a response, however here is an addendum:

For the extras branch, the sole purpose is to provide the blender files and scripts in a manner consistent with the licensing of the image data (copied to buttons.png) needed for the scripts to run.  I will be creating another commit to that branch for the new iron girder piers.  As mentioned below, I would need to either confirm that such image data is public domain or need permission from the copyright holder to transfer such information to another repository such that it could be reproduced and distributed outside of the git/github environment.  (This is my conclusion based on the legalize, I am not a lawyer).

I also do not use visual studio, but use use GNU Make (note irgend42 committed the cmake adjustments for this branch).

Though the pier system may someday deprecate the current elevated way system (and viaduct like bridges), directly replacing all elevated ways with piers may not be practical for a couple reasons.  The blender files for most of the elevated ways do not appear to be available, and the few that are appear to be done using the deprecated blender internal renderer.  (Hence, it took a couple tries to get the lighting and colors to match).  Also unavailable are the blender files for the ground, hence the reason that the arch based piers are only available on ground I was able to reverse engineer the 3D contours from the images.  The other reason is the level of incompatibility in the workings between the old elevated ways and the new pier systems.  Where old elevated ways could be built on anything, there are heavy restrictions to what piers can be built on to prevent vehicles from appearing to go through the support structures(eg. with brick viaducts), or have piers appearing to be supported insufficiently (eg. bricks viaduct over wood trestle).  This would mean any direct replacement would need to override these restrictions.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on October 24, 2021, 10:00:27 PM
Thank you both for your replies: I will have to re-test when I get a chance and look in the landscape tools. This is definitely not where one would expect to find tools for building ways, so this will need to be reconsidered before this can be finalised (better would be to have them in every way type menu even if this involves duplication).

As to the Blender sources, I believe that these are all licenced under the Artistic Licence 1.0 as with the rest of the Pak128.Britain project - have you seen documentation suggesting to the contrary? There is a separate repository for Blender sources that will need to be used for this. I should note, incidentally, that all Pak128.Britain-Ex objects use the deprecated Blender internal renderer, so it is necessary to use an archive version of Blender to produce graphics for Pak128.Britain-Ex. I am not aware of any possibility of a workable solution to this without somebody spending hundreds and possibly thousands of hours converting every single object in the pakset to be rendered with Evee in order to appear consistent (and that would be after spending a considerable time fine tuning the settings for Evee to get a good appearance).

However, I am not sure that it is necessary to have the Blender sources in order to have separation of piers from the underlying ways graphically. Certainly, I did not need this when doing this with the bridges; I simply masked the images in the GIMP and made transparent the parts of the bridge images that had hitherto contained the ways, then simply removed the code that stopped Simutrans from drawing the way images on top of bridges. I would suggest using the same approach for piers.

The real benefit of piers will be to allow economic separation between structure and way for elevated ways to allow for better balancing of these. This advantage will not enure unless piers entirely replace elevated ways; having a system in which players can build either current elevated ways or piers is likely to be extremely confusing and impossible to balance economically. Thus, while having code that allows for piers and legacy elevated ways both to be built at once may make sense for a testing phase, this is not a workable solution in the longer term or for the master branch. Ideally, what you would want to do in respect of different building restrictions is simply allow piers to replace existing elevated ways in saved games even when they do not meet the new building requirements, but not let any new piers be built that do not meet these new requirements: this is generally how I have handled any situation where I need to add a constraint in building infrastructure in a way to work with existing saved games.

In any event, now that I know where to look for these, I will test these more thoroughly when I have a chance and report back in more detail. Thank you again for your work on this: it is much appreciated.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: prissi on October 25, 2021, 03:37:03 AM
I think an extended building of elevated ways is also highly sought after for standard, given the many elevated way sources from the Japanese community.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on October 25, 2021, 09:30:10 PM
I have now had a chance to test this. First of all, once again, thank you indeed to PJMack for all the work put into this - this has clearly been a great amount of effort to produce some interesting new functionality. Apologies once again for the delay in being able to test this.

This work is very promising, but needs some further refinement before it is ready to be incorporated into the master branch. First of all, the system for building the piers and building the ways on top of them is very difficult to understand and implement. I have still not worked out how to build piers in the east/west direction, and it is not clear whether there is a non-cosmetic difference between the piers with open arches and those with filled-in arches. The purpose of the supports (and especially the different types of supports) is not clear. It is also significantly more awkward to build these structures than existing bridges or elevated ways as there is no click/drag functionality.

Really, this system needs to have the same sort of ease of use as elevated ways or bridges have at present. If we incorporate a system that is much harder to use than elevated ways or bridges, we are effectively taking a quite significant backwards step in terms of usability and accessibility, which is likely to make it very difficult for people to be able to enjoy the game effectively unless they are already very experienced. Making things difficult for newer players will ultimately reduce the number of new players becoming interested in Simutrans-Extended and may well mean that the number of people playing in the future dwindles to nothing over time. Thus, not making usability significantly worse is really very important indeed.

Secondly, this system definitely needs to integrate much better with existing bridges and elevated ways. From a conceptual perspective, the distinction between a bridge and an elevated way as at present makes sense to an extent, but to have bridges, elevated ways and this pier system does not make much sense. There needs to be a clear answer rooted in the real world of the thing being simulated by Simutrans-Extended to the question of why a player would build a pier system structure as opposed to a bridge or an elevated way. The reality is that these distinctions do not exist in real life, and we need to make sure that we simulate this lack of distinction.

Thus, what this needs in order to be workable is both a user interface and conceptual integration of the piers with existing bridges and elevated ways so that they either simply replace elevated ways or even replace both bridges and elevated ways. The expected behaviour would be for players to be able to click and drag elevated ways in place just as at present, but then be able to replace the way with a way of a different type. Also, consistency is very important: if players can replace a railway with a road on an elevated way but not in a tunnel or on a bridge, this would be perplexing and make no economic sense. The game needs to become more internally consistent over time, not less.

I have not looked into the pier system code in detail to see how readily that this expected outcome might be achived. When I worked on separating the bridges and tunnels from the underlying ways in 2014, I found that it was fairly easy to achieve this using large parts of the existing code, which already had some separation of the bridge/tunnel and underlying way built in. I did not do this for elevated ways because this was an entirely different system that did not have this underlying separation already built in and it would have required a much more fundamental rewrite in order to achieve the same result; instead, I implemented a fudge of discounted upgrading between different elevated ways that were in substance the same underlying structure with a different way on top. It looks like the pier system might be the basis for this sort of work, but it needs to be made more consistent with the way that things work now in order to achieve this.

Another issue is the graphics. Again, we need to make sure that, at the point of integration of any new system into the master branch, we do not go backwards in terms of the range of elevated ways/bridges available to be built. This may well mean specifically designing the system to be able to work with the existing graphics (or the existing graphics with minor modifications as I did in 2014), as it is not likely that anyone will be able to re-do all of the bridges and elevated ways in the pakset from scratch any time soon, and if we implement a system that abandons the existing graphics but does not replace them immediately, then the pakset is likely to be in a fundamentally unfinished state for an indefinite time into the future, whereas it is not in such a fundamentally unfinished state at present.

Once again, the amount of work that has evidently gone into this is very much appreciated. This does have the potential to make elevated ways a great deal better, but, before this can be integrated, we need to make sure that there is no sense that Simutrans-Extended will be taking a step backwards in usability, internal consistency, economic realism, fathomability, and variety and quality of game objects/graphics.

More generally in relation to elevated ways, I note the points raised by Matthew, and I do wonder whether elevated ways are well balanced at present. I had not looked into the cost because balancing has not been dealt with fully, but if Matthew can suggest an interim rebalance of elevated way costs based on a real life comparison with the cost of non-elevated ways, then this is likely to be very helpful. It may also be time to reconsider the question of whether elevated ways should be able to be built over other buildings; allowing this may well have been a mistake, on reflection; the real advantage of elevated ways in reality is that they can be built over roads, rivers and other ways, not over buildings, and one does not see actual buildings (as opposed to repurposed arches) underneath elevated ways in reality. I should be interested (in a separate thread, so as not to clutter this one) on feedback as to this possible change.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: Sirius on October 26, 2021, 12:53:11 AM
Quote from: jamespetts on October 25, 2021, 09:30:10 PMThe expected behaviour would be for players to be able to click and drag elevated ways in place just as at present
The current tool is not quite user friendly but I do not agree that at any cost, the pier system has to behave exactly the same as elevated ways do now.
A restriction of elevated ways is that they can only be built a full height above ground and can only be built on top of flat grounds or slopes in the direction of the way.
A restriction that does not exist in the real-world and cannot be solved when sticking to the exact same behavior as elevated way construction.
In my opinion it is totally fine and desirable for piers to stick to a fixed altitude.
Besides that, they should rather behave like any other way, especially should support draft-dragging in any direction, with construction on mouse button release.

Quote from: jamespetts on October 25, 2021, 09:30:10 PMThe purpose of the supports (and especially the different types of supports) is not clear.
To me it felt quite intuitive that you can build ways underneath an arc support, but not underneath a filled support.
That's clearly a disadvantage of filled supports, but I must admit, I don't know any advantage of filled supports.

Quote from: jamespetts on October 25, 2021, 09:30:10 PMAlso, consistency is very important: if players can replace a railway with a road on an elevated way but not in a tunnel or on a bridge, this would be perplexing and make no economic sense. The game needs to become more internally consistent over time, not less.
I do not agree with this.
As you have noted, the way on top of elevated ways cannot be replaced at all.
This indeed does not improve consistency, but it doesn't make it worse as well.

In my opinion it is rather a general discussion: For gameplay reasons, does it make sense to build general piers, bridges or tunnels?
What are the balance implications of this? And can this be implemented in a visually pleasing way?
Depending on this, there hsould be an individual decision on piers, bridges and tunnels whether to allow general construction or to always tie them to a specific waytype.

In my opinion, gameplay and economics are totally fine with general ways and bridges.
I am not sure about tunnels though. In case of bridges and piers, the maximum permitted (live) load has a major effect on cost, whilst in tunnels, the tunnel diameter has a major effect on economics.
I have really no idea about the visual point.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on October 26, 2021, 02:37:27 AM
I will admit that I did not make things as intuitive as it ought to be, but for now, here is some documentation which would be edited and placed in the help menu when the time comes:
As with station buildings, control click the tool icon to select the orientation.  For some piers, a rudimentary, but usable, dragging system is in place where one can hold the mouse button down to place piers in a straight or diagonal line.  For where piers can be placed in relation with ways, it is up to the packset designer to use the ribi filters to make sure that if it looks like a pier would block a way, it blocks a way, and if a pier blocks a way, it looks like it blocks a way.  Likewise the pakset designer would use the masks to make sure that if it looks like a pier cannot fit or be supported, then it cannot be placed, and if a pier cannot be placed, it would not look to be possible to place it.  The remove tool will only delete a pier if it is not supporting anything else.  Holding control when clicking on top of a pier stack with remove tool will remove most of the stack, or as many non load-bearing elements as possible.

Some sort of indicator may be needed on the pier building menu icon or tooltip to hint to the user that control-clicking sets the rotation.




Quote from: jamespetts on October 24, 2021, 10:00:27 PMAs to the Blender sources, I believe that these are all licenced under the Artistic Licence 1.0 as with the rest of the Pak128.Britain project - have you seen documentation suggesting to the contrary?
I could not find a license file posted for the blender source repository.  From what I read of the artistic license file provided with simutrans-pak128.britain, it only permits the copying, distribution, and modification of the as a whole package, and does not give permission for transferring a part of such package to another (even one with the same artistic license).  Granted, we are in different countries with different copyright and licensing laws (we don't even spell license the same way), so this may be a source of some of the confusion here.

Quote from: jamespetts on October 24, 2021, 10:00:27 PMHowever, I am not sure that it is necessary to have the Blender sources in order to have separation of piers from the underlying ways graphically. Certainly, I did not need this when doing this with the bridges; I simply masked the images in the GIMP and made transparent the parts of the bridge images that had hitherto contained the ways, then simply removed the code that stopped Simutrans from drawing the way images on top of bridges. I would suggest using the same approach for piers.
I did to this at the beginning, however, found that due the the ways being built after the piers, and the greater variety of pier images needed (there are over 2000 images so far for the only two types of piers), I found it easier to try to port the lighting system in eevee (which appears successful) and use blender's animation to automate the image generation for the new types of images needed. 
Furthermore, there is the question as what to do if a pakset only has images for the existing elevated ways, as there would be no direct translation of the images.  The simplest solution would be to keep the existing elevated way system in place withing simutrans extended, and allowing the pakset designer to determine if the elevate ways are legacy.

Quote from: jamespetts on October 24, 2021, 10:00:27 PMlook in the landscape tools. This is definitely not where one would expect to find tools for building ways, so this will need to be reconsidered before this can be finalized (better would be to have them in every way type menu even if this involves duplication).
I had thought of this, but given the 27 different pier buttons for only two types of piers, I did not want to overfill the toolbars.  The reason I though landscaping tools was appropriate was that the piers are not ways, but structures to build artificial ground above land.

Quote from: jamespetts on October 25, 2021, 09:30:10 PMSecondly, this system definitely needs to integrate much better with existing bridges and elevated ways. From a conceptual perspective, the distinction between a bridge and an elevated way as at present makes sense to an extent, but to have bridges, elevated ways and this pier system does not make much sense. There needs to be a clear answer rooted in the real world of the thing being simulated by Simutrans-Extended to the question of why a player would build a pier system structure as opposed to a bridge or an elevated way. The reality is that these distinctions do not exist in real life, and we need to make sure that we simulate this lack of distinction.
If starting from scratch, the system I would envision is that the piers would represent all general types of viaducts, and bridges would represent long single spans.  Where the existing elevated way could fit in would the the special purpose elevated ways that may be either height restricted or cheaper to build at a standard height.  The example the comes to mind are hanging monorails. 

Quote from: jamespetts on October 25, 2021, 09:30:10 PMI have not looked into the pier system code in detail to see how readily that this expected outcome might be achived. When I worked on separating the bridges and tunnels from the underlying ways in 2014, I found that it was fairly easy to achieve this using large parts of the existing code, which already had some separation of the bridge/tunnel and underlying way built in. I did not do this for elevated ways because this was an entirely different system that did not have this underlying separation already built in and it would have required a much more fundamental rewrite in order to achieve the same result; instead, I implemented a fudge of discounted upgrading between different elevated ways that were in substance the same underlying structure with a different way on top. It looks like the pier system might be the basis for this sort of work, but it needs to be made more consistent with the way that things work now in order to achieve this.
The pier system code has elements from the elevated ways, bridges, and even station buildings.  For the existing system, the elevated way is built the same as a way at ground level, except the a new artificial ground type is created 2 levels above and the way object placed upon that.  For the pier system implementation, a pier is places as if it were a building, also with a different new type of artificial ground (pier deck) on top.  The way building code was modified to take into account the restrictions the underlying piers when attempting to route the way on the pier deck.  As of yet, such restrictions only include the direction of the way (if any) possible for a given pier, but planed and layed out are restrictions for restricting specific waytypes to piers (such work would be trivial, but involve a pakset version change).

Quote from: jamespetts on October 25, 2021, 09:30:10 PMIt may also be time to reconsider the question of whether elevated ways should be able to be built over other buildings; allowing this may well have been a mistake, on reflection; the real advantage of elevated ways in reality is that they can be built over roads, rivers and other ways, not over buildings, and one does not see actual buildings (as opposed to repurposed arches) underneath elevated ways in reality
For the piers, there is an option in the pakset to prevent building curtain types of piers over buildings, with variables in place to restrict buildings to match the piers (such as archways).  (Again, such work would require a pakset version change.)  Thought I have not seen any examples for the UK, I do recall having seen some examples ordinary buildings below elevated transit systems in the US and Japan.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on October 26, 2021, 05:23:41 PM
Thank you both for your replies. To deal first with Freahk's replies: I concede that it goes too far to say that a new pier system needs to be identical in UI to the existing elevated way system, but it does need to be fundamentally very similar, based on a straightforward click and drag mechanic.

As to tunnels and bridges being bound to particular way types, I do not think that that is economically necessary: I am aware of both having changed uses (a tunnel in Caernarfon in north Wales, for example, has transitioned from rail to road use within the last 60 years or so). However, to make this work, careful research would be needed to ensure that this ends up being economically workable, and whether current live loading limits of bridges and other such restrictions are sufficient to prevent exploits that undermine the economic balance. PJMack does propose a possible way of dealing with this, by being able to specify at pakset level which waytypes that particular piers/tunnels/bridges can support, although this would need to be able to be communicated clearly to players for this to be workable.

As to PJMack's replies, thank you for letting me know how the current building system works. As indicated, we do need to get this to the point where the usability is on the same level as the rest of the way/bridge/tunnel infrastructure (i.e., click and drag) before this is ready for the master branch, although it does not necessarily have to be identical in every detail to current elevated ways; we might click and drag once for the underlying structure, for example, then drag a way over the top.

In relation to Blender rendering, the use of Evee does not, unfortunately, give a consistent appearance: the pier graphics (especially the brick arch graphics) did look noticeably different in style and shading to the existing pakset graphics. When I have re-rendered existing objects using Evee, I have found them to look very different from how they look with the internal renderer. If you were able to configure the Evee renderer so that existing objects exported with Evee thus configured look near identical to those same objects rendered with the old internal renderer, and also make the process automatic to the same extent (i.e., once it is configured, press one button, and all 8 renders, complete with proper transparency and ready for immediate use in a .dat file, are produced), then this would be extremely helpful. We do need the identicality of appearance, however, as it is often necessary to re-render things that have already been rendered to make some minor correction, or, for example, to add liveries to a vehicle, which needs to look otherwise totally consistent with the same vehicle in different liveries.

As to keeping existing elevated ways, the idea of keeping the existing implementation of elevated ways for paksets which do not have new graphics will not really work, since this is requires two substantial pieces of code that essentially do the same thing to be maintained indefinitely and also prevents an effective transition for paksets that do upgrade to the new pier system: if existing saved games will break without elevated ways being defined in the pakset, then elevated ways will have to be retained forever, giving rise to economically incoherent duplication. Really, the pier system can only work if it does act as a total replacement for elevated ways. How to do this effectively is likely to be complex, but then much in Simutrans-Extended is, by its very nature, necessarily complex.

As to toolbar button placement, I can see why having 27 different new buttons in every way menu might be a problem. However, the problem is really that the system needs 27 different buttons to work: elevated ways need only one button per type. We definitely need significant refinement of the usability of the user interface if the pier system is to be workable for the master branch, and players having repeatedly to select between 27 different options for each different tile when building piers is not likely to be workable. If we do need to have a large number of buttons for any reason (although definitely <27), then these will need to be in the form of a sub-menu from the way menus. Having tools for building elevated ways/bridges in the landscape menu is virtually certain to be unfathomable to most players: indeed, I did not even realise that the piers were there when I first tested this because I would never have thought to look in the landscape menu for tools for building ways.
I am not sure that I fully understand the significance or purpose of the utilisation of existing elevated ways: why would cost or height restriction be a reason to have an elevated way on which one cannot replace the way type? Hanging monorails are an interesting case, but this does not really explain the nature of the distinction being drawn, which would, if implemented, affect more than just hanging monorails. I note the idea of being able to have particular piers tied to particular types of way, however, which might account for monorails effectively.
As to interaction with buildings, there may be much to be said for being able to define at pakset level a relationship between building height/level and the level of the way above the pier, including the ability to preclude all buildings beneath a particular pier system.

In any event, thank you again for your work on this. This is a very promising start to an interesting system; if we can only improve the usability and integrate this better with existing bridges/elevated ways both economically and graphically, this will be a very worthwhile enhancement.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on October 28, 2021, 07:43:38 PM
As a "two_click_tool_t" method of building piers is still on the drawing board, an automated system to allow building of straight runs of piers is in place.  The reason for the 27 different buttons is the 36 different scenarios one could encounter with the possible directions of ways above and below the pier.  With one exception (which I may deprecate) each pier has it's own costs and use balance the benefits and restrictions of each pier.  Solid piers are less expensive (easier to build, less surface area to re-point) than arches, and piers that allow intersections on top are pricier due the added material needed.  Also note that not all such combinations are practical, such has having the way below being parallel to the way above for arch based piers.  As for the placement of such buttons, a designated toolbar may be the way to go, unless relabeling the the landscaping toolbar to "Landscaping, Viaductions [and Tunnels]" would be appropriate.  If the former is the case, it may be plausible (as suggested below) to have a single menu icon per rotation. Also because the elevated intersections are cost balanced, I am also skeptical of any automated method placing such.

As for deprecating the existing elevated way system, I did look into the code, and found what it probably the best compromise.  About 95% of the existing elevated way code (that is code explicitly for elevated ways) is for building elevated ways, which now I agree can go once the piers system is finalized.  About 3% would be needed for opening files with the existing elevated ways, and the other 2% adds up to about 20 lines of code, 8 lines to display them, 4 lines to delete them, and 8 lines for building bridges to them.  Those 20 lines of code would be far easier to maintain and debug than anything to convert the elevated ways into the piers.

As for weight and speed limits, I am still trying to do some research on that.  So far the best I could come up with is having an axle load limit (as is done on bridges in the US) for spans.  There was a suggestion of having the speed limit be a function of the vehicle weight, however that would require diving deep into the routing and physics code.  Another thought I had was to multiply the weight by the wear factor to better represent the live load and vibrations better, but again, would require a deep dive.

For communicating to the user, it may be best to use tooltips to indicate the types of ways a pier could support where it is not obvious from the appearance of the ways in relation to the piers (eg. by width).



So overall, my TODO list is (not necessarily in order, the was with an asterisk would probably be done first):

Again, I should point out that this is a tentative plan and unfortunately I am not currently in a position to promise anything.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on October 31, 2021, 11:08:32 AM
Excellent, thank you for the progress on this. It would be very interesting indeed to see these working with a full click and drag system. I do think that we need intersections automated, however: all other intersections in Simutrans are fully automated, and it would be perplexing and confounding for players for one and only one type of way to work differently. Also, automated intersections are the way that all other games of broadly this type use, both past and present. That intersections have a different cost to straight way makes sense, but I do not see this as a reason for not automating, since the different cost for this can be shown in the preview display for way costs shown when clicking and dragging.
As to the different balances for different types of way, may I ask whether the solid piers costing less than the arches is based on real research? Solid piers would consume vastly more building materials and would take vastly more labour to complete because of the much greater number of bricks (or similar) required, which is why one does not normally see totally solid viaducts built of brick or stone: one normally sees either an arched construction, a girder construction or a solid embankment of earth.

In terms of the existing elevated way system, the important thing is for games with existing elevated ways to be able to convert them into piers automatically on loading, or else there will be some very weird anomalies when players transition from older to newer saved games, as, currently, elevated ways, because they fail to separate way and underlying structure, wear out with passing loads and must be replaced periodically, as well as needing to be connected to and extended.

In terms of weight and speed limits, since pier structures are fundamentally similar to bridges, it would be sensible, I think, to use the same weight limit system as for bridges: the bridge itself has a weight limit based on the weight of all the vehicles in one convoy on it at once, and the underlying way has its own axle load limit.

In terms of tooltips, this is an interesting suggestion - I should be interested to see what you come up with as regards this.
In any event, thank you again for your work on this. Do not worry about not being able to promise anything: Simutrans is a hobby and not a job, so feel free to progress this at whatever pace suits you.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: Sirius on October 31, 2021, 11:57:09 AM
About the license issue, PJMack is entirely correct, that there is no license provided to the repository.
It should not be an issue to incorporate his changes into Pak128.Britain-blends, but that will not grant anyone permissions to re-use the provided content, except from the use granted by GitHub TOS, that you agree with by using GitHub in any case.
See GitHub TOS Section D. 4-5
Long story short: GitHub is permitted to host the repository and anyone is permitted to fork the repository. No words being said about modifying content, thus it is not permitted!

Looking at the not-so-long list of contributors, it should be rather simple to agree with them on a license, so you can change repositories license accordingly.
You might reconsider whether you really want to use the AL 1.0 as it is vague in some points and discouraged by FSF. You might consider CC-BY-SA or AL 2.0 instead.



Quote from: PJMack on October 28, 2021, 07:43:38 PMWiden masks to 64 bits*
Re-thinking this. I did not expect 32 bits to become insufficient that quickly.
If I remember this correctly from the review, the mask is stored in the description object, thus memory consumption is negligible and it is not used in a quite performance critical manner.
Thus, you might as well go for a string based constraint system instead. Just like vehicle coupling constraints. Instead of defining Constraint[Next][n] = "train_name", you define Constraint[Above][n] = "pier name" or even better Constraint[Above] = "pier_support_type", where the pier_support_type is any name that can be referenced to from a Constraint[Below][n] = "pier_support_type" Note that each type of pier offers exactly one type of support to piers above, but can be built on top of n different supports below.

That will grant some more flexibility and should also be more pakset-author friendly than fidling with a huge bitfield, at cost of maintaining many more bytes in the description, which should be negligible though.

Quote from: PJMack on October 28, 2021, 07:43:38 PMThere was a suggestion of having the speed limit be a function of the vehicle weight, however that would require diving deep into the routing and physics code.
A simplistic implementation of this alraedy exists on bridges. I might have a look at this. It shouldn't be too complicated to implement this on piers.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on November 03, 2021, 02:33:47 AM
Quote from: jamespetts on October 31, 2021, 11:08:32 AMAs to the different balances for different types of way, may I ask whether the solid piers costing less than the arches is based on real research? Solid piers would consume vastly more building materials and would take vastly more labour to complete because of the much greater number of bricks (or similar) required, which is why one does not normally see totally solid viaducts built of brick or stone: one normally sees either an arched construction, a girder construction or a solid embankment of earth.
The solid viaducts are based on two structure types, one being the Canton Viaduct (which is hollow) and the other being simply two retaining walls filled with dirt where an embankment would be two wide.  Such would require less bricks (costly) and more infill (cheap), as well as less skilled labor needed for making a wall verses an arch.  Such structures are more common in the US.  After looking more into the viaducts specific to the UK (is appears such structures are more prevalent locally), I decided to limit the height of the solid viaducts to discourage their use where an arch would be more appropriate.   

Quote from: jamespetts on October 31, 2021, 11:08:32 AMIn terms of the existing elevated way system, the important thing is for games with existing elevated ways to be able to convert them into piers automatically on loading, or else there will be some very weird anomalies when players transition from older to newer saved games, as, currently, elevated ways, because they fail to separate way and underlying structure, wear out with passing loads and must be replaced periodically, as well as needing to be connected to and extended.
I will have to add it to my TODO list.

Quote from: jamespetts on October 31, 2021, 11:08:32 AM
In terms of weight and speed limits, since pier structures are fundamentally similar to bridges, it would be sensible, I think, to use the same weight limit system as for bridges: the bridge itself has a weight limit based on the weight of all the vehicles in one convoy on it at once, and the underlying way has its own axle load limit.
As the existing elevated ways used axle loads, I did implement the piers to use axle load as well.  Also, road bridge wight limits in the US use axle load, is seamed appropriate to continue using it, particularly given the spans are about the same length as many of the vehicles.

Quote from: Freahk on October 31, 2021, 11:57:09 AMRe-thinking this. I did not expect 32 bits to become insufficient that quickly.
If I remember this correctly from the review, the mask is stored in the description object, thus memory consumption is negligible and it is not used in a quite performance critical manner.
Thus, you might as well go for a string based constraint system instead. Just like vehicle coupling constraints. Instead of defining Constraint[Next][n] = "train_name", you define Constraint[Above][n] = "pier name" or even better Constraint[Above] = "pier_support_type", where the pier_support_type is any name that can be referenced to from a Constraint[Below][n] = "pier_support_type" Note that each type of pier offers exactly one type of support to piers above, but can be built on top of n different supports below.

That will grant some more flexibility and should also be more pakset-author friendly than fidling with a huge bitfield, at cost of maintaining many more bytes in the description, which should be negligible though.
This time I looked into every type of bridge and viaduct existing in the pakset, and found that 64 bits will be enough (accually I only need 40 bits).  Two things the bit field allows easilly are rotation of the piers and allowing two piers to have the same support as one.  Right now, two single brick pillars can be used as a substitute for a single brick pillar (if one pillar is already made and another is needed), and for the girder ways there are instances where combining piers to work as one is required.



I did push some changes, but they may need some more testing.  Some piers can no longer be built on water (iron girders) and straight/diagonal solid piers can no longer be stacked.  Way filtering for piers has been enabled, so building runways and canals on the piers in the pakset have been disabled.  Restrictions on what types of piers can be built on what types of buildings have been refined, however I am still working on having cities construct buildings below piers.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on November 06, 2021, 10:42:12 AM
Thank you for your replies: it is interesting to learn about in-filled viaducts, which I was not aware of previously, possibly because they are not common in the UK.

In terms of axle loads and bridges/piers, we really do need to have this consistent - so, if there is a good reason for bridges to have axle load restrictions as well as weight restrictions and on top of the axle load restriction of the underlying way, then this should be implemented for bridges, too: but I am concerned that such a system would be very difficult to communicate to players, who might find it very confusing.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on November 09, 2021, 11:48:38 PM
It does seam that axle load is a significant factor in bridge weight limits, as higher axle loads results in more strain and stress on the girders for girder bridges and more strain and stress on the peaks of the arch for arch bridges.  One analogy I found is that thin ice can support more weight of one laying verses standing.  For many posted bridges in the US, a chart is given based on number of axles (though it varies by state), and for federal roads, there is a formula involving the number of axles and their distribution (see https://ops.fhwa.dot.gov/freight/publications/brdg_frm_wghts/ (https://ops.fhwa.dot.gov/freight/publications/brdg_frm_wghts/)). 

In the meantime, I added a feature where some special types of piers can support the way on the bottom rather than the top.  Such piers can only be built on another pier.  I have only created one of such for the pakset for testing purposes as I am finding out that my artistic abilities are a bit more limited than I thought, and am struggling to get the proportions right in some cases.  The good news is that I think I may have gotten the lighting correct, and am attaching an image for a second opinion.

Addendum:
For some strange reason the image looks darker on the forum than it does in an image viewer.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on November 22, 2021, 11:53:45 PM
I updated the PR, this time managing to get everything to merge properly with simutrans/simutrans-extended/feature-pier_system.

The new feature now is that holding control when dragging will automatically adjust the pier type for the situation whenever possible.   For example, when holding control when dragging a brickarch, a brickpillar would be placed on the bottom when needed, and double spans over diagonals would be handled as well. 

As for the new piers, they are meant to be a somewhat temporary (at least graphically) to test the new features.  As they to not yet have visual cues needed for stacking, I would recommend only using the new cntl-drag system when building the heavy steel piers.  For game balance, they are meant to be more of diagonal capable heavy weight multi-span bridges than anything else.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on December 15, 2021, 01:56:56 AM
As I am finishing up the coding, a few questions have come to mind that I think the community may want to weigh in on. 

The first is what should the cost of pier removal be?  One method would be some fixed multiple of the build cost.  Another method would be to specify on a per pier basis, or allow a settable multiple of build cost.  Also, should forge costs be disabled when building upon piers?

The other question is whether this system should be called "Piers"?

(I did push some code on github as a status update, it is not quite ready for a PR yet).
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on December 18, 2021, 10:36:56 PM
I just created another PR for simutrans-extended and updated the PR for simutrans-pak128.britian-ex.  This should be that last of the coding part of this project, the remainder should be help text and pakset design.  I will also be adding pakset design documentation in the appropriate sub-forum. 


The automated tests are failing on macOS (SDL2) due to the error:
/Users/runner/work/simutrans-extended/simutrans-extended/music/core-audio_midi.mm:12:9: fatal error: 'QTKit/QTMovie.h' file not found
#import <QTKit/QTMovie.h>
        ^~~~~~~~~~~~~~~~~

I am not sure as to why since my pier code does not touch the audio subsystem.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on December 24, 2021, 05:09:57 PM
I am afraid that this PR needs some adjustments before merging as I found two and a half minor bugs while doing pakset design.  They should not take long to fix.
It should be all set now.  Auto pier now handles timeline and ocean tiles as expected.  Auto_group variable increased to 32 bits.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on December 26, 2021, 06:26:59 PM
Thank you very much for your work on this, and apologies that I have not had time to review this until now. I have just attempted to merge the pier branch into the master branch, but I get some merge conflicts with one of the CI text files and also the Visual Studio project. Attempting to compile this on Linux, I get the following compile error:


===> CXX descriptor/reader/pier_reader.cc
obj/pier.cc: In member function 'virtual const char* pier_t::is_deletable(const player_t*)':
obj/pier.cc:108:6: error: 'get_player_nr' was not declared in this scope; did you mean 'get_owner_nr'?
  108 |  if (get_player_nr()==welt->get_public_player()->get_player_nr()) {
      |      ^~~~~~~~~~~~~
      |      get_owner_nr
make: *** [common.mk:55: simutrans/obj/pier.o] Error 1


The result of that is that I am not able to test this at present. I should be grateful if you could look into this. Thank you.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on December 27, 2021, 08:45:50 PM
I had been working on a PR for simutrans/simutrans-extended:pier_system-feature branch completely forgetting that I still had the PR open for the jamespetts/simutrans-extended:master branch.  The compile error is also a merge conflict due to a change in function name.  I manually fixed this error and it complies using make on my machine and cmake for all working test benches (see https://forum.simutrans.com/index.php/topic,21277.0.html (https://forum.simutrans.com/index.php/topic,21277.0.html)).  As for the visual studio file, I did what I could to merge it, but have no way of testing it.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on December 29, 2021, 12:28:51 AM
Excellent, thank you for this. I have now been able to compile this, and the automatic building makes a big difference. I have not completed my testing yet, but a few preliminary issues I have noticed at this stage I will list.

1. The brick arch piers look very good, although the contrast between light and dark shading is somewhat less than the existing models - the shadows need to be darker. Also, the brick colour could do with being slightly yellower to make it closer to the existing bridge colours; it would also be helpful to have graphics for edge walls and coping stones as the existing brick elevated ways have: the roads in particular look a little odd having no protection for the plummet to earth over the sides. (I note that you refer to these as temporary graphics).

2. The steel type looks good, too (the shading is better for this), but there are quite large gaps between each section, which does not look right.

3. It is possible to set piers to have a starting height of zero in the automatic mode, but it is not possible actually to build piers when this height has been set.

4. It is not possible to build stations/stops on the steel piers. Is this intended? If so, there needs to be a bespoke error message for this case. This also leads onto the next point.

5. The automatic pier building menu tooltips do not give any clue as to the cost or other characteristics of the piers being built, e.g., whether one can build stops on top of them. This is likely to make it difficult for players to understand how to choose between pier types. This may need some more sophisticated tooltip code than the game has so far, but should not be unduly complex.

6. Building a connexion between a single height pier and a sloped ground tile is possible but is quite difficult and does not appear to work fully in some cases at least.

7. The only way of joining piers to the ground is to use a single height sloped ground tile. It does work this way, but is this intended? Many real structures will have a brick/steel structure extending to the ground rather than relying on a small embankment.

8. The steel peers do not whereas the brick piers do allow intersections. Is this intended? Again, if so, this needs to be in the tooltip.

9. It does not appear to be possible to build waterways/canals on top of piers. Is this intended? If so, I suggest that this be reconsidered, as aqueducts are definitely a thing.

10. The way of building slopes in different directions is inconsistent with the system in the landscape tools: in the landscape tools, there is one button for each direction, whereas for the piers, there is a single button, which brings up a submenu of the different directions. Ideally, the landscape tool would work as the pier tool does, but failing this, a tooltip explaining to the player that the direction can be selected by CTRL+clicking is necessary to prevent confusion, I think.

11. It is possible to build a crossroads out of the brick piers, but this does not work well automatically: simply dragging one pier across the other does not produce a crossroads.

12. I cannot see any difference in clicking and dragging with the automatic pier building tool with CTRL pressed and with CTRL not pressed. An earlier post suggested that CTRL+dragging should do something differently. Can you elaborate on what difference that I should be noticing?

13. I get weird placements when I try to drag steel piers diagonally over brick piers.

14. Starting building a pier from an existing pier tile results in a pier stacking on top of that tile rather than continuing from it, which makes building piers much more difficult than it would be if starting dragging a pier from an existing pier tile by default simply continued the existing pier, as it does with ways, including elevated ways.

I have pushed my merges of the pier system branch onto my pier_system branch, both of code and pakset, on my repository so that you can check that I am using the most up-to-date version.

I answer some of your questions above in the below enumerated paragraphs.

1. "Piers" does seem to be a reasonable name for this system; I cannot currently think of a better name, but I am open to alternative suggestions.

2. The forge cost should indeed be disabled when building on a pier, as the cost of building the pier itself should count as the forge cost.

3. I would suggest that piers should share the existing removal cost specified for bridges: players would expect that bridge removal costs would work in the same way as pier removal costs.

4. Given that your research has indicated that axle load can be important for bridges, I suggest having an option to specify axle load as part of the pier itself, but having this by default as a very high axle load if this be not specified. The behaviour should then be that the minimum of the pier and way axle load should be the ruling axle load limit. The pier axle load will need to be shown in the tooltip as well as the way information dialogue when queried.

Thank you very much for your excellent work on this (which I can imagine must have taken a very large amount of time and effort), and apologies again for the delays in testing this properly. If you can clarify some of the issues that I raise above (as to what is intended behaviour in the various cases, especially as to what CTRL+drag should do), I can continue to test this more thoroughly. Can you also let me know what other aspects of this that need testing that I have not mentioned so far?

Finally, have you had any further thoughts on integrating this system with the elevated ways system? I note that these piers can be built to join the ends of elevated ways, which is definitely helpful.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on December 29, 2021, 07:25:04 PM
Thank You.  To answer you responses in no particular order:

1,2,13: I am still working on replacing the temporary graphics with the more permanent ones for pak128.britain as I had prioritized on the coding aspects.  One of the diagonal steel piers does have incorrect graphics assigned to it.  As for the lack of guard rails, this would be tricky as the pier object is on the tile below the way object for the brick piers, and may involve additional coding.

3, 14: The zero height start is for two situations: one being to cross a valley starting at the level where the way is desired to be at, the second being to connect two existing piers where the ground beneath are not easily accessible.  This is to mirror the behavior running non elevated ways on elevated ways.  For when the start height is 2 would mimic the behavior of running an elevated way on another.  This will be addressed in the help menu.

4, 5, 8, 12: These should also be addressed in the help menu once written, along with appropriate tool tips.  The steel piers are special in that the deck is within structural component instead of on top of it (the proper term escapes me at the moment, but will be added in game), and have more restrictions.  For the dragging, the difference would only occur with deep valleys.

6. I am not sure what you mean by this.  The brick piers are not compatible with a few odd slope tiles as when designing the pakset, I did not have access to the 3D ground files and could only approximate a few of them.  For the iron piers, the supports were thin enough that I could get it to look right on all 65 possible slopes without too much effort.

7. As with the existing elevated ways, it is intended to use bridges and their ramps to connect piers to ground.  The sloped piers were intended for connecting one level of piers to another.  Being able to use a sloped pier on sloped ground for connections is simple a side effect.

9. This was disabled in the pakset to take into account the depth and leak resistance needed for aquaducts.  Aquaducts are on the pakset TODO list.

10. I will look into this.

11. I can add this to the pakset TODO list.

(2nd list)

2, 4: Added to coding TODO list

3: I will look into this.

It looks like my next step would be writing the help menu so testers know what to test for and any coding corrections. 
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on December 29, 2021, 11:29:18 PM
Excellent, thank you. I will use the same numbering for comments in reply.

1. Noted - prioritising the coding does make sense. As to guard rails, can you not use the existing frontimage/backimage system for this, or, at least, replicate the .dat file syntax if you cannot reuse the existing code?

2. As 1.

3. I shall be interested to see the help menu item on this, and perhaps a demonstration of how it should be used.

4. Noted and understood - it does make sense to have restrictions on the steel piers, providing that these be clearly communicated to the player in tooltips as well as the help text; but a bespoke error message is definitely needed when a player attempts to build in an impermissible way on a restricted pier.

5. Noted - I shall await the tooltips.

6. I cannot fully reproduce the problem that I initially had with this when testing yesterday. However, one difficulty that I do find is that, by default, the cursor will tend to move to try to place a way one tile above the pier, even when this is not possible, rather than on top of the pier itself. To give an example, here is the slope configuration:

(http://bridgewater-brunel.me.uk/screenshots/pier-to-slope-transition.png)

This is what happens when one first attempts to build a road up to it:

(http://bridgewater-brunel.me.uk/screenshots/pier-to-slope-road-attempt.png)

Only carefully moving the mouse cursor slightly downwards does one then get the road to build:

(http://bridgewater-brunel.me.uk/screenshots/pier-to-slope-road.png)

7. It is not obvious that one should use bridges or bridge ramps - certainly, this is not part of the automated pier building, and it seems odd to use bridge parts rather than pier parts when building piers. The most obvious way to build a ground to pier transition is like this, which looks odd and is cumbersome to build:

(http://bridgewater-brunel.me.uk/screenshots/pier-to-slope-transition.png)

Dragging a pier over a slope does not cause it to realise that it should be ending and transitioning to the level of the slope:

(http://bridgewater-brunel.me.uk/screenshots/building-pier-to-slope.png)

(http://bridgewater-brunel.me.uk/screenshots/pier-slope-weird.png)

The behaviour in the last of the screenshots appears somewhat anomalous - the automatic dragging should probably not do this.

Connecting bridges to piers does appear to work:

(http://bridgewater-brunel.me.uk/screenshots/bridge-pier.png)

but the graphics look somewhat anomalous; these will need to be seamless or at least nearly seamless for release (and note that the parapets do cope with the road being a different layer in the case of the bridge, so I imagine that the code could at least largely be re-used for the piers).

In any event, there definitely needs to be a way of automating or at least semi-automating the pier/bridge transition, or else this could be quite awkward for the player.

8. As above.

9. Noted. This sort of restriction will also need to be in the tooltip in that case.

10. Excellent, thank you.

11. Splendid, thank you.

12. I tried creating some deep valleys and dragging the brick arch piers over these valleys with and without CTRL pressed but observed no difference. I am still unclear on the intended effect of CTRL+dragging - it would be helpful to have clarification on this.

13. I assume that the weird placements is the graphical error to which you referred?

14. This is not really answered by the response at no. 3. Perhaps it might be clearer if I were to illustrate with screenshots (and I have also tested this in more detail so can add detail to the original report).

When attempting to drag from the existing end of a pier, the mouse cursor will normally be at one of the following heights:

(http://bridgewater-brunel.me.uk/screenshots/pier-build-continue-2-square.png)

(http://bridgewater-brunel.me.uk/screenshots/pier-build-continue-3-square.png)

Trying to drag onwards from the pier in such a state results in a stack rather than a continuation:

(http://bridgewater-brunel.me.uk/screenshots/pier-build-continue-stack.png)

The only way to continue is to position the mouse cursor very carefully thus:

(http://bridgewater-brunel.me.uk/screenshots/pier-build-continue-1-square.png)

Most of the time, when building from an existing pier, players will want simply to continue rather than to create a stack; yet by far the easiest thing to achieve is a stack rather than a continuation, and it takes very careful mouse placement to get a continuation, which makes continuing existing piers very hard work. I would suggest that, whatever the height of the cursor, the system default to giving a continuation rather than a stack without some further explicit input requesting a stack, e.g. pressing SHIFT or CTRL at the same time as dragging.

I have noticed a further issue with intersections when testing:

15. See these screenshots, showing piers intersecting.

(http://bridgewater-brunel.me.uk/screenshots/pier-escher.png)

There appears to be an erroneous down slope in the graphics at the connexion point, giving the effect of an Escher staircase. These should be flat as demonstrated when covered in road:

(http://bridgewater-brunel.me.uk/screenshots/pier-escher-with-roads.png)

I wonder whether this is related to issue no. 11?

As to the current priorities, I would suggest that the issue at nos. 14 and 6 (which I believe are closely related issues) are probably a high priority for ease of use, followed perhaps by tooltips.

In any event, thank you again for your work on this. I think that I had better await the next set of revisions and detailed tooltips/help text before testing further at this stage, but it is very good to see progress being made on this. Thank you indeed for your work on this project.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on January 02, 2022, 01:42:27 AM
I pushed some changed to handle some of the aforementioned issues.  I have adjusted the tool-tips to include speed and weight limits where applicable (both left un-shown for the default to values of 0xFFFF).  For the steel piers (an any future ones with the same restrictions) the term "(Through Truss)" is appended to the tool-tip.  The restrictions for "through truss" type piers (low_waydeck in the dat file documentation), will be well defined in the help menu (which I am still editing). 

I did fix number 6 above, however the cost of doing so means that pakset designers no longer have the option for a "through truss" type pier that can directly support another pier on top, however I do not think that would have come up often anyway.  After this post, I will be updating the post for the dat file documentation.  Number 10 above has also been fixed, and the method to enable it in the pakset will be described in the dat file documention.  I have activated it for one of the sloped piers in pak128.britain (I also adjusted the coloring for that particular pier, but I am not sure I am happy with it). 

As for using bridges to connect to the piers, I thought it would be obvious as that is the method to connect to existing elevated ways.  Nevertheless, it will end up in the help menu.  For the second to last image in number 7, this is intentional, as one of the main features of building elevated ways is to ignore the ground below it.  For the last image, it may be easier to adjust the bridge graphics to match the pier than the other way around. 

For number 14, I understand what you are saying, however disagree.  Connecting piers can be done by starting on the right and dragging left, or setting the starting height to zero and dragging from the pre-placed pier.  Perhaps other members of the forum can chime in. 

For guard-rails, it is doable but would require some fancy coding.  The existing bridge code cannot be reused as the "bridge" is actually placed on top of the way, whereas the piers (except for the heavily restricted through truss style) are placed beneath the way.  To have them, it would require a dummy object on the way above.

I believe that covers everything code related.  Happy New Year.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on January 02, 2022, 01:46:57 PM
Excellent, thank you for that. I will respond again using the existing number sequences.

1. Guard rails/parapets: I note that the "steelstraightheavy" does have images protruding correctly from the base that obstructs the view of the road/rail/etc. behind it. Could this graphical system not be used for adding parapets to the brick bridge, too? I have not looked into the graphics system in detail, so apologies if I am missing something obvious.

3. Help menu: I note that this is still in progress; I shall be interested to see the final product.

4. Restrictions: We still need bespoke error messages when: (a) a player tries to build an intersection to the "steelstraightheavy" type or similar; and (b) a player tries to build a canal on a pier that does not support aqueducts.

5. Tooltips: This is definitely an improvement. I note that we have an axle load limit but not an overall weight limit: is this intended? I also note that the speed and weight limits are not specified if unlimited: I think that it would be better to specify "axle load: unlimited" and/or "speed: unlimited", as this is easier for the player to understand than a dialogue without this information at all. Also, the individual component parts in the pier blocks menu also need to have the axle load and any other restrictions given.

6. Construction ease: The slope configuration does work better - thank you for that.

7. Collecting slopes: I note that the third example was intentional, and this does make sense. I wonder whether there is any way in which we can automate the building of slopes in the same way as we do for bridges? This may be a more advanced aspect of this project for the future, but it is worth thinking about and would certainly make the player experience of building piers a lot easier.

10. Directional slopes interface: I do not see a change here: the pier tools still choose a slope direction by CTRL+click on a single button, whereas the landscape tools still choose a slope direction by one individual button per direction in the main menu. May I ask what you have changed in this respect?

12. Effect of CTRL key: I am still not clear what this does when dragging. Can you elaborate?

13. Diagonal graphical error: I can still reproduce this error:
(http://bridgewater-brunel.me.uk/screenshots/diagonal-pier-error.png)
I assume that this is the error in the pakset graphics to which you referred?

14. Building continuation: I should be interested in others' views on this - certainly, I should find it much easier if one could build continuations of piers in the same way as one could build continuations of ways. Also, it is not possible (at least not without adjusting the starting height) to continue a pier a single/half height above ground level because of this.

15. Escher effect in slope graphics of brick pier intersections: This still seems to be present.

16. Future treatment of elevated ways (New): I believe that I have mentioned this briefly before - had you any thoughts as to how best to treat this? The current elevated ways are (mostly) inferior to this pier system, and the benefits of having this pier system will be lost if players can continue to build existing elevated ways indefinitely into the future, as the anomalies inherent in the existing system (i.e. the lack of separation between way and supporting structure) will persist permanently. However, there are some cases in which we need the conventional types of elevated ways, being for monorail and maglev trains (indeed, I believe that this is what the current system of elevated ways was designed for). What I would suggest, therefore, is adding a pakset option to the existing elevated ways to make them buildable only by the public player (and shown in the menu toolstrip only for the public player). This would allow existing saved games to be unaffected by the transition, and allow monorails and maglevs to continue using the existing system of elevated ways. Indeed, this could potentially be a useful feature to add generally: any given object might have a simple "buildable_by_public_player_only=1" flag meaning that it would only appear in the build menu and would only be selectable by any other means (e.g. keyboard shortcut) if the current player is the public player. A more sophisticated solution would be to allow certain elevated ways (specified in the pakset) to be converted automatically to piers on loading a saved game, but this would be much more complex to implement.

In any event, I should be very interested in any other players' feedback on the pier system, including but not limited to the issues raised above.

Thank you very much as ever for your work on this, and happy new year to you, too.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on January 02, 2022, 11:35:08 PM
I was a bit rushed when responding last night, so I will respond in order now.

1. It is a bit more complicated than that.  For both the "steelstraightheavy" and bridges the way is on the same 3D tile as the pier or bridge, whereas for most other piers, the way is on the 3D tile above it.  For the "steelstraightheavy" there are two sets of front images, one for when no way is present and one for when a way is present.  As the bridges are defined once per way-type, only the front image for when a way is present is defined.  (The reason I had not thought of this originally is that parapets for bridges are not common where I am from, and for the bridges that do have them, they tend to be quite short relative to those in Britain.  Steel fences, Jersey Barriers, and short guard-rails for roads are more common here.)

3. I attached a draft of the help menu as a preview.

4. I will look into this, however I should note that currently ways do not give an error message unless the problem preventing construction is on end tile.

5. There is currently no absolute weight limit to piers.  For the axle and speed limits, I can put some some indication of no additional limits to way.  A few of the pier blocks do have weight limits given so the afformentioned fix should make it more obvious.

6. You're welcome

7. This would indeed be a more advanced project for the future.

10. I had only changed one pier in the pakset, the brickarchslope1 for testing purposes.  You can still CTRL-Click the icons for that pier, but each of the four will have different default orientations.

12. I just checked a again and must apologize as the CNTL-drag does not appear to be functioning correctly anymore for some reason.  With the fully automated build tool working, it may be best to deprecate this feature.

13. Yes, this is a pakset error.  It is on my list.

15. This is indeed an illusion, but is also present in the existing arch based elevated ways.  It also seams to affect you and me slightly differently since the image with the road to me looks more like an Escher staircase unless I slowly take my glasses off.

16. I had planned on setting the intro and retire dates to before 1700 or after 2100 for all existing elevated ways and any multi-span bridges made obsolete by the pier system.  This allows the save game to still work without any additional coding.  If it is decided to fully deprecate the existing elevated ways, it would likely require year or two of notice to other pakset designers, so any conversions would be a future undertaking.

Hopefully that answers any remaining questions.  I will likely focus on the parapets issue, then further refine the documentation before continuing with pakset design (I may fix the issue with the heavy steel piers sooner through.)
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on January 05, 2022, 03:54:00 PM
Thank you for that: that is most helpful.

First of all, about the name of the system. Having spoken to one or two people, I suspect that the name "piers" may be apt to be confused with marine piers (https://piers.org.uk/), that is, structures projecting out into the sea from the coast to allow boats to dock or used for leisure purposes. I would suggest that this feature be named "elevated way supports", and the existing type of elevated way referred to in future as an "integral elevated way" to distinguish it. I have on my branch pushed some translation texts reflecting this change.

I have also reviewed the help text, which is indeed most helpful. I attach a revised version, including the proposed name change, and the explanation of the difference between this system and the old integral ways. We still need a help text for "pierblocks". I also need a list of the new in-engine texts to translate so that I can add these to en.tab - you will also need to prepare the .dat file in readiness for uploading to Simutranslator.

I turn below to the numbered issues.

1. Guard rails/parapets: I see - it would definitely be good to have the ability to have parapet graphics if possible.

3. Help texts: See above.

4. Bespoke error messages: Thank you for looking into this. I think that we do need bespoke error messages here, even though there are not such errors in other contexts, as elevated way supports are inherently more complex and less intuitively obvious than other things. For example, you do not need an error message telling you that you cannot build a road on the sea or though somebody's house without demolishing it first, but it is much less obvious why one cannot build a canal atop an elevated way support.

5. Tooltips: Thank you - it would definitely be helpful to have it stated when there is no limit. As to an overall weight limit rather than an axle load limit, is this something that you plan to add? I note that we have this for bridges.

7. Connecting slopes: Noted - this would definitely be a good feature, but I understand that this may take a lot of work. This system is useful enough that it is a substantial net gain to usability/balance to include it even without this.

10. Directional slopes interface: Thank you for clarifying - I note that the brick arch slopes now do indeed match the landscape tools. This is helpful - thank you.

12. Effect of CTRL key: Noted.

13. Diagonal graphical error: Noted.

14. Building continuation: Does anyone else have any views on this?

15. Escher effect: interesting - I had not noted this on existing ways. This is a minor issue in any event.

16. Treatment of integral elevated ways: Changing the introduction/retirement dates is a clever way of deprecating these without changing the code - this seems sensible. I suspect that existing integral elevated ways may need to be retained to accommodate maglev and monorail (the latter of which is hard-coded to be an elevated way, I believe), although I note that some have expressed disagreement with this on Discord.

Thank you again for your work on this. This does look as though it will be a significant advance once it is ready, and should allow much better balancing of elevated ways in paksets. I shall look forward to the progress with the pakset and documentation.

Edit: Incidentally, one thing that we do need to test is how this system works in an online/server environment. Can I check whether you have yet had the chance to test this to see whether a client stays in sync with a server when using this feature?
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on January 05, 2022, 04:38:47 PM
I have just attempted to test this system in network mode. Unfortunately, it is not possible to build elevated way supports in network mode: dragging creates the preview, but the pier itself is not built. This will need to be fixed before I can test this properly in network mode.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on January 07, 2022, 01:23:35 AM
Thank You.  "Elevated Way Supports" is a suitable user visible name.  I do plan on writing "pierblocks.txt" shortly. 

For translations, I attached a list of all new text called by translator::translate.  (Note there is some leading and trailing white-space to watch out for.)  I assume that each line would be an entry of program text for a new simutranslator dat file?

I push some updates per the numbers:

1. Code updated, parapets only added to pier-brick-arch.  (I think I finally got the graphics right)
3. Is next on my TODO list
4. Completed.
5. Uses translatable text.

For 16, I did look into the monorails a while back and it appears that the only place in code explicit to monorails being elevated is in depot construction.

For the tools working in client-server mode, I am not sure what I am doing wrong.  For the block construction, the tool is (except for what it builds) identical to that station extension buildings.  Likewise for the automated construction and signal construction.  Am I missing something obvious?
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on January 07, 2022, 12:19:48 PM
Excellent, thank you for this. The new pier graphics for the brick arch piers do look good, especially with the parapets. They seem to join well with the old elevated ways, too:

(http://bridgewater-brunel.me.uk/screenshots/pier-transition-old-elevated.png)

(New piers on the left, old elevated ways on the right)

Have you managed to get the shading right in Evee with the new version of Blender, or did you have to revert to the old Blender internal renderer with the older version? If you were able to use Evee, I should be very interested in how you set this up so that I can see whether this can be used in place of the existing system (although it would be necessary for the existing render scripts to work with this for that to happen as manual exporting is too time consuming for the very large number of images necessary for producing new vehicles).

1. Parapets

We do have some issues with the parapets, however. First of all, attempting to delete an elevated way support with parapets deletes just the parapets before deleting the structure itself:
(http://bridgewater-brunel.me.uk/screenshots/pier-remove-parapet.png)

Secondly, the parapet graphics overlap with depots and stations/stops:

(http://bridgewater-brunel.me.uk/screenshots/parapet-overlap-depot.png)

(http://bridgewater-brunel.me.uk/screenshots/parapet-overlap-station.png)

3. Help (and translation) texts

Thank you for posting the the translation texts. I will review these and add translations at the same time as reviewing the help texts for the pier blocks.

4. Bespoke error messages

Excellent - this is a helpful error message indeed. This makes a lot of difference to usability. Thank you.

5. Tooltips

Excellent, I see that you have now added the speed unlimited option.

16. Treatment of existing integral elevated ways

That is interesting to note about monorail depots.

There is a discussion on the Discord channel at present about this issue - some others are suggesting there that there may not be any need to use integral elevated ways in paksets at all in the future, although I am still not entirely sure how the deck of an elevated monorail which can in theory be replaced can sensibly be treated in the same way as a monorail.

I suspect that this will ultimately be a pakset decision - producing new style elevated way supports will involve significant pakset work, and deprecating the old style integral elevated ways requires pakset intervention as you describe, so probably the best solution in the code is to retain the existing integral elevated ways, allow connecting to new style elevated way supports (as is already possible), and add to the notes for pakset authors that old style integral elevated ways have been at least mostly superseded by the new style elevated way support system.

However, this is closely related to a further consideration, which I will address in its own number below.

17. New Toolstrip icon locations

Currently, we have elevated way supports in their own menu, with the two automatic types having their own buttons and the individual blocks tools with its own submenu. The landscape tools menu still has all the pier blocks.

This is not entirely consistent with the interface for building bridges or elevated ways. Now that we have the system of automatic building with the blocks in their own separate submenu, and thus the number of elevated way support icons in the main menu are small, I suggest moving the elevated way supports tool to the menu of each waytype and removing them from the landscape tools menu. There is already precedent for items (station extension buildings and signalboxes) appearing in multiple waytype toolstrip menus. It would make much more sense for a player to have in the one menu all the things that he/she can build for, e.g., railways or roads than to have to look in a specific menu for one particular sort of bridge-like structure, but to be able to build other types of bridge, way, signalbox, stop, etc., from the other menu.

This has a further advantage: it would be straightforward to exclude elevated way supports not compatible with a waytype from the toolstrip menu of that waytype. For example, elevated way supports not capable of being an aqueduct could be excluded from the canal toolstrip. This would make it much easier for players to understand what could be built.

18. Network mode

Without checking the code path in my graphical debugger at home (I am staying with my parents at present), I cannot check exactly what the problem is here: I do not remember enough detail about how the code works to check this without a debugger. As you have probably gathered by now, what you need to do is call a tool and set parameters, which will transmit these parameters in text form over the network and be received by the server.

What I suggest is that you test this in network mode with a debugger running to see which bits of the code are skipped and trace the error back to the point where things start to go wrong. You can easily set up a game in network mode by saving a game and then loading it with the "Start this game as a server" option checked.

19. New Forge cost tooltip

Incidentally, I notice that the forge costs are still shown on elevated way support decks even though you had removed the forge cost from building ways on top of elevated way supports:

(http://bridgewater-brunel.me.uk/screenshots/pier-building-forge-cost.png)

This also shows forge costs for types of way that cannot be built on this elevated way support. What I would suggest is modifying this to show zero forge cost for the types of ways that can be built, and either not show at all the types of ways that cannot be built or alternatively state that they cannot be built.

In any event, thank you again for your work on this: it is excellent to see this coming along.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on January 07, 2022, 06:23:25 PM
You welcome.  For the graphics, It took a bit of math.  I first extracted three textures from the existing elevated ways images for the three directions that visible walls face.  I used nodes in blender to bypass the shading system such that the correct texture is shown for the walls of the new piers. 

1. Being able to delete parapets was semi-deliberate and partially due to attempting to disable their deletion resulted in preventing ways from being built.  I can easily adjust the behavior so that deleting an empty pier deletes both the parapet and the pier itself, however for non-empty piers, behavior adjustments become non-trivial.  It should also not be too difficult to have parapets be automatically deleted when building depots and stations.

17. The icons and menus are set in the pakset, and leaving the icons in the landscaping tools was an oversight.  For filtering piers by way classification, this is a moderately non-trivial affair as the ways are only filtered by individual type.  For the pakset, I had set all canal and air waytypes to be unbuildable on the brick piers, but could re-enable them individually.  As for the lack of icons, that in mainly due to the pakset still being a work in progress, and the menu should have at least half a dozen pier types when complete.

18. I will continue working on it.

19. Removing the forge cost listings should be an easy fix, but again, determining which way classifications are enabled would be moderately non-trivial.  The way compatibility should be implicit from the pier name.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on January 07, 2022, 09:55:49 PM
Excellent, thank you.

0. Graphics

Interesting - this does not sound like a system that could reliably be used for new objects without vastly increasing the amount of effort involved. It is a shame that Evee cannot be made to be consistent with the existing system - we shall have to keep using the old version of Blender for the time being. Would it not have been easier for you to install an older version of Blender than to go to all this trouble?

This is less significant now for the existing graphics that have been produced, but may be worth bearing in mind for the future.

1. Parapets

Thank you for that clarification - that is helpful. Can the deletion not be configured always to delete the way rather than the parapet when there is both a way and a parapet on the tile so that there is never a situation where there is an attempt to delete a parapet on a tile with a way?

17. Toolstrip icon locations

The pakset specificity of this is noted - but I think that even if we do have 6 different types of automatic way plus one "pierblocks" button, this will not be more than the number of elevated way and bridge types that we already have, so this should ideally be in the way building menu, albeit for other paksets, this will of course be a choice for the pakset author.
It would definitely be helpful to be able to exclude unsuitable types from the relevant menus automatically, but if this is difficult, allowing these to be adjusted manually by the pakset author might well be an acceptable alternative: the important thing is to have only the types on which the current type of way can be built buildable from the relevant way menu.

18. Network mode
Excellent - do let me know when you have made progress so that I can continue testing.

19. Forge cost tooltip
In that case, it may be better simply to remove all reference to the forge cost on elevated way decks.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on January 07, 2022, 11:24:16 PM
0. It was not too much trouble and once created it should now just need a texture change for a different material type.  I have two dozen or so models with animation where back-porting would be nightmare.

1. I will look into that.

17.  I will have to think about this.

18. I fixed the issue with networking.  The problem was that I did not add the pier tools to the "call general tool" function.

19. On my TODO list.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on January 08, 2022, 12:01:49 PM
Excellent, thank you for this.

0. Graphics
Interesting. It may well be that there are divergent workflows for elevated way supports and other pakset objects.

1. Parapets
Excellent, thank you.

18. Networking
Excellent. I have now spent some time testing this, and it does appear to work. I was able to remain in sync over a long period with two different small test games involving sending trains and then loaded 'buses over the piers, creating and deleting them and deleting them when in use. The networking does appear to be working satisfactorily with this now.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on January 10, 2022, 02:41:47 AM
1. I made the corrections.  Parapets are now undeleteable and hidden for stations and depots.

17. Made it possible for pakset designers to filter pier types using the way adjustment bits.  I did not yet update pak128.britain, but tested on a local branch with temporary menus.

19. Corrected.  "Pierdeck" would need to be added to the list of translations.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: Phystam on January 11, 2022, 07:45:13 AM
Thanks for this great work! I am hoping this will be a new system to replace the existing bridges and elevated way.
I would like to implement this new pier system for pak256 as well, but there are a few things I want to make sure of before I do so.
20. when using the automatic construction tool, the piers cannot be built facing a specific direction
For example, if you build a pier that contains a diagonal way from west to north, the pier will always end up facing north. If you then start construction from the end point to build it facing east, you will not be able to connect them together. This is different from the normal way of constructing elevated ways and may confuse the user. This is probably because the piers end up facing north, and you are not allowed to rebuild those piers to face east. I think we need to either allow the piers to be rebuilt at the end point, or use Ctrl+drag to switch the construction direction.
(https://media.discordapp.net/attachments/665986412641779712/930353492881719366/unknown.png)
21. slope tool is not available
In the past, elevation could be changed by using the slope tool at the end of the elevated way. However, this system is not implemented in the new pier system, which makes it inconvenient to build individual ramps.
(https://media.discordapp.net/attachments/665986412641779712/930364752469831710/unknown.png)
22. bitmask is very difficult to specify
The use of bit masks increases flexibility, but on the other hand, they are incomprehensible just by looking at them, and I feel that they need to be made easier to understand, for example, by using symbols to indicate directions, such as NSEW.
23. how can I specify the waytype that can be constructed at the top? If possible, it would be nice to be able to specify constraint_permissive and constraint_prohibitive as well.

--edit: question number
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on January 11, 2022, 10:42:29 PM
Good to here that this is becoming more popular (though it does put a bit more pressure on me).  It is intended to replace most elevated ways, and multi-span bridges, however single span (length limited) bridges would likely be left as is. 

To answer your inquiries:

20. This is an oversight.  I just pushed an adjustment so that the ending pier whilst dragging is diagonal instead of always NS.

21. This would not be simple, hence why it has not been implemented yet.  The coding for piers is closer to that of buildings than to ways, so changing a flat pier to a sloped one would involved demolishing the flat one, finding a suitable replacement (if the pakset designer even included one), and building the slope.  In pak128.britain, we are trying to discourage the use of elevated ways except when absolutely needed. Slopes on elevated ways should be rare enough that this would be a future project, rather than a priority. 

For both 20 and 21, one thing I had considered is to make deleting a pier be refundable if deleted within a specific time-frame of being built (sort of like an undo).  Right now, as with bridges, the piers cost as much to remove as they do to build.

22. Coming from a low level programing and hardware design background, hexadecimal and binary numbering is second nature to me, however I can see how they can be daunting on first glance.  For the individual masks themselves, I do have a map on my desk as to what each bit means for the base, middle, and support masks.  I attached the one used for the brick piers, it has since expanded but it should help.  I also have a diagram if ribi directions and corresponding bits relative the view-port, as well as a list for the sub object masks.  (I have not yet digitized these other charts).  For all but the ribi, it is up to the pakset designer what they mean as so suit needs of the individual paksets.  As for using NESW rather than the raw RIBI, this is not a bad idea, but as having the charts is needed anyway this would not be my top priority.

23. The way filtering is done via the deck_obj_mask for the pier and the deckmask for the ways.  The deckmask must be zero or a superset of the deck obj mask for the way to be built on the pier.  For pak128.britain, this is still incomplete (bits 30 or 31 are set for canals, runways and taxiways to prevent default piers from supporting them, otherwise everything is default). 

I updated the pakset designer documentation in https://forum.simutrans.com/index.php/topic,21271.0.html (https://forum.simutrans.com/index.php/topic,21271.0.html).
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: Phystam on January 12, 2022, 06:11:28 PM
Thank you so much for your response.
20. I see. I will test it.
21. Yes, I know the difficulty. It needs replacement of the elevated way.
22. and 23. Finally I understand how to make the pier system add-ons, thanks to the attached svg file!
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on January 13, 2022, 10:57:19 PM
Excellent, thank you. I have been busy in work this week and have not had a chance yet to test. However, I am interested in the idea that this will place multi-span bridges, as currently it is necessary to use a bridge as a ramp. Using this elevated way support system instead of multi-span bridges would definitely solve a lot of anomalies, including the problem of roads appearing to be, but not actually being, blocked by the bridge supports.

One other thing that we may want to consider is applying a cost multiplier to elevated way supports built over water tiles - perhaps 4x the cost of those built on land, although this should be a pakset setting. Ideally, we would want to implement the same for tunnels built underwater, too: balancing research has unearthed a huge difference in the cost of building tunnels under water as opposed to building them over land. For bridges, building supports in water was always difficult, with the need for caissons and other such mechanics. Bridges that cross water without having actually to have supports built on the water, of course (e.g. girder bridges, with limited length spans), of course, would not have this cost differential.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on January 14, 2022, 03:50:22 AM
Quote from: Phystam on January 12, 2022, 06:11:28 PMUsing this elevated way support system instead of multi-span bridges would definitely solve a lot of anomalies, including the problem of roads appearing to be, but not actually being, blocked by the bridge supports.
This was actually half the reason I made this "patch".

Quote from: jamespetts on January 13, 2022, 10:57:19 PMHowever, I am interested in the idea that this will place multi-span bridges, as currently it is necessary to use a bridge as a ramp.
My plan for pak128.Britain is for the arch bridges to be set for a single span (length of 3) to allow their continued use by the AI and road generators (for factories).  The bowstring bridges would be have their graphic modified to use the pillars from the iron lattice girder rail bridge to prevent the visual anomaly. 

Quote from: jamespetts on January 13, 2022, 10:57:19 PMOne other thing that we may want to consider is applying a cost multiplier to elevated way supports built over water tiles - perhaps 4x the cost of those built on land, although this should be a pakset setting. Ideally, we would want to implement the same for tunnels built underwater, too: balancing research has unearthed a huge difference in the cost of building tunnels under water as opposed to building them over land. For bridges, building supports in water was always difficult, with the need for caissons and other such mechanics. Bridges that cross water without having actually to have supports built on the water, of course (e.g. girder bridges, with limited length spans), of course, would not have this cost differential.

I actually already thought of this, and have a "keep dry" flag which prevents piers with that flag set from being built on ocean tiles (rivers still permitted).  My plan is to have a more expensive "granite" pier to be used as a foundation in ocean tiles.  I was trying to look into how much more expensive a wet foundation for a pier would be, but so far my research (see the snipping of pricing post) appears to have gotten me two steps backwards as far as understanding viaduct pricing.  One thing that we do not (thankfully) need to simulate is that a few land based piers need foundations as if they were in the water, such as for soft clay and bogs.  As for tunnels, the would likely need to be a future project.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: Sirius on January 14, 2022, 06:19:26 PM
Quote from: jamespetts on January 02, 2022, 01:46:57 PMIn any event, I should be very interested in any other players' feedback on the pier system, including but not limited to the issues raised above.
I had been ocupied for a while, but there is my feedback now.

Quote from: jamespetts on January 02, 2022, 01:46:57 PM16. Future treatment of elevated ways (New)
At least in the long-term, i.e. when most active paksets have adapted their graphics, elevated ways in old savegames should be converted to elevated way supports + way.
In the short term, it seems preferable to convert existing elevated way objects into elevated way support + way using the elevated way graphics.
As to the lack of proper graphics and additional dat file definitions, these could not support the whole feature set of elevated way supports.
I see that this conversion might not be quite trivial, so this is of rather low priority.

The reason for this is because some objects in the simuworld interact with elevated ways in a specific way and there are still some bugs around elevated ways, which retains complexity to maintain.
Converting these surely adds some complexity as well, but it's all in a single place and such conversion bugs will be much easier to detect.

In any case, I don't think it's a good idea to maintain elevated way construction for the public player. I see the merit in this as to allow "fixing" accidentally deleted elevated ways, but is this really that useful?
There already exist many cases where constrcution of elevated ways had one day been possible but is not anymore. E.g. when a large building has spawned underneath afterwards or elevated ways that have been constructed over airports or public buildings in an old version.
If we want public service to allow for some "cheating", we should instead disable some collision or constraint checks of the new elevated way support system when using public player.
Disabling such checks, the new system can offer all use cases that the old elevated way system has offered (and which are intentionally restricted by the new system) and even more!


Quote from: jamespetts on January 02, 2022, 01:46:57 PMI should be interested in others' views on this - certainly, I should find it much easier if one could build continuations of piers in the same way as one could build continuations of ways.
It is not quite clear which exact behavior you mean by this.
Relevant advantages of the new system over the old one are handling of uneven terrain as well as the ability to build at any height, not only one tile above ground.
When building elevated structured, I don't think the old behavior of following ground level is desirable in most cases, so in these points it is quite good that the new tool behaves differently.

In other points, I'd prefer a more consistent behavior as well, but I understand that it might not be quite simple to achieve.
I'd prefer junction/crossing construction to be just as simple as building those on elevated ways. Use any way of the same type, connect adjacent grounds, done.
Also I'd pferer slope adjustments to be as simple as on ways. Simply raise or lower an end-tile to alter the slope.
Furthermore, I'd like to see the two-click tool construction style here, just as in usual ways.
But again, I see why these might be rather difficult to implement and I don't think this consistency is mandatory at any cost.


Quote from: jamespetts on December 29, 2021, 12:28:51 AM10. The way of building slopes in different directions is inconsistent with the system in the landscape tools: in the landscape tools, there is one button for each direction, whereas for the piers, there is a single button, which brings up a submenu of the different directions. Ideally, the landscape tool would work as the pier tool does, but failing this, a tooltip explaining to the player that the direction can be selected by CTRL+clicking is necessary to prevent confusion, I think.
A combination of both feels most user freindly to me:
One icon per direction will mess up the menu quite much.
Using ctrl to get a submenu is not intuitive at all. You'll always need a description of this behavior.

There is no sensible definition of a "default direction" for slopes. You always want to build slopes in a specific direction.
So why don't you open a submenu when clicking on the slope icon? Just as default behavior without ctrl involved?
Might even put both slopes in the submenu: single and double.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on January 14, 2022, 10:41:36 PM
Attempting to test this on my Windows system at home, I am getting a compile error. When first merging, a reference to a file called sys\simsys_w32_png.cc is added to the Visual Studio project file, but, in fact, no such file exists. I cannot find it in your Github repository, nor the latest Standard Github repository.

If I remove this file I get linker errors: the compiler expects raw_image_t::raw_image_t(), raw_image_t::~raw_image_t() and raw_image_t::write_png() to be defined, but they are not.

This appears to be associated with this change from Standard from February 2021 (https://github.com/aburch/simutrans/commit/c18e1f3e976530dd1298195a86852ff6538d616b), which I assume that Ranran must have merged at some point recently.

I should be grateful if you could look into this so that I can compile and test this on Windows. Thank you.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: Roboron on January 15, 2022, 12:18:58 AM
Quote from: jamespetts on January 14, 2022, 10:41:36 PMIf I remove this file I get linker errors: the compiler expects raw_image_t::raw_image_t(), raw_image_t::~raw_image_t() and raw_image_t::write_png() to be defined, but they are not.

I'm afraid that is my fault. When working on porting the CMake improvements from Standard, I incorporated those files as part of the changes. However, I forgot to add them to the makefile/vsproject. Since the CMake implementation itself was not "completed" because of the failing zstd build, I did not test the other build systems. I believe Sirius noticed and assigned itself such task, but it is still not done obviously. 

Luckily, I found the fix for the failing zstd two days ago and already was planning on a new PR with both of those things fixed, finally completing the port https://github.com/simutrans/simutrans-extended/pull/11
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on January 15, 2022, 12:34:09 AM
Quote from: Roboron on January 15, 2022, 12:18:58 AM
I'm afraid that is my fault. When working on porting the CMake improvements from Standard, I incorporated those files as part of the changes. However, I forgot to add them to the makefile/vsproject. Since the CMake implementation itself was not "completed" because of the failing zstd build, I did not test the other build systems. I believe Sirius noticed and assigned itself such task, but it is still not done obviously. 

Luckily, I found the fix for the failing zstd two days ago and already was planning on a new PR with both of those things fixed, finally completing the port https://github.com/simutrans/simutrans-extended/pull/11

Thank you. Can I clarify - is that a pull request for the master branch or the piers branch?
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: Roboron on January 15, 2022, 01:12:52 AM
That is a pull request to the master branch of simutrans/simutrans-extended, which is the fork where work started on the new nightly build system. In the middle of this process, the the pier system branch was created from this fork, and not from jamespett/simutrans-extended. So that explains why you have two open PRs with the same issue (https://github.com/jamespetts/simutrans-extended/pull/460#issuecomment-970827598).

I am also getting a bit lost at this point with that many forks, but I guess that currently the order of procedure would be:

1. Merge my PR for simutrans/simutrans-extended.
2. Merge the Nightly Builds PR for jamespett/simutrans-extended (which will be updated after my PR is incorporated).
3. Merge the Pier system PR for jamespett/simutrans-extended (which at this point should be able to be compiled without using CMake).
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on January 15, 2022, 01:42:44 AM
Quote from: Roboron on January 15, 2022, 12:18:58 AMHowever, I forgot to add them to the makefile/vsproject.
I had noticed the makefile stopped working during a merge, but thought it was only a merge error for the pier branch.  I made the corrections during the merge, but for some reason the history in gitk is not showing all of the changes I made.  I do remember having to add libpng to the linking flags and change the source listing to comply with the changes in commit number 3685abc444b26b084710a6f8b4a748aedac9bf66.

For visual studio, I would imagine that the procedure would be similar.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: Roboron on January 15, 2022, 02:23:34 PM
I think you refer to this merge https://github.com/jamespetts/simutrans-extended/commit/c2347e71d6550d87cc3351a201f849dbf99037f9#diff-76ed074a9305c04054cdebb9e9aad2d818052b07091de1f20cad0bbac34ffb52

Well if you made parallel changes, then that should be solved too.

I'm also getting compilation errors on raw_image.bmp when trying to compile on MSVC that I can't reproduce with CMake + MSVC, so someone please tell the PR first.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on January 16, 2022, 12:31:36 AM
Quote from: Roboron on January 15, 2022, 01:12:52 AM
That is a pull request to the master branch of simutrans/simutrans-extended, which is the fork where work started on the new nightly build system. In the middle of this process, the the pier system branch was created from this fork, and not from jamespett/simutrans-extended. So that explains why you have two open PRs with the same issue (https://github.com/jamespetts/simutrans-extended/pull/460#issuecomment-970827598).

I am also getting a bit lost at this point with that many forks, but I guess that currently the order of procedure would be:

1. Merge my PR for simutrans/simutrans-extended.
2. Merge the Nightly Builds PR for jamespett/simutrans-extended (which will be updated after my PR is incorporated).
3. Merge the Pier system PR for jamespett/simutrans-extended (which at this point should be able to be compiled without using CMake).

Thank you for this.

I have merged from your master branch into my nightly-builds branch (which I have pushed), but, unfortunately, I get the following compile errors:


Severity Code Description Project File Line Suppression State
Error C2059 syntax error: 'constant' Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\io\raw_image_bmp.cc 57
Error C2143 syntax error: missing ';' before '}' Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\io\raw_image_bmp.cc 60
Error C2059 syntax error: '}' Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\io\raw_image_bmp.cc 60
Error C1083 Cannot open include file: 'miniupnpc/miniupnpc.h': No such file or directory Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\network\network.cc 890
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: Roboron on January 16, 2022, 01:03:17 AM
The syntax errors are exactly the errors I was referring to in my last message. It also happens to me. However, it is unlikely that they are truly syntax errors, because:
1) the raw_image_bmp.cc is a verbatim copy from Standard
2) make (and msbuild when called using CMake) don't throw any errors
What is the root cause then? I don't have idea. I can have a second look, but I don't have much hope.

QuoteCannot open include file: 'miniupnpc/miniupnpc.h'

I had to change the miniupnpc includes because otherwise the automated build would fail with the default installation of the miniupnpc library (vcpkg and linux repositories). This error is unrelated with the previous, but it indicates that you don't have miniupnpc in a standard include directory.

=> https://github.com/Roboron3042/simutrans-extended/commit/dbc5612725ee9d690e01fc06083a40869e0b5114

You should probably look at your miniupnpc include path, specially if it is a custom installation.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: prissi on January 16, 2022, 01:14:54 AM
MSVC often complains about totally unrelated things if a semicolon or something is missing way above the offinding line or a missing include. Thus got really annoying in the newest MSVC. The real syntax error is  usually way up (an may be even a warning, like statement does not evaluate or so). Please look for warnings in the same file above this offinding line. It will be often cause by a semi-legal statement.

cmake msvc may using clang for building, which can generate different error messages, depending on you setting. I think clang is default for CLI use.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: Roboron on January 16, 2022, 04:53:19 AM
First, in the process of trying to fix this I incorporated the rest of the r9620. Well, it didn't fix the issue, and it caused other builds to fail when I pushed the changes, so I reverted it for now.

Second, renaming the "constants" allowed me to compile without errors. This may indicate that there is a library being imported somewhere that already define constants with those names. Since not CMake nor the Makefile had such problem, it is probably a missconfiguration in the Simutrans-Extended.vcxproj. Furthermore, it probably has something to be with simsys_w.cc since one of the constants also appears there.

However, the Simutrans-Extended.vcxproj is a labyrinth to navigate for me. And if I pushed for CMake was precisely to avoid it. So I'll stop here. You can look at the configurations and try to fix it, or you can embrace the rename fix which is not the correct solution but it will do the trick...
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on January 16, 2022, 01:31:05 PM
Thank you for this. I did indeed have a clashing miniupnpc directory - I think that I have fixed this issue with a custom preprocessor definition to revert to the old locations if specified or else use your new locations.

Oddly, initially, I got linker errors:


Severity   Code   Description   Project   File   Line   Suppression State
Error   LNK2001   unresolved external symbol "public: static unsigned char __cdecl raw_image_t::bpp_for_format(enum raw_image_t::format_t)" (?bpp_for_format@raw_image_t@@SAEW4format_t@1@@Z)   Simutrans-Extended   C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\raw_image_png.obj   1   
Error   LNK2001   unresolved external symbol "public: __cdecl raw_image_t::raw_image_t(unsigned int,unsigned int,enum raw_image_t::format_t)" (??0raw_image_t@@QEAA@IIW4format_t@0@@Z)   Simutrans-Extended   C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\simgraph16.obj   1   
Error   LNK2001   unresolved external symbol "public: __cdecl raw_image_t::~raw_image_t(void)" (??1raw_image_t@@QEAA@XZ)   Simutrans-Extended   C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\simgraph16.obj   1   


I had to compile raw_image.cc individually in Visual Studio to make these go away. That is rather odd, but in any case, this is solved now and this is now on the master branch.

As to the other nightly builds fix, can I check whether you mean this (https://github.com/jamespetts/simutrans-extended/pull/460/commits) pull request? If so, it is showing with merge conflicts in a file whose syntax and function is not known to me, so I do not know how they ought to be resolved.

Thank you very much for your work on this.
Edit: Now having merged this into the pier-system branch, I am also able to get that to compile, too.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on January 16, 2022, 05:08:22 PM
Now that I have been able to compile this on my Windows machine and test it, I find that I am now getting some weird behaviour with the latest version of this. Using the automatic build tool with the brick elevated way supports, I get something that looks like this:

(http://bridgewater-brunel.me.uk/screenshots/peir-weirdness.png)

whereas using the automatic build tool on the metal structure will not build at all, claiming that it cannot find a valid route. I am not sure what has gone wrong, but I should be grateful if you could look into this. Thank you.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: Roboron on January 16, 2022, 05:40:45 PM
Quote from: jamespetts on January 16, 2022, 01:31:05 PMAs to the other nightly builds fix, can I check whether you mean this pull request? If so, it is showing with merge conflicts in a file whose syntax and function is not known to me, so I do not know how they ought to be resolved.

Seems that the CMake source list was the cause of conflict. I solved it it in this pull request https://github.com/jamespetts/simutrans-extended/pull/467

After that, the automated builds should be green again 🟩

Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on January 16, 2022, 08:33:36 PM
Splendid, thank you; now incorporated.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on January 16, 2022, 08:39:30 PM
Quote from: jamespetts on January 16, 2022, 05:08:22 PMNow that I have been able to compile this on my Windows machine and test it, I find that I am now getting some weird behaviour with the latest version of this. Using the automatic build tool with the brick elevated way supports, I get something that looks like this: whereas using the automatic build tool on the metal structure will not build at all, claiming that it cannot find a valid route. I am not sure what has gone wrong, but I should be grateful if you could look into this. Thank you.

I have not seen anything like that before and it is working fine on my computer.  I can think of a few causes it could be:

(A) A strange merge error.  Unlikely as the code file to do the routing is unique to the pier system.
(B) A build/compile/linking error.  Also unlikely, but a clean build may be in order.
(C) The pakset was generated with an older version of makeobj.  I have made that mistake a couple times.  You may want to recompile makeobj and regenerate the pakset.
(D) A memory error.  I really hope this is not the issue.

From my end, (D) is the only thing I can test. For (C), I did have a chance to update the brick graphics and create the stone ones and have pushed the changes.

Edit: Valgrind found no errors during pier construction.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: Roboron on January 16, 2022, 08:56:27 PM
Quote from: jamespetts on January 16, 2022, 08:33:36 PMSplendid, thank you; now incorporated.

You left the last commit out https://github.com/jamespetts/simutrans-extended/pull/467/commits/6da02a032e43f75b7b1cc133c8fea60866383cc3
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: [C] Ranran on January 16, 2022, 09:09:33 PM
Quote from: jamespetts on January 16, 2022, 01:31:05 PMOddly, initially, I got linker errors:
I got the same kind of errors when I tried to test the master branch.

https://github.com/Ranran-the-JuicyPork/simutrans-extended/commit/5b8a71741609d81d6109edeeb60a36171aa57a56
I found one what seemed to be an error, but fixing it did not solve the problem...

1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_create_read_struct が関数 "private: bool __thiscall raw_image_t::read_png_data(struct _iobuf *)" (?read_png_data@raw_image_t@@AAE_NPAU_iobuf@@@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_create_write_struct が関数 "public: bool __thiscall raw_image_t::write_png(char const *)const " (?write_png@raw_image_t@@QBE_NPBD@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_set_longjmp_fn が関数 "public: bool __thiscall raw_image_t::write_png(char const *)const " (?write_png@raw_image_t@@QBE_NPBD@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_create_info_struct が関数 "public: bool __thiscall raw_image_t::write_png(char const *)const " (?write_png@raw_image_t@@QBE_NPBD@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_write_info が関数 "public: bool __thiscall raw_image_t::write_png(char const *)const " (?write_png@raw_image_t@@QBE_NPBD@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_read_info が関数 "private: bool __thiscall raw_image_t::read_png_data(struct _iobuf *)" (?read_png_data@raw_image_t@@AAE_NPAU_iobuf@@@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_set_expand が関数 "private: bool __thiscall raw_image_t::read_png_data(struct _iobuf *)" (?read_png_data@raw_image_t@@AAE_NPAU_iobuf@@@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_set_strip_alpha が関数 "private: bool __thiscall raw_image_t::read_png_data(struct _iobuf *)" (?read_png_data@raw_image_t@@AAE_NPAU_iobuf@@@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_set_filler が関数 "private: bool __thiscall raw_image_t::read_png_data(struct _iobuf *)" (?read_png_data@raw_image_t@@AAE_NPAU_iobuf@@@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_set_packing が関数 "private: bool __thiscall raw_image_t::read_png_data(struct _iobuf *)" (?read_png_data@raw_image_t@@AAE_NPAU_iobuf@@@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_set_strip_16 が関数 "private: bool __thiscall raw_image_t::read_png_data(struct _iobuf *)" (?read_png_data@raw_image_t@@AAE_NPAU_iobuf@@@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_read_update_info が関数 "private: bool __thiscall raw_image_t::read_png_data(struct _iobuf *)" (?read_png_data@raw_image_t@@AAE_NPAU_iobuf@@@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_read_image が関数 "private: bool __thiscall raw_image_t::read_png_data(struct _iobuf *)" (?read_png_data@raw_image_t@@AAE_NPAU_iobuf@@@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_write_row が関数 "public: bool __thiscall raw_image_t::write_png(char const *)const " (?write_png@raw_image_t@@QBE_NPBD@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_write_end が関数 "public: bool __thiscall raw_image_t::write_png(char const *)const " (?write_png@raw_image_t@@QBE_NPBD@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_read_end が関数 "private: bool __thiscall raw_image_t::read_png_data(struct _iobuf *)" (?read_png_data@raw_image_t@@AAE_NPAU_iobuf@@@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_destroy_read_struct が関数 "private: bool __thiscall raw_image_t::read_png_data(struct _iobuf *)" (?read_png_data@raw_image_t@@AAE_NPAU_iobuf@@@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_destroy_write_struct が関数 "public: bool __thiscall raw_image_t::write_png(char const *)const " (?write_png@raw_image_t@@QBE_NPBD@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_init_io が関数 "public: bool __thiscall raw_image_t::write_png(char const *)const " (?write_png@raw_image_t@@QBE_NPBD@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_get_valid が関数 "private: bool __thiscall raw_image_t::read_png_data(struct _iobuf *)" (?read_png_data@raw_image_t@@AAE_NPAU_iobuf@@@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_get_rowbytes が関数 "private: bool __thiscall raw_image_t::read_png_data(struct _iobuf *)" (?read_png_data@raw_image_t@@AAE_NPAU_iobuf@@@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_get_IHDR が関数 "private: bool __thiscall raw_image_t::read_png_data(struct _iobuf *)" (?read_png_data@raw_image_t@@AAE_NPAU_iobuf@@@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_set_IHDR が関数 "public: bool __thiscall raw_image_t::write_png(char const *)const " (?write_png@raw_image_t@@QBE_NPBD@Z) で参照されました。
1>.\simutrans\Simutrans-Extended-debug.exe : fatal error LNK1120: 23 件の未解決の外部参照
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: wlindley on January 16, 2022, 09:11:12 PM
Confirm linker errors on Linux compile.  This seems to be because libpng is only linked when building makeobj -- it was not formerly a dependency of the main program... not sure when/what changed.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on January 16, 2022, 09:57:40 PM
Quote from: wlindley on January 16, 2022, 09:11:12 PMConfirm linker errors on Linux compile.  This seems to be because libpng is only linked when building makeobj -- it was not formerly a dependency of the main program... not sure when/what changed.
The change was in commit number 3685abc444b26b084710a6f8b4a748aedac9bf66.  For Linux, the line "LDFLAGS += -lpng" can be added to the makefile (or the config file) if not using cmake.  (And libpng needs to be installed properly)  This line was added to the pier system PR.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: Roboron on January 16, 2022, 11:42:19 PM
libpng is indeed now needed by the main program. However, when testing in MSVC the library was already part of the configuration (Debug, x64), so I assumed that it was true for others as well. Well I see now that some configuration have it and others don't (¿?). It should be added to any configuration missing it. And the makefile, if merging of the pier branch is not happening anytime soon.

Quote from: Ranran on January 16, 2022, 09:09:33 PMhttps://github.com/Ranran-the-JuicyPork/simutrans-extended/commit/5b8a71741609d81d6109edeeb60a36171aa57a56
I found one what seemed to be an error, but fixing it did not solve the problem...

This is indeed what caused jamespett's issue, thank you for spotting it:
Quote from: jamespetts on January 16, 2022, 01:31:05 PMOddly, initially, I got linker errors:

Error   LNK2001   unresolved external symbol "public: static unsigned char __cdecl raw_image_t::bpp_for_format(enum raw_image_t::format_t)" (?bpp_for_format@raw_image_t@@SAEW4format_t@1@@Z)   Simutrans-Extended   C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\raw_image_png.obj   1   
Error   LNK2001   unresolved external symbol "public: __cdecl raw_image_t::raw_image_t(unsigned int,unsigned int,enum raw_image_t::format_t)" (??0raw_image_t@@QEAA@IIW4format_t@0@@Z)   Simutrans-Extended   C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\simgraph16.obj   1   
Error   LNK2001   unresolved external symbol "public: __cdecl raw_image_t::~raw_image_t(void)" (??1raw_image_t@@QEAA@XZ)   Simutrans-Extended   C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\simgraph16.obj   1   
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on January 18, 2022, 12:21:14 AM
Thanks to Roboron's assistance, I have managed to get this compiling again in Visual Studio, as well as fixing the problem with the master branch on the server, so we can return to focussing on the elevated way support system itself.

I can confirm that deleting a new elevated way support with parapets now automatically deletes both parapet and deck as intended - this is helpful. I have now merged in PJMack's latest pakset build.

However, we still get this odd form of support when building the structures:

(http://bridgewater-brunel.me.uk/screenshots/piers-still-weird.png)

and the steel (iron?) type still refuses to build at all, claiming that it cannot find a valid route. I am not sure why this is. This appears to be a special type of support that allows ways to run underneath the structure - is this correct? Do we have any historical examples of this in a brick arch structure? The height above the road below appears very low - I assume that vehicles marked "is_tall" would not be able to pass underneath?

I can confirm that the parapets are now no longer present on depots and stations, although this leaves 'bus stops on top of these elevated ways looking very odd:

(http://bridgewater-brunel.me.uk/screenshots/pier-bus-stop.png)

I am not sure what is best to do about this, but it merits further consideration in any event.

Thank you again for all your work on this.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on January 18, 2022, 03:40:42 AM
I have attached some screenshots of the graphics that are working on my machine.  I do not know why it is doing that on your machine, but I suspect for some reason there is an issue with loading (or generating) the pakset as the automated build tool has redundant checks in it (the build restrictions are taken into account for route finding and checked again during building).  Makeobj passed with Valgrind.  I put the Valgrind errors for simutrans-extend below (while building a steel pier), which contains no errors relevant to the pier system.  At this point, I am not sure quite what to do.  Has anyone else tested this?

==258325== Memcheck, a memory error detector
==258325== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==258325== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==258325== Command: ./simutrans/simutrans-extended
==258325==
Parsed simuconf.tab for directory layout; multiuser = 1
Pak found: pak128.Britain-Ex/
==258325== Conditional jump or move depends on uninitialised value(s)
==258325==    at 0x53D4565: pa_shm_cleanup (in /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-13.99.so)
==258325==    by 0x53D47A1: pa_shm_create_rw (in /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-13.99.so)
==258325==    by 0x53C44B6: pa_mempool_new (in /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-13.99.so)
==258325==    by 0x51539B1: pa_context_new_with_proplist (in /usr/lib/x86_64-linux-gnu/libpulse.so.0.21.2)
==258325==    by 0x4C72D5E: ??? (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.10.0)
==258325==    by 0x4C7365A: ??? (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.10.0)
==258325==    by 0x4BC5D9B: ??? (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.10.0)
==258325==    by 0x4BC1906: ??? (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.10.0)
==258325==    by 0x2BBF97: UnknownInlinedFun (sdl2_sound.cc:119)
==258325==    by 0x2BBF97: UnknownInlinedFun (sdl2_sound.cc:110)
==258325==    by 0x2BBF97: UnknownInlinedFun (simmain.cc:1173)
==258325==    by 0x2BBF97: sysmain(int, char**) (simsys.cc:1097)
==258325==    by 0x489F0B2: (below main) (libc-start.c:308)
==258325==
==258325== Conditional jump or move depends on uninitialised value(s)
==258325==    at 0x367FF1: fabrik_t::calc_operation_rate(signed char) const [clone .part.0] (simfab.cc:4118)
==258325==    by 0x377836: UnknownInlinedFun (simfab.cc:4106)
==258325==    by 0x377836: fabrik_t::rdwr(loadsave_t*) (simfab.cc:1726)
==258325==    by 0x2C9B47: UnknownInlinedFun (simfab.cc:835)
==258325==    by 0x2C9B47: karte_t::load(loadsave_t*) (simworld.cc:9727)
==258325==    by 0x2CF045: karte_t::load(char const*) (simworld.cc:9135)
==258325==    by 0x2B932D: UnknownInlinedFun (simmain.cc:1493)
==258325==    by 0x2B932D: sysmain(int, char**) (simsys.cc:1097)
==258325==    by 0x489F0B2: (below main) (libc-start.c:308)
==258325==
==258325== Conditional jump or move depends on uninitialised value(s)
==258325==    at 0x367FF9: fabrik_t::calc_operation_rate(signed char) const [clone .part.0] (simfab.cc:4127)
==258325==    by 0x377836: UnknownInlinedFun (simfab.cc:4106)
==258325==    by 0x377836: fabrik_t::rdwr(loadsave_t*) (simfab.cc:1726)
==258325==    by 0x2C9B47: UnknownInlinedFun (simfab.cc:835)
==258325==    by 0x2C9B47: karte_t::load(loadsave_t*) (simworld.cc:9727)
==258325==    by 0x2CF045: karte_t::load(char const*) (simworld.cc:9135)
==258325==    by 0x2B932D: UnknownInlinedFun (simmain.cc:1493)
==258325==    by 0x2B932D: sysmain(int, char**) (simsys.cc:1097)
==258325==    by 0x489F0B2: (below main) (libc-start.c:308)
==258325==
==258325== Conditional jump or move depends on uninitialised value(s)
==258325==    at 0x352E7D: simline_t::recalc_status() (simline.cc:744)
==258325==    by 0x35545C: simline_t::create_schedule() (simline.cc:181)
==258325==    by 0x355C3A: UnknownInlinedFun (simline.cc:96)
==258325==    by 0x355C3A: simlinemgmt_t::rdwr(loadsave_t*, player_t*) (simlinemgmt.cc:133)
==258325==    by 0x41D77E: player_t::rdwr(loadsave_t*) (simplay.cc:916)
==258325==    by 0x2CAEBC: karte_t::load(loadsave_t*) (simworld.cc:9809)
==258325==    by 0x2CF045: karte_t::load(char const*) (simworld.cc:9135)
==258325==    by 0x2B932D: UnknownInlinedFun (simmain.cc:1493)
==258325==    by 0x2B932D: sysmain(int, char**) (simsys.cc:1097)
==258325==    by 0x489F0B2: (below main) (libc-start.c:308)
==258325==
==258325== Conditional jump or move depends on uninitialised value(s)
==258325==    at 0x352EDD: simline_t::recalc_status() (simline.cc:756)
==258325==    by 0x35545C: simline_t::create_schedule() (simline.cc:181)
==258325==    by 0x355C3A: UnknownInlinedFun (simline.cc:96)
==258325==    by 0x355C3A: simlinemgmt_t::rdwr(loadsave_t*, player_t*) (simlinemgmt.cc:133)
==258325==    by 0x41D77E: player_t::rdwr(loadsave_t*) (simplay.cc:916)
==258325==    by 0x2CAEBC: karte_t::load(loadsave_t*) (simworld.cc:9809)
==258325==    by 0x2CF045: karte_t::load(char const*) (simworld.cc:9135)
==258325==    by 0x2B932D: UnknownInlinedFun (simmain.cc:1493)
==258325==    by 0x2B932D: sysmain(int, char**) (simsys.cc:1097)
==258325==    by 0x489F0B2: (below main) (libc-start.c:308)
==258325==
==258325== Conditional jump or move depends on uninitialised value(s)
==258325==    at 0x352EF9: simline_t::recalc_status() (simline.cc:762)
==258325==    by 0x35545C: simline_t::create_schedule() (simline.cc:181)
==258325==    by 0x355C3A: UnknownInlinedFun (simline.cc:96)
==258325==    by 0x355C3A: simlinemgmt_t::rdwr(loadsave_t*, player_t*) (simlinemgmt.cc:133)
==258325==    by 0x41D77E: player_t::rdwr(loadsave_t*) (simplay.cc:916)
==258325==    by 0x2CAEBC: karte_t::load(loadsave_t*) (simworld.cc:9809)
==258325==    by 0x2CF045: karte_t::load(char const*) (simworld.cc:9135)
==258325==    by 0x2B932D: UnknownInlinedFun (simmain.cc:1493)
==258325==    by 0x2B932D: sysmain(int, char**) (simsys.cc:1097)
==258325==    by 0x489F0B2: (below main) (libc-start.c:308)
==258325==
==258325== Conditional jump or move depends on uninitialised value(s)
==258325==    at 0x352FDE: simline_t::recalc_status() (simline.cc:769)
==258325==    by 0x35545C: simline_t::create_schedule() (simline.cc:181)
==258325==    by 0x355C3A: UnknownInlinedFun (simline.cc:96)
==258325==    by 0x355C3A: simlinemgmt_t::rdwr(loadsave_t*, player_t*) (simlinemgmt.cc:133)
==258325==    by 0x41D77E: player_t::rdwr(loadsave_t*) (simplay.cc:916)
==258325==    by 0x2CAEBC: karte_t::load(loadsave_t*) (simworld.cc:9809)
==258325==    by 0x2CF045: karte_t::load(char const*) (simworld.cc:9135)
==258325==    by 0x2B932D: UnknownInlinedFun (simmain.cc:1493)
==258325==    by 0x2B932D: sysmain(int, char**) (simsys.cc:1097)
==258325==    by 0x489F0B2: (below main) (libc-start.c:308)
==258325==
==258325== Thread 39:
==258325== Conditional jump or move depends on uninitialised value(s)
==258325==    at 0x59CCB1: wayobj_t::get_image() const (wayobj.h:59)
==258325==    by 0x5A8039: obj_t::display(int, int, signed char) const (simobj.cc:210)
==258325==    by 0x600F2C: UnknownInlinedFun (objlist.cc:1128)
==258325==    by 0x600F2C: UnknownInlinedFun (objlist.cc:1144)
==258325==    by 0x600F2C: grund_t::display_obj_bg(short, short, bool, bool, bool, signed char) const (grund.cc:1763)
==258325==    by 0x60515E: grund_t::display_obj_all(short, short, short, bool, signed char) const (grund.cc:1674)
==258325==    by 0x335C6C: planquadrat_t::display_obj(short, short, short, bool, signed char, signed char, signed char) const (simplan.cc:547)
==258325==    by 0x20087D: main_view_t::display_region(koord, koord, short, short, bool, bool, signed char) [clone .constprop.0] (simview.cc:576)
==258325==    by 0x58D4B6: display_region_thread(void*) (simview.cc:77)
==258325==    by 0x4B1C608: start_thread (pthread_create.c:477)
==258325==    by 0x499A292: clone (clone.S:95)
==258325==
==258325== Conditional jump or move depends on uninitialised value(s)
==258325==    at 0x59CCB1: wayobj_t::get_image() const (wayobj.h:59)
==258325==    by 0x5A8039: obj_t::display(int, int, signed char) const (simobj.cc:210)
==258325==    by 0x600F2C: UnknownInlinedFun (objlist.cc:1128)
==258325==    by 0x600F2C: UnknownInlinedFun (objlist.cc:1144)
==258325==    by 0x600F2C: grund_t::display_obj_bg(short, short, bool, bool, bool, signed char) const (grund.cc:1763)
==258325==    by 0x604721: grund_t::display_obj_all(short, short, short, bool, signed char) const (grund.cc:1633)
==258325==    by 0x335C6C: planquadrat_t::display_obj(short, short, short, bool, signed char, signed char, signed char) const (simplan.cc:547)
==258325==    by 0x20087D: main_view_t::display_region(koord, koord, short, short, bool, bool, signed char) [clone .constprop.0] (simview.cc:576)
==258325==    by 0x58D4B6: display_region_thread(void*) (simview.cc:77)
==258325==    by 0x4B1C608: start_thread (pthread_create.c:477)
==258325==    by 0x499A292: clone (clone.S:95)
==258325==
==258325== Conditional jump or move depends on uninitialised value(s)
==258325==    at 0x59CCB1: wayobj_t::get_image() const (wayobj.h:59)
==258325==    by 0x5A8039: obj_t::display(int, int, signed char) const (simobj.cc:210)
==258325==    by 0x600F2C: UnknownInlinedFun (objlist.cc:1128)
==258325==    by 0x600F2C: UnknownInlinedFun (objlist.cc:1144)
==258325==    by 0x600F2C: grund_t::display_obj_bg(short, short, bool, bool, bool, signed char) const (grund.cc:1763)
==258325==    by 0x60507E: grund_t::display_obj_all(short, short, short, bool, signed char) const (grund.cc:1682)
==258325==    by 0x335C6C: planquadrat_t::display_obj(short, short, short, bool, signed char, signed char, signed char) const (simplan.cc:547)
==258325==    by 0x20087D: main_view_t::display_region(koord, koord, short, short, bool, bool, signed char) [clone .constprop.0] (simview.cc:576)
==258325==    by 0x58D4B6: display_region_thread(void*) (simview.cc:77)
==258325==    by 0x4B1C608: start_thread (pthread_create.c:477)
==258325==    by 0x499A292: clone (clone.S:95)
==258325==
==258325== Conditional jump or move depends on uninitialised value(s)
==258325==    at 0x59CAD1: wayobj_t::get_front_image() const (wayobj.h:69)
==258325==    by 0x5A7E3E: obj_t::display_after(int, int, signed char) const (simobj.cc:285)
==258325==    by 0x600A2C: UnknownInlinedFun (objlist.cc:1105)
==258325==    by 0x600A2C: UnknownInlinedFun (objlist.cc:1073)
==258325==    by 0x600A2C: grund_t::display_obj_fg(short, short, bool, unsigned char, signed char) const (grund.cc:1789)
==258325==    by 0x604D8A: grund_t::display_obj_all(short, short, short, bool, signed char) const (grund.cc:1731)
==258325==    by 0x335C6C: planquadrat_t::display_obj(short, short, short, bool, signed char, signed char, signed char) const (simplan.cc:547)
==258325==    by 0x20087D: main_view_t::display_region(koord, koord, short, short, bool, bool, signed char) [clone .constprop.0] (simview.cc:576)
==258325==    by 0x58D4B6: display_region_thread(void*) (simview.cc:77)
==258325==    by 0x4B1C608: start_thread (pthread_create.c:477)
==258325==    by 0x499A292: clone (clone.S:95)
==258325==
==258325== Thread 1:
==258325== Conditional jump or move depends on uninitialised value(s)
==258325==    at 0x2957A5: road_vehicle_t::enter_tile(grund_t*) (road_vehicle.cc:1105)
==258325==    by 0x28B039: vehicle_t::hop(grund_t*) (vehicle.cc:1685)
==258325==    by 0x293D4A: road_vehicle_t::hop(grund_t*) (road_vehicle.cc:1141)
==258325==    by 0x28F03D: vehicle_base_t::do_drive(unsigned int) (vehicle.cc:332)
==258325==    by 0x28F20C: road_vehicle_t::do_drive(unsigned int) (road_vehicle.cc:1042)
==258325==    by 0x39E109: UnknownInlinedFun (simconvoi.cc:1333)
==258325==    by 0x39E109: convoi_t::sync_step(unsigned int) (simconvoi.cc:1226)
==258325==    by 0x2DBE3D: karte_t::sync_list_t::sync_step(unsigned int) (simworld.cc:4864)
==258325==    by 0x2DBFC8: karte_t::sync_step(unsigned int, bool, bool) (simworld.cc:4937)
==258325==    by 0x201F38: UnknownInlinedFun (simintr.cc:111)
==258325==    by 0x201F38: interrupt_check(char const*) [clone .constprop.0] (simintr.cc:91)
==258325==    by 0x2D7DFC: karte_t::step() (simworld.cc:5699)
==258325==    by 0x345745: UnknownInlinedFun (simmain.cc:268)
==258325==    by 0x345745: modal_dialogue(gui_frame_t*, long, karte_t*, bool (*)()) (simmain.cc:200)
==258325==    by 0x2BAB31: UnknownInlinedFun (simmain.cc:1617)
==258325==    by 0x2BAB31: sysmain(int, char**) (simsys.cc:1097)
==258325==
==258325== Conditional jump or move depends on uninitialised value(s)
==258325==    at 0x2957A5: road_vehicle_t::enter_tile(grund_t*) (road_vehicle.cc:1105)
==258325==    by 0x39EE53: convoi_t::move_to(unsigned short) (simconvoi.cc:478)
==258325==    by 0x399BCA: UnknownInlinedFun (simconvoi.cc:3486)
==258325==    by 0x399BCA: convoi_t::step() (simconvoi.cc:2224)
==258325==    by 0x2D7F6D: karte_t::step() (simworld.cc:5807)
==258325==    by 0x2C474D: karte_t::interactive(unsigned int) (simworld.cc:11425)
==258325==    by 0x2BA9FE: UnknownInlinedFun (simmain.cc:1644)
==258325==    by 0x2BA9FE: sysmain(int, char**) (simsys.cc:1097)
==258325==    by 0x489F0B2: (below main) (libc-start.c:308)
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on January 18, 2022, 11:32:17 AM
That is very odd. It was working when I was compiling on Linux on the computer that I was using visiting my parents - I am now at home on my Windows machine, compiling with Visual Studio.

Can I check whether you are using Linux or Windows to compile the versions with which you are testing?
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on January 18, 2022, 05:21:35 PM
I am using Linux, more specifically XUbuntu 20.04 with gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 and GNU Make 4.2.1.  (I did at one point test a cmake build)  I have tested this with a debugging build and with optimization maxed out.  As far as I am aware of, all the code written is compliant with C++ standards.  As is does not appear to be working in Windows, this is now a nightmare scenario.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on January 18, 2022, 07:11:17 PM
Quote from: PJMack on January 18, 2022, 05:21:35 PM
I am using Linux, more specifically XUbuntu 20.04 with gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 and GNU Make 4.2.1.  (I did at one point test a cmake build)  I have tested this with a debugging build and with optimization maxed out.  As far as I am aware of, all the code written is compliant with C++ standards.  As is does not appear to be working in Windows, this is now a nightmare scenario.

This is indeed unfortunate. May I suggest testing using Visual Studio Community Edition in a Virtualbox instance? Also, would it help if I were to upload somewhere my pakset (perhaps just the piers part of it) as compiled with this branch with the Windows Visual Studio makeobj so that you can narrow the problem down to either the reading or the writing code?
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on January 18, 2022, 08:21:14 PM
Quote from: jamespetts on January 18, 2022, 07:11:17 PMAlso, would it help if I were to upload somewhere my pakset (perhaps just the piers part of it) as compiled with this branch with the Windows Visual Studio makeobj so that you can narrow the problem down to either the reading or the writing code?
Yes please.  This would be helpful.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on January 19, 2022, 12:08:59 AM
Quote from: PJMack on January 18, 2022, 08:21:14 PM
Yes please.  This would be helpful.

I have put a zipped version of my piers directory here (http://bridgewater-brunel.me.uk/misc/piers.zip) for your analysis. I hope that this helps.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on January 19, 2022, 03:19:43 AM
Quote from: jamespetts on January 19, 2022, 12:08:59 AMI have put a zipped version of my piers directory here for your analysis. I hope that this helps.
The dat files and images in zip file does match what I have (except for yours has DOS line endings and mine has Unix line endings), however the piers.pak file is not in it.  Could you please transmit that file.  Thank You.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on January 19, 2022, 10:59:01 PM
Thank you for checking that. Here (http://bridgewater-brunel.me.uk/misc/piers-pak.zip) is the .pak file (zipped). I hope that this helps.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on January 20, 2022, 01:43:16 AM
Thank you for the pak file.  When using it, it does produce results consistent to your images.  Upon further inspection, the pak file was created with an older version of makeobj-extended (from before October 11th) that predated some of the features that the automated build tools use.  Could you please rebuild makeobj-extended and rebuild the pakset using that?
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on January 22, 2022, 06:20:10 PM
Thank you for checking. This is very odd: I have tried this, verifying that I am using the latest version of makeobj, but I am still getting the same results. I am using makeobj compiled from my pier_system branch.

Would it help if I were to upload the executable?
Edit: I have tried cleaning the build and totally rebuilding and also pulling the latest code from your branch, but this makes no difference.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on January 22, 2022, 08:47:21 PM
The minor adjustment I made last night was for the wrought iron piers (I am still working on the graphics) and should not effect the stone, masonry (AKA brick), or steel piers. 

I double checked the pak file you sent my by viewing it in a hex viewer.  The version number of the pier node is C109, whereas the code in pier_writer.cc (lines 66-70) write a value of C309 for the latest version.  The node length is also the same as when the pier node version number was C109 (if it was not, reading would have caused a crash).  Still, the only conclusion is that somehow or other, the old makeobj-extended executable stuck around after the clean build.  The only thing I can think of is to try cleaning the build, then doing a general file search for makeobj-extended.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on January 22, 2022, 09:15:35 PM
Quote from: PJMack on January 22, 2022, 08:47:21 PM
The minor adjustment I made last night was for the wrought iron piers (I am still working on the graphics) and should not effect the stone, masonry (AKA brick), or steel piers. 

I double checked the pak file you sent my by viewing it in a hex viewer.  The version number of the pier node is C109, whereas the code in pier_writer.cc (lines 66-70) write a value of C309 for the latest version.  The node length is also the same as when the pier node version number was C109 (if it was not, reading would have caused a crash).  Still, the only conclusion is that somehow or other, the old makeobj-extended executable stuck around after the clean build.  The only thing I can think of is to try cleaning the build, then doing a general file search for makeobj-extended.

I do not think that this can be the problem, since I did not build the piers branch at all until December, and then only on my Linux machine: I first compiled the piers branch on the computer that I am using now earlier this month. Also, I checked the file modification date for the executable, and it was dated to-day.

Can you check that my pier_system branch on Github is up to date with the correct code?

Edit

For reference, the version code in my pier_writer.cc is:


uint16 version = 0x8009;

version |= EX_VER;

version += 0x300; //Version number of node times 0x100
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on January 22, 2022, 09:23:46 PM
Hmm - the problem appears to have been solved after some further testing, although I am not entirely sure what it was that did it. It may be that the makefile is ambiguous in the name of makeobj to which it refers when in a Windows environment. In any event, this now does appear to be working - apologies for having taken your time with this.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on January 28, 2022, 02:05:22 AM
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.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on January 29, 2022, 05:51:17 PM
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.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on January 29, 2022, 08:20:36 PM
It should be fixed now.  It was from a recent merge with standard in bauer/hausbauer.cc.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on January 30, 2022, 11:59:25 AM
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.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on January 30, 2022, 07:22:42 PM
Apparently I did not do a good enough job merging bauer/hausbauer.cc.  It should be fine now.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on February 06, 2022, 03:07:54 PM
Quote from: PJMack on January 30, 2022, 07:22:42 PM
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:

(http://bridgewater-brunel.me.uk/screenshots/brick-arch-issues.png)

The same appears to be so of the stone structure:

(http://bridgewater-brunel.me.uk/screenshots/stone-arch-issues.png)

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

(http://bridgewater-brunel.me.uk/screenshots/aqueduct-road.png)

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

(http://bridgewater-brunel.me.uk/screenshots/pier-height.png)

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.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on February 06, 2022, 06:17:22 PM
Quote from: jamespetts on February 06, 2022, 03:07:54 PMFirst 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)?

Quote from: jamespetts on February 06, 2022, 03:07:54 PMAlso, 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.


Quote from: jamespetts on February 06, 2022, 03:07:54 PMThe 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.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on February 08, 2022, 09:04:30 PM
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.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on February 18, 2022, 03:21:14 PM
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.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on February 18, 2022, 05:49:58 PM
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.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on February 18, 2022, 06:41:55 PM
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.

(8) 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:

(http://bridgewater-brunel.me.uk/screenshots/aqueduct-anomaly.png)

(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.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on February 18, 2022, 09:26:52 PM
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.

(8) 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.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on February 18, 2022, 09:54:45 PM
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:
(http://bridgewater-brunel.me.uk/screenshots/pier-height.png)
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.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on February 18, 2022, 10:07:06 PM
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.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on February 22, 2022, 02:04:08 AM
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). 
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on February 23, 2022, 01:52:27 AM
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?
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on February 26, 2022, 01:55:23 AM
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.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on March 01, 2022, 10:07:52 PM
Quote from: PJMack on February 26, 2022, 01:55:23 AMFor 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.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on April 03, 2022, 01:26:34 PM
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.
Title: Elevated slopes
Post by: Matthew on April 25, 2022, 03:17:49 PM
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
(https://i.imgur.com/sgP26rh.jpg)

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?
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: PJMack on April 25, 2022, 05:57:39 PM
Quote from: Matthew on April 25, 2022, 03:17:49 PMI 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.
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: Matthew on April 26, 2022, 04:47:44 AM
Quote from: PJMack on April 25, 2022, 05:57:39 PMThere 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.

QuoteAs 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:

(https://i.imgur.com/2WXdIum.png)

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?
Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: jamespetts on May 25, 2022, 10:59:56 PM
Somebody has made a Youtube tutorial about the new bridge system:

Title: Re: New system for elevated ways (inc. half height and uneven terrain)
Post by: wlindley on May 25, 2022, 11:25:49 PM
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.