Search the Community

Announcing the next installment of 'The Lieutenant' series: High Expectations! Never heard of this series before? That's because I just made it up. Actually, it continues on from my previous FM, In Plain Sight. You don't need to have played In Plain Sight before, but there are some references to it in the readables that might not make sense if you haven't (some of which will be spoiler-ish). "Follow the Lieutenant on his next mission to the City of Highborough" Mission Type: City Missions Beta Testers (thank you all!!! @wesp5 @Acolytesix @Shadow @Cambridge Spy @AluminumHaste @jaxa @thebigh @joebarnin @Mezla @snatcher @datiswous Extra credit goes to @Mezla for providing the idea behind one of the objectives! Notes: TDM 2.11 required You can explore most of the map from the start of the mission, but if you find yourself getting a bit lost or unfocused, just concentrate on the main objective Your objectives will become visible after you read your briefing in your inventory The map does not contain any secrets The only difference in the difficulties is the (optional) loot goal This mission has some replay potential built-in. Explanation below, but I suggest you read this only after your first playthrough: Spoiler warning!: Download links (v1.4): Proton Drive: https://drive.proton.me/urls/ZDTKN6DDM4#8Re0CpARxcbc Github: https://github.com/FrostSalamander/fsx/releases/download/1.4/highex.pk4 Screenshots: https://flic.kr/s/aHBqjAB8qt Known Issues it appears that to some players keys bound to AI are unfrobable. I don't have a solution as I've never been able to reproduce it. As a mitigation, for these doors you can either lockpick them or an alternate key will be available. Other hints Atkinson/Burns objective This objective is more about rewarding the 'explorer' types. It's optional and requires you to find a lot of stuff to piece together the whole story of what happened. Most of these are not really 'hidden', but rather require a visit to most of the accessible areas of the map. If you have given up searching, then: Hotel Safe Combination hint: spoiler: What's going on with Brother Gregory? If this isn't clear, then read on: There's a wooden door in the prison that I can't open... hint: spoiler:

As a player, one thing I'm also not too fond of is the lack of uniformity. I think mission authors should take into account that especially players new to the mod want to figure out how the weapons work, and, they will have a hard time doing so, if many missions tweak the weapons. Apart from the "WTF" moment, they will also not know what the default behavior of the weapon is. Also not a fan of some other things some missions introduce, like the different sounds for foot steps etc. Most of them don't improve anything over the default sounds, to be honest. They're rather worse, and irritate me every time I play a mission with custom sounds.

I created discussion here and mentioned authors (maybe I missed someone though). Unlike the previous thread about main menu GUI overrides, I think the new one does not look aggressive . The main question there is why this was done, and how to adapt to avoid this problem now and in the future. Indeed, all the missions will be fixed by 2.13 even if some authors don't respond. Dev builds regularly break something, although usually it is done unintentionally. I added "known issues" point on the dev build, which happens pretty rarely. I apologize for the negative emotions this change has caused. Sometimes I am too rough in communications. Moreover, I am not a creative kind of person, I'm more a technical type of person. Thus I believe in interface boundaries, so in my mind the blame for breakage is always on the side that violates these boundaries. Anyway, I know I'll have to fix the breakage, probably myself if necessary.

Well that doesn't mean that everyone is d'accord with all the gameplay choices he made in these missions, does it? All I can say is that I never got the impression here or elsewhere that there are issues with the weapon behavior in TDM. Maybe apart from the blackjacking, which has been a controversial topic in the past. I can only repeat myself in arguing that the big problem is the uniformity of essential gameplay elements. The game just doesn't feel coherent, if every FM author changes important gameplay dynamics, and it makes it difficult and frustrating, not just for beginners.

By searching at several music sites on ambient music (looking at the license) Or by creating them ourselfs, https://wiki.thedarkmod.com/index.php?title=Composing_Ambient_Tracks_and_Music_Tracks

Is that really correct? Unless TDM team changed stuff from Doom 3 times, if you use Doom 3 as example, normal maps that represent outward surfaces, use OpenGL system, those that represent inward surfaces, aka holes, use D3D system. On real DirectX renders, outward surfaces, use the D3D system instead and the OGL one for inward, is inverted. And to reinforce this the original example by idSoftware, looks to use the OpenGL system see here cyan for top, purple for the bottom, in d3d is inverted. Thou like I said maybe the TDM team changed all of this by now... edit: Incorrect info so ignore it any mod is free to delete this if he/she wants.

I don't know about actually breaking lights, but I have considered the idea of using water arrows on electric lights to short circuit them temporarily, making them flicker, and go out temporarily. How much they flicker could be set by the modder, and depend on difficulty level.

