Author Topic: Double height bridges and tunnels  (Read 13451 times)

0 Members and 1 Guest are viewing this topic.

Offline kierongreen

Double height bridges and tunnels
« on: June 16, 2013, 09:49:47 PM »
This adds some more bridge and pillar images to cope with double heights better:
get_simple now returns different images depending on whether the bridge is 1 tile high or more - currently some bridges in pak128.Britain appear to extend below ground level due to the lower tile height.
get_pillar now uses single and double height pillar images to construct pillars - having only half height pillars could mean a very repetitive pattern.

Existing bridges and paks should be unaffected.

In time I hope to extend this to allow 1 and (optionally) 2 tile high ramps from flat ground, to add more images for linking neighbouring bridges together, and then to add repeating patterns over a number of tiles to make suspension bridges look reasonable in game.

Offline kierongreen

Re: More bridge images
« Reply #1 on: June 18, 2013, 09:48:37 PM »
Removed the additional pillar images as they proved too problematic in asymmetric bridges :( Patch therefore just adds simple double height images in addition to the end images already in trunk. Screenshot to show where the extra simple and end images are used:


 

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15130
  • Total likes: 353
  • Helpful: 154
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: More bridge images
« Reply #2 on: June 18, 2013, 11:45:39 PM »
Splendid idea!
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.

Offline Fabio

  • Devotee
  • Administrator
  • *
  • Posts: 2898
  • Total likes: 5
  • Helpful: 91
  • The Pak128 Guy
    • Visit me on Facebook
  • Languages: EN, IT, RO, FR
Re: More bridge images
« Reply #3 on: June 21, 2013, 02:23:06 PM »
Kieron, could you please post/link the dat files with new entries?

Could anyone compile an updated makeobj?



Images for bridges have been extended:
BackStart/FrontStart - used when starting slope is single height
 BackStart2/FrontStart2 - used when starting slope is double height

Additionally the following are planned but not implemented (yet):
BackImage/FrontImage - to be used when only one tile high
BackImage2/FrontImage2 - to be used when two or more tiles high
BackRamp/FrontRamp - to be used when way rises by 1 tile
BackRamp2/FrontRamp2 - to be used when way rises by 2 tiles

All of the 2 variants are/will be optional and existing pak files continue to work correctly.

« Last Edit: June 21, 2013, 02:28:07 PM by Fabio »

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 8685
  • Total likes: 294
  • Helpful: 228
  • Languages: De,EN,JP
Re: More bridge images
« Reply #4 on: June 21, 2013, 09:40:56 PM »
I would not like to release a new makeobj as there might be still some further changes may be needed for the climate code executable.

Offline kierongreen

Re: More bridge images
« Reply #5 on: June 22, 2013, 05:49:59 PM »
New version - single and double height ramps are now also supported. The double height ramp is optional - if it is present then that type of bridge will be built with a double height ramp, and can end on single or double height ramp, if not then single height ramps will be used at both ends. Of course the other end may be a slope or cliff.

Example dat:
Code: [Select]
Obj=bridge
name=BrickViaduct
copyright=kieron
waytype=track
intro_year=1860
retire_year=1950
topspeed=160
cost=420000
maintenance=1800
max_weight=120
pillar_distance=1
pillar_asymmetric=1
cursor=images/brick-viaduct.4.1
icon=> images/brick-viaduct.4.0
BackImage[NS][0]=images/brick-viaduct.0.5,0,32
FrontImage[NS][0]=images/brick-viaduct.1.5,0,32
BackImage[EW][0]=images/brick-viaduct.0.4,0,32
FrontImage[EW][0]=images/brick-viaduct.1.4,0,32
BackStart[N][0]=images/brick-viaduct.0.0,0,32
FrontStart[N][0]=images/brick-viaduct.1.0,0,32
BackStart[S][0]=images/brick-viaduct.0.2,0,32
FrontStart[S][0]=images/brick-viaduct.1.2,0,32
BackStart[E][0]=images/brick-viaduct.0.1,0,32
FrontStart[E][0]=images/brick-viaduct.1.1,0,32
BackStart[W][0]=images/brick-viaduct.0.3,0,32
FrontStart[W][0]=images/brick-viaduct.1.3,0,32
BackRamp[N][0]=images/brick-viaduct.0.6
BackRamp[S][0]=images/brick-viaduct.0.8
BackRamp[E][0]=images/brick-viaduct.0.9
BackRamp[W][0]=images/brick-viaduct.0.7
FrontRamp[N][0]=images/brick-viaduct.1.6
FrontRamp[S][0]=images/brick-viaduct.1.8
FrontRamp[E][0]=images/brick-viaduct.1.9
FrontRamp[W][0]=images/brick-viaduct.1.7
BackImage2[NS][0]=images/brick-viaduct.2.5,0,32
FrontImage2[NS][0]=images/brick-viaduct.3.5,0,32
BackImage2[EW][0]=images/brick-viaduct.2.4,0,32
FrontImage2[EW][0]=images/brick-viaduct.3.4,0,32
BackStart2[N][0]=images/brick-viaduct.2.0,0,32
FrontStart2[N][0]=images/brick-viaduct.3.0,0,32
BackStart2[S][0]=images/brick-viaduct.2.2,0,32
FrontStart2[S][0]=images/brick-viaduct.3.2,0,32
BackStart2[E][0]=images/brick-viaduct.2.1,0,32
FrontStart2[E][0]=images/brick-viaduct.3.1,0,32
BackStart2[W][0]=images/brick-viaduct.2.3,0,32
FrontStart2[W][0]=images/brick-viaduct.3.3,0,32
BackRamp2[N][0]=images/brick-viaduct.2.6
BackRamp2[S][0]=images/brick-viaduct.2.8
BackRamp2[E][0]=images/brick-viaduct.2.9
BackRamp2[W][0]=images/brick-viaduct.2.7
FrontRamp2[N][0]=images/brick-viaduct.3.6
FrontRamp2[S][0]=images/brick-viaduct.3.8
FrontRamp2[E][0]=images/brick-viaduct.3.9
FrontRamp2[W][0]=images/brick-viaduct.3.7
backPillar[S][0]=images/brick-viaduct.4.3
backPillar[W][0]=images/brick-viaduct.4.2
backPillar2[S][0]=images/brick-viaduct.4.5
backPillar2[W][0]=images/brick-viaduct.4.4
BackImage[NS][1]=images/brick-viaduct-snow.0.5,0,32
FrontImage[NS][1]=images/brick-viaduct-snow.1.5,0,32
BackImage[EW][1]=images/brick-viaduct-snow.0.4,0,32
FrontImage[EW][1]=images/brick-viaduct-snow.1.4,0,32
BackStart[N][1]=images/brick-viaduct-snow.0.0,0,32
FrontStart[N][1]=images/brick-viaduct-snow.1.0,0,32
BackStart[S][1]=images/brick-viaduct-snow.0.2,0,32
FrontStart[S][1]=images/brick-viaduct-snow.1.2,0,32
BackStart[E][1]=images/brick-viaduct-snow.0.1,0,32
FrontStart[E][1]=images/brick-viaduct-snow.1.1,0,32
BackStart[W][1]=images/brick-viaduct-snow.0.3,0,32
FrontStart[W][1]=images/brick-viaduct-snow.1.3,0,32
BackRamp[N][1]=images/brick-viaduct-snow.0.6
BackRamp[S][1]=images/brick-viaduct-snow.0.8
BackRamp[E][1]=images/brick-viaduct-snow.0.9
BackRamp[W][1]=images/brick-viaduct-snow.0.7
FrontRamp[N][1]=images/brick-viaduct-snow.1.6
FrontRamp[S][1]=images/brick-viaduct-snow.1.8
FrontRamp[E][1]=images/brick-viaduct-snow.1.9
FrontRamp[W][1]=images/brick-viaduct-snow.1.7
BackImage2[NS][1]=images/brick-viaduct-snow.2.5,0,32
FrontImage2[NS][1]=images/brick-viaduct-snow.3.5,0,32
BackImage2[EW][1]=images/brick-viaduct-snow.2.4,0,32
FrontImage2[EW][1]=images/brick-viaduct-snow.3.4 ,0,32
BackStart2[N][1]=images/brick-viaduct-snow.2.0,0,32
FrontStart2[N][1]=images/brick-viaduct-snow.3.0,0,32
BackStart2[S][1]=images/brick-viaduct-snow.2.2,0,32
FrontStart2[S][1]=images/brick-viaduct-snow.3.2,0,32
BackStart2[E][1]=images/brick-viaduct-snow.2.1,0,32
FrontStart2[E][1]=images/brick-viaduct-snow.3.1,0,32
BackStart2[W][1]=images/brick-viaduct-snow.2.3,0,32
FrontStart2[W][1]=images/brick-viaduct-snow.3.3,0,32
BackRamp2[N][1]=images/brick-viaduct-snow.2.6
BackRamp2[S][1]=images/brick-viaduct-snow.2.8
BackRamp2[E][1]=images/brick-viaduct-snow.2.9
BackRamp2[W][1]=images/brick-viaduct-snow.2.7
FrontRamp2[N][1]=images/brick-viaduct-snow.3.6
FrontRamp2[S][1]=images/brick-viaduct-snow.3.8
FrontRamp2[E][1]=images/brick-viaduct-snow.3.9
FrontRamp2[W][1]=images/brick-viaduct-snow.3.7
backPillar[S][1]=images/brick-viaduct-snow.4.3
backPillar[W][1]=images/brick-viaduct-snow.4.2
backPillar2[S][1]=images/brick-viaduct-snow.4.5
backPillar2[W][1]=images/brick-viaduct-snow.4.4

Note that backPillar2 is still defined although at present it's not used (I'll add it back in if I can as it really does make some bridges look a lot better).

