Encode Track Type in Track Element

[duncanspumpkin]

Describe the feature

Currently the rendering of a track element is governed by its associated ride "type" but most of the community likes to mix and match across different ride types. This is currently achevied by merging of two different rides. This though is a waste of ride indexs and means for complex building. I propose that instead the track elements rendering is governed by its track type. This would be acheived by using up the free space in the track element to add a new field TrackType (eventually renamed to TrackObjectType if we ever manage to move track drawing into object files).

https://github.com/OpenRCT2/OpenRCT2/blob/develop/src/openrct2/world/TileElement.h#L378

At present this would only use one byte of space but if we ever want to move to objects for tracks we might need to allocate two bytes.

This is obviously only possible on the NSF and also it would be gated behind some cheats. Would require a new track format as well for best compatability.

Feature type

Quality of life

[spacek531]

When track type objects are added, the remove_unused_object command will have to look at all track elements. This isn't a problem, just noting it down.

[spacek531]

Some people have said to me they would love to be able to change the appearance of just the brakes on e.g. giga coaster or looping coaster, to mimic more modern coaster styles like Intamin LSM and Vekoma loopers. Having a simple one byte 'this appears like this ride type' field is elegant, but to me it seems like a waste to create a new track type just to change one element appearance.

[frutiemax]

        TRACK_PAINT_FUNCTION_GETTER paintFunctionGetter = ride->GetRideTypeDescriptor().TrackPaintFunction;
        if (paintFunctionGetter != nullptr)
        {
            TRACK_PAINT_FUNCTION paintFunction = paintFunctionGetter(trackType);
            if (paintFunction != nullptr)
            {
                paintFunction(session, ride, trackSequence, direction, height, trackElement);
            }
        }

If I understand, you think it would be better to first get the trackElement, then based on the new TrackType field in the TrackElement struct (not TrackElementDescriptor), you would decide if you draw a giga track or a corkscrew track for example?

EDIT - I'm not too sure, can you give an example?

[spacek531]

Aren't RTDs available by ride type with GetRideTypeDescriptor(rideType)? If so, then it can just get the paint function there.

[frutiemax]

Right now, it's a TrackType field that got added to the Ride struct. You need an additional RideType variable that would be not the same as the one in the ride struct to do it like this.

[spacek531]

This proposal puts a rideType byte into track elements. So it looks up the RTD for the rideType listed in the piece and paints the piece with that RTD's paint code. By default, the rideType byte is set to the ride's rideType.

[duncanspumpkin]

Yeah in this issue I've called it track type but yeah i realise that there is also a field at present for the track id called track type. All gets a bit confusing in naming.

[duncanspumpkin]

This is now part of the game.