I plan to gradually try out all or most of the different path node types and adjust them depending on the interaction. Though I don't plan to use it in this particular mission, I have a keen interest in the follow type, as I'll want an NPC to follow the player character in another, future FM I'd like to create. Never too soon to try out various functions while I'm already learning new FM-building skins after a long hiatus. Thank you for the suggestion. I completely forgot about the location system ambients as an option ! A few years back, when I was testing various stuff in DR, I did actually use that approach instead, once or twice. I haven't used DR much in recent years, so I eventually forgot about setting it up that way. Acknowledged, and I'll look into it. It'll save a lot of time concerning the audio side of the mission. My first few missions won't have much a natural environment, they'll largelly be small and focused on buildings or urban spaces, so I won't need to bother with detailed audio for rivers yet. I have an outdoor FM planned for later (it's in the pre-production phase), and I'll have a good reason to study it in greater detail. It's actually okay, I don't reallt need rectangular speakers. Given that I've been reminded I can set a main ambience for each room - something I did know before, but forgot, after not working properly with DR these past few years - I'll do just that, and use the speakers for more secondary ambience concerns. Handy indeed. A rectangular shape would be easier to remember. I'll just use the filters in the editor to put away the speakers if I ever the get the impression they're blocking my view. Also, I don't actually mind the shape all that much. As you and the others say, the size/radius of the speaker is the actual key aspect. I'm a bit disappointed it's seemingly not possible to resize speakers the same way you can resize brushes or certain models, though you can still tweak the radius numerically, manually. As long as I can work with that, the actual shape of a speaker isn't really important. My main concern is expanding the minimum and maximum radius areas to an extent where they'll be audible for most for all of the respective areas the player will visit, rather than fading away quickly once the player leaves the hub of the speaker behind. As was already said above, I'll use the different utility to set the main ambient for the individual rooms, rather than a manually placed speaker, and I'll reserve the speakers for additional sound effects or more local ambience. I've already added some extra parameters to the speakers I'm testing out in my FM, so I'll take a look at those soon, though I'll deal with the main room ambience settings first. I'd like to thank everyone for their replies. While I'm not surprised by the answers, I'm now more confident in working with the path node and speaker entities. On an unrelated sidenote to all of this, the same in-development FM where I'm testing the speaker placement and range was tested yesterday for whether an NPC AI can walk from the ground floor all the way to the topmost floor, without issues. Thankfully, there have been no issues at all, and the test subject - a female mage, whom I won't use in the completed FM, sadly - did a successful first ascent of the tower-like building that'll serve as the main setting. (That's all your getting from me for now, concerning the FM contents.)

For the FM? For beta 1 it's here: https://drive.proton.me/urls/H1QBB04GA0#oBZTb1CmVFQb I've already done around 100 fixes though, so you might want to wait for beta 2 which should be ready in a couple of days hopefully. All links are in the first post of the beta thread here: https://forums.thedarkmod.com/index.php?/topic/22439-the-lieutenant-3-foreign-affairs-beta-testing/

I hope you didn't forget the (controversial) discussion about his implementation of a Resident Evil style save room in Hazard Pay. Or the change to the arrows, which one head shot zombies. These changes are anything but commonly accepted and wanted. Rather something he implemented, because he thought it was a good idea. Which is fair enough, but, it unfortunately leads to the lack of uniformity that I was talking about, when every FM author thinks he has to reinvent the wheel. Especially new players can't get used to how the game, weapons and enemies behave, if the behavior is different in every FM.

dev17042-10732 is public. We decided to restore the ability to create cvars, so the broken missions are "unbroken" as they are. Although I'll still try to hunt down and remove overriding scripts in the future.

A big thank you and congratulations for this mission I would rate 10/10. I can't find a better one in my memory. It's so big and varied, full of new assets. Just... wow ! Finding a way through the was hard for me, as well as being able to jump and go through a narrow hole in the I also gut stuck in this area just below the horizontal mesh hatch that opens with Oh, and my game use to crash when firing a fire arrow at a Thanks again, you are so good at this.

