All Activity

The translation pack has the german string in the base pack rather than in the fm subfolder. I will fix it in the mission database. Edit: Fixed in the mission db Edit 2: Nope. Not exactly fixed. It seems that lang files in the mission string folder need to be "complete" because they fully override the core strings. If I am correct, this was broken in 2.11 when we permitted in-file overrides of core files in missions. Edit 3: Still broken in 2.10, rolling back to 2.07 Edit 4: Still broken in 2.07. Something has gotta be wrong with the translation specific to this mission. Edit 5: The core mission XD files don't use the strings so nothing happens if the lang files are in the strings/fm subfolder. Probably means that the translation packs "never worked" for many missions unless impacted players sought out special editions of the missions on Tels' server. What a mess. Fuzzy recollection time: I think Tels was trying to push the team to mass convert all missions to move XD data into strings/fm/english.lang but nobody wanted to broach it and even mission authors weren't happy about this way of handling things. If the translation pack takes precedence, the best way forward is to include the converted XD file into it. Testing... Edit 6: Couldn't get the XD update to work, so I decided to checkout Darkfate's version. It works flawlessly. I copied their pack into the standard translation pack and the added string files for the other languages worked as well. Darkfate's packs include map files so I'll need to study whether we can avoid that. Otherwise we are basically doubling our mission db or "damaging" our hosted versions to make them translatable. Since this mission is so small and probably will never be edited again we can probably use darkfate's version as-is.

Then the composer did their job correctly.

It very well could be from another TDM mission, but it felt very reminiscent of Thief 3. It felt like a core memory when I heard it.

Oops, sorry, I forgot about those. I'll work on that soon.

At the end of darkmod.cfg. like what xlm posted. or do a "seta" in the console, like "seta mysetting value" According this site, you can also to change some def files. https://doom.fandom.com/wiki/Doom_3 (See header "difficulty) A link to Info about A.I (what xlm posted earlier) https://wiki.thedarkmod.com/index.php?title=Cvars_in_The_Dark_Mod#AI

No disagreement on this but one clarification: You can use characters instead of numbers, eg. #str_mycrazyspeech . This was discovered around 2.10 but is not widely known.

Everything SHOULD be copyright free, so no it shouldn't be from Thief 3

I was wondering when you plan to include these subtitles + the ones I made for The Heart of Saint Mattis . It didn't work out that way, but still impressive. 5 missions in 6 years.

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 .

Thanks for playing! Yeah, I was real lucky to find that track on freesounds. It was super fitting and definitely helped tie the whole thing together

Absolutely loved this mission, great job. I immediately recognized the minimal piano key track once you get inside- is that from Thief 3? I want to say it's from the seaside manor mission in T3, but maybe in another part of that game? Let me know, now I'm super curious. This is one of my favorite missions recently!

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.

I remember I was surprised it couldn't run Invisible, Inc. properly. But I'll give it a try later.

He's les stale croutons now

BTW, the Perl script I18N.pl expects only an integer value after "#str_". Could be modified (or deprecated).

Would be interesting to see what happens but Intel GMA 950 has "No Hardware T&L" and only supports OpenGL 2.0. If you are willing to install TDM 2.06 and try" r_useGLSL 0" then we would at least know whether such hardware can run the latest OpenGL 2.0 compliant TDM.

Did @LePetit_Baguette_69 die by baking in the oven for too long after his first post?

I guess I could try to make it run on this: https://www.notebookcheck.nl/Fujitsu-Siemens-Lifebook-P1620.8269.0.html Not sure if an Intel GMA 950 will be enough..

We get it, you don't like the mission. No need to stamp it into the ground. This is total nonsense. There are much larger missions than this with more story and they get good reviews.

That is one reason. That is 2 more reasons. You'd like a script that, if you had to run it again, would "do the right thing". Unfortunately, that right thing is very hard to program, and needs IMHO to be both bidirectional and with a better method of string version control, to support both the FM author's updates and potentially multiple translators. Yes, another reason. Currently, it is my understanding that updating an FM (from the non-converted copy) and running the conversion script again causes mis-alignment of newly-generated #str values and previous .lang #str values. Another important cause of "nobody is making these language packs" is that Dark Radiant at best tolerates converted FMs. It offers no special translation support, as expressed in this code comment: "...we don't have any support for parsing the mod-specific translation data...." [from DR's DifficultySettingsManager.cpp]. That's where we are now. So officially give up on FM Western translations? Or improve the #str system to make it work for everyone? Or invent a new system? A new system. What would that look like to the FM author? To a non-author translator

Well if you go to the mission downloader again, it will show a new update for the mission, which is the translation pack. If I select Germain language and activate The Outpost, TDM will not start anymore (2.13 dev)

Then your experience is different than mine. I just recently downloaded a very old mission, The Outpost, that is listed as having German, French, Italian translations, to test out language capabilities. It was not converted (no "#str" found in .map file). Nor was there a language pack included (at least not from thedarkmod downloader).

I agree; a very tasty little morsel of a mission.

As of 09e5ec1cae16b8350097fc97839de64cf96c4e88 I have changed the logic to write spawnargs if EITHER the speaker radii are different from the shader default, OR if there were min/max spawnargs to begin with. Spawnargs will no longer be created (or deleted) as a result of a speaker move, but will appear and change if the speaker is resized, which I assume is closer to the expected behaviour.

If all written strings were kept in XD files, the process would be easier. We shouldn't need map edits for this. The current system makes mission updates a real problem to the point that only long dormant missions are viable for translation.