Search the Community

ThiefGuild has some tags: https://www.thiefguild.com/fanmissions/?advanced_search=&series=&collection=&table=&page=&works=&work_lists=&sort_by=newest&search=&games=5&released_from=all&released_to=all&genre=all&original_games=fms Not sure how complete or accurate those are, after all either the author or users add the tags to the missions.

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

Today I am happy to announce the release of my first FM for The Dark Mod. After 6 years of using this lovely game creation engine, I'm finally able to contribute my own project for it! It took roughly two weeks of non-stop work to do everything from start to end... there's always some little detail to come back to when mapping, thus there were a few little things left out to prioritize others, but at the end of the day this came out almost exactly as I envisioned it. In this mission you play as the typical professional thief. You've been hired to retrieve a scroll containing forbidden knowledge from the mansion of a wealthy noble, put there by the builder church who is close to its owner and found it a more suitable spot. A banquet is being thrown by the lord who owns the mansion which is the perfect opportunity to make your move. Nothing out of the ordinary: You're to retrieve this scroll and get paid for your work... simple, right? Notice: Performance in some areas may be poor. I optimized the lighting setup as much as possible, trying to use as few long range light sources as I could. To achieve the desired theme however I had to leave parts of them map relatively open. Hopefully this won't be a hindrance to anyone... if it is you may need to lower some graphical settings. For people who don't like surprises and may be sensitive to certain themes, read the spoiler below. If you're okay with anything don't as it will ruin the experience! For people who are stuck and don't know how to proceed, instructions are provided in the spoiler below. Only read them if necessary. A tip that needs no spoilers: The key in this FM is exploration and reading everything carefully. There are secrets to be found: Always look everywhere and closely at everyone! I'm eager to hear what your experience with this FM is. Use spoilers when referring to specifics, but do let me know what your thoughts are! Especially with this being my first FM I could use tips, including technical ones if you look at the map in DarkRadiant. Here are a few screenshots of the main areas (intended for the installer): And finally the download links. Unzip and place the main directory inside your fms folder, this should get it to show up in the mission list. Mirror 1 Mirror 2

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.

Hmmm, po also uses leading # for comments generally, so the use of # isn't going to scream "TDM-specific". That said, I'm ok with #empty. For the group comments where I was using msgctxt "//", I'd like to keep it short. How about "##"?

Darkmod underutilizes, in my opinion, capabilities for procedural animation. We already do some, like the random head and torso turns that are added on top of existing animations. There's also possibility for separate animation for top and bottom of the character as well as head. There's a missing opportunity for varied facial expressions. I talked about animation blending in this thread. Here's something that for example Thief: Deadly Shadows did. It's swaying side to side while turning. I used Gemini to add code to the tdm_ai_base.script. I don't know if this is the most efficient way of doing it, probably not. Here are the parts added: Gemini came up with the term "banking" which is used in car racing. I don't know if that's what it's called in animation or games. There's a lot of variables that can be tweaked. You can rotate this way any bone you wish. I use 'Origin', 'Spine_Dummy' and 'Neck' bones: You can tweak amount of rotation for each bone. setJointAngle(m_bankingJointHandle, 1, jointRotation * 1); setJointAngle(m_bankingJointHandle1, 1, jointRotation * 0.6); setJointAngle(m_bankingJointHandle2, 1, jointRotation * -1.5); There's also global intensity: (targetBanking = deltaYaw * 1.4;) and attenuation: m_bankingCurrentValue = (m_bankingCurrentValue * 0.95) + (targetBanking * 0.05); modifiers. Gemini also proposed to add an LOD system, which I thought was a great idea. So currently at a distance of 1500 from player the swaying will be disabled. Here are examples, each with slightly different values: And here's comically exaggerated one:

