r5830 new landscape (binary and source versions)

[kierongreen]

Thanks for adding to trunk

There seems to be some issues relating to loading old saved games that I'll look into later on today but I hope this particular bug was the crashing one I found a few weeks ago (which wasn't related to double heights, rather a pak file).

However one thing to be aware of is that while saved game compatibility when loading a save from versions prior to 112007 should be guaranteed for either single or double height paks there is no compatibility for versions greater or equal to 112007 (either from single to double or vice versa, at least when the double height pak has conversion factor two). This is because height scaling only happens once, when you load an old saved game.

[TurfIt]

Details on the issues?
The only thing I've noticed is the height conversion isn't applied when the demo savegame loads. But manually load it and it's ok.

[kierongreen]

Right - I've confirmed the crashing bug is still the one mentioned here (so nothing to do with patch).

Regarding compatibility (half height pak here means a double height pak with conversion factor 2 - if you use conversion factor one you won't get these problems of course as the visual height step remains the same):
Old single height save loaded with single height pak - OK
Old single height save loaded with half height pak - OK, heights are converted automatically
New single height save loaded with single height pak - OK
New single height save loaded with half height pak - Loads but heights appear to be halved
New half height save loaded with single height pak - Loads but heights appear to be doubled
New half height save loaded with half height pak - OK

Whilst halving/doubling of heights is visual only it will make bridges look odd as there won't appear to be clearance for vehicles to pass underneath. When using half height paks building ways under bridges with height 1 is prohibited.

[TurfIt]

Is this really a problem though?  Simutrans is quite permissive at allowing one to load savegames using a pak other than the one it was saved with. Up to the user to use the same pak if they want identical behaviour...

[kierongreen]

Being permissive is good. The problem comes with paks that are not converted straight away as players could be confused by changes in the landscape when/if it was finally converted.

[prissi]

Just a question. Does it mean that saving an old game again as old version will not work with the double height code? (So far you could still save games as 99.17.) If so, maybe one should also clean up a lot of this compability code then.

IS this also the reason, why you bumped the savegame version? (Usually, this is only done when everything is stable.)

EDIT: Saving the yoshi game under your patch as 99.17 and loading again crashes in the tunnel code.

EDIT2: Lowering a beach tile does not enlarge the beach. This should be standard behaviour with old pak, because these will have no tool to achieve this otherwise.

Also it would be great if someone would summarize the changes on a wiki page, as there are currently 14 paksets ...

[TurfIt]

The savegame version needed bumping so that maps actually using the double height feature save correctly. Otherwise the heights are corrupted on load. Such games using these new features can never be saved correctly with the old save format versions. But, an old game using an old pak should be saveable in the old versions - I get the same crash attempting it so clearly something broke...

[kierongreen]

The main reason saved game version is increased is because each tile now has a climate that needs to be saved. However the conversion code currently needs a version to decide whether or not to convert also. Alternatively we could save a flag to indicate whether the game has been converted.

By enlarging the beach do you mean the beaches generated on new maps with water and sand at the same height? This code is only run for generating new maps (or enlarging existing ones). Currently lowering/raising landscape resets surrounding tiles to default climate for that height.

Saving the yoshi game as 99.17 and reloading - does this work even before this patch? It may be that loading really old saved games is broken now?

[prissi]

If you have a flat beach tile at global water level, lowering the tiles next to it never generates water, even if they touch the water in one corner. Since the beach in new maps is now irregular (looking good actually) this happens frequently. Try enlarging the sea in pak 64 and you sure will come about an unexpected behaviour soon.

About he 99.17: Well it was working half a year ago, so indeed this may have been broken in between.

[kierongreen]

If you can give a link to the saved game I'll investigate further. As to lowering tiles near water - this automatically removes water from nearby tiles to try and prevent graphical glitches. Creating complex beaches as happens at map creation is possible but it really links in with a wider point - should there be default climates for each height, should there be a more complicated distribution, what should happen to climate when tile height is changed?

[TurfIt]

Saving Yoshi as 99.17, and 100.0 is broken pre this patch. - Fatals on load with "simlinemgmt - Broken Savegame". But, saving as 101.0 and up still works at r6529. This patch breaks that.
http://www.physik.tu-berlin.de/~prissi/simutrans/yoshi87-2-102.sve


Climates per tile needs to be decoupled from height levels to get any benefit IMHO (except for backwards compatibility). i.e. changing the height of a tile must not change the climate, otherwise complicated climate distributions become undone. I've been trying to adapt the rain4.m from the wind thread, and climates reverting on changing height was the first thing I noticed. The exact effect on climates from changing height will need to depend on the algorithm used to create the distribution. For rain4, I think it'll need to reapply the whole map on each height change. ughh.

Also, how hard would it be to add a couple climates? Ideally the number/names of climates would be on a per pak basis...

EDIT: updated saveversions that work.

[kierongreen]

Adding extra climates is a fair bit of work because at the moment permission bits are used in a byte. Shouldn't be impossible though. As for names well they can be translated to anything I think. Water and snow are the only fixed ones.

[Ters]

Changing height must to some degree affect climate, as it would look stupid to have two mountain peaks next to eachother, but only one covered with snow. That is unless the meaning of climate has changed, so that a tiles climate just defines at which level and time of year it receives snow and so on, not whether it actually has snow.

[kierongreen]

There are now two types of snow in the game - seasonal snow which rises and falls as the year progresses and overlies a base climate and permanent snow which is a climate in itself.

[Ters]

But there is still a progression of climates related to height. I think that is still needed (in the sense climates are at all), possibly combined with a horizontal variation in climates.

[isidoro]

Climates now form a gradation from cold to hot and there is continuity because they are linked to height.  If made independent of height or at least less dependent, I think that that continuity should be preserved: does it make sense to have tropical just close to snow?

[jamespetts]

There are now two types of snow in the game - seasonal snow which rises and falls as the year progresses and overlies a base climate and permanent snow which is a climate in itself.

So we can now have the wrong type of snow? Excellent!

[IgorEliezer]

does it make sense to have tropical just close to snow?

If snow occurs in a mountainous region next to an equatorial basin, e.g. Andes mountains next to the Amazonian basin. Yes, altitude plays a role.

Also, the probability of two climates to meet each other should be inversely proportional to the difference of temperature.

Desert x Tropical: 5/6
Desert x Mediterranean: 4/6
Desert x Temperate: 3/6
Desert x Tundra: 2/6
Desert x Alpine: 1/6

And/or, the probability of a hotter climate to occur decreases as the altitude goes higher.

[Max-Max]

Without having followed every post in this thread, it sounds like you are trying to implement something like biomes in Simutrans.
Minecraft have an excellent biome implementation. Maybe it's worth having a look to see how they implemented it?

Just a thought 

[IgorEliezer]

Without having followed every post in this thread (...)

^^' o dear, not here. It's everywhere.

[Max-Max]

Well, that was another thread
The idea of biomes has struck me too and it would be awesome if Simutrans was capable of creating maps with biomes that blend into each other nicely.

[kierongreen]

The blending is now taken care of, all that needs to be done is coding initial climate distribution. this might slow map generation down though...

[prissi]

Also please remember, climate are used in pak german to cluster bavarian, middle german and costal buildings together. Thus a "clustersize" for climates similar to forests is needed.

[Dwachs]

Thanks for incorporating this patch! I do not have much time at the moment to follow development.

I noticed that the structure planquadrat_t (simplan.h) now has three bytes wasted to alignment (both 32bit and 64bit builds). These bytes could be used to store water-height and grid-height (which is in karte_t simworld.h).

In addition, the back_bild_nr from grund_t could be moved to this structure as well (it is a property of the map ground - anything not on ground should not display cliffs). This would free an extra byte in grund_t, which could be used to store the extra byte from bridge grounds and water tiles. Then all grund_t have the same size, and the complete ground of a map could be allocated in one big memory block. This could speed-up karte_t::lookup_kartenboden, as the indirection to plan->get_kartenboden->check plan.data can be omitted.

Comments?

[prissi]

I would very much like to to this. But the different grounds treat stuff differently, especially water, fundaments and tunnels/bridgeheads? I think there is some more code magic needed until this works out. (It might indeed speed up lokkup considereably.)

[kierongreen]

Sounds good in theory! If there was spare memory it could maybe be used to do more caching of climate transitions. Or if people were wanting more climates that would need more memory also.

[kierongreen]

Here's a small patch to address a few issues with bridges reported here (I also attached patch to that thread).

[hApo]

When will this patch be included into Simutrans?

[Markohs]

It's already in. nightly builds have it, and the next release will havr it too