News:

Simutrans Forum Archive
A complete record of the old Simutrans Forum.

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

Started by PJMack, October 06, 2021, 10:33:51 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

PJMack

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) 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). 

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.

prissi

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.

Sirius

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.

PJMack

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. 

Sirius

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

Matthew

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

  • It gives players more control over the construction of their ways.
  • You have made a large number of combinations possible at multiple heights.
  • You have already included checks to stop players blocking existing ways.
  • You have already included checks to stop players building on attractions or town halls.
  • You have contributed graphics yourself, instead of leaving them to others.

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 "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, 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.
(Signature being tested) If you enjoy playing Simutrans, then you might also enjoy watching Japan Railway Journal
Available in English and simplified Chinese
如果您喜欢玩Simutrans的话,那么说不定就想看《日本铁路之旅》(英语也有简体中文字幕)。

PJMack

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. 

PJMack


PJMack

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), 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.

Sirius

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

PJMack

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.

prissi

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.

Sirius

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.

PJMack

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.

Sirius

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.

PJMack

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?

Sirius

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.

freddyhayward

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.

PJMack

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.

freddyhayward

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?

Sirius

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.

Sirius

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

PJMack

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).

Sirius

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.

PJMack

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.

Sirius

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.

PJMack

I just split the minor fix into its own branch and pull request.

Sirius

Reviewed including the girders.
They feel way too weak, but that might be a matter of taste.

Incorporated the menu icon fix.

PJMack

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.

jamespetts

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Sirius

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.

PJMack

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.

jamespetts

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

prissi

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.

jamespetts

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.