Search the Community

@datiswous, made that correction fm_test.subs --> fm_conversations.subs @stgatilov, about srt naming and file location, would you be OK with the following edit? New/changed stuff in italics: srt command is followed by paths to a sound sample and its .srt file, typically with matching filenames. An .srt file is usually placed either with its sound file or in a "subtitles" folder. The .srt file format is described e.g. [1]. The file must be in engine-native encoding (internationalization is not supported yet anyway) and have no BOM mark. It contains a sequence of text messages to show during the sound sample, each with start and end timestamps within the sample's timeline. It is recommended to use common software to create .srt files for sound samples, instead of writing them manually. This way is more flexible but more complicated, and it is only necessary for long sounds, for instance sound sample of a briefing video. It's a simple enough standard that it can be shown as an short example, demonstrating that subtitle segments can have time gaps between them. And the example can show correct TDM usage, without requiring a trip off-site and picking through features that TDM doesn't support. Specifically, the example shows how to define two lines by direct entry, rather than using unsupported message location tags (X1, Y1, etc.). And skips other unavailable SRT font markups like italics, mentioned in the wikipedia description. The example would also show the TDM-specific path treatment. The example could be inserted before the sentence "It is recommended to use common software...."

Suppose we had a system like this: "verbosity story" are small width=0 by default "verbosity speech" are small width=1 by default The default of either can be overridden on a per-subtitle basis by using new option "-smallWidth" or "-sw", e.g.: with verbosity story inline "something.ogg" "I've hid the gem in m'lady's knickers." -sw 1 srt "something.ogg" "something.srt" -sw 1 // sw affects all messages of this srt the same with verbosity speech (as an alternative to breaking into individual messages and using srt) inline "yetmore.ogg" "I need to cast that spell tonight after midnight,\nbut once again, my supply of eye-of-newt is sadly depleted." -sw 0 #define FIELD_MARGIN is not anywhere official yet, just in my prototype tdm_subtitles_common.gui, hidden in yesterday's post. The values I show are from my analysis and testing, earlier reported in this thread and/or AI Barks.

Hidden Hands: Vitalic Fever Filename : hhvf.pk4 Date of release: 20/07/2019 Latest Version: 3 (17/02/2021) Download via the in-game downloader or here: http://www.southquarter.com/tdm/fms/hhvf.pk4 http://darkmod.taaaki.za.net/fms/hhvf.pk4 http://www.fidcal.com/darkuser/missions/hhvf.pk4 Known bugs: - stencil shadows do not work correctly (version 1) - sometimes, the character "Applefinger" cannot be knocked out when sitting on the chair without failing the mission. (version 1) Hidden Hands Series: I. Initation - II. Vitalic Fever Jack Farmer: mapping & drafts Amadeus: alpha testing, geometry fixes, performance checks, drafts for gameplay and objectives, revision of all readables, dialogues & narrator texts Grayman: AI fixes, gameplay fixes, trap fixes Duzenko: alpha testing, performance checks and improvement tips Beta Testers: - Joebarnin - Cambridge Spy - Boiler's Hiss (aka "The architect's darling") - Jedi_Wannabe (aka "The man of many voices") - Amadeus (aka "The Writer") Voice actors: Malasdair Narrator Jedi_Wannabe All four guards chatting about the guests, chickens, inventions and unusual job interviews New Horizon The educated Builder Goldchocobo The naive Builder Special thanks to: - Springheel, Sotha, and Fidcal for the tutorials. - VanishedOne, Stumpy, Destined, Grayman, Joebarnin and ERH+ for patiently answering my questions solving all the in-game problems. - PsymH (aka "Stringer Bell") for connecting me with the right guys on TTLG for additional voice acting. - Goldwell for teaching me how to integrate a custom video in a fms and helping me with troubleshooting during the integration of one of the Builder's voices. - all voice actors & beta testers for their great support. - all others not mentioned here who answered my questions in the Newbie thread or via PM. Contributors from the Inventor's Guild: - Destined wrote a new definition for the "spidsey-babsies", enabling those beasts to move through tunnels. - Grayman wrote a script enabling Halfrid to hold the quill only when it is needed. He also fixed several other AI problems with respect to path finding, damages and interaction with light switches. Pilfered items: - Portal sky with hills and trees originally developed and arranged by Sotha for "Thomas Porter: The Transaction". - Frobbox booster re-created from a map originally developed by Grayman All new ambient music and sound effects written, performed and mixed by Jack Farmer. Briefing video by SirSmokeAlot Pictures

