Repository navigation
Skip a UTF-8 byte order mark at the start of multi.cfg - #7881
Open
dustinspace217 wants to merge 1 commit into
Open
dustinspace217 wants to merge 1 commit into
dustinspace217 wants to merge 1 commit into
Conversation
Editors such as Notepad can save multi.cfg with a byte order mark. The reader compared the first word of each line with the option names, so the mark made the first option silently ignored.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Fixes #5543
What?
Strips a UTF-8 byte order mark from the first line of multi.cfg before it is parsed.
Why?
Some editors (Notepad, depending on version and settings) save the file with a byte order mark. The reader compares the first word of each line with the option names, so with the mark in front the first option never matches and is silently ignored. That is why adding a dummy first line works around it. The engine never writes multi.cfg, so "works once, then stops" most likely comes from the file being saved again by an editor.
How?
On the first line only, if it starts with EF BB BF, those three bytes are removed before parsing. I didn't reuse
util::check_encoding_and_skip_bom: it callsError()on a file with a mark when Unicode text mode is off, which would make this case fatal instead of fixing it.Testing?
A standalone server with its own preferences folder, checked through the standalone web API: which login works, which port it listens on, and the server name it reports. Each run used its own port and server name, so every answer came from that run. Master (a1250d7) against this branch, Linux Release builds, retail FS2 data, no mods. 14 multi.cfg variants:
A normal game launch into SM1-01 on this branch reads multi.cfg at startup and plays as before.
Anything Else?
fs2_open.ini has the same problem in
profile_read: a mark before[Default]means the keys under it are dropped, which fits the part of #5543 about the ini. I'll send that as a separate PR. Written with Claude Code; the investigation, review and testing ran on my machine.