Search the Community

Welcome to the forums Ansome! And congrats on making it to beta phase!

So I thought whether to mention this here, in the end I guess it makes sense as it's now technically a bug report. The discussion started out as a feature request, or rather a set of them... then it was mentioned that one of the functionalities I described should in fact exist, but an error is causing it to be overridden. We aren't sure when it was introduced but since I've always observed the broken behavior it might be years. You can read the full conversation here: https://bugs.thedarkmod.com/view.php?id=6436 What I observed and initially requested: When the player shoots at an AI, the AI shouldn't go searching in a completely random direction, and instead go somewhere toward the player as they should have a general sense of where the arrow came from. Currently guards completely ignore the direction of an attack and will cluelessly run to a completely random spot when hit which is very unrealistic: If an arrow hits you in the back, you aren't going to sprint forward looking for the perpetrator there. How this turned into a bug report: Someone investigated the issue and discovered that when attacked, AI should in fact be picking a search area between their own position and that of the players. I understand the pain event mistakenly overrides that decision, causing the guard to pick random locations within their own radius when attacked. Now that this is known, maybe this can be fixed in time for 2.12 so we aren't stuck with the broken behavior for the whole release?

It seems like more and more "thief" and "thief players" is becoming a short hand to dismiss community members earnest desire to improve the game - which happens to be a barely legally distinct "thief style" game which was made by thief fans for thief fans and is "designed to simulate the stealth gameplay of Thief". Who is the predominant player base of the game supposed to be beyond fans of the thief games? Is there some better avenue to find feedback for the game beyond this forum? FOSS and linux forums? I have seen maybe half a dozen posts from that segment. I am a thief fan, I play thief fms, my association with those games is what drives me to play and make things for this game. Are we supposed to pretend the original games are not a huge reason why most of us are here at all? TL;DR version:

Thanks! 1) Doing LONG_PRESS PAD_A (what I, for lack of knowledge, call "jump-mantle" or "_jumpmantle") differs from doing PRESS PAD_A ("_jump"). "_jumpmantle" differs from "_mantle", so they must be mapped to different button-calls. "_jumpmantle" differs from "_jump", so they must also be mapped to different button-calls. This appears to be the case, but it is not evident (or changeable) in DarkmodPadbinds.cfg. "_jumpmantle" seems to be hard coded to always connect to the same button as "_jump" but with a long press. It is as if bindPadButton PRESS PAD_A "_jump" is not actually just binding PRESS PAD_A to "_jump", but rather interpreted as "link PAD_A (regardless of button press time) to behave exactly like keyboard SPACE for short and long presses". I would have expected the default DarkmodPadbinds.cfg to explicitly read: bindPadButton PRESS PAD_A "_jump" bindPadButton LONG_PRESS PAD_A "_jumpmantle" bindPadButton PRESS PAD_B "_crouch" bindPadButton LONG_PRESS PAD_B "_mantle" ... but neither LONG_PRESS PAD_A or "_jumpmantle" is listed in the file. If there are actions "_jump" and "_mantle", I suppose there must also be an action "_jumpmantle" since it is possible for the player to do all those movements: * "_mantle" does the movements "crouch on the high surface, then stand up" * "_jumpmantle" idoes the movements "jump slightly forward, then land standing on the high surface" * "_jump" idoes the movements "jump up, then land exactly where you started" If the actions "_jump" and "_moveup" are not synonymous, then perhaps the action "_moveup" is what i call "_jumpmantle"? 2) Thanks for the link! It was useful in more than one way. I'll link to that page from https://wiki.thedarkmod.com/index.php?title=Bindings_and_User_Settings#Gamepad_Default_Bindings if I can get an account on the wiki, which proved more difficult than i thought (https://forums.thedarkmod.com/index.php?/topic/22327-how-can-i-create-an-account-on-the-tdm-wiki/). However, it does not answer my question how to find out the name ("<button>") used for a button on my gamepad. Basically, I would need to press the button on my gamepad and some program could tell me "That button is called 'PAD_A'". In my case, I have a gamepad "Logitech F310" (https://commons.wikimedia.org/wiki/File:Logitech_F310_Gamepad.jpg) which has a "Logitech button" (see image) that I want to use. I was hoping to find out the "button name" for that button and then edit DarkmodPadbinds.cfg to map it to a function. 3) ... but if that button has an "unusual name" that TDM does not recognize, then it may perhaps not work. E.g. if that button is called "PAD_LOGITECH" and TDM cannot recognize that name, then I cannot map anything to it via DarkmodPadbinds.cfg. Using QJoyPad I can map any keyboard key to it instead, as a workaround, but I cannot map MODIFIER to it (since MODIFIER cannot be set to a keyboard key). If current implementation is still called "experimental", then I must say it works very well; @cabalistic: kudos for that! I may not have continued playing TDM had it not worked with a gamepad.

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.