Announcing the release of the first William Steele mission! Summary In the North is a mansion heist that takes place outside the town of Braedon, north of Bridgeport. William Steele is an adventurer from Bridgeport who has been away several years, working as a soldier/guard for one Lord Bascombe at his castle in Braedon. Lord Harckoff, a nasty fellow who lives in a renovated Builder church nearby, sees Bascombe as a threat to his shady business, and has put a price on Bascombe's head. Steele decides to visit Harckoff one night to see what he can do to prevent Bascombe's death. The William Steele Missions In the North is the first of several Steele missions. Altogether they'll tell a story of corruption, greed, and revenge. At some point, I'll start packaging them as a campaign, in addition to the single missions. Download This Mission can be obtained using the in-game loader. Look for WS1: In the North. Mission Details and Download: http://www.thedarkmo...ndetails/?id=65 Build Time About one year. Thanks Thanks to the TDM team for creating a terrific platform for storytelling and stealth gaming. Thanks to Bikerdude, Springheel, and AluminumHaste for beta testing, especially at a time when we were all busy dealing with the final phase of TDM 1.08. The Translators (Smallman, Overmann, and Sengu) are hard at work on translations for various languages, so thanks go out to them as well. Localized versions will be available after they're completed and tested. And thanks to YOU for playing! Known Issues This is a large non-linear mission. To ease the burden on slower systems, consider shutting doors behind you as you go. If you experience low frame rates, please consult the Performance Tweaks page on the Wiki. Performance Tweaks For very low end PCs I recommend the following settings: V-sync is offAA is offAniso is 4x or lowerAdvanced settings are simple/defaultPost processing is disabledAnyone having performance issues with TDM missions can put the following cvars into their Darkmod.cfg file. This will improve the framerate and stutter/chop when in-game, but may increase loading times a little. image_usePrecompressedTextures "1" image_useNormalCompression "2" image_useAllFormats "1" image_useCompression "1" image_preload "1" Important This mission requires TDM 1.08 or later. Repeat after me: "Read and explore, Read and explore". Most Importantly, Enjoy! Screenshots WS2: Home Again Steele's story continues with Home Again, which you can find here.

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

I'm looking for a small number (3?) of beta testers for my new mission "The Heart of Saint Mattis". It'll be ready for testing in the next day or two. Sign up here, and once we get a quorum I'll create a topic in the Beta Test section. Regards, joebarnin

OK I think I've got to the bottom of this. I've created this forum thread (with bug report): https://forums.thedarkmod.com/index.php?/topic/22221-bug-drowning-ai-in-shallow-water/ I can apply a workaround, although it won't be perfect and the bug itself needs fixing in the engine. There are a few other things that need fixing so will put an update together soonish.

If any mappers have encountered weirdness with kill objectives not working with drowning AI, I think I've found out why. I don't think it would be a particularly difficult one to fix either. I've raised this bug report: https://bugs.thedarkmod.com/view.php?id=6323 Some context here: https://forums.thedarkmod.com/index.php?/topic/21837-fan-mission-the-lieutenant-2-high-expectations-by-frost_salamander-20230424/&do=findComment&comment=487316 I think this is a bug, but just raising here in case some people think otherwise.

Congratulations on the release. It's a neat little level and I had fun testing it.

My own take on the beta process is that devs on one side commit to adding and improving features, but also to ensuring that the new releases are, as far as reasonably achievable, free of bugs and that the new features aren't broken on release. To balance that we have a general policy to freeze the code when the beta starts, where code changes should primarily be fixes to issues detected in the beta. Exceptions are made on a semi-regular basis for changes that go further if they can be justified. That's mainly the case when there's still enough time left in the beta to get the changes properly tested and reviewed, or the risk of breakage is low i.e. because you're adding, but not changing things. For example, I worked extensively on assets this release cycle and didn't manage to get all the work done before the beta, so I was still busy until about the middle of the beta phase. However, I prioritised my work so that asset changes were ready ahead of the beta, while asset additions (which won't break anything) were made during the beta. I also treaded particularly carefully when adding the new assets to compensate for their shorter beta testing time. I might not have been around as much lately, but I only heard of Daft Mugi's slew of patches when we were discussing whether the next beta build should be the release candidate, which gets released as-is if no significant issues are reported. At that point any changes will either prolong the beta testing phase, or carry the risk of not working as intended. The plan was to reach this point at the end of january (if this was not prominently communicated somewhere it was a mistake). Personally I definitely see the value in trying to accommodate as many of these changes as possible because they make TDM more attractive to Thief players, Daft Mugi is even standing ready to introduce them to the TTLG community, and it looks like they're fairly simple changes. However, prolonging the beta comes with its own drawbacks. One is that players and mappers are delayed in getting access to all the other new features. Another is that the beta phase is a relatively draining part of the release cycle for the devs because new projects are mostly on hold while the focus is on getting to a stable build. One of the ideas behind dev builds was to shorten the beta phase by spreading out the testing. Ultimately, we've designated Stgatilov as the project lead so it's his task to call the shots on how to balance these demands.

