Search the Community

On a lighter note (and because my holiday started today, oh yeah!), let's have a new thread for music, that you just enjoy and probably is not so well known...or somehow obscure but does not sound as strange as the songs we report in @STiFU's progessive music thread. Here is one of my new favourites, a similar recording of this track by other artists has been used in an US show broadcasted last year ( @Amadeus: What is the name of the show? )

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 am working on improvements I can make to all.lang. The potential scope of work is overwhelmning, so I'm focusing at this time on the Main Menu, particularly Settings. I'd appreciate your review of the workplan, which has 3 main components - 1) commenting-out #str phrases no longer useful 2) adding #str to replace phrases hard-coded in English, in the relevant GUI files. a) in [English] b) in other languages (using AI) 3) For existing Settings #str in the GUI files, that were translated for some languages: do the remaining languages (using AI). I'm excluding this - - strings in *.cpp files - translations into Dutch and Swedish, where almost all strings are untranslated. Each of these is a project in itself, and I'm not up to it currently. Reviewers... My base is the 2.14 all.lang. If you know of 2.15 changes that could affect individual #str, please mention it here Details I have a revised all.lang WIP with the following changes done so far: - Group (1) work in both [English] and all other sections, as summarized and itemized here... - Group (2a), only in [English] so far, as summarized and itemized here... Workplan for Group 3 is WIP.

"Out of all the districts in Bridgeport, the Pagan Quarter is probably the second worst... it's certainly the last place I'd want to live. Sadly, I don't have a choice in the matter." It's with great pleasure that I present my third Dark Mod FM, "The Maybury Idol, Part 1: A Trip to the Museum" https://www.thedarkmod.com/missiondetails/?internalName=maybury1 This is the first in a planned 4-part series which is largely already plotted out to conclusion, and I'm planning to get started on Part 2 soon. Compared to the last FM I submitted, this one is a lot more linear and story-driven, but it also includes conversations and a mid-mission cutscene... which along with learning some basic scripting has really opened up a lot of possibilities in mission creation, and I'm looking forward to putting the lessons learned here to use in future. I'd like to thank everybody in the Beta Testing thread for ironing out the many, many wrinkles that came up and for offering helping advice in how to patch up the map's shortcomings: @Baal, @Cambridge Spy, @Bikerdude, @wesp5, @Bergante, @Keruah, and @tapewolf I hope you enjoy it.

Following the discussion of the Released and Upcoming thread Fidcal and I came up with some ideas how we could save abandoned labours of love. We came up with the following for contributing and adopting unfinished work maintained in this thread: How to contribute? If for any reason you decide to quit working on a map, map parts, etc. please consider contributing your abandoned work to the community! Proof of concepts and appealing results from "just playing around" alike may be interesting for other people to pick up. To do so just send a private message to a team member (preferably a mission manager like nbohr1more) with all relevant information about your work so far (see format below) and a link where it can be downloaded. Please do not post any download links in this thread. Your work will be archived on one of the Team's TDM servers. FM's (WIP) Name: ... Former author(s): ... Current author(s): (If any) Status: (free for adoption / in work) Due Date: (the next date I expect a new WIP version and progress report) Type: (Mansion, City, Crypt, Wilderness, ...) Theme: (Gold Heist, Horror, Story Focused, Inventors, ...) Progress: (Geometry, Details, AI, Gameplay, ... in some rough percentage) Informations: (anything the authors like to share about the work so far) How to adopt? Send a PM to a team member (ideally a mission manager). If you have already released an FM for TDM then most likely adoption will be granted. If you have never released an FM it'll be less likely.. If you did release FM's for Thief or a mod for any other game please send details that help us to decide. If you're the original author you can always pick up your committed work again as long as it is still (or again) "free for adoption". What do we expect from authors who did adopt assets? All former authors must be given credit upon release. You may like to use the unfinished assets the way you like: use parts in your own map or continue finishing the abandoned map. We and the former authors have to trust anyone given responsibility of the assets of a possibly already superb unfinished map. We all know that it sometimes happens that people cannot continue a work for various reasons (if so, please PM the team member), lose interest or in the worst case just disappear! In this case, or if we try to contact you for a status update and do not hear from you in a reasonable amount of time, we will offer the map again for adoption to someone else who might want to finish the FM. We hope to see some great unfinished works being worked on again and completed. So, fellow authors ... contribute your unfinished work List of Abandoned Works _________________________________________ Please check the wiki for details of abandoned work free for adoption and adopted maps: https://wiki.thedarkmod.com/index.php?title=Abandoned_Works

