Search the Community

There's a group of players who have meticulously tested and adjusted ghosting rules for The Dark Mod. Please see: Official Ghosting Rules: https://www.ttlg.com/forums/showthread.php?t=148523 Ghost Rules Discussion: https://www.ttlg.com/forums/showthread.php?t=148487 Why alienate an established group of dedicated players?

That sort of tone doesn't fly in our forums.

Maybe start with finding who are these "we" people who want to change the license to assets?... As a programmer, I definitely do not want to maintain any additional packages. And I do not want to get entangled into any kind of licensing questions. Just that I understand: A license that forbids commercial usage is considered not free (CC-NC). A license that allows commercial usage but efficiently forbids making money from it is considered free (GPL and AGPL). Yes, this is a great distinction Now someone should come and say "but hey, you can sell your support for GPL product!" UPDATE: Well, I think there is also an approach when company provides reduced version under GPL and expanded version under commercial license (like Qt). As long as reduced version is reduced enough, it seems to work fine.

Initially wanted not to post about this, I told myself it's just another useless feature that would waste time before a release and all. But it does carry actual gameplay limitations I run into: I often have no way to tell if an enemy is dead or just knocked out. If the FM has a "don't kill anyone" objective that makes it clear, otherwise you need to pick up the body and see what the text says. In the past you could tell by their eyes: Dead AI would have them open while knocked out AI had them closed. Last time I played it seemed like even this stopped working and both cases had their eyes shut... a recent bug perhaps? In any case it's often a difficult cue to find, so I wonder if anything better would be possible. Obviously AI become ragdolls so animating any important bones is surely impossible: I'd suggest making them move slightly so it's clear they're still breathing, but this would likely send the ragdoll shaking all over the place since they probably can't handle an animation being mixed in. So here's one idea that should work great: Alongside the eyes we could have the mouth be open, which is easier to spot from a close distance. Knocked out AI have their mouth closed, dead AI have it open which is a clear cue and also looks more... well, dead. Another would be to add the snoring sound to knocked out AI... now I'm curious if in real life someone being knocked unconscious snores like when they're asleep, don't try it out of course

I like that we can extinguish candles and light on/off lanterns with a long frob. A lot. It feels very natural. Congratulations for the idea and execution. From an usability point of view I disagree with the default 200ms but since members here are confident players will always get the desired result consider me and oddball. Thanks for having provided a cvar for me to change the timing. I don't like the fact that the toying with bodies or body limbs mechanic has been rendered unusable. People that don't use this mechanic to its full extent won't understand the reasons: take a limb and painfully carry the body to another room, hide a body carefully in the most peculiar place and position, recreate a crime or comic scene... Only TDM provides this fun, for those seeking it. The potential of the mechanic is gone for both existing and new players: too much long frob / key press to bother. Don't try to convince me of the opposite. Please make a cvar for snatcher to shoulder and unshoulder bodies on long frob, just like with candles. This is, in my opinion, the wisest of the solutions. Many thanks in advance.

Don't you get that I mentioned my alternative over and over again? The original players had an issue because they didn't know they need to use a different key for shouldering a body. If this is done by long frobbing instead, the same as e. g. multilooting or extinguishing a candle in your current patch this problem is solved! I have no issues with the idea, I only would like to have the order consistent: short frob - pick up (as is normal with all moveables in TDM), long frob - special action (like shouldering, extinguishing, multilooting or maybe eating consumables next). The thing I find inconsistent is that you see shouldering not as a special action. Also I hope Daft is kind enough to add a cvar variable with which this can be adjusted, it shouldn't be too difficult to reverse short and long triggers.

I would use this massive list for any fan missions, it includes campaigns too: https://www.ttlg.com/forums/showthread.php?t=148090 There are a lot of Fan Missions for the picking, I myself go for the lesser known ones and the short variety, because sometimes they hide a gem or two. Just like jaxa, I'm a bit outdated after the temporal retirement, but I do remember some amazing campaigns like "The Black Frog". If you intend to play The Black Frog, you should play the first two of the L'Arsene series missions, it's how I did it myself. Also, yes, L'Arsene are a fantastic series. The first mission of L'Arsene is a "rough draft", author was a bit new to Thief level making, but still great either way, after the 3rd you will see how his skill increased by a massive amount.

No, I remembered the old system, but I also was using my patch so I suspected at first I messed something up before I remembered that the handling of bodies and lights are so counter intuitive right now. I could easily add my own patch solution to make extinguishing lights short frob again, but I would rather see a consistent version of it in the core game! To provide some background information, I had just finished both the Cyberpunk DLC and The Outer Worlds DLCs, both of which use short-use and long-use systems too so my mindset somehow was expecting something more consistent ;).

