r5773 Double Heights

[kierongreen]

This is a testing release, while the game engine is playable paksets will need altering to support this. In addition any saved games made using this patch will most likely not be able to be loaded in future releases. It will mostly be of use to pakset maintainers who might wish to consider supporting double heights. There are likely to be many, potentially severe bugs so use at your own risk!

This patch fixes support for double heights in simutrans. Existing saved games can be loaded, and will be automatically converted based on a new entry in a pakset simuconf.tab "height_conversion_factor". This can be either 1, converting existing slopes to new single slopes or 2, converting existing slopes to new double slopes. This conversion factor also alters gameplay (see below). New and converted saved games will be saved as simutrans "version 112". This is only a temporary measure, and until (if) this patch is incorporated into trunk this is liable to change.

Gameplay features:
Single and double height slopes will be used when generating new maps or loading heightmaps. Climates, shore and snow are displayed correctly onto these.
All ways and elevated ways can be built on single height slopes, if ImageUp2 images for slopes have been specified then additionally they can be built on double height slopes.
Bridges can be constructed to and from single or double height slopes providing the tops are the same height.
Bridges will only connect to flat ground if they are 1 (conversion factor 1) or 2 (conversion factor 2) tiles above.
Tunnels can only be built into single height (conversion factor 1) or double height (conversion factor 2) slopes.
Tunnels can only have single height slopes within them.
Vehicles have higher friction on double slopes, less on single slopes.
For conversion factor 2 only a one tile height gap is required above and below when building any way, bridge or tunnel (to allow clearance for vehicles graphically under bridges).

Notes for pakset maintainers:
In deciding whether to choose conversion factor 1 or 2 the following may be helpful:
conversion factor 1 keeps existing heights as they are, allowing new more mountainous double height slopes
conversion factor 2 converts existing heights, and allows new more gentle slopes (and you will want to half the previous height when using this).

The attached files use conversion factor 2, and reduce the tile height from 16 to 8 for pakBritain.

The following new graphics are required (examples included):
Double height lightmaps
Transition textures for slopes and beaches
Markers
Grids
Foundations - natural and landmade. Double height images drawn if not present already
Double height way and way object images (note: ImageUp must be provided, ImageUp2 is optional, however if you are using conversion factor 2 then you will need to draw images that are half the existing gradient for all ways and way objects, if these are not present then the patch will use existing slope images which will not look right!)
Pavements and tunnel ground images.


Known Issues:
Powerline Bridges have some problems.
Powerline Tunnel Transformers will most likely appear in the wrong position.
Some terrain altering is not permitted when it should be when near ways.
Not considered 1 tile high climates yet when drawing terrain, so these will result in graphical glitches.


Attached files:

http://simutrans-germany.com/files/upload/5773-double-binary.zip
linux executable for sim and makeobj, and configuration files and compiled pak files for pak128.Britain. Copy over an existing installation of simutrans with pak128.Britain to see and use new slopes. Compile your own executable if you have windows (or the linux version doesn't work for some reason).

http://simutrans-germany.com/files/upload/5773-double-source.zip
diff file against svn 5773. Source dats, pngs and (where applicable) blends for paks. Look at these to work out what you will have to change for your own pakset. Some graphics are completely new, others are adapted.


I've not drawn new graphics for every way in pak128.Britain, just a few that I needed for testing myself. In time I'll try to provide more.

Bug reports are welcome (particularly if you are designing a pakset to use conversion factor 1 as I have not tested this much).

Screenshot shows ways on single and double slopes (also an error with the marker that has since been fixed).

[An_dz]

Wow, this patch is marvelous!
Incredible effort kierongreen. It looks really sweet.

[rainer]

Wow! Great! I will check it carefully and use it in pak64.ho-scale.
Hopefully this will come to a status which enables it to be included in the main trunk!

Many thanks for the great work!

[Carl]

This looks seriously awesome. I look forward to having time to experiment with this in my projects.

[kierongreen]

I've tried compiling a test release (SDL) for windows also:

http://simutrans-germany.com/files/upload/5773-double-binary-win.zip
This contains windows executable for sim and makeobj, and configuration files and compiled pak files for pak128.Britain. Copy over an existing installation of simutrans with pak128.Britain to see and use new slopes.

Feedback on whether this works, and any dll's it requires would be appreciated (as I don't have a proper windows system to test it on).

