Search the Community

I just recently became aware of this feature: https://wiki.thedarkmod.com/index.php?title=Particle_collisions_and_cutoff Unfortunately I completely missed it, as when I went to create weather effects in my FMs I just followed this (which doesn't mention it): https://wiki.thedarkmod.com/index.php?title=A_-_Z_Beginner_Full_Guide_Page_3#Rain_and_Snow The point of this thread is to a) make people aware of it and b) gather feedback from any mappers that have used it so we can get some mapper-focused documentation in the Wiki. The page above is great for background information about how it works, but as a mapper I really just want to know: What are the limitations of this (i.e. when should it be used and when shouldn't it be used)? Why isn't it the default behaviour? Why all this work to get it into the map? What built-in support for it exists (particle definitions, materials, etc). Do I need to create all this stuff myself? Texture layout vs. Linear layout: what's the difference in the end, pros/cons, why would I use one over the other... Why does it need a separate command (runParticle)? Can this just not be bundled in with dmap? A clear, step-by-step instruction on how to implement it in a map from beginning to end using a simple use case. Tagging some users who have relevant experience with this: @stgatilov @Goldwell @Amadeus

I've been wanting to post this topic for many months now. It's a continuation to ideas I posted a while back, regarding my wish to create a total conversion for TDM, adding a cyberpunk theme alongside the original steampunk world. The reason for making a new thread is that I have a plan laid out by now, but will need help from the community with it. I wish to know how many people would be willing to help out, so that I may know whether I should start laying out the foundation of this project. I will explain exactly what I plan to do in the form of a FAQ below, so that I can easily cover every aspect. This is going to be long, so make sure you have some time before diving into it! If you want to go straight to the points about what I require and skip the rest, read the titles in red which cover the essential paragraphs. What is this all about?The idea is in part inspired by one of the favorite games in my childhood, DeusEx - The Conspiracy. I used to spend weeks playing through it every few months, drawn by its adventurous story and its dark yet appealing environments. Since the last few years, it's been a dream of mine to create a FOSS cyberpunk stealth game with RPG elements, that would be entirely unique (similarly to how TDM is unique from Thief) yet have the same feel and atmosphere I loved about it (once again like TDM has the same atmosphere as Thief). My earliest thoughts were on trying to achieve this in Xonotic, which is a GPL licensed arena-type shooter I've been a long time contributor to. Of course I eventually abandoned the idea... mostly given that Xonotic has no features for single-player mechanics, such as saving / loading or any kind of AI except bots treated as real players. Then more than two years ago, I finally discovered The Dark Mod. After playing it for some time, I quickly realized it's by far my best option to making such a project come true. Why The Dark Mod, instead of building the game from scratch? It was designed to be a steampunk stealth game after all!The first reason why I want to use TDM as a basis is that it already has every crucial mechanic I need, in terms of AI and interaction and world programming. It does of course lack a lot of the features I ultimately hope to include, although most are optional and I could attempt scripting them at a later stage... for now little to no game code chances would be required. The most significant features are the AI (very advanced and intelligent), carefully balanced gameplay plus other common ideas, as well as the mapping system with its intelligent area portals. It should also be considered that while I'm usually a competent contributor, I'm terrible when it comes to programming something from the ground up, so there's no other way this could happen as a FOSS project unless I hire an entire team. The project aims to be a stealth game that works the same way after all, so why not? To exemplify what I mean: You can open DarkRadiant and build a medieval town with a tavern, then add a guard patrolling the tavern with a bow and a sword. In the conversion, you'll be able to build a futuristic city with a club, and have a guard patrol that club with a knife and a rifle. In both cases, the AI will do exactly the same things with equally correct results: The guards take the same patrol routes, chase after the player the same way, vocally alert one another in the same fashion, and search rooms and hiding spots as efficiently once the player disappears from view. There is no "medieval patrol style" versus "futuristic patrol style", the choices and decisions are exactly the same! The only considerable difference will be the assets and animations and settings. The second reason is that I'm a fan of the idTech engines as well as gtkRadiant based editors. idTech 4 is in fact one of my favorite engines in the line, due to how intuitively it was designed at its core and how much it pulled off during its day. Its only problem is that it hasn't had as many developers forking and modernizing it, unlike idTech 3 with say Daemon engine (for Unvanquished)... that is of course not its fault, and in part due to being open-sourced much more recently in comparison. How exactly would the mod work? Are you thinking of creating your own TDM fork?I don't plan to create an actual fork of TDM, which would be impossible to maintain on my own and only divide the community and its efforts. My plan is to create a mod that will run on top of vanilla TDM, adding new content without affecting any of the existing functionality. The mod would be distributed as one or many pk4 files, which are simply dropped into the main directory next to the stock pk4's! Its assets will be grouped under the mod's own name, so that they're always distinguishable from the normal ones... just like every default component is listed in a "thedarkmod" directory inside DarkRadiant, they would be listed in a "howeverthiswillbecalled" group. Once you have the pk4(s) of the mod inside your TDM installation, normally download any mission using them it in order to play it! So missions will be able to use entities and assets from both stock TDM and this mod?My plan is to allow that, and nothing should prevent maps with mixed assets. Keep in mind however that I ultimately want the mod to be independent, and encourage relevant missions to only use textures and entities included with it rather than a mix! If you take out every single stock TDM asset (excluding md5anim's which will be reused) the mod will be expected to work on its own. Will the new assets also be non-commercial?Unlike vanilla TDM, I don't wish to include any CC-*-NC and CC-*-ND assets with the mod. That's primarily because I find them limiting, and feel that they ruin the openness of the project. Is there a name for the mod yet?I've been thinking about it but haven't fully decided so far. I want it to be something familiar and related to TDM; Initially I wanted to call it The Dark Modern, but that sounds rather silly. The name I'm considering now is The Dark Machina, which retains familiarity with TDM and is also more theme relevant... further suggestions are appreciated. What is the benefit for the community? Why should anyone put any effort into this?The project is targeted to everyone in the TDM community who alongside a steampunk stealth game, would enjoy a cyberpunk stealth game of equal or greater visual fidelity... with exactly the same base gameplay and core functionality, but an entirely different world and atmosphere. The project will be publicly available on a Git repository of its own (most likely Gitlab), and anyone will be able to easily install it on top of vanilla TDM. Simply put: If you help and things go according to plan, you'll have a triple-A scifi game inspired by the look and feel of the DeusEx series, just as you currently have a triple-A game victorian game inspired by the look and feel of Thief. What do you need help with exactly? What would others have to do?Obviously I'm not asking others to do the work for me. But at the same time, it's not something I can just go ahead and do on my own either! For this reason I've come up with a plan, which would allow contributions to happen gradually whenever someone willing to dedicate their time to helping adds something new. This is mainly a call to existing TDM developers, who know best how to export and define new assets. If the project takes off, based on the answers I get in this thread, the starter plan is as follows: I will be creating two Git repositories. One will be the official repository of the mod, which will contain assets in working format and condition... the other will contain images, sounds, blend files, and other resources in their native format. This will include freely licensed assets I find on the internet, which I will hand pick and tweak to make sure they're in the readiest state possible, then sort them in a way that's easy to work with. Most will be taken from http://opengameart.org and http://www.blendswap.com and I'll likely use a few things from Xonotic altogether! The assets included in this repository are to be exported and / or converted to TDM compatible formats, then included in the real mod repository. A list will be maintained in order to keep track of which assets have already been ported. Every ported asset can be issued as a pull request, or sent to me personally in case the contributor doesn't have access to the Git service that will be used. The rigging, exporting, and conversion processes are what I require the community's help with! As far as models textures and sounds go, no new content will need to be created... I plan to use freely licensed resources which are already available and plenty, enough to create a full mod out of. Obviously I'll be doing some of the exporting and definition writing myself, but since there will be so much new content I can't do it all on my own... unless I dedicate every waking hour of my life to it for over an year, which would be more than I can handle TLDR: I'll be compiling a repository of game-ready assets, such as textures and models and sounds. Anyone who wishes to help is only asked to pick them up, adjust the TDM specific necessities (exporting to md5, creating material definitions, etc) and publicize the results for inclusion. So no new content is going to be needed?For the most part, no. There is only one exception to this rule: Voices. As they're something TDM specific, they have to be created to match the world and what's happening in it. They are however not a priority, and can happen at a later stage in the project. Until then we can live with a few cyborg troops saying things like "in the name of the Lord Builder, you shall go to the gallows, you heretic" Other than that, I will eventually want to add new functionality. Including a Minecraft type inventory system, computer chips the player can install into their suit or body in order to gain enhancements (modules / augmentations / whatever), and most importantly a re-implementation of the interactive touchscreens in Doom 3. Those are however even more distant needs in comparison, and not what this thread will focus on at this point... I plan to look into such once I'm sure there are enough contributors to be certain this is happening altogether. What do you need done for each type of asset explicitly?Here is a list of every new asset type the mod is going to introduce, and the steps I estimate to be required for each: Characters: I will be offering the blend files of all characters scheduled for inclusion. They will contain the mesh, textures, as well as the rig that the character comes with (if available). Steps to be taken include: Rigging the character to the TDM animation skeleton after using the original rig for initial posing (including face rigging), generating the shadow mesh, making sure polygon count is within acceptable limits, and finally exporting to md5. Lastly, generating and tweaking the character definitions (stats, team, social status, voice, etc) and the material definitions for the character's textures, which should be all that's needed for the model to become a working character. Notice: I'll be preparing a blend file containing the simplified / optimized TDM rig in order to ease the process, including the face rig which I remember had to be extracted from existing characters. Models: A similar process would be needed with static models and simple entities: They will be distributed as blend files which include the model and texture, and need to be exported to ase / lwo, with entity and material definitions in place. Textures: Most will likely be distributed as jpg and png, and will need to be converted to dds and tga. The material definitions will need to be created as usual. Sounds: Will be distributed as wav or ogg, which normally don't need to be converted. Sound definitions need to be created however.As far as specific TDM functions go, this is how I intend the modifications to work per component: Weapons: The plan is to keep each weapon the same in terms of purpose and functionality, and mainly modify the models animations and sounds. The same core code will therefore be used by each, but new entity definitions should be made in order to not affect maps using the existing items while the mod is installed. Menu: When a mission intended for the mod is installed, the main menu will use different textures and a different background song... no modifications to the entries or functionality will be made otherwise. I'm uncertain as to how this can be achieved, although it is lower on the priority list.What will be the modern equivalent of existing TDM items, as well as new content?Like I said, I plan to keep the functionality and purpose roughly the same, at least for a while. Therefore items will serve the same goals, and work almost exactly like the existing ones in TDM... it will be basically the names and appearances that change. The important replacements I currently have planned include: Weapons: Blackjack becomes Police Baton or Taser. Sword becomes Knife. Bow becomes Crossbow or Sniper (arrow types and behaviors unchanged). Items: Lantern becomes Flashlight or Keychain Light. Telescope becomes Binoculars. Compass remains Compass. Snake and Triangle lockpicks become Physical and Electronic lockpick (mechanical doors are unlocked with the first, electronic doors with the later). Potions become Medkits, Syringes, or special types of enhancements.As far as completely new content goes in regard to items and entities, here is a rough list so far: Books & Notes: Alongside the existing books and notes, laptops / smartphones / tablets will be added. They are unrelated to future plans for interactive screens, and simply refer to new types of visuals for readable items found throughout the world. Lighting: The replacement to existing candles and torches will mostly consist of desk lamps, particularly neon and LED based ones. Characters: A similar structure of factions will be followed, compared to the existing guards + thieves + civilians + beggars + nobles. In this case the main categories will be: Police (ideally different suits for various units), gang members (once again different clothing for each gang), with modern looking civilians of various classes. There will also be entirely new outfits covering jobs existent in modern times, such as scientists or industrial workers. Robots: The existing code behind the Steambot will be used to implement multiple kinds of security drones patrolling an area. Especially in early stages before new scripts are considered, they can have the same function of only sounding an alarm when the enemy is spotted. Props: There will be various modern props added throughout the world, depending on what content I find. This will include: Flaming barrels for poorer areas, futuristic cars and bikes parked on the sidewalks, televisions that play videos (in case itTech 4 allows video textures), and the list goes on.Closing thoughts:First of all, thank you for reading this enormous post, regardless of whether you wish to support the project or not. This is something I've dreamed of creating for a while now, and I really hope at least a few artists out there are willing to support it! Please leave your thoughts if you want, as well as voting on the pool so I can more easily estimate the help I may expect.

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.

