Fix: do not use {STRING} when {STRING1} or {STRING2} is needed

[rubidium42]

Motivation / Problem

STR_JUST_STRING with {STRING} when that string consumes one or two parameters.

Description

Introduce STR_JUST_STRING1 and STR_JUST_STRING2, and use them.

Limitations

There might be other cases where this is the case, but reviewing that is very cumbersome. Enabling the check for not consuming too many parameters is something for another PR. That will make the broken strings visible, if there are any, and hopefully reported relatively soon.

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, gs_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

[PeterN]

Some of this was the fairly recently changes to remove various strings which just set colour/size, which is now done by attributes.

So what should I/we have done to notice these were wrong at the time, and is it preventable?

[rubidium42]

Some of this was the fairly recently changes to remove various strings which just set colour/size, which is now done by attributes.

So what should I/we have done to notice these were wrong at the time, and is it preventable?

There was a warning in strings.cpp when parsing the {STRING} that it does not consume any parameters, but then it allows parameters to be consumes. The comment stated how to disable that.
So, to preventing it back then would be knowing that you need to change that parameter and then finding it either crashing when {RAW_STRING} is used, or a message to the console and "bad data" in the string.
The last 24 hours I fixed the crash for {RAW_STRING} and enabled the enforcement, so it would show strings with the wrong data (getting the parameter value would always return 0), and a lot of warnings on the console. So it will be more obvious that you did something wrong.

[PeterN]

By "a warning" you mean the comment, rather than anything at compile-time or run-time?

One of these was 10 years old, did it not work at all that time?

In some cases the originally used string contained e.g. "{BLACK}{STRING}" which was replaced with a string that contains "{STRING}". This is now replaced with a string that contains "{STRING1}". Was it also broken before the string changes we made?

[rubidium42]

By "a warning" you mean the comment, rather than anything at compile-time or run-time?

Yes, that comment.

One of these was 10 years old, did it not work at all that time?

It kinda worked, because it previously just passed all the remaining parameters. So if you had enough parameters, it would show correctly. Even though (incorrectly) using {STRING} over {STRINGn}

In some cases the originally used string contained e.g. "{BLACK}{STRING}" which was replaced with a string that contains "{STRING}". This is now replaced with a string that contains "{STRING1}". Was it also broken before the string changes we made?

Yes, technically it could have been broken for years. {STRING} just behaved as a {STRING<inf>} that does not increase the offset after using them.