I did play Thief and FMs, but I don't play it any more, except for major things like Black Parade. The clunky movement and antiquated Dromed editor is what discouraged me from interacting with it over the years. I regularly play and sometimes make content for TDM, because it has much better movement model than Thief. I know that most missions don't use it well, but if you construct your geometry (gaps, ledges, distances) using power of two measurements, movement and mantling feels fast and snappy. There's no need for regression in that regard, in my opinion, there's a need for assets and missions made with the movement model in mind, to showcase its strengths properly. Even if TDM originally intended to "simulate the stealth gameplay of Thief, many things will be familiar to veteran Thief players" the actual mod history was a bit different. The team came up with a mission platform that has its own identity when it comes to mechanics. The way assets were made might have been a huge mistake, but that didn't prevent the platform from growing. Since you like anecdotal evidence, noone other Skacky once said that TDM movement model was super clunky, after playing The Painter's Wife. It was really hard to convince him that if a mapper places geometry this poorly, and isn't aware what spatial measurements play to the strengths of a movement model, no movement model will save his mission. And there is no fixing of this problem on the engine side, although it's not the first time when TDM team tries to address the asset problem with engine changes, which I suspect will ultimately lead to even more problems down the line. In game development, things like core mechanics and player tools are locked-down first, in one of the pre-production phases, because all the levels will be constructed around them. Making changes in core mechanics in a project this mature is very risky, I assume you don't plan on going through all playable spaces in all released TDM FMs to check for errors. Instead of making incremental changes in fundamental mechanics, I'd encourage you to create a fork, or some kind of major version bump candidate, like 3.0, where all things could be revamped: movement, player tools, UI, new frob mechanics, perhaps with UI contextual icons, new training map to incorporate all that, etc. Once all new elements fall into place and create something new, with a map or maps to back it up as relevant changes, it will be easier to convince existing player/author base that it was worth it. I assume the existing fanbase is already fragmented, as a result of all those heated discussions around the topic. But with multiple versions available for download, the transition to hypothetical "TDM 3.0" should be easier. It could be similar to UE2 and UE3, and you could also use this as an occasion to draw the line for backwards compatibility. I know there are old systems and variables kept in place just in order not to break existing missions. This way you could e.g. redo the LOD system, implement lights using math functions instead of textures, etc.