Phew, it's almost exactly been 3 years since my first post about my VR modification for TDM. Three more versions of the game have been released in the meantime, and with them come performance improvements that I feel it's finally viable to continue my work on the VR adaptation So without further ado, head on over to https://github.com/fholger/thedarkmodvr and grab the latest release. It's based on the future 2.09 version, but is fully compatible with a 2.08 install. Although I've tried to make the VR version use its own set of resources (separate `darkmod_vr.cfg` and shader folders), I'd recommend you make a backup or copy of your TDM installation to be able to get back to the flat version cleanly without effort. Please heed the README in the repository, particularly about the choices of VR backends. Some noteworthy information for this new version: performance should be considerably improved from the old alphas. That doesn't mean it's perfect - although the CPU bottleneck is now completely gone, the game is now severely fill-rate limited. So if you have a current-gen headset with high resolution and/or a weaker video card, forget about any supersampling or AA. I also strongly recommend to stick to stencil shadows and disable soft shadows and ambient occlusion - the latter isn't that impressive in VR, anyway, and simply not worth the GPU cost. And even then, there will be some scenes in some missions where reprojection is just unavoidable, even with the beefiest GPU. That being said, I have tried a multitude of maps, and I think it's very playable. the UI is finally usable! Both the menu and ingame HUD elements are projected to a virtual screen in front of your sitting position. It's not the most elegant or immersive solution for the HUD, but it works vertical mouse movement is excluded from the VR view - this was suggested by some of you way back, and I think it makes the experience much more enjoyable. It can make it a little hard, though, to aim with the mouse for actions like frobbing items, because there's currently no visual indication to where the mouse is pointing. I'm planning to add one asap, but in the meantime, you can equip a weapon to get a vague sense of your mouse orientation. If you do want to re-enable vertical movement in the view, set 'vr_lockMousePitch' to 0 in the console. Other than that, I hope you enjoy this new version. Let me know which improvements you'd like me to work on first. Also, there are probably any number of render and other bugs still left in there somewhere. If you find one, please report them over at the Github tracker (https://github.com/fholger/thedarkmodvr/issues), so I can keep track of them. Latest Update:

Yes, we can. Although this specific convention is completely out of nowhere. What's in common between these special values? #str_nnnnn // __empty__ Wouldn't it be better to have: #str_nnnnn #comment (or at least ###) #empty as it becomes obvious that we use #smth for our special words?

Screenshots: Mission: Breaking out the Fence Version: 1.00 Released: 17/03/2014 Theme: City Author: kyyrma Testing and additional content: RJFerret, Airship Ballet, Goldwell Breaking out the Fence continues the story from my first FM In a Time of Need. The player once again takes the role of an anonymous Thief who is getting tangled with an organization called the League of Seafaring Merchants. This time you will be sneaking your way into an import shop down at the South Docks and getting your fence Terry out from a pinch you have indirectly got him into. Prior knowledge of the story is not strictly necessary, and the level works just as well as a one shot stand-alone mission. Note that the story briefing is quite long - if you don't appreciate walls of text in your game, all the relevant information is on the last page. However if you want to set the mood and enjoy a good tale of skullduggery then give it a read. The difficulty level is moderate to high, and compared to my last mission it is much larger. The average play time should be around 1 - 2 hours depending on how much you decide to explore the level. You will start the level with only a blackjack, compass, spyglass and a map. You have to find the rest of your equipment while on the job. If you can't find a pair of lockpicks, remember to keep your eyes peeled for keys! The only differences between difficulty settings are the objectives, with higher difficulties requiring either a no-kill or a full ghost playthrough. Injection needles have been made a loot item, so remember to pick them up if you are going for loot completition I've succumbed under peer pressure and decided to have a poll where you can rate the level, but I would really appreciate your comments as well! Please get back to me if you have any questions or critique regarding the mission. Help! I'm stuck! How do I find the key to the closed off area in the sewers? Download links: If the mission is not yet available from the in-game downloader, you can use the following link: Private mirror Installation: Drop breakingout.pk4 in you darkmod/fms/ folder Run TDM and select New Mission. Breaking out the Fence should now appear on the list of downloaded missions. Install and play. Known issues: AI pathfinding can be slightly erratic at times Outdoors can cause performance issues on low-end hardware Sleeping AI can glitch through the bed if KO'd or killed There remain some audio issues such as pop-in and incorrect sound propagation Thanks: My testers RJFerret and Airship Ballet for their invaluable input and help during the creation of the level Goldwell for providing his vocal talent for the characer Terry All the TDM devs for creating such a great game All the people who have answered my newbie questions at the Editor's Guild

I think I have some working local version. Here is the list of errors I get on Russian language. Trying to use some wrong-language characters in the language where they are not expected: WARNING:file /strings/english.pot, line 5494: Unexpected UTF-8 characters: 0xC2 0xA8 0xC2 0xAE We cannot support empty string with gettext (it remains unknown because I drop all empty values): WARNING:file /strings/english.pot, line 748: Empty msgid on non-first entry WARNING:file /strings/russian.po, line 1064: Empty msgid on non-first entry WARNING:Unknown string id #str_02313 Missing strings: WARNING:Unknown string id #str_02386 WARNING:Unknown string id #str_02387 WARNING:Unknown string id #str_02388 In general, it looks fine. I'll add mission-side support, and it should be it...