The Numbers don't lie. It has been 15 years since the release of TDM 1.0 in 2009. I think we should consider a contest to celebrate this. Further, the contest goal should be with the intention of motivating the completion of a campaign that can be deemed official. Here are some possible ways forward: Proposal 1: Middle mission(s) Authors are asked to create a mission that expands the story between "A New Job" and "Tears of St Lucia". This can involve escaping the heavily guarded city perimeter, stowing away on a ship or caravan, attempting to recruit a partner for St Lucia and failing, getting caught by Builders before arriving and having to escape their compound, getting lost in haunted woods on the way there, etc. Any interesting way that the connection between the two official missions can be expanded. Points are awarded for making explicit references to Corbin, St Lucia, and any story elements in the two official missions. If the resultant mission is of high enough quality, it can possibly be made into an official mission. If we get a number of excellent submissions and they do not cause logical inconsistencies, we might even be able to add two or more to the official list. Proposal 2: Intellectual Property distinct approximation of TDS missions Over the years, many have asked that we recreate Thief 1 \ 2 in this engine. Obviously we cannot do this due to copyright law but we could create similar missions and stories that approximate the Thief 1 or 2 designs. That said, I think that most of our audience has played these missions to death so it may be underwhelming to see them arrive in approximate form anyway. What might be better would be to develop a similar story to TDS and make missions that resemble what T1 \ T2 players were dreaming would arrive when TDS was announced and the first screen-shots were shown in gaming magazines. So take any TDS mission you like, examine the story arc and wildly re-interpret something similar but on a much grander scale. Since it's possible that two or more contestants will choose the same mission to re-interpret, we have a slot system were authors need to claim their preferred mission and if it is taken then they must select another one or lose some story points. The slots represent a sketch of what the mission author might try to do rather than a blueprint. If authors can come up with a mission that has almost no resemblance to any TDS mission but would make for a compelling story development in a similar story arc then that can be claimed as an alternative to a slot. Proposal 3: Same as proposal 2 but we stick with Thief 1 rather than TDS. Wildly re-interpret T1 based on what you may have dreamed of when reading the gaming magazines or playing the demo. Slots system to prevent duplicate submissions. Maybe with either proposals 3 and 4, we still require the use of Corbin as the protagonist and a connective enough story that they could also be adapted as middle missions for the official campaign if the team agrees on it. Proposal 4: Another "Connections" Contest. We just allow authors to connect any two missions with each other or expand the story of an existing series or single mission. So those are my thoughts. I'll leave it to players and mission authors to suggest other proposals and if we have some sort of consensus about the most popular proposals then we will make a poll. Realistically between now and October we may not be able to hold a contest with any strict guidelines ( and tricky issues with maintaining a distance to Thief IP ) so proposal 4 may still be the easiest option.

@Ansome's question is correct. Nothing in real life ever has a perfectly sharp corner, and one of the pieces of advice often given to newbie modellers trying to make things look realistic and avoid the "obvious CG" look, is to give sharp edges a tiny bevel so they look like something that might be manufactured in real life. The problem you've got in DarkRadiant is (1) dealing with tiny bevels using regular brush geometry is awkward, and (2) brushes aren't smoothed at all (unlike the cube on the right which actually has full smooth shading which you don't notice because of the tiny bevel). So unless you're willing to create imported 3D models with smoothed bevelled edges and place them on the corner of your buildings, adding bevels in brushwork might be more trouble than it's worth. Probably the most important things with brickwork corners is to make sure the bricks line up properly. There's nothing more obviously CG than a plastered-on brickwork texture which just ends in an unrealistic column of cut-off bricks, with mortar joints that are completely unaligned with the brickwork on the adjacent face.

To summarize bullet points: https://github.com/fholger/thedarkmodvr/wiki/Gamepad-support https://bugs.thedarkmod.com/view.php?id=5400 Also an idea is having vibration while lockpicking: http://www.thief-thecircle.com/thief3/saamspreview.asp "Now, what are the differences in the controls between the Xbox and PC versions of TDS? For starters, lock-picking on the Xbox enables the force-feedback on the controller, so you feel different levels of “rumble” as you get closer or farther away from a successful pick. It does make lock-picking easier, especially when you’re in a hurry (while a guard is coming your way!) but you can always turn the rumble off if you’re a purist in playing everything to the hardest level possible."

A stealth way to do this is probably to overvolt the streetlights, there should be a way to do so but tell the player in a roundabout way

The commit which introduced unconditional writing of the s_mindistance and s_maxdistance spawnargs was this one: https://github.com/codereader/DarkRadiant/commit/541f2638c810588ada12e9a28360f16df6143d45 and it appears it was intended to fix this bug: https://bugs.thedarkmod.com/view.php?id=6062 The current logic is to set the spawnargs to the same values as in the sound shader, if a shader is set: // Write the s_mindistance/s_maxdistance keyvalues if we have a valid shader if (!_spawnArgs.getKeyValue(KEY_S_SHADER).empty()) { // Note: Write the spawnargs in meters _spawnArgs.setKeyValue(KEY_S_MAXDISTANCE, string::to_string(_radii.getMax(true))); _spawnArgs.setKeyValue(KEY_S_MINDISTANCE, string::to_string(_radii.getMin(true))); } This happens in the freezeTransform method which is called after performing some manipulation of the speaker entity such as moving or resizing it. In this case _radii is the object which contains the modified speaker radii, so this code is persisting the modified radii into the relevant spawnargs. This seems to be working correctly when I manipulate a speaker with a valid sound shader. The only way I can get 0 is by creating a speaker with a sound shader like blackjack_swing which does not have radii defined. In this case the speaker has a default minimum radius of 0.0 and a default maximum radius of 10.0. We could avoid setting a radius at all, but then the speaker just appears as an entity box rather than a sphere/circle, which I assume is the original reason for setting a default value. Right now I have no idea what code path would lead to having both a minimum and a maximum of 0.0. I think we'd need more detailed reproduction steps. This is the current logic for setting the spawnargs on speaker construction (rather than manipulation, which is the previous code): // Initialise the speaker with suitable distance values auto radii = soundShader->getRadii(); entity.setKeyValue("s_mindistance", string::to_string(radii.getMin(true))); entity.setKeyValue("s_maxdistance", radii.getMax(true) > 0 ? string::to_string(radii.getMax(true)) : "10"); So there is a specific check that s_maxdistance is greater than 0 before setting it as a spawnarg. Code similar to this has existed for many years, as far as I can see, and I have to go as far back as 2009 to find something different (originally all speakers just had hardcoded 16/32 radii to make them visible).

