More height levels (in trunk since r27010)

[Zuu]

(1) Am I right, that _settings_newgame stores the settings as they are currently configured in the menus, whereas _settings_game stores the settings used for the currently active game?

Yes

(2) In detail, does the intro game run using _settings_game?

I've not read the code, but to my understanding the intro game is nothing special except for that you can't do anything with it in the main menu. So I would say it uses _settings_game.

(3) What happens when I alter a settings in-game? Do I edit _settings_newgame or _settings_game in that situation, and if the former is true, how does this affect _settings_game?

When you alter advanced settings in-game your changes will only affect the save game, not the new-game settings.

(4) Is it possible to allow changes of a setting only from the main game menu, not from inside the scenario editor or the game?

I don't know the answer of this question. Well possible yes, but how hard and how much do you need to hack, I don't know.

[PhilSophus]

(2) In detail, does the intro game run using _settings_game?

I've not read the code, but to my understanding the intro game is nothing special except for that you can't do anything with it in the main menu. So I would say it uses _settings_game.

Yes, opntitle.dat is just a normal savegame that is loaded for the intro screen (you can see this if you enable debugging output for saveload code). A special game mode (GM_MENU) prevents interaction of the player with this game.

(4) Is it possible to allow changes of a setting only from the main game menu, not from inside the scenario editor or the game?

I don't know the answer of this question. Well possible yes, but how hard and how much do you need to hack, I don't know.

From settings.cpp:822:
#define NG SGF_NEWGAME_ONLY
I didn't look deeper into the code, but from the naming I assume that setting NG as a flag on the setting should allow it only for new games.

[ic111]

Thanks for the hints!

Nevertheless one further question:

Regarding savegames I basically have the problem that I introduce an array that exists and especially should be saved in the savegame if and only if my new configuration variable allow_more_heightlevels is true.

Ok, implementing this in map.cpp / AllocateMap is fairly easy. But what is the best way to save such an array in a savegame?

Can I load an array without knowing its size (or even wether it's != null) before? So, can I do something like _map_heightdata = <Load array if it's there, otherwise construct array of size 0 or something similar>?

I don't think I need to take the information from the settings into account here, since it must always fit to the state of the array (array must be there if and only if allow_more_heightlevels is true).

I have seen an example for something similar in stations_cmd.cpp, but I'm not yet sure wether this fits to my problem.

[ic111]

Hello,

I have finished the first version of my more heightlevels patch.

What did I do?
=========
I introduced a new configuration setting construction.allow_more_heightlevels. I furthermore added a new array _map_heightdata, which saves the heightlevel information when the patch is active. If the patch is not active, this array is just null, so it does not waste any space in this case. This especially applies to savegames. If the patch is active, the 4 bits in the old tile_height field of _m are ignored.

What works so far?
============
Terraforming mountains higher than height 16.

Saving and loading games (the patch being turned on or not) works. After loading, the setting saved in the game will be used. If the game was saved before the patch was introduced, it will be loaded with the patch being turned off.

Turning on and off the patch works. This is especially possible in game, so old games can be used with the patch being turned on. The patch even can be turned off again, however this is only possible if no mountain higher than height 15 exists (i.e. if the information can be saved in the old 4 bit datastructure).

What still needs to be done / what I want to implement in further versions?
==============================================
(1) The minimap currently displays just the color for maximal height for any fields higher than height 15.

(2) Terraforming works. However, I suspect that some array overflows will be possible if you try to terraform too big mountains in one click. Furthermore, I suspect that the current code is not that efficient. Maybe, using advanced data structures like HashSets would be appropriate instead of linear searches by coordinate in arrays.

(3) I didn't look at the painting code. As you can see on the screenshot, it works without glitches, but I didn't try it with heights > 20 so far. The argument concerning efficiency may apply here as well. Maybe one has to expect glitches when using bigger heights than height 20, I didn't test this so far.

(4) Looking at CmdLevelland in terraform_cmd.cpp, I don't really understand the code there. You get an unsigned int, the docs say it can have the value -1. Then you add it to another unsigned int, and finally you test for already being at sea level. So maybe here something has to be done. However, I used the levelling tool to generate the sample game I attach to this post.

(5) I did not touch map generation so far. Maybe someone familiar with the algorithms could do something senseful with the existent algorithms?

(6) Furthermore, I would very much like generated maps with really huge valleys, like e.g. the Inntal and its side valleys in the austrian mountains. Unfortunately, the current generators don't support this.

(7) Much easier than (6) will be generating maps with height levels much higher than just 16 from height maps.

(8) I didn't test or touch airplanes.

(9) One might make the sea level be a flexible setting, e.g. having a sea level at height 128. Things like allowing bridges only in flat water or making them really expensive in deep water will be possible.

Finally, a screenshot:

A screenshot of a test game at height level 17.

ScreenshotOfGameWithHeight17.png (66.9 KiB) Viewed 4771 times

[Terkhen]

I'll start testing it soon. Here is a compiled binary for win32:

PS: Why is the patch created against the src folder?

[Thief^]

(2) Terraforming works. However, I suspect that some array overflows will be possible if you try to terraform too big mountains in one click. Furthermore, I suspect that the current code is not that efficient. Maybe, using advanced data structures like HashSets would be appropriate instead of linear searches by coordinate in arrays.

---------------------------
Microsoft Visual C++ Runtime Library
---------------------------
Assertion failed!

Program: ...sktop\Moreheightlevels-14667-win32\openttd.exe
File: C:/msys/1.0/home/terkhen/alturas.../terraf...cmd.cpp
Line: 119

Expression: ts->tile_table_count < TERRAFORMER_TILE_TABLE_SIZE

For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts

(Press Retry to debug the application - JIT must be enabled)
---------------------------
Abort Retry Ignore
---------------------------



So yes.

[CommanderZ]

Sounds good.

I did not touch map generation so far. Maybe someone familiar with the algorithms could do something senseful with the existent algorithms?

I will look at this tomorrow, I'm quite familiar with map gen.

(6) Furthermore, I would very much like generated maps with really huge valleys, like e.g. the Inntal and its side valleys in the austrian mountains. Unfortunately, the current generators don't support this.

I was working on a feature that would allow this (see the first patch in my sig), but it got stuck because my second mapch got stuck.

[Terkhen]

I've been looking at the code, and I managed to generate 32 levels heightmaps (it's just a different conversion rate from heightmap height to scenario height). I've attached the diff file and two scenarios created with it. One is from a random heightmap with a big mesa, and the other is my Andalusia map. It's incredible how detailed the mountains look now