After testing I think I like daft mugis version better. Right mouse double clicking works, but doesn't feel nice especially after a period of play. The only big issue I have with daft muggies version is the long press moving body doesn't toggle. This makes moving bodies a shore.

I guess I'll chime in here for clarity. When the TDM Dev Build thread is active: This is when big changes and contributions are supposed to be welcome. When we are in "Beta Testing" it is supposed to be a code freeze period where only regression fixes are applied. Sometimes a fix or improvement that shouldn't be in a beta phase gets added anyway if it is seen as exceptionally beneficial, but every time this is done it can potentially extend the beta testing for another 2 weeks or more and during that additional 2 weeks even more fixes and improvements are proposed by eager contributors which can potentially lead to a never ending beta. I am not particularly bothered by a long dev build phase, nor a long beta and am inclined to wait a long time until new official releases are available. Players, on the other hand, generally aren't keen on using Dev Builds so we need to stop at some point and christen something as official if only for the sake of getting more feedback in case regressions slipped through Dev or Beta testing. Let's be clear though, neither TDM 2.10 or 2.11b7 are "unplayable garbage". Enhancements are fantastic but if 2.11 doesn't include every improvement you can conjure it will still be better than 2.10 which is already an excellent TDM version. I am still in favor of most or all of your improvements making it into 2.11 but we have to follow the process and need to have agreement from the team about what happens next. If you disagree with the way that we rollout "dev > beta > release" cycles and want to offer your fixes before they go into TDM official release, I suggest you consider creating a fork project. You can call it "The Darker Mod" , "Better Dark Mod Enhanced", etc, any of the monikers you typically see on enhancement projects on Moddb. If your fork becomes popular then it may be the main one that players use sorta like how Debian Linux is the core project but most people use Ubuntu or Linux Mint. ( If you made such a fork, I would probably ask that you integrate my fresnel shader mod into it. )

I was thinking about the concern @snatchermentioned about this making the ability to manipulate bodies around prohibitively tedious. I think there a bit of truth to that. I don't think it's that bad: I just manipulated a body around with not much hassle. But I can see how the delay might end up feeling like a stone in your shoe, for someone who does this often. But as I was testing this, trying to manipulate a guard around, I noticed that most often when I want to manipulate, I have a tendency to want to not just click and hold, but to also drag the mouse (or start walking). And that's where the delay interferes a bit. So I was thinking, maybe the implementation could also detect mouse dragging after the initial click, and immediately enter manipulation mode when it detects it? (Maybe it would be wise to still have a slight threshold for this? Not all mice and hands are exactly steady when clicking, so I suppose there might be a slight unintentional movement. I suppose this would have to be better thought about and tested.) And maybe the same could be said about detecting walking right after the initial click.

Hidden Hands - Vitalic Fever will be ready for beta testing in a few days. Play time should be around 1 - 2 hours. Map size is ca. 25% of "Initiation". Please sign up here. Would be good to get two people on board as Amadeus will also have a closer look. Cheers! Jack