I also hope the big pile of movement changes is finally over All these changes seem minor but cause heavy reaction. First we got overly lengthy arguments about it internally, now the same continues publicly. I'm not sure why everyone thinks parkour was the main motivation. In fact, I watched parkour videos to understand how the hell it should be possible to do the wall climb up as fast as @Daft Mugi wants it. Now I play Prey and its climb up is insanely fast, totally unrealistic... I guess in the end most people are annoyed by having to wait for the same boring mantling animation and prefer to regain control faster. By the way, I believe 50% of reception to such changes boils down to plain habit. When I took the first build of faster mantle it seemed crazily fast. But after we tweaked it (I don't think we made it much slower in the end) the reception gradually changed and I did not feel it that absurdly fast anymore. That's why I even suggested accelerating mantle gradually (e.g. 100 ms per release) to avoid much negative feedback

I was asked for feedback on some different mantle implementations. I liked the overall direction and the current 2.12 one not just because it is more responsive but because it also includes some other polish like getting rid of the kind of weird “double dip” mantle you would get when mantling into a crouched position with low ceilings. There are small things I would change were it up to me, but I prefer it to the original. It’s nice that there is some accompanying control in the main menu in terms of the animation intensity. I always liked the mantle feel of TDM and think now it feels even better, but that is just me.

