It's a lot of code changes for inverting the vehicle->bank_rotation... I think you could create a function inside the vehicle class to get the transformed bank rotation if it is inverted and use it. You could remove all the uint8_t imageBankRotation variables in the function parameters I believe.

I figured there was a less nasty solution but couldn't think of it at the time - this is definitely a better way to do it.

I've tested it with the corkscrew coaster and I like it. You should implement this with all the roller coasters with continuous mode enabled and get it merged as is before adding new features.

Regarding which coaster types to add the new modes to, my initial thought was to add it to types that
-A) have run or could plausibly run reversed cars/trains IRL
-B) look visually distinct in game when reversed.

Traditional, sit-down style coasters work well with this. I could add it to the classic variants of the rides I've already added. In terms of access without cheats, I think adding it to all coaster types would make it a bit bloated. Additionally, there are a few types it doesn't work well for:
- Giga Coaster : Cable lift only works in continuous circuit modes.
- Spiral Coaster : The spiral lift doesn't have corresponding backwards sprites, so the trains would appear at a flat pitch.
- Suspended / Suspended Mini / Bobsled / Wooden Wild Mouse : The cars swing the wrong way when running in reverse.

One coaster that could benefit from the new modes is the Multidim, as flipping the trains would open up more design space for it.

It's also pretty common for Six Flags parks to run their batman B&M roller coasters in reversed mode.

I think this can be all a bit simplified by passing the mode and not storing a new field, having that field per vehicle would make sense if only some vehicles are reversed but if I get this right its always all or none.

I implemented it this way with reversing individual cars in mind, I'm just not sure how that would be designed/implemented yet. Could be a toggle somewhere in the ride settings to flip either the last car in the train, or any cars of the player's choosing. Depending on the design of the cars it could cause visual weirdness with the positions of the wheel bogies (since most coaster cars are trailered, rather than having four wheel bogies). Because of that, the additional flexibility might be something that is better left to cheats or plugins.

As I mentioned before, this implementation also makes it possible to simplify the ride types that currently support flipping cars, and allow other train types to use turntables/etc. I've added this for testing to the log flume turntable, and it seems to work well (at least for single-car trains). If only the whole-ride-reversing modes are wanted, though, the implementation can certainly be changed.

I think this can be all a bit simplified by passing the mode and not storing a new field, having that field per vehicle would make sense if only some vehicles are reversed but if I get this right its always all or none.

I implemented it this way with reversing individual cars in mind, I'm just not sure how that would be designed/implemented yet. Could be a toggle somewhere in the ride settings to flip either the last car in the train, or any cars of the player's choosing. Depending on the design of the cars it could cause visual weirdness with the positions of the wheel bogies (since most coaster cars are trailered, rather than having four wheel bogies). Because of that, the additional flexibility might be something that is better left to cheats or plugins.

As I mentioned before, this implementation also makes it possible to simplify the ride types that currently support flipping cars, and allow other train types to use turntables/etc. I've added this for testing to the log flume turntable, and it seems to work well (at least for single-car trains). If only the whole-ride-reversing modes are wanted, though, the implementation can certainly be changed.

I would prefer to do things in gradual steps, the lines you touched revealed that it can be a bit cleaned up in general, you can add the new field to the vehicle when its actually possible to individually set their rotation. The reverse field is a bit too specific to store as its driven by the operating mode at the moment.