Revelator, that is actually super interesting. OpenGL is not my bag, but I get the gist of it. The most effective way to improve performance is simply not to do any extra work at all. Seeing your post and thinking about the hardware occlusion, it made me think that maybe we can approach this in a different way. 1) Do this as a "pre" rendering step 2) Gather all the entities in front of the camera, regardless of distance. 3) Get the real world coordinates of those entities, as well as their on screen projection rectangles, all of which is already computed and readily available info. 4) Do some quick math checks to see which objects are spatially behind others, as well as having bounds that are fully occluded. If any match this, preset the interaction as not visible. 5) rinse and repeat for the set of entities in front of the camera in that frame. Then, proceed with the normal rendering check. Entities marked as not visible are not rendered, thus saving those cycles. This is all linear algebra functionality, which is super fast and efficient. Of course, doing this as a preprocess would be required, but if it only takes 50ns to save 5ms, that is huge. Granted, this is completely conjecture at this point, but you have my wheels turning.

This is likely in part due to the bannings by Darkplaces and Xonotic concurrently some years ago. That hit Mircea very hard: having put much of their life into _programming_ for BOTH of those projects, as well as alot of 3d work etc. For free. I, to this day, use Mircea's work: the extra hit effects client side. More recently was ported over the digital-read-out-on-weapons-models (like UT 1999) code that Mircea created for their fun vore-tournament mod. Mircea was visciouly rejected by the (so-called) Darkplaces and Xonotic communities after working for _YEARS_ for them: they decided they did not like something Mircea tweeted years before. Those people are the true enemy. To this day they make fun of Mircea and say "it was no loss" and they're glad Mircea is not working for them any longer. >was banned by unanimous vote from both the darkplaces and xonotic communities >behavior post-ban affirms our decision. i'm not a fan of cancel culture myself, but we just... don't associate with those kind of people, for reasons i sincerely hope you can appreciate... They laugh and mock Mircea to this very day. A person who did so much ACTUAL WORK for these people. >go ahead and google mircea kitsune and >there is a lot of negativity that comes up. theres your reasons for bans etc

I think we should create a thread where you can put requests and suggestions for Orbweaver. This thread should be NOT a discussion thread. If you want to discuss a proposal, create a specific thread for it. I want it to be only for collecting proposals, so we have an overview of what people might want to have. I guess this might also help Orb to decide what he should focus on once he gets productive. BTW: I really appreciate your effort, because we can really use this. So my personal wishlist proposal is that I would like to see a group handler. Similar like in Blender, where you can select several objects and put it in a group. When you select one or more of these groups, the objects are visible. If the group is not selected, it's invisible. In Blender and other 3D apps this is called layers (forgot the name before so I had to look it up).

