Fix: GetCurveSpeedLimit needs railtype from current tile #8466
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation / Problem
This is a fix to make railtype prop 11 work as described in the newgrf spec https://newgrf-specs.tt-wiki.net/wiki/Action0/Railtypes#Curve_Speed_advantage_multiplier_.2811.29
"This property sets the multiplier to the curve speed advantage which all trains running on this track type get."
GetCurveSpeedLimit was using the railtype from train prop 05, not the current railtype on the tile. Seems plausible that it was just missed when NewGRF railtypes were added.
I noticed this (some time ago) when I created a railtype grf setting a higher value for prop 11 and could see no difference in game.
Additionally for Jan/Feb 2021 there is a tt-forums contest running for 'make a High Speed grf' which motivated me to look into this again, as contestants may encounter this bug.
Description
GetCurveSpeedLimit now checks current railtype on the tile.
Test grf and savegame attached. Behaves as expected in the test case.
8466-railtype-prop-11-test-case.zip
Limitations
I tried a test case where the railtype changes mid-curve. It's not in the savegame, but it does appear to work.
GetAccelerationType in train.h (railtype prop 15) may have the same issue, but the NewGRF spec is less definitive there and is likely to trigger a debate, so I would like to stick to just fixing prop 11 as a single issue.
Checklist for review
Some things are not automated, and forgotten often. This list is a reminder for the reviewers.