Feature: Setting to disable loading speed penalty for trains at short platforms

[EmperorJake]

Motivation / Problem

Trains get a penalty to loading speed if the platform is shorter than the train. There is currently no way to get around this, however there are several use cases why a player might want to do so:

• Underground stations where the rest of the platform is "hidden" inside the tunnel or on a bridge. This applies to eyecandy players who might do creative things with overlapping station tiles and such.
• Saving space by loading trains in curved tracks rather than one long platform. Similar to "through loading" as found in JGRPP, but without the extra train movement.
• Saving infrastructure costs by not needing as many station tiles. This applies to min-maxer players.

There have been various patches in the past to the same effect. Some have added a cheat, others have straight up deleted the code responsible for the loading speed penalty. This feature has been in demand by a subsection of the playerbase for a long time now, it's time it was made a proper setting.

Description

This PR adds a setting which allows the player to disable the loading speed penalty for trains at shorter platforms.

The setting is an "Expert" setting as it has relatively niche uses and new players don't really need to see/change it.

The setting is under the "Limitations" category as this is more in line with #11683

Limitations

The setting does not affect the train pathfinder avoiding short platforms. But that's a good thing as it would mess up many rail layouts otherwise.

Checklist for review

Some things are not automated, and forgotten often. This list is a reminder for the reviewers.

• The bug fix is important enough to be backported? (label: 'backport requested')
• This PR touches english.txt or translations? Check the guidelines
• This PR affects the save game format? (label 'savegame upgrade')
• This PR affects the GS/AI API? (label 'needs review: Script API')
  • ai_changelog.hpp, game_changelog.hpp need updating.
  • The compatibility wrappers (compat_*.nut) need updating.
• This PR affects the NewGRF API? (label 'needs review: NewGRF')
  • newgrf_debug_data.h may need updating.
  • PR must be added to API tracker

[2TallTyler]

I'm not sure how I feel about this. It feels like a very niche feature. That said, I agree that having it as a cheat would be the proper way to do it.

You'll notice that commit checker has failed for invalid tab usage. We only use tabs for the leftmost indentation. Any spacing/indentation besides that is created with spaces.

[EmperorJake]

I agree that it's a fairly niche feature, but I think there is a small but important part of the playerbase who would greatly appreciate this feature. If the developers feel that it's still too niche, perhaps it would be better ported to JGRPP.

Here is a Discord coversation involving players who support this feature and how they would use it: https://discord.com/channels/142724111502802944/919788785217179738/1077537785759674388

[ldpl]

I completely disagree with it being a cheat, it achieves nothing but making this setting inconvenient to use (can't change in mp, put into a config etc.).

[EmperorJake]

That's a valid point, it would work better as a setting. However, in the past devs have voiced concerns about "significant gameplay implications" (see JGRennison/OpenTTD-patches#330) so I thought it would be more palatable as a cheat.

[ldpl]

Cargodist, breakdowns and build on pause have much more significant "gameplay implications". This just allows you to build one station tile instead of TL, big deal. Also, you can already unload train on a small station quickly by reversing it a few times.

I can even make an opposite argument - this is a joke of a cheat because it only saves you a few pennies :p

[EmperorJake]

I just found a patch to the same end on a forum thread from over 10 years ago. This goes to show that this feature has been in demand for a very long time https://www.tt-forums.net/viewtopic.php?p=1074153

[PeterN]

That's a valid point, it would work better as a setting. However, in the past devs have voiced concerns about "significant gameplay implications" (see JGRennison/OpenTTD-patches#330) so I thought it would be more palatable as a cheat.

I don't see any vanilla dev's opinions on that link...

I agree (shock horror) with @ldpl here.

[2TallTyler]

Okay, your comments here and this morning's Discord discussion have changed my mind. I like this as a setting. 🙂

Oh, and you'll want to squash your commits.

[rubidium42]

Is this setting properly saved in the save game? As far as I can see it's not; at least, I'm not seeing a save game version and such.

[JGRennison]

The settings table doesn't require a savegame bump for new settings.
It isn't otherwise necessary to bump to savegame version because there isn't any new/changed state which prior versions couldn't understand.

[EmperorJake]

I tested saving and loading a game, and the state of the setting got saved too.

The original cheat version of the PR had some saveload code, but I assumed that was due to cheats being recorded by the save. I copied a different PR that added a setting and it didn't come with saveload code either.