Search the Community

Ah, pity I wasn't reading the forums back in February. I'm fond of that game, along with Bugbear's other early title, Rally Trophy. I was never too good at FlatOut, but it was always a hoot to play.

Yes, definitely needs to be distinguishable. Clear glass with light bulb visible would be the best way: You know that if you see clear glass and the bulb inside you can shoot it. The distinction isn't always possible to make without first trying it out though... paintings are the best example, you always need to get close to see if a painting can be looted. As for players learning about this, we should add those lights to the tutorial level where the basics of TDM are taught: In one of the hallways we'd have examples with the message "solid lights can't be shot, but ones with fragile glass and a lightbulb can be broken with broadhead arrows", the player is given arrows and can shoot at different lamps to compare. As for explosive barrels those would be cool to have too! In their case they should already be doable with a script, just that no one's ever done them: Remove the barrel, spawn the same explosion as the fire arrow or mine, and some temporary lasting physical debris if possible. Breakable lights would need support added to the builtin spawnfunc.

And making it possible for the new electric lights to be broken adds a psychological problem: how will players know that they are breakable if in 99% missions they are not? Recall lootable paintings and frob-extinguishable unmoveable candles.

It's okay! I'm down with any option hence why I asked. But I agree: Most players would likely not approve of such a change being done retroactively and affecting all old FM's, so it would likely be best as a derivative entity for mappers to use in the future based on new or existing lamps that can provide one. In any case it would likely require engine changes, not something you can currently do with a script: Lights already use their own hardcoded script classname which can't be overridden. Even if it weren't for that I don't think there's a way to intercept broadhead arrow collisions and check what kind of surface they hit, even with the Stim / Response system. There should probably be two new spawnargs: A breakable boolean enabling the feature on an entity, and a skin_broken to specify the skin used when a light was smashed.

As someone who has been playing TDM since it went standalone all those years ago, I was skeptical about the new frob until I gave it a try to see how it's handled in 2.12. It's really intuitive. Yeah, old time players are used to the old frob + use mechanic, and there was nothing wrong or confusing about it IMO, but the new frob is so easy to get into there should be no problem for old-timers. So, from my perspective, it's a good change. It takes away nothing from the players and gives them an easy-to-get-into mechanic that is simple to use. If such a small, simple change brings in more players, even better.

I just added (in-game) a background color to the rectangle of the "Acquired" message for better reference. I think you better let it be Some players might make the light-gem a little smaller or larger and these players have been serviced. Players with tiny or huge HUD elements are on their own (and they know it!)

I know of no reason why it wouldn't - the xray glasses are really the only thing that does any kind of screen effect. There is no FOV slider in the game so it was not tested admittedly. I am not recalling anything really that interacts with the players inventory directly in the mission. Dropping the glasses with "Drop Inv. Item" and reacquiring them doesn't restore the item to the players inventory either I am guessing?

Thank you. I see two different models: Hearing Impaired (HI) and Hearing Unimpaired (HU). The HI model includes low-hearing, deaf, and players with audio turned off for which all sounds are relevant: Plot (key conversations, special effects such as footsteps upstairs...) Surroundings (generic barks, doors...) Environment (machinery, thunders...) You somehow have to let players know how an event (sound) relates to them and their actions. I understand italics and colors are not available so you probably have to use brackets, in example, for anything that is of no concern to the player (but still relevant). You then have to let players know where sounds are coming from and it seems this is going in a good direction (congrats). A different story is how to make HI players know how much noise they are making... The HU model would be for: Players for whom English is not native Translations for obscure ai dialects or accents Support for bad audio or recordings I think we don't need effects in this model, players can hear effects already. I have a question at this point, what happens if a key conversation and general barks take place at the same time?

Yes, I've been working with a mapper who ardently adheres to the principle that only moonfacing windows should cast moonrays indoors (so about 1/4 to 1/2 of all windows), even though this is a powerful tool for creating an atmosphere and for maintaining some gameplay challenge. I found that this approach often ended in scenes that had only dim and uniform ambient_world lighting, which meant players couldn't really appreciate many of the details. Something I've seen in things like Dishonored is the use of sourceless lights to add highlights to scenes that otherwise contain no lit lights. That could be an especially viable approach in a mission like this which has a haunted theme.

Well, let's explore this a bit. How can this be solved? Currently, creeping overrides running (like you said). Here are a couple issues or considerations: What about players who want to keep the fine control of toggling each one independently? Perhaps some players want to go from creeping to running. At the moment, the code is written in such a way (due to its Doom 3 history) that toggling creep can set the toggled run state, but toggling run cannot set the toggled creep state. The toggle creep key can set the toggled run state to walk but only once. If the player presses the toggle run key again, it will toggle without regard to the toggled creep state. Fixing this would require a lot of code rewriting. Brainstorming: It almost sounds like increase and decrease speed keys are desired. Run key to go from creep to walk and from walk to run. Creep key to go from run to walk and from walk to creep. If you're curious to give this a try, here's a Linux test build that matches beta212-05 (rev 16950-10635) with the following change: The toggle creep key sets the toggled run state to walk but only once. If the player presses the toggle run key again, it will toggle without regard to the toggled creep state. https://drive.google.com/file/d/1osTCQRf7LQ5wPvhGl2uRU4NcFnJPEu9_/view?usp=sharing