Screenshot to show the mixed single/double height ramps.

Edit: Here's a build of makeobj from 6555 trunk (trunk besch writer already has support for the extra images used by this patch)
http://simutrans-germany.com/files/upload/6555-makeobj-win.zip

Edit2: New version of patch attached with improved support for loading older games (did result in graphical glitches). This also means that much support for pillar2 is back in, although still unused for new build bridges.
« Last Edit: June 22, 2013, 07:50:24 PM by kierongreen »

Offline Fabio

  • Devotee
  • Administrator
  • *
  • Posts: 2898
  • Total likes: 5
  • Helpful: 91
  • The Pak128 Guy
    • Visit me on Facebook
  • Languages: EN, IT, RO, FR
Re: More bridge images
« Reply #6 on: June 22, 2013, 10:43:05 PM »
thanks a lot, kieron!

could it be possible - in future - to have two-tile ramps to climb from ground to double height (especially for half height paksets) with the gentler gradient?

Offline kierongreen

Re: More bridge images
« Reply #7 on: June 22, 2013, 10:57:28 PM »
Well with a bit of thought you can do this now (see the screenshot which shows different ways at either end of the bridge). But to have a two-tile ramp with completely flat ground would have to wait until/if we have more flexible bridges. Those will in turn need more graphics although I have been giving some thought as to how the interface for building might work...

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4545
  • Total likes: 165
  • Helpful: 106
  • Languages: EN, NO
