Search the Community

Unless you are using Windowed mode, TDM locks its resolution to the native resolution of your desktop. If you want to reduce resolution for better performance, try adjust Render Scale slider instead. E.g. setting it to 0.5 would result in internal rendering resolution 960 x 540, i.e. 4x less pixels to render.

I just tested now. A few interesting results: I was able to load all the largest missions ( Painter's Wife, Iris, Penny Dreadful 3, BCD, NHAT v4 , Northdale 1, Written in Stone ) Some of the larger missions would not render shadows in Shadow Map mode if you had a higher r_shadowMapSize value ( resolution ) than the default 1024. Painter's Wife required you to drop to r_shadowMapSize 512 for shadow map mode. Many missions loaded with AAS32 out-of-date errors at the start. Missions had AI that were properly pathing but there was an increased prevalence of AI going in circles in tight areas. Not sure how valid this is because I have a 64-bit CPU and OS so Linux may be compensating somehow when the 32-bit memory limit is reached and allowing these monster missions to load? Edit: Tested the 32-bit Windows executable under Wine. I was able load BCD with no issue and ran fine. Iris loaded but had very low FPS ( 5FPS or less ) at the start and remained pretty unstable FPS wise 20 to 40FPS. Painter's Wife provoked an emulated Windows Crash on load.

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.

Just realized a flaw in my proposal: Each probes view range can't be just its distance from the neighboring probe, as that distance will also be the maximum distance of the reflection itself. At a grid size of 64 for instance, a probe in front of a wall would only reflect at most 64 units behind that wall. So reflection distance should be minimum the grid distance doubled to avoid gaps, but also higher if you want your reflection to fade further. This would mean some bad news for performance unfortunately. An similar yet different alternative would be for each point to capture and retain a single color, acting as a 3D pixel / point of light altogether. This would automatically emanate light and show up in specular channel without requiring material changes, tackling both GI and reflectivity at once... the grid size would be the resolution of the result in this case. But now we run into the issue that points behind the player need to be updated... in this case it would be best to calculate and remember all voxels inside a room the moment its portal is opened, only updating ones within radius of a light or object when there's movement near it.

No. The Aeden's staff optional objective is the hardest of the game. To point out directions here, though, is getting into an area of heavy-duty spoilers ... so I'm constrained in my response just as I was constrained in my responses to the "endless keyhunt" complaints because to show the rather simple direction would be a huge spoiler. So I had to bite my tongue and take it. Aeden's staff is different, though - harder. I've never tried a no-KO ghost playthrough. Because I'm clumsy and have slow reflexes. I think it might be possible to do a stealth no-alerts playthrough. Are you allowed to KO? I think I've gotten the staff a few times in my playthroughs without alerting the builders in that room. The only switchable lights in the FM are table lamps. The cylindrical style wall lamps aren't extinguishable. The other fire and gas wall lamps are extinguished by water. In the Ox all waiters and commoners in the common room and outside are friendlies - except for the waitress in the upper lounge which is filled with enemies. You need water arrows. Moss arrows. Rope arrows. I've never used a gas arrow in a playthrough of the FM but one would make things easier, for sure. I'm going to replay the area and check through the locations that you mentioned - the loop etc. - then if it's OK with you I'll PM you with some info, tho' I'll ask you if you want the info first. So's not to spoil it for others who get that far in the game (few and far between!). I find it almost impossible not to click the "reveal spoiler" tags and read the info ... and, y'know, spoilers do spoil the real deal.

I don't recall a system for noise masking. It sounds like it'd be a good idea, but when you get into the details you realize it'd be complicated to implement. It's not only noise that that goes into it, I think. E.g., a high register can cut through even a loud but low register rumble. And it's not like the .wav file even has data on the register of what it's playing. So either you have to add meta-data (which is insane), or you have to have a system to literally check pitch on the .wav data and paramaterize it in time to know when it's going to cut through what other parameters from other sounds. For that matter, it doesn't even have the data on the loudness either, so you'd have to get that off the file too and time the peaks with the "simultaneous" moment at arbitrary places in every other sound file correctly. And then position is going to matter independently for each AI. So it's not like you can have one computation that works the same for all AI. You'd have to compute the masking level for each one, and then you get into the expense you're mentioning. I know there was a long discussion about it in the internal forums, and probably on the public subforums too, but it's been so long ago now I can't even remember the gist of them. Anyway the main issue is I don't know if you'll find a champion that wants to work on it. But if you're really curious to see how it might work, you could always try your hand at coding & implementing it. Nothing beats a good demo to test an idea in action. And there's no better way to learn how to code than a little project like that. I always encourage people to try to implement an idea they have, whether or not it may be a good idea, just because it shows the power of an open source game. We fans can try anything we want and see if it works!

Yes, there is a 2.10 tracker to get Linux to do what is done in Windows (always desktop resolution). So changing the resolution in Windows should be similar to using the render scale slider ( r_fboResolution ). If you choose a lower resolution in the GUI and disable Sharpening do the game graphics become blurrier (as with resolution scale)?

DarkRadiant 3.6.0 is ready for download. What's new: Feature: Selection Focus (Ctrl-F) Feature: Add Radiant.findEntityByName script method Feature: Media Browser shows a thumbnail preview when selecting folders Feature: Map is remembering layer visibilities between loads Fixed: ModelDefs are shown in T-pose Fixed: Patch vertices are the wrong colour Fixed: Shader Clipboard source gets cleared on 'copy shader' operation Fixed: Nodes of hidden layers are still visible after loading the map Fixed: Can't close properties window Fixed: Merge Action rendering is broken Fixed: After using ToggleMainControl_Camera, the center panel is grey after restart Fixed: When using ToggleMainControl_Camera, arrow keys cannot be used to move the viewer Fixed: Property Panel not remembering undocked/closed tabs Fixed: Texture Tool not updating during manipulation Fixed: Orthoview ignores filters for surfaces in models Fixed: Blue dot when selecting one face removed Tweak: Conversation Editor: double-click opens selected conversation Tweak: Preference option to disable drag select in camera view Tweak: ESC key should clear the resource tree view filter text Tweak: New layers function: tooltip popup getting in the way Feature: Selection Focus (see video) Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.6.0 and of course linked from the website https://www.darkradiant.net Thanks to 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. The list of changes can be found on the our bugtracker changelog. Have fun mapping!

DarkRadiant 3.4.0 is ready for download. What's new: Feature: Allow Layers to be arranged into a Tree Fixed: Readable Editor displays "shader not found" in view Fixed: Undoing snap to grid with prefabs causes crash Fixed: Include doc in building instructions Fixed: Decal textures causes DR to crash - (textures/darkmod/decals/dirt/long_drip_pattern01) Fixed: Skin chooser: double click on materials list closes window Fixed: Selecting and deselecting a filtered child brush through layers leaves the brush selected Fixed: Material editor re-sorts stages on pasting image map resulting in wrong material stages list and wrong selected stage Fixed: Crash on start if engine path is choosen (Doom 3) Feature: Layers can now be arranged to form a hierarchy Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.4.0 and of course linked from the website https://www.darkradiant.net Thanks to 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. The list of changes can be found on the our bugtracker changelog. Have fun mapping!

I'm using the version from kcghost. I just tested and I can't see any difference inside the inventory. On the stats itself it doesn't show the different loot types (still seen in the inventory), but instead gives more info on stealth score. Edit: I see Dragofer made an updated version of his script. I have to check that out. Edit2: That version works: https://forums.thedarkmod.com/applications/core/interface/file/attachment.php?id=21272&key=02755164a3bed10498683771fe9a0453

DarkRadiant 3.5.0 is ready for download. What's new: Feature: More customisable layout, all windows and panes can be dragged and arranged Layouts like Embedded, Regular and Splitpane are superseded and have been removed Tweak: The LayerControlPanel's tooltip popup is now less annoying Tweak: Clarify distinction between Shadow render mode and other render modes Fixed: Show/hide Light Volumes for combined entities inconsistent Fixed: Currently applied particleDef not selected in Particle Selector Fixed: Layer visibility checkbox not reacting to double-clicks Fixed: Cannot toggle visibility of layers in Linux Fixed: Drag-and-dropping layers is not working in Linux Feature: Customisable Layout (click to see the videos) Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.5.0 and of course linked from the website https://www.darkradiant.net Thanks to 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. The list of changes can be found on the our bugtracker changelog. Have fun mapping!

I looked but didn't see this video posted in these forums. It's pretty cool.

@stgatilov, you said, RE string comparisons: I'm unclear if you are referring just to changes you made in 2.11. I think equality testing of two strings (one of which is "text") was working and is a good and expected capability, and should be supported. Including against an empty string. I noticed in your bug activities that you did remove some comparisons with ... == "". I see you also removed string concatenation with "\". No problem, but does that mean multiline macros are no longer a thing? (If so, I'll need to change some examples) BTW, the series so far hasn't really tried to cover the 2.11 changes, since I figured it's a work in progress. But since you did a great deal of GUI work in July, perhaps it's stable enough to try to consider it. I see the logs listed in bugtracker, but don't have access to the private forum threads mentioned there: https://forums.thedarkmod.com/index.php?/topic/20526-gui-refactoring/&do=findComment&comment=477179 https://forums.thedarkmod.com/index.php?/topic/21535-order-of-evaluation-in-expressions-materials-and-gui/ (Nor do I have SVN currently set up on my newer machine, for changelogs from there.) Any place else I should look?

