News:

The Forum Rules and Guidelines
Our forum has Rules and Guidelines. Please, be kind and read them ;).

r5773 Double Heights

Started by kierongreen, June 13, 2012, 01:13:24 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

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! :o
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 :D
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

QuoteWhen 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

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

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

rainer

#10
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

#12
 :o


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

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

kierongreen

QuotePerhaps 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

Quote from: kierongreen on June 30, 2012, 03:34:32 PM
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.

Quote from: kierongreen on June 30, 2012, 03:34:32 PM
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

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

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

QuoteThere 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

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


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

QuoteEDIT:- yup.. im correct. worked it out.
Glad you worked it out :)

QuoteGod, 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

#25
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

#27
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

QuoteIs 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

#29
Quote from: kierongreen on July 04, 2012, 11:50:47 AM
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

Quote from: Fabio on July 04, 2012, 11:16:14 AM
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

greenling

Thats it a cool idea what here be make!
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!

kierongreen

Any more than 2 different heights will require a different system for rendering terrain as the possible number of tiles becomes very large... 1 height gradient needs 15, 2 needs 80, 3 would need 255, 4 would need 624. The only practical way to go for that is a full 3d renderer.

Fabio

Is this a problem of climates (thus solvable with stricter rules as suggested), or light maps? 255 is a big number, but it shouldn't impact too much on memory usage.

kierongreen

Lightmaps. Drawing 255 lightmaps is quite a task! Of course there would also be an increase in textured tiles required. Overall I don't think it's worthwhile myself.

prissi

About very steep slopes: With double slopes, artifical slopes in the worst case are not possible on all tiles, since between top and bottom more than 2 level of height difference may be needed. Not sure, how to deal with this; maybe this is just a further challenge of it.

And as kieron said. Probably then just rendiring the ground is better, if you go to freeform slopes. And not only ground: all ways are affected too.

Fabio

About restricted artificial slopes: I don't see it as a problem, possibly as a feature. After all you can't just build any containment wall in real life.

kierongreen

This patch handles artificial slopes with up to 4 height difference by combining different images.

prissi

Sorry, I really have to delve deeper into the code then.

Spartanis

Regarding more slopes than HH and FH. Sure. be nice to have realistic "cliffs" but i agree, it is utterly pointless and time consuming.

Best way to acheive the Realistic Mountain look with sheer drop cliff.. is create a pak out of it. As my Pakset(in the works) is currently implementing this idea.

I made it as a CUR building, but instead of randomizing curiosity, I just build it at various places. For example. Cur_1_CliffFace would have 4 views of a str8 cliff face two tiles high. Cur_1_CliffCnr would have corner cliffs. Using this idea would allow you to build a natural realistic landscape, save the map for anyone to play with. (so long they have the appropriate pakset)

Of course, Building the SAVE.MAP may be time consuming, but least you got a nice landscape to play with!

Spartanis

#44
Quote from: kierongreen on July 04, 2012, 02:11:29 PM
All corners 1 higher than image number 0 (so you can use the same lightmap just shifted up a few pixels)

Oh, ok.. correct me if Im wrong. That line with "TODO" uses the same lightmap image, rather than us creating another flat but 1 point higher than normal?




EDIT:-


Oh hang on, you mean saying so, notifying others to USE the SAME image as used before...


eg: TODO 0 up 1 = Use the same image used in image[0]



EDITx2:=

AHHHH.. I get it now.. I had to "clean up" your dat file and saw that you used  0.14 (flat ground) as a temp image instead of a proper image (of which you havent created yet)


I shoulda seen that coming.. surely.. lol so sorry mate..  :)


EDITx3:=


Ok.. completed the TIKI WIKI page regarding Lightmapping.. *phew*.. lotta work, but i learnt alot about it tho.. should be EASY to create a Blend file now :)


Anyone is welcome to add/modify the page, so long it kept to that. The idea is to keep it simple but easy to understand....(hopefully)

kierongreen

The images with TODO actually aren't used in game :) - hence why they remained as TODO!

Spartanis

ohhh.. ok ok.. but still.. i create the appropiate image anyways..  so that i dont need to recreate the set again when ya actually done them. I'm nearly done with the pak64 lightmap (smooth slope, not triangulated).. its been fun i must say! :)

Spartanis

Kierogreen

If you be so kindly, check the wiki page if the data is correct? 

If you dont have time, thats ok :)

Sparty

Spartanis

Reason being:





Following the order of the MENU tiles... this is the result. I think i might have mis-read your dat file somewhere    O.o


While everything else, the landscape that is, is perfect, no slope errors there....

kierongreen

What slope numbers did you use for menu tile? You will need following entries in menuconf.tab for slopes:

# slope tools
toolbar[1][0]=general_tool[2]
toolbar[1][1]=general_tool[3]
toolbar[1][2]=general_tool[4],10,,36 #southslope
toolbar[1][3]=general_tool[4],11,,4 #northslope
toolbar[1][4]=general_tool[4],12,,12 #westslope
toolbar[1][5]=general_tool[4],13,,28 #eastslope
toolbar[1][6]=general_tool[4],14,,82 #all up slope
toolbar[1][7]=general_tool[4],15,,83 #all down slope
toolbar[1][8]=general_tool[5]

These are for half slope varients, for both types of slope you will need something like:
# slope tools
toolbar[1][0]=general_tool[2]
toolbar[1][1]=general_tool[3]
toolbar[1][2]=general_tool[4],10,,36 #southslope
toolbar[1][3]=general_tool[4],11,,4 #northslope
toolbar[1][4]=general_tool[4],12,,12 #westslope
toolbar[1][5]=general_tool[4],13,,28 #eastslope
toolbar[1][6]=general_tool[4],10,,72 #southslope*2
toolbar[1][7]=general_tool[4],11,,8 #northslope*2
toolbar[1][8]=general_tool[4],12,,24 #westslope*2
toolbar[1][9]=general_tool[4],13,,56 #eastslope*2
toolbar[1][10]=general_tool[4],14,,82 #all up slope
toolbar[1][11]=general_tool[4],15,,83 #all down slope
toolbar[1][12]=general_tool[5]

(but you will probable want to draw new icons also)

AP

Just wanted to post to say how awesome it is that we're able to incorporate this feature. Good job!!

Spartanis

ahh.. one need to update menuconfig as well!.. my god! lol.. *toodles off to have more fun* :)

jamespetts

I have to say, this looks very promising, and should substantially enhance the Simutrans experience.
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.