Later I will test some of the possible bugs mentioned. Your patch is looking good, ic111

[ic111]

I'll start testing it soon. Here is a compiled binary for win32:

PS: Why is the patch created against the src folder?

Well, because http://wiki.openttd.org/wiki/index.php/ ... a_patch.3F tells me to do the following:

"In Linux, use the command "svn diff > mypatch.diff" from the source directory to create a diff file."

Maybe I got that wrong, so against what should I create a patch usually?

[ic111]

(2) Terraforming works. However, I suspect that some array overflows will be possible if you try to terraform too big mountains in one click. Furthermore, I suspect that the current code is not that efficient. Maybe, using advanced data structures like HashSets would be appropriate instead of linear searches by coordinate in arrays.

So yes.

Ok, I will take a look on this now / this weekend.

What do you think, what is the best strategy to organize the diffs now? Should I just make another diff as soon as I solved the next problem and post it as version 2? Or should I do something else?

And what will patch do when I try to apply e.g. the heightmap-patch posted afterwards? After all, this patch contains my changes as well, so I would apply the patch to a source directory already containing some, but not all changes in the patch. Would this cause a problem?

[Yexo]

I'll start testing it soon. Here is a compiled binary for win32:

PS: Why is the patch created against the src folder?

Well, because http://wiki.openttd.org/wiki/index.php/ ... a_patch.3F tells me to do the following:

"In Linux, use the command "svn diff > mypatch.diff" from the source directory to create a diff file."

Maybe I got that wrong, so against what should I create a patch usually?

Most people here who use svn create patches by running svn diff one level higher then the src directory.

What do you think, what is the best strategy to organize the diffs now? Should I just make another diff as soon as I solved the next problem and post it as version 2? Or should I do something else?

Just create a new diff and post it here.

And what will patch do when I try to apply e.g. the heightmap-patch posted afterwards? After all, this patch contains my changes as well, so I would apply the patch to a source directory already containing some, but not all changes in the patch. Would this cause a problem?

