Land below sea level

[kierongreen]

See http://forum.simutrans.com/index.php?topic=9347.0 for previous discussion on this. This patch implements a separate water height grid. The behaviour of the lower land tool is then modified so that if the land lowered is not connected to water it will remain land even below sea level. Using the lower tool to breach dykes created where land below sea level meets the sea is not permitted.

While I have written code for tools to adjust water level and tile transitions, neither are not implemented in this patch as they are not needed for just allowing land below sea level. They maybe supported at a future stage depending on the outcome of discussions about implementation. As there significant code overlap there may be some traces still remaining in the patch of these features, however neither is functional I have removed associated code where ever possible.

At present the tile slope tools are not affected by dyke breaching restrictions. Using them to breach a dyke will result in graphical anomalies - you have been warned.

[Dwachs]

Impressive!

What is the rationale behind the water_hgt array? Should it not be altered if land is raised?

[kierongreen]

It could be if you wanted, however there is no need as the value is irrelevant if below land level. At present it's only set when it needs to be, that is, for land below sea level. Otherwise it defaults to grundwasser.

[Dwachs]

If first terrain is lowered (below sea level) and then raised again, is there the possibility that the lower-land tool is forbidding lowering due to the then stale water height? I could not trigger something like this though.

One seems to be able only to lower one level below sea level, is this intended?

[kierongreen]