I do have some thoughts. My original idea was to implement a simple renderer culling distance as a CVar and intercept the rendering process, but that raises a whole set of questions I can't answer, yet. For example, take a large building where part of it falls inside the culled distance, but part of it is outside that distance? What do you do? Do you render the whole thing? If so, it would most likely be the only thing projected beyond the cutoff point, and it would look weird. If you don't render it, a large structure would just disappear when it should be visible. Without a serious amount of dev kungfu to rendering process itself, a hard render distance is probably going to be a non starter, at least for me. There are, however, a couple of other interesting ideas I am playing with. One is the light/entity interaction system. During play, the renderer maintains "idInteraction" objects representing the relationships between a particular light source and the surfaces it affects. For example: Street Lamp -> Wall Street Lamp -> Road Street Lamp -> Wooden Cart Street Lamp -> Barrel Street Lamp -> NPC A single light source will make multiple idInteraction objects, each of which must be evaluated separately. If an object falls into the radius of multiple light sources, then an idInteraction object is created for *each* one. Just having the interaction defined isn't that big of a deal, other taking up some RAM. It is the evaluation of that interaction that costs alot from a CPU/GPU standpoint. As the amount of lights and the amount of surfaces in an area increase, so do the computations for that area. Hence, a large open area with lots of lights and things usually brings the system down to 10-15 frames per second unless the mapper does some design magic to control things. Shadows also play into this, which complicates it further. Since there is no distance culling, the bigger the area, the more likely of a performance drag. But with respect to this, there is an interesting possibility. Within the idInteraction class are a couple of functions to add an interaction and to create one as a deferred action. By implementing a new CVAR like "r_lightInteractionCullDistance", a very fast and quick check can be made from the camera to the closest part of that interaction. If it is outside that distance, don't activate it. If it isn't activated, it isn't calculated or rendered. This could add in a simple distance culling mechanism and I think it could be huge in performance. As I stated, shadows are an extra wrinkle here. The engine keeps some things around which are not directly visible because their shadows may project across the camera, even though the light source causing the shadow is not visible. This can have added ovehead, and again, this increases with the amount of lights in an area. There is also another option I have been looking into that could actually be better. That is calculating how much of the screen is being occupied by the object. A relevance factor, if you will. An example is a large building, say a Templar church, and it is 8000 units away. Maybe there is something needing to be frobbed on the ground about 3000 units away, like a potion. With pure distance calculation, the church would disappear even though it can be plainly seen, but potion wouldn't even though it is most likely not visible or very, very small. As part of the calculations, the screen projection sizes are already computed by the engine. It would be fairly academic to query the engine for the onscreen rectangle size and cull it based on if it is too small. I have been leaning toward this idea more and more as I run scenarios through my head. Things usually don't work out the way they are intended to in the first pass with stuff like this, but as I dissect the source more, it is what I think the better solution. In a similar way, portal traversal can follow the same idea - if the visible projection of a portal on screen is below a certain threshold, do not go through it. Basically, when the map is created, the compiler breaks up the map into areas, separated by visportals. This is actually a super important function because it provides hard separation between to disparate locations on the map. A closed visportal prevents the engine from searching through it for things that are beyond that "could" visually affect the current view from the camera. Much of the time, things behind visportals do not affect the current view in the camera at all, but if the portal is open, the engine will search through it every time, regardless. Good map makers (ahem...JackFarmer?) know how to use all the tricks in the book to force occlusion - doors, 90 degree turns, short alleys, tall structures that obscure, and visportals. Closing a door/portal immediately halts the search for anything past it from an engine standoint. But an open portal beyond an open portal causes searching into a third area which most certainly won't have any relevance to the current view. It can cascade from there because the engine will continue through all open portals it finds during that rendering pass. So, this is great for interiors, closely confined towns, etc. But a large outdoor space is harder. Breaking up a large area with multiple visportals is worthless since they would all have to be open to see the area in the first place. Interestingly, the engine does clip out the stuff that can't be seen behind a portal. But the problem is that it has to search through it at all to figure out if it needs to clip it. So, I am thinking another CVAR for portalScreenSize or something like that. If the portal occupies less space on screen than the size specified in the CVAR, then don't traverse it. As an example, assume the map is a long alleyway. At the far end is a portal that is only showing on screen as a 2x2 pixel square after it is rendered. That is something you wouldn't even really see, but the engine sure can. Because the engine can see it, the renderer goes through the opening to find a bunch of stuff behind it - lights, surfaces, etc. It then has to compute all of that stuff it finds through that little tiny opening because it "may" affect the current screen view. After everything has been calculated, it then just simply clips it out anyway because all of that stuff isn't visible through the portal or the 4 pixels it takes up don't change. All that work for literally no reason. I don't want to sound like I am putting down the engine - quite the contrary. I am amazed that anyone could come up with this at all. For it's time, this thing is a marvel to be sure. The renderer does do plenty of screen culling, to be sure. The engine could never achieve real playability if it didn't. It just doesn't do anything that is *distance* related, or screen size tested to determine that culling, and that is why large open areas die horribly: too many lights and surfaces to compute because it doesn't know not to. The last thing I have found, I am not sure how to handle/fix. In any area (as defined by visportals), walls and other things are not actually doing occlusion from a calculation standpoint. They block things visually on screen, sure, and this does go a long way in performance. It is also the expected behavior. I mean, lights shining through walls is a bit silly. But if you place a large wall in front of a light source, and stand on the other side where you can't see the light, the engine still has to check the idInteraction objects that the light it connected with to see if it is interacting with the viewscreen. Of course, it isn't, but the calculations take place because from the engine's viewpoint, it could. So those are my ideas for now. Finding the engine really fascinating. In many ways, it is much easier to understnad than the beast that is Unreal Engine. Obviously, it isn't nearly as mature and developed as Unreal but it wouldn't be realistic to expect it to be. In reality though, knowing what I know about UE has really made me appreciate it that much more. Bottom line is that all of these guys were geniuses. Incidentally, there are lots of good comments througout the source code - big time kudos to whoever did that. It would be very, very hard to digest this if they hadn't documented it.