Announcing the Release of 'Requiem' for The Dark Mod! Download Download the latest version of the Dark Mod here: http://www.thedarkmo...wnload-the-mod/ Download the mission here: Mediafire: http://www.mediafire...u89/requiem.pk4 Southquarter: http://www.southquar...ons/requiem.pk4 Fidcal.com: http://www.fidcal.co...ons/requiem.pk4 Create a folder in your Dark Mod install with the path "darkmod/fms/requiem" and place the downloaded .pk4 file inside. When you load up The Dark Mod, the mission will appear on the "New Mission" page. Requiem can also be found directly using the in-game loader. Gameplay Notes While this mission is playable in TDM 1.8, for an optimal experience please download and play in TDM 2.0 (or higher). Most inventory items in the game can be dropped, so no need to carry them around after they are no longer of any use. Note that If you use noclip or other console commands while playing, there is a good chance that you will break the intended flow of gameplay. Credits Mapping and Readables: Gelo R. Fleisher Voice Acting: Goldwell Additional scripting: Obsttorte Additional textures and assets: Flanders, Sotha, Grayman, Springheel, Bikerdude, Obsttorte Additional map optimizations: Bikerdude Testers: Bikerdude, Obsttorte, Gnartsch, AluminumHaste, Baal, nbohr1more, PPoe Custom Soundtrack: Leonardo Badinella - http://leonardobadinella.com/ Additional Music: Lee Rosevere - http://freemusicarch...c/Lee_Rosevere/ Marianne Lihannah - http://www.funeralsinger.net/ Vox Vulgaris - http://www.last.fm/music/Vox+Vulgaris/ A note from the author Hi all. While I've been involved in indie game development for a while now, I'm first and foremost a writer. My most recent project has been a novella that tries to capture the visual feel and tone of the Thief series (you can find the link below). As I was writing, I found myself playing a lot of Thief and Dark Mod fan missions, and got to thinking that maybe I wanted to make one myself, as a companion piece to the book. When I finished up writing, I had a bit of down time and decided to take the plunge. Having never done any serious mapping before, my plan was to make a small mission that I could bang out in a month or two and call it a day. Well, as sometimes happens, the project got a little bit bigger than I had planned. Ten months, and lots of elbow grease later, Requiem is finally ready for you to play. I'd like to thank everyone who helped pitch in to help make Requiem come alive, from those who took the time to answer my many questions on the forums to those who actively contributed to the FM. I especially want to thank Bikerdude who served as my mapping mentor, and Obsttorte whose clever scripts really turned what was in my head into the game that you are playing. Above all, I want to thank you for downloading and playing Requiem; I hope you enjoy it. Links of Interest Author's Blog: http://gfleisher.blogspot.com/ Companion Novella (Amazon): http://www.amazon.co...k/dp/B00BYEW02M Companion Novella (Smashwords): http://www.smashword...oks/view/298956