Interesting, didn't think about that. Yeah the compass uses that trick, I could just use a model of the helmet instead. If it looks good and is worth maybe I'll consider that, though it might be distracting and not make enough sense. The heads are modeled that way: Hoods and helmets are part of the head mesh as they aren't attachments. This is normally a good thing since performance isn't wasted rendering the head or hair under the helmet, but complicates things for my approach as the only way is changing the head models at runtime which may break precaching and stuff. Only a few hats are attached as a separate entities, like the little red hat some merchants wear or the straw hat... those aren't ideal for disguises though and I don't plan on supporting both approaches. Technically I could try attaching the independent helmet model to the player head, but that would surely look awful and clip through the hood and stuff... only right way is to give the player the Citywatch head once that error is fixed. For AI there is no other way apart from also changing the head model: Stealing the helmet from a guard implies taking it off them, which means they need to switch to a helmetless head which can only be done by setting a different head mesh upon frobbing... no idea if that triggers the same crash as the player head, if so I'm out of luck till a dev can take a look at my report. The base disguise system can be used that way too, it's just not the theme I went for by default as I wanted them to be physical wearables. You can define a magical disguise too that implies creating an illusion which tricks other AI into seeing you as one of them. In fact I thought of including one for undead using a magic skull that makes them think you're also dead, might add that in the next version if others think it makes sense and is worth it? Note that the spawnargs are documented via editor vars in case anyone wants to make their own: As long as you have a moveable model and inventory icon it's just a few tweaks to define any disguise. Simply inherit from the base "atdm:playertools_disguise" entity def and customize the team and other spawnargs... remember to use the proper mass / friction / impact sounds. Let me throw them here for anyone who wants a quick preview: atdm:playertools_disguise { "inherit" "atdm:playertool" "editor_usage" "Don't use. This is the base class for disguise inventory items." "editor_usage1" "Individual hats and helmets will derive from this." "scriptobject" "playertools_disguise" "gui" "guis/tdm_hud_disguise.gui" //"model" // to be defined in subclass //"clipmodel" // to be defined in subclass "inv_name" "Disguise" "inv_category" "Disguises" "inv_icon" "" "inv_droppable" "1" "inv_map_start" "0" // Disguise "team" "0" "rank" "0" "personGender" "PERSONGENDER_MALE" "personType" "PERSONTYPE_THIEF" "regen" "0.25" "rate" "0.5" "rate_alert" "0.1" "distance" "500" "speed_move" "1" "speed_turn" "1" "overlay" "" "snd_wear" "player_rustle_short" "snd_remove" "player_rustle_short" "model_head" "head_thief" "skin_head" "" // Disguise editor vars "editor_float team" "The team the player disguises into when the disguise is active." "editor_float rank" "Rank while the disguise is active." "editor_var personGender" "Person type while the disguise is active." "editor_var personType" "Person gender while the disguise is active." "editor_float regen" "The disguise regenerates over time at this rate." "editor_float rate" "The disguise degrades at this rate when the player is seen by a member or ally of the team." "editor_float rate_alert" "The disguise further degrades by this amount when an AI is alert, increases gradually with alert level." "editor_float distance" "Maximum distance at which being seen by the AI can degrade your disguise, offsets with AI visual acuity." "editor_float speed_move" "Movement hindrance while wearing the disguise." "editor_float speed_turn" "Turning hindrance while wearing the disguise." "editor_var overlay" "Overlay image while wearing the disguise." "editor_snd snd_wear" "Sound to play when putting on the disguise." "editor_snd snd_remove" "Sound to play when taking off the disguise." "editor_model model_head" "The player's head changes to this model while the item is worn, can be seen in mirrors." "editor_skin skin_head" "The player's head changes to this skin while the item is worn." }

I am going to sort-of reveal that this is loosely like the nature of my upcoming mission. I noted it here when JackFarmer asked about things that are coming along in this post: https://forums.thedarkmod.com/index.php?/profile/37993-jackfarmer/&status=3943&type=status It too is a builder church. The player is requested by a hopefully famous character in another mission to handle some business that is affecting the congregation. I am looking to invoke some info and history laid down in other missions as a hook story.

I'll add one thing, which I didn't state earlier because I assumed it was obvious. But I'd like to make it clear. What is the purpose of dragging a body and body manipulation in this stealth game? In my opinion, it is a "tool" or "game mechanic" that gives the player the ability to do two things: The last 10%. After shouldering a body and dropping it in a desired location, the player can drag and hide it more precisely in the shadows. Is just a foot or hand sticking out into the light? No problem. Grab and drag it into the shadows. No need to shoulder and drop the entire body again. That's a good thing. Dragging gives fine-tuned control for that scenario. Nearby shadows. After KO-ing a guard near a dark area, the player can quickly drag the guard into the dark area. The distance here would be one or two body lengths away. Given that the distance is short, dragging is quicker than shouldering and dropping. That's a good thing. Dragging gives a quick way to hide a body in that scenario. In my opinion, the 2.12 controls enhance the experience for those two scenarios, because the controls give a quick way to grab a body, drag it into position, and release it quickly and precisely. However, most of the time that fine-tuned control is not necessary for this stealth game. Shouldering and dropping a body can work well enough, hence why it became the primary action. That said, being able to precisely drag a body is a great enhancement to just shouldering, and it's something players can learn and appreciate given time.

Breakable lights might be an interesting concept so long as they are not implemented retroactively. Add a loud sound or other punishment for breaking them as you see fit, but it would still change the difficulty and design intended by level authors if you applied it to all previously made levels. I would also suggest that if you instead intend to make breakable variants of existing light models that you add a clear visual indicator that the light is breakable, otherwise it would require explicit messaging to the player that electric lights are breakable in that particular FM. I’m hesitant to see something of this sort added as it is in stark contrast to Thief precedent, but I would be more supportive of it if it was added carefully and responsibly.

The weapon hack is something that IIRC forces a model to render in front of everything else. It's limited by the fact that it can only apply to .md5mesh models, currently, such as the viewmodel of the player's arm and any weapons attached to the arm.

Yeah, that is a true aspect. Which is why I think there could be one of two approaches if this happened: Either make breakable lights a new entity for some lamps that want to feature them, so just as you have "atdm_lamp_1" and "atdm_lamp_1_unlit" you'd have an "atdm_lamp_1_breakable"... or if we implemented it for all lamps retroactively, it should come at the cost of AI becoming suspicious whenever they see a broken lamp just like when they notice a rope arrow, in which case the player choosing to go down this route comes at the cost of attracting attention and possibly ruining their stealth score.

This kind of mechanic would break a ton of existing FMs. Some (I dare say even most) mappers often choose electric lamps so that they can't be extinguished or turned off, forcing the player to time their movements through the light. There are of course switchable electric lights, but that is up to the author on how they want to implement those. It would definitely be fun to see an FM implement this Splinter Cell-style mechanic, where the mapper has designed their map to function in such a way, but to add this as a core feature would break the gameplay of countless maps

Тest: Thief's Den 3: Heart of Lone Salvation Settings: by default Version: 2.09 Bug description: While the player is moving, if he look at the floor, he can see a wave of light. This wave of light moves with the player, as if the player is the source of this light. Example. stand at the specified point, go forward till the next point and at the same time look at the area marked with a white line.

The devs didn't title this thread, and @datiswous said they're attempting to mislead people by using Russell's name and a retro style to make it resemble Thief, which is cynical. I grew up on forums like I'm sure anyone who likes a game from '98 did. I actually left the Discord immediately after joining it because it was more off-topic doom-posting than anything relevant to the mod. I thought the forums might be better, but it's mostly just grown men yelling at clouds and telling strangers how mature they are, and a few brave souls actually developing anything. Depressing place, I'll just stick to enjoying new missions every 6 months without an account.

True, but, 1. this thread is called "Western stealth FPS with Stephen Russell", and, 2. nothing you said changes anything for me. The gameplay still doesn't look like something I'd enjoy. And, if you really think this forum is cynical, then you don't visit forums much. Actually, the majority of the users are are pretty mature, unlike in other forums.

New script for mappers: my flavour of a fog density fading script. To add this to your FM, add the line "thread FogIntensityLoop();" to your map's void main() function (see the example in fogfade.script) and set "fog_fade" "1" on each foglight to enable script control of it. Set "fog_intensity_multiplier" on each info_location entity to change how thick the fog is in that location (practically speaking it's a multiplier for visibility distance). Lastly, "fog_fade_speed" on each foglight determines how quickly it will change its density. The speed scales with the current value of shaderParm3, using shaderParm3 = 1000 as a baseline. So i.e. if shaderParm is currently at 1/10th of 1000, then fade speed will be 1/10th as fast. Differences to Obsttorte's script: https://forums.thedarkmod.com/index.php?/topic/14394-apples-and-peaches-obsttortes-mapping-and-scripting-thread/&do=findComment&comment=310436 my script uses fog lights you created, rather than creating one for you. Obsttorte's script will delete the foglight if entering a fogfree zone and recreate it later more than one fog light can be controlled (however, no per-fog-light level of control) adding this to the map requires adding a line to your void main() script, rather than adding an info_locations_settings entity with a custom scriptobject spawnarg in my script, mappers set a multiplier of fog visibility distance (shaderParm3), while in Obsttorte's script a "fog_density" spawnarg is used as an alternative to shaderParm3 smaller and less compactly written script fogfade.scriptfogfade.map

