Search the Community

I am pleased to announce the release of our new fan mission, The Hare in the Snare: Part 1 Mission type: City Missions + Inn/Tavern Description: People are being abducted off the streets and a Watch Captain requires the services of a thief to help him find out why. Download link (v1.0.2-release): https://drive.google.com/file/d/1HYvM_u56wDB16uIlb7qgS_q3P24V69MO/view?usp=sharing Credits: Mapping and original characters: @Frost_Salamander Story, readables, custom models, voices and cinematics: @Kerry000 Menu title track produced and mixed by @JackFarmer with selected gigagooga sound samples Beta testers: @Cambridge Spy @Zerg Rush @Amadeus @Acolytesix @Lzocast @wesp5 @nbohr1more @Kerry000 @ate0ate @Wellingtoncrab @prjames Additional thanks: @Dragofer, @nbohr1moreand @peter_spyfor technical help @Springheel for the modules and tutorials @kingsalfor allowing @Kerry000to abuse his manbeast everyone else on Discord and the TDM forums who offered assistance Requirements and notes: This mission requires TDM 2.09. Earlier versions will probably work but you might see one or two missing models. You may experience some FPS drops in some areas with lower-end hardware. Mid-range and above should be fine. If you have issues, I highly recommend you use shadow maps instead of stencil (settings -> advanced -> shadows implementation). It makes a big difference. For 'Hard' and 'Expert' the light gem sensitivity has been increased by '1' (meaning easier for AI to detect you). Screenshots:

Hi, I need to know what the code is to use Spoiler Tags. I am using my tablet and I don't have the options to use anything, like spoiler tags, quote tags, text changes etc. Thanks

I'd like to better understand what you want. The design of dragging bodies is to hold frob (key down) to drag and release frob (key up) to let go. That way it's impossible to walk away while unintentionally dragging a body. Plus, it's quick to grab and move several body limbs in rapid succession. This is thought to provide a better experience, especially for new players. Towards the beginning of this thread, I created a "tdm_frobhold_drag_body_behavior" cvar. https://forums.thedarkmod.com/index.php?/topic/22198-feature-proposal-frob-to-use-world-item/&do=findComment&comment=487580 "tdm_frobhold_drag_body_behavior", default:"1" Which drag body behavior? 1 --- on frob key up, drop body (limb). 0 --- on second frob, drop body (limb), TDM v2.11 (and prior) behavior. That cvar was removed shortly afterwards, because it was said that it wasn't needed. With that cvar set to 0, a second frob would be required to let go of the body. Is that the behavior that you want? If so, I can add that cvar back. Also, I saw elsewhere that you want the ability to revert back to the old way. If you mean that all of the controls match TDM 2.11, that can be done with "tdm_frobhold_delay 0" and there will be a menu setting to disable it as well.

Extensive customization options are appropriate during the pre-release testing or early roll out of a new feature. The people testing the feature can't know yet what configuration will work best for them, much less the people making the patch. My expectation is that by the time you have to make a final decision about including this patch in the next official update of TDM, there will be a rough consensus about the optimal parameters for the new mechanics, and you will only need one toggle for the new behavior. Or, preferably, there would be no need for an option at all if we can only get over our OCD about preserving arbitrary semantic grouping in our key-bind allocations; and embrace a superior control scheme that's not designed around highlighting an old gimmick feature whose trendiness expired with the Half-Life 2 era of FPS. But that's a pipe dream. Maybe instead we can just all agree that the general>gameplay options are getting a bit crowded. Perhaps we could split some of them off into an "appearance" or "accessibility" tag. As more people make their own mods and we modernize our accessibility options it is going to become a problem regardless. Best to get ahead of it. I agree, and that is one of TDM's strengths. It borrows and combines many of the best features from the three beloved Thief games, but it also gives FM creators tools to expand their creative vision in new directions. To some Thief purists that will never be an enticing proposition. But I don't see this feature as throwing a bone to those Thief players specifically, but just player in general who are bouncing off our game because it deviates from some genre conventions for no obvious reason, which makes them think this is an unpolished product. It is true that Thief was what set these conventions, and (shockingly/s) it is mostly Thief players who are interested enough in TDM to give it a try... but our responsibility to address these problems (if we can) is the same as if AMD or Linux players were having technical problems with TDM. They are people who we want to be part of our community because we never know if one of them might make the next FM like Iris, or do something crazy-innovative with TDM that we can't even imagine!