The new system is great and, in my opinion, does not need changing. But just for the sake of this discussion: what if the default action for bodies (drag or shoulder) could be chosen with an option? A simple checkmark that switches these around (either short frob = drag and long frob = shoulder or the other way around)? Both variants would be ok with me.

Yeah, I know what you mean. For some reasons, the entity type atdm:moveable_custom_item does not work as intended and the only workaround is as per you description via approximation, but: if you use a key category instead of the moveable item, then it works with frobbing. @cvlw Clint, please answer my question in my previous post, then I will provide you with a setup for your to modify in your map.

I think that was directed at me, as I usually argue for the new control scheme (albeit with some modifications). I liked that post because it contained some valid points of criticism: Especially the first point frequently happened to me. Yes, the new frob-to-loot feature is there to help, but I still sometimes accidentally shouldered a body.

I agree with snatcher that the current solution has the bodies backwards and I have another example: consumables. Right now it's frob to take and use to eat. Your solution would be frob to eat and long frob to what, not eat? Because we need this for missions where you are supposed to give consumables to somebody. The consistent solution would be frob to take and long frob to eat. So it must be frob to take bodies and long frob to shoulder them. I for one do not should everybody I knock out, only those who might rise suspicions. As for auto opening of doors, I had this off by default, but sadly there are missions who only work with this on, which indeed is an mistake of these missions, but thus has become standard...

Unfortunately, TDM forum deletes the separator between the numbers. So I have to guess where one number ends and the next starts Also, user can rename screenshot manually, or push it through something that would rename it automatically. Thenwe won't see coordinates on screenshot address on forums.

Nah, forget it. It was a targeted message: somebody takes a position but later reacts to a post that goes in different directions and this is perceived as heresy.

The fewer words you need to explain your mechanic the better it is designed: For static objects press "frob" to interact with them. For moveables press "frob" to grab them and "use" to interact with them. TDM follows these simple rules nicely. @Daft Mugi I welcome this initiative and I encourage you to carry on experimenting. Here are my thoughts: Interacting with moveable lights: currently to extinguish a candle I must "frob" it and "use" it. If I extinguish a candle unintentionally it is my fault (I pressed the wrong button). With your design, is it my fault if I frobbed a candle 201 milliseconds and extinguished it unintentionally? Long-pressing buttons in TDM is faulty because there isn't any visual timer / bar / whatever. Dragging vs shouldering a body: interacting with the limbs of a body is the more challenging of the two mechanics. Do we really want to promote the easiest of the two and make the challenging mechanic more difficult? Besides, with your design I unintentionally drop bodies often while I intend to interact with doors, is it my fault? In my opinion the short term solution is a very long frob (0,5 secs or longer) to extinguish a candle and/or shoulder a body. Leave the original mechanic intact but have the new functionality somewhere in there for those who want them. The long term solution is something else: what would you do if you were to build these mechanics from scratch? Think big. PS1: Developers should never point players to anything that isn't available in the in-game settings. cvars should be there for 1) debugging 2) testing 3) very special cases, mainly accessibility / usability. PS2: "This is how Thief does it" sounds like a lame excuse. Thief is dead, TDM is alive!

tdm_show_viewpos cvar and screenshot_viewpos command: https://forums.thedarkmod.com/index.php?/topic/22310-212-viewpos-on-player-hud-and-screenshots/

Perhaps I am mistaken, but this seems to have been the position on other accessibility features not needing to be forward for existing players in places like the main menu as long as they are addressable by cvar? But they will at a minimum be able to move a body right away without sinking hours into the game thinking they can only drag them around. As far as the merits of double click vs long press it sounds like it is worth testing, but can’t say without feeling it out. Long press has been working fine on my end.

Wasn't sure if I should still post this since the mystery was somewhat solved, but just to confirm this case can be found in the wild with FM's other than mine: Yesterday I played Chronicles of Skulduggery 0: To Catch a Thief. There's a door up on a terrace (I can reinstall it and go there to get a viewpos if anyone's interested) which upon picking and opening will cause the light on the back of the wall indoor to slightly shine on the floor outside through the entire wall. Exact same camera position / angle in both images so you can just overlap the two screenshots to see the difference, though if you look at the bottom left ground it's pretty clear what happens once the door is opened. It's still a bit weird: The wall module model should still be casting a shadow, even if the wall brush uses caulk and not shadow caulk. Whatever the case a few FM's out there seem to have this problem, even if it's not an issue the engine or building modules can resolve I wonder if mappers can be better put on notice about it since like me most are likely not aware this is a thing or what causes it. Looked at the first post again and the video attached to it: Definitely seems like the same thing. Most importantly it wasn't doing this in earlier versions which I didn't realize... I'm seeing the clarification by Stgatilov as well which I initially missed, I definitely prefer the performance optimization but now I do wonder if something can also be done about this eventually.

