Search the Community

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.

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.

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

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

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

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

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

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

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

All of my machines use DDR4 and have 32-64 GB each. Used DDR4 pricing isn't particularly outrageous, and I'll probably hang onto these until the end of time. I've pretty much checked out of the market. But I'll look at new low-end graphics cards if AMD/Nvidia/Intel launch any. I'm optimistic about RDNA5 AT4, but AMD has repeatedly fumbled at sub-75W. Intel's Arc Pro B50 was a little too generous, with an announced $300 MSRP morphing to $350 launch MSRP, and street prices skyrocketing. They may be abandoning dGPUs in favor of accelerators like Crescent Island. Nvidia is more opaque but AMD is basically copying their moves, and the low-end faces neglect. Nvidia has little incentive to focus on consumer graphics, period. I would pick up a 12th gen Alder Lake office PC (most if not all use DDR4), but I didn't find the current prices compelling. It would be something nice to have (but not necessary), and I could instantly transplant 64 GB into it.

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

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.

Which is newer, this or Hellforge? Edit: Anyway I just decided to use Hellforge for now because it is has more and pretty awesome features I think.

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

"When the leaves change and the air is still, there is a quiet." -Lady Blackbriar -=| DISPLACEMENT |=- BY AMADEUS & WELLINGTONCRAB = DOWNLOAD = <( | )> -REQUIRES TDM 2.14- -JOIN THE BETA NOW- "Seek not the prideful sin that is perfection The Builder's light shines through all flaws. It is His wisdom to recognize a thing is done Before it is ever truly finished." -St. Edgar's Sermon of Rust LAMPFIRE HILLS... They say the woods around here give the tourists bad dreams, but I don't mind. I like it here. I feel like a piece of me belongs here. ... That it fits. DISPLACEMENT is a medium-sized traditional manor mission with a highly variable playtime. *2.14 provides a number of improvements to gameplay, performance, and stability. It is strongly encouraged to play on the latest 2.14 beta release. Join in testing now!* *Mods such as the “Unofficial Patch” and “TDM Modpack” are not supported by this mission and should be used at your own risk* https://www.thiefguild.com/fanmissions/97429/displacement CREDITS: ADDITIONAL MUSIC: -AIRSHIP BALLET -GIGAGOOGA ADDITIONAL SCRIPTING: -DRAGOFER -OBSTORTTE -FROST SALAMANDER -KINGSAL ADDITIONAL ASSETS: -KINGSAL -TDASH -SKACKY -BIKERDUDE -GOLDWELL -EPIFIRE -STRUNK -SHANNEN ART -POLYHAVEN -TEXTURES.COM -SKETCHFAB CULTURAL HERITAGE CC0 COMMUNITY -LOISTE INTERACTIVE -COLINFIZGIG -CDMIR BETA TESTERS: -KINGSAL -GOLDWELL -MAT99 -FROST SALAMANDER -MIKE A -STGATILOV -STIFU -MARBLEMAN -DETEEFF -THEBIGH FURTHER ACKNOWLEDGMENTS: -STIFU FOR HIS EFFORT IN FIXING THE NOTORIOUS STUCK AI AND ARROW CRASH BUGS. -STGATILOV WHO MADE A NUMBER OF 2.14 OPTIMIZATIONS AND BUG FIXES. -KINGSAL FOR PROVIDING SOME OF THE MAIN MENU GUI ASSETS -PURAH FOR ORIGINATING THE SETTING OF LAMPFIRE HILLS, REIMAGINED HERE, IN HIS THIEF FMS. -GUY-ON THE COUCH AND JAM61 FOR THEIR SILENT HILL COMMUNITY MAPS WHICH HEAVILY INSPIRED THE LAMPFIRE HILLS REGION MAP. -SPECIAL THANKS TO LOISTE INTERACTIVE FOR ALLOWING US TO USE ASSETS FROM THEIR GAME "INFRA." SOME ADDIITONAL DETAILED LICENSING INFORMATION: SOME NOTES ON PERFORMANCE: NOTE TO MAPPERS: MOST OF THE NEW ASSETS IN THE MISSION ARE INCLUDED IN 2.14

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 .

plenty of lian li models have both firewire and flash drives (i have one heh). the early models came in silver or black anodized alu (also got one of both). biggest problem with lian li's older cabinets were the fans which while silent unless pushed did not move much air at all. replace them with a set of noctuas and the airflow is actually reasonable. some also make cutouts in the frame for more fans and the 5.25 drive trays can be converted to fans as well (there are some fan trays that are ready made for these but they usually come in black). i use my small 3 fan silver lian li case with a haswell 4790k and an AMD RX5700XT and it works well despite the gfx card getting rather hot even in a well ventilated case. the reason i like them so much is that they are easy to modify and there are a ton of accessories for them though you will have to look those up on the used market as they no longer get produced. i have a 5.25 " fan controller for the silver one but with the haswell board i did not really have any use for it since it is new enough to have several fan controllers. also got a 3.14" flash drive controller for the floppy cutout. i also liked the old coolermaster HAF X cabinets, which while old still has some of the best airflow you can get (downside is that its heavy as hell because its a full tower steel cabinet).

