search

OpenRCT2 / OpenRCT2

An open source re-implementation of RollerCoaster Tycoon 2 🎢
https://openrct2.io
GNU General Public License v3.0
13.29k stars 1.52k forks source link

Impossible acceleration with tightly banked drops #21105

Open The0neThe0nly opened 8 months ago

The0neThe0nly commented 8 months ago

Operating System

Linux (x86-64)

OpenRCT2 build

OpenRCT2, v0.4.6 (, DEBUG)

Base game

RollerCoaster Tycoon 2, RollerCoaster Tycoon Classic

Area(s) with this issue?

The bug also exists in the original game (RCT2/RCTC)

Describe the issue

When building a custom wooden roller coaster for a scenario, I noticed a bug in which my trains gained minuscule speed in an impossible way. Using tightly banked downward curves followed by steep inclines, somehow roller coasters gain velocity instead of decelerating due to friction as expected.

Upon further investigation, I found that this bug exists on multiple types of roller coasters. I was also able to reproduce it in Roller Coaster Tycoon 2, so this is an original bug. I tried wider banked drops, but this did not reproduce the issue and friction acted as intended.

Steps to reproduce

I've attached two different proof-of-concept TD6 track files made in OpenRCT2 that obviously reproduce the issue. You can reproduce this yourself without the track files by building drops with the design pattern indicated in the screenshot: image

PoC.zip

Attachments

Here are some screenshots that demonstrate the impossible velocity gain.

image

Despite the original lift hill taking the train to 90 ft, and despite every successive hill only reaching 90 ft (no chain), the train impossibly accelerates to the point where it is able to successfully clear 110 ft by the end.

image

ocalhoun6 commented 8 months ago

Fixing a bug like this is tricky, because some existing track designs might depend on this speed boost without even knowing it, and fixing the bug might break those track designs.

The0neThe0nly commented 8 months ago

I agree. I understand if this issue is a "wontfix" but I was also thinking that if there are other acceleration/physics issues, they could be combined into a non-default "Realistic physics" setting or something similar.

cheweytoo commented 8 months ago

I realise that this would introduce separate code paths to be kept forever, and thus might be a non-starter: A possible solution would be a versioning attribute on a ride that would be set at the time a ride is first built.

Any ride without this attribute would get "legacy acceleration", while others would get the acceleration model their attribute declares.

Mixing several acceleration models in one park might be unwanted though. For one, I have no idea about the possible performance impact of running different acceleration models in a single park.

spacek531 commented 8 months ago

There is an open PR that changes vehicle physics that implements @cheweytoo's proposal regarding a different change to physics. The changes to physics in the PR is more readily backwards-compatible than the one discussed in this thread, so the two should not be combined. This change to physics, if it is ever implemented, will have to wait until after NTDF to be completely backwards-compatible.

The issue with combining the two together is that the PR's change is backwards-compatible with track designs because of the limitations of track designs, but the proposed change is not. I suspect the devs will choose not to allow saving and loading of the information to track designs.