It'll complain that some changesets are already here. You can
1) Remove your previous patch from the source dir (by running 'svn revert -R .' for example) and then apply the new patch.
2) Just try to patch the new patch in and manually say no to reapplying/reverting already applied chunks.

[Terkhen]

If you need it I can post just the modified file (heightmap.cpp).

Anyways, I've been doing some testing:

(2) Terraforming works. However, I suspect that some array overflows will be possible if you try to terraform too big mountains in one click. Furthermore, I suspect that the current code is not that efficient. Maybe, using advanced data structures like HashSets would be appropriate instead of linear searches by coordinate in arrays.

Confirmed. At height 28, any terraforming that raises more than one tile gives the same error Thief posted.

(3) I didn't look at the painting code. As you can see on the screenshot, it works without glitches, but I didn't try it with heights > 20 so far. The argument concerning efficiency may apply here as well. Maybe one has to expect glitches when using bigger heights than height 20, I didn't test this so far.

Confirmed. Just select any tool that "draws" anything in the ground (I used demolish) and pass it through anything to see them. The same happens when a vehicle gets behind a building or a tree. Viewports that are pointing to 28 height look glitched too.

(8) I didn't test or touch airplanes.

Airplanes are drawn "into the mountain" but can be seen. Airplanes landing in a mountain airport go "up" and airplanes taking of go "down". I wanted to do some tests raising the flying height but I wasn't able to find it in the source.

(9) One might make the sea level be a flexible setting, e.g. having a sea level at height 128. Things like allowing bridges only in flat water or making them really expensive in deep water will be possible.

This old patch seems to do just that:

http://www.tt-forums.net/viewtopic.php? ... 76&start=0

[DonRazzi]

If we're talking about sea levels, I believe this three sea levels should be sufficiant:

1. Binland: This level should be the same like rivers or canals. It represents a level which isn't deep enough for large vessels.

2. Brackish Water: This is a coastal zone where both binland- and oversea-vessels have access to.

3. Open Sea: This level only should be used by vessels which are strong enough to operate on the ocean.

The lower sealevels should be able to operate harbours.

Is it possible to have such a feature in the game?

Don

[michael blunck]

If we're talking about sea levels, I believe this three sea levels should be sufficiant:

1. Binland: This level should be the same like rivers or canals. It represents a level which isn't deep enough for large vessels.

2. Brackish Water: This is a coastal zone where both binland- and oversea-vessels have access to.

3. Open Sea: This level only should be used by vessels which are strong enough to operate on the ocean.

The lower sealevels should be able to operate harbours.

Well, I think it´s too early to talk about sea-levels in detail. So this should only be regarded as a note.

Nevertheless, I think two different sea levels would not only be sufficient for an improved ship handling, but even better for gameplay than having three.

Having only two levels would require the player to use either sea-going vessels or inland vessels for a specified task, but having three zones as above, sea-going vessels would be used for any task, simply because of their larger capacity.

Travelling restrictions for ships could be implemented like it has been done for trains with the freighttrains switch set to on, i.e. a sea-going vessel wouldn´t be stucked in shallow water but would be reduced to a minimum speed of 1 km/h. In this way, every point at the coast could be reached if necessary. O/c, it would be better to have deeper water for harbours, as is the case in reality.

In addition, the newgrf specs already have support for two water levels (canals/rivers and open sea), but not for three.

Apropos: Speaking of "reality", the Panama and Suez canals allow for ocean-going vessels ...

regards
Michael

[CommanderZ]

Here is my terrain generator addon for this patch. The mountainous terrains now look really monumental

It is really quick and dirty work. It doesn't respect the patch setting right now, so you need the patch to be ON while making a new map.

There is this thing in the tgp.cpp just under includes:

#define MAX_TGEN_HEIGHT 31
//(_settings_game.construction.allow_more_heightlevels ? 31 : 15)

As you can see, you can set the max height there and it will affect whole map generation process. I tried to make a macro to decide the max height from the patch setting (the commented line), but it always behaved as if the patch was off.

I will look more into it later - the smoothenss values need to be rebalanced too, because the smoothness behaves as if the terrain was still only 16 levels high (so the slopes are generally 2* steeper).

I have attached one creene from a mountainous map with smoothness very smooth.

Do you see the ugly coastline? The Better Map Borders© patch is desperately needed

[DonRazzi]

