Looking for information on the ride header structure about rct2ridegenerator HOT 19 CLOSED

Me and X123M3-256 found out through excessive trial and error. I'm sure if there was more information on it you guys at OpenRCT2 would have found it first. :)

from rct2ridegenerator.

Oh well thanks anyway. Your information did prove to be quite useful. So far this is what we have https://github.com/duncanspumpkin/OpenRCT2/blob/peep/src/ride/ride.h#L49-L126 I know there are a bunch you have labelled that I haven't labelled that will be sorted out eventually.

from rct2ridegenerator.

Glad to be of help. When I find the time I'll upload my program that I was working on which went more in-depth on non-rollercoaster ride types. It should help you guys figure out a few more values and flags.

from rct2ridegenerator.

Seems trigger-death has already replied, but yes, it was determined almost entirely by trial and error, observing the effect of altering various bytes in game.

My initial implementation was based off of Buggy's Ridemaker, but I think I have everything it supports now so I wouldn't recommend digging through that code -it's a bit of a mess. I also used the information at http://tid.rctspace.com/, which you are probably aware of.

I've been unable to spot a pattern in some of the remaining bytes, and I have enough information now to generate ride files from scratch, which was my original goal, so I'm not actively pursuing any further reverse-engineering of the files, but I think trigger-death has some flags that I didn't include.

Also, if you haven't seen it, I have amalgamated (almost) all the information that I have here. The only think not included is the track piece flags, there's quite a lot. Trigger-death has determined almost all of them, and they can be found in my source code if you want them.

from rct2ridegenerator.

Thanks that will be very useful.

I can fill in some of those blanks in the car structure bytes 24 - 79 are dword offsets to different images for the ride each dword represents a different type of track piece. Byte 80 - 83 is the total number of images. All of these fields are populated by the object dat loader and can be left as blank. Bytes 97-100 are a dword pointing to the position peeps sit this is again populated by the loader and is blank in the .dat file.

There are probably a bunch of other fields I have information on but thats all I can remember.

from rct2ridegenerator.

Thanks, I'll add that information to the page. Do you happen to know anything about the unknown structures following the string tables? I remember reading somewhere that it has to do with peeps, and the number of structures does appear to correlate with the number of peep sprites, but I can't observe the effect of altering these values because the scenario editor keeps crashing.

from rct2ridegenerator.

Its string tables followed by an unknown chunk (3 bytes wide, variable size), followed by the peep loading positions (4 lots of variable size positions for the 4 vehicle types), followed by the image directory. Its covered in the rctspace page I think.

from rct2ridegenerator.

Is it known what the peep loading positions actually do in game?

from rct2ridegenerator.

Yup its the positions that the peeps have to go to be on the ride. At least its where they walk to for example on the enterprise ride.

from rct2ridegenerator.

Oh, that makes sense. I'd thought they might be some sort of sprite offset, but those are already accounted for.

from rct2ridegenerator.

Alright, I uploaded my source code here. Don't take the names or descriptions of flags and variables at face value. Some of them are only guesses based on changed behavior but most of them are pretty accurate. And I have to say that it's an honor to be of help to OpenRCT2. :)

from rct2ridegenerator.

Thanks again.

from rct2ridegenerator.

Oh and just to add to your information offset 0-1 is the ride name populated by the loader. 2-3 is the ride description populated by the loader. 4-7 is the offset to the images populated by the loader. Your also missing bytes 430-433 an offset to an unknown structure again populated by the loader (This is the unknown structure after the string table). I think thats it for my known offsets.

from rct2ridegenerator.

How can the name and description fit into 4 bytes?

from rct2ridegenerator.

The way all strings work in rct2 is they are placed in a big array. They are then only referenced to by their index. So in theory there is an maximum number of strings of 65535.

When the string table of a ride is loaded they are added at the next available string array slot. The index of this slot is then placed in the ride header. Thus only taking up 4 bytes instead of being pointers taking up 8 bytes.

from rct2ridegenerator.

Oh, that's interesting. So is the ride object header copied verbatim into RAM?

from rct2ridegenerator.

Yup and then all of the missing fields are filled in. I could also probably get you a list of what each of the image offset variables in the vehicle header are referenced to but as already mentioned they are filled in by the loader and should be left blank. For example byte 32-35 is the offset to Incline 25 sprites, 36-39 is Incline 60, then verticle, then unknown, then banked, ... I'm not sure if that matches the format for anything else. I think it matches bytes 12 and 13 in the vehicle structure.

from rct2ridegenerator.

OK, that's interesting. I have the unknown sprites now - after flat banking is 40 frames for inline twists, if supported, and just before restraint animations is 80 frames for corkscrews, if supported. These haven't been added into my source code yet.

Also, the incline sprites are at 22.2 degrees for gentle slopes and 58.5 degrees for steep slopes, so not quite 25 and 60.

from rct2ridegenerator.

cool didn't know they would be not quite 25 and 60 but it makes it easy for description reasons so I don't think I will change their names.

from rct2ridegenerator.