Search the Community

You can try my alternative footstep sounds package which addressed the things you described together with a lot of other footstep sounds both for player and AI if you want to. https://forums.thedarkmod.com/index.php?/topic/17631-new-footstep-sounds/

Mods can this moved again? @Acolytesix- can you make sure you post in the beta thread instead of this one please (this one is public, the beta thread is only for logged-in forum members): https://forums.thedarkmod.com/index.php?/topic/21822-beta-testing-high-expectations/

sure - I would only ask that you follow the thread to make sure you don't report stuff that has already been mentioned: https://forums.thedarkmod.com/index.php?/topic/21822-beta-testing-high-expectations/

Wow I just completed the mission, but it looks like I need to go back in and look around some more. So many streets and paths and open windows - this map is a thief's dream

The spoiler tags aren't for you, it's for the rest of us reading this thread so WE don't get spoiled. Thanks for spoiling the frobbable book on a shelf for the rest of us. EDIT: I'll be unsubscribing to this thread to avoid further spoilers. Maybe I'll check back after I've finished the mission Amadeus

I have switched our Matrix4 class to use the Eigen library internally (more specifically, an Eigen::Transform which can represent geometric transformations which decompose to a 4x4 Matrix). The advantages of Eigen are: It's a well-tested and respected linear algebra library, which means we don't need to maintain our own code to perform already-solved problems like matrix multiplication. It can potentially use SIMD instructions (SSE, AVX etc) to improve performance. I haven't yet looked into whether this happens automatically or whether we have to explicitly enable these optimisations. It is header-only, so should not present any build issues on the various platforms. Our Matrix4 class still exists but it is now just a syntactic wrapper around the Eigen implementation, and several methods which performed matrix maths manually have now been changed to forward directly to Eigen methods like inverse(), transpose() etc. Since Matrix4 is now well covered by unit tests, I am pretty confident that nothing is broken because of this change, although it's still possible of course. @greebo Next time you pull from my master branch, you will need to do two things: Issue the git submodule update -i command (or GUI equivalent, if you're using one) to populate the external/eigen directory with the Eigen git repository. Update include paths in the VS project so that external/eigen is added to the header file search paths. Since it's already cross-platform and header-only, and the only current usage is with an existing class wrapper, I hope no other changes should be required on Windows.

heh i was thinking the same though it might just have been a glitch when writing the names are pretty similar. But for correctness it is called the dark engine and the newer version that allows us to run these beauties on win10/11 is called newdark. newdark is kinda interresting as it just suddenly popped up on a french forum some time ago by an anonymous developer with the alias le corbeau who allegedly got his hands on the original source code and started updating it for modern OS. this was the original thread i believe -> https://www.ttlg.com/forums/showthread.php?t=140085 bikerdude was on that forum to when the patch hit i noticed hehe.

Not that it's relevant, but, I strongly dislike random patrol paths. For quite a simple reason: If I hire guards to guard my property, I'd expect those guards to cover a preferably as big as possible area. Without having all guards potentially at the same spot at the same time, leaving big areas completely unguarded. I can understand that random paths might, just might be a thing for NPC's which don't guard anything, but, for "real" guards, it absolutely makes no sense to me. For example, I played a mission once (won't name and shame, but, it's pretty well known), where I had 3 guards in the same room at one time. Or another where guards occasionally visited the kitchen, and one by one and more and more came, until I stockpiled the bodies in the kitchen's restroom. And when I had 6 NPC's already stockpiled there, another came, took a look inside the restroom (!), and noticed all the bodies in there, and was permanently alerted. It not only makes no sense, but, it even totally wrecks the gameplay, at least if you are looking for those very rare spots where you can actually drop bodies. I think a lot of mission makers make a big mistake by allowing such random paths, not only from a common sense point of view, but also from a gameplay point of view. A.I. has to be predictable to some degree. You can frequently read about that as well in articles about game design. It robs games off its fun and joy to play, if A.I. is totally unpredictable, and it's not realistic either. A guard has its patrol path, and, it's also appointed with other guards, otherwise guarding a mansion or anything else makes no sense, if everyone is stepping on each other's foot. That's my view, which of course nobody has to agree with. But, it's not just subjective really. There are good rational reasons for NOT having guards act unpredictably. Actually, I think another approach would be much more realistic, and also would make much more sense: A guard has a set patrol path, but, every now and then (maybe every 3 rounds he does), he sits down to eat something, or just gets a rest, making way for the player to exploit the situation by sneaking past him. That's not only more fun, it's also more realistic than a guard which is all over the place.

Personally I think this is the worst idea ever. The Reason forums has LOADS of info and knowledge, built up through years and years. I'm really sad to see it go away, and I can't understand why they've made this decision. https://www.propellerheads.se/forum/showthread.php?p=1579099#poststop

I've been thinking about this for some time. I think the layers and filtering systems could be greatly improved, and, having used Hammer extensively in the past, I can't help but bring my ideas from it. Because, tbh, I think Hammer's way of doing this is the very best example of how we could improve layers and filters (for some odd reason, no other editor that I've used does a good job at this -- not even TrenchBroom). And the reason I'm putting layers and filters in the same sentence here, is because they're actually the same thing (or ought to be). I'll explain that below. On layers: One of the issues with layers is that the interface is a bit bulky. I've had to make extensive use of them since I started a complete overhaul of the mission map I'm currently building, because it's easier to work with layers than with regular grouping (because you need to ungroup to edit stuff, then probably isolate things, then re-group them). But I've been finding layers quite unwieldy as well. This is how my current layers list looks like: It doesn't fit my screen anymore. But you might notice another issue: I've resorted to using underscores and prefixes (or CAPS) to try to keep them organized, because there's no way to group layers by their relationship. But I think there's also something to be said of the rename/delete buttons, which could be on a drop down menu, to save screen space. As it is, I've had to keep reducing the size of my DR window to allow more and more space for the layers panel, as the names grew wider and the buttons became hidden. Another issue is the buttons that are at the bottom will go off into oblivion when you have so many layers. I think they might be better off in a toolbar at the top. Yet another issue, is you can't hide things that belong to more than one layer, if one of them is set to visible. The visible one will always override visibility to on. Say you have stairs on floor1 and floor2, and you want to nudge floor1 stuff but not the stairs. In that case it's easy to deselect just the stairs and nudge away, but you might easily imagine it becoming complicated when you have many more things to deselect that overlap between two or more layers. You'll forget some, and you may not notice your mistake soon enough. So it would help if you could select floor1, then hide floor2, and it would hide all the overlapping content with it, removing it all from the selection. As another facet of this issue, I have a layer there called new___thug_house, which was supposed to contain the entire house, but doesn't have anything in it anymore, because when it did, then I couldn't hide anything by hiding the other layers. And so at this point, the only way I have to select the entire house, is by clicking all the layers one by one (which is one reason I didn't create even more layers related to it). On filters: The main issue with filters is that you have to either keep browsing the menu, or remembering whatever hotkeys you reserved for it. E.g., I have ALT-P, ALT-SHIFT-P for patches or paths, and ALT-C, ALT-CTRL-C and ALT-SHIFT-C for clips, collisions and caulks, but I often forget which is which, so, for me, there's always a bit of recap trial and error involved in using some filter hotkeys. I suspect this is also a limiting factor on how many filters DR offers by default, or even how many users can feasibly create. Because the menu would grow even more unwieldy if DR would support even more filters, and you can only feasibly have (and remember) so many hotkeys with a consistent pattern. Now, Hammer did this this pretty well. And the way it did it shows layers and filters ought to be the same thing. It was all in one place. To be perhaps a bit pedantic, let's face it, the concept of "layers" doesn't apply anywhere in the context of a map (TrenchBroom is doing the same mistake). If we call a spade a spade, then "groups" is what layers actually are. Or more accurately, "visibility groups", which is what Hammer rightfully called them (VisGroups, for short). Here's what VisGroups look like in Hammer: They are compact and still fit my screen (on a map that reached the limits of Hammer (8192 brushes)). But even if they didn't, the tree structure makes it easy to collapse them. And it also makes it easy to organize things. In the way Hammer did it, you can also toggle off a parent visgroup and then toggle on a child visgroup to override visibility. Or, you can do that with unrelated overlapping visgroups as well. The last group you toggle on/off will override the objects it contains to visible or hidden. Now, you might notice there's an "Auto" tab at the top. This is where filters come in. As you're editing your map, Hammer automatically creates visgroups for all the things you have as filters in DR and more. There's no need for menu access or hotkeys, they're all right there at the tip of a single mouse-click, and are listed in the same place as other visgroups (Monster clips would be listed under "Tool Brushes -> Clips", but this was a deathmatch map, so there aren't any). And if you need to disable all filters you can just toggle the parent node off. DR actually has one advantage in this: it already allows the user to create custom filters. So with a system like this one, it could support more (and more specific) filters by default, as well as allow users to expand it.