We didn't make the holidays (such a busy time of year) so here's a New Year's gift, an unusual little mission. Window of Opportunity Recover an item for a regretful trader out in a wilderness setting, and discover more! Available within the in-game mission downloader or: Download: http://www.thedarkmo...ndetails/?id=79 Alternative: https://drive.google...WTMzQXZtMVFBSG8 Some unorthodox gameplay on regular/ghost difficulties. (Arachnophobes might prefer short mode...) Please expect to need your lantern in regular and ghost modes! Short ("easy") mode is a smaller map, so if you are looking for areas others reference below, or 100% of the loot, you'll need to play on another mode. I wanted to create my first mission before I became influenced by too many others' ideas, and limited myself to what has been done before. As such, this mission is not set in a city/town, and has some features that are likely to be provocative. There's a section some really like, which others don't, either way I kept it short to not last too long. That being said, I hope you do find it fun! :-) Special thanks to those who provided valuable testing and feedback: Goldwell, Kyyrma, plotzzz, 161803398874989, PPoe & Bikerdude (who also contributed a sound). (Please remember spoiler tags to not expose things meant to be discovered by playing.) Like so: [spoiler]secrets[/spoiler] If you are having trouble finding the main objective, here's what to pay attention to in the mission for hints: There is a spot it's possible to get stuck on the ground in the corner by the cliff/rockfall where there's a rope laying on the ground, please take care if you poke around there!

