Leaderboard

Then the composer did their job correctly.

This might be frowned onto by tdm mappers/veterans, but I find it strange that it's considered ok to use text inside entities, which can then be found inside map files. That in general seems badly organised. Like for example with text decals: https://wiki.thedarkmod.com/index.php?title=Text_Decals_for_Signs_etc.#The_Decal Personally I think xdata could/should be used for all instances of text (except maybe darkmod.txt and subtitles), including readme files and GUI files. Or at least some kind of external text file. Could be something else, but the xdata format seems good and supported. So the sign text prefab could have a default xdata_contents spawnarg instead of gui_parm1 . Edit: Objective description text is also inside an entity inside the map file, but it could just as well be a reference to an xdata file. I posted about this before, here:

This is how i18n typically works in code: Developers write the strings in English (or their native language), but mark all the strings with a function/macro which identifies them for translation. In C++ this might be _("blah") or tr("blah") — something which is short and easy to write. A tool (which may be integrated into the build system), extracts all the strings marked for translation into a big list of translatable strings. This list is then provided to the translators, who do not need to be developers or compile the code themselves. They just create a translation for each listed string and send back a file in the appropriate format (which may or may not be created with the help of translation tools, perhaps with a GUI). At runtime, the code looks up each translatable string, finds the corresponding translated string in the chosen language, and shows the translated version. At no point do developers (who in this case would be mission authors) have to mess around with manually choosing string IDs. All they do is use the appropriate function/macro/syntax to mark particular strings as translatable. String IDs may be used internally but are completely invisible to developers. I suggest that any system that involves instructions like "search the list of known strings for a similar string" or "manually choose a string ID between 20000 and 89999 and then write it as #str_23456" are over-complicated, un-ergonomic and doomed to be largely ignored by mappers.

He's les stale croutons now

I don't like pumpkins, but fortunately we were not required to eat any. I ate the mushrooms though! It sounded like the pub goers were having a great time, stomping to the beat of the music - a cool and fitting soundtrack. +1 for the Canadian reference

Ill do better!

This appears to be the function which calculates the texture values for Q3 export: https://gitlab.com/orbweaver/DarkRadiant/-/blob/master/radiantcore/map/format/Quake3Utils.h?ref_type=heads#L56 It's largely based on legacy GtkRadiant code and means absolutely nothing to me.