Search the Community

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!

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.

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

Nice walkthrough, i made it in Hard mode, entering in the sitedoor, which i think is somewhat more tricky than with the Ropearrow (not disp. in the Hard mode), Without KO nearly impossible, at least for me. I made it with 782 loot and 0 stealth. Inside is easy, normal stealth level, also~20 min. In the Bar no stealth needed, at least when you don't rob the coins of the card player, they don't like it with the lights on. Also don't try to frob the Key for the Main entrance, not healthy with a Guard with torch, who turns in a half second without the key.

Last night we chatted on Discord about Vulkan support and PBR, bringing up a system for adding proper reflections once more. I suggested screenspace reflections but it was argued reflection probes would still be better than SSR in our case, a ticket for that is already open but I'm uncertain whether it's the best way: A manual approach would need new entities to be placed by the mapper... this requires extra effort and would exclude old FM's that are no longer updated, while the result will also be inaccurate and static meaning you won't see an AI reflected as they walk on a shiny metal plate for instance. If PBR with realistic graphics can be a hope for 2.12 or later, we'll definitely want to do it right rather than using a limited / limiting system. A technique came to mind that might just work for our engine and setup. I wanted to share it here before I forget the specifics; This might already be a common practice and even have a definition, for the purpose of this thread I'll just describe it as I originally imagined it and feel this would work for our engine. The idea is we'd use reflection probes but in an automated fashion: A probe is automatically spawned in every valid area (within bounds) in the player's view, at a given grid unit size. For example: If the grid scale is 16, a probe may exist at position '0 -48 16' another at ''0 -48 32' and so on. Every point projects its result on all surfaces in its radius which contain a specular channel masking it, the best alternative presently available till we were to convert all textures for PBR support. The cool thing is the same cubemap can also be projected as a light source, allow for global illumination in addition to just reflections! This would be similar to how the Irradiance Volume works in Blender / Eevee except each dot renders a little cubemap from its perspective. I already know what everyone is rightfully thinking: This is going to kill performance! After all each probe needs to produce a render from its perspective, and being a 360* panorama it will open portals in all directions. Normally that would be insane, but I thought of various ways in which the impact could be greatly minimized to very bearable amounts. The frame buffer of each probe will be at a very small resolution by default since much detail shouldn't be needed. Even 64x64 per cube face might do. Each probe only needs a draw distance double its grid size, given it only has to see as much as is necessary to fill the gaps between it and its neighbors. So if the grid size is set to 64, each probe would only have a draw distance of 128 to cover the space in between its neighbors, nothing beyond that would exist to it. Only probes the player can see would ever be spawned and calculated; If the view frustum doesn't overlap the virtual cube who's corners touch that probe's neighbors, the probe is dropped from memory. Probes are also only spawned in a valid visible space, never out of bounds including rooms culled by portals. A draw distance after which probes are removed or not spawned can also be included. This would further help by making any probe further than X distance be ignored, slowly fading away as to not noticeably pop in and out of existence. Reflections / GI are a discrete effect you'll only see up close. Similar to lights and shadows, the result of a probe should be cached and not calculated unless necessary. This means that unless something moves within radius of that probe its cubemap won't be rendered again. Probes would only be updated either when they first come into the player's view, or if something touching their cube has moved. Note that particles and lights with animated textures would have to count as you may see them in a detailed reflection, candles and torches would force constant updates per-frame for probes they intersect. If with all that performance is still affected, frame skipping is also a solution: Reflection probes can update at a lower frame rate to further decrease their impact. If you have a 60 Hz monitor and are running TDM at 60 FPS max, reflections could run at 30 / 20 / 10 FPS without looking out of place. They could in fact be defined as a fraction of your average framerate, so for the FPS you get you can decide whether it's going to be 1/2 or 1/4 or so on of that... this would have the added advantage of exponentially gaining back FPS the lower your FPS goes. There are several reasons why I believe this would be better than mappers manually placing new probe entities: Extra work is required for the mapper, who needs to figure out how to cover each area in probe lights. Every piece of the map would need to be encompassed in a reflection / GI probe otherwise you won't get shiny surfaces or bounce lighting which will look out of place. Most existing FM's will never be updated to use this: Only maps created or updated after the feature is introduced would benefit, anyone playing old missions will get boring visuals without reflections / GI which will be inconsistent to new ones. I strongly believe this should be done as an universal effect like SSAO. Single large probes will produce inaccurate results; The larger a cubemap is, the more drift and a fake results you get with distance from its center. This can be mitigated by using parallax corrected cubemaps which should be used for automated cubemaps too... none the less you get a single point of vision for a large room which makes the result inaccurate the further you go... with an automated approach you could have many probes in a dense grid (if your hardware allows it) for a much more accurate result at any position and angle. What are your thoughts on this solution, do you think it's realistic and can work out? I do believe it should be either this or screenspace reflections the way they're done in Godot or Blender / Eevee. If SSR isn't the right choice for our engine, reflections and global illumination alike could be captured using a global grid of capture points shining within their respective areas.