Because the player didn't move/make noise, the code that AI uses to "listen" for the player wasn't triggered. Because the AI weren't on the same team, the alert level wasn't propagated to the other AI. There's so much that goes on to make AI SEEM like a facsimile to real people, but there's always going to be edge cases where's there's no code to handle it.

Since I'm bored and haven't posted in a while and yet still finished Thief 4 a few times, I feel compelled to post. In response to a number of observations @Rio_Walker made: Seeing your hands and all the animations newGarrett would do was fun... at first. But given all the looting and environmental interactions the game has it really did slow things down a lot, especially when the game would occasionally realign the player just perfectly before playing an animation to open a drawer. If they had an option to disable these animations or speed them up significantly I'd have been happy. I've played using the Custom difficulty with the option to disable focus and the experience is kinda mixed. While it does make things a bit more traditional without the superpower ability to find loot more easily, it does seem like the game is designed very much for focus and disabling it can hide things you never even knew were present. If it weren't for the focus for example, I would never have noticed the "special" candles hidden around the city that talk when you light them. This game reminds me of a movie that has been reshot several times with footage from separate reshoots blended together with bad editing. It's painfully clear the story has been chopped and changed over the many years of its development and there's assets in the game that clearly had greater importance in a previous iteration but for which their plot points were cut. The most obvious example is the automatons. There's a dude who provides missions on obtaining pieces for one he's building, but apart from that there's also signs in other areas they had more importance (e.g. you see rooms full of them when going up an elevator, the Baron has disassembled ones on tables in his cutscene, etc.) Some plot elements just feel not fleshed out because they had to cobble together something to create this Frankenstein's monster of a game from so many elements. The ending sucks and is incredibly abrupt. Do we even know what the deal is with that half-built ship? Probably another abandoned plot point. With all of its problems, I still kinda like it in so far as its general gameplay. But it doesn't have the longevity of something like TDM or the classic Thief games especially with all the user missions available for them. Oh well, maybe I'm just pining for what it could have been in the hands of a better developer.

Beta 11 Fix finished-on state auto-update was unreliable Slighty improve scanner title/author detect Tags are now named some whatever regular-version-looking thing to force GitHub to put the newest at the top

I would guess you would take a random swing and maybe something like this could be implemented. Like if the player hits the guard with his sword, sooner or later the guard should just hit back even if he can't see the player. I don't think we need to do anything about hitting guards from far away in the back. How should they know where the arrow came from?

You cheeky nandos. XD Have you not considered using the screen? She walks behind it, there is a shadow of her lifting her arms, the light flickers - POOF - model swap, she steps out clothed. Although, there had to be something preventing the player from walking behind the screen. I liked how you handled her undressing to begin with. What startled me earlier tho, along with creepy music while the Builder's priest sings in the background, is the dress mannequin... with human hands.