I just played the new beta mission and wondered why I couldn't extinguish moveable lights as I had already forgotten that I need to use hold-frob in 2.12. This is completely counterintuitive to shouldering bodies and there is no global information about this, so please make it so that hold-frobing takes a moveable light and short frobing extinguishes it! This would also be more consistent to the static lights. The same should be done for consumables too: short frob eat, long frob pick up...

There's a bug I've been noticing for a long time, but for some reason it didn't click with me to mention it till someone else just mentioned seeing the same thing and I realized I'm not the only one. The contents of some chests and small containers like drawers will sometimes not become frobable when you open that container: You may need to close the door and open it again, after which you can frob any scrolls / keys / etc inside. Most likely something is happening with target_setfrobable getting triggered at the wrong time. Even when they are frobable, tiny items in small containers will sometimes only highlight from a very specific position and angle: I've had cases where I needed to lean forward and look at a coin just right and it would only highlight when my crosshair was on that one pixel. I'm sorry I didn't think to note down a FM and viewpos where to test it; If you need I'll keep that mind for when I play the next one. This doesn't happen a lot any might be hard to catch, but often enough as to be noticeable... in most recent FM's it seems to occur at least once in some drawer or lockbox.

I see this differently: When you short frob a candle, you can move it in the world. Then you do the special operation, long frob or use, to extinguish it. With a body it was the same: When you short frob it, you can move it in the world. Then you do the special operation, long frob or use, to shoulder it. Your current solution is counterintuitive to that and it also looks much too fast because of this! Can you add a variable to turn that behaviour around? Or could this be done by editing a script or something? Also wasn't long frob supposed to be used to unshoulder a body now, which again is counterintuitive to the short frob shouldering behaviour?

