When I wrote the original change to a vector instead of an array, I was working on the assumption that this section of code was parsed after some other code that had already made sure that the special_char_indexes vector was at least three entries. Further testing has revealed this is not true, and this fix keeps it from crashing.
1. Stores the filename from the table Parser into the font struct so we can lookup fonts via their filename.
2. Allow "+Special Character Font:" to specify the first entry with the same filename's special character index for their own special character index, provide a default if not, and allow the moddert to specify them manually, but do not override already recorded values if the default is picked in order to protect retail behavior.
3. Vectorize Special Character Indexes, so that we don't have a table limit that will randomly crash FSO based on what table you happened to write! Woohoo!
Back in PR #2390, I fixed translation behavior in `lcl_ext_localize_sub` for SCP_string, but neglected to also fix it for `char*`. This PR remedies that.
I also added `!=0` to the string compare to match the `!=0` used with `strcmp`.
This is a minor follow-up to PR #2390. There are a few minor differences between untranslated strings and the internal strings in strings.tbl; this PR fixes them.
Since the original release of FS2, internal strings have been translated to their English entries in strings.tbl but external strings have not been translated to their English entries in tstrings.tbl. It appears that string translation was universal until it was disabled via a hack, probably due to FRED idiosyncrasies (see comment in `fred_init()`), and then not re-enabled for release. PR #2343 re-enabled it, but this turned out to have undesirable side-effects since many mods used incorrect XSTR indexes for external strings.
This PR restores the previous behavior and also cleanly separates localization into translated and untranslated modes. FRED will always run in untranslated mode. FSO will run in translated mode for all languages except English, where it will run in untranslated mode UNLESS the new option `$Use tabled strings for the default language` is enabled in game_settings.tbl.
Certain mods provide their own tstrings.tbl, but this runs into trouble when you localize data meant for one mod using a tstrings.tbl meant for another mod. See the Mantis ticket:
http://scp.indiegames.us/mantis/view.php?id=2942
and also the HLP post:
http://www.hard-light.net/forums/index.php?topic=85041.msg1716600#msg1716600
This PR adds an optional flag that will check the untranslated string against the "default language" translated string. The two strings should be identical. If they aren't, the code assumes there is a tstrings.tbl mismatch.
I modified the mission listing code to enable this check when localizing mission info (titles and descriptions), and to avoid adding the mission to the list if there is a mismatch. Fortunately, I think mission listing is the only place where this bug is likely to happen.
This commit adds new id for existing strings, so that they are translateable through the strings.tbl.
The following is translateable now:
- The 'or' seperator in the Keypress Directive gauge, if one function is bound to two keys.
- The Supernova warning.
- The error message that is displayed prior the pilot selection screen, if something is wrong with the loaded modification.
The current code drops trailing white space which can cause issues if
the translated string is used in concatenations. The retail tstrings.tbl
has some entries with white space at the end but since those strings are
not used for concatenations (or else this issue would have been found
earlier) this change should not cause issues there.
This fixes#1739.
This adds support for displaying subtitles embedded in movie files. This
supports files with multiple subtitle streams where each stream contains
the subtitles for one language. When the movie file is opened, the
stream for the currently active language will be used and displayed.
This resolves one of the points mentioned in #1522.
This also depends on PR #1484.
This adds proper Unicode support by allowing the parse system to read
UTF-8 encoded files. The new mode is controlled by a mod option which
allows older mods to continue using the legacy text encoding.
That option changes the behavior of several systems in FSO. It disallows
the usage of Volition fonts since they don't support Unicode encoding
and changes a few usages of special characters to their unicode
counterparts of generic rendering solutions.
This fixes#1415.
Since 4500 strings are not enough for some mods there was a request for
removing that limit. I chose to use an unordered map for storing the
entries since the indices are not guaranteed to be sequential.
This fixes Mantis 3199.
Before, if any parsing call failed it would throw an exception which
would have been propagated to the exception handler in main() which
terminates the program. This should fix that.
This allows to use standard TrueType Fonts for text rendering in FSO. It uses the NanoVG library which provides the ability of drawing 2D shapes. This library is used for most 2D operations now and can also be used directly by using the PathRenderer class.
Revert an Error back to a Warning
Prevent an out-of-bounds read of the Lcl_ext_str array
git-svn-id: svn://svn.icculus.org/fs2open/trunk/fs2_open@11008 387891d4-d844-0410-90c0-e4c51a9137d3
In other words, a pilot can only be used in the same language it was
created with. Checks both the initial selection screen and in the
barracks.
Also fixes issue with PLR version being ignored in pilotfile::verify()
git-svn-id: svn://svn.icculus.org/fs2open/trunk/fs2_open@10817 387891d4-d844-0410-90c0-e4c51a9137d3
update hud_num_make_mono (& callers) to handle the font number
add partial support for specifying special char indexes for individual fonts
git-svn-id: svn://svn.icculus.org/fs2open/trunk/fs2_open@9985 387891d4-d844-0410-90c0-e4c51a9137d3
JohnAFernandez