It seems like this PR could easily change from using a unique operating mode to having a tickbox in vehicle selection, which the tickbox could be enabled with the TrackedRide RTD flag (assuming it isn't also present for tower rides). This means more flexibility and less code bloat since you don't have to copy all the Continuous Circuit/Continuous Circuit Block Section code, and it can be applied to rides of other operating modes like Reverse Incline Lift Hill, Powered Launch, Powered Launch Block Section, etc.

Otherwise this is a pretty solid implementation.

This is all good feedback - It seems there's some different opinions on how best to support this feature, so maybe it'd be worth sending this PR back to draft to let more discussion take place (I maybe jumped the gun a bit with this PR)

• If only the operating modes are wanted to start with, I can remove the IsReversed attribute and derive behavior from ride mode for the time being
• If capacity for plugin modification is wanted, I can leave as is
• If the operating modes are too bloaty, I can send this back to draft and look into adding an option in vehicle selection UI (though that implementation might make it harder to restrict to specific coaster types, which is definitely important)

Something to consider doing is changing the peep target locations when the ride vehicle is loading/unloading. It appears the peeps will walk to (when loading) or spawn from (when unloading) the regular positions instead of the reverse positions.

You need to rebase this PR as I did some cleaning around that code. Right now the question is rather should be this be an operating mode or not, I think that an operating mode fits this case the best but I can see how people might have the idea to individually reverse only certain vehicles, in both cases quite a bit logic requires to be changed. I'm not opposed of the new operating mode but some comments should be addressed, the reversed field is not needed when it can be derived from the operating mode. I think having it per vehicle basis makes things a bit more complicated code wise and probably has some issues with certain modes.

Right now the question is rather should be this be an operating mode or not

For what it's worth, my opinion is that per-vehicle flipping is great for advanced players (has applications in creating custom rides, for instance) but might be too crazy or overwhelming for your average player. I think splitting it up between plugin support for full flexibility, and operating modes for "official" support, could be a good compromise. I've been developing the feature based on that framework so far, but I'm open to different ideas. Maybe it'd be helpful to get a few more opinions to try and reach a consensus.

To clear up any confusion, since there might be some, I am not advocating for allowing users to flip individual vehicles around using the ride window. That granular functionality should be limited to plugins whose purpose is to manipulate individual vehicles.

I think the implementation is reasonable now, tagging @Broxzier and @duncanspumpkin to see what they think, I think this is a great addition overall I just were not too happy about the code.

I think the implementation is reasonable now, tagging @Broxzier and @duncanspumpkin to see what they think, I think this is a great addition overall I just were not too happy about the code.

Changes look nice and concise and simple. I don't have much to add.

The current implementation has to add or modify 7 operating mode conditions. This doesn't seem very future-proof: adding other operating modes requires modifying these same checks and more, and it clutters the list of operating modes.

I say it should be stored as a separate value from operating mode. An RTD flag can enable a tickbox on desired rides like so:

This compartmentalizes the features.

I say it should be stored as a separate value from operating mode. An RTD flag can enable a tickbox on desired rides like so:

That's certainly doable, though I do have some concerns:

• This would require use of a ride flag - there are only 4 remaining free ride flags, (compared to the 16 free vehicle update flags). The other option is a new attribute and save format version. I misread the code - as far as I can tell, this would definitely require a new attribute and save format version.
• The new UI element and GameAction would add a lot more complexity which is already handled by operating modes. In order to reverse the trains, the ride also needs to be closed and reopened, which operating modes already handle.
• Having this feature as Operating modes also integrate well with the "Show operating modes" and "Allow arbitrary ride type changes" cheats - it makes it trivial to add to a different ride type.
• A new UI element that's sometimes there and sometimes not could be confusing to players, as the rules for its appearance are hidden (I know it took me some time to figure out the rules for the "number of circuits" tick box). On the other hand, anyone who's played the game will know that operating modes vary from ride to ride.

I definitely agree that having to touch a bunch of ride mode conditions isn't the best. My impression while I was writing the code was that the RideMode type could stand a rework - perhaps to a parameterized enum or struct. Obviously that's outside the scope of this PR though.

I say it should be stored as a separate value from operating mode. An RTD flag can enable a tickbox on desired rides like so:

That's certainly doable, though I do have some concerns:

• This would require use of a ride flag - there are only 4 remaining free ride flags, (compared to the 16 free vehicle update flags). The other option is a new attribute and save format version. I misread the code - as far as I can tell, this would definitely require a new attribute and save format version.
• The new UI element and GameAction would add a lot more complexity which is already handled by operating modes. In order to reverse the trains, the ride also needs to be closed and reopened, which operating modes already handle.
• Having this feature as Operating modes also integrate well with the "Show operating modes" and "Allow arbitrary ride type changes" cheats - it makes it trivial to add to a different ride type.
• A new UI element that's sometimes there and sometimes not could be confusing to players, as the rules for its appearance are hidden (I know it took me some time to figure out the rules for the "number of circuits" tick box). On the other hand, anyone who's played the game will know that operating modes vary from ride to ride.

I definitely agree that having to touch a bunch of ride mode conditions isn't the best. My impression while I was writing the code was that the RideMode type could stand a rework - perhaps to a parameterized enum or struct. Obviously that's outside the scope of this PR though.

More or less what I thought also. And you are also correct that the PR should not extend beyond the current scope, as I suggested before its best de-hardcode such things so in the future either plugins or some form of meta data can extend/change the functionality of the game, the long term goal should be to rewrite the code in a way that we no longer have to change/add code for the sake of changing/adding things, this also allows people with very little to no coding experience to extend/modify the game in a way they see fit.

• This would require use of a ride flag - there are only 4 remaining free ride flags, (compared to the 16 free vehicle update flags). The other option is a new attribute and save format version. I misread the code - as far as I can tell, this would definitely require a new attribute and save format version.

I don't know how the OpenRCT2 team feels but I don't think twice about bumping save file format. If a feature needs a modification to the save file format, then so be it.

RTD flags: there's no issue with using another ride type flag because we have BitSet which RTDs already use for available track elements but nobody has gotten around to upgrading the ride flags field to use it.

Ride flags: the lifecycle_flags field has 22 of 32 flags used, so there's no issues there.

Vehicle flags: vehicle update flags are actually the ones in short supply; the uint32 for the enum is a mistake because the actual flags field is only a uint16. This flags field should be widened or a second flags field added since "update flags" implies a relationship to simulation. On second thought, this could be its own PR so I am going to do that right now.

• The new UI element and GameAction would add a lot more complexity which is already handled by operating modes. In order to reverse the trains, the ride also needs to be closed and reopened, which operating modes already handle.

I don't see how it would add complexity compared to modifying all the ContinuousCircuit/ContinuousCircuitBlockBrakeReferences in ride and vehicle code. With the number of those changes, LOC might not even go up up with this approach. There's already RideSetSettingAction which can handle setting the reverse property.

• Having this feature as Operating modes also integrate well with the "Show operating modes" and "Allow arbitrary ride type changes" cheats - it makes it trivial to add to a different ride type.

As a separate button, it will integrate with the "disable vehicle limits" cheat, and as a ride type flag it is equally trivial to add to a different ride type.

• A new UI element that's sometimes there and sometimes not could be confusing to players, as the rules for its appearance are hidden (I know it took me some time to figure out the rules for the "number of circuits" tick box). On the other hand, anyone who's played the game will know that operating modes vary from ride to ride.

I think the solution is then add it to enough rides that the pattern is clear. If all roller coasters had this tickbox, it would be relatively obvious that roller coasters can have reversed vehicles. I could see limiting the number of rides with the operating mode but when it's separated from operating mode I don't see why it would be arbitrarily limited to a few roller coasters.

I realize this is your first OpenRCT2 PR so if I come off too strong, I apologize. Vehicle update code is something I feel strongly about. I am willing to help implement what I've outlined above if you want it.

Not coming off too strong at all, this is all good info (and I do this stuff for a living, I'm used to it). I want this to be the best it can possibly be.

Regarding the flags, the lifecycle flags didn't initially seem to me like the right place for that sort of setting, and I didn't want to just add it haphazardly. I now notice that the flag for music is there, so it makes enough sense for a cosmetic setting like this.

I totally get the concerns with the hardcoded conditions. It seems to me like this feature revealed an issue with the RideModes implementation, and I think it could be addressed with some improvements to the RideMode model in a separate PR. I have some ideas as to how to do that, so if that's desirable I could potentially tackle it (if you want to talk about that more we can take it to a separate discussion thread). If those issues are resolved I personally think an operating mode would be the simplest (and easiest to understand for players) implementation for this. This PR could either wait for that redesign, or temporarily make the code smell a little worse, or go with the tickbox design instead. I'll give the tickbox a try to see how it plays.

In an earlier comment I mentioned limiting this feature to a few coasters for visual & realism reasons. Of course, with cheats it's usable on any, but for the "proper" experience I think having it be kept special makes sense. There's also a few rides that it would cause graphical oddities with, such as all the ones with swinging sprites (Not sure if I can do something about that).

Thanks for all your help and patience!

Newest commit uses the tickbox implementation. Now that I see it in action I like it a bit more. Let me know how you folks feel about it.

A couple notes:

• The window height for the vehicle page had to be adjusted. If the tickbox was placed in that position without changing the height, it would overlap the vehicle info text if the text used 2 lines and had all three E/I/N modifiers (an example being the Wooden 6-Seater Reversed trains)
• The new setting is currently not persisting across a track design save/load. The TrackDesign model appears to have some (apparently unused) flag parameters - I wasn't sure if it would be acceptable to place the setting there, so I left it out for now.
• The tickbox will appear on ride types with the ALLOW_REVERSED_TRAINS property, or if the "Show all operating modes" cheat is enabled. It might be better design to tie it to the arbitrary vehicle changes cheat, though the text "Show vehicles from other track types" doesn't imply that behavior.
• EDIT: I noticed that the Mini Railroad never leaves the station with reversed trains. Seems to be unique to that ride type/vehicle. Will look into it, but it may or may not be worth fixing given it's not any more broken than some of the other cheated ride/mode combinations.

• EDIT: I noticed that the Mini Railroad never leaves the station with reversed trains. Seems to be unique to that ride type/vehicle. Will look into it, but it may or may not be worth fixing given it's not any more broken than some of the other cheated ride/mode combinations.

Ride trains are either "powered" or "unpowered" and that status is determined by the factory template of the first car in the train. The steam locomotive is flagged as powered, and the cars are flagged as unpowered.

EDIT: For the tickbox cheat, disable vehicle limits might be more appropriate - it already affects stuff on the vehicle selection page.