I though something similar and suggested adding objectives to the Training Mission. That would help introduce some linearity into the mission and also suggest tasks to players, where the objectives are listed in order of increasing level of difficulty.

@snatcher I understand that when you feel your work doesn't live up to your goals that you don't want it out in the wild advertising your own perceived shortcomings but that leads to a troubling dilemma of authors who are never satisfied with their work offering fleeting access to their in-progress designs then rescinding them or allowing them to be lost. When I was a member of Doom3world forums, I would often see members do interesting experiments and sometimes that work would languish until someone new would examine it and pickup the torch. This seemed like a perfectly viable system until Doom3world was killed by spambots and countless projects and conceptual works were lost. I guess what I am trying to say is that mods don't need to be perfect to be valuable. If they contain some grain of a useable feature they might be adapted by mission authors in custom scenarios. They might offer instructive details that others trying to achieve the same results can examine. It would be great if known compelling works were kept somewhere safe other than via forum attachments and temporary file sharing sites. I suppose we used to collect such things in our internal SVN for safe keeping but even that isn't always viable. If folks would rather not post beta or incomplete mods to TDM's Moddb page, perhaps they would consider creating their own Moddb page or allow them to be added to my page for safe keeping. Please don't look at this as some sort of pressure campaign or anything. I fully understand anyone not willing to put their name next to something they aren't fully happy with. As a general proviso, ( if possible \ permitted ) I just want to prevent the loss of some valuable investigations and formative works. The end of Doom3world was a digital apocalypse similar to the death of photobucket. It is one of my greatest fears that TDM will become a digital memory with only the skeletons of old forum threads at the wayback archive site.

Congrats on the release! Remember to check ThiefGuild as well as the DarkFate forums (via Google Translate) for additional feedback.

Hello sneaksie taffers! I'm very pleased to release a new map, named Down and Out on Newford Road. Our kleptomaniac protagonist has found himself without his gear after a job gone wrong and is now stuck in a strange part of town with few friends to call on. It's a smallish-to-medium city exploration map with several intricate parts to deal with. In keeping with the "connections" theme there are usually multiple ways in and out of the various City sections. This is a Christmas Connections contest entry. For my connections to previous missions I have chosen two of the oldest missions in the archive: The silly Builders from the Outpost north of Bridgeport are making another attempt to manufacture a golden holy symbol. Has the Bishop learned his lesson from last time? ...because the one man still willing to talk to you wants you to steal it before he'll help you out. This contact is none other than Hamill, the fence from the first FM of them all. Thieves with a talent for exploration and an eye for hidden secrets might come across a sneaksie reference to my first mission The Factory Heist. Here and there are also bits of foreshadowing for my upcoming mission, tentatively called A House Call. And of course I had to work in a tribute to the greatly missed Grayman, also findable by players with a passion for discovering secret areas. ---- ---- This mission would be much uglier, buggier, disorganised, and z-fightier without my kind beta testers: ate0ate, datiswous, JackFarmer, and Kingsal. There were also useful comments from Dragofer, wesp5, and madtaffer. I am very grateful to them for their hard work and attention to detail. ---- Here is the link to the mission: Down and Out on Newford Road --(!!TDM 2.10 v 8 BETA REQUIRED!!)-- I'm also including some promo shots for the downloader: Promos ---- Enjoy and thanks for playing!

Just curious, based on this discussion: http://forums.thedarkmod.com/topic/19239-soft-r-gamma/?p=427350

If the "mission fails as soon as stealth score turns non-zero," that would not be good for ghost players. They might need to find out "how" they failed and experiment to avoid alerting guards. They might need to take those score points as a "bust". They might need to take those score points to complete an objective. Then, mission authors would need to encode exceptions into their missions, which would be a lot of work (if they decide to do it at all). However, part of what makes ghosting challenging and fun is when mission authors do not create their missions with ghosting in mind. Please see: Official Ghosting Rules: https://www.ttlg.com/forums/showthread.php?t=148523 Writing code for these rules would be a huge undertaking. Ghost Rules Discussion: https://www.ttlg.com/forums/showthread.php?t=148487 Creating an official mode could alienate these dedicated ghost players, because it would clash with what is considered ghosting in the community. Including the Stealth Stat Tool mod in the official release would be more useful. Or, making the audible alert states of guards quick and easy to recognize could help as well. For these reasons, I don't agree with an official "Ghost" mode. If the dev team were to do it, we should consult with @Klatremus so we get it 100% correct or not pursue it at all. (This ghosting bit should probably be in its own thread.)

