Openrct2: money making glitch involving swamps

[kevinburke]

https://www.youtube.com/watch?v=MpSpAXuqRGo

should prolly be fixed in the C version.

[Gymnasiast]

I put it on the wiki:
https://github.com/OpenRCT2/OpenRCT2/wiki/Found-bugs-and-limitations-in-RCT2

[rwjuk]

Just tested this on the latest build and got a nice segmentation fault due to a null-pointer exception in game_command_remove_scenery(). Fixed that (and got back to the same state as RCT2), now to _actually_ fix whatever's causing this.

My buggy-sense says it has to do with the fact that you end up with a stack of 16 objects on each tile...

EDIT: It's not just swamps - seems that having more than 15 objects under track (doesn't have to be _directly under_ either) will trigger this bug. Null entries end up in gSmallSceneryEntries, seemingly at positions 254 and 255.

[IntelOrca]

Just tested this on the latest build and got a nice segmentation fault due to a null-pointer exception in game_command_remove_scenery()

Oh, how did you reproduce that?

[rwjuk]

Oh, how did you reproduce that?

I did exactly as they showed in the video.

1. Create a stack of 15 or more elements (e.g. swamp, geometric roof)
2. Build a coaster on top of this stack
3. Test it, save the track design with the stack of scenery.
4. Try to insert the track design - segmentation fault in game_command_remove_scenery(). Line 884 dereferences a null pointer and everything goes boom.

[IntelOrca]

Ah okay, I see it. I made an issue, #5037 for removing all cases of checking entry with -1 and changing it to check for NULL instead, as well as ensuring the entries are never set to -1.

[rwjuk]

Just noticed I managed to not say which file I was referring to with my line 884 comment - sorry, long day!

We can get rid of the 'checking for -1' easily enough, but the issue is how does it end up being uninitialised in the first place...

[IntelOrca]

@rwjuk https://github.com/OpenRCT2/OpenRCT2/blob/develop/src/openrct2/object/ObjectManager.cpp#L371

I am not sure why its sometimes 0 though, that is part of the investigation.

[rwjuk]

Indeed! To the debugger! :mag:

Thanks for the pointer to the ObjectManager.

[Chaosmeister]

Hi everyone!
I just checked what the last issue in this project was and tried to solve it while getting to know the code.
I found the cause and a possible fix:

https://github.com/OpenRCT2/OpenRCT2/blob/develop/src/openrct2/ride/track_design.c#L62
This variable seems to store the Z value of the highest scenery element.
When executing window_track_place_get_base_z(), the SceneryZ value was not added to the _trackDesignPlaceZ. this would later lead to negative Z values in track_design_place_scenery() which then leads to erasing the entry_index(later scenery_type) information from the edx variable.

https://github.com/OpenRCT2/OpenRCT2/blob/develop/src/openrct2/ride/track_design.c#L1315
Adding(subtracting - because the z values are negative) the SceneryZ to the _trackDesignPlaceZ value in place_virtual_track() delivers the correct base_z value in window_track_place_get_base_z().

This solves the exception in my build.

Pullrequest #5700

[janisozaur]

Hi, thanks. We have some issues labelled as starter that you may want to check out if you're intersted in doing some more.