Search the Community

I don't consider this an urgent or highly important feature, but found the concept useful enough to ask and may definitely use it on my maps. I actually don't know if it might already be implemented: No FM I'm aware of does this and it's not mentioned on the AI Relations (Editing) page either, however the AI Relations (Scripting) page mentions a gradual sys::OffsetRelation function but doesn't specify if it's also a gradual change in the AI's behavior. When setting team relations you normally have just 3 options: -1 (enemy) 0 (neutral) 1 (friendly). There is one limitation in this system: They seem to be integers and not floats, meaning you can't also express an amount by which the teams should be allies or enemies. Having this ability could have interesting use cases: You may want teams that still oppose the player but don't care that much and will only attack if you get right in their face or stick around for too long. As such you should be able to use values between 0 and +1 or -1 to indicate an interest level in the relationship, as well as values above +1 or below -1 to boost the AI's friendliness or hatred toward another team beyond its normal levels. Consider for instance a FM where thugs protect a territory they own: They don't like the player wandering into their turf, but seeing you is more of an annoyance than an emergency... they aren't as motivated to catch you as a citywatch guard who knows the player is a wanted thief and will immediately jump to apprehend you. In this scenario the relationship between thugs and the player could be changed to -0.25: Now you can walk between thugs for a few seconds and they will ignore you at first, but if they see you for too long you're eventually getting attacked. A super simple implementation would be to merely multiply the AI's alert increase rate from a target with its abs(relationship) toward it: If you set it to -0.5 for instance, AI on that team will take twice longer to be alerted by you until eventually attacking, same for allies who will be slower to notice a friend in trouble... meanwhile if you set it to -2 AI on that team will go alert twice faster than normal. I presume this solution can be done by changing one line somewhere in the alert code, and should have the accurate behavioral effect intended without reducing visual / audio acuity... no existing FM or default behavior should be affected either since I can't think who would be using those values if this feature doesn't already exist.

Hi folks! Since today, long awaited features of mission management are available on our portal. Mission reviewing is also here at the same time! For more information check out the post here: https://www.thiefguild.com/news/1/9443/the-guild-of-creators-and-players Creator Account description: https://www.thiefguild.com/showcase/creator_account How to review missions: https://www.thiefguild.com/showcase/reviews

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

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.

Looking at the code, the originals were "pm_mantle_pull 750" and "pm_mantle_pullFast 450". The new "pm_mantle_pull" value is "400". A "pm_mantle_pullFast" value of "450" would be slower than regular pull, not faster. With both being set to "400", they are at least similar. Other than that, it's subjective and the feedback from playtesters was positive. Also, referenced internally here: https://forums.thedarkmod.com/index.php?/topic/22256-movementcontrols-settings-in-main-menu/&do=findComment&comment=489158

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.

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.

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.

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

Well, I hate to be that guy, but as a researcher who has done tons of subjective tests with big subject groups, I would like to jokingly comment that the used test procedure does not allow the conclusion that people prefer short press frob for shouldering. What we can conclude from this poll is that people prefer short press frob for shouldering as well as various other actions AND long press frob for alternative actions in favor of short press frob for various actions as well as double-press frob for alternative actions including shouldering. This is the classic error of modifying too many determining factors between test cases and attributing the results to only one of the determining factors. However, I don't question that there is strong agreement with making shouldering the primary / short-press frob action. This has been criticism of TDM for a long time. We've had people coming to the forum asking for shouldering over and over again. So I concur to change this and set it as the new default even.

I quickly hacked this in yesterday evening and it actually worked quite well. Having the option to both toggle-type-grab and hold-type-grab junk objects is a nice quality of life feature to me. It actually worked for most loot and inventory items in the training mission as well, so that's also pretty cool. However, what isn't so cool is that food remains, unlit candles or candleholders (that never even saw a candle) are not treated as junk objects so the hold-type-grabber ist not applied. This requires some more coding logic, but should be fairly doable. So basically, above table would have to be altered in the following way. With this adjustment, long press would always execute a special action first and would then consistently degrade to hold-type-grabber. Entity type Short Press Long Press Junk Toggle-Grabber Hold-Grabber Food Toggle-Grabber Eat Food remains Toggle-Grabber Hold-Grabber Loot Pick-up Hold-Grabber Bodies Shoulder Hold-Grabber Lanterns Toggle-Grabber Extinguish / Light Lit Candles Toggle-Grabber Extinguish Unlit Candles Toggle-Grabber Hold-Grabber Tools Inventory Hold-Grabber

Known general issues: When clicking "Restart" in settings, the game does not land back to the same settings. In mission failed screen, the list of objectives does not show status of objectives properly. Missions to be checked and fixed: A) Overriding some mainmenu_*.gui which should not be overriden: ac1 (post) ac2 (post) bcd (post) bathhouse (post) briarwood_manor (post, update) claw1_31 (post, fix) cauldron_v2_2 (post) --- changes accepted by @kingsal elixir (post) gatehouse1_3 (post) good (post) hhi (post) hhta (post) hhvf (post) hhtlc (post) itb (post) lich_queens_demise (post) northdale1 (post) northdale2 (post) nowandthen (post) painterswife (post) snowed_inn (post) springcleaning (post) talbot (post) ulysses_genesis (post) u2_flock (post) volta1_3 (post) NEW: away0 (post) B| Videos controlled by SDK (both briefing and debriefing): ahouseoflockedsecrets (post) nhat3 (post, update) requiem (post) score_to_settle (post) -- acknowledged by @Springheel sneak_destroy (post) C) Custom title: hareinthesnare (post) marshofrahena (post)

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

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

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 just typed it wrong in the post. But in the game I did it correct.

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.

I think we should deprecate parallel lights. The way they are implemented in Doom 3 only works intuitively if it is fully contained in a single visportal area, which is rarely the case. Otherwise, there are huge issue with area-portal graph and shadows. For something global like moonlight, the new parallelSky light should be used. If it is contains the whole level in its light volume, then the behavior should be well-defined as long as portalsky material is used to seal levels from the sky (not caulk or something similar). The light is supposed to come through the portalsky surfaces into all areas in this case. Are there any other usages of parallel lights?

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

If no one turns up the missing file (previous post), then I'll probably try to figure out how to regenerate it sometime in 2024. And/or edit DDS images. But for TDM 2.13, not 2.12

This is false. The quick-press frob action never happens before or after the long-press frob action. The single-click action always happens before the double-click action. You stated the following about double-click: Long-press frob to extinguish a candle never moves it. Double-click frob to extinguish a candle always moves it slightly. Therefore, long-press frob works well for ghost players whereas double-click frob does not.