I reported about this a lot during beta testing and some of these got fixed I think. I think the reason is that the mission has a lot of noshadows lights, for better performance. Source Possibly with the performance improvements in 2.11 (stencil shadows + Ai processing) it's not needed to have so many noshadows lights in there. Fixing whould also make the mission look better. I'm sorry to hear, hope you recover soon.

Thanks: will look at the lights changing - that might be the same ambient thing that happened in the square I've fixed the readable already for an update I'm getting ready the pool - the lights are magic

Regardless of what is used in the end, I think we should move auto-loot to that too for everything to be consistent. Right now auto-loot is long-frob, bodies and lights are double-frob and consumables are frob+use! Rather an unintuitive mess.

I played both test versions with "The Bakery Job" and as everybody could guess, I like stgatilov's version better because it is consistent. I don't see why daft's version should be more intuitive, especially as shouldering bodies and extinguishing lights are working in opposite ways. Still I believe that without a tutorial or key binding hint, no new players will discover either version on their own as double-frob and long-frob are not used elsewhere. stgatilov, is it possible to make both double-frob and long-frob work in your version? Also to really make this consistent, could you add eating food on double frob too, please?

At the risk of derailing the conversation, here's something I threw together today. It's a re-imagining of a tiny part of the training mission, specifically the hallway where you use moss arrows to sneak up on a Builder guard and then hide his body in an upstairs storeroom. I agree with @ChronA that the training mission is only competent, not exceptional, and as a tool for attracting new players to TDM it doesn't really get the job done. One problem is that the TDM universe doesn't really have anything like the Keepers, so it's difficult to reproduce a cool training mission like A Keeper's Training. The changes I made for this tiny snippet is that the instructions are nearby, not hidden in a static book in another room. The crucial information regarding shouldering v dragging is communicated via a GUI immediately after you KO the Builder guard. @Wellingtoncrab, if you'd seen this popup on your play of the training mission would it have taken a happy accident to rediscover how to shoulder bodies later? I also added volumetric lights, EAX, and secrets because I figure if the training mission were ever to be revamped it should show off all the coolest new features :] (if you look around a bit you'll also see a shout-out to T1 architecture. because I like it, and because I think paying respects to the original is decent) ztraining.pk4

OK I think I've got to the bottom of this. I've created this forum thread (with bug report): https://forums.thedarkmod.com/index.php?/topic/22221-bug-drowning-ai-in-shallow-water/ I can apply a workaround, although it won't be perfect and the bug itself needs fixing in the engine. There are a few other things that need fixing so will put an update together soonish.