[sdog]

this looks like the long awaited solution to make half-height useable (through the double height tiles required for bridges and tunnels.)

157 kB diff file, that's doesn't look like a trivial change.

[HDomos]

The windows version works cool
One thing I noticed: When I want to raise a single heigth slope to double heigth next to something it brings up the "groung not empty" warning. See picture:

[kierongreen]

When I want to raise a single heigth slope to double heigth next to something it brings up the "groung not empty" warning.

Thank you for this report - I've encountered this issue myself:
Some terrain altering is not permitted when it should be when near ways.

I've not worked out a fix yet - you should be able to adjust height when ways are not nearby though.

[rainer]

Sorry, I am running in problems. What I did:

- moved aside my entire $Simutrans_foo to get a clean environment.
- got a fresh pak128.Britain and unzipped it.
- downloaded your package and installed it over the rest.
- added the directories font/ and text/ from standard.

When starting your version, Simutrans claims not to find cityrules.tab,
which is placed correctly in both, ~/simutrans/config/ and
~/simutrans/pak128.Britain/config/

What am I doing wrong?

Astonished regards
Rainer

[edit] Tried it with /usr/share/games/simutrans, same result.

[kierongreen]

You should have the following directory structure already, use standard download for simutrans and pak128.Britain to get this. Then copy the contents of the binary zip over this.

Code Select Expand


<simutrans>
-config
-font
-music
-pak128.Britain
  -config
  -text
-skin
-text


[rainer]

Kierongreen,

thanks for your quick reaction.

This is exactly the directory structure I have. I followed your instructions again.

Same result : - /

Got it! A rest of an installation at /usr/share/games/simutrans/ was causing the problems.
Deleted it. It's running now.

Many thanks for your help!

[kierongreen]

If you run it as single user (add -singleuser to commandline when running) then it should ignore other installs on the computer - however you'll not have access to any saved games from other installs either.

[Spartanis]

 


WOW!!!




You just did the most amazing thing ever done to Simutrans since Simutrans first created!.. This is exactly the type of thing i liked to see and play in!


In fact, i think im going to create my paksets for this particular PATCH of yours.


One simple question: When creating an addon, are there any differences to coding a DAT file than to the original way? (eg: way types = 4x half-height slope, 4x normal slope, etc etc.. in regards to image[0][0] etc etc)

Just saw your attached source file.. Having a look at it now...

[kierongreen]

way dat files remain unchanged except for adding an ImageUp2[direction][snow].  This is used for double height slopes in game.

Remember that if you are modifying an existing pakset you have the option of adding half height slopes (with height_conversion_factor=2) or double slopes (with height_conversion_factor=1):
If you are modifying an existing pakset to have double heights you only need to define and draw ImageUp2[direction][snow] images if you want players to be able to construct the way on double height slopes.

If you are adding half height slopes then you will need to define and draw these as ImageUp[direction][snow]. Any existing slope images will now need to be defined as ImageUp2 in this case.

I hope that makes sense!

[Ters]

As games start having more realistic slopes, rather than the simple distinction between flat and slope, I start getting annoyed by the fact that trains drive straight up the steep slopes. Perhaps half-height Simutrans should have a, possibly pak-togglable, restriction that railroad tracks can only be laid on the half-height slopes.

[VS]

Ters - That isn't a new idea, and I dare say shared by many

[kierongreen]

Perhaps half-height Simutrans should have a, possibly pak-togglable, restriction that railroad tracks can only be laid on the half-height slopes.

Ways which do not have ImageUp2 images defined cannot be built on double height slopes. A pak author could therefore choose to disable this for railways for example.

Only slight note is that this doesn't apple to bridges for pak height conversion factor 2. These have to be double height in order that conversion of existing saved games works and that I can easily enforce the 2 height rule over ways.

Just for reference trains can climb up steep slopes just not that efficiently. Between 1 in 10 and 1 in 20 is about the limit. Once you have rack gears you can go as steep as 1 in 3 or so (in the past rope haulage would have also been used). Given that gradients of 1 in 100 are preferred to me it makes sense to generally have 2 gradients available in simutrans, with penalties (friction) for using the steeper one.