May I ask where you got that "feedback from players" from, and who the "several mission authors" supporting making mantling faster are exactly?

When I tested TDM with a gamepad long ago, I'm afraid there wasn't any. I believe I tested force feedback with a system command and it worked, so TDM just doesn't implement this yet.

With TDM 2.12, after the credits finished, the "Mission Complete" screen did not display. I found that the screen was black and I could hear my footsteps when I tried to move around. I think the reason for the mission not completing successfully was that the "Do not kill or harm allies" objective was never marked as "1 = STATE_COMPLETE" instead it was left as "0 = STATE_INCOMPLETE". Note, I didn't use noclip throughout the mission. Same as: https://forums.thedarkmod.com/index.php?/topic/18054-fan-mission-the-accountant-2-new-in-town-by-goldwell-20160509/&do=findComment&comment=458491

How about using TDM automation framework (and maybe pcem/qemu)? More info see: https://forums.thedarkmod.com/index.php?/topic/19828-automation-features-and-discussion/

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

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.)

To cater to both audiences. I mentioned LibreGameWiki as one example. nbohr1more mentioned other uses. Explicitly allowing reuse and spread will help TDM reach a wider audience and would hopefully attract more volunteers. More volunteers which can help improve both TDM versions. There are several benefits for a project of being in the Debian repo. One is that TDM Debian-users can report defects on any package directly to Debian (no need to register on separate forums). Debian may then fix the issue themselves (in their "TDM-libre" package) and will offer the patch upstream to TDM, who can then choose to accept or reject the patch. I envision "TDM-libre" to have the same capability of downloading any mission as regular TDM. The only difference is that "TDM-libre" would come packaged with the regular engine (which is GPL+BSD) and an included mission that has libre media/gamedata. When I play TDM by myself, I want the unlimited-play and can accept commercial restrictions. But if I were to promote it somewhere, or charge for a stream when playing online, or make a video, I would want a version without commercial restrictions (and can temporarily accept limited-play) to make sure I don't violate anyone's copyright. Perhaps. That's what I'm trying to find out.