If any mappers have encountered weirdness with kill objectives not working with drowning AI, I think I've found out why. I don't think it would be a particularly difficult one to fix either. I've raised this bug report: https://bugs.thedarkmod.com/view.php?id=6323 Some context here: https://forums.thedarkmod.com/index.php?/topic/21837-fan-mission-the-lieutenant-2-high-expectations-by-frost_salamander-20230424/&do=findComment&comment=487316 I think this is a bug, but just raising here in case some people think otherwise.

I think I found a way to settle this. Managed to put together a script / addon which emulates this functionality. The advantage is you can use it in any FM: Drop the pk4 directly inside your TDM folder and it will automatically work. Two versions are provided: One turns the light off entirely, the other only disables its shadows... don't use both at once but pick one. Just remember this is a testing script and will break your run! For one it doesn't know when a light is meant to be turned off, thus will enable even lights that started or were toggled off once they're in range... meanwhile the nowshadows version enables self lighting on torch models which looks wrong. They also seem to cause infinite loop crashes on occasion, though it should take long enough for them to occur in order to obtain a result. light_dist.pk4 light_dist_noshadows.pk4 // Test script for hiding lights with distance #define DIST_TORCH 1024 #define DIST_GAS 1536 #define DIST_ELECTRIC 2048 void light_dist() { while(1) { // sys.waitFrame(); sys.wait(0.5); player ent = $player1; entity ent_find; // Do torch lights do { ent_find = sys.getNextEntity("lightType", "AIUSE_LIGHTTYPE_TORCH", ent_find); if(ent.distanceTo(ent_find) > DIST_TORCH) ent_find.Off(); else ent_find.On(); } while(ent_find != $null_entity); // Do gas lights do { ent_find = sys.getNextEntity("lightType", "AIUSE_LIGHTTYPE_GASLAMP", ent_find); if(ent.distanceTo(ent_find) > DIST_GAS) ent_find.Off(); else ent_find.On(); } while(ent_find != $null_entity); // Do electric lights do { ent_find = sys.getNextEntity("lightType", "AIUSE_LIGHTTYPE_ELECTRIC", ent_find); if(ent.distanceTo(ent_find) > DIST_ELECTRIC) ent_find.Off(); else ent_find.On(); } while(ent_find != $null_entity); } } // Test script for hiding lights with distance #define DIST_TORCH 1024 #define DIST_GAS 1536 #define DIST_ELECTRIC 2048 void light_dist() { while(1) { // sys.waitFrame(); sys.wait(0.5); player ent = $player1; entity ent_find; // Do torch lights do { ent_find = sys.getNextEntity("lightType", "AIUSE_LIGHTTYPE_TORCH", ent_find); ent_find.noShadows(ent.distanceTo(ent_find) > DIST_TORCH); } while(ent_find != $null_entity); // Do gas lights do { ent_find = sys.getNextEntity("lightType", "AIUSE_LIGHTTYPE_GASLAMP", ent_find); ent_find.noShadows(ent.distanceTo(ent_find) > DIST_GAS); } while(ent_find != $null_entity); // Do electric lights do { ent_find = sys.getNextEntity("lightType", "AIUSE_LIGHTTYPE_ELECTRIC", ent_find); ent_find.noShadows(ent.distanceTo(ent_find) > DIST_ELECTRIC); } while(ent_find != $null_entity); } } With the defaults I balanced it at, I admit I'm not all impressed with the result on my FM: The popping is noticeable and the performance improvement doesn't feel as radical as I would had hoped even if it's there. With r_showprimitives it does seem to kick about 300.000 triangles off when fully disabling the light which doesn't seem too bad... not giving any more verdicts this way though, I'll let the devs play with the script and decide what to make of it.