It wasn't a "sacrifice", it was a deliberate decision. People wanted the game to be as close as possible to the original, including pixelated graphics. If you ask me, the former version based on the Unity engine looked and felt better. But, hey... I guess I'm not the right person to judge that, as I never played the original, and always found that the art style of System Shock 2 is much better anyway. This also illustrates the issue with community funded games: Too many cooks spoil the broth. In game design, you need freedom, not thousands of people who want you to do this and this and that. Just take a look at the Steam forums and see how all those wimps complain again about everything. Hopeless.

First of all, I'd like to make sure we're talking about the same thing here... which if so is something I actually wanted to bring up for a while: When you change the texture on a surface in DarkRadiant, its scale setting is modified based on the resolution. For instance: If the previous texture was 1024x1024 and you set the scale of your face to 0.25 x 0.25, changing the texture to one that's 2048 x 2048 will automatically modify that scale to 0.125 x 0.125. This is something that has been annoying me for a long time: It's an effect I actually do NOT want! Don't get me wrong: I can see why it exists, it helps to keep pixel resolution of a surface the same which is actually neat and handy. But I for one prefer to set the scale manually and keep it at a fixed value as I change textures... typically 0.25 or 0.125. An option to disable automatic scale conversion when changing material resolution would be appreciated so I don't have to reset the scale whenever replacing textures. I don't want to see this conversion removed nor necessarily disabled by default (I'd have a vote on that one). But please add a setting (maybe a toolbar button) to disable it when not needed and the mapper wants to keep the scale the same while cycling through textures.