sadly i newer got a big stockpile of DDR4 since i came a bit late to it. mostly due to my old x79 sandy holding out as long as it did (well it still works). so i have an abundance of DDR3 ram (512 gb's worth) but these dont fetch especially high prices even in these times. got 64 gb's of DDR4 and these are all in use sadly in two of my machines. alder lake should still be ok performance wise atleast for some years to come. hmm x299 bundles are still priced ok and not at all bad if you have a decent cooler for the cpu as it tends to get pretty toasty. biggest problem with used DDR4 is that it can be a bit hard to find paired modules in quantities above 2 modules so a HEDT platform will be tough to get going unless you know for a fact that all modules have the exact same charateristics (the boards tend to refuse to post if they are not).

the 9800x3d is still faster but not as much as you might believe . it generally does better in the 1% lows but the 5800x3d is not that far behind. im seriously considering it though the 12 cores on the 5900x are nice as well. still wainting on my argb splitters but the supply chain is kinda fubared atm so earliest i will see them is in 3 to 4 days. the liquid freezer III is humming along in the meantime as i cure the thermal paste. its pretty silent unless i crank the fans to 11 so i barely notice it running in the background. the lighting is more distracting tbh . found a 4 stick set of 32 gb cl16 3600 mhz ram at a nice price though i cant afford it atm so it will have to wait. the current ram are probably better suited for my broadwell as the default is 2133 mhz cl14 and the old board not liking 3200 mhz sticks unless i use the xmp profile in which case it would be overclocked anyway. found an adapter from one of the internal usb 3.1 connections to usb C so i can get that cable mounted as well in the lancool III where my developer machine is currently residing. at some point and if prices dont go nuts on used hardware i might invest in a 299x board and cpu for the developer machine. should match the capability of my 3070 a little better as right now i dont get any use out of rebar since my old board does not support it and i had no luck with the bios hacks that should enable it.

That's quite an understatement, considering he practically left for a handful of people making use of AI in their missions. Again, I think it's more of a drama queen moment. Because it makes things you need a semi-professional artist for much easier and more accessible. I don't think it matters if A.I. or not, it rather matters how you use A.I. Of course, it's totally stupid to let it do the whole mapping for you, and I don't think anyone half-serious would use it that way. Again, I think an excellent example were the paintings in Seeking Lady Leicester. Yes, they obviouly got replaced now (I haven't played the mission since then), but, I think that's a great example for the fair use of A.I. Although WellingtonCrab of course will probably smite me again for saying that, because he never used A.I. in his life. Sorry, bit of teasing has to be.

In pursuit of a long-sought secret, the key to life everlasting lies deep within the recesses of an ancient athenaeum. Dragofer, Bikerdude, and I proudly present our FM for the Christmas Connections Contest titled "Written in Stone." Notes - TDM 2.10 Beta 5 or later is REQUIRED to play this mission. However, it is recommended to play using 2.10 Beta 6. You can get the latest version here. - This FM is a sequel to The Elixir. While it is not vital to play that before playing Written in Stone, there are some story connections. - This FM may be more hardware intensive than normal. LOD settings can be set below "Normal" to improve performance on low-end machines by disabling certain features. - Various areas will look better with shadow maps enabled at the possible expense of performance. - This FM implements the func_peek mechanic, allowing players to peek through any door that has a keyhole on it by leaning forward. PLEASE NOTE: This function has been known to cause crashes for a small number of players in the past, likely due to using the 32-bit version of TDM. At no point in this mission is it required to use the func_peek mechanic; it is purely optional, so feel free not to use it. As an entry in the 2.10 Christmas Connections Contest, the new features and assets used by this FM are: Download Version 1.1 This FM is available for download here: Google Drive Simply place the written.pk4 into your darkmod/fms folder and you're ready to go! Promotional Screenshots (via ThiefGuild) Credits A big thanks goes out to Wellingtoncrab for making a beautiful city map, Narrator for their wonderful voice work, nbohr1more for creating the original story premise as well as a few readables, Goldwell for animating the introduction to our briefing video and Duzenko for making certain glasses work as well as they do! A huge thank you also goes out to our beta testers: Goldwell, Wellingtoncrab, Kingsal, noodles, Krilmar, Garrett(Monolyth-42) ate0ate, and Mike_A. Thank you all very much for your keen eye to detail and great insights! Asset Credits Kingsal's Killer Assets Wellingtoncrab's Wonderful Furniture and Book Skins ***PLAYERS BEWARE*** SPOILERS lurk in the depths below. We strongly recommend playing this FM first so you don't spoil the fun for yourself!

many good ideas that were scrapped at the time people got them due to the technology to take advantage of it was not there yet. sounds a bit fun to have a resonator in a cmos but i bet people will complain if it starts to sound like coil whine . had been up for two days yesterday so i did not quite finish up my project, but despite not having the argb splitters yet i did some housekeeping by adjusting a few things in the build. the AIO was as said mounted in the front cutout but i arranged it so that the tubes are at the bottom. this is because otherwise the air inside the AIO would move towards the pump and that would destroy it pretty quickly. only downside is that the hoses kinda bump into my gfx card but mechanically it is sound. i also had to reverse the top fans due to how the fan outlets are arranged on my board (at the bottom) otherwise i had to use an extra cable because the one on the fans are to short when arranged like i did previously. i also did some housekeeping on the cables in the back especially the arbg cables so now they are ready for when i get the splitters. my board actually has a pretty funny feature where if you have a mechanical harddrive you can cache the command queue which makes it just as fast as an ssd unless the cache gets emptied to quickly. this depends on how much ram the board is currently holding (supports up to 128 gb) i use about 15% of my 32 gb as cache and it runs cyberpunk 2077 from that drive without a hitch . all the lighting stuff is really not me i have to admit, but the cabinet came loaded with it and the board supports it so i thought what the heck. ill take some pictures when it is done