How to detect coast?

[StoneyTT]

For some houses I deactivated foundations and have special graphics for the slope tiles. But now I have to consider that a slope tile could belong to the coast line. According to my observations, nearby_tile_is_water only works when there is no building on the tile. As I am building a house there, nearby_tile_is_water(0,0) always returns 0.
Is there any way to find out if it is a coast tile or not?

[planetmaker]

That's indeed not very easy. You need to check tile height and slope and adjacent tile water class:

The simple case: Assume that all tiles at sea level are sea, shore tiles will report as height 0, no matter their slope. Thus simply check for a slope at height 0:

Code: Select all

(nearby_tile_height(0, 0) == 0) && (nearby_tile_slope != SLOPE_FLAT)

If you want to be more accurate you need to extend that by a check for sea water adjacent to the tile it slopes towards to. Maybe along these lines (direction X towards SW, direction Y towards SE):

Code: Select all

(nearby_tile_height(0, 0) == 0) && (nearby_tile_slope != SLOPE_FLAT) && 
  (  (  (nearby_tile_slope(0, 0) & bitmask(CORNER_W) != 0) && 
        (nearby_water_class(-1, 0) == WATER_CLASS_SEA || nearby_water_class(-1, 1) == WATER_CLASS_SEA || nearby_water_class(0, 1) == WATER_CLASS_SEA)
     ) || (
     (similar conditions for other corners)
     )
  )

See also:
http://newgrf-specs.tt-wiki.net/wiki/NM ... ile_slopes

I solved this on an intermediate accuracy in OpenGFX+ Landscape: http://dev.openttdcoop.org/projects/ogf ... _land.pnml

[StoneyTT]

Ok, thanks. I will try it that way.

[StoneyTT]

Another question: How can I find the correct ground sprites for the coast tiles?
I tried 'GROUNDSPRITE_WATER + some_offset', but only found the correct offsets for some of the tiles by trying out different offsets (slope_to_sprite_offset(nearby_tile_slope(0, 0) does not work).
There must be a way to do it right.

[planetmaker]

Another question: How can I find the correct ground sprites for the coast tiles?
I tried 'GROUNDSPRITE_WATER + some_offset', but only found the correct offsets for some of the tiles by trying out different offsets (slope_to_sprite_offset(nearby_tile_slope(0, 0) does not work).
There must be a way to do it right.

That's complicated. And sadly it's currently impossible to do failsafe due to the nature how shores are defined:

* There are eight shore sprites wich have a fixed sprite number, starting at 4062.
* A base grf then can (and should) define additional 10 shore sprites via replacenew (action5). Those have no fixed sprite number. Their sprite number in principle can vary between different base set versions and of course between different base sets.
* If a NewGRF defines the shore sprites it's different again and sprite numbers can be anything above the base set sprite numbers.

So in summary: you're screwed.
Your approach works often for eight of the shore sprites like you describe. Doing that for those is eight sprites fine. Getting the other shore sprites... is possible but I'd like to discourage it. If you find the proper sprite number (e.g. via the sprite alignment tool if you enabled OpenTTD's newgrf developer tools), it will break badly when the base set's extra NewGRF defines the shores at other sprite offsets than you found them in the version you tested it with.

Actually if anyone has a suggestion as to how this situation can be improved without breaking existing NewGRFs: please let me know

[frosch]

We've exposed the necessary information via Action D.
Not sure yet, how it will look like in NML.

[planetmaker]

In NML you'll have available the variables base_sprite_foundations and base_sprite_shores as the offset to the start of the respective sprites

You'll need NML version r2075 which will be compiled tonight (or a later version).

EDIT: I implemented use of this feature in OpenGFX+ Landscape for the company land to help improve the way company land is displayed at sea shores:

Code: Select all

switch (FEAT_OBJECTS, SELF, company_land_tropic_decide_ground, [
			(...)
			STORE_TEMP( ((nearby_tile_height(0, 0) == 0) && (openttd_version  >= version_openttd(1, 4, 0, 25230)) && ) ?
                                              base_sprite_shores : LOAD_TEMP(var_groundsprite), var_groundsprite),
		]) {
	company_land_fences_switch;
}

Comparison of behaviour with OpenTTD 1.3.0 and trunk:

[StoneyTT]

EDIT: I implemented use of this feature in OpenGFX+ Landscape for the company land to help improve the way company land is displayed at sea shores:

It looks like I don't understand how to use this.

Code: Select all

base_sprite_shores + slope_to_sprite_offset(nearby_tile_slope(0, 0))

does not work for me. Can you give me a short example how to get the right sprite if I already know that it is a shore?
And what about that version part in your code?

[planetmaker]

Code: Select all

base_sprite_shores + slope_to_sprite_offset(nearby_tile_slope(0, 0))

That's exactly the sprite number which works for me. Use it as ground sprite number.

The version check in the above quote just makes sure that I don't try to access that variable in an OpenTTD version which does not yet support it (anything older than r25230. 1.3.0 won't help here).

[StoneyTT]

I use OpenTTD 1.3.0 (the stable release, but latest nightly build seems to be r25227?) with OpenGFX graphics and NML r2079, but with the line mentioned above used as ground sprite it just shows nonsens.

[planetmaker]

Obviously the nightly builds stopped being generated on 5th May - and no-one did tell us. We should again get some builds tonight (thanks to TrueBrain!), so you could test there.

The line will generate nonsense in OpenTTD versions prior to r25230. Hence the version check I employed. Earlier versions simply lack that capability and you need to skip any such expression where the result of that variable is going to be used.

[StoneyTT]

Thanks, I will try it with a new nightly build. But for now, as I need a fallback solution anyway, I'll just use some other sprites for the non-trivial cases.

[planetmaker]

For older OpenTTD versions just use the normal grass ground tile.

The only other viable alternative is to provide your own sprites. But you might not want to do that