News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

Double height bridges and tunnels

Started by kierongreen, June 16, 2013, 09:49:47 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

kierongreen

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.

kierongreen

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:



jamespetts

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.

Fabio

#3
Kieron, could you please post/link the dat files with new entries?

Could anyone compile an updated makeobj?




Quote from: kierongreen on June 09, 2013, 11:20:47 PM
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.


prissi

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.

kierongreen

#5
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:
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.

Fabio

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?

kierongreen

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

Ters

How about slope going down, but bridge going up?

kierongreen

Possible in theory but it would add even more graphics...

kierongreen

Update to 6557 with "minor" bug fix regarding height of bridges built vs preview for those with only a single height....

kierongreen

Update to 6579 (no feature changes/bug fixes)

kierongreen

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.

Dwachs

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.

kierongreen

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

Fabio

Quote from: kierongreen on September 13, 2013, 05:00:29 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.

kierongreen

Ok will look into this tomorrow if I have time.

prissi

What is about tunnels, are those limited too? So far the writer seems untouched.

kierongreen

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.

prissi

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

kierongreen

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.

z9999+

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.

kierongreen

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

Fabio

#23
Quote from: kierongreen on September 25, 2013, 11:47:28 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

Ters

Quote from: Fabio on September 26, 2013, 12:59:04 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.

prissi

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.

Ters

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.

greenling

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!

sdog

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

kierongreen

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.

z9999+

#30
Quote from: sdog on September 26, 2013, 10:02:21 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.


sdog

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

prissi

One might want to forbid single height tunnel for half height though, i.e. force double heights.

Sarlock

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

prissi

That terraforming can fail too, if cliffs are too high. But it may be rare enough to then jsut show the terraforming error message.

Sarlock

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