Search the Community

So, if I understand you, no Thief Gold FM does sound and text notifications of completed objectives? The missions in The Black Parade surely did. I'm completely confused now. I was sure that original Thief Gold had those objective complete notifications (at least the sound). Reading this thread suggests otherwise though: https://www.ttlg.com/forums/showthread.php?t=132977

Greetings everyone! I recently got into TDM and am already having a lot of fun playing through and ghosting missions. However, coming from Thief, I am mostly relying on the rules and my experience with that game, while there are clearly differences in how TDM works. Right now, there is talk in the ghosting discussion thread on TTLG to amend the ruleset and include clarifications pertaining to TDM. So I wanted to drop by and ask: is there an active TDM ghosting community already and have any rules for this playstyle been developed? I would also like to ask someone to take a look at the draft of this addendum to see whether everything looks correct: https://www.ttlg.com/forums/showthread.php?t=148487&page=16&p=2473352&viewfull=1#post2473352 Thanks!

A Problem Arises I've paused subtitling of the Lady02 vocal set, because of a problem with the voice clips described here: https://forums.thedarkmod.com/index.php?/topic/21741-subtitles-possibilities-beyond-211/&do=findComment&comment=490151 While a way forward is being determined, I'll work on a different vocal set. Maybe manbeast, for which Kingsal just provided me the voice script.