Looking at russian.po: msgctxt "#str_02520" msgid "Restart this Mission?" msgstr "" This entry says that this placeholder should be replaced with empty string. I can indeed do it, but I suppose it is not right. So let's consider another option: this is untranslated string, and I should use English text instead. This is some kind of implicit convention, which is never good. And now we suddenly need to answer a question: are we absolutely sure translation system will never ever need to replace some placeholder with empty string? As far as I understand, it is already used for per-language customizations which have nothing to do with translations. Can we simply delete missing entries from .PO files?

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

the shader based versions might be better nowadays but im from a time before they became the mainstay so im really bad at them . though the members who can do those might also be interested in this discussion. the old version works quite well though so it depends on the need. currently cleaning up the code a bit and looking into what needs changing for idtech4. ill use doom3 to check for oddities and if it works ill post the code changes needed.

Hm, yeah, I think I understand what you mean. The worst example from my projects would be "Hidden Hands: Vitalic Fever". I wanted to have a free standing building in a "hilly" (hope that is correct English) area, and that causes significant problems with entities in sight. I had to use lots of "hide when in a certain distance" arguments for lots of entities. That, of course, leads to the "things pop up in front of the player" problem when the sight line is too long. The other problem with large open spaces is, that the "borders" always have to be build of large (and tall) geological structures. Because without it, it quickly becomes obivious that the whole area is somehow artificial. It is hard for me to describe this as I am not native English. I will look for examples from TDM missions and other games, if you want to.

if you are worried about clearance then the be quiet slim tower is actually pretty good. it cools well enough that it can hold a somewhat overclocked haswell frosty and there is a lot of clearing for ram and pcie latches. its not noisy though unless you change the fan to something different than the be quiet fan . the thermalright macho series also has good clearing despite it being allmost the size of the noctua NH-D15S due to the cooling element being offset from the base (not so much for a HEDT board though due to those having ram on both sides of the cpu). if you like downdraft coolers then the scythe grand kama is one of the better ones (pretty silent to). i know of some guys who made an intel style LGA mounting plate for use with the wraith cooler using 3d printing (not sure if these are still avaliable). for AMD it will fit both on an AM3 or AM4 since it was only the width of the mount that changed (might even fit on an AM2 socket). as for how the wraith spire sounded well if you used it together with an AM4 3900x it sounded like a jet engine . it was barely able able to keep the ryzen 3900x cool enough (usually it lingered in the 55 to 65 degree range on idle dependent on how well ventilated the case was). a slightly negative airpressure is allmost allways the better option for cases as a positive one has a tendency of sucking in the same hot air it just expulsed. but it depends on many things like placement of fans and how many unrelated air conduits the cabinet has besides the fan outlets. allways set the back fan to have a more lend back fan curve than the front fans to keep the pressure inside the cabinet higher than the outside. fanspeed does have some merits but it is actually more effective to have a slow but steady airflow running along the interior.

I concur with the “developers have gotten better at making the fans quieter" part because so far what I’ve found is that the cpu coolers really have become quieter. that's a unique design from zalman right there To me, 140mm seems too big or even jumbo-sized. But it makes sense for high-end systems. right now i am still fixated on downdraft cpu coolers altho updraft brings more advantage I’ve never tried the Wraith Spire, but does it produce a high-pitched sound and a hum? I’ve also thought about mounting an AM3+ fan(yeah fan only) onto a Ryzen heatsink (just attaching the fan itself to the heatsink), but I still need to figure out the compatibility, especially the size of the clip holes. If you put the old amd stock cooler the bracked couldn't fit obviously Has anyone tried this yet? Note that you’ll need to use a clip-on or tab mounting system: https://www.reddit.com/r/Amd/comments/69ckvh/for_anyone_wondering_yes_you_can_use_a_old_8350/ As for the ASRock DeskMini cooler, from what I can see, the heatsink and fan seem smaller; it’s also likely that the cooling surface area isn’t very large, so it has to run at a higher RPM. I can’t comment on the fin spacing (might has some effect) or the thickness of the base plate (this helps spread the heat even more) heat transfer and thermodynamic role here I don’t know how I managed to put up with a loud cooler back then. I’ll test it out again later. My plan is to give my PC a major overhaul in 2027. edit : I’m having the most trouble with the GPU clearance(modern GPU cooler and GPU die is getting bigger and bigger), the PSU exhaust direction & downdraft CPU cooler exhaust, and balancing the airflow negative pressure for sleeper pc (PC case fan intake and exhaust arrangement) lol. not as simple as i thought

