Simutrans 124.3.1 and nightlies: segfault when drawing terrain [Dumb mistake]

[Nazalassa]

System: Ubuntu Linux 22.04.1, kernel version 6.8.0.
The bug is present in both version 124.3.1 and the latest nightly. Interestingly, it seems to depend on the pakset being used. So far it has only occured with an (incomplete) pakset I am developping. It causes Simutrans to segfault, and seems to manifest itself differently depending on the zoom level.

It is possible that it is an issue with my pakset though. So if the problem turns out to be within the pakset please ignore this report.

How to reproduce
1. Install the pak64.box pakset (provided with this bug report: pak64.box.zip) since it seems not to affect other paksets.
2. Start Simutrans and select the pak64.box pakset.
3. Simutrans should load the pak64.box pakset and display the banner.
4. Close the banner (e.g by clicking outside of it). Simutrans should have opened the "default map". The view should be centered at the north-west corner of the map.
5. Move the view southwards until you get to the island.
6. Simutrans should segfault as the island comes into view. If not, zooming and dezooming and moving around should eventually trigger it. (The latest version of the code, on my computer, seems to crash reliably dezooming twice.)

Note: the pakset's source can be found at https://codeberg.org/nazalassa/pak64.box.

[makie]

version 124.3.2  ? ? ? 

Happens this also if you create a new map?

The  "default map" is not intended to be played with or use it.
The default map does not match your modified pak which leads to mixed data.
Only when you create a new map, your modified pak will be used.

[prissi]

Create_textured_tile fails with a heap overflow already on load with a debug build. Looking at the data, there are way too few lightmap images, there are 80 needed, see pak64. You could leave some empty if you do not want to draw double slopes, but the positions must match. The routines does not check for the available number, they loop until 80 (i.e. over all slope combinations).

[Nazalassa]

Happens this also if you create a new map?

Yes, it does happen.

Create_textured_tile fails with a heap overflow already on load with a debug build. Looking at the data, there are way too few lightmap images, there are 80 needed, see pak64. You could leave some empty if you do not want to draw double slopes, but the positions must match. The routines does not check for the available number, they loop until 80 (i.e. over all slope combinations).

This seems weird, since this is a single-height pak and I did not change anything from the .dat from pak48.bitlit, in which the bug does not happen. (Only the images have changed.)

[prissi]

If you do not use the lightmap just a single type of ground, you can have a single height pak. Otherwise, if you used textured ground, you need the full 80 tiles for all slopes. Single height is not really considered for the modern climate texture system right now.

[Nazalassa]

I think I have expressed myself in an ambiguous way: what I meant by "single height" is that I use slopes, but no double slopes. (sorry about that)

Nevertheless, I tried to define all 80 lightmap tiles, but that still causes a segfault.

[makie]

For "single height" all have to fit together.
Not only lightmap

Obj=ground
Name=SlopeTrans
Obj=ground
Name=Basement
Obj=ground
Name=Borders
Obj=ground
Name=Marker
Obj=ground
Name=Slopes
Obj=ground
Name=LightTexture

[prissi]

Try to define everything but only at the single height positions and missing images defined by - (minus).
If this still crashes, then please update your repo on codeberg and I check again.

[Nazalassa]

It does still crash. I have updated the codeberg repo with the new version.

[Nazalassa]

I have done some more tests and the lightmap seems to be (part of) the problem.

First I blanked it all (except for the flat tile), and there was no assertion failure. Then I tried to add back the tiles, one by one, to see which ones caused the assertion to fail. It seems they all do. I also tried replacing a tile with the equivalent from pak64, and it still failed.

Then I added some pixels back, to see which part of a tile is "safe", and which is not. Surprisingly, pixels in the lower 31 lines (as high as the flat tile) are OK, yet any pixel set outside of this zone makes the assertion fail.

This makes the lightmap as such:

[prissi]

I still see only 16 pictures. You will need 80, or are the other pictures empty?

The program loops over all 80 slopes to blend climate transitions. If a lightmap is missing, it will crash. Empty image is fine, no image => crash.

[Nazalassa]

Yes, replacing everything but the lightmap by their pak64 equivalents does work.

Interestingly, only defining the 16 "single-slope" lightmap images (i.e numbering them 0-15) works as well. So I guess the problem lies in the rest of the images, rather than in the lightmap.

I will next try to replace all those things, one at a time, in the hope to see what was wrong.

-- Upd. --
Turns out it was the climate texture - more precisely, the water texture.
Ugh... I'm so dumb. I just realized I had litterally copied the pak64 water tile texture to have animated water, and forgot that this specific texture only has isometric tiles. So it was only a dumb mistake.

Sorry for having wasted you time.

[prissi]

Well, the climate system is not the easiest. Good that it had been resolved.