I'm opening this topic to summarise the technical changes that have been made to DR's renderer and get some feedback from my fellow coders. I'd love to get a peer review on the code changes, but going through that by looking at a pull request of that renderer branch would be a terrible experience, I assume, so instead I'd like to give an overview over what is done differently now. General things to know about DR's renderer DarkRadiant needs to support three different render views or modes: orthographic view, editor preview (fullbright) and lighting preview. Each of them has very different needs, but the lit preview is the most complex one, since it ideally should resemble what the TDM engine is producing. Apart from the obvious things like brush faces and model geometry, it needs to support drawing editor-specific things like path connection lines, light volumes, manipulators (like the rotation widget) or patch vertices. Nodes can be selected, which makes them appear highlighted: they display a red overlay and a white outline in the camera preview, whereas the orthoview shows selected item using a thicker red dashed line to outline selected items. DarkRadiant cannot specialise its renderer on displaying triangles only. Path lines for instance are using GL_LINE_STRIPs, Single brush faces (windings) are using GL_POLYGON for their outline (triangulation of brush faces in the ortho view or the camera (when selected) introduce a lot of visual noise, we just want the outline), patches want to have their control mesh rendered using GL_QUADS. Model surfaces (like .ASE and .LWO models) on the other hand are using GL_TRIANGLES all the way. Almost every object in DarkRadiant is mutable and can change its appearance as authors are manipulating the scene. CPU-intensive optimisations like generating visportal areas is not a likely option for DR, the scene can fundamentally change between operations. The Renderer before the changes DR's rendering used to work like this: all the visible scene nodes (brushes, patches, entities, models, etc.) were collected. They have been visited and were asked to forward any Renderable object they'd like to display to a provided RenderableCollector. The collector class (as part of the frontend render pass) sorted these renderables into their shaders (materials). So at the end of the front end pass, every shader held a list of objects it needed to display. The back end renderer sorted all the material stages by priority and asked each of them to render the objects that have been collected, by calling their OpenGLRenderable::render() method. After all objects rendered their stuff, the shader objects were emptied for the next frame. Culling of invisible objects has been happening by sorting objects into an Octree (which is a good choice for ortho view culling), some culling has been done in the render methods themselves (both frontend and backend calls). The problems at hand Doing the same work over and over again: it's rare that all the objects in the scene change at once. Usually prefabs are moved around, faces are textured, brushes are clipped. When flying through a map using the camera view, or by shifting the ortho view around, the scene objects are unchanged for quite a number of frames. Separation of concerns: every renderable object in the scene has been implementing its own render() method that invoked the corresponding openGL calls. There were legacy-style glBegin/glEnd rendering (used for path nodes), glDrawElements, glCallList, including state changes like enabling arrays, setting up blend modes or colours. These are render calls that should rather be performed by the back end renderer, and should not be the responsibility of, let's say, a BrushNode. Draw Calls: Since every object has been submitting its own geometry, there has been no way to group the calls. A moderately sized map features more than 50k brush faces, and about half as many patch surfaces. Rendering the whole map can easily add up to about 100k draw calls, with each draw call submitting 4 vertices (using GL_POLYGON). Inconsistent Vertex Data: since each object was doing the rendering on its own, it has been free to choose what format to save its data in. Some stored just the vertex' 3D coordinate, some had been adding colour information, some were using full featured vertices including normal and tangents. State Changes: since every object was handled individually, the openGL state could change back and forth in between a few brush windings. The entity can be influencing the shader passes by altering e.g. the texture matrix, so each renderable of the same material triggered a re-evaluation of the material stage, leading to a massive amount of openGL state changes. Then again, a lot of brushes and patches are worldspawn, which never does anything like this, but optimisation was not possible since the backend knew nothing about that. Lighting mode rendering: Lighting mode had a hard time figuring out which object was actually hit by a single light entity. Also, the object-to-entity relationship was tough to handle by the back end. Seeing how idTech4 or the TDM engine is handling things, DR has been doing it reversed. Lighting mode rendering has been part of the "solid render" mode, which caused quite a few if/else branches in the back end render methods. Lighting mode and fullbright mode are fundamentally different, yet they're using the same frontend and backend methods. The Goals openGL calls moved to the backend: no (frontend) scene object should be bothered with how the object is going to be rendered. Everything in terms of openGL is handled by the back end. Reduced amount of draw calls: so many objects are using the same render setup, they're using the same material, are child of the same parent entity, are even in almost the same 3D location. Windings need to be grouped and submitted in a single draw call wherever possible. Same goes for other geometry. Vertex Data stored in a central memory chunk: provide an infrastructure to store all the objects in a single chunk of memory. This will enable us to transition to store all the render data in one or two large VBOs. Support Object Changes: if everything should be stored in a continuous memory block, how do we go about changing, adding and removing vertex data? Changes to geometry (and also material changes like when texturing brushes) is a common use-case and it must happen fast. Support Oriented Model Surfaces: many map objects are influenced by their parent node's orientation, like a torch model surface that is rotated by the "rotation" spawnarg of its parent entity. A map can feature a lot of instances of the same model, the renderer needs to support that use-case. On the other hand, brush windings and patches are never oriented, they are always using world coordinates. Unified vertex data format: everything that is submitted as renderable geometry to the back end must define its vertex data in the same format. The natural choice would be the ArbitraryMeshVertex type that has been around for a while. All in all, get closer to what the TDM engine is doing: by doing all of the above, we put ourselves in the position to port more engine render features over to DR, maybe even add a shadow implementation at some point.