Gotta say I'm pro free-save. My issue with the save method for this demo is that it has some alternate areas to explore where a single misstep can kill you and that, at least for now, it can get a bit glitchy with the grabbing and climbing and also with the rope arrows (both with grabbing/staying on them and with shooting a wooden platform with one and no rope appears). There's one place where I see loot but I don't want to go through all the reloads and getting back to it that I can tell it will take. It also discourages me from trying different tactics / using resources unless very near a save spot. Stick with what works every time or your progress is knocked back substantially. Btw, I thought "save-scumming" was saving before something that rewards random loot so that you can repeat until you get something you like, which does not appear to be something you can do here. Except for the frustrating save mechanism, I like it. I've had no issue with the push mechanism. One rope arrow that was wasted when shot directly at a wooden platform. One item looted through the wall of an unopened room (maybe intentional, dilapidated wooden walls you can see through). And I changed healing herbs to Z from X because I kept hitting it when crouching (likely because of numerous games that use X to crouch). I had an easier time with getting stuck while climbing around when I found that I could either look down and behind to get back down or that looking straight up while hitting space would unstick me and often allow me to proceed as well. Once when I dragged a body and tossed it over the edge it dragged me with it after releasing it. Sometimes when I try to drag a body it doesn't pick it up but I still have to release it even if I walk well away from 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

only really relevant if going for intels HEDT platform with 4 paired ones . non HEDT boards actually run better with just 2 sticks. HEDT actually runs ok with just 2 sticks as well, only downside is you dont get to use the quad pumped architecture which gives faster memory throughput. upside to HEDT is that you can use some pretty slow and cheap 2133 mhz modules (faster sticks tend to make it unstable) because they are run in 4x data rate mode compared to 2x which most boards use. but if you run it with 2 sticks you can use faster and bigger sticks (there is still a limit though). for x99 a 3200 mhz 16gb stick is pretty much the ceiling before it refuses to post (officially the speed limit is 2666 mhz but i tried with 2x 3200 mhz sticks in mine and it runs just fine as long as i dont run it in quad channel mode. it depends on the board though), i would guess x299 could use 3600 mhz or higher if run with two sticks (ok checked it can go as high as 4133 mhz sticks but these are seriously expensive so ouch).

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

Use lockpicks to relock closed unlocked doors. Useful when the key cannot be otherwise returned (supreme).

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.

The still ongoing Windows 10 topic sparked my curiosity why people do not just switch to Linux. But users of other OSes are also allowed to vote.

idtech 4 "can" do large outdoor maps, lights are the biggest problem for performance as plastering a map with 100's of lightsources will utterly smash performance due to all the calculations it has to do. one of the reasons many engines used pre baked lightsources. carmack usually newer wrote more code in then what the game it was made for needed, relying on engine modders or game studios that wanted to use it to add the missing pieces like say fence textures (for vegetation) and whatever else a modder needed for his or hers idea of a game. this works for DOOM as there is no vegetation on mars but it would look rather out of place on earth. sure you could maps with (faked vegetation) but i dont think it would look good. sadly idtech 4 newer really got that popular and only a few games ever got made based on it. prey. wolfenstein 2009. enemy territory quake wars. quake 4. as for mods the list is somewhat bigger but still a lot lower than most of the other idtech engines. the built in mapping tools were well how shall i put it... not very good. which may have been a reason it was not adopted by many. darkradiant is way better than the built in map editor but a few of the built in tools are still needed i think ?. also the change to C++ may have put off a lot of otherwise gifted engine modders who were used to working in C like previous idtech engines were coded in. C++ is great but there are a lot more pitfalls you need to be vary of compared to C. C = follow these rules. rigid but less error prone. C++ = my rules!. uh why did my PC bsod ?.

I think that's related to the two different ways of attaching a key to an AI. See https://wiki.thedarkmod.com/index.php?title=Doors#Keys_Carried_by_AI. Note that using the Bind Method has this proviso: "The AI cannot use a bound key to open a locked door; the workaround is to fake it with "can_unlock" as discussed further below." So you can end up with guards with a key that can't open a door, or guards without a key that can (if the can_unlock method is used).