If like me you scour the web looking for inspiration for your next TDM mission then look no further.. Now... talking of images have you guys seen the latest from the master that is DrK from his Rocksbourg4 campaign. We need more dirty texture in TDM me thinks...

I kind of miss our old status-bar on the right, where you could casually share what's on your mind or what is happening in your life right now. So, I figured, let's just start a thread for that. Let's get this started...

@stgatilov, here is a release of the generated .po files with the *existing* translations for every TDM language in all.lang Generated_po_files_Oct_14_2026.zip The zip file has this content: [from_all_lang_to_po_v0.12] all.lang input file [with_chunking] tdm_main.pot, *.po, comand_line_output.txt [with_long_lines] tdm_main.pot, *.po, comand_line_output.txt [poedit_3.10_resave_with_po_tweaks_&_mo_gen] [from_chunking_with_poedit_wrap_on] tdm_main.pot, *.po, *.mo [with_long_lines_with_poedit_wrap_off] tdm_main.pot, *.po, *.mo [draft doc] Generating POT & PO Files and their Headers.docx The data for chunking and long-lines is equivalent; just the internal file structure differs. When opened in PoEdit, the .po files generally exhibited some problematic rows, which PoEdit moves to the top. Typically, there were a handful of warnings (in yellow) and 1 or 2 severe errors (in red). On purpose, these are not corrected in this release. Each .po file was saved, which can alter the internal file structure & header (i.e. "PO tweaks") but not what is shown visually. The saving also generated a .mo binary file. For files with red errors, during save you get a warning that the "MO file probably won't work". Many of the red errors were due to strings that had printf format specifiers (e.g., "%i"), and where the number of spec fields in English differed from that of the translation. Since the same culprits turned up across languages, perhaps the translations were right at one time, but now stale after code revisions. Only languages without red errors at moment are: russian, turkish, and the overwhelmingly-incomplete dutch & swedish. The draft Word doc supplements (i.e., not an update) the draft doc in my earlier release above.

Hello I currently tried to update the game to release version 214 but after a, by the way, very slow downloading process of about 15 minutes, I repeatedly get an error message about the hash value, when the game start to install. I tried installing with default settings as well as custom select the release 214. Both tries gives the same error messge. Could someone possibly help me with this ? Is there a way to download the complete installer manually somewhere, and run the installation process offline then ? Further the installer tells that it "was run as admin what is strongly discouraged" even though I didn't started it as admin and can't even stop it from doing so by itself. But that behavior was always like this, as I remember it right, and don't ever seemed to be a problem in the past. Greetings martin

For the people eager to play with the latest state of development, two things are provided: regular dev builds source code SVN repository Development builds are created once per a few weeks from the current trunk. They can be obtained via tdm_installer. Just run the installer, check "Get Custom Version" on the first page, then select proper version in "dev" folder on the second page. Name of any dev version looks like devXXXXX-YYYY, where XXXXX and YYYY are SVN revision numbers from which the build was created. The topmost version in the list is usually the most recent one. Note: unless otherwise specified, savegames are incompatible between any two versions of TDM! Programmers can obtain source code from SVN repository. Trunk can be checked out from here: https://svn.thedarkmod.com/publicsvn/darkmod_src/trunk/ SVN root is: https://svn.thedarkmod.com/publicsvn/darkmod_src Build instructions are provided inside repository. Note that while you can build executable from the SVN repository, TDM installation of compatible version is required to run it. Official TDM releases are compatible with source code archives provided on the website, and also with corresponding release tags in SVN. A dev build is compatible with SVN trunk of revision YYYY, where YYYY is the second number in its version (as described above). If you only want to experiment with the latest trunk, using the latest dev build gives you the maximum chance of success. P.S. Needless to say, all of this comes with no support. Although we would be glad if you catch and report bugs before the next beta phase starts

