QFG4CD: Fix parsing/compiling escaped backslash in string literals

[laurence-myers]

Parser fix

ParserCommon.h: _ReadStringSCI: fix parsing \\

In QFG4CD, script 54 "Import" tries to add a backslash to a string, using the syntax {\\}. The parser used a naive test to see if the closing quote char was escaped, by checking if the previous character was a backslash, which falls over when that backslash is escaped by another backslash. I've fixed it by instead checking the "fEscape" boolean.

I've also added an explicit case for parsing an escaped backslash. This might fix/impact the "default else" case - we may want to uncomment the statement processCharNormally = true, since my changes might fix the case for sciAudio\\command.con.

Syntax highlighting fix

ScriptView.cpp: fix syntax highlighting for double-quoted string literals containing double-backslashes (escape characters), in SCI script syntax.

Additional changes

• Add my name to the credits. Mostly to test that I can rebuild the project with some kind of change. :) (I don't mind removing this or making it less prominent, it was just for testing really.)
• .gitignore: ignore the .vs/ directory, added in at least Visual Studio 2022

Testing

Before

• Decompile QFG4CD. (I used a copy without NewRisingSun's patches, i.e. not the GOG version.)
• Open script 54 (MyButton_54.sc, which is actually the hero import script)
• Scroll to line 600. Observe that all code after column 54 is syntax highlighted as if it were part of the string.
• Compile the script. Observe that you receive the error "Expected an expression."

After

As before, but this time the syntax highlighting is constrained to the actual string literal, and compilation succeeds.

Other notes

In ParserCommon.h, _ReadStringSCI, there's a line of code commented out: processCharNormally = true. The comment near it mentions that it was causing problems parsing sciAudio\\command.con into sciAudio\\mmand.con. I think my changes fix the parsing of the double backslash, so we might be able to restore the commented code. I don't know what game/script it's referring to, so I can't test it myself.

(However, it might be even better to just fail parsing, if we find an invalid escape sequence like \c. I don't know if that's possible currently.)

Caveats

• I've not fixed the SCI Studio syntax, I don't see much value in supporting it any more.
• I'm a C++ newbie, I may have made some basic mistakes. For example, the function signature BOOL IsStringCharEscaped(LPCTSTR pszChars, int indexOfChar) might be wrong. I wasn't sure whether to use BOOL, like the other existing functions, or bool, which seems more standard. I also would have thought LPCTSTR pszChars should be LPCTSTR &pszChars. Any guidance would be welcome (but not expected). 🙂

[Kawa-oneechan]

Regarding your other notes, that whole thing refers to SCI0 fan games writing instructions to a file for an external program to pick up that plays better soundtracks. All you should need to test it is to have a string literal with that path in it, see if it compiles and decompiles correctly. You do that, and I'll be willing to hit the merge button.

As for your caveat, that's actually not specific to C or C++ but rather Win32.

[laurence-myers]

All you should need to test it is to have a string literal with that path in it, see if it compiles and decompiles correctly. You do that, and I'll be willing to hit the merge button.

Great! I tried it out, and it looks good to me. I changed the string literal to {sciAudio\\command.con}, compiled, and decompiled, and it preserved the string. 🙂

Initial change & compile:

Decompile:

Decompiled script:

I then tried changing that last "else" condition. Now, if you pass an invalid escape sequence, like \c, it will output just c. I think this is less surprising than outputting an extra backslash. I've pushed up another commit with this change.

Initial script:

After decompile: