News:

Simutrans Tools
Know our tools that can help you to create add-ons, install and customize Simutrans.

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.

Sirius

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.

PJMack

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.

jamespetts

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

PJMack

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

  • Move piers to it's own menu or rename landscaping menu
  • Improve tooltips
  • Add weight and/or speed limits (may need to discuss on forum more)*
  • Widen masks to 64 bits*
  • Clean Attic
  • Get lighting to match existing simutrans objects (I think I am almost there)
  • Create wooden and concrete piers
  • Re-render arches and iron girders, create variants of arches (stone, concrete, old brick)
  • Add filters to way and building types*
  • Write Documentation for pakset and user*
  • Add two_click_tool_t for automated piers (without junctions)

Again, I should point out that this is a tentative plan and unfortunately I am not currently in a position to promise anything.

jamespetts

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

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.

PJMack

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.

jamespetts

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

PJMack

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

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.

PJMack

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.

PJMack

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

PJMack

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.

PJMack

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.

jamespetts

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

PJMack

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).  As for the visual studio file, I did what I could to merge it, but have no way of testing it.

jamespetts

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

PJMack

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. 

jamespetts

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:



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



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



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:



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:





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:



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:





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



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



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.



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:



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

PJMack

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.

jamespetts

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:

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

PJMack

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

jamespetts

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

jamespetts

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

PJMack

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?

jamespetts

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:



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


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





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:



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

PJMack

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.

jamespetts

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

PJMack

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.

jamespetts

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

PJMack

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.

Phystam

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.

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.

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

PJMack

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.

Phystam

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!

jamespetts

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

PJMack

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.