Cleaning Up the Neighborhood by some1stoleit, bikerdude Brief Description: A small-medium sized assassination mission, taking place in a bar and casino environment with streets surrounding the bar. Story: Crime is out of control in my neighbourhood, when thugs attacked my wife I decided I can no longer stand by idly. Unable to rely on the corruptible city watch and the aloof Builders, I must take matters into my own hands. My first target is a bar called the Scoundrel’s Rest which is not far from my home. It’s owned by a man named Godfrey and considered neutral ground to the various criminal factions inhabiting the city district. There is no doubt its presence attracts criminals towards my neighbourhood, contributing to the infestation of crime. Infiltrating the bar not only creates the opportunity to kill Godfrey and shut it down for good but also allows me to find information about the rest of criminal groups that inhabit my neighbourhood. I gave my thieving days when I met my wife, but for her sake I must take up the profession once more and prowl in the shadows again. Notes/Tips: Your lock picks are noticeably old, so you can’t rely on them to get you past every door. Examine the environment and keep an eye out for keys on pockets.If you see a pipe outside, chances are you can climb up it.On Rusty and Practiced difficulty settings there's a map available for the bar’s ground level and the street surrounding it.It should be possible to ghost the every area in the mission. A small amount of loot however may be difficult or impossible to acquire without knockouts.There are a few hidden optional objectives you can discover. Screenshots Download Mirrors: https://www.dropbox.com/s/rbiashq1c1k56ns/Cleaning%20Up%20the%20Neighbourhood%20v1.0.zip?dl=0 https://mega.nz/#!bMtgiSra!Y1KXGovfYfdtG1xxRkmPYndLxgq7wMNVr8oENnS2Qxg FAQ: I dislike when I get stuck on an FM and have to leave the game to scroll through forums to find out what to do. I think the mission should be straightforward enough to beat without answers, but I will provide a FAQ if it’s needed. Just be sure to give a good try working it out yourself before reading this. Thanks: I’ve found the TDM community very welcoming and helpful as a new member and would like to thank several people. Bikerdude, for allowing me to collobarate with him and showing me a different way to build maps from scratch in Dark Radiant, as well as many other mapping techniques.Resources:Springheel, for his Modules and his retroactive permission to use New Job street segments.Amadeus, for doing some proofreading of the briefing and readables.Obsttorte, for his objective checking script used for one of the optional objectives.Rsoul, for creating new internal version of architecture models.Beta Testers:Amadeus, Cambridge Spy, Abusimplea, Shadow, Boiler’s_hiss, nbohr1more, Springheel, JudithPeople who helped Answer my Questions:Destined, JackFarmerSpecial thanks to Sotha and Springheel whose video tutorial series give me the guidance and confidence to start using Dark Radiant.I apologise if I missed anyone, if I missed you please do contact me and I’ll credit you appropriately. About the Development: Initially this was a solo developed mission made by myself, upon some beta testing I agreed to make the mission collaboration with Bikerdude, with the intention to learn good mapping practices from the collaboration. The mission was redesigning using the same layout as the original but using Springheel’s modules instead of my very simple brushwork, and expanded in scope to include a more detailed street, a canal, a sewer and a rooftop segments. Bikerdude’s use of springheel modules and custom skins is mostly responsible for the beautiful visuals, with my contribution being the layout of areas and the writing. Known Issues: None at the moment.