Nevertheless, I think two different sea levels would not only be sufficient for an improved ship handling, but even better for gameplay than having three.

Having only two levels would require the player to use either sea-going vessels or inland vessels for a specified task, but having three zones as above, sea-going vessels would be used for any task, simply because of their larger capacity.

This is what I had in my mind. But with only having two levels there would be no need to reload between inland vessels and sea-going vessels. For a route from let's say Cologne to London a player would use only inland vessels which do a direct job.

The idea is to have a level which is deep enough for sea-going vessels, but prevent inland vessels from going overseas.

Travelling restrictions for ships could be implemented like it has been done for trains with the freighttrains switch set to on, i.e. a sea-going vessel wouldn´t be stucked in shallow water but would be reduced to a minimum speed of 1 km/h. In this way, every point at the coast could be reached if necessary. O/c, it would be better to have deeper water for harbours, as is the case in reality.

Hehe. As you mentioned you're sailing: Have you ever get stuck in the wadden sea and fallen dry? Reminds me much of that...

In addition, the newgrf specs already have support for two water levels (canals/rivers and open sea), but not for three.

I think this would be sufficient, as the mid-level is nothing more than a mix of both levels.

Apropos: Speaking of "reality", the Panama and Suez canals allow for ocean-going vessels ...

Yes, but these big canals only have locks at the entrances, AFAIK. All the way is on the same level. For such canals digging is a good way for simulation.

Don

[michael blunck]

[...] with only having two levels there would be no need to reload between inland vessels and sea-going vessels. For a route from let's say Cologne to London a player would use only inland vessels which do a direct job.

Not necissarily. As already mentioned, both types of ships (inland vessel, sea-going vessel) could be made to use different max speeds with regards to canals/rivers resp. ocean.

In this way, it wouldn´t be attractive to use sea-going vessels in rivers/canals (or near coast if the water is shallow), or to use onland vessels or coasters on oceans.

Indeed, how to use ships best would depend on the special topography of the map and the depth of water, incl transshipping.

The idea is to have a level which is deep enough for sea-going vessels, but prevent inland vessels from going overseas.

Yes, I understand, but IMO, this could be achieved even better by setting properties 14 and 15 to a certain speed fraction. This would allow both types of ships to operate in "foreign regions", but only with a certain handicap. It would allow sea-going vessels to pass canals (Panama, Suez, Corinth, ..), inland vessels to travel the coasts, and coasters to travel the ocean, but there would be no use to do so on a regular base.

In addition, it might be difficult to introduce three different depths, especially with regards to their graphical representation.

Hehe. As you mentioned you're sailing: Have you ever get stuck in the wadden sea and fallen dry? Reminds me much of that...

Only deliberately. But that´s always fun.

[Suez, Panama canals]
Yes, but these big canals only have locks at the entrances, AFAIK. All the way is on the same level. For such canals digging is a good way for simulation.

Well, the Suez canal doesn´t have any locks, but the Panama canal has 46 of them. We recently had the pleasure to visit them in our "guess the train" game", see also http://www.canalmuseum.com/canalphotos/ ... hotos.html, very interesting photos!

regards
Michael

[SirXavius]

I'm really amazed at how well this is coming along. altho i can't use the patch, i see the resulting screenshots. Hopefully CommanderZ will get that map generator working to perfection....

The next big step are the planes. Should they go around if the mountain is too high? Or will the path routines need to be adjusted? Perhaps the planes just disappear "above the mountains" like vehicles do within tunnels...

Keep up your hard work. Some of us are interested in your progress!

[Zuu]

The next big step are the planes. Should they go around if the mountain is too high? Or will the path routines need to be adjusted? Perhaps the planes just disappear "above the mountains" like vehicles do within tunnels...

For that to work, airports must be forbidden over a certain hight level. Which is actually has a counter part in reality, as airplanes can't take off if the air pressure is to low. To theoretically take of they need to go in a speed that requires a very long runway, and even if you manage to build this runway in mountainous terrain, you might exceed the allowed wheel speed of the airplane.

And for gameplay, that would be an interesting limit if airports would be forbidden over a certain hight level.

[michael blunck]

[...] And for gameplay, that would be an interesting limit if airports would be forbidden over a certain hight level.

One more clue that would support my old thesis that orientating to reality would be the way to go, rather than sticking to some of the more childish and toy-like attitudes of the original game.

regards
Michael