The fewer words you need to explain your mechanic the better it is designed: For static objects press "frob" to interact with them. For moveables press "frob" to grab them and "use" to interact with them. TDM follows these simple rules nicely. @Daft Mugi I welcome this initiative and I encourage you to carry on experimenting. Here are my thoughts: Interacting with moveable lights: currently to extinguish a candle I must "frob" it and "use" it. If I extinguish a candle unintentionally it is my fault (I pressed the wrong button). With your design, is it my fault if I frobbed a candle 201 milliseconds and extinguished it unintentionally? Long-pressing buttons in TDM is faulty because there isn't any visual timer / bar / whatever. Dragging vs shouldering a body: interacting with the limbs of a body is the more challenging of the two mechanics. Do we really want to promote the easiest of the two and make the challenging mechanic more difficult? Besides, with your design I unintentionally drop bodies often while I intend to interact with doors, is it my fault? In my opinion the short term solution is a very long frob (0,5 secs or longer) to extinguish a candle and/or shoulder a body. Leave the original mechanic intact but have the new functionality somewhere in there for those who want them. The long term solution is something else: what would you do if you were to build these mechanics from scratch? Think big. PS1: Developers should never point players to anything that isn't available in the in-game settings. cvars should be there for 1) debugging 2) testing 3) very special cases, mainly accessibility / usability. PS2: "This is how Thief does it" sounds like a lame excuse. Thief is dead, TDM is alive!

With actual raytracing being a long time away from even being imaginable in our engine, I've become a growing fan of simulating bounce lighting with the conventional lighting system we have. It's good for realism and because I love that warm soft light emanating beyond walls from one candle in a dimly lit area behind. TDM currently has no global illumination, the only form of estimating GI being a constant light that changes per area based on the amount of lights in that portal zone (great system but not enough). Today it just occurred to me that for starters, it wouldn't be that hard to attempt a simple yet more effective estimation. Initially I was going to write a script for it before realizing I could just do this via defs alone! The rule is simple: For each normal light, we attach a secondary light of roughly the same radius, textured with a low-intensity ambient light (lights/ambient_biground) to simulate directionless diffusion with minimal impact on performance. I wrote one def for my bounce lights and another to override all of the builtin light types and attach the appropriate one and that was it! Kind of, it's never that simple. Here's my patch in its initial form and a few screenshots of what it achieves, mainly noticeable as a dim light showing through the shadow of the standard one. tdm_bouncelight_v1.0.pk4 Of course it's not all rainbows and sunshine. As you probably expected, this approach has the fatal flaw of lights shining through walls as the area lamp casts no shadows. This looks horrid from other angles where you see walls being lit out of nowhere by sources on the other side. That's the result of candles and torches shining through the floor from other rooms... not okay and unfortunately a deal breaker until I found some way to fix it. Apart from this it appears that with a lot of lights in more complex maps, performance takes a considerable hit while even freezes and crashes are being introduced by the extra lights... I find this strange given ambient lights cast no shadows nor do they do per-pixel calculations like specular or normal mapping, and most don't even move so shouldn't they be cached? I don't know to what extent it would be a waste of time to approach this further: On one side it's a tedious task and my hope of getting it to work with just one extra light is naive... on the other side as you can see from the first batch of screenshots, it can look gorgeous if done right, this gives us a glimpse of what we could have with a proper system. Normally this needs to be coded in the engine to get any sane results anyway, especially as this setup calculates no actual bounces just adds a radial glow to estimate it, surfaces don't colorize the light and there isn't any real bouncing going on in any form. Of course I don't have a fraction of the knowledge to do that, and I'm not gonna be this cruel to @cabalistic and other graphics devs to suggest this after all the other exciting yet difficult ideas I've been bringing up. What are your thoughts on this? Can you suggest any tricks to fix the lights going through walls when they shouldn't, or perhaps a better approach altogether? Maybe I can define my own light texture to reduce wall leaking but not destroy the immersion otherwise?

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.

Holy crap this problem is driving me crazy downloaded whole another copy updated windows updated drivers deleted netframeworks reinstalled them nothing works ! look at this

