![[de]](/mwf/flags/de.png "Germany")
Why would anyone change their CR masterserver to that of OpenClonk? It doesn't make sense.
To get attention in this forum!
Blacklist their key and burn their barn, I say!
And it appears that OC dies if it tries to display a list of network games, that include CR scens with Umlaute. I can't deal with that. :(
For reference: the masterserver delivers the unmodified CR reference with the usual \000 octed-escaped special characters. Has this behaviour maybe been modified in OC?
My guess is that this triggers an assertion (
But this isn't a reason to forbid CR references (instead it's a reason to sanitize the received references).
IsValidUtf8) in the font rendering code because we forgot to reject invalid UTF-8 strings.But this isn't a reason to forbid CR references (instead it's a reason to sanitize the received references).
Can't we just drop that assertion and let the font rendering code ignore any invalid characters?There are so many other inputs (like chat, player/clonk names, script, almost every place that does string formatting, etc.) that would have to be checked. I think it's better if we just define any sequence of characters as valid and some are just not rendered.
I think that assertion is fine in theory, and the actual problem is that release builds don't disable assertions. After all, this isn't technically valid input to the DrawText routine (since it expects UTF-8 and gets some other random assortment of bytes).
To have the assertions enabled in the release build will help us find errors in our game better though. Perhaps we could convert non-critical assertions into error logs.
Some assertions might add a performance overhead, by the way. If they ever pop up in a profiler run, it might be advantageous to create two types of assertions for release and for debug builds.
I think we'd still be better of by adding some always-fatal assertion and turn the standard assertion in release-builds off, or automatically convert them into LogSilent. This is very likely not the only assertion that was written with the assumption that assertions are turned off in release builds. After all, we had them turned off in CR.
Until there is no way to display these invalid letters, the easiest way would be to replace them with question marks (or other signs). Then words where some letters are missing are almost readable again and it helps debuggers to guess which letters are invalid.
U+FFFD REPLACEMENT CHARACTER
Incidentally, that's already what GetNextUTF8Character returns if it encounters invalid bytes.
Incidentally, that's already what GetNextUTF8Character returns if it encounters invalid bytes.
We actually have a function that will make those CR references work just fine:StdStrBuf::EnsureUnicode() // // Checks wether the contents are valid UTF-8, and if not, convert them from windows-1252 to UTF-8.So its a one-line fix, someone just has to search the code for the right place to insert it.
Not revalidating everything every time we draw text might be a premature optimization, but validating things when they first enter the program feels cleaner. In other words, I meant the place where the code reads the data from the masterserver answer into the internal data structures representing that answer.
What do you mean by "it feels cleaner"? Of course we might want to validate some strings so Umlauts in the wrong charset are converted, etc. But I'd still say a clean solution would be if a text drawing routine doesn't crash the engine no matter what text you hand it.
> What do you mean by "it feels cleaner"?
There's less invalid data in the engine. Cleaning up early feels cleaner than cleaning up late.
And of course we shouldn't crash on invalid text data. Except in debug builds, where crashing is often the most convenient way to find bugs.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