Re: More bridge images
« Reply #8 on: June 23, 2013, 08:59:18 AM »
How about slope going down, but bridge going up?

Offline kierongreen

Re: More bridge images
« Reply #9 on: June 23, 2013, 09:40:16 PM »
Possible in theory but it would add even more graphics...

Offline kierongreen

Re: More bridge images
« Reply #10 on: June 25, 2013, 09:03:26 PM »
Update to 6557 with "minor" bug fix regarding height of bridges built vs preview for those with only a single height....

Offline kierongreen

Re: More bridge images
« Reply #11 on: July 07, 2013, 05:15:04 PM »
Update to 6579 (no feature changes/bug fixes)

Offline kierongreen

Re: More bridge images
« Reply #12 on: July 08, 2013, 11:22:45 PM »
Final update to 6582 - now behaves correctly for bridges with no back images (e.g. powerlines).

Any objections to including in trunk? Works correctly with current pak64 in single height mode - pak128 and pak128.Britain are waiting on this to implement double height bridges correctly.

Offline Dwachs

  • DevTeam, Coder/patcher
  • Administrator
  • *
  • Posts: 4143
  • Total likes: 137
  • Helpful: 147
  • Languages: EN, DE, AT
Re: More bridge images
« Reply #13 on: July 09, 2013, 07:56:28 PM »
Just skipped through the patch: in  bridgewriter.cc there is a silly line starting with //intf .. this can be deleted :)
Parsley, sage, rosemary, and maggikraut.

Offline kierongreen

Re: More bridge images
« Reply #14 on: July 09, 2013, 08:02:54 PM »
The intf line is just copied from existing code. It occurs several times so I think is better taken out in  a separate commit.

--

Edit: Committed r6584. I've left the intf in for now.
« Last Edit: July 10, 2013, 01:55:36 AM by kierongreen »

Offline Fabio

  • Devotee
  • Administrator
  • *
  • Posts: 2898
  • Total likes: 5
  • Helpful: 91
  • The Pak128 Guy
    • Visit me on Facebook
  • Languages: EN, IT, RO, FR
Re: Double height paks
« Reply #15 on: September 25, 2013, 04:49:36 PM »
Ramp N/S/E/W is used when bridge begins or ends on flat ground and is rising by 1 height step.
Ramp2 N/S/E/W is used when bridge begins or ends on flat ground and is rising by 2 height steps. If not present then bridge can only rise by 1 height step

