RCT Discussion / RCT Extended BETA

This was a clever April Fools joke. I'm surprised that people are getting angry at Levis for this. At least Levis was successful since the joke did what it was supposed to do: FOOL PEOPLE. Whether you find it funny or not, it's not Levis' fault that you fell for it... and he even said it on his first post! haha classic...

Yeah, he edited his first post. Besides, one half was playing along with the joke, the other half was questioning already in their post if this was an april fools joke and didn't hope it was. Then there are a couple of members who did fell for it I guess. So not really a successful joke I would say, even more because a lot of members didn't find this funny at all, and wouldn't expect Levis to make a joke about something this important and groundbreaking for the RCT2 community as K0NG pointed out.

In the end I think it hurt Levis' status in this community.

But yeah, let's just all stfu and build rollercoasters !1!

SF

In the end I think it hurt Levis' status in this community.

what status .

April fools isn't about being funny, it's about fooling people and levis did just that...

grow up. levis did a thing, get over it already.

Is this subject over done or is it just me?

YAY!!!!

Count me in on RCTExtended!!!!

Where'd you download it at?!?!

7 YEARS WHAT

YAY!!!!

Count me in on RCTExtended!!!!

Where'd you download it at?!?!

 

Did you actually read the rest of the thread? It was an April fools joke, he patched out the bounds check, but didn't actually extend the array, so it just segfaults. It's been said again and again, these limits are built into the SV6 structure and cannot be removed until we have a new file format.

 

 

Did you actually read the rest of the thread? It was an April fools joke, he patched out the bounds check, but didn't actually extend the array, so it just segfaults. It's been said again and again, these limits are built into the SV6 structure and cannot be removed until we have a new file format.

 

 

thanks for the guy necroposting, had a nice time re-reading this .

About your post:

Every datachunk of the savegame file starts with a header defining how large the chunk will be. As far as I discovered it's possible to expand this chunk and still have the savegame load. So it's actually possible to add space for it. But you would need something which makes rct2 also access this data. This is hardcoded. Altough with the technique I used here it might work if you could find where in the game it stored how long these array's actually should be and access them. As far as I could find out in the past the game assigns a number (I believe it was 2 bytes long or so) to each object so it can be refred to at other places. But not all data is filled, there are still open spots in it I believe. But if you really wanted to make the game access the other objects too you would probably need some clever way of adding a bit somewhere in the datachunk (I believe there are still some unused bits for normal objects) which defines if you should take it from the "normal" array or the "extended" array. You would need to have a scrip running at the background which then have the game access the right part of the data depending on if this bit is set or not.
Theoraticly it's possible, and I tried it the past. But back then my coding knowledge wasn't good enough to pull it off and now my interest isn't high enough to pull it off.

Every datachunk of the savegame file starts with a header defining how large the chunk will be. As far as I discovered it's possible to expand this chunk and still have the savegame load.

 

Yup, you can do this. I use this to make unexportable objects export without changing the checksum - just tack some bytes onto the data chunk so the checksum comes out as it should. The game ignores them everywhere except in the checksum calculation.

 

You could use it to extend the SV6 format in a backward compatible way if you want, but you couldn't use this to extend the object limit. RCT2 uses 1 byte to store indices of loaded objects. That means, that even if you extend the file format to allow loading more objects you would have to resize some of the fields to be able to actually reference the extra objects. As soon as you do that, you'd break compatibility with vanilla.

 

So if you aren't concerned about vanilla, you could just go through and increase the limits right now - there's nothing preventing it now the game is fully implemented. But then you change the file format - it's no longer compatible with vanilla, and when you inevitably want to change it again because such a simple extension would still be very limited, you'll have to keep supporting both old formats.

 

For that reason, I think it's best not to touch the file format at all until ready to completely revamp it. I think it would be better to redesign it once and get it right, than to make incremental improvements and end up with ten slightly different but mutually incompatible file formats.