Search the Community

I post for the first time since January with a detailed response about an important(ish) topic and I get a laugh reaction. In all seriousness though, if one doesn't like DRM they have to be careful posting nowadays since a lot of people have a lot of time invested in games and platforms with DRM of various sorts, and any issues you raise with the game/platform these people will take as personal attacks against themselves, even though it was never intended. Not so bad here, but reddit and Steam forums? Good God. Bruh we both live in Australia, it's not that bad here with regards to the authorities most of the time. I mean it does depend where you live (I'm in SA) but comparing our cops to those in the US is like using a cheat code.

Actually, I was rather facepalming than laughing. But, I guess it could be a good learning effect, which should teach you that you should first check your stuff, before blaming anyone else's work for problems on your end.

I don't know if I'd call it a necessity given places like GOG exist. I might tolerate some DRM so long as it's crackable or there's a plan in place to remove it at some point. I read somewhere that Denuvo has moved to a subscription model which has motivated publishers to remove it after a while once its value has diminished beyond a certain amount. I think this is the reason why games sometimes release an update that removes Denuvo after a while - most of the bulk purchases would have been made by that point so there's no value in continuing payments for it. Unfortunately it's taken a lifetime for me to accept that I have very little influence in most matters and ultimately the only decisions I can make are those for myself. If I wish to boycott a company or product or anyone that is doing something I disagree with, that is a personal decision and I cannot expect others to do the same. Even if it means your hobby or interest ends up going to shit because of the indifference of others, it sucks but all you can either do is navigate the shit or do something else. We must follow our own value systems, even when there's an incredible amount of money invested in an industry that is continually pressuring us to not do so (you MUST play this game, you MUST buy this console, you're missing out! FOMO, etc).

DRMs like that pose the problem, not DRMs in general. They're responsible for most stuff which doesn't work anymore here. Although I must say that that is really the vast minority. Most stuff is still working, even after 20 years. Ultimately, it's not like on Mac OS, where every OS update can break stuff, or the change of processor architecture once a decade Apple is so "famous" for, which renders ANY old software non-operable. Bunch of crazies. And their fans still throw money at everything they do.

Then you should probably install the proper driver... or look up where the setting you're looking for is located, because you probably just missed it... Or insult me some more while you keep using a massively outdated aa method rather than one of the key selling points of the RTX cards...