Welcome to the New Mappers Workshop! This is a communal workshop for new mappers who have never made a TDM mission before. Each week or two I will make a tutorial video and help to guide everyone through the process of creating a small, complete mission. I'm hoping the participants will feel free to ask questions, no matter how small--we're all here to learn from and encourage each other. Since I expect this thread to get fairly busy, I'm going to be heavy-handed about removing off-topic content. ====================================================================================================================================================================== Lessons often include links or other written instructions; direct links to the lessons are collected below: Lesson 1: Planning http://forums.thedarkmod.com/topic/18945-tdm-new-mappers-workshop/?p=407999 Lesson 2: Visportals http://forums.thedarkmod.com/topic/18945-tdm-new-mappers-workshop/?p=408253 Lesson 3: Your First Room http://forums.thedarkmod.com/topic/18945-tdm-new-mappers-workshop/?p=408484 Lesson 4: Decorating Your Rooms http://forums.thedarkmod.com/topic/18945-tdm-new-mappers-workshop/?p=408785 Lesson 5: Connecting Your Rooms http://forums.thedarkmod.com/topic/18945-tdm-new-mappers-workshop/?p=409215 Lesson 6: Outdoor "Rooms" http://forums.thedarkmod.com/topic/18945-tdm-new-mappers-workshop/?p=409322 Lesson 7: Creating Doors http://forums.thedarkmod.com/topic/18945-tdm-new-mappers-workshop/?p=409547 Lesson 8: Functional Props (ie, entities) http://forums.thedarkmod.com/topic/18945-tdm-new-mappers-workshop/?p=409731 Lesson 9: Immersive Details (sound/particles) http://forums.thedarkmod.com/topic/18945-tdm-new-mappers-workshop/?p=410258 Lesson 10: Advanced Brushwork (ladders/water) http://forums.thedarkmod.com/topic/18945-tdm-new-mappers-workshop/?p=410667 Lesson 11: AI http://forums.thedarkmod.com/topic/18945-tdm-new-mappers-workshop/?p=411192