I'm now considering the .xcf files as being in effect the source texture for the game fonts, at least those that have been bitmap edited in GIMP. So that's an argument for putting them in the TDM assets repo. But, in any event, they do need to be backed up somewhere official.

EDIT - v1.1 can be found a few posts below ------------------------------------------------------------------ Nameless Objects Mod v1.0 Description: this mod adds names to almost all core objects players can grab and hold in their hands. ------------------------------------------------------------------- How to use: As of this moment the Mod only works if you have "Core Essentials", which is included in TDM Modpack v4.0. Make sure to have "Core Essentials" and then download the *.pk4 attached to this post and place it in your TDM folder. I try my best to provide stuff people can experience first hand to form an opinion. I suggest you try "Business as Usual" by Bikerdude since this mission includes quite a few items you can grab right at the beginning. ------------------------------------------------------------------- Technical: The mod consists in a couple of def files and a script. I had to include two defs because otherwise there can be issues related with inheritance. The script does most of the work and it will run in the background as soon as a mission starts. The script runs once but it takes its time (10 to 30 seconds) not to hinder performance. All this is transparent to you. ------------------------------------------------------------------ Future: I wouldn't like this to remain as a mod and I volunteer to add names to all core defs for 2.13. I would, of course, use the translation system so that names can be translated in the future to languages other than English. I can name all core defs in a couple of rainy mornings but the Development Team must guarantee this work won't go to waste. The idea is that we name all core objects today and we let it stay: nothing changes in the source code and nothing gets displayed on screen. We get stuff done in the background and someday perhaps, all or part of it sees the light in some form. ------------------------------------------------------------------ There are quite a few things that must be discussed and agreed before we get started but the first step is: yes or no. People that might be interested in supporting and helping with this initiative: @datiswous, @Geep. Cheers! z_nameless_objects_mod_v1.0.pk4

Well, I actually found that initial folder in the HiRes SVN repo. This is different from the TDM assets repo as it has a bunch of source files for textures, fonts, etc, but they aren't really game-ready assets. This is where I found the tga image files for the fonts I thought you were looking for. I haven't uploaded Tels folder yet, but I was thinking of uploading them in the HiRes SVN repo, just for the sake of backing it up

Here's my first FM. A small and easy mission, inspired by Thief's Den and The Bakery Job, where you must find and steal a cook's recipe book in order to save a friend from going out of business. Download: Mediafire (sk_cooks.pk4) TDM Website's Mission Page The in-game mission downloader Thanks to: The people who helped me get this far, both in the forums and on Discord. The beta testers: MirceaKitsune, Mat99, Baal, wesp5, Cambridge Spy, jaxa, grodenglaive, Acolytesix ( Per the author in the beta testing thread. ) Skaruts has given permission to the TDM Team to add Subtitles or Localization Strings to this mission. (No EFX Reverb.) If anyone from the Community or TDM team wishes to create these we will gladly test them and update the mission database.

This is how i18n typically works in code: Developers write the strings in English (or their native language), but mark all the strings with a function/macro which identifies them for translation. In C++ this might be _("blah") or tr("blah") — something which is short and easy to write. A tool (which may be integrated into the build system), extracts all the strings marked for translation into a big list of translatable strings. This list is then provided to the translators, who do not need to be developers or compile the code themselves. They just create a translation for each listed string and send back a file in the appropriate format (which may or may not be created with the help of translation tools, perhaps with a GUI). At runtime, the code looks up each translatable string, finds the corresponding translated string in the chosen language, and shows the translated version. At no point do developers (who in this case would be mission authors) have to mess around with manually choosing string IDs. All they do is use the appropriate function/macro/syntax to mark particular strings as translatable. String IDs may be used internally but are completely invisible to developers. I suggest that any system that involves instructions like "search the list of known strings for a similar string" or "manually choose a string ID between 20000 and 89999 and then write it as #str_23456" are over-complicated, un-ergonomic and doomed to be largely ignored by mappers.