Hello, everyone! In this multi-part, comprehensive tutorial I will introduce you to a new light type that has been available in The Dark Mod since version 2.06, what it does, why you would want to use it and how to implement it in your Fan Missions. This tutorial is aimed at the intermediate mapper. Explanations of how to use DarkRadiant, write material files, etc. are outside of its scope. I will, however, aim to be thorough and explain the relevant concepts comprehensively. Let us begin by delineating the sections of the tutorial: Part 1 will walk you through four, distinct ways to add ambient light to a scene, the last way using irradiance environment maps (or IEMs). Lighting a scene with an IEM is considered image-based lighting. Explaining this concept is not in the scope of this tutorial; rather, we will compare and contrast our currently available methods with this new one. If you already understand the benefits IBL confers, you may consider this introductory section superfluous. Part 2 will review the current state of cubemap lights in TDM, brief you on capturing an environment cubemap inside TDM and note limitations you may run into. Three cubemap filtering applications will be introduced and reviewed. Part 3 will go into further detail of the types of inputs and outputs required by each program and give a walkthrough of the simplest way to get an irradiance map working in-game. Part 4 will guide you through two additional, different workflows of how to convert your cubemap to an irradiance map and unstitch it back to the six separate image files that the engine needs. Part 5 will conclude the tutorial with some considerations as to the scalability of the methods hitherto explained and will enumerate some good practices in creating IEMs. Typical scenes will be considered. Essential links and resources will be posted here and a succinct list of the steps and tools needed for each workflow will be summarized, for quick reference. Without further ado, let us begin. Part 1 Imagine the scene. You’ve just made a great environment for your map, you’ve got your geometry exactly how you want it… but there’s a problem. Nobody can appreciate your efforts if they can’t see anything! [Fig. 1] This will be the test scene for the rest of our tutorial — I would tell you to “get acquainted with it” but it’s rather hard to, at the moment. The Dark Mod is a game where the interplay between light and shadow is of great importance. Placing lights is designing gameplay. In this example scene, a corridor with two windows, I have decided to place 3 lights for the player to stealth his way around. Two lights from the windows streak down across the floor and a third, placeholder light for a fixture later to be added, is shining behind me, at one end of the corridor. Strictly speaking, this is sufficient for gameplay in my case. It is plainly obvious, however, that the scene looks bad, incomplete. “Gameplay” lights aside, the rest of the environment is pitch black. This is undesirable for two reasons. It looks wrong. In real life, lights bounce off surfaces and diffuse in all directions. This diffused, omni-directional lighting is called ambient lighting and its emitment can be termed irradiance. You may contrast this with directional lighting radiating from a point, which is called point lighting and its emitment — radiance. One can argue that ambient lighting sells the realism of a scene. Be that as it may, suppose we disregard scary, real-life optics and set concerns of “realism” aside… It’s bad gameplay. Being in darkness is a positive for the player avatar, but looking at darkness is a negative for the player, themselves. They need to differentiate obstacles and objects in the environment to move their avatar. Our current light level makes the scene illegible. The eye strain involved in reading the environment in these light conditions may well give your player a headache, figurative and literal, and greatly distract them from enjoying your level. This tutorial assumes you use DarkRadiant or are at least aware of idtech4’s light types. From my earlier explanation, you can see the parallels between the real life point/ambient light dichotomy and the aptly named “point” and “ambient” light types that you can use in the editor. For further review, you can consult our wiki. Seeing as how there is a danger in confusing the terms here, I will hereafter refer to real life ambient light as “irradiant light”, to differentiate it from the TDM ambient lights, which are our engine’s practical implementation of the optical phenomenon. A similar distinction between “radiant light” and point lights will be made for the same reason. Back to our problem. Knowing, now, that most all your scenes should have irradiant light in addition to radiant light, let’s try (and fail, instructionally) to fix up our gloomy corridor. [Fig. 2] The easiest and ugliest solution: ambient lights. Atdm:ambient_world is a game entity that is basically an ambient light with no falloff, modifiable by the location system. One of the first things we all do when starting a new map is putting an ambient_world in it. In the above image, the darkness problem is solved by raising the ambient light level using ambient_world (or via an info_location entity). Practically every Dark Mod mission solves its darkness problem1 like this. Entirely relying on the global ambient light, however, is far from ideal and I argue that it solves neither of our two, aforementioned problems. Ambient_world provides irradiant light and you may further modulate its color and brightness per location. However, said color and brightness are constant across the entire scene. This is neither realistic, nor does it reduce eye strain. It only makes the scene marginally more legible. Let’s abandon this uniform lighting approach and try a different solution that’s more scene-specific. [Fig. 3] Non-uniform, but has unintended consequences. Our global ambient now down to a negligible level, the next logical approach would be hand-placed ambient lights with falloff, like ambient_biground. Two are placed here, supplementing our window point lights. Combining ambient and point lights may not be standard TDM practice, but multiple idtech4 tutorials extol the virtues of this method. I, myself, have used it in King of Diamonds. For instance, in the Parkins residence, the red room with the fireplace has ambient lights coupled to both the electric light and the fire flame. They color the shadows and enrich the scene, and they get toggled alongside their parent (point) lights, whenever they change state (extinguished/relit). This is markedly better than before, but to be honest anything is, and you may notice some unintended side-effects. The AI I’ve placed in the middle of the ambient light’s volume gets omnidirectionally illuminated far more than any of the walls, by virtue of how light projection in the engine works. Moving the ambient lights’ centers closer to the windows would alleviate this, but would introduce another issue — the wall would get lit on the other side as well. Ambient lights don’t cast shadows, meaning they go through walls. You could solve this by creating custom ambient light projection textures, but at this point we are three ad hocs in and this is getting needlessly complicated. I concede that this method has limited use cases but illuminating big spaces that AI can move through, like our corridor, isn’t one of them. Let’s move on. [Fig. 4] More directional, but looks off. I have personally been using this method in my WIP maps a lot. For development (vs. release), I even recommend it. A point light instead of an ambient light is used here. The texture is either “biground1” or “defaultpointlight” (the latter here). The light does not cast shadows, and its light origin is set at one side of the corridor, illuminating it at an angle. This solves the problem of omnidirectional illumination for props or AI in the middle of the light volume, you can now see that the AI is lit from the back rather than from all sides. In addition, the point light provides that which the ambient one cannot, namely specular and normal interaction, two very important features that help our players read the environment better. This is about as good as you can get but there are still some niggling problems. The scene still looks too monochromatic and dark. From experience, I can tell you that this method looks good in certain scenes, but this is clearly not one of them. Sure, we can use two, non-shadowcasting point lights instead of one, aligned to our windows like in the previous example, we can even artfully combine local and global ambient lights to furnish the scene further, but by this point we will have multiple light entities placed, which is unwieldy to work with and possibly detrimental to performance. Another problem is that a point light’s movable light origin helps combat ambient omnidirectionality, but its projection texture still illuminates things the strongest in the middle of its volume. I have made multiple experiments with editing the Z-projection falloff texture of these lights and the results have all left me unsatisfied. It just does not look right. A final, more intellectual criticism against this method is that this does not, in a technical sense, supply irradiant light. Nothing here is diffuse, this is just radiant light pretending the best it can. [Fig. 5] The irradiance map method provides the best looking solution to imbuing your scene with an ambient glow. This is the corridor lit with irradiance map lights, a new lighting method introduced in The Dark Mod 2.06. Note the subtle gradients on the left wall and the bounced, orange light on the right column. Note the agreeable light on the AI. Comparing the previous methods and this, it is plainly obvious that an irradiance environment map looks the most realistic and defines the environment far better than any of the other solutions. Why exactly does this image look better than the others? You can inform yourself on image-based lighting and the nature of diffuse irradiance, but images speak louder than words. As you can see, the fact of the matter is that the effect, subtle as it may be, substantially improves the realism of the scene, at least compared to the methods previously available to us. Procuring irradiance environment maps for use in lighting your level will hereafter be the chief subject of this tutorial. The next part will review environment cubemap capture in TDM, the makeIrradiance keyword and three external applications that you can use to convert a TDM cubemap into an irradiance map. 1 “ Note that the color buffer is cleared to black: Doom3 world is naturally pitch black since there is no "ambient" light: In order to be visible a surface/polygon must interact. with a light. This explains why Doom3 was so dark ! “ [source] Part 2 Cubemaps are not new to The Dark Mod. The skybox materials in some of our prefabs are cubemaps, some glass and polished tile materials use cubemaps to fake reflections for cheap. Cubemap lights, however, are comparatively new. The wiki page linked earlier describes these two, new light types that were added in TDM 2.05. cubicLight is a shadow-casting light with true spherical falloff. An example of such a light can be found in the core files, “lights/cubic/tdm_lampshade_cubic”. ambientCubicLight is the light type we will be focusing on. Prior to TDM 2.06, it acted as a movable, on-demand reflection dispenser, making surfaces in its radius reflect a pre-set cubemap, much like glass. After 2.06, the old behavior was discarded and ambientCubicLight was converted to accept industry standard irradiance environment maps. Irradiance environment maps (IEMs) are what we want to make, so perhaps the first thing to make clear is that they aren’t really “handmade”. An IEM is the output of a filtering process (convolution) which requires an input in the form of a regular environment cubemap. In other words, if we want to make an IEM, we need a regular cubemap, ideally one depicting our environment — in this case, the corridor. I say a snapshot of the environment is ideal for lighting it because this emulates how irradiant light in the real world works. All radiating surfaces are recorded in our cubemap, our ambient optic array as it were, then blurred, or convoluted, to approximate light scatter and diffusion, then the in-game light “shines” this approximation of irradiant light back to the surfaces. There is a bit of a “chicken and the egg” situation here, if your scene is dark to begin with, wouldn’t you just get a dark irradiance map and accomplish nothing? In the captured cubemap faces in Fig. 6, you may notice that the environment looks different than what I’ve shown so far. I used two ambient lights to brighten up the windows for a better final irradiance result. I’ve “primed the pump”, so to speak. You can ignore this conundrum for the moment, ways to set up your scenes for better results, or priming the pump correctly, will be discussed at the end of the tutorial. Capturing the Environment The wiki has a tutorial on capturing cubemaps by angua, but it is woefully out of date. Let me run you through the process for 2.07 really briefly. To start with, I fly to approx. the center of the corridor with noclip. I then type “envshot t 256” in the console. This outputs six .tga images in the <root>/env folder, simply named “t”, sized 256x256 px and constituting the six sides of a cube and depicting the entire environment. This is how they look in the folder: [Fig. 6] The six cube faces in the folder. Of note here is that I do not need to switch to a 640x480 resolution, neither do I need to rename these files, they can already be used in an ambientCubicLight. Setting Up the Lights For brevity’s sake, I’ll skip explaining material definitions, if you’ve ever added a custom texture to your map, you know how to do this. Suffice it to say, it is much the same with custom lights. In your <root>/materials/my_cool_cubemaps.mtr file, you should have something like this: lights/ambientcube/my_test_IEM_light { ambientCubicLight { forceHighQuality //cameraCubeMap makeIrradiance(env/t) cameraCubeMap env/t colored zeroClamp } } We’ll play with the commented out line in just a bit. Firstly, let’s place the actual light in DarkRadiant. It’s as simple as creating a new light or two and setting them up in much the same way you would a regular ambient light. I select the appropriate light texture from the list, “my_test_IEM_light” in the “ambientcube” subfolder and I leave the light colored pure white. [Fig. 7] The corridor in DR, top view, with the ambient cubic lights highlighted. I can place one that fills the volume or two that stagger the effect somewhat. Remember that these lights still have a spherical falloff. Preference and experimentation will prove what looks best to you. Please note that what the material we defined does is load a cubemap while we established that ambientCubicLights only work with irradiance maps. Let’s see if this causes any problems in-game. I save the map and run it in game to see the results. If I already have TDM running, I type “reloadDecls” in the console to reload my material files and “reloadImages” to reload the .tga images in the /env folder. [Fig. 8] Well this looks completely wrong, big surprise. Wouldn’t you know it, putting a cubemap in the place of an irradiance map doesn’t quite work. Everything in the scene, especially the AI, looks to be bathed in slick oil. Even if a material doesn’t have a specular map, it won’t matter, the ambientCubicLight will produce specular reflections like this. Let’s compare how our cubemap .tga files compares with the IEM .tgas we’ll have by the end of the tutorial: [Fig. 9] t_back.tga is the back face of the environment cubemap, tIEM_back.tga is the back face of the irradiance map derived from it. As you can see, the IEM image looks very different. If I were to use “env/tIEM” instead of “env/t” in the material definition above, I would get the proper result, as seen in the last screenshot of part 1. So it is that we need a properly filtered IEM for our lights to work correctly. Speaking of that mtr def though, let’s not invoke an irradiance map we haven’t learned to convert yet. Let’s try an automatic, in-engine way to convert cubemaps to IEMs, namely the makeIrradiance material keyword. makeIrradiance and Its Limitations Let’s uncomment the sixth line in that definition and comment out the seventh. cameraCubeMap makeIrradiance(env/t) //cameraCubeMap env/t Here is a picture of how a cubemap ran through the makeIrradiance keyword looks like: [Fig. 10] Say ‘Hi’ to our friend in the back, the normalmap test cylinder. It’s a custom texture I’ve made to demonstrate cubemap interactions in a clean way. Hey now, this looks pretty nice! The scene is a bit greener than before, but you may even argue it looks more pleasing to the eyes. Unfortunately, the devil is in the details. Let’s compare the makeIrradiance keyword’s output with the custom made irradiance map setup seen at the end of part 1. [Fig. 11, 12] A closer look at the brick texture reveals that the undesired specular highlighting is still present. The normal map test cylinder confirms that the reason for this is the noisy output of the makeIrradiance keyword. The in-engine conversion is algorithmic, more specifically, it doesn't allow us to directly compare .tga files like we did above. Were we able to, however, I'm sure the makeIrradiance IEM would look grainy and rough compared to the smooth gradient of the IEM you’ll have by the end of this tutorial. The makeIrradiance keyword is good for quick testing but it won’t allow you fine control over your irradiance map. If we want the light to look proper, we need a dedicated cubemap filtering software. A Review of Cubemap Filtering Software Here I’ll introduce three programs you can produce an irradiance map with. In the coming parts, I will present you with a guide for working with each one of them. I should also note that installing all of these is trivial, so I’ll skip that instructional step when describing their workflows. I will not relay you any ad copy, as you can already read it on these programs’ websites. I’ll just list the advantages and disadvantages that concern us. Lys https://www.knaldtech.com/lys/ Advantages: Good UI, rich image manipulation options, working radiance/specular map filtering with multiple convolution algorithms. Disadvantages: $50 price tag, limited import/export options, only available on Windows 64-bit systems. cmftStudio https://github.com/dariomanesku/cmftStudio Advantages: Available on Windows, OSX and Linux, free, open source software, command line interface available. Disadvantages: Somewhat confusing UI, limited import options, missing features (radiance/specular map filtering is broken, fullscreen doesn’t work), 32-bit binaries need to be built from source (I will provide a 32-bit Windows executable at the end of the tutorial). Modified CubeMapGen https://seblagarde.wordpress.com/2012/06/10/amd-cubemapgen-for-physically-based-rendering/ Advantages: Free software, quickest to work with (clarified later). Disadvantages: Bad UI, only Windows binaries available, subpar IEM export due to bad image adjustment options. Let’s take a break at this point and come back to these programs in part 3. A lot of caveats need to be expounded on as to which of these three is the “best” software for making an irradiance map for our purposes. Neither of these programs has a discreet workflow; rather, the workflow will include or exclude certain additional programs and steps depending on which app you choose to work with. It will dovetail and be similar in all cases. Part 3 The aim of this tutorial is twofold. First, it aims to provide the most hands-free and time-efficient method of converting an envshot, environment cubemap to an IEM and getting it working in-game. The second is using as few applications as possible and keeping them all free software that is available for download, much like TDM itself. The tutorial was originally going to only cover IEM production through Lys, as that was the app I used to test the whole process with. I soon realized that it would be inconsiderate of me to suggest you buy a fifty dollar product for a single step in a process that adds comparatively little to the value of a FM, if we’re being honest (if you asked me, the community would benefit far more from a level design tutorial than a technical one like this, but hey, maybe later, I’m filling a niche right now that nobody else has filled). This led me to seek out open-source alternatives to Lys, such as Cubemapgen, which I knew of and cmftStudio, which I did not. I will preempt my own explanations and tell you right away that, in my opinion, cmftStudio is the program you should use for IEM creation. This comes with one big caveat, however, which I’m about to get into. Six Faces on a Cross and The Photoshop Problem Let’s review. Taking an envshot in-game gives you six separate images that are game-ready. Meaning, you get six, split cubemap faces as an output, you need six, split irradiance map faces as an input. This is a problem, because neither Lys nor cmftStudio accept a sequence of images as such. They need to be stitched together in a cube cross, a single image of the unwrapped cube, like this: [Fig. 13] From Lys. Our cubemap has been stitched into a cross and the “Debug Cube Map Face Position” option has been checked, showing the orientations of each face. In Lys only panoramas, sphere maps and cube maps can be loaded into the program. The first two do not concern us, the third specifically refers to a single image file. Therefore, to import a TDM envshot into Lys you need to stitch your cubemap into a cross. Furthermore, Lys’ export also outputs a cubemap cross, therefore you also need to unstitch the cubemap into its faces afterwards if you want to use it in TDM. In cmftStudio you can import single map faces! Well… no, you can’t. The readme on GitHub boasts “Input and output types: cubemap, cube cross, latlong, face list, horizontal and vertical strip.” but this is false. The UI will not allow you to select multiple files on import, rendering the “face list” input type impossible.2 Therefore, to import a TDM envshot into cmftStudio you need to stitch your cubemap into a cross. Fortunately, the “face list” export type does work! Therefore, you don’t need to unstitch the cubemap manually, cmftStudio will export individual faces for you. In both of these cases, then, you need a cubemap cross. For this tutorial I will use Adobe Photoshop, a commercial piece of software, to stitch our faces into a cubemap in an automated fashion (using Photoshop’s Actions). This is the big caveat to using cmftStudio, even if you do not want to buy Lys, PS is still a prerequisite for working with both programs. There are, of course, open source alternatives to Photoshop, such as GIMP, but it is specifically Photoshop’s Action functionality that will power these workflows. GIMP has its own Actions in the form of Macros, but they are written with python. GIMP is not a software suite that I use, neither is python a language I am proficient with. Out of deference for those who don’t have, or like working with, Photoshop, I will later go through the steps I take inside the image editor in some detail, in order for the studious reader to reconstruct them, if they so desire, in their image editing software of choice. At any rate, and at the risk of sounding a little presumptuous, I take it that, as creative types, most of you already have Photoshop on your computers. 2 An asterisk regarding the “impossibility” of this. cmftStudio is a GUI for cmft, a command line interface that does the same stuff but inside a command prompt. I need to stress that I am certain multiple faces can be inputted in the command line, but messing with unwieldy prompts or writing batch files is neither time-saving nor user-friendly. This tutorial is aimed at the average mapper, but a coder might find the versatility offered in cmft interesting. The Cubemapgen Workflow You will have noticed that I purposefully omitted Cubemapgen from the previous discussion. This is because working with Cubemapgen, wonderfully, does not need Photoshop to be involved! Cubemapgen both accepts individual cubemap faces as input and exports individual irradiance map faces as output. Why, then, did I even waste your time with all the talk of Lys, cmftStudio and Photoshop? Well, woefully, Cubemapgen’s irradiance maps look poor at worst and inconsistent at best. Comparing IEMs exported from Lys and cmftStudio, you will see that both look practically the same, which is good! An IEM exported from Cubemapgen, by default, is far too desaturated and the confusing UI does not help in bringing it to parity with the other two programs. If you work solely with Cubemapgen, you won’t even know what ‘parity’ is, since you won’t have a standard to compare to. [Fig. 14] A comparison between the same irradiance map face, exported with the different apps at their respective, default settings. Brightened and enlarged for legibility. This may not bother you and I concede that it is a small price to pay for those not interested in working with Photoshop. The Cubemapgen workflow is so easy to describe that I will in fact do just that, now. After I do so, however, I will argue that it flies in the face of one of the aims of this tutorial, namely: efficiency. Step 1: Load the cubemap faces into Cubemapgen. Returning to specifics, you will remember that we have, at the moment, six .tga cubemap faces in a folder that we want to convert to six irradiance map faces. With Cubemapgen open, direct your attention to these buttons: [Fig. 15] You can load a cubemap face by pressing the corresponding button or using the hotkey ‘F’. To ensure the image faces the correct way, you must load it in the corresponding “slot”, from the Select Cubemap Face dropdown menu above, or by pressing the 1-6 number keys on your keyboard. Here is a helpful list: X+ Face <1> corresponds to *_right X- Face <2> corresponds to *_left Y+ Face <3> corresponds to *_up Y- Face <4> corresponds to *_down Z+ Face <5> corresponds to *_forward Z- Face <6> corresponds to *_back ...with the asterisk representing the name of your cubemap. With enough practice, you can get quite proficient in loading cubemap faces using keyboard shortcuts. Note that the ‘Skybox’ option in the blue panel is checked, I recommend you use it. Step 2: Generate the Irradiance Map [Fig. 16] The corridor environment cubemap loaded in and filtered to an irradiance map. The options on the right are my attempt to get the IEM to look right, though they are by no means prescriptive. Generating an IEM with Modified CubeMapGen 1.66 is as easy as checking the ‘Irradiance cubemap’ checkbox and hitting ‘Filter Cubemap’ in the red panel. There are numerous other options there, but most will have no effect with the checkbox on. For more information, consult the Sébastien Lagarde blog post that you got the app from. I leave it to you to experiment with the input and output gamma sliders, you really have no set standard on how your irradiance map is supposed to look, so unfortunately you’ll have to eyeball it and rely on trial and error. Two things are important to note. The ‘Output Cube Size’ box in the red panel is the resolution that you want your IEM to export to. In the yellow panel, make sure you set the output as RGB rather than RGBA! We don’t need alpha channels in our images. Step 3: Export Irradiance Map Faces Back in the green panel, click the ‘Save CubeMap to Images’ button. Save the images as .tga with a descriptive name. [Fig. 17] The exported irradiance map faces in the folder. These files still need to be renamed with appropriate suffixes in order to constitute a readable cubemap for the engine. The nomenclature is the same as the table above: “c00” is the X+ Face, to be renamed “right”, “c01” is the X- Face and so on. Right left, up down, forward and back. That’s the order! This is all there is to this workflow. A “cameraCubeMap env/testshot” in the light material will give us a result that will look, at the very least, better than the inbuilt makeIrradiance material keyword. [Fig. 17] The map ended up being a little bright. Feel free to open Fig. 4 and this in seperate tabs and compare the Lys/cmft export with the cubemapgen one. A Review of the Workflow Time for the promised criticism to this workflow. I already stated my distaste for the lack of a standardised set of filtering values with this method. The lack of any kind of preset system for saving the values you like makes working with Cubemapgen even more slipshod. Additionally, in part 2, I said that Cubemapgen is the fastest to work with, but this needs to be qualified. What we just did was convert one cubemap to an irradiance map, but a typical game level ought to use more than a single IEM. Premeditation and capturing fake, “generic” environment cubemaps (e.g. setting up a “blue light on the right, orange on the left” room or a “bright skylight above, brown floor” room, then capturing them with envshot) might allow for some judicious reuse and keep your distinct IEM light definition count down to single digits, but you can only go so far with that. I am not arguing here for an ambient cubic light in every scene either, certainly only those that you deem need the extra attention, or those for which the regular lighting methods enumerated in Part 1 do not quite work. I do tentatively assume, though, that for an average level you would use between one and two dozen distinct IEMs. Keep in mind that commercial games, with their automated probe systems for capturing environment shots, use many, many more than that. With about 20 cubemaps to be converted and 6 faces each to load into Cubemapgen, you’ll be going through the same motions 120 whole times (saving and renaming not included). If you decide to do this in one sitting (and you should, as Cubemapgen, to reiterate, does not keep settings between sessions), you are in for a very tedious process that, while effective, is not very efficient. The simple fact is that loading six things one by one is just slower than loading a single thing once! The “single thing” I’m referring to is, of course, the single, stitched cubemap cross texture. In the next part, I will go into detail regarding how to make a cubemap cross in Photoshop in preparation for cmftStudio and Lys. It will initially seem a far more time-consuming process to you than the Cubemapgen workflow, but through the magic of automation and the Actions feature, you will be able to accomplish the cubemap stitch process in as little as a drag-and-drop into PS and a single click. The best thing is that after we go through the steps, you won’t have to recreate them yourself, as I will provide you with a custom Actions .atn file and save you the effort. I advise you not to skip the explanations, however. The keen-eyed among you may have noticed that you can also load a cube cross in Cubemapgen. If you want to use both Cubemapgen and Photoshop together to automate your Cubemapgen workflow, be aware that Cubemap gen takes crosses that have a different orientation than the ones Lys and cmftStudio use. My macros (actions) are designed for the latter, so if you want to adjust them for Cubemapgen you would do well to study my steps and modify them appropriately. For the moment, you’ve been given the barebones essentials needed to capture an envshot, convert it to an irradiance map and put it in your level at an appropriate location, all without needing a single piece of proprietary software. You can stop here and start cranking out irradiance maps to your heart’s content, but if you’re in the mood for some more serious automation, consider the next section.

I realized a fun change we could consider for the lightgem, which should also be fairly easy to implement if agreed upon. We know how aside from the amount of light shining on the player, some FM's increase the lightgem based on movement and crouching, you become more visible while walking and especially when running. I'd like to ask if anyone thinks we should additionally support a slight increase to the lightgem based on mouse movement. Explaining how the idea came to mind is the best way to illustrate why I feel it would make the experience more fun. The player often hides in a dark corner waiting for a hostile AI to pass right by as they patrol: In any real scenario you'd be holding your breath as to not make any sound or the slightest movement, even breathing would stand out slightly and could get you spotted. Thus from a perspective of realism, it feels out of place that I can zoom the mouse all over without any consequence... merely turning your head would draw a bit of attention, let alone looking behind which implies the player turning their whole body around. Meanwhile from a gameplay perspective, it could be a welcome challenge having to not move the mouse when a guard is right next to you, keeping your mouse steady similar to how you'd hold your breath as you wait till the danger passes to look away... this would feel more exciting and add a new form of tension, especially as many players complained the AI feels too easy even on the highest difficulty settings. Obviously the increase should be minuscule, possibly just 1 lightgem point: We don't want players feeling they can't look around while hiding, just not doing it too much when an enemy is right in your face. The best way seems like making it based on the movement speed: Moving the mouse very slowly could have no penalty, whereas jerking it suddenly could increase the lightgem by a few points so even in total darkness the AI sees something and may even catch you if you keep looking around rapidly while next to them. Another debate is whether this should be a spawnarg new missions have to configure, similar to some existing visibility properties and lightgem offsets. Personally I'm in favor of defaulting it to a low value, just 1 lightgem point increase if it's fixed or something like 3 if it's speed based. Alternatively we could tie it to the difficulty setting... if it's controversial maybe just implement it as a hidden cvar we can try out? Very curious what you think so let me know your thoughts, I'd definitely like to at least see the concept tested!

Not to be a nag, but I was thinking about the columns problem. If you go to the view source tab in the wiki article: https://wiki.thedarkmod.com/index.php?title=Fan_Missions_for_The_Dark_Mod&action=edit The raw table data is accessible directly: |- !align=left|{{TDM-FM|written|Written in Stone}} |Bikerdude, Amadeus, Dragofer |{{Forumlink|https://forums.thedarkmod.com/index.php?/topic/21265-written-in-stone-beta-210-only-20220128/}} |2022-01-28 |338 |Yes |Yes |CCC 22, Elixir |City Missions |Undead, Horror Themes |- Each pipe character represents one of the columns.

From a econimic point of view, that rather seems like suicide though. The "classics" are remade, because they have a good name, not a bad one. Anyway, even a remake of Thief is completely unrealistic. There's the issue of a company holding the IP, there's the issue of stealth games not being exactly popular these days, there's the issue of having to cater to a completely different target audience etc. etc. I can't see it happen, not even in the next 20 years. I still love to play the originals. Nothing wrong with them. I actually think they have the edge over TDM, gameplay wise. There's also the matter of consistency. TDM missions are pretty diverse, depending on the mission author. Not just style wise, but, also gameplay wise. The original Thief's are obviously much more consistent. Whenever I start the original Thief's after a while of only playing TDM, it's sort of coming home.

I was thinking about the new gameplay in next Thief game because I think it should be improved along A.I. I would like Thief has blunt arrows which he can shoot first guard in the below knee area. Thief shoots from the dark shadow so he's not seen. Guard tumbles down, then stands up and he sees second guard and thinks the guard pranked him with the blunt arrow. This could lead to intense gameplay and funny dialogue. G#1: "You shot me with the arrow." G#2: "No I didn't." G#1: "But we're the only ones in the room." Garret is in the shadows and yellow is vision cone of the first guard who tumbled down.

Nintendo is a pretty abysmal company in many respects, but this is one area where their priorities are better put together than their western competitors. They show that you can actually make ends meet by focusing on gameplay and atmosphere over graphics. In fact it's hard to dispute that that is the key to their success as a company. It seems like the only times they ever get into real difficulty is during the generations where they try to modernize their consoles. They've also survived for over 20 years in the console wars against two global mega corps. It's rather surprising none of the other AAAs are really tying to challenge them for that apparently quite reliable niche. On the other hand maybe that is the point. Nintendo is the beloved king of gameplay focused, low-fi franchises. If an Activision or a Sony tried to muscle in on that territory and Nintendo decided to fight back there can be no doubt of who would win. Nintendo has years of developer experience, a positive track record, and a loyal customer base. I do think there is more to it than that. If you have an XBox, Play Station, or gaming PC there is nothing stopping you from getting almost the full Nintendo experience via indie copycats, but no such luck for the Switch-only owner who wants to dip into AAAs. Anyone who wants the best of both is going to go for the high fidelity consoles, and once you have the graphics card you might as well use it, even if it costs extra. In that sense I suspect the AAAs are rational, but its still interesting that they don't hedge their blockbuster bets with a lot more reliable low fi offerings. You'd think it would pay off in the long term, even if only by nurturing talent to tap for their big projects (like how Hollywood still finances marginal projects despite the summer blockbusters being their bread and butter).

I think we all agree that good graphics are nice. The thing is, though, that a significant amount of work and budget has to be done for the shiny visuals alone, the hardware has to work hard to display it, and the games are getting a massive size on the hard drive. And, IMO, shiny visuals is the wrong way to go. The gameplay and atmosphere (including, and, epecially, the game's soundtrack and audio) are, in my eyes, much more important that high definition graphics (my best example for that would be System Shock 2. I already get goose bumps when I just play the intro of that game.). It's a shame to see the development over time, with people only caring about graphics. Every second game is trashed because of bad graphics or performance these days. And games like Assassins Creed, whose gameplay is as shitty as it gets, and requires absolutely zero skills (and gives you zero achievement that you've done something special), are AAA games with tens of millions of sold copies. It also shows the Zeitgeist, and the shallow mentality of the target audience these days. It's really sad to see. But, I guess it's the fate of most things which get commercially interesting for companies. At some point, it's just doing professional work, for a safe investment return. Instead of the creative "Let the game designers go wild!" in the early days (thinking Deus Ex, Thief, System Shock etc.). Also happens with most musical genres. Over time, they get less and less interesting, more professional, sterile, less creative, more professional handicraft.

Hidden Hands: Vitalic Fever Filename : hhvf.pk4 Date of release: 20/07/2019 Latest Version: 3 (17/02/2021) Download via the in-game downloader or here: http://www.southquarter.com/tdm/fms/hhvf.pk4 http://darkmod.taaaki.za.net/fms/hhvf.pk4 http://www.fidcal.com/darkuser/missions/hhvf.pk4 Known bugs: - stencil shadows do not work correctly (version 1) - sometimes, the character "Applefinger" cannot be knocked out when sitting on the chair without failing the mission. (version 1) Hidden Hands Series: I. Initation - II. Vitalic Fever Jack Farmer: mapping & drafts Amadeus: alpha testing, geometry fixes, performance checks, drafts for gameplay and objectives, revision of all readables, dialogues & narrator texts Grayman: AI fixes, gameplay fixes, trap fixes Duzenko: alpha testing, performance checks and improvement tips Beta Testers: - Joebarnin - Cambridge Spy - Boiler's Hiss (aka "The architect's darling") - Jedi_Wannabe (aka "The man of many voices") - Amadeus (aka "The Writer") Voice actors: Malasdair Narrator Jedi_Wannabe All four guards chatting about the guests, chickens, inventions and unusual job interviews New Horizon The educated Builder Goldchocobo The naive Builder Special thanks to: - Springheel, Sotha, and Fidcal for the tutorials. - VanishedOne, Stumpy, Destined, Grayman, Joebarnin and ERH+ for patiently answering my questions solving all the in-game problems. - PsymH (aka "Stringer Bell") for connecting me with the right guys on TTLG for additional voice acting. - Goldwell for teaching me how to integrate a custom video in a fms and helping me with troubleshooting during the integration of one of the Builder's voices. - all voice actors & beta testers for their great support. - all others not mentioned here who answered my questions in the Newbie thread or via PM. Contributors from the Inventor's Guild: - Destined wrote a new definition for the "spidsey-babsies", enabling those beasts to move through tunnels. - Grayman wrote a script enabling Halfrid to hold the quill only when it is needed. He also fixed several other AI problems with respect to path finding, damages and interaction with light switches. Pilfered items: - Portal sky with hills and trees originally developed and arranged by Sotha for "Thomas Porter: The Transaction". - Frobbox booster re-created from a map originally developed by Grayman All new ambient music and sound effects written, performed and mixed by Jack Farmer. Briefing video by SirSmokeAlot Pictures

Terrific! The beta test thread is up: https://forums.thedarkmod.com/index.php?/topic/22238-beta-testing-the-spider-and-the-finch/

Welcome to the Dark Mod forums MarsManon! Thank you very much for the kind words about SLL, it's always nice to hear We all worked real hard on bringing Grayman's map to life and I'm glad you enjoyed it

I was so enchanted by this FM, I had to sign up to the forums the same day I finished it to come thank the authors Genuinely, truly incredible work! I was so overwhelmed in places that I resorted to just shouting joy at my monitor two, three, maybe four entirely separate times while playing. Exploring, puzzling, finding something new, trying to use it, and finding it does a whole new, separate, wonderful thing! There aren't enough words inside me to describe the feeling. It was breathtaking. I don't have any specific feedback that hasn't come through this thread before Thanks so much for making this, for all the inspiration and ingenuity and effort it took. If I never play another level this good, in any other game, in my life, I'd be fine with that.

Ulysses 2: Protecting the Flock By Sotha The mission starts some time after the events of Ulysses: Genesis, and continues the story of Ulysses. It is a medium sized mission with a focus on stealthy assassinations and hostage liberation. BUILD TIME: 12/2014 - 05/2015 CREDITS The TDM Community is thanked for steady supply of excellent mapping advice. Thanks goes also to everyone contributing to TDM! Voice Actors: Goldwell (as Goubert and Ulysses), Goldwell's Girlfriend (as Alis) Betatesters: Airship Ballet, Ryan101. Special Thanks to: Springheel and Melan (for proofreading). Story: Read & listen it in game. Link: https://drive.google.com/file/d/0BwR0ORZU5sraRGduUWlVRmtsX3c/view?usp=sharing Other: Spoilers: When discussing, please use spoiler tags, like this: [spoiler] Hidden text. [/spoiler] Mirrors: Could someone put this on TDM ingame downloader? Thanks!

@datiswous, made that correction fm_test.subs --> fm_conversations.subs @stgatilov, about srt naming and file location, would you be OK with the following edit? New/changed stuff in italics: srt command is followed by paths to a sound sample and its .srt file, typically with matching filenames. An .srt file is usually placed either with its sound file or in a "subtitles" folder. The .srt file format is described e.g. [1]. The file must be in engine-native encoding (internationalization is not supported yet anyway) and have no BOM mark. It contains a sequence of text messages to show during the sound sample, each with start and end timestamps within the sample's timeline. It is recommended to use common software to create .srt files for sound samples, instead of writing them manually. This way is more flexible but more complicated, and it is only necessary for long sounds, for instance sound sample of a briefing video. It's a simple enough standard that it can be shown as an short example, demonstrating that subtitle segments can have time gaps between them. And the example can show correct TDM usage, without requiring a trip off-site and picking through features that TDM doesn't support. Specifically, the example shows how to define two lines by direct entry, rather than using unsupported message location tags (X1, Y1, etc.). And skips other unavailable SRT font markups like italics, mentioned in the wikipedia description. The example would also show the TDM-specific path treatment. The example could be inserted before the sentence "It is recommended to use common software...."

I looked into this. The lightgem code is quite involved as there are many factors that influence its final value. I'm mostly sure I found the final value, and when I compared the two leans at the spot shown in the video in the training mission, the new lean had an increase of roughly zero to one lightgem unit. Rarely, there would be a two unit increase. The lightgem range is 0 to 32. So, where the old lean would be 15, the new lean would be 15 or 16 (or rarely 17). Would that actually make a difference in gameplay? I don't know. Also of note, if the lean angle is increased, the lightgem value decreases at that spot with that particular lighting. The old lean angle is more than the new lean angle, so that is why there is roughly a zero to one unit difference.

@Wellingtoncrab In regards to getting discouraged by criticism I was more refering to the reaction of mappers in general. And as stated, I am not for changing it in the core mod (don't mix up my posts with those of others). It has been like this for so long that it doesn't make sense to change it. I, however, consider it important to discuss such things to simple bring it to the mappers attention, as if something is done in a certain way for long enough, people, including myself, tend to stop thinking about it. And yes, the missing balance in tools given, among other aspects, is a general observation. It neither implies that it is like that in every single mission nor does it mean that there has been no thought put into this by the respective mappers. However, putting thought into something doesn't guarantee the best results, so feedback and criticism is vital, as maybe the concepts that went into those thoughts have issues or things have been overseen. I for one just added my opinion in a response to a statement made by Dragofer. The original intent of the thread is not refered to by me. Despite beeing named as mission author I am not. The mission is by Bikerdude, I just helped with scripts and performance. And it has quiet some of the flaws I mentioned here and in other threads, too, like my own mission have (Old Habits and Builder Roads). One other thing both the Elixir and my first Release have in common is bottleneck design, something extremely common among TDM fms. In Old Habits you have to find a specific key to be able to get to the upper levels, and the key is hidden. If you are unable to find the key, something that happened to some players, you end up coming to the forum and making a post starting with the magical words "I am stuck...". Something you read in a lot of mission threads. The Elixir suffers from the same issue. That's one thing I changed when creating the rebuild, providing an alternative way. Other things are no kill objectives (I added it because Thief had them, not for a gameplay reason), and today I would probably not add loot objectives. The light placement allows for players to always have a corridor of shadow to walk through without getting spotted, which is extremely artificial. In regards to the loot amount I am not sure anymore, but iirc it at least differs difficulty dependent. Builder Roads was a bit of an experiment, which automatically leads to flaws. The main thing is that the whole setup doesn't allow for much variety in how you approach the mission. And again there is only one way to fulfill the main objective, requiring the player to solve a puzzle (which sometimes doesn't work ). If he is unable to, he cannot finish the mission. Those missions are old, though, and so are others. I am not as critical to old missions as I am to new ones, because there was a lack in experience back then. But I would have liked to see some sort of evolution in terms of gameplay, which didn't happen (in the sum!). The missions get bigger, they look better and overall production quality increased. But the gameplay didn't. And this is no surprise if almost everytime you write a critic mappers feel offended, even if you stress positive aspects, too, and try to be as objective as possible. This was more so in the past then in the last time, so I guess the mood has changed a bit around here. (Lots of drama going on in the past, so people were probably a bit more thin-skinned). There are two things btw. where I have gotten positive feedback on Old Habits. The loot placement and patroling. The first caused me to pay more attention to it in other fms, noting that there is no (obvious) logic behind it. So I asked. And tell you what: Neither players nor mappers consider loot placement or the values important. At least back then, although I can't say it has changed much. In regards to patroling I was told that it almost appeared as if the patroling was timed (aka thought went into it) and I just thought: "Of course they are, that's a fundamental part of the gameplay. To tight and it becomes unfair, to loose and it becomes boring." But the response and my own observation in other fms tell me that this is something rarely (not never!) taken into consideration. So I don't consider my own work much better in regards to gameplay, from my nowadays standards they are mediocre at best, and my criticism is not only based on how I perceive the missions, but also on the kind of feedback and statements I have read in the forum over the years.

Just finished this. Really enjoyed this mission. Nice details throughout the mission, good gameplay and the story was ok, though it did lack depth in terms of readables. I had a few issues with FPS, probably due to all the extra buildings added that are not needed or seen unless you noclip around. Same with the ship. Better visportalling will probably fix that up too. Overall an very good mission, could do with a little refinement, but I really enjoyed it. Thank you for your hard work. It was worth it.

Just took a few minutes to give this a go, and I 've had no issues at all. As far as I can tell it works as intended: frob to shoulder body frob to unshoulder body hold-frob to drag body hold-frob to pinch candle It seems to prioritize highlighted objects just fine (loot bags on bodies, doors while shouldering, etc). I'm quite happy about how it works, tbh, in terms of gameplay. It's a relief to have no unnecessary steps to it. I played my unpatched game just to check everything else behaves the same, and I immediately had a bit of a hiccup with the controls. I don't often blow candles or shoulder bodies, since I tend to ghost more often, so I don't exactly have to default controls in my muscle memory. I had to remind myself I was playing the unpatched version and that there's extra steps to it, because the patched controls are so more intuitive to me that I had already got used to them (in just 5 minutes of goofing around).

That would be great, but what I would really like is just a cvar to reverse the short frob and long frob behaviour for bodies. Also the optimal solution would probably be to add gameplay options so each player can set this how they want it! This would also fix the problem of players not knowing about the new controls. But then this might be a lot of additional work.

Does this mean the new lean will get you potentionally more exposed? Because it should be. I think with the current lean you peak your head around the corner, but with the new lean feature you just step aside. That's what it looks like. If the new lean system is easier to use, shouldn't there be a trade-off? I personally do like it when there's some realism in gameplay. If something feels wrong because it's unrealistic, then I notice it. I think that could be actually cool, but I think first breathing sounds need to be introduced, music disabled.. Maybe something to try out in a specific mission build.