The International Simutrans Forum

 

Author Topic: New system for elevated ways (inc. half height and uneven terrain)  (Read 1403 times)

0 Members and 1 Guest are viewing this topic.

Offline PJMack

  • *
  • Posts: 43
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.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 10905
  • Languages: De,EN,JP
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #1 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.

Offline Freahk

  • Devotee
  • *
  • Posts: 1624
  • Languages: DE, EN
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #2 on: October 07, 2021, 05:20:25 PM »
I 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
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.
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.


Quote
Also 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.
« Last Edit: October 07, 2021, 11:56:00 PM by Freahk »

Offline PJMack

  • *
  • Posts: 43
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #3 on: October 08, 2021, 02:42:13 AM »
Quote
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.
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.

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

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

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

Offline Freahk

  • Devotee
  • *
  • Posts: 1624
  • Languages: DE, EN
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #4 on: October 08, 2021, 04:04:16 PM »
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.
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.

As 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 :)
« Last Edit: October 09, 2021, 12:09:04 AM by Freahk »

Offline Matthew

  • Devotee
  • *
  • Posts: 622
    • Japan Railway Journal
  • Languages: EN, some ZH, DE & SQ
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #5 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!:
  • 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

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.

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.

Offline PJMack

  • *
  • Posts: 43
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #6 on: October 09, 2021, 02:49:57 AM »
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 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).

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

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

Offline PJMack

  • *
  • Posts: 43
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #7 on: October 09, 2021, 08:27:32 PM »
Just a status update, sloped piers are now working.

Offline PJMack

  • *
  • Posts: 43
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #8 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), 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.

Offline Freahk

  • Devotee
  • *
  • Posts: 1624
  • Languages: DE, EN
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #9 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

Offline PJMack

  • *
  • Posts: 43
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #10 on: October 13, 2021, 09:33:59 PM »
So 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.
About 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.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 10905
  • Languages: De,EN,JP
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #11 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.

Offline Freahk

  • Devotee
  • *
  • Posts: 1624
  • Languages: DE, EN
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #12 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.

Offline PJMack

  • *
  • Posts: 43
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #13 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.

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.
This is deliberate as the current elevated way system allows elevated ways to be built on another players land.
When 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.
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.
I will also be working on this.
for 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.

Offline Freahk

  • Devotee
  • *
  • Posts: 1624
  • Languages: DE, EN
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #14 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.

Offline PJMack

  • *
  • Posts: 43
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #15 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?

Offline Freahk

  • Devotee
  • *
  • Posts: 1624
  • Languages: DE, EN
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #16 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.

Offline freddyhayward

  • Devotee
  • *
  • Posts: 692
  • Languages: EN
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #17 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.

Offline PJMack

  • *
  • Posts: 43
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #18 on: October 19, 2021, 07:10:03 PM »
It 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.

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

Offline freddyhayward

  • Devotee
  • *
  • Posts: 692
  • Languages: EN
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #19 on: Yesterday at 07:06:06 AM »
As 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?

Offline Freahk

  • Devotee
  • *
  • Posts: 1624
  • Languages: DE, EN
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #20 on: Yesterday at 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.

Maybe 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.
« Last Edit: Yesterday at 03:47:16 PM by Freahk »

Offline Freahk

  • Devotee
  • *
  • Posts: 1624
  • Languages: DE, EN
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #21 on: Yesterday at 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:
Code: [Select]
git fetch origin pull/<PRid>/head
git checkout FETCH_HEAD

In this specific case:
Code: [Select]
git fetch origin pull/3/head
git checkout FETCH_HEAD

Alternatively, use GitHub Desktop or GitHub CLI
« Last Edit: Yesterday at 08:18:50 PM by Freahk »

Offline PJMack

  • *
  • Posts: 43
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #22 on: Yesterday at 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).

Offline Freahk

  • Devotee
  • *
  • Posts: 1624
  • Languages: DE, EN
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #23 on: Yesterday at 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.

Offline PJMack

  • *
  • Posts: 43
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #24 on: Yesterday at 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.

Offline Freahk

  • Devotee
  • *
  • Posts: 1624
  • Languages: DE, EN
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #25 on: Yesterday at 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.
« Last Edit: Yesterday at 10:43:48 PM by Freahk »

Offline PJMack

  • *
  • Posts: 43
I just split the minor fix into its own branch and pull request.

Offline Freahk

  • Devotee
  • *
  • Posts: 1624
  • Languages: DE, EN
Reviewed including the girders.
They feel way too weak, but that might be a matter of taste.

Incorporated the menu icon fix.