The time has finally come for me to release my 5th mission for The Dark Mod. This project started sometime around 2015-2016 (couldn't find any old files to confirm) with me starting poking on a city mission and for some time I built quite randomly without a plan. I expected I could plot a story later; You can never go wrong with a city section, eh? I had a hiatus and did other projects in my life with model painting and skydiving and mapping became more and more scarce. Now and then I felt an itch to map and some kind of responsibility towards the mod team to produce something, to provide and give something back, if you will. At the start of the pandemic I started building more focused on this misson, but still no exact goal on what I wanted to achieve. Finally I decided I wanted a mission where you follow a person and the mission continued to grow in a linear fashion. I am not the quickest mapper and have severe problems on how to imagine a scene without building it first. This means that I often have to redo scenes and lots of stuff gets unnecessarily built just to be removed later, hence the almost absurd build time (about 1900 hours all in all). Betatesting came about and I got very good tips and feedback and decided to redo a lot of the mission. This need for a rework could have killed my motivation but fortunately, as the map was designed, it only required a modest amount of work and the mission became so much better for it! Sometimes I believe I'm somewhat of the uncrowned king of missions with a bit more unusual and experimental playstyles and this mission also have some elements that isn't used that much. In contrast to some of my other missions though, this one isn't depending on any quirky meter or sun shining down on the player (Reap as you sow *cough*). As mentioned, it is a sprawling city mission with lots of exploring that I hope will satisfy you! So DeTeEff gives to you: Who Watches The Watcher? ver 1.0 https://drive.google.com/file/d/1YYoJJnxr2UbGxemTR-WoWmH64fbazusH/view?usp=sharing The night is creeping over Bridgeport. You squint in the street lights as you trot down the small alley to where you're about to meet your contact. As a man who straddles the line between lawful and outlaw, it's not often you have peaceful interactions with the City watch but as you're about to learn, this time they have more problems on their hands than to deal with petty thieves like yourself. You see the trademark silhouette of a City watch helmet approaching and you make a last take of your immediate surroundings, should you have to flee if things get awry. The guard presents himself as Albert and you listen carefully to his story and you quickly realise that you don't have much to fear from this man; The Citywatch has wrestled with some internal problems lately with missing reports and evidence that disappear. Albert strongly believes they have a mole on the inside that works for the Greynard RoughBoys; a band of ruthless thugs that doesn't hesitate to maim anyone who oppose them. You learn that he thinks the mole is no other than a Sergeant named Clerwick. Your mission will be to find this man, and collect intelligence on his doings for the night. And as it is payday, you should of course also help the inhabitants to carry some of their heavy purses. Mission type: Creepy elements? Undead? Spiders? Thanks to: My wonderful girlfriend who endures my constant talking about mapping and for helping me with readables and story design and some voice lines. Dragofer - Scripting help Springheel - All those modules Sotha - Hangman model Henrik Swenson for providing some ambients Digiffects Sound Library for some custom sound bites Betatesters: Acolytesix Datiswous Duzenko Jaxa Mezla Nort Prjames Shadow Thebigh Wellingtoncrab Wesp5 And a big thank you to the community for keeping the mod alive! I hope I haven't forgotten anyone... Known bugs: -The AI in TDM is inaccurate in some ways. They will sometimes behave strangely when returning to their original routes after being alerted, like sitting on chairs in weird ways or turning in places, especially if they meet another AI in narrow places. I have done my best to adjust these weird behaviours but with the complexity of everything that's going on and the player making different desicions/noise, it's probably impossible to adjust for everything. I believe I have ironed out the last wrinkles I can, with respect to my knowledge/skills. -Frobbing out of boxes/chests/drawers has always been a pain but I think this is largely an error within the code and how frobing works as the frob highlight wants to lock onto the box itself and not its contents. -There seems to be some kind of bug with the skybox, especially in places where there is water reflections present; The Sky/water volume switch between an opaque variant to a more translucent one. Neither is straight up ugly, but it's jarring to see the sky switch (as it seems randomly). I don't know what is causing this, and I have decided to let this one pass (if any players knows what is causing this, please let me know so can I squash this annoying bug. PLEASE POST ANY QUESTIONS/SPOILERS IN SPOILER BRACKETS

DarkRadiant 3.8.0 is ready for download. What's new: Feature: Support new frob-related material keywords Improvement: Mission selection list in Game setup is not alphabetically sorted Improvement: Better distinction between inherited and regular spawnargs Improvement: Silence sound shader button Improvement: Add Reload Definitions button to Model Chooser Fixed: Model Selector widgets are cut off and flicker constantly on Linux Fixed: DarkRadiant will not start without Dark Mod plugins Fixed: GenericEntityNode not calculating the direction correctly with "editor_rotatable" Fixed: RenderableArrow not drawing the tip correctly for arbitrary rotations Fixed: Light Inspector crashes on Linux Fixed: Models glitch out when filtering then showing them Fixed: Skin Editor: models not centered well in preview Fixed: "Copy Resource Path" includes top level folders Fixed: Skin Editor: internal test skins are shown if Material Editor was open previously Fixed: Changing Game/Project doesn't update loaded assets correctly Fixed: Model Chooser: initially hidden materials aren't revealed when enabling them Fixed: Choosing AI entity class 'atdm:townsfolk_commoner_update' causes crash Fixed: Sporadic assertion failure on shutdown due to LocalBitmapArtProvider destruction Fixed: Prefab Selector spams infinite error dialogs on Linux Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.8.0 and of course linked from the website https://www.darkradiant.net Thanks to all the awesome people who keep using DarkRadiant to create Fan Missions - they are the main reason for me to keep going. Please report any bugs or feature requests here in these forums, following these guidelines: Bugs (including steps for reproduction) can go directly on the tracker. When unsure about a bug/issue, feel free to ask. If you run into a crash, please record a crashdump: Crashdump Instructions Feature requests should be suggested (and possibly discussed) here in these forums before they may be added to the tracker. The list of changes can be found on the our bugtracker changelog. Keep on mapping!

You can walk through every entity and spawnarg in the set up piece by piece and see if there's a logical problem buried in there. I don't recall how the fade-in works for the initial ambient anymore. It's been too long. But you can experiment to see if it's really borked. But what I came to say is that note there's a Sound Override setting where you can just set up an ambient transition yourself by some trigger if the location transitions aren't working properly for some reason. One thing you might try, if the initial ambient always borks the fade in no matter what you do, is to set a dummy initial sound by immediately triggering the Sound Override as soon as the map starts, like just a quarter second of silence, and then turn the Sound Override off a half second later to have the system immediately transition back into the initial location ambient, and then the fade in should work properly. It's a bit of a hack, but it could fix your problem. You might be able to think of other ways to deal with it along those kinds of lines.

The output of condump log would be nice. Please hook up a monitor the troubled displayport and load the mission using some start-parameters. After And post the output of the condump in this topic. Maybe we can answer it by giving some driver setting changes. More info: https://wiki.thedarkmod.com/index.php?title=Debugging_TDM_systemerrors