Fond of your first FM, I was quite eager to jump into this one. The story had me hooked right away. Pretty great idea on your part - putting the player in the shoes of an infiltrator tasked with unraveling a conspiracy and searching for a missing agent. You really managed to find a good reason to give the player the incentive to steal while playing a character who is not a thief by nature. The map is well designed, with plenty of paths one can take to reach another place. As I am fond of tight alleyways and verticality, this was a joy to explore, especially since there is plenty to discover, be it secrets or readables adding to the story. The rain was neat and added to the gloomy atmosphere, another thing I enjoy in FM's. The optional side objectives were a neat addition too. The only difficulty encountered was that at times I had to abandon my current path and hunt for a key to unlock the way forth, but nothing to seriously disturb the flow of the FM. Found 3/5 secrets, so there is still more for me to explore. The secrets are really well hidden and yield nice rewards, I'll get back on the weekend and hopefully find the remaining two. Thanks for another wonderful FM! Possible bug

DarkRadiant 2.12.0 is ready for download. Feature highlights include a new customisable GUI and the first iteration of the Material Editor GUI. Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/2.12.0 and of course linked from the website https://www.darkradiant.net Thanks go out to all who helped testing this release! Please report any bugs or feature requests here in these forums, following these guidelines: Bugs (including steps for reproduction) can go directly on the tracker. When unsure about a bug/issue, feel free to ask. If you run into a crash, please record a crashdump: Crashdump Instructions Feature requests should be suggested (and possibly discussed) here in these forums before they may be added to the tracker. Changes since 2.11.0 Feature: Customisable GUI layout Feature: Extended MaterialManager scripting interfaces by manipulation methods Feature: Material Editor GUI Feature: Same origin / duplicate detection script Feature: 3D grid feature Feature: Show light_radius on 'other' entities Feature: Show attached (light) entities Improvement: Better support for stage transform keywords in idTech4 materials Improvement: ESC to close dialogs with Cancel Improvement: Add portal_sky filter to default filters Improvement: Copy model/entity/prefab paths to clipboard (context menu in tree views) Fixed: Material stages with alpha test are incorrectly rendered as translucent Fixed: ASE importer needs to handle shared vertices with different normals Fixed: Ambients don't light sides facing away Fixed: Table lookup evaluation is not producing the same results as in the engine Fixed: Attached light radii are the wrong colour if "Override light volume colour" is active Fixed: Add missing image dimension reads to Quake 3 legacy brush parser Fixed: Opening the Create Entity dialog a second time will present an empty tree view Fixed: "Toggle 16x16 grid" function in the Particle Editor broken Fixed: Use of BITMAP field in ASE differs from TDM Fixed: Newly added or imported items don't use the location of previously selected item Fixed: Newly drawn brushes don't use height of previous selection with "Show Size Info" switched off Fixed: Rotation widget does not re-center on selected object Fixed: Duplicating model and moving with Alt-arrow results in pivot on original model when trying to rotate afterwards Fixed: Brushes with no visible surface towards orthoview "camera" are invisible in orthoview Fixed: Can't select one-sided models in certain 2D views Fixed: Twosided models can only be selected from one side The list of changes can be found on the our bugtracker changelog. Have fun mapping!