[Ters]

Just for reference trains can climb up steep slopes just not that efficiently. Between 1 in 10 and 1 in 20 is about the limit. Once you have rack gears you can go as steep as 1 in 3 or so (in the past rope haulage would have also been used). Given that gradients of 1 in 100 are preferred to me it makes sense to generally have 2 gradients available in simutrans, with penalties (friction) for using the steeper one.

I was about to suggest rack and/or cable railroads as new way types.

As for the slope gradients, the slopes in Simutrans today look like somewhere between 1 in 2 and 1 in 4, but the landscape is so unrealistic that I see the slopes as symbolic. With half-height, even the half height slopes are steeper than 1 in 10, yet my brains willingness to see slopes as symbolic has diminished.

Only slight note is that this doesn't apple to bridges for pak height conversion factor 2. These have to be double height in order that conversion of existing saved games works and that I can easily enforce the 2 height rule over ways.

That won't work for me, but don't let me stop you.

[isidoro]

I agree with you, Ters.  Even at low speed, it is very unrealistic to have a train climbing a huge mountain straight ahead.  And if trains are not allowed to climb steep slopes, tunnels would have to be used more often, as in RL...

[Spartanis]

I played this patched game, and everything works. I worked out how to build suitable slopes in order to build bridges .. on flat plains, and on the existing slopes (rivers, ridges,, valleys etc)

There are a graphic bug but thats understandable .. Easily fixable (Pavement slope for city roads)

Had a good look at the source files (namely dat files) and it is simple to understand. As you have said:  ImageUp2[direction][snow] is for steep slopes graphics.

Well done mate, you done an excellent job. I propose that this patch be included in the standard simutrans game!

[prissi]

I think, if there are not way graphics for double slope, then such ways will be forbidden to built on double slopes. This will however require bridges and tunnels to be single slope for the moment imho.

[kierongreen]

I think, if there are not way graphics for double slope, then such ways will be forbidden to built on double slopes.

This is indeed the case.

This will however require bridges and tunnels to be single slope for the moment imho.

Slopes within tunnels are only single height at present. Tunnel entrance slopes (where the way is flat of course) are single height for pak height conversion 1, double height for conversion 2. This is just so that graphically they are the right height, and so that old games will load.

For bridges I've made ends on flat ground 2 tiles high for conversion factor 2 as otherwise old saved games would not be able to be loaded.

There are a graphic bug but thats understandable .. Easily fixable (Pavement slope for city roads)

What is the issue with the pavement? (screenshot?). At least on my machine I thought this was working now.

[Spartanis]

As you can see from two red circles. The slope is half-height. Like I said.. its no big issue, its a pakset error,, not your programming

[Spartanis]

I have a question, good sir.


Regarding Lightmap ground tileset. I understand teh first two top row is the standard tileset of ground slopes lightmapping. (half and full height) the next few rows i fail to understand.  im assuming these are slopes to fill the gaps between half and full and flat slopes? 


I noticed in your dat file, you left a "guideline" quote at end of each line.. nw1, ne2 se1 etc etc etc etc...

eg:
Image[69][0]=images/texture-lightmap.3.0   # nw2,ne1,se2   

Am I correct to assume that:
   nw2 = the north west point is at z-level 16
   ne1 = the north east point is at z-level 8
   se2 = the south ease point is at z-level 16
   sw (the point not mentioned) = is a Z-level 0 (flat ground z level)


EDIT:- yup.. im correct. worked it out. God, it'll mess my mind up a bit to work this out lol...

[kierongreen]

Regarding the two problems highlighted with red circles, yes these are purely pakset issues. The double height road on a single slope is because I hadn't drawn single height versions for that particular road. The city pavement works fine I must have just forgotten to include that in the zip...

EDIT:- yup.. im correct. worked it out.

Glad you worked it out

God, it'll mess my mind up a bit to work this out lol...

Imagine what it was like drawing everything in the first place! If you saw some screenshots from development builds in the early stages they were... interesting!

[Spartanis]

