Rocks'n'Diamonds

Not really sure where to start that topic, but basically, one of the recent updates made some unknown characters to display as "??" when originally they displayed as just invisible characters, when originally some displayed as just empty spaces. Here's screenshots of two different versions handling the same thing differently for comparison:

Here's what the text file itself looks like:
Now, I'm not sure if that was intentional or not, but that was probably done to support more characters (potentially?), but I actually utilized one of these "invisible" characters, mostly for info screens to hide some text fields empty, especially music info, you can see that in the first screenshot above.
I'm not saying this change should be reverted, but I think there at least should be a way to have some of these fields to be empty just for such cases, maybe a character the game itself would never use that would render empty. And for context, it can't be just space, since using space basically means no input, therefore it uses whatever the game has by default for it. In my case, the "played:" field would just display as "Level 001" since I didn't replace it with anything valid:

Is there any potential solution to this besides weird workarounds? (although it was a workaround of it's own)

Now, I'm not sure if that was intentional or not, but that was probably done to support more characters

Yes, exactly. Although I wonder why it did not happen earlier, as older versions also supported things like ISO-Latin-1 character sets etc. But indeed I did some additional changes recently, which most probably have caused what you reported here.

I think the best solutiion would be to be able to assign an empty string to a configuration parameter, as that is what you really want to do, so no "dirty" workaround (using non-printable characters) would be needed anymore.

I will have a look how this could be done; maybe a simple
would be sufficient, but without having a string that contains two double quote characters as the result.

Just had a deeper look at this issue:

Although I wonder why it did not happen earlier, as older versions also supported things like ISO-Latin-1 character sets etc. But indeed I did some additional changes recently, which most probably have caused what you reported here.

The change was indeed as follows: If a character would result an invalid position inside the font bitmap (as it would be the case for your "dummy" character "ъ" here, which seems to be a "wide" (non-8-bit) UTF-8 character), instead of just falling back to an empty space (" ") character in the font, an explicit "?" character is used instead in recent versions, to make it more clear that an invalid character was used here. (For example, when using a player name with only kyrillic characters, a player name text like "???????" will be shown instead of just spaces, indicating that "unknown" characters were used here.)

I think the best solutiion would be to be able to assign an empty string to a configuration parameter

Unfortunately, that does not work here, as an empty string is treated as "not defined here", so the whole info text section is just skipped. (For example, using an empty "artist:" results in just skipping both "artist_header: <whatever>" and "artist:".)

For now, I would suggest to just use an otherwise unused character (like one of the umlaut characters "Ä", "Ö", or "Ü", for example) for the section you want to be displayed as "empty", and change your font bitmap ("font.text_3.INFO" in this case) to have the same graphics at that position you have at the position for the "space" character. That should do it!

Yeah, kind of expected that, so sure thing I guess...