William Steele - In the North. It leads to some pretty odd stuff though. Like, 4 or 5 guards entering the same place after a while, making it hard to hide bodies. Apart from that, any kind of unpredictability (also in the guard routes) makes it hard to knock out enemies. Apart from being unrealistic. Guards should have a set path, and not intervene with other guard paths. Also, how many guard shifts can there be, when the player plays a mission, for, like. 2 to 4 hours? And, different players take a different amount of time in missions. Some rush through, some explore every little corner of a map. For timed events: I strongly dislike them. Especially as the mission and the objectives must be very well designed, otherwise the player could stumble across the map, not knowing what to do and where to go to reach the objective before the timer ends. I also don't like the hassle. I like to take my time, and enjoy exploring a lot of the map, and, timed events make that impossible most often. There is a reason why none or only the least missions feature all this.

Interesting, although I'm not sure what to make of that. One of my favorite games (The Chronicles of Riddick Assault on Dark Athena) was published by Atari, and, they don't even seem to care to keep the activation servers running much. Or remove/change the copy protection, which doesn't work at all on Windows 11. I really hope that Nightdive delivers at the end of May... I'm not one of the shit storm crowd (it's absolutely horrible on the Steam forums...), but, 7 years of development is a long time, and delaying the release obviously has become a bit of a habit, to say the least.

... and I have a couple ??s First. I have my (very crude) carriage bound to a horse. When the horse makes path changes at path corners, the carriage adjusts its angle abruptly. Is there any way to make it turn smoothly behind the horse... perhaps some elastic-behaving func that could be between the horse and the carriage, and bound to both, to buffer the sudden change in direction? Second. I have an AI sitting on the carriage and have worked it so he sits pretty well. But on occasion, when the carriage changes angles with the horse's path corners, it moves under the AI and sends him damage (I set AI not to receive damage already so he doesn't die). The problem is that the func_static carriage drastically moves to an extreme angle, away from the wheels & axle, then returns to its proper position and looks fine again... most of the time. Other times it ends up knocking the rider off or gets stuck in a funny position and leaves the horse either walking in place or walking backward. Excuse the low ambient light and the very crude box the AI is sitting on. I was just testing a concept and have not started actually building anything yet:

When I tried your .exe, I got this: https://forums.thedarkmod.com/index.php?/topic/21477-water-effects-not-rendered-through-warp-glass/&do=findComment&comment=475732 You also suggested trying the 'latest development build'. I asked if that can be obtained using tdm_installer, and you said 'yes'. That's what I reported here: https://forums.thedarkmod.com/index.php?/topic/21477-water-effects-not-rendered-through-warp-glass/&do=findComment&comment=475856 So - I am probably doing something wrong but not sure what