(I apologize for the odd poll question layout. I wasn't able to add five yes-no questions, because polls are limited to three questions.) Hi everyone, I've recently been working on some patches for issues that I've read about from players on the TDM and TTLG forums — and Discord. My goal is to make it as easy as possible for players, especially new players and those who need usability/accessibility options, to find what they need in order to have a better TDM experience. I've already written the GUI and game engine code for these settings, which I've been using in my personal build. The reason for this poll and discussion is to both guide the finalization of my work and collect data to help inform the dev team. Which patches I submit depend on the outcome of this poll, discussion, and what the dev team agrees to accept. Once decided, I can coordinate with the dev team. I've attached screenshots of what the new settings menu would look like if all of the settings are accepted. Below, I have detailed each menu setting, so you can have an easier time understanding each one. Very important to keep in mind: None of these settings change TDM default behavior. They are all opt-in. If you are already happy with the behavior of 2.10, 2.11, etc. and these menu settings are accepted, nothing will change for you. Rename "Always Run" to "Run Mode" with options "None, Always, Toggle" After 2.11 was released, @i30817 requested that "toggle run" be added to the settings menu. Its cvar is already in TDM as "in_toggleRun" (same as Doom 3). I propose renaming the "Always Run" setting to "Run Mode" with options: "None", "Always", and "Toggle". None = in_alwaysRun 0; in_toggleRun 0 Always = in_alwaysRun 1; in_toggleRun 0 Toggle = in_alwaysRun 0; in_toggleRun 1 Show Blackjack Helper @Wellingtoncrab suggested that the new blackjack helper be added to the settings menu. Its cvar was added to 2.11 as "tdm_blackjack_indicate". More info: It's the new blackjack helper added to 2.11. When the game detects that the blackjack can be used for a successful hit or KO, the blackjack will rise slightly. I propose a "Yes/No" setting for this. Slider for "View: Head Bob" @ChronA requested a way to disable head bobbing, because a viewer watching him play was having severe motion sickness. Also, there was a bug in TDM that made setting the head bob in the console not stick after loading a saved game. (Even with 2.11, if a mission overrides the "tdm_player_thief.def" file and sets "pm_bobroll", "pm_bobpitch", "pm_bobup", and other cvars, it will override player preferences.) As far back as 2008, players have had trouble setting head bob. Another one from 2018. At the end of 2022, @Shadowex3 registered just to voice the need for a way to control head bob. I propose that a slider be added to adjust the amount of head bob. This would use a new "pm_headbob_mod" cvar with a value between 0.0 and 1.0 (default 1.0, no change). The "pm_headbob_mod" would be a multiplier for "pm_bobroll", "pm_bobpitch", and "pm_bobup". The advantage to this approach is that missions like Volta 2 and Hazard Pay would not need to adjust their "tdm_player_thief.def" files for head bob to work properly. And, the player can still adjust "pm_bobroll", "pm_bobpitch", and "pm_bobup" as they like. Slider for "View: Mantle Roll" This is similar to head bob for those who are sensitive to motion. Its cvar was added to 2.11 as "pm_mantle_roll_mod". A Thief player on Discord said, "2.11 will have a cvar to tune down the mantling animation at last." I propose that a slider be added for "pm_mantle_roll_mod". Auto-Search Bodies @Zaratul requested the "auto-search bodies" feature from Thief 1 & 2. Its cvar was added to 2.12 dev16783-10307 as "tdm_autosearch_bodies". I did a poll on the a Thief Discord server and roughly 20% of players there use the Thief auto-search bodies feature. I propose a menu setting for this, so that players coming from Thief 1 & 2 can easily find it.

A couple more: https://forums.thedarkmod.com/index.php?/topic/21739-resolved-allow-mantling-while-carrying-a-body/ https://forums.thedarkmod.com/index.php?/topic/22211-feature-proposal-new-lean-for-tdm-212/ https://forums.thedarkmod.com/index.php?/topic/22198-feature-proposal-frob-to-use-world-item/ https://forums.thedarkmod.com/index.php?/topic/22249-212-auto-search-bodies/

Ever since I worked on "Chalice of Kings" with Bikerdude, I have wanted to get flame particles with new particle glares into the core mod. My reasoning was that the candles have glares and the un-glared torches look mismatched. This proposal was met with mixed reactions, so (knowing the history of TDM feature proposals...) I have created a technical demo. You may download it here: zzz_flameglare.pk4.txt (fixed) Just rename without the .txt extension at the end and place it in your Darkmod directory. Here are some screens. Using particles for this is probably the wrong way to go now that Duzenko has an emissive light feature in his branch: http://forums.thedarkmod.com/topic/19659-feature-request-emissive-materialsvolumetric-lights/

I would like to make sure we are on track to solve the issues at hand. Is there agreement that new players struggle and often quit playing TDM due to its current control scheme? Note the player complaints on the first page. Is there agreement on this proposal's main objective? Make TDM's "frob" and "use" interactions simpler for new players while also improving it for longtime players. I should point out that "improving it for longtime players" does not mean that every single longtime player will get a new control scheme that they are satisfied with. They might have to continue to use the "TDM 2.11" control scheme or learn the new one, even though they don't entirely agree with it. Again, the main objective is to "make TDM's frob and use interactions simpler for new players." Is there agreement that the following issues need to be solved? How can the control scheme be made less cumbersome? How can bodies be shouldered without first dragging them? How can candles be extinguished and lanterns toggled off/on without first picking them up? How can so much key pressing and mouse clicking (currently in TDM 2.11) be eliminated? @stgatilov Are you in agreement with this proposal's main objectives? Even if you disagree with long-press frob, is it ok to include long-press frob in 2.12 dev if players want it?

The "external argument about exact duration" is not removed with double click. There is a setting in OS preferences for setting double-click speed, is there not? The challenge of setting the exact duration is the same for both long-press and double-click frob. Therefore, the confusion is not removed with double click. I tuned the long-press frob to be somewhere between "unintentional long-press frob" and "it being too sluggish." Early player feedback guided the current default value of 200ms -- it was originally 300ms. During more play testing, if players are having trouble, the default can be increased and tested. We need to follow the data from actual play testing. The player can adjust the tdm_frobhold_delay cvar to their liking as well. It's more likely that a player will hold frob while moving an item, because for most items, nothing different or bad happens. It's less likely that a player will unintentionally double-click frob an item during pick up, because they know that would cause them to drop it. Therefore, players are more likely to discover long-press frob to extinguish than double-click frob to extinguish, which is a good thing. We want the player to discover it (if they didn't read the manual or play the tutorial mission). Also, long-press frob is used in other games, such as Fallout 4. Getting double-click frob to extinguish to work well along with drop item would be troublesome, because there would always be a double-click delay before a single-click drop initiates. Long-press frob does not have a drop issue, because the player can long-press frob until they see the candle extinguish or quick-press frob to instantly drop it. To be clear, long-press frob also "does not change existing controls, only adds new meaning for" a longer frob press. This long-press frob proposal has already been play tested and agreed to be a good control scheme by several players. Double-click frob would need new code written, would need to be play tested, and would need to be fine tuned based on player feedback. Another rewrite of the code would be a distraction and may not bring us closer to the goal of "providing a better experience for new players as well as longtime players," especially since one has already been found and proven: long-press frob. For longtime players who are not satisfied with this new control scheme, "tdm_frobhold_delay 0" restores TDM 2.11 behavior. After 7 months of player research, code experiments, early player feedback, adjustments, rewriting code, and more player feedback, I believe long-press frob is good enough, given all of the compromises, imperfections, and its iterative design. It solves the problems stated in the proposal on the first page, and its design goals are met.

Author Note: This is a brand new mission and a new entry into the accountant series. There are some different than usual puzzles in this FM, so if you find yourself stuck try to think about your pathway forward in a logical manner. And if you're still having troubles then pop by this thread and ask (preferably with spoiler tags). This FM is brand new and serves as the first installment in The Accountant series, a few years back there was a small prologue style mission released however I felt that it did not represent The Accountant series so I decided to go back to the drawing board and do a whole new mission that's larger, has a better level design and has a story that lines up closer to what I plan to do with the accountant series. The mission is medium sized and you can expect between 30-90 minutes to complete it depending on your playstyle. Beta Testers Captain Cleveland Crowind Kingsal PukeyBee Skacky SquadaFroinx Voice Actors AndrosTheOxen Epifire Goldwell Stevenpfortune Yandros Custom assets Airship Ballet Bentraxx Bob Necro Dragofer DrKubiac Epifire Kingsal MalachiAD Sotha Springheel SquadaFroinx Available via in-game downloader File Size: 233 MB - Updated to v 1.1 (01.06.2018)

See it as a first step for you to get familiar with the process. You can present the Patch as: fms z_unofficial_patch_wesp5.pk4 tdmup-logo.jpg tdmup-readme.txt Yes, incompatibilities remain but at least players can give the Patch a try without marrying it too much. Alphabetically. Last pk4 wins. It's the same raw or in pk4.

Yes. It's a case by case exercise. We have the tools and we have the knowledge. We just need the will to do it. A pk4 is just a zip with a pk4 extension. If you pack the Unofficial Patch (except the "fms" folder) players can easily install it and remove it. Give it a try, pack it and give it a name, in example: z_unofficial_patch_wesp5.pk4 Test it.