Openrct2: The penalties for excessive lateral G's are significantly lower in vanilla and classic

Created on 22 Oct 2018  路  4Comments  路  Source: OpenRCT2/OpenRCT2

If you look at these screenshots you can see that the penalty for having at least 2.81 lateral G's is about 3.75 in OpenRCT2 while it's only about 2 in vanilla.
image
image

The same goes for the penalty for having at least 3.11 lateral G's. In OpenRCT2 you get an extra 8.5 intensity while in vanilla it seems to be about 4.6.
image
image

Here is also the save file if you want to see it for yourself.
Lateral G penalties.zip

The extra nausea you get from those penalties is different as well. Classic has the same penalties as vanilla.

I know that the order of the stat requirement penalties and lateral G penalties was reversed in openrct2, but that shouldn't have an influence here since there are no stat requirement penalties.

bug

Most helpful comment

Why is that the reason? In there I see nothing about changing the actual penalties, only the order. Since these rides both don't receive any penalties from the stat requirements that change should not have any effect on it.

By changing the order you change the size of the penalty if and only if there is another modifier that is a multiplier. There are a number of multiplier modifiers listed below:

  • ride_ratings_apply_adjustments
  • ride_ratings_apply_intensity_penalty only excitement
  • ride_ratings_apply_highest_drop_height_penalty
  • ride_ratings_apply_max_speed_penalty
  • ride_ratings_apply_num_drops_penalty
  • ride_ratings_apply_max_negative_g_penalty
  • ride_ratings_apply_max_lateral_g_penalty
  • ride_ratings_apply_first_length_penalty

Before the g force calc applied the penalty at the start of the rating calc.
It has now been moved to after the:

  1. ride_ratings_apply_highest_drop_height_penalty
  2. ride_ratings_apply_max_speed_penalty
  3. ride_ratings_apply_max_negative_g_penalty
  4. ride_ratings_apply_num_drops_penalty
  5. ride_ratings_apply_max_lateral_g_penalty
  6. ride_ratings_apply_first_length_penalty

So in that 3.11 coaster we have:
No application of ride_ratings_apply_highest_drop_height_penalty as it is high enough.
No application of ride_ratings_apply_max_speed_penalty as it is fast enough.
No application of ride_ratings_apply_max_negative_g_penalty as it is less negative than the threshold.
No application of ride_ratings_apply_first_length_penalty as it is long enough for the first section.
No application of ride_ratings_apply_num_drops_penalty as it has enough drops.
ride_ratings_apply_max_lateral_g_penalty does not apply for this ride type.

So because of the above it gets the full penalty and that should match the vanilla game. This as much as it pains me to say it suggests there is a mistake somewhere in the OpenRCT2 calculation.

And after a little look at the code I've found the source of the issue. The ride type modifier is not being applied to the ride_ratings_apply_excessive_lateral_g_penalty unlike the old ride_ratings_apply_gforces so it should be 35746*penalty / 65356 so roughly 0.54 * penalty. So it should be ~5.6 points lower for intensity. Giving a final estimated value for intensity of 13.685. Which is very very close to RCT2. I think that proves the issue.

All 4 comments

This was from #3656 which has the reasoning.

Why is that the reason? In there I see nothing about changing the actual penalties, only the order. Since these rides both don't receive any penalties from the stat requirements that change should not have any effect on it.

I see the same penalties for excessive lateral G-forces in the code of very old versions of OpenRCT2.. (ride_ratings.c). Perhaps someone should check if the aforementioned fix caused the rating calculations to be different, or that it was already different before that.

Why is that the reason? In there I see nothing about changing the actual penalties, only the order. Since these rides both don't receive any penalties from the stat requirements that change should not have any effect on it.

By changing the order you change the size of the penalty if and only if there is another modifier that is a multiplier. There are a number of multiplier modifiers listed below:

  • ride_ratings_apply_adjustments
  • ride_ratings_apply_intensity_penalty only excitement
  • ride_ratings_apply_highest_drop_height_penalty
  • ride_ratings_apply_max_speed_penalty
  • ride_ratings_apply_num_drops_penalty
  • ride_ratings_apply_max_negative_g_penalty
  • ride_ratings_apply_max_lateral_g_penalty
  • ride_ratings_apply_first_length_penalty

Before the g force calc applied the penalty at the start of the rating calc.
It has now been moved to after the:

  1. ride_ratings_apply_highest_drop_height_penalty
  2. ride_ratings_apply_max_speed_penalty
  3. ride_ratings_apply_max_negative_g_penalty
  4. ride_ratings_apply_num_drops_penalty
  5. ride_ratings_apply_max_lateral_g_penalty
  6. ride_ratings_apply_first_length_penalty

So in that 3.11 coaster we have:
No application of ride_ratings_apply_highest_drop_height_penalty as it is high enough.
No application of ride_ratings_apply_max_speed_penalty as it is fast enough.
No application of ride_ratings_apply_max_negative_g_penalty as it is less negative than the threshold.
No application of ride_ratings_apply_first_length_penalty as it is long enough for the first section.
No application of ride_ratings_apply_num_drops_penalty as it has enough drops.
ride_ratings_apply_max_lateral_g_penalty does not apply for this ride type.

So because of the above it gets the full penalty and that should match the vanilla game. This as much as it pains me to say it suggests there is a mistake somewhere in the OpenRCT2 calculation.

And after a little look at the code I've found the source of the issue. The ride type modifier is not being applied to the ride_ratings_apply_excessive_lateral_g_penalty unlike the old ride_ratings_apply_gforces so it should be 35746*penalty / 65356 so roughly 0.54 * penalty. So it should be ~5.6 points lower for intensity. Giving a final estimated value for intensity of 13.685. Which is very very close to RCT2. I think that proves the issue.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

nuclearslurpee picture nuclearslurpee  路  3Comments

telk5093 picture telk5093  路  3Comments

Ryder17z picture Ryder17z  路  3Comments

Superjustinbros picture Superjustinbros  路  3Comments

deurklink picture deurklink  路  3Comments