The Problem Readables are available in a wide range of TDM bitmap fonts. Unfortunately, the majority of these fonts lack non-ASCII glyphs for European languages, and it would be a prohibitively lengthy task to craft them. This is one of several translation hurdles. (Another is soliciting, organizing, and distributing the work of human translators; see “AI for Translations: An Exploration” for work on an alternative. This also promotes the use of meaningful alphanumeric #str_ IDs - possibly automatically generated – instead of traditional numeric.) A Proposed Solution Suppose that when a particular page of readable is shown, it is shown first is English, with the mapper-specified font (e.g., Camberic), and then, after a number of seconds, shown in the current user-selected language, with a different font (e.g., Stone), one that offers the needed diacritics? And with the translated font size scaled down to accommodate potentially more-lengthy translated strings? Both the English and translated text can be viewed in sequence. That opens the door to “quick and dirty” default translations, e.g., machine translation. In particular, the reader may sometimes be able to work-around any layout problems and sub-optimal translation by consulting the English text. (Nevertheless, default translations may sometimes miss subtle nuanced hints, so the ability to improve them with tweaked text is a necessity.) The Proposed Mechanics Recall that the game engine currently passes these values to a readable’s gui: gui::title gui::body With a multipage readables, the content of these parameters changes as pages are flipped. For clarity, it is proposed to replace them with: gui::titleEnglish gui::bodyEnglish gui::titleTranslated gui::bodyTranslated The latter 2 would be just like gui::title and gui::body, except that they would serve empty strings when the current language is English or there is no translation available in the current language (and so be used for gui code program logic, to suppress a transition). Observe that this behavior does not substitute an English string for a missing non-English string. Skip the remainder of this section if details are not of interest. Each stock readable .gui would need a one-time conversion to use them. Instead of the traditional 2 winDef overlays for text, there would be 4, corresponding to the 4 text-passing parameters just mentioned. This allows the translated text to fade in while the English text fades out, when an onTime event starts the transition (at 2 seconds in this example). Here is the fragment of .gui code that has been altered: Aspects of this Design – Transition from English The transition is timed, so no extra “Translate” button is shown, nor a hard-to-come-by hot key required. If you want to see the English again, you would briefly navigate away from the page to another, then return; or, if a single-page, close and re-open it. A simple implementation (as the code above and example below) uses a fixed, hard-coded time. Alternative Mechanism. At some cost to code clarity, it is probably possible to get by with just the 2 normal text-passing parameters (gui::title and gui::body) and their traditional 2 overlays, though additional variable(s) would be needed for tight time-synchronization between engine and gui; and overlapping fade-in/fade-out between English and translation would not be possible. Advanced Version. In the longer term, timing could be made more flexible, by passing it as parameter from the engine, e.g.: “gui::transitionTime” Where does this value come from? While it could somehow encoded into the .xd file by the mapper, I prefer a different approach. Have the engine calculate it from character or word count of the body, with user-specified globals for reading rate and min and max bounds, e.g.: sys_readablesWordsPerSecTransTime sys_readablesMinTransTime sys_readablesMaxTransTime A drawback of a timed transition is that additional reading time is needed to get to the translations, which may, with immobile readables, increase risk of discovery by guards. So having these additional user controls would let a user get to the translations faster, even skip the English entirely by setting bounds to zero. A Simulated Example – FM “readableTranslationFadeIn” In the absence of engine support for the 4 text-passing parameters, it is still possible to make an approximately-functional mockup using some hard coding. However, this prototype DOES NOT suppress the transition when the current language is English. That is, it shows (rather than prevents) an English-to-English transition with change of font & font-scale. TDM with the languages set to “Francais” (French). The first screen shot shows page 1 of a 3-page scroll, momentarily displayed in English with Camberic title and body. After a few seconds, it transitions to the second screen shot, in French in Stone font. With accents. While shown here as a scroll, this approach should be easily adaptable to books and sheets. About the Example’s Implementation The screen shots are from a prototype FM: readableTranslationFadeIn Notable files are: guis/readables/scrolls/scroll_calig_camberic.gui, a custom override of the standard Camberic scroll readable, with the translation transition mechanism from above, plus additional simulation fakery described below. strings/all.lang, a UTF-8 file containing 6 #str_ (2 per scroll page – title & body) in each language section. Only the [English] and [French] sections were implemented. The English example content was loosely derived from the St. Lucia FM. The English text (without #str_ structuring) was manually converted to UTF-8 French using Google Translate (website, not API). strings/english.lang & french.lang. These were generated from all.lang using my gen_lang_plus program to create the 8-bit “ANSI” versions as required, e.g., ISO-8859-15 encoding for French. xdata/readableTranslationFadeIn.xd, that contains the #str_IDs for the 3 scroll pages. Within scroll_calig_camberic, this simulation had this fakery: “gui::title” and “gui::body” were stand-ins for hypothetical parameters “gui::titleTranslated” and “gui::bodyTranslated”; The English text was hard-coded, and the appropriate content selected by actual parameter “gui::curPage”, to make up for missing hypothetical parameters “gui::titleEnglish” and “gui::bodyEnglish”. The READABLE_FADE_TIME is currently set to 2 seconds for testing. Probably 5-6 seconds would be better during game play. Aspects of the Design – Font Scaling As mentioned earlier, the translated font is scaled to make the text smaller than the original, to accommodate languages that need more room. A simple implementation (like in the example code) uses fixed values with “textscale”. So the textscale for the two Translated winDef overlays is smaller than for the 2 English winDef overlays. Specifically, in the example GUI code, the text scaling factors from the original Camberic readable were retained: textscale 0.4 // titleEnglish textscale 0.31 // bodyEnglish and supplemented by (with a different font, namely Stone): textscale 0.33 // titleTranslated textscale 0.24 // bodyTranslated The goal is to keep the rendered text smaller than the original English rendering for languages with more characters per sentence. These values, while hard-coded, will differ across readables (due to different starting fonts), and would need to be experimentally determined. But this treatment, with just a fixed scaling value that is independent of both text content and current language, is unlikely to be very satisfactory. Better ideas, needing additional engine modifications, will be considered in a follow-on post. Additional Considerations When Authoring the XD File. Recall that TDM is relatively inflexible when using #str_ within an .xd file. So this form will not work: "page1_body" : { "" "" "#str_fm_scroll_camberic_pg1_body_parish_inspection_excerpts" } Instead use "page1_body" : "#str_fm_scroll_camberic_pg1_body_parish_inspection_excerpts" With the 2 leading linebreaks moved into the #str content as leading \n\n. When Testing. If there is a mismatch between the TDM Language setting and the PC’s language setting (e.g., under Windows), then some characters may turn out wrong or indicated as missing (e.g., as boxes). The degree will vary by language, and is unlikely to be seen in the initial English render (because that’s almost all in ASCII, common to all the ISO encodings.) Even with such mismatches, the translation can be reviewed as to overall length and where linebreaks occur. Be aware that direct editing of *.lang files is not recommended, and could risk converting from a particular “ANSI” raw 8-bit encoding into “UTF-8”. Applying this Technique More Broadly. A few fonts have oddball glyphs for certain characters, e.g., a skull and crossbones in Treasure Map. This would require special handling during translation. For Briefings, Objectives, and Messages, similar approaches can be conceived. However, for each of these (and different from readables), only one particular font is routinely offered. And there are alternative designs to be considered. For instance, the English and Translated text could be shown simultaneously side-by-side in various ways, instead of sequentially. The Objectives have the additional complication that the font size is already user-adjustable.

If you want your settings to persist without worries, you can store your non-default settings in a separate cfg file, including your key binds. You can make an autoexec.cfg or autocommands.cfg (one or the other, not both), which will be automatically executed when the game starts. If you put your preferred settings in there, they'll always be left intact when you update the game, even if the update changes Darkmod.cfg or DarkmodKeybinds.cfg. You can also execute other cfg files from inside you autoexec.cfg with the "exec other_file.cfg" command. This is what my autoexec.cfg looks like (abbreviated): echo "--- LOADING AUTOEXEC CFG ---" seta sensitivity 5.5 seta pm_bobroll 0 seta tdm_music_volume -22.4 // seta com_maxFPS "70" seta com_maxFPS 120 seta con_fontSize 8 seta logFile 1 seta tdm_download_list_sort_by 1 seta tdm_download_list_sort_direction 1 seta tdm_mission_list_sort_direction 0 seta tdm_mission_list_title_style 0 bind HOME "exec gameplay" bind END "exec mapping" com_smp 1 tdm_player_wait_until_ready 0 // run other custom cfgs exec windowed_mode exec gfx exec mapping Some keybindings are a bit annoying to figure out, especially the "impulses". You have to change them in the game and then see what changed in the keybindings file, or something like that, so you learn which bind command corresponds to which ingame keybinding.

We don't care about your "liability". Slap a big fat disclaimer on it with the final update. Your online-only game runs on hardware, and is likely designed to be portable to prevent vendor lock-in (to AWS for example). You can provide what's needed for some random person to run it on their 96-core Threadripper or Ampere workstation.

I think you are right, i also never heard of any paid games (offline) that have been actively disabled yet, but it does not seem implausible to me. I bought the first version of the Quest VR headset. When it started out, still as Oculus, it was stated that no facebook account will be necessary. After a few years i had to create an account with facebook nonetheless, but then it was still separated as an oculus subaccount. Then after a few more years eventually i got the message that now i have to merge this account to be a regular Meta account or i will loose my library of completely offline and functioning games. They shipped the headset with a fully working gallery software that was able to display 360 spherical stereo images. The gallery program simply crashes on startup since in about 2 years down the line. Reviews left on the product page reported the same. Decrepit. They also shipped it with a small introductory game called Bogo. It was removed from the library in 2023 and well.. remotely disabled. These were 'free' - so what can you do - not even this proposition would defend against that i guess. I ask though if it were so hard to offer a chance to keep the library of completely offline games and opt-out of further updates? or maybe try an update and revert, keep a snapshot on an external storage. We can still do these on a Pc, but i fear without regulation it will last as long as the sanity of the next guys heading the industry. *Update* Just found out that Bogo was brought back to availability some time after its shutdown.

I just copy the files from old install to new install. However, I shouldn't recommend this in case there are new variables in 2.13 that will get missed? But you'd think they would get written to the files anyways. Not sure what to really recommend here, but that's what I do and I haven't had any issues.

A lot of questions, and a lot ifs and buts. And, that illustrates the problems with this thing. I doubt that anyone would want to use Windows 7 or Linux to make stuff work. Everybody wants stuff to work with the lates OS on their computers. Which just wouldn't work, when the games were never designed to run on it. And, again, it also denies the fact that software has a shelf-life, like everything. You can't magically keep things working. The best thing you can hope for is some modders modifying the game to work with modern hardware, and, that happens a lot, fortunately.

Inventory Item Results The AI results, generated in a flash, were successful overall. The desired output format was achieved, and the back translations detected very few problems. An example result (before alphabetic ordering), from [Italian]: "#str_fm_map_inv_key_sea_trunk" "Baule da mare" Sea chest "#str_fm_map_inv_key_galley" "Cucina di bordo" Ship’s galley "#str_fm_map_inv_key_mess" "Refettorio" Mess "#str_fm_map_inv_key_master_key" "Chìave maestra" Master key ... Caveats: A judgement of “overall success” is without ground-truthing by human translators. The back-translation uses the same AI as the forward-translation... loosely analogous to “grading its own paper”. Though told not to look at the original English when back-translating, is it cheating and lying? Revisions and Refinements Title Casing for Inventory Items. I should have explicitly prompted to generate this in the results. I manually corrected these (leaving separators like di, de, do, del in lower case), but a few cases required ChatGPT consultation to get the proper upper-case Unicode letter. Mess. Two translation needed revision, because they seemed to suggest an eating area of a much larger or luxurious ship: [German] "#str_fm_map_inv_key_mess" "Offiziersmesse" Officers’ mess [French] "#str_fm_map_inv_key_mess" "Salle à manger" Dining room Rather than rerun the whole translation, I just asked ChatGPT about these cases: On a small ship, what is the mess or eating area called in French? On a small ship, the eating area is typically called la cambuse or le carré, depending on the context: Le carré – This is the standard French nautical term for the crew's or officers’ mess (eating/living area) on a ship. It’s equivalent to the English term mess. Carré des officiers – officers' mess Carré de l’équipage – crew mess La cambuse – Often refers to the ship’s food storage or sometimes the galley (kitchen), but in some informal or small-vessel contexts, it can be used more broadly, though this is less precise for "mess." So for a small ship’s mess or dining area, the best and most nautical French term is le carré. Consequently, I just replaced "Salle à manger" with “Carré”. Likewise, in German, simply “Messe”. Master Key. This was back-translated as “Main key” in 6 of the languages, which I guess is OK. In Air Pocket, a Master Key (entity name key_master) was left in the blue room, if needed for a debugging build; inaccessible otherwise. Arguably, it should not be translated at all. So I’ll comment those non-English lines out. (“Master key” is not part of TDM’s base strings?) Captain’s – Odd Punctuation and Perhaps Compound Unicode. The German translation of “Captain’s Cabin” had odd punctuation: "Kapitan­s¬kajüte" (and some evidence of a Unicode “combining character”). I did a separate follow up to ChatGPT, and revised to drop the punctuation and add an umlaut over the 'a': Kapitänskajüte. Another German use of “Captain’s” was similarly revised. German reportedly never uses apostrophe for possessive form. Captain’s – Title versus Name. There was one case in [Danish] where the word “Captain’s” was not translated, as if it was a person’s name. (Also, reportedly, Danish does not generally use apostrophes for possessives; there are exceptions, but doesn’t seem to apply here.) State of All.Lang So Far Starting from a temporary file into which I pasted the raw AI results (with [<language>] headers added), I fabricated all.lang by: Making sure it had Unix line ending, not CRLF. (In Notepad++, Edit/EOL Conversion/Unix). Begin it with a first-draft preamble comment, heavily adapted from TDM’s all.lang preamble. Following that, a line with just an opening bracket. And a closing bracket line at end of file. Making the handful of translation corrections mentioned above. Change the casing to Title Case. (I didn’t bother changing the back-translation’s case.) Tagging the back-translations with “//bt:”, so they are denoted and if need be can be quickly stripped out with an editor. (If subsequent revision is manually applied, the delimiter will also be altered; preamble will provide guidance.) Lessons Learned So Far Improvements to Prompting... Specify that the FM’s ship is small. Specify that “Captain” is a title, not a person’s name. (Hmm, there’s some shouldered names, not touched by I18N.pl, that maybe should be partially-translated too, with titles like “First Mate Logan”.) For inventory items (and likely readables titles), ask the AI to make the output in Title Case. Tell the AI not to generate Unicode combining characters. Ask the AI to add a special delimiter “ //bt: “ before the back-translation. To the extent possible, convert any directional punctuation (apostrophes, single quotes, double quotes) to non-directional, to comply with TDM font limitations. Since it seems to give better results if you ask about one specific item (like “mess” in French), maybe it’s optimizing for speed instead of accuracy. Ask it to take more time? ChatGPT translation seems to have problems with possessive forms... or at least those problems are more-easily spotted during review. Speculation: maybe one cause of this is that I didn’t specify which country or regional dialect of a language to use. Perhaps a prompt to “prefer the form of language spoken in a language’s originating country, within or adjoining Europe.” Concerns about Translation Length... The results are generally short, but in-game will some of them prove to be too long? Traditionally, inventory names are limited to 2 lines, with “\n” needing to be inserted. This will need to be tested eventually.

Yes, if you add: Required TDM Version: 2.13 To darkmod.txt is should warn players: https://wiki.thedarkmod.com/index.php?title=Packaging_Your_Mission Most authors don’t do it since many missions are still playable with broken assets and they don’t want to exclude folks who can’t upgrade (etc). Let me know and I’ll update the darkmod.txt in the mission database.

If value the games you buy, you should sign one of these petitions - SIGN THE EU CITIZENS INITIATIVE: - https://eci.ec.europa.eu/045/public/#/screen/home SIGN THE UK PETITION: - https://petition.parliament.uk/petitions/702074/ EU petition is @ 826K- needs to hit 1'000'000 UK petition is @ 97K - needs to hit 100,000 A video from Gamers Nexus on the subject - https://www.youtube.com/watch?v=p9ahH6HrtTc ----------------------------------------------------------------------------------------------------- EU: This initiative calls to require publishers that sell or license videogames to consumers in the European Union (or related features and assets sold for videogames they operate) to leave said videogames in a functional (playable) state. Specifically, the initiative seeks to prevent the remote disabling of videogames by the publishers, before providing reasonable means to continue functioning of said videogames without the involvement from the side of the publisher. UK: The government should update consumer law to prohibit publishers from disabling video games (and related game assets / features) they have already sold without recourse for customers to retain or repair them. We seek this as a statutory consumer right.

@grodenglaive Actually, funny story... originally it would have been possible, but pathfinding caused some horrific lag if he couldn't open that door during his patrol, so I had to give him the can_unlock spawnarg. Actually, the lag issue might not be so bad since the map got optimized, I haven't tested that. Maybe I ought to consider that for an update.

I know sometimes in the past I've misconfigured DR's File/"Game/Project Setting..."/ and gotten mystery problems similar to what you describe.

That's correct but many people just use the in-game mission downloader to check for new stuff without even looking at the forums, which is what I did. In the past a lot of missions that required a newer version of the game executable and assets would tell you this when you tried to start them up. I was just reporting on this and that you don't need to reinstall, just update via tdm_updater if you find this issue.

I think this is a great mission, after having played it. Wanted to also post and say that I initially had the same issue as a user on the first page with the black untextured floors and some walls. I think the issue is the mission doesn't check the version of the game that's being played--I had 2.12 installed and it started the mission without asking me to update. After running tdm_installer and forcing a file analysis and then updating to 2.13 not only did the pure black texture issues go away but the slight framerate issues I was having in some of the outdoor areas disappeared as well.

@snatcher made a new install for TDM2.13 added your mod-V5 activated : Forward Lantern / Shadow marks ( and added the "z_tdm_loot_stealth_stats" into it ) Yours : the Forward lantern isn´t here anyones ? : Inventory Grid - to F2 does not show up like messaged before (old appearance, no sorting)

I just noticed you included a / in there, because Godot uses / for all paths, and all path validity checks just failed when I was testing the code. I'm presuming I don't need to worry about it, as the zip file will probably always contain the compatible one, and it may be ok to not check for that character. But I'm a bit confused at how / causes problems, though, so I'm not sure what to think. The python version uses \ instead (I think), which may be why I never noticed this before, but maybe that's because I'm on windows. If that's the case, then it will misreport every path as invalid on linux.

Hrm I wasn't able to type on *after* the spoiler and accidentally already submitted the reply.. (Does this forum somewhere have a raw mode where you type text with tags around them or something instead of this broken WYSIWYG editor?) Anyway, what I was gonna add: This was a great mission and I already played Away1 - I'm really looking forward to Away2, want to see how the story goes on

This might be a thing we can do with modding! I went digging through the source again because this was hanging in the back of my mind, and there is no actual use of the cvars that are defined in the c++ code for how the player reacts to the flashbomb. Seeing that, I followed that cvar through the scripts in my TDM install instead. As it turns out, the white flash that occurs when you flash yourself is defined as a gui element in tdm_gui01.pk4\guis\playertools\flashbomb.gui. Most of the lines of this script are defining color values to fade from and to, as vector4's that presumably represent RGBA values. Everywhere in that script that says something along the lines of transition backcolor "1 1 1 1" "0 0 0 0" "4000"; , "1 1 1 1" represents fullbright, fully opaque white. Changing that to "0 0 0 1" would be fully opaque black, and doing that across the whole script might just solve the problem. The going-all-the-way solution would be to change this color value to a cvar that you can set through a menu accessibility option, but it'd probably be simpler to mod it out in the shorter term

Im ok with it but it is getting a bit long in the teeth for a ryzen 5900x even the low cost ryzen models have plenty power to drive this card. I would have used my 3070 instead but with 8gb im running into some rather annoying texture loading problems. So a 16gb model will be next project but the lower end while having plenty vram are just not worth upgrading to with such a small percentage. Guess ill donate a kidney for a 9070 or 5070

Hi! I play The Dark Mod on Linux and I prefer to use a controller for most games, so for games that lack native support I use a program called AntiMicroX to map gamepad buttons from my Xbox One controller to keyboard keys. It works pretty well, and I've enjoyed using an identical setup for Thief, Thief 2, and TDM. I was pretty excited when TDM added native gamepad support, but for reasons I still prefer my setup with AntiMicroX. So I completely cleared my "DarkmodPadbinds.cfg", threw in"unbindPad" to completely disable the native controller bindings, and everything was fine. Either that was a fluke, or one of the most recent updates changed something, because I'm now finding that "unbindPad" no longer unbinds the control sticks in TDM. I can confirm this by running TDM with my config file and without running AntiMicroX; with a controller plugged in, the control stick bindings still function both on the menu and during gameplay. Some of the button bindings also still function in the menu. So my questions are: 1) Is it possible to completely unbind the gamepad (including the control sticks) in DarkmodPadbinds.cfg using "unbindPad" or another command? 2) Is it possible to add rebinding of the control sticks in a future update? (I realize this is probably a lot more work, but it would be nice to have!) Thanks for all the effort you guys put into this game, I've been enjoying it for many years.

Another update to the saga of leak complaints: Sometimes things which didn't leak before start leaking all of a sudden after a few saves. I swear I can't possibly be moving the walls and leaving a gap in the corner- if I were the pointfile would be going there, but it goes straight through, even after I practically build a Matryoshka around the whole map. It's like some entities just become cursed. I've even had them copied and pasted into other maps and leak or not leak according to chance. And now, on to my real question. Is it possible with the tools already available to do a scripted fade of an NPC's opacity / alpha ? What about overlaying a color on an NPC, making them blue or charcoal colored or whatever. Thanks