How you can help depends a lot on what skills you have. I can Record Video Recording "Let's Play" videos or simple walkthroughs of existing missions and posting them to Youtube is great exposure for the mod (see example .) Be sure to let us know so we can link to them. If you have some editing ability, Video tutorials, where you explain how the mod works, or how to use specific tools, would also be great. Video trailers, showcasing interesting places and features, are also great for publicity. An example is . I can Write Writing reviews for missions are always nice, especially if they include good screenshots. Not only does it give us something to post on other forums, but it makes mappers feel good when their mission gets attention (especially if it's positive). We have a collective thread to post reviews in: http://forums.thedar...s-walkthroughs/ Writing reviews of the mod as a whole, targetted an an audience that doesn't know much about TDM, is also very useful. You could also try offering your services to mappers to create interesting readables, or to proofread for their mission. I can Act and Record Audio We are always on the lookout for good quality audio recordings for vocal sets. If interested, you can pick a few different lines from this script: http://wiki.thedarkm...t:_Average_Jack and send the recordings to Springheel, who then writes a script based on the type of voice you have. I can Translate We could always use translations of our menu/hud into more languages. Also, only a few FMs are aavailable in more than one language, so there is a lot of work there, see the I18N Translator's Guide in the Wiki. I can Model Great! Take a look at the model request thread:http://forums.thedar...-requests-here/ and pick something that interests you. Or just post a, "Hey, anybody want a model?" thread in this forum and I'm sure mappers will get back to you. I can Animate Fantastic. We can always use more good animations. Our current character rigs use a Maya skeleton. PM Springheel for more info. I know C++ Have a look at our coding section in the wiki, pick an issue or feature from the bugtracker of the mod or the leveleditor, download the recent sourcecode release (or better ask for an SVN checkout) and get cracking. Make sure nobody is already working on that specific issue and feel free to ask questions. I can Edit Images We can always use completely new textures and/or improved versions of older textures. How to get started and how to import them into the mod. I can Take Photos Good quality photos of useful textures (medieval-ish building facades, dirt, rocks, wood, etc) are always welcome. The fewer directional shadows and higher resolution, the better. I don't have any skills Even if you can't do any of the above, you can still help out. Talk about TDM in other forums; share your (preferably positive) experiences with other gamers you know. Last, but not least, compliment people when you like their work. Saying "thanks", to a developer or, "I really enjoyed your mission" to a mapper will make their day. -------------------- I'll update this further as more things occur to me.

I came across this site: https://www.rijksmuseum.nl/en They offer incredible quality pictures of art. I emailed them about including their images free of charge under CC license and they replied with: They are pretty amazing quality, just for testing I made one with a pretty picture and threw it in the game. They have a ton of stuff that would fit our time period I think. https://www.rijksmuseum.nl/en/rijksstudio

This just isn’t a true description of the scope as lined out in the original post. Why is it that you feel there is reason enough that you get to decide to just change this? Why is a change which is completely backwards compatible with the existing control scheme “radical”? It is clear in this thread there are players that want this, and anyone who doesn’t doesn’t have to use it. Why at a minimum can’t it go out for testing with more players in a proper dev build like the frob highlight did?

This, just like click again to drop a body, is already included in the patch. If a switch, button or door are highlighted you will interact with them without dropping the body. There are probably more objects this would need to cover which will come up with more testing (readables maybe?) Seems like elements of the patched executable aren’t working with your install for some reason?

Author note: It's hard to believe it's already been a year since Act 1 came out! Well during this mission the player will be following Corbin into the Grimwood district to followup on a lead from last night (Act 1) .. the mysterious tablet! This mission is my first time including full EFX support as well as a HD briefing video file, additionally a new script has been added crafted by the talented Obsttorte which has loot flying towards the player when you pick it up. On a level design front I have tried to change things up a bit by really catering towards a number of play styles, this mission can be completely ghosted or you can use the tools at your disposal to wreak havoc on the citizens of Northdale. For the first time I have tried to create more sandbox environments which don't offer clear answers handed directly to you, so if you're having trouble figuring something out try a different method. This mission takes between 1 - 2 hours to finish depending on the difficulty you play on and how thoroughly you explore. I hope you enjoy your night in Northdale! - Goldwell Voice actors Fen Phoenix Goldwell Random_taffer Yandros Beta testers Amadeus Boiler's Hiss Cambridge Spy Chakkman Crowind Epifire Kingsal SquadaFroinx Custom Assets Andreas Rocha DrK Epifire Grayman Kingsal MalachiAD Obsttorte Sotha Springheel SquadaFroinx Purgator With special thanks to Epifire for creating a large collection of custom models, Grayman for helping out with coding, Kingsal for drawing the ingame map and Moonbo for his script revision on the briefing video. Available via in-game downloader MIRROR File Size: 417 mb EDIT: If you are having performance issues please consult this post by Nbohr1more which may address your issue http://forums.thedarkmod.com/topic/19936-fan-mission-shadows-of-northdale-act-ii-by-goldwell-20190320/page-2?do=findComment&comment=436271

Quick-press frob Pick up body and shoulder it (carry it) / Drop body Pick up candle/lantern and carry it / Drop candle/lantern Pick up an item and carry it / Drop item Long-press frob (for special action) Drag body or body limbs Pinch out candle (also, pinch out candle while carrying it) Toggle lantern off/on (also, toggle lantern while carrying it) Not many words at all. Have you tried the Windows build that @Wellingtoncrab made yet, or did you just think about this? I'm a bit surprised that you are not for this change. It seems like something you would like. This change is something best felt while playing. During early testing, those who tried it out in game liked it.

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!