roof work (leaky shit...) some garden work what i can manage. and currently trying to get my chainsaw running again (dies when i give it gas so probably needs a cleaning of the carburator). gaming not so much atm atleast. been toying a bit with my retro gamer to see which games from my collection will run on it (quite a few actually). it is kinda weird to game on as you start to notice all the little tweaks you had to do back in those days to get it to be enjoyable . busy month and i been feeling a bit under the weather lately (tired as all hell). also been raining like crazy here the last 4 days so everything is soaking wet. first frost came yesterday night but daytime temperatures are still in the double digits so... started reading some good books to pass time (been a while since i last did that).

Okay, I had a quick go and if this guy is really going to listen to your feedback, please report this to him: - For me a stealth game with Souls-like saving is a no go. That's almost as worse as Spector's time pressure! - Why do we need to sharpen the sickle already after two or three hits of a supposendly spongy soft tissure? - The push hard to kill move is almost useless, it takes too long and the first push usually does nothing at all. - There is no way to extinguish the small lights like candles and water arrows on enemy torches didn't work. I couldn't finish the demo because of the issues above, and I am missing the patience to try again and again and again! I don't understand why so often in modern games the developers take an old working system and then make something worse out of it: Free Saves? No, let's make them location and object dependent. Steel melee weapons that work forever? No, ours are made from aluminum. Cool kick like in Dark Messiah? No, we need to push long and we also use the same button as normal attacks so mistakes are easy. Extinguish all the light sources like in TDM or Thief? No, lots of small lights can't be doused, because that'll be more fun. No...

https://www.ttlg.com/forums/showthread.php?t=153454&p=2543356&viewfull=1#post2543356 Great reaction from heywood.

Since we have a Random Video of the Day thread, it seems like this is fair. Show us any article you find interesting, or funny, or surprising, or whatever else is out of the ordinary. I'll begin: http://www.dailytech...rticle33998.htm I never imagined people pissing in an elevator. Of all the strange ideas I've had in my life, that was never one of them. Personally, I suspect the thug. ... and this comment cracked me up. "Why in the world would someone pee in an elevator? Also, when the system catches someone, they don't have to call the police. All they have to do is lock the elevator doors, engage the heaters and shaking motors, and get paid ad money on YouTube for the footage. "

by the great cthulhu christians have invaded the blood of the dawnwalker forums moaning about them being put in a bad light by a game... looking back chritianity was one of the most bloody in human history and they bitch about the game allowing for people to fight back i mean wtf... yes lets have the dark ages back as if we truely need more to bog us down. i think its time we neutered they're access to the internet .

ugh finally got my argb splitters. 10 days delivering time cause of all the unrest in shipping. still havent got my usb 3.1 to usb C converter which is expected to be delivered around the 18 this month (ordered it the 30 last month sigh). but atleast my build is complete now. next up will either be a 5900x or 5800x3d so that i can finally enjoy my new gfx card without all the jitters and bops at lower resolutions than 4k (does 4k quite well though). my bedroom is as bright as daylight now when its running in the late hours . also got my boards that suddenly failed to post checked and it was me test PSU that was faulty... newer buying a cheap corsair again sigh. atleast the boards all work fine except one which seems to have problems with the onboard sound (heaviliy distorted). this might have been due to my friend borrowing it for his machine when his board suddenly gave out and he mounted the board without checking the standofs (one was missing so he bolted the board right into the metal where the soundcard chip is located lol).

Well... if I remember correctly, Ctrl+Ins and Shift+Ins were present in DOS, while Ctrl + C and Ctrl + V became widespread in Windows. Somewhat similar to Ctrl + Shift versus Alt + Shift for changing keyboard language. Also, Ctrl+C and Ctrl+V often mean something in Linux terminals, some kind of escape characters, I don't know myself. The point is: they don't work as I expect often. For instance, it did not work for me in pure terminal until I had set it as hotkey in the settings. And even now, some embedded terminals (e.g. in Kate) still don't work as expected. In general, I have a feeling that the only reason some Linux versions support Ctrl+C and Ctrl+V out of the box is to make us poor Windows users feel at home, and not as some traditional option.

"Displacement" works, but now my scripts get overwritten, so they don't work when that mission is installed. I don't know of a way to introduce those scripts without causing any conflicts. Or we can give up on them if they cause more trouble then it's worth.