Keirongreen, I bet there were!.. but you managed to pull it off.. Meanwhile.. im going to try to create a "table" for your improved pakset as a guideline..

you know.. something like

SW  |  NW  |  NE  |  SE  |  Name  |  Image[n]
-------------------------------------------------------
  0   |   0     |   0   |   0   | Flat ground | 0

etc etc..

it would probably help the pakset maintainers to create ground paks in BLENDER (or their prefered 3cd modeling software) with this guide, and then edit DAT file to suit..

It may take me time, but im sure my effort would be appreciated.. hopefully!

I might even Create a TIKI WIKI Simutrans page specially for this.. assuming that the Admins of Simutrans accepts your patch into the SIMUTRANS mainstream software.. There would be alot of people asking questions!! lol anyways.. I best leave you to your intellectual prowess!

Sparty


EDIT: [size=78%]http://simutrans-germany.com/wiki/wiki/tiki-index.php?page=en_ImprovedGroundDef&no_bl=y[/size] <-- So far.. so good?

[Spartanis]

Is it possoble to rewrite the order of Image[n] to order of slopes?

Like forexample....

Half Height series....

image[0] = flat ground
image[1] = South Slope
image[2] = West Slope
image[3] = North Slope
image[4] = East Slope
image[5] = One Point Corner Slope S
image[6] = One Point Corner Slope W
....

Full Height Series:

image[15] = flat ground
image[16] = South Slope
...
...
...


or would that takes too much of your time in rewriting the codes in MakeObj and Simutrans?

[Fabio]

The problem would be backwards compatibility IMHO.
Many paksets will move to double height, but probably not all (especially legacy paksets) and anyway it won't happen out of the blue, so better for the dat files to be either single or double slope.

EDIT: backwards compatibility was not the problem, but indeed a slow transition is an issue to be considered.

[kierongreen]

Is it possoble to rewrite the order of Image[n] to order of slopes?

Not easily, and for what purpose? The number is linked to the height of each corner, in standard simutrans it is:
sw+2*se+4*ne+8*nw

When double heights are enabled it is:
sw+3*se+9*ne+27*nw

The page you have started on the wiki looks promising, documentation to help others contribute is always welcome

[Spartanis]

Not easily, and for what purpose? The number is linked to the height of each corner, in standard simutrans it is:
sw+2*se+4*ne+8*nw

When double heights are enabled it is:
sw+3*se+9*ne+27*nw

The page you have started on the wiki looks promising, documentation to help others contribute is always welcome

As an Aussie would say "No worries mate!!" lol

About Tiki Wiki: Thanks.. its slowly getting there.. got up to image(10) reference.. so far.. 




EDIT: I will also create and include a .blend file with simple instructions to render the tiles to suit desireable paksize... but i will do that after I done the tiki wiki

[Spartanis]

The problem would be backwards compatibility IMHO.
Many paksets will move to double height, but probably not all (especially legacy paksets) and anyway it won't happen out of the blue, so better for the dat files to be either single or double slope.

You are right. Most likely will happen, is the same way as the EXPERIMENTAL section of Simutrans. Kinda like an Off-Shoot version of Simutrans.

So in effect, one would have three kinds of Simutrans game to play with:

(1) Standard Simutrans
(2) Simu_Experimental
(3) Improved Simutrans (For the lack of a better name)

[Spartanis]

ok.. sorry to pester you but..

Image[40][0]=images/texture-lightmap.0.14   # nw1,ne1,se1,sw1   TODO   0 up 1

What do you mean by  -> 0 up 1 <- ?

[kierongreen]

All corners 1 higher than image number 0 (so you can use the same lightmap just shifted up a few pixels)

[checksumdigit]

This is a great achievement for kierongreen and the simutrans community! I can't wait to start seeing paksets with this addition.


I have 1 thought on this since it is still being developed. Would it be possible to add a double height (quadruple height?) to the terrain/light map, so that you can have very steep slope transitions and more realistic terrain. On such a steep slope, nothing should be constructible (ways), so that shouldn't change the development of new way graphics for the half height slopes.

[Fabio]

And these steep cliffs could necessarily have climate= rocky, so
1) less climate transitions
2) realistic mountains