Yes there can be stale water heights but these do not cause problems, as they are below current ground level and thus ignored. Yes it is intended to only be able to lower one level below sea level. This is an arbitrary restriction and could be set to anything (within reason). Just make sure that all associated values are changes (there's a few scattered around the patch).

[Dwachs]

Path-finding of ships is broken with this patch. The ribi-bits on water tiles are calculated differently in boden/water.cc, I suspect something going wrong there.

[kierongreen]

Seemed to work when I tested before - will look into this.

Edit:
Ok issue with save/load - both water depth and path finding. Working on it.

[kierongreen]

Solved save/load issue which is what I think you were referring to - or is there another problem?

Patch attached

[Dwachs]

The problem appeared after loading an old game. So it could be related to the issue you found.

[Isaac Eiland-Hall]

Ooooh, is this in the nightlies?

[Dwachs]

no

[IgorEliezer]

owwww

[Isaac Eiland-Hall]

k

[kierongreen]

New version of patch attached. Many, many bug fixes related to rotation, land lowering and more. Also lakes can now be generated on new maps (but not on enlarge map). Transition images are automatically calculated. Dykes are enforced at sea level but not for lakes. With all of this it is a pretty huge patch...

[kierongreen]

Quick update for r5636 (no feature changes).

[kierongreen]

Update and bug fix for r5698. Quick question for anyone who has experience with different platforms, if following code likely to be safe with a different endian processor?

Code Select Expand


...
            uint8 neighbour_flags = 0;

            if(hn_nw == hneu) {
                neighbour_flags|=0x83;
            }
            if(hn_ne == hneu) {
                neighbour_flags|=0xe0;
            }
            if(hn_se == hneu) {
                neighbour_flags|=0x38;
            }
            if(hn_sw == hneu) {
                neighbour_flags|=0x0e;
            }

            for( sint16 i=0 ; i<8 ; i++) {
                const koord neighbour = koord(x,y)+koord::neighbours[i];
                if( ist_in_gittergrenzen(neighbour) && ((neighbour_flags>>i)&1) ) {
...


[Ters]

I think endianness is only an issue when you manipulate the smaller units of a larger (the individual bytes of an int, not the members of a struct) or small units in terms of a larger (cast from char * to int *). Your code doesn't appear to contain any of that. As long as you always treat an int as an int, the sequence of bits will be the same within it logically on all popular platforms, even if that's not true physically.

[kierongreen]

Yes, reading elsewhere seemed to confirm this so I think my worries were unfounded!

[prissi]

However, for reading later, in such cases it would be nicer of those could be or'ed together from constant enums ...

[Ters]

However, for reading later, in such cases it would be nicer of those could be or'ed together from constant enums ...

I was about to agree, but it is perhaps easier to understand the shifting below if you see the actual values rather than symbolic names. In either case, there should be some comments in this piece of code to explain the logic.

[kierongreen]

I'm inclined more to go with comments as defining enums seems likely to take up significant amounts of space while not explaining entirely what's going on. I could of course have used many if statements but this seemed a way to avoid code duplication....

Edit:
Attached version with comments for this bit...

[jk271]

I have download patch 5700... for land below water level. It is nice to see lakes on the map and I am looking forward to see rivers connecting them to the sea.

Unfortunately with this patch shortcut "v" (small v - highlite station coverage) does not work. I have not tested older versions of the patch so i do not know in which version it was introduced.
My OS is 32-bit Linux and pak was pak64.

[kierongreen]

Bug fix attached, looks like at some point wires got crossed with some of the multithreading effort which resulted in the coverage code getting orphaned.

[kierongreen]

Update for 5718 with small bug fix for map colours of land below sea level attached.

[kierongreen]

Update for 5774.

Testing executable binaries can be found at:
http://simutrans-germany.com/files/upload/5774-water-heights-linux.zip
http://simutrans-germany.com/files/upload/5774-water-heights-windows.zip

[IgorEliezer]

Great feature! Now we can build subways for our shore metropolises.

And I discovered I can get rid of shoreline. It's a bit tricky and sometimes it gets glitched.



Now, what if Simutrans had "fairly" plain beaches instead of slopes?

(I believe, after this, we would need a river/water editor tool.)

[kierongreen]

And I discovered I can get rid of shoreline. It's a bit tricky and sometimes it gets glitched.

This is currently a bug. One easy way to get rid of this would be to not allow the slope tool to lower to a tiles water level. This might affect how some people play though.

I could try adding new code to try and detect when you would be creating an illegal transition. However it took quite a long time to get this working for the normal raise/lower terrain tools. I fear that there would still be certain situations when using a mixture of slope and raise/lower terrain tools where you could generate such glitches. Taking into account players using a mixture of the tools might require more complex code.

Now, what if Simutrans had "fairly" plain beaches instead of slopes?

On the one hand it would be possible, with a bit of work to code beaches to be 0 or 1 tile high (or with double heights, 2 tiles). There'd be a few extra transition tiles required (although looking at this screenshot it seems transitions are barely noticeable in pak64 anyway). The main reason I disabled this was that it required 4 textures on some of these tiles when snow was nearly at water level. My texture mapping only supports 3 textures, however when I wrote the double height patch I added support for overlaying addition layers which would make flat beaches possible graphically now.

However prissi made it clear his preference for water to be surrounded by slopes. At sea level I agreed and saw this as representing a need for sea defenses and dykes at least. For lakes to me these slopes seemed to get in the way of certain landscape features (i.e. rivers flowing out of valleys) and resulted in an unattractive terrain.

(I believe, after this, we would need a river/water editor tool.

I have code for a basic 1 tiles water height editor but it is prone to glitches. Still this was useful for tidying the flat edge of lakes and when I restricted it to this appeared to work correctly. It wasn't a priority for me to spend a lot of time coding on it, and multi-tile editors for raising or lowering lake levels until the main part of the code was in the trunk.

[Fabio]

However prissi made it clear his preference for water to be surrounded by slopes. At sea level I agreed and saw this as representing a need for sea defenses and dykes at least.

Flat beaches, in selected parts of the map to be determined somehow, could be SEA - flat BEACH (1-2 tiles, sand only) - beach SLOPE (2x, or better 2*1x).

Those flat beaches would have a specific climate setting (beach, using sand/desert texture like now) and would allow only specific buildings (mostly beach resorts) and forbid harbours (because of their shaols).
They would improve nicely the seashore variety, and the realism of seashore cities...

[wlindley]

Can the FloridaKeys pak be far behind?  See also http://en.wikipedia.org/wiki/Florida_East_Coast_Railway#Key_West_Extension:_Eighth_Wonder_of_the_World

[kierongreen]

Flat beaches, in selected parts of the map to be determined somehow, could be SEA - flat BEACH (1-2 tiles, sand only) - beach SLOPE (2x, or better 2*1x).

Those flat beaches would have a specific climate setting (beach, using sand/desert texture like now) and would allow only specific buildings (mostly beach resorts) and forbid harbours (because of their shaols).
They would improve nicely the seashore variety, and the realism of seashore cities...

It would, having a realistic coastline with sandy bays, esturies, sand bars, headlands and so on would be nice for sure. Writing the code to generate all these features would be a good challenge in itself!

I think my preferred way forward from this point would be to combine the water height and double height patches, then add per tile climates to this combined patch. All of these together would allow what you are talking about (and more)

Combining the two patches is going to be a task in itself I think, let alone adding the per tile climates!

Can the FloridaKeys pak be far behind?

Well, if you want to get drawing...

[Fabio]

You might want to get in touch with jk271 and integrate his valley generation algorithm, too.

Normally, where a large valley reaches the sea you would expect a sandy beach, where a mountain degrades itself to the sea you can expect a headland or a steep slope, yet when you have flatland till the coast you can have cliffs, or gentle slopes.

[kierongreen]

You might want to get in touch with jk271 and integrate his valley generation algorithm, too.

On the whole it's better to keep patches separate. Water heights, double heights and per tile climates all affect similar sections of code, so if they are ever to be incorporated into trunk, or used alongside each other conflicting sections will have to be resolved. It's easier I do that now than leave it to one of the dev team. As far as I know valley generation isn't linked to this section of code significantly.

[Ters]

On the other hand, with multiple features in a single patch, a problem with one of them will prevent all of them from being applied.

[kierongreen]

On the other hand, with multiple features in a single patch, a problem with one of them will prevent all of them from being applied.

I agree, hence my preference in general for separate patches. In this case though there really isn't a choice, unless I wait for each one to be incorporated into trunk before starting on the next. Producing one enhanced landscape testing version, especially if pakset authors get a chance to draw appropriate graphics is going to give a wide test audience too (and I can now make windows binaries to aid this). More testing should mean fewer bugs and a better chance of the code being incorporated into trunk.

[kierongreen]

Flat beaches, in selected parts of the map to be determined somehow, could be SEA - flat BEACH (1-2 tiles, sand only) - beach SLOPE (2x, or better 2*1x).

Those flat beaches would have a specific climate setting (beach, using sand/desert texture like now) and would allow only specific buildings (mostly beach resorts) and forbid harbours (because of their shaols).
They would improve nicely the seashore variety, and the realism of seashore cities...

Normally, where a large valley reaches the sea you would expect a sandy beach, where a mountain degrades itself to the sea you can expect a headland or a steep slope, yet when you have flatland till the coast you can have cliffs, or gentle slopes.

Your wish is my command... :p

At moment these are just desert climate though.