At the moment I feel pretty stuck: Engine changes may be needed in the end, even for a cheap estimation that can do the minimal thing of not leaking through walls it can't physically travel past. My last hope was to try modifying the default ambient light material and turn it into a cube, knowing every map has one of these surrounding it so it would automatically work on most. At the moment darkmod/tdm_textures_base01.pk4/materials/tdm_light_textures.mtr/lights/ambientlightnfo looks like this: lights/ambientlightnfo { ambientLight lightFalloffImage makeintensity( textures/lights/ambientlightnfo) { forceHighQuality map textures/lights/ambientlightnfo_amb colored zeroClamp } } With my idea it would probably be something like this... correct any obvious mistakes there. lights/ambientlightnfo { ambientCubicLight lightFalloffImage makeintensity(textures/lights/ambientlightnfo) { forceHighQuality map textures/lights/ambientlightnfo_amb colored zeroClamp } { forceHighQuality cameraCubeMap env/my_realtime_cubemap colored zeroClamp } sort postProcess { vertexProgram bounce.vfp fragmentProgram bounce.vfp fragmentMap 0 _currentRender fragmentMap 1 _fsfx_input } } If bounce.vfp doesn't know the geometry and lights in the area however, there's not much I can do then. Hoped I was onto something but any approach has a lot of complexity attached to it.

Author note: It's hard to believe it's already been a year since Act 1 came out! Well during this mission the player will be following Corbin into the Grimwood district to followup on a lead from last night (Act 1) .. the mysterious tablet! This mission is my first time including full EFX support as well as a HD briefing video file, additionally a new script has been added crafted by the talented Obsttorte which has loot flying towards the player when you pick it up. On a level design front I have tried to change things up a bit by really catering towards a number of play styles, this mission can be completely ghosted or you can use the tools at your disposal to wreak havoc on the citizens of Northdale. For the first time I have tried to create more sandbox environments which don't offer clear answers handed directly to you, so if you're having trouble figuring something out try a different method. This mission takes between 1 - 2 hours to finish depending on the difficulty you play on and how thoroughly you explore. I hope you enjoy your night in Northdale! - Goldwell Voice actors Fen Phoenix Goldwell Random_taffer Yandros Beta testers Amadeus Boiler's Hiss Cambridge Spy Chakkman Crowind Epifire Kingsal SquadaFroinx Custom Assets Andreas Rocha DrK Epifire Grayman Kingsal MalachiAD Obsttorte Sotha Springheel SquadaFroinx Purgator With special thanks to Epifire for creating a large collection of custom models, Grayman for helping out with coding, Kingsal for drawing the ingame map and Moonbo for his script revision on the briefing video. Available via in-game downloader MIRROR File Size: 417 mb EDIT: If you are having performance issues please consult this post by Nbohr1more which may address your issue http://forums.thedarkmod.com/topic/19936-fan-mission-shadows-of-northdale-act-ii-by-goldwell-20190320/page-2?do=findComment&comment=436271

Sorry about this but I'm having another problem, I decided that I would now take the plunge and start mapping, I made a good start with prefabs and models and only used 1 brush, I then added an amdient light and a streetlight model that I used before that was pre lit, using F3 it showed the light was working but the alarm bells started ringing when I used light inspector and Omni was faded out, projected was selected but none of the functions in the right hand pane were usable. No prelit light source works in game.. do I throw the computer out of the window and become a monk?? or do I uninstall Dark Radiant and reinstall it?. Thanks Peeps.

Hello TDM-ers. I am encountering an issue where textures seem to partially disappear. I tried searching the forums, but, I don't know what to search for. The missing textures are a worldspawn brush acting as a roof with {for now} flat iron texture. There are other worldspawn brushes right below to create an attic ceiling with roof framework board texture. These gaps appeared a few edits ago. I can't "undo" to get back before whatever edit did this. The gaps are only visible during play and are not visible during editing. Closing and reopening DR and TDM do not fix anything. Some of the brushes overlap in areas behind the play area but I have never seen an issue doing that. The attached image has the effect I am now seeing. Ideas on where to start debugging this? Very much appreciated. Clint