I suggest you use the term "I", to make clear that it is something YOU want, and that you speak for yourself. But, as wesp5 mentioned, I don't really know what this is about, at all. And, I'm also wondering about all the newly registered people lately, who just arrived at this forum, and already want to revolutionize this mod. This is a thing I noticed 2 or 3 years ago, and which hasn't been present in the 15 years I play this mod and frequent these forums now. Really seems like a common thing these days, to not knock on the door, but kick it in, and stomp right in.

Allowing mantle while carrying a body was originally proposed by Bikerdude one year ago (January 2022). https://bugs.thedarkmod.com/view.php?id=5892 I agreed with him, since that is how Thief 1 & 2 work. I've submitted patches, and due to feedback, I've submitted three patches each with a different behavior, starting in August 2022 (5892) : (Patch v1) Always enable mantling while carrying a body. (Patch v2) Only enable mantling while carrying a body if "pm_mantle_while_shouldering" cvar is set. This is already available in 2.11 beta 7. (Patch v3) Restrict mantling at the waist. There is no agreement about how this should work yet. I've spent over 12 hours of work and testing on (v3) so far, so it would be incredibly discouraging if a final decision is not made between versions (v1), (v2), or (v3) for 2.11. Personally, I think patch (v1) always enable mantling while carry a body is best. This matches Thief 1 & 2 and does not require a cvar. If (v3) is chosen, the rules need to be decided. Could you all please answer the following questions? (Please copy and paste the questions below when answering.) Do we really need to restrict mantling while shouldering at all? Is there a mission with a mantle trap? If so, which mission? If we restrict the player while shouldering, what should the rules be? While shouldering, what's the tallest object that can be mantled? While shouldering, should there be different object height requirements between crouched and standing? While shouldering, can the player mantle during a fall or jump across to another ledge? While shouldering, what mantle types are allowed out of: push, pushNonCrouch, pull, pullFast, hang? (Are there other rules to consider?) Resolved Patch v3 is included in 2.12 dev builds, starting with dev16778-10275, which is open to feedback during the dev release cycle. pm_mantle_while_shouldering cvar. pm_mantle_while_shouldering, default: 1 Which restriction for mantle while shouldering? 0 --- no mantling while shouldering a body (TDM original) 1 --- restricted mantling while shouldering a body 2 --- unrestricted mantling while shouldering a body (Cheat Mode) pm_mantle_maxShoulderingObstacleHeight cvar. pm_mantle_maxShoulderingObstacleHeight, default: 41 The maximum height of obstacles allowed for a shouldering body mantle Note that mantling above eye level is disabled regardless of this value