This doesn't work for half heights.
By design choice I want to limit railways ramps to half height only.
Yet, using Ramp (but no Ramp2) I get full height bridges with the ramps obviously misplaced.

Offline kierongreen

Re: Re: Double height paks
« Reply #16 on: September 25, 2013, 05:36:46 PM »
Ok will look into this tomorrow if I have time.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 8685
  • Total likes: 294
  • Helpful: 228
  • Languages: De,EN,JP
Re: Re: Double height paks
« Reply #17 on: September 25, 2013, 09:13:37 PM »
What is about tunnels, are those limited too? So far the writer seems untouched.

Offline kierongreen

Re: Re: Double height paks
« Reply #18 on: September 25, 2013, 10:08:47 PM »
Tunnels rely on a way, tunnel then follows restrictions for way.

Edit - above applies within tunnels. For tunnel entrances height must be single height if pak conversion factor 1, double height if pak conversion factor 2.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 8685
  • Total likes: 294
  • Helpful: 228
  • Languages: De,EN,JP
Re: Re: Double height paks
« Reply #19 on: September 25, 2013, 10:16:49 PM »
Shouldn't we consider also tunnel mound into steeper slopes? It would make much more sense, especially if there is no way for such a slope ...

Offline kierongreen

Re: Re: Double height paks
« Reply #20 on: September 25, 2013, 10:53:55 PM »
Would need double height graphics, but main issue is that you would also then need to consider what happens if exit is half way up a slope.

Offline z9999+

Re: Re: Double height paks
« Reply #21 on: September 25, 2013, 11:34:43 PM »
But pak64 doesn't have half height slope. I agree with prissi.

In pak64, bridges don't need rising by 2 height steps, one step is enough.
And tunnel mouth should be allowed both on single and double height slope.

Offline kierongreen

Re: Re: Double height paks
« Reply #22 on: September 25, 2013, 11:47:28 PM »
It's because pak64 has double height slopes that there is the issue.

Tunnel mouth on both single and double height slope means 3 mouths are needed. Single height, double height (first level) and double height (second level).

Offline Fabio

  • Devotee
  • Administrator
  • *
  • Posts: 2898
  • Total likes: 5
  • Helpful: 91
  • The Pak128 Guy
    • Visit me on Facebook
  • Languages: EN, IT, RO, FR
Re: Re: Double height paks
« Reply #23 on: September 26, 2013, 12:59:04 PM »
Tunnel mouth on both single and double height slope means 3 mouths are needed. Single height, double height (first level) and double height (second level).

That would be great for half height paksets: tunnel mouths on full (double) height or a 2-tile long tunnel mouth for 2 half height slopes.
Similarly, bridge ramps would also be great if 2-tile long, the first ramp tile raising to half height and the second ramp tile raising to the full height.



Edit: Bug report split here
« Last Edit: September 27, 2013, 11:14:21 AM by Fabio »

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4545
  • Total likes: 165
  • Helpful: 106
  • Languages: EN, NO
Re: Re: Double height paks
« Reply #24 on: September 26, 2013, 02:54:29 PM »
That would be great for half height paksets: tunnel mouths on full (double) height or a 2-tile long tunnel mouth for 2 half height slopes.
Similarly, bridge ramps would also be great if 2-tile long, the first ramp tile raising to half height and the second ramp tile raising to the full height.

You are thinking horizontally, while kierongreen is thinking vertically. The latter is a more pressing problem, I think. Fabio's suggestion for bridges would be nice, but there might be more problems with tunnels due to their somewhat different nature. Tunnels should be doable, and look good with a cutting followed by a normal opening. It is perhaps also the most realistic.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 8685
  • Total likes: 294
  • Helpful: 228
  • Languages: De,EN,JP
Re: Re: Double height paks
« Reply #25 on: September 26, 2013, 08:01:48 PM »
I think a tunnel which a double height slope at its end will just trigger "Cannot buiild tunnel here". OpenTTD does it (or rather terraforms it into single slope). So I thin double height, starting at ground and single height (starting at ground) is ok. Double height, starting at intermediate level will require further codechanges and may even have gaps in the tracks. No, terraform then, I would say.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4545
  • Total likes: 165
  • Helpful: 106
  • Languages: EN, NO
Re: Re: Double height paks
« Reply #26 on: September 26, 2013, 08:12:07 PM »
I also think tunnels should only exit at the bottom of a sloped tile. My concern was how to indicate properly and understandably what, and where, the problem is to the player. I think it's very much doable, but it must be done.

Offline greenling

  • Lounger
  • *
  • Posts: 1729
  • Total likes: 1
  • Helpful: 15
  • Simutransarchology it my hobby!
  • Languages: DE,EN