@duzenkoTwo problems, first I did have my folders named darkmod in succession so I renamed to tdm and darkmod respectively. But the asset issue was fixed cause I forgot to run the flippin launcher... LOL So the engine boots up however... @stgatilovThe first time running, it decompressed textures but the game wouldn't start. Launched a second time and I get a fullscreen window, but it hangs on a black screen, last item in terminal is "Async thread started". When I run "thedarkmod.custom.debug" I get an ELF Exec error like it's compiled for wrong architecture, however a 'file' shows it is an aarch64 ARM executable. My terminal output below: EDIT: I noticed below the line "Unknown command '#'", I do know one project I was compiling on required me to modify a C file and change the # hashtags to // double forward slashes as ARM assembly uses // for comments. *Shrug* wooty@wootylx2k-ubn:~/build/tdm/darkmod$ ./thedarkmod.custom TDM 2.10/64 #9574 (1435:9574M) linux-aarch64 Aug 23 2021 01:34:57 failed parsing /proc/cpuinfo measured CPU frequency: 1000.1 MHz 1000 MHz unsupported CPU found interface lo - loopback found interface enx00249b1e62ae - 151.151.88.220/255.255.0.0 found interface virbr0 - 192.168.122.1/255.255.255.0 Found Unsupported CPU, features: TDM using Generic for SIMD processing. Found 0 new missions and 0 packages. ------ Initializing File System ------ Current search path: /home/wooty/build/tdm/darkmod/ /home/wooty/build/tdm/darkmod/tdm_textures_wood01.pk4 (376 files) /home/wooty/build/tdm/darkmod/tdm_textures_window01.pk4 (389 files) /home/wooty/build/tdm/darkmod/tdm_textures_stone_sculpted01.pk4 (463 files) /home/wooty/build/tdm/darkmod/tdm_textures_stone_natural01.pk4 (133 files) /home/wooty/build/tdm/darkmod/tdm_textures_stone_flat01.pk4 (302 files) /home/wooty/build/tdm/darkmod/tdm_textures_stone_cobblestones01.pk4 (224 files) /home/wooty/build/tdm/darkmod/tdm_textures_stone_brick01.pk4 (520 files) /home/wooty/build/tdm/darkmod/tdm_textures_sfx01.pk4 (69 files) /home/wooty/build/tdm/darkmod/tdm_textures_roof01.pk4 (72 files) /home/wooty/build/tdm/darkmod/tdm_textures_plaster01.pk4 (142 files) /home/wooty/build/tdm/darkmod/tdm_textures_paint_paper01.pk4 (63 files) /home/wooty/build/tdm/darkmod/tdm_textures_other01.pk4 (127 files) /home/wooty/build/tdm/darkmod/tdm_textures_nature01.pk4 (286 files) /home/wooty/build/tdm/darkmod/tdm_textures_metal01.pk4 (497 files) /home/wooty/build/tdm/darkmod/tdm_textures_glass01.pk4 (51 files) /home/wooty/build/tdm/darkmod/tdm_textures_fabric01.pk4 (43 files) /home/wooty/build/tdm/darkmod/tdm_textures_door01.pk4 (177 files) /home/wooty/build/tdm/darkmod/tdm_textures_decals01.pk4 (465 files) /home/wooty/build/tdm/darkmod/tdm_textures_carpet01.pk4 (92 files) /home/wooty/build/tdm/darkmod/tdm_textures_base01.pk4 (407 files) /home/wooty/build/tdm/darkmod/tdm_standalone.pk4 (4 files) /home/wooty/build/tdm/darkmod/tdm_sound_vocals_decls01.pk4 (27 files) /home/wooty/build/tdm/darkmod/tdm_sound_vocals07.pk4 (1111 files) /home/wooty/build/tdm/darkmod/tdm_sound_vocals06.pk4 (696 files) /home/wooty/build/tdm/darkmod/tdm_sound_vocals05.pk4 (119 files) /home/wooty/build/tdm/darkmod/tdm_sound_vocals04.pk4 (2869 files) /home/wooty/build/tdm/darkmod/tdm_sound_vocals03.pk4 (743 files) /home/wooty/build/tdm/darkmod/tdm_sound_vocals02.pk4 (1299 files) /home/wooty/build/tdm/darkmod/tdm_sound_vocals01.pk4 (82 files) /home/wooty/build/tdm/darkmod/tdm_sound_sfx02.pk4 (605 files) /home/wooty/build/tdm/darkmod/tdm_sound_sfx01.pk4 (966 files) /home/wooty/build/tdm/darkmod/tdm_sound_ambient_decls01.pk4 (8 files) /home/wooty/build/tdm/darkmod/tdm_sound_ambient03.pk4 (24 files) /home/wooty/build/tdm/darkmod/tdm_sound_ambient02.pk4 (163 files) /home/wooty/build/tdm/darkmod/tdm_sound_ambient01.pk4 (220 files) /home/wooty/build/tdm/darkmod/tdm_prefabs01.pk4 (961 files) /home/wooty/build/tdm/darkmod/tdm_player01.pk4 (125 files) /home/wooty/build/tdm/darkmod/tdm_models_decls01.pk4 (103 files) /home/wooty/build/tdm/darkmod/tdm_models02.pk4 (2053 files) /home/wooty/build/tdm/darkmod/tdm_models01.pk4 (3163 files) /home/wooty/build/tdm/darkmod/tdm_gui_credits01.pk4 (49 files) /home/wooty/build/tdm/darkmod/tdm_gui01.pk4 (721 files) /home/wooty/build/tdm/darkmod/tdm_fonts01.pk4 (696 files) /home/wooty/build/tdm/darkmod/tdm_env01.pk4 (152 files) /home/wooty/build/tdm/darkmod/tdm_defs01.pk4 (187 files) /home/wooty/build/tdm/darkmod/tdm_base01.pk4 (198 files) /home/wooty/build/tdm/darkmod/tdm_ai_steambots01.pk4 (24 files) /home/wooty/build/tdm/darkmod/tdm_ai_monsters_spiders01.pk4 (80 files) /home/wooty/build/tdm/darkmod/tdm_ai_humanoid_undead01.pk4 (55 files) /home/wooty/build/tdm/darkmod/tdm_ai_humanoid_townsfolk01.pk4 (104 files) /home/wooty/build/tdm/darkmod/tdm_ai_humanoid_pagans01.pk4 (10 files) /home/wooty/build/tdm/darkmod/tdm_ai_humanoid_nobles01.pk4 (48 files) /home/wooty/build/tdm/darkmod/tdm_ai_humanoid_mages01.pk4 (8 files) /home/wooty/build/tdm/darkmod/tdm_ai_humanoid_heads01.pk4 (100 files) /home/wooty/build/tdm/darkmod/tdm_ai_humanoid_guards01.pk4 (378 files) /home/wooty/build/tdm/darkmod/tdm_ai_humanoid_females01.pk4 (172 files) /home/wooty/build/tdm/darkmod/tdm_ai_humanoid_builders01.pk4 (91 files) /home/wooty/build/tdm/darkmod/tdm_ai_humanoid_beasts02.pk4 (229 files) /home/wooty/build/tdm/darkmod/tdm_ai_humanoid_beasts01.pk4 (23 files) /home/wooty/build/tdm/darkmod/tdm_ai_base01.pk4 (9 files) /home/wooty/build/tdm/darkmod/tdm_ai_animals01.pk4 (82 files) File System Initialized. -------------------------------------- Couldn't open journal files failed parsing /proc/cpuinfo alternative method used /proc/cpuinfo CPU processors: 16 /proc/cpuinfo CPU logical cores: 16 ----- Initializing Decls ----- ------------------------------ I18N: SetLanguage: 'english'. I18N: Found no character remapping for english. I18N: 1277 strings read from strings/english.lang I18N: 'strings/fm/english.lang' not found. Couldn't exec editor.cfg - file does not exist. execing default.cfg Unknown command '#' Couldn't exec autoexec.cfg - file does not exist. I18N: SetLanguage: 'english'. I18N: Found no character remapping for english. I18N: 1277 strings read from strings/english.lang I18N: 'strings/fm/english.lang' not found. ----- Initializing OpenAL ----- Setup OpenAL device and context [ALSOFT] (EE) Failed to set real-time priority for thread: Operation not permitted (1) OpenAL: found device 'SB Omni Surround 5.1 Analog Stereo' [ACTIVE] OpenAL: found device 'Kensington SD4700P Dual Video Dock Digital Stereo (IEC958)' [ALSOFT] (EE) Failed to set real-time priority for thread: Operation not permitted (1) OpenAL: device 'SB Omni Surround 5.1 Analog Stereo' opened successfully OpenAL: HRTF is available OpenAL vendor: OpenAL Community OpenAL renderer: OpenAL Soft OpenAL version: 1.1 ALSOFT 1.21.1 OpenAL: found EFX extension OpenAL: HRTF is enabled (reason: 1 = ALC_HRTF_ENABLED_SOFT) OpenAL: found 256 hardware voices ----- Initializing OpenGL ----- Initializing OpenGL display Borderless fullscreen - using current video mode for monitor 0: 3440 x 1440 ...initializing QGL ------- Input Initialization ------- ------------------------------------ OpenGL vendor: AMD OpenGL renderer: AMD Radeon (TM) Pro WX 4100 (POLARIS11, DRM 3.40.0, 5.11.0-31-generic, LLVM 12.0.1) OpenGL version: 4.6 (Core Profile) Mesa 21.3.0-devel (git-2b4b310 2021-08-21 hirsute-oibaf-ppa) core Checking required OpenGL features... v - using GL_VERSION_3_3 v - using GL_EXT_texture_compression_s3tc Checking optional OpenGL extensions... v - using GL_EXT_texture_filter_anisotropic maxTextureAnisotropy: 16.000000 v - using GL_ARB_stencil_texturing v - using GL_EXT_depth_bounds_test v - using GL_ARB_buffer_storage v - using GL_ARB_texture_storage v - using GL_ARB_multi_draw_indirect v - using GL_ARB_vertex_attrib_binding v - using GL_ARB_bindless_texture X - GL_ARB_compatibility not found v - using GL_KHR_debug Max active texture units in fragment shader: 32 Max combined texture units: 192 Max anti-aliasing samples: 8 Max geometry output vertices: 256 Max geometry output components: 4095 Max vertex attribs: 16 ---------- R_ReloadGLSLPrograms_f ----------- Linking GLSL program cubeMap ... Linking GLSL program bumpyEnvironment ... Linking GLSL program depthAlpha ... Linking GLSL program fog ... Linking GLSL program oldStage ... Linking GLSL program blend ... Linking GLSL program stencilshadow ... Linking GLSL program shadowMapA ... Linking GLSL program shadowMapN ... Linking GLSL program shadowMapNG ... Linking GLSL program ambientInteraction ... Linking GLSL program interactionStencil ... Linking GLSL program interactionShadowMaps ... Linking GLSL program interactionMultiLight ... Linking GLSL program frob ... Linking GLSL program soft_particle ... Linking GLSL program tonemap ... Linking GLSL program gaussian_blur ... --------------------------------- Font fonts/english/stone in size 12 not found, using size 24 instead. --------- Initializing Game ---------- The Dark Mod 2.10/64, linux-aarch64, code revision 9574 Build date: Aug 23 2021 Initializing event system ...852 event definitions Initializing class hierarchy ...172 classes, 1690368 bytes for event callbacks Initializing scripts ---------- Compile stats ---------- Memory usage: Strings: 45, 7160 bytes Statements: 20303, 812120 bytes Functions: 1278, 166124 bytes Variables: 91948 bytes Mem used: 2019680 bytes Static data: 3989840 bytes Allocated: 5034004 bytes Thread size: 7904 bytes Maximum object size: 884 Largest object type name: weapon_arrow ...6 aas types game initialized. -------------------------------------- Parsing material files Found 0 new missions and 0 packages. Found 3 mods in the FM folder. Parsed 0 mission declarations, no mission database file present. -------- Initializing Session -------- session initialized -------------------------------------- Font fonts/english/mason_glow in size 12 not found, using size 48 instead. Font fonts/english/mason_glow in size 24 not found, using size 48 instead. Font fonts/english/mason in size 12 not found, using size 48 instead. Font fonts/english/mason in size 24 not found, using size 48 instead. --- Common Initialization Complete --- WARNING: terminal type 'xterm-256color' is unknown. terminal support may not work correctly terminal support enabled ( use +set in_tty 0 to disabled ) pid: 4706 Async thread started Killed