TDM has tons of textures from "free" texture resources that do not allow redistribution and cannot be incorporated into a commercial project. Someone would need to create a huge replacement pack of textures that do not break the look of existing missions and do not infringe on the copyrighted textures. Also, many artists who contributed to this project do not want 3rd party entities to use their work in commercial projects. They intended the models, textures, sounds, animations to be exclusively used for Darkmod content. You would either have to replace ALL assets or contact every contributor and ask them to re-license their assets. Many contributors are no longer active with the project and haven't visited the forums in years so it would be no easy feat. I cannot speak to Debian policy but I think that they treat installers that add non-free content the same as non-free content itself. One could argue that Steam is such an installer but I guess Debian would counter that there are a few fully Libre games on Steam. I think Debian, Ubuntu, or Linux Mint need to consider a repo that allows for games (etc) that include non-libre content but intentionally offer this content for free to the community with no stipulations other than "don't try to sell it as a product".

The gamepad implementation allows for a great degree of flexibility to personalize settings, aside from a few minor issues that I mentioned here: https://forums.thedarkmod.com/index.php?/topic/22337-gamepad-bindings/ I would say that playing TDM with a gamepad works very well, especially considering that it was implemented as experimental and hasn't been changed since then. If I could, I'd go back to 2021-you and congratulate you on buying that gamepad. I notice that your DarkmodPadbinds.cfg looks very different from mine...

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.

It is possible that this is a setting that needs to be activated to work: https://mantisbt.org/forums/viewtopic.php?t=23221

This thread is for discussion and feedback on the xray feature, which has been developed further for 2.10 and is now considered feature rich enough to be publicised and wikified with X-Rays and X-Rays in GUIs. See below for the main wiki article's introductory section: As well as some screenshots from the demonstration map found in the main wiki article: (Note that various assets mentioned in the article are currently only available in the demo map and will become part of the second 2.10 beta build).