Re: Re: Double height paks
« Reply #27 on: September 26, 2013, 08:29:30 PM »
Hello All
I Think that tunnels can only build on double highed level tile. :o
The Building of tunnels on a half level Tile need new Painted tunnels. :o
Opening hours 20:00 - 23:00
(In Night from friday on saturday and saturday on sunday it possibly that i be keep longer in Forum.)
I am The Assistant from Pakfilearcheologist!
Working on a big Problem!

Offline sdog

Re: Re: Double height paks
« Reply #28 on: September 26, 2013, 10:02:21 PM »
@greenling: In the case discussed double height means twice the height of current simutrans. Such a pak-set would not have half-height tiles. This is planned for pak64.

@Ters
When a tunnel ends at a double height tile it could be terraformed into a configuration where only a single height tile is involved.

(a) When a tunnel ends in the lower half, the tunnel would end at a normal single height slope and the tile above it -- the former upper half of the double height slope -- would become empty with the adjacent tile being connected by an escarpe. (see improvised figure below)

\    |
 \   0

(b) When a tunnel ends at the upper half of a double height slope, the upper half of the slope would be turned into a single height slope with tunnel portal. The lower part of the double height tile would end with an escarpement.

\    0
 \    |

This way only the two stacked tiles forming the double height slope would have to be changed. This would not look good, but it would give the player direct feedback and a way to correct it, with the slope tool (or a bridge)

Offline kierongreen

Re: Re: Double height paks
« Reply #29 on: September 26, 2013, 10:05:54 PM »
Autoterraforming would be a good idea to correct slopes anyway - and would cover both half and double height paks. It's not alway easy to know where a tunnel exit might be so having the game work this out for you would seem to make it easier for players. Also dragging tunnels (entrance to entrance) would be another player friendly feature.

Offline z9999+

Re: Re: Double height paks
« Reply #30 on: September 26, 2013, 10:30:28 PM »
(b) When a tunnel ends at the upper half of a double height slope, the upper half of the slope would be turned into a single height slope with tunnel portal. The lower part of the double height tile would end with an escarpement.

\    0
 \    |


There is no tile at upper half of the slope. Even thought you use slice view, you never select that tile.

I added a image. Vertically, tunnel mouth cannot exist on the same tile.
So, upper half of the slope is empty.

« Last Edit: September 26, 2013, 11:00:40 PM by z9999+ »

Offline sdog

Re: Re: Double height paks
« Reply #31 on: September 26, 2013, 11:03:48 PM »
Then i rather ought have phrased it as "When a tunnel would end at the volume element that is directly above a volume element that is the base of a double height slope, following would be done: The lower volume element is changed to a solid ground volume faced by a vertical escarpment in the direction the previous slope was facing. The upper volume element would be changed to a single height slope of an orientation corresponding to the previous double height slope. It is housing a standard height tunnel entrance."

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 8685
  • Total likes: 294
  • Helpful: 228
  • Languages: De,EN,JP
Re: Re: Double height paks
« Reply #32 on: September 26, 2013, 11:44:03 PM »
One might want to forbid single height tunnel for half height though, i.e. force double heights.

Offline Sarlock

Re: Re: Double height paks
« Reply #33 on: September 27, 2013, 02:32:12 AM »
I like sdog's suggestion.  Simple and elegant.  Just auto-terraform the exit to make it work.  Far better to create a strange looking exit than for the tunnel building to fail and the player being potentially confused as to why.  Then the player can either make the exit work through terraforming or redo the tunnel at a different elevation.

For half-height paks, tunnels should only be available on a full slope, half-height is too short graphically.  Again, there will need to be some terraforming done here to make the exit slope work if it is a half-height slope (or exits at the top part of a full slope).
Current projects: Pak128 Trees, blender graphics

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 8685
  • Total likes: 294
  • Helpful: 228
  • Languages: De,EN,JP
Re: Re: Double height paks
« Reply #34 on: September 27, 2013, 10:39:52 AM »
That terraforming can fail too, if cliffs are too high. But it may be rare enough to then jsut show the terraforming error message.

Offline Sarlock

Re: Double height bridges and tunnels
« Reply #35 on: September 27, 2013, 02:35:27 PM »
The restriction of 2 vertical cliffs: is this a limit due to program/graphical constraints or is this mostly a cosmetic limitation (due to it being too far down to see behind it when pointing north or west)?  Meaning, in the rare instance that requires it, if we had to use 3 vertical tiles to configure an exit, how would this affect things?
Current projects: Pak128 Trees, blender graphics