So giving it none of those tags, but making the AI invisible, silent, non-solid, and on a team neutral to everyone would not work? Oh well, it was a horrible inelegant idea anyway.

Black Parade is released ! https://www.ttlg.com/forums/showthread.php?t=152429

Body awareness please. https://forums.thedarkmod.com/index.php?/topic/20013-are-you-gonna-add-this/

I loved it. Awesome game. I faceplanted at the people who asked for quest markers in the Steam forums there... Herr, lass Hirn regnen. The game is so great, and so true to the original, because it doesn't hold your hand. When is the new breed of gamers gonna learn.

Horror themed fan mission - exploration of seemingly deserted keep in the middle of swamps. Spiders, undead, darkness. ----------------------------------------------------------------------------------------------------------------------------- This is the story about the fate of my family. My uncle, Ralph Mac Roberts, is the baron of a keep nestled deep within the Rahenaen marshes. It was once an important outpost tasked with guarding one of the few Builder roads that cross the marsh, but after the Inventor`s Guild built a system of nearby dams that flooded the whole land, the road closed and there was no longer anything to watch over anymore. The keep itself needed reinforcement against the raising water level and the trade routes become almost impassable, not only for the carriages but for lone couriers as well. There hadn`t been any messages coming from the keep for over a year and my father was about to assemble a caravan so he could go on an expedition to the keep himself. However, in the middle of the night before he was set to leave, a carrier pigeon landed on his windowsill. My father received the letter and read the apologies from my uncle and his family, excusing their long absence. As a way to make reparations for their extended silence, my uncle invited me to the keep to stay there for a fortnight or so. My uncle had instructed me to leave my horse three leagues away from the keep by the nearest charcoal burning hut and hike the remainder of the road on foot, as the trek through the marsh is treacherous for horses. The weather will be awful this time of year, but my father insists that I should go anyways to ensure that our relatives are okay. These plains become dreadfully deserted - to the point where you more expect to meet the dead than the living. And by the way - I think I`m lost. ----------------------------------------------------------------------------------------------------------------------------- Download link: https://1drv.ms/u/s!Aj1DVS465udZgVkXteBbr6cUxdPH Thanks: to the TDM team for great tools, and all the contributors for their assets, to betatesters: Amadeus, Bienie, Boiler's_hiss, Dragofer, Filizitas, Judith, nbohr1more, s.urfer, again to Amadeus for proofreading and text tweaks, and to all the players for their time! Few screenshots: http://forums.thedarkmod.com/topic/10003-so-what-are-you-working-on-right-now/?p=434716 http://forums.thedarkmod.com/topic/10003-so-what-are-you-working-on-right-now/?p=429558 http://forums.thedarkmod.com/topic/19886-fm-marsh-of-rahena-beta-testing/?p=434507 Enjoy! Walk-through !major spoilers! Finding a way across the marsh area: Getting inside: Bed objective: Light sources: Maps: Enemies: Room objective: Hut objective: Sealed objective: Gold: Key: Bodies:

We have at least 3 users affected by this: @Araneidae: OpenGL vendor: X.Org OpenGL renderer: AMD CAYMAN (DRM 2.50.0 / 5.9.8-100.fc32.x86_64, LLVM 10.0.1) OpenGL version: 4.3 (Core Profile) Mesa 20.2.2 core @zergrush: Can't find anything more specific than: Radeon card. On Linux. @Alberto Salvia Novella: OpenGL vendor: X.Org OpenGL renderer: AMD CYPRESS (DRM 2.50.0 / 5.10.63-1-MANJARO, LLVM 12.0.1) OpenGL version: 4.3 (Core Profile) Mesa 21.2.1 core I wonder if we should already introduce a hack for automatically switching to 32 bits on such platforms. Either by searching for CYPRESS, CAYMAN, and similar codenames of pre-GCN drivers... Or by checking main menu screenshot for corruption Interestingly, screenshot checking sounds more reliable to me.

Not so long ago I found what could make a pretty good profile picture and decided to try it out on these new forums. But I couldn't find a button anywhere that would let me change it. I asked on Discord and it seems Spooks also couldn't find anything anywhere. So I logged into an old alternative account and, lo and behold, that account has a button. This is on the first screen I get when I: 1) click on my account name in the top-right of the browser -> 2) click on 'profile'. Compared to my actual account: Are you also missing this button on your account? It'd be very much appreciated if that functionality could be restored to any of the affected accounts.

The Linux segfault is definitely not merge related, since I can reproduce it in your branch prior to the merge commit. It looks like a problem with OpenGL being called during shutdown (maybe after the context has been destroyed or invalidated?). Here is the stacktrace: The actual line which crashes is: -> 31 glDeleteBuffers(1, &_buffer); which then jumps to address 0x0000, which I think can only mean that the glDeleteBuffers function pointer itself has been set to null. My first thought was that headless OpenGL simply won't work on Linux, but this doesn't really make sense as an explanation because the crash happens in an OpenGL call during shutdown, which must have been preceded by several other calls (which did not crash) during initialisation and running the tests. Also there is a HeadlessOpenGLContextModule which has been used by tests for 18 months without crashing, so it can't be the case that no OpenGL commands work in tests. I'm guessing this must be something related to the order of destruction of some of the new rendering-related objects (as commented within the OpenGLRenderSystem destructor), but I'm not sufficiently up to speed on how the new objects fit together to identify an obvious root cause.

Thanks for the replies, gonna try those spoiler Tags again now for my short review (oh well it inserted one above my text now and I can't seem to delete it on mobile - this text editor is strange)

Just finished this mission and wow I gotta say in great honor to Grayman and of course the rest of the team picking it up, this was something I've never seen before in any other TDM mission, especially visually wise. I am so happy that grayson gave green light for other experienced mappers to finish his last mission. And what came out of this is really something special. I'll put my review in spoiler tags since I'm now referring to critical mission details. Edit - How do I put spoiler text here on mobile?? [spoiler] test [/spoiler][SPOILER] test [/SPOILER] [spoiler[spoiler [sfah

Okay, I had no idea, I have googled it up now and you are right, to my own surprise. Done, I´ve put some paragraphs which were previously not in spoiler tags into spoilers.

Thebigh is right. The pronunciation tripped me up too, but that is apparently how Leicester is pronounced. Also @TarhielI'm glad you are loving the FM but do you mind putting spoiler tags on your post please

That indeed sounds useful, but those Eevee renders do seem to be more advanced than what TDM can do, like those reflections and shadows, seem to be way ahead, is that really simple OpenGL lighting? Seems more like some kind of modern PBR system.

Public release v1.7.6 (with Dark Mod support) is out. Improvements since the final beta 14 are: Fixed a few remaining bugs with zip/pk4 support. Game Versions window now properly displays TDM version. Import window no longer has a vestigial off-screen TDM field (because TDM doesn't need or support importing). Web search option is now disabled if an unknown/unsupported FM is selected. If an FM with an unknown or unsupported game type is selected, the messages in the tab area now no longer refer to Thief 3 ("Mod management is not supported for Thief: Deadly Shadows"). The full changelog can be viewed at the release link. The de facto official AngelLoader thread is here: https://www.ttlg.com/forums/showthread.php?t=149706 Bug reports, feature requests etc. are usually posted there. I'll continue following this thread though. Thanks everyone and enjoy!

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

As reference, here's a few Blender renders showing how light radius works there... for accuracy it's the Eevee engine which uses the same lighting technology as OpenGL (no raytracing). 0, 0.25, 0.5 in order: This shows what it's doing better, though like I said we could use another box like for the standard radius. I believe Eevee simulates the light source at a random position within the sphere for every sample. Obviously this would murder our performance, hence why I'd use a shader to emulate this behavior in 2D on the light texture itself.

We will look at some of this stuff, but SPOILER tags, please!!!

This may make sense in that the performance impact of the volumetric effect can scale with how much of the effect is filling the screen. We shipped with a “performance mode” but had to setup the entities by hand to do it (so it’s not perfect). If you change the LOD detail settings to “Low” or “Lowest” this will disable certain lights, particles and such that can be very heavy to render. You can try these settings and see if you notice an improvement. If not sending us some pictures of heavy areas (with spoiler tags please) will be helpful with tuning these “performance modes” in subsequent patches. Thanks for playing!