Here is some feedback: This is a great addition. Thank you. I would like someday to be able to mod it and remove the restrictions via scripting. This is a great addition. Thank you! I haven't tested this yet but it sounds good. The problem I had with this is the damage you take at the end if you are not careful, spoiling any fun that may be reside in the mechanic. I don't understand this change. What's the case that triggered it? Chases many times end during or right after an "overhead mantling": there's that moment where you never know if you will get the hit or not. I always found this exciting and I never wondered whether "overhead mantling" was right or wrong, fast or slow. "Overhead mantling" has always felt right to me in any situation. My observations: Chances of being hit is reduced to almost zero now Mantling sounds have been limited to one, it sounds boring and repetitive Players can clip through ceilings in some situations It feels a little robotic, for some reason.

Surrounded by greedy noblemen and treacherous siblings, Lady Kamila Leicester gets more than she bargains for after acquiring an ancient tome and performing the dark rituals within. Bikerdude, Wellingtoncrab, Dragofer, and I proudly present Grayman’s FM “Seeking Lady Leicester.” Notes - TDM 2.11 or later is REQUIRED to play this mission. You can get the latest TDM version via the installer or here. - Seeking Lady Leicester was originally a work-in-progress given to the Dark Mod community per Grayman’s wishes after his passing and was initially adopted by Bikerdude before Dragofer, Amadeus, and Wellingtoncrab joined to complete the FM. -This FM does NOT support any unofficial gameplay patch or mod. The use of such a patch and/or mod could break things in this FM. You've been warned. - "Story" subtitles are available for this FM. Simply go to Settings --> Audio and select "Story" or "On" for the subtitles setting. - This FM may be more hardware intensive than normal. LOD settings can be set below "Normal" to improve performance on low-end machines by disabling certain features. - This FM implements the func_peek mechanic, allowing players to peek through any door that has a keyhole on it by leaning forward. PLEASE NOTE: This function has been known to cause crashes for a small number of players in the past, likely due to using the 32-bit version of TDM. At no point in this mission is it required to use the func_peek mechanic; it is purely optional, so feel free not to use it. Download Version 1.1 This FM is available for download via the in-game mission downloader, or here via Google Drive. Promotional Screenshots ThiefGuild Thread Credits A big thanks goes out to Noelker and Goldchocobo for their wonderful voice work with the briefing and conversations, JackFarmer and itsPapiD for their fantastic briefing video, and nbohr1more for his story contributions and writing one particular gameplay feature that I won’t spoil here but you can read about in the readme.txt. An even bigger thank you goes out to our beta testers: nbhor1more, Daft Mugi, Silverwolf, Havoc, Datiswous, Cambridge Spy, Aluminumhaste, Thebigh, Ate0ate, Acolyte6, Kalavi, JoeBarnin. Thank you all very much for your fantastic feedback and tireless efforts as this FM evolved throughout the course of development! Asset Credits - Arx EOS’s Fish - Epifire’s models - Kingsal's Assets and Textures - WellingtonCrab’s assets and textures - Obsttorte's frob loot script - ZergRush's custom Grayman painting ===================Rest In Peace Grayman. You are missed=======================

I think daft said he would consider a variable to try and cover you. It'd be nice to see you acknowledge that you understand while this is your preference it nullifies one of the primary goals of the patch which is to address specific feedback we see from new players who are giving up on playing the game. That is because what seems consistent to you is actually inconsistent with any other game like this they have played. Apologies, it is quit tiresome to emphasize this aspect of the patch over and over again. Everyone respects your preference and understands your feedback, to the point that full backwards compatibility with the original controls has been in the patch since the very beginning and as mentioned daft already said he would consider an option for you. It's just very hard to tell if you do not care about solving this particular problem (which is fine), or you just don't understand at all what the patch is attempting to achieve (also fine). Either way you are asking over and over again to undo this aspect of the patch and never providing an alternative that addresses the same problem. Agreed - my experience is that it feels completely natural to me. Frob being a contextual action - if an object is highlighted in your view you interact with it, if there isn’t one you drop the body. i haven’t run into issues with not being able to interact with doors or even very small buttons like snatcher was describing. Since all the original inputs also still work you actually have multiple options for dropping or snuffing candles you are holding.