DarkRadiant 3.0.0 is ready for download. It took a while, but DarkRadiant 3.0.0 is finally available. Most of the time has been spent on improving DarkRadiant's renderer, which now features shadow mapping support of up to 6 lights. It's still not matching the engine's output (especially in terms of performance), but it should be faster and much more helpful than it was before. The effort that has been put into the renderer rewrite plus the bigger changes in the previous few releases make the jump to the next major version feel more than justified. Besides of that, a lot of non-renderer issues have been resolved in this release too, next to some fine usability improvements. For more things that have changed or fixed, see the list below. Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.0.0 and of course linked from the website https://www.darkradiant.net Thanks go out to all who helped testing this release! And I'll gladly repeat myself, by thanking all the awesome people who keep using DarkRadiant to create Fan Missions - they are the main reason for me to keep going. Please report any bugs or feature requests here in these forums, following these guidelines: Bugs (including steps for reproduction) can go directly on the tracker. When unsure about a bug/issue, feel free to ask. If you run into a crash, please record a crashdump: Crashdump Instructions Feature requests should be suggested (and possibly discussed) here in these forums before they may be added to the tracker. Changes since 2.14.0 Feature: Realtime shadow mode Feature: Allow way to hide some entities in Create Entity list Feature: MD5 Animation Viewer: show current frame & total frames Feature: MD5 Animation Viewer: jump to frame Feature: DarkRadiant warns about missing .darkradiant file on load Feature: Ability to center 3D camera on selected entity Feature: Cut functionality to complement copy and paste Feature: Save user settings by application version Fixed: Free Rotation not working anymore, can only rotate along 3 axes Fixed: DR crash with combination of mouse buttons pressed Fixed: Git Sync Exception: too many redirects or authentication replays Fixed: Missing brushes when opening alphalabs1 from vanilla Doom 3 PK4s Fixed: Selected Skin not showing in ModelSelector Fixed: Reload Defs takes longer every time Fixed: ForceShadows materials are not casting shadows Fixed: Objective GUI doesn't display properly in some places Fixed: Crash on loading certain maps Fixed: Vertex colours do not show on models in lighting mode Fixed: Entity inspector shows inherited spawnargs of previous selection Fixed: DR overwrite order for defs is different from TDM's Fixed: X/Y and Camera View bindings don't save properly Fixed: Material Preview rendering Fixed: "Replace Selection with exported Model" sets classname to "func_static". Fixed: Map -> Edit Package Info (darkmod.txt)... crashes DarkRadiant Fixed: Rotating a func_static result to random stretch textures Fixed: DR crashes when syncing with remote Git repository Fixed: Switching visibility of Github repo from public to private causes crash Fixed: Dockable window layout doesn't save new floating XY views Fixed: "Choose skin..." button on custom model spawnargs shows skins for main model spawnarg Fixed: Entity inspector considers inherited colors black Fixed: ReloadDefs moves def_attached light crystals to entity origin Fixed: Option to filter skins out of search results in the Choose Model dialogue Fixed: .lin files can't be opened if different case than .map name Fixed: Model chooser radio box selection issue Fixed: Changing multiple lights between omni/projected resets colours to black Improvement: Allow absolute paths for snapshots Improvement: Light diamonds and Speaker radii are transparent Improvement: Unify Declaration Parsers Improvement: Add "Create Particle" to right-click orthoview drop-down menu Improvement: Revisit Interaction Shader to get closer to the TDM looks Improvement: Entity inspector should recognise spawnargs beginning with "sprS_" as def spawnargs Improvement: UI for worldspawn-to-entity conversion Improvement: classname field should always be read-only, to force use of the "Choose entity class" button Coding: Update solution and build dependencies to Visual Studio 2022 The list of changes can be found on the our bugtracker changelog. Have fun mapping!