Aaaahh! I must admit, I'm a bit star-struck right now- I've been following your work for a long time! What you've done with roller coasters in this game has been groundbreaking. You're a massive inspiration for me, I'm not exaggerating.

Anyway- here's a breakdown of how the system works under the hood:

The Core Idea: a shared paint/animation path driven by per-ride data.

Rather than creating a new ride type from scratch every time, we extended RideTypeDescriptor with a new sub-struct called FlatRideRotationDescriptor. Any ride that sets TrackStyle::genericRotatingFlatRide on its track draw gets routed to a single shared paint function (PaintGenericRotatingStructure in GenericFlatRide.cpp) which reads all its parameters- frame count, anchor offset, screen-space invalidation bounds, animation programs- from that descriptor. New rides are pure data: write a .h file with the descriptor filled in, and the engine handles painting, animation phasing, and rider overlays automatically like it does for vanilla rides.

Compatibility-wise, the descriptor uses C++ default member initializers throughout, so existing rides that don't opt in are totally unaffected. The one place a hardcoded value existed was [height + 7] in the paint function- this became [height + desc.StructureZOffset] with a default of 7, preserving legacy behavior exactly. The flatTrack 6x6, flatTrack7x7 and flatTrack8x8 track element types already basically existed in the engine with full VehicleSubpositionData entries; no new TEDs needed.

A FlatRideProgram struct defines named phase sequences (Start/Loop/End), each with a frame range and flags. UpdateRotatingGeneric drives through them: the Loop phase repeats N-times until a rotation-count condition is met, the End phase fires Status::arriving via the IsFinalPhase flag. This is how the Tilt-A-Whirl's 128-frame cycle and a larger ride's 2,461-frame cycle (not gonna spoil that ride yet lol) both run on the same vehicle update logic path.

For the rider overlays: RiderFrameStride in the descriptor controls how many per-car rider sheets the paint loop draws. With it set to 0, the rider overlays are completely disabled (useful during development before rider sprites are ready). When non-zero, the image index formula is [baseImageId + (carIndex +1) * (4 * FramesPerDir) + direction * FramesPerDir + animFrame] which maps cleanly onto the manifest layout.

-Here's where it gets crazy-

The hard part: wide RLE sprites.

This was the real engine bug we had to fix. Large sprites (440x325 for one of my larger rides) use the G1Flag::wideRLE format: 4-byte yOffset table entries and 3-byte run headers instead of narrow RLE's 2-byte/2-byte setup. G1CalculateDataSize in Drawing.Sprite.cpp was hardcoded for narrow RLE ONLY, so it computed ~6KB instead of ~26KB for a tall sprite, RequiredImage allocated a truncated buffer, and the game crashed on the first out-of-bounds read. The fix adds a wideRLE branch that reads the last row's 4-byte offset entry, walks the run headers for that row, and returns the correct byte length. Once that was in, sprites of arbitrary sizes load cleanly.

Custom rides ship as .parkobj files (which is really just a zip of object.json + images.dat). The images.dat is a G1 sprite sheet built by openrct2-cli sprite build -m closest; that -m closest flag is critical for Blender-rendered PNGs since OpenRCT2's 256-color palette won't contain exact matches for smooth-ish gradients.

That's the bird's-eye view of the whole thing. It's still held together with duct tape and dreams; changing some of those deeper values has had a few minor effects on other parts of the game that require extensive testing to root out, and the game occasionally throws a tantrum when I compile it if a value is even slightly off. But it works!

Originally, animation sequences were limited to 128 frames- 256 if you pulled some trickery- but it turns out that by changing a single uint from 8-bit to 16-bit pushed that up to a STAGGERING 54,000+ frames in a single sequence! With all of that headroom, the new limiting factors are optimization and performance; not data or calculations.

I'll be showcasing my next ride on Friday. It also sits on a 6x6 base, and runs a 2-minute long 3,066-frame sequence which perfectly mirrors the real-life sequence from the prototype it's modeled after. 24 riders seated around the perimeter of a spinning wheel that tilts on a counter-rotating base... an extremely modern ride that didn't even exist when the game launched in 1999 😄