Search the Community

A couple more: https://forums.thedarkmod.com/index.php?/topic/21739-resolved-allow-mantling-while-carrying-a-body/ https://forums.thedarkmod.com/index.php?/topic/22211-feature-proposal-new-lean-for-tdm-212/ https://forums.thedarkmod.com/index.php?/topic/22198-feature-proposal-frob-to-use-world-item/ https://forums.thedarkmod.com/index.php?/topic/22249-212-auto-search-bodies/

As everyone know, right now we have both stencil shadows and shadow maps in the engine, and the player is mostly free to choose whichever he likes more. Due to the reasons I provide below, stencil shadows will most likely be dropped in some future, but that future is definitely not here yet. Unlike shadow maps, stencil shadows do not support: Alpha-tested shadow occluders. Shadows on translucent surfaces. Volumetric lights with account for shadows. Soft shadows with contact hardening. Point 4 can be ignored, point 3 has an automatic workaround by forcing lights with volumetrics to shadow maps. Points 1 and 2 result in major difference in behavior between the two modes. For the reference, we have one more technical difference: Front faces cast shadows in shadow maps mode, but don't cast them in stencil shadows mode. I recall how initially volumetric lights had their shadows disabled in stencil shadows mode, and mappers were not happy because that's a big difference in behavior. One issue was that every mission has to be beta-tested in both modes. That's why right now I mostly follow the same strategy: Alpha-testing is disabled when rendering shadow maps (since 2.12), unless you enable r_shadowMapAlphaTested. Shadows are disabled on translucent objects (since today's 2.13 dev build), unless you enable r_shadowMapOnTranslucent. I wonder if this is still what majority of the mappers think is best?

The real St. Alban was a pagan who became a celebrated religious personality, this All Saints Day 2010 The Dark Mod places its own spin on this mythical figure. Screenshots: Intro: "'Business' has been slow lately, even more so after most of my gear got snatched during a Watch raid... I've since been forced to hit the streets and pick pockets for a living. But my luck was about to change, last night I was approached by a red hooded figure with a proposition... As we sat down in a dark corner of a nearby inn, he told to me that the Builders of St. Alban's Cathedral in the Old Quarter had recently unearthed a discovery that might lead to the final resting place of some saint." " But before I do anything, I need to get my tools and stash from the evidence room at the local watch station." "with the hawks, doves will congregate they will drop honey from the cliffs wine will surge over the earth the sheep will wander harmlessly with the wolf then the wicked will rise, but to retribution" - 'scripture of St Alban' There is a new version out now, see the following thread St Albans Cathedral version 1.6 Build Time: about 2-3 months. Thanks:- Huge respect to the Dark Mod team for such a great mod and for all the hard work they put into it and continue to put into it. Special thanks to Fidcal, Serpentine and others for their help on the forums and to Testing:Ugoliant, Baddcog, Grayman, Lost soul, Bjorn and Baal (for doing all the Vp work in the town. Readables: Ungoliant and Mortemdesino for all awesome work on the readables. Resource: Fids, Grayman, Ungoliant - guis, models & images. Misc: Loren Schmidt - the author of the map I based the cathedral on. Info: # Like Thief2, some things are climable, pipes, wall vines etc.. You can also drop some of the keys, some door that are frobbabe mean there is another way inside - explore u taffer! # Due to TDM being a lot more of a resource hog than T2 I have been forced to limit the number of Ai in the mission, but they have better placement than my last mission. # On all difficulty levels the player starts with vertualy no tools/weapons, there are weapons to be found - read, read, read! # For the love of all that is holy, read the briefing otherwise you will problems completing the mission. Known issues:- # This mission will have less than optimal fps at a few points on the map, mid range DX9 card(X1900/GF7800) or higher required. # On low end PCs I recommend, V-sync is off, AA is off, Aniso is 4x or lower and that any and all background apps are closed.

There's a lighting issue in "William Steele 1: In the North" at -1153.92 3523.22 -955.75 29.8 -145.6 0.0 There's a candle on the other side of the wall. In 2.12 dev, that candle's light leaks through the wall at the base of the door as seen in the video, comparing 2.11 and 2.12-r10451.

I think yes. The root of the issue is always an opaque wall (in terms of areas/visportals) which does not cast shadows (in terms of lighting). Shadowcaulk is both opaque and casts shadows, so there is no contradiction.

Author Note: This is a brand new mission and a new entry into the accountant series. There are some different than usual puzzles in this FM, so if you find yourself stuck try to think about your pathway forward in a logical manner. And if you're still having troubles then pop by this thread and ask (preferably with spoiler tags). This FM is brand new and serves as the first installment in The Accountant series, a few years back there was a small prologue style mission released however I felt that it did not represent The Accountant series so I decided to go back to the drawing board and do a whole new mission that's larger, has a better level design and has a story that lines up closer to what I plan to do with the accountant series. The mission is medium sized and you can expect between 30-90 minutes to complete it depending on your playstyle. Beta Testers Captain Cleveland Crowind Kingsal PukeyBee Skacky SquadaFroinx Voice Actors AndrosTheOxen Epifire Goldwell Stevenpfortune Yandros Custom assets Airship Ballet Bentraxx Bob Necro Dragofer DrKubiac Epifire Kingsal MalachiAD Sotha Springheel SquadaFroinx Available via in-game downloader File Size: 233 MB - Updated to v 1.1 (01.06.2018)

I may know why the builders and guards suddenly go all aggro, and it has nothing to do with a window. If you wait long enough, eventually Malachi gets killed by the elevator and they don't think it was because they elevator lacks safety features. I did a playthrough and Malachi was killed by the elevator but I had knocked out all the other roving builders that would have seen him. After I finished, I went in and set up on the table by the elevator that had a candlestick on it. Eventually old Malachi got chewed by the elevator and they all alerted. Sometimes other people get killed on the elevator at that point and sometimes it says I failed the don't kill anybody objective and sometimes it doesn't. Don't know if it'll happen every time. My first attempt either I didn't wait long enough or it may be some triggers need to happen. The second time I still waited quite a while but Malachi eventually died on the elevator again. So if that isn't intentional, that may be what starts the issue.

Welcome to the forums Ansome! And congrats on making it to beta phase!

Ok, here is the source of the goddamn precision issue: static void WriteFloat( idFile *f, float v ) { if ( idMath::Fabs(v - idMath::Round(v)) < 0.001 ) { f->WriteFloatString( "%i ", (int)idMath::Round(v) ); } else { f->WriteFloatString( "%f ", v ); } } I guess I'll never stop finding more weird tolerance stuff in this codebase Anyway, I'll fix this after 2.12: never know the consequences. UPDATE: Here is issue in bugtracker 6480

I looked closer at the problem in Dragon's Claw, and this is caused by some kind of precision issue in dmap. The .proc file contains imprecise BSP plane: /* node 18377 */ ( 0.0399680398 1 0 1202.8780517578 ) -38 18378 And also there is a visportal stored there: /* iap 62 */ 4 37 50 ( -96 -1200 -488 ) ( 304 -1216 -488 ) ( 304 -1216 300 ) ( -96 -1200 300 ) The game loads the visportal polygon and computes portal plane from it, which is: plane (a=-0.0399680398, b=-0.999200940, c=0.00000000, d=-1202.87805) As you see, the plane normals are different by 0.2%. The visportal plane computed from polygon is almost perfectly unit, but the BSP plane is not unit (length slightly greater than unit). This makes the game think it is on the left of visportal in one place, but on the right of visportal in another place. I tried to re-dmap but the data is the same. I'll try to see what is going on. Indeed, making the portal axis-aligned would have most likely fixed the issue.

Another issue I ran into which I remember from playing the mission way back: you can basically softlock yourself here if you jump onto the boulders as they float up. You get stuck in them and can't jump anymore. Edit: if you just stay on one of these boulders for too long, you get stuck too.

To cater to both audiences. I mentioned LibreGameWiki as one example. nbohr1more mentioned other uses. Explicitly allowing reuse and spread will help TDM reach a wider audience and would hopefully attract more volunteers. More volunteers which can help improve both TDM versions. There are several benefits for a project of being in the Debian repo. One is that TDM Debian-users can report defects on any package directly to Debian (no need to register on separate forums). Debian may then fix the issue themselves (in their "TDM-libre" package) and will offer the patch upstream to TDM, who can then choose to accept or reject the patch. I envision "TDM-libre" to have the same capability of downloading any mission as regular TDM. The only difference is that "TDM-libre" would come packaged with the regular engine (which is GPL+BSD) and an included mission that has libre media/gamedata. When I play TDM by myself, I want the unlimited-play and can accept commercial restrictions. But if I were to promote it somewhere, or charge for a stream when playing online, or make a video, I would want a version without commercial restrictions (and can temporarily accept limited-play) to make sure I don't violate anyone's copyright. Perhaps. That's what I'm trying to find out.

Yeah it would be cool to see some more detailed statistics and it’s a shame they aren’t really captured. Since we are talking about fan mission platforms, where players also make the content for the game, I feel like the best thing we’ve got is you can look at the number of content releases for the games. Keep in mind the graph counts campaigns as single missions - so for example NHAT and TBP both count as 1 mission. A good year for TDM has has approaching maybe 50% - mostly we’re 25-30%. https://www.ttlg.com/forums/showthread.php?t=152494 You could also look at the number of ratings thief missions get on https://www.thiefguild.com/ vs TDM ones, but that is pretty iffy in that you could chalk that up to more awareness of the site in the thief community than TDM Out of curiosity is there a reason a thief player can’t be a new player? I kind of think a player is a player and new players would be ones who are playing the dark mod who weren't? Is there disagreement the base of players most likely to pick up the game are fans of the thief games? They are certainly the most fruitful place to find feedback on the game beyond the sphere of this forum that I have seen. When we were trying to finish up SLL there was a lot of discussion on the forums about how long it had been since there was a release for the game. I am thankful that the stats show at least some stability over the years in terms of releases for TDM, but the trend for all of the games is decline. Not doing anything is a valid response if that’s what the devs want to do - it is not possible to provide evidence that any effort will slow that inertia. As a player and content maker I would just prefer trying to find feedback where it is offered from players who were willing to try the game but ultimately could not engage with it and see if there is anything that can be done within reason to ease them into the game. The game has a lot to offer imo. All those players are potential contributors - contributions in turn attract players - it’d be nice to see the cycle go on as long as it can.

The readable editor in my DarkRadiant seems to be broken on my installation. When I bring it up I get this ("Shader Not Found"): When I select the GUI Definition browser, I get a bunch of errors in the DarkRadiant log: 2022-09-26 12:22:04 (57608) Unknown token encountered in GUI: rect-100 2022-09-26 12:22:04 (57608) Unknown token encountered in GUI: , 2022-09-26 12:22:04 (57608) Unknown token encountered in GUI: -10 2022-09-26 12:22:04 (57608) Unknown token encountered in GUI: , 2022-09-26 12:22:04 (57608) Unknown token encountered in GUI: 500 2022-09-26 12:22:04 (57608) Unknown token encountered in GUI: , 2022-09-26 12:22:04 (57608) Unknown token encountered in GUI: 400 2022-09-26 12:22:04 (57608) Unknown token encountered in GUI: rect-100 2022-09-26 12:22:04 (57608) Unknown token encountered in GUI: , 2022-09-26 12:22:04 (57608) Unknown token encountered in GUI: -10 2022-09-26 12:22:04 (57608) Unknown token encountered in GUI: , 2022-09-26 12:22:04 (57608) Unknown token encountered in GUI: 500 2022-09-26 12:22:04 (57608) Unknown token encountered in GUI: , 2022-09-26 12:22:04 (57608) Unknown token encountered in GUI: 400 2022-09-26 12:22:04 (57608) Unknown token encountered in GUI: rect-100 ... I searched for "rect-100" and found several in *.gui files. For example, book_bamberg_gothic_both_curl.gui has: windowDef rightPageBackground { WORLD_SCALE rect-100, -10, 500, 400 background "guis/assets/readables/books/book_rightpage_curled_01" matcolor 1, 1, 1, 0 } Note, no space after "rect" and before the "-100" I haven't been editing readables for a while, so I don't know when this started happening. I uninstalled and reinstalled DR 3.3.0; still have the problem. I ran tdm_installer to ensure my DM install was up to date (2.10). It must be something local to my configuration, because if this was happening to everyone we'd have heard about it by now. Does anyone have any ideas what is going on here?

Losing the option for stencil shadows would be extremely sad. TDM has the best stencil shadows implementation I've ever seen, and they look far better than shadow maps. They also perform wonderfully. Stencil shadows not supporting shadows on translucent surfaces is a bummer, but that's a fine tradeoff. Personally, I'd rather not see alpha-tested shadow occluders, because they look awful and are distracting. Shadow maps in general look bad and pixelated -- quite immersion breaking. Another issue with shadow maps is that they substantially increase the usage of the GPU. For those using laptops or integrated GPUs, it could cause performance or heat issues. For those with decent dedicated GPUs, increased wattage (and therefore heat) can and does turn on its GPU fans. The wattage on my AMD RX 6700 XT can become tripled when using shadow maps. That's undesirable. The advice I give players is: There really isn't a "best" shadows implementation these days. Some devs and players prefer one over the other. Regardless of which is chosen, stencil shadows and maps are used where needed. So, I'd try out both and pick the one you prefer. Here's Fen complaining about shadow maps. Complaint #1 (7:28): Complaint #2 (23:46): In his next video (Written in Stone - 4 - Chocolate Coated Brendel Bar), he turned on stencil shadows, and as far as I know, he never complained again. The following area in Written in Stone shows a good example of alpha-tested shadow occluders. Yes, technically the moving leaves cast shadows, but it looks awful in game, in my opinion. I know others like it. The same scene using stencil shadows looks amazing in game. (The screenshots don't do a good job demonstrating how it looks in game.) The current hybrid system is fantastic. It gives people choice. Those who prefer stencil shadows can use them; those who prefer shadow maps can use them. People become attached to the "art" and "style" of a mission, and changing the shadow implementation changes the art and style. If one must be dropped, I'd say shadow maps should be dropped from the menu settings. Use shadow maps for volumetric lights and stencil shadows everywhere else. And, I agree with nbohr1more that defaulting to rules consistent with stencil shadows is a good idea.

Yes, I would like to find out what the issue is even if the ultimate decision is to use a different library in future. So far I have established that this line in Game.cpp is apparently working (no exception is thrown): // Import the game file into the registry GlobalRegistry().import(fullPath, "", Registry::treeStandard); but this (and any subsequent attempt to getKeyValue) then fails: // Get the engine path _enginePath = getKeyValue(enginePath); I can only think of two hypotheses: It's a timing issue or race condition: the import call is returning but something in libxml2 has not "finalised" the tree so it isn't ready to do XPath queries yet. I don't think there is any asynchronous or threaded code in the libxml2 API but who knows. There's something different about how XPath queries need to be formatted after merging. E.g. perhaps "//game" no longer works, and it has to have some other prefix. Further debugging is therefore needed. Edit: OK, there's definitely something weird going on with encodings. Adding a Registry::dump call into the Game constructor gives me output like this: output error : string is not in UTF-8 output error : string is not in UTF-8 eCrosshairs" ="mU" ���mU="SHIFT"/>< ="ToggleGrid" ="(&#xB3;R"/>< ="ToggleView" ="U" ���mU="SHIFT+CONTROL"/>< ="NextView" ="" ���mU="CONTROL"/>< ="ZoomIn" ="Delete"/>< ="ZoomOut" ="Insert"/>< ="CenterXYViews" ="" ���mU="CONTROL+SHIFT"/>< ="CenterXYView" ="" ���mU="CONTROL+ALT"/>< ="ToggleCubicClip" ="" ���mU="SHIFT"/>< ="ToggleCamera" ="U" ���mU="SHIFT+CONTROL"/>< ="TogTexLock" ="" ���mU="SHIFT"/>< ="DragVertices" ="U"/>< ="DragEdges" =""/>< ="DragFaces" =""/>< ="ToggleSelectionFocus" ="" ���mU="CONTROL"/>< ="ThickenPatchDialog" ="" ���mU="CONTROL"/>< ="ToggleShowAllLightRadii" ="" ���mU="CONTROL+SHIFT+ALT"/>< ="ToggleClipper" ="mU"/>< ="MouseTranslate" =""/>< ="MouseRotate" =""/>< ="MouseDrag" =""/>< ="NewOrthoView" ="" ���mU="CONTROL+ALT"/>< ="SetGrid0.125" ="" ���mU=""/>< ="SetGrid0.25" ="" ���mU=""/>< ="SetGrid0.5" ="" ���mU=""/>< ="SetGrid1" ="" ���mU=""/>< ="SetGrid2" ="U" ���mU=""/>< ="SetGrid4" ="" ���mU=""/>< ="SetGrid8" ="" ���mU=""/>< ="SetGrid16" ="" ���mU=""/>< ="SetGrid32" ="" ���mU=""/>< ="SetGrid64" ="" ���mU=""/>< ="SetGrid128" ="" ���mU=""/>< ="SetGrid256" ="" ���mU=""/>< ="ToggleTextureTool" ="" ���mU="CONTROL+ALT"/>< ="ToggleMainControl_TextureTool" ="" ���mU="CONTROL+ALT+SHIFT"/>< ="NormaliseTexture" ="" ���mU=""/>< ="TexToolGridUp" ="plus" ���mU="SHIFT"/>< ="TexToolGridDown" ="minus" ���mU="SHIFT"/>< ="TexToolMergeItems" ="" ���mU="Y&#x11D;mU"/>< ="GroupCycleBackward" ="ISO_Left_Tab" ���mU="SHIFT"/>< ="GroupCycleForward" ="" ���mU=""/>< ="RevertToWorldspawn" ="" ���mU="SHIFT"/>< ="SavePosition1" ="" ���mU="CONTROL+ALT"/>< ="SavePosition10" ="(&#xB3;R" ���mU="CONTROL+ALT"/>< ="SavePosition2" ="U" ���mU="CONTROL+ALT"/>< ="SavePosition3" ="" ���mU="CONTROL+ALT"/>< ="SavePosition4" ="" ���mU="CONTROL+ALT"/>< ="SavePosition5" ="" ���mU="CONTROL+ALT"/>< ="SavePosition6" ="" ���mU="CONTROL+ALT"/>< ="SavePosition7" ="" ���mU="CONTROL+ALT"/>< ="SavePosition8" ="" ���mU="CONTROL+ALT"/>< ="SavePosition9" ="" ���mU="CONTROL+ALT"/>< ="LoadPosition1" ="" ���mU="Y&#x11D;mU"/>< ="LoadPosition10" ="(&#xB3;R" ���mU="Y&#x11D;mU"/>< ="LoadPosition2" ="U" ���mU="Y&#x11D;mU"/>< ="LoadPosition3" ="" ���mU="Y&#x11D;mU"/>< ="LoadPosition4" ="" ���mU="Y&#x11D;mU"/>< ="LoadPosition5" ="" ���mU="Y&#x11D;mU"/>< ="LoadPosition6" ="" ���mU="Y&#x11D;mU"/>< ="LoadPosition7" ="" ���mU="Y&#x11D;mU"/>< ="LoadPosition8" ="" ���mU="Y&#x11D;mU"/>< ="LoadPosition9" ="" ���mU="Y&#x11D;mU"/>< ="ToggleOrthoBackgroundPanel" ="U" ���mU="Y&#x11D;mU"/>< ="ToggleRotationPivot" ="" ���mU="CONTROL"/>< ="ToggleAasVisualisationPanel" ="" ���mU="CONTROL+SHIFT"/>< ="GroupSelected" ="" ���mU="CONTROL+SHIFT"/>< ="UngroupSelected" ="" ���mU="CONTROL+SHIFT"/></mU><> Whereas with xmlParseFile there are no weird characters and the output just looks like properly formatted XML. I wonder if we have some nonstandard characters in our XML files for some reason.

I spend 90% of my time on Linux Mint. I occasionally pop over to Windows 10 to check a few things or run some updates but Linux Mint is my home. TDM runs better under Mint than Windows for me but your mileage may vary. When running TDM in Linux, you must set FPS to "Uncapped Mode" in the Advanced settings, the old capped mode has terrible stuttering and performance under Linux ( even native Doom 3 has this issue ). You can set Max FPS to 60 if you are worried about any inconsistencies with game timing ( the only known issues are rare problems with audio behavior at really high FPS). Just don't use the native 60FPS capped mode, use Uncapped mode with a Max FPS value.

Changelog of 2.13 development: dev17042-10732 * Restored ability to create cvars dynamically, fixing bow in missions (5600). * Fixed issue where .cfg files were saved every frame (5600). * Added sys.getcvarf script event for getting float value of cvar (6530). * Extracted most of constants from weapon scripts into cvars (6530). dev17035-10724 * Support passing information between game and briefing/debriefing GUI via persistent info. Also changed start map & location selection, added on_mission_complete script callback (6509 thread). * New bumpmapped environment mapping is now default (6354). * New behavior of zero sound spawnarg is not default (6346). * Added sound for "charge post" model (6527). * Major refactoring of cvars system to simplify future changes (5600). Known issues: * Bow does not shoot in some missions (only in this dev build): thread dev17026-10712 * Nested subviews (mirrors, remotes, sky, etc.) now work properly (6434). * Added GUI debriefing state on mission success (6509 thread). * Sound argument override with zero now works properly under cvar (6346 thread). * Environment mapping is same on bumpy and non-bumpy surfaces under cvar (6354 thread). * Default console font size reduced to 5, added lower bound depending on resolution. * Added high-quality versions of panel_carved_rectangles (6515). * Added proper normal map for stainglass_saint_03 (6521). * Fixed DestroyDelay warning when closing objectives. * Fixed the only remaining non-threadsafe cvar (5600). * Minor optimization of depth shader. * Added cm_allocator debug cvar (6505). * Fixed r_lockView when compass is enabled. dev17008-10685 * Enabled shadow features specific to maps implementation (poll). * Auto-detect number of parallel threads to use in jobs system (6503). * Improved parallel images loading, parallelized sounds loading, optimized EAS (6503). * Major improvements in mission loading progress bar (6503). * Core missions are now stored uncompressed in assets SVN (6498). * Deleted a lot of old rendering code under useNewRenderPasses + some cleanup (6271). dev16996-10665 * Environment mapping supports texcoord transforms on bumpmap (6500). * Fully disabled shadows on translucent objects (6490). * Fixed dmap making almost axis-aligned visportals buggy (6480). * com_maxFps no longer quantizes by milliseconds on Windows 8+. * Now Uncapped FPS and Vsync are ON by default. * Supported Vsync control on Linux. * Added set of prototype materials (thread). * Fixes to Stone font to remove stray pixels (post). * Loot candlestick no longer toggle the candle when taken. * Optimized volumetric lights and shadows in the new Training Mission (4352). * Fixed frob_light_holder_toggle_light on entities with both skin_lit and skin_unlit. * Now combination lock supports non-door entities by activating them. * Added low-poly version of hedge model (6481). * Added tiling version of distant_cityscape_01 texture (6487). * Added missing editor image for geometric02_red_end_HD (6492). * Added building_facades/city_district decal material. * Fixed rendering with "r_useScissor 0" (6349). * Added r_lockView debug rendering cvar (thread). * Fixed regression in polygon trace model (5887). * Added a set of lampion light entityDefs.

Some changes were made to the training mission, but this process began while 2.12 was already in beta testing, and it became too extensive. To my knowledge this mainly consisted of adjustments to the messages in order to match the new 2.12 control scheme, addition of a vine arrow training area, some minor gameplay changes as well as major visual changes. A last minute major issue caused the mission to be reverted to its 2.11 state except for the adjustments to the popup messages. The training mission is slated to undergo proper beta testing of its own later on.

I took a quick look at the training mission and I didn't notice many changes in the first place. Some new windows on walls that didn't have them, but was something gameplay related changed? I found there are still a lot of unique items missing in the object handling section which I added in my patch for example. The main issue I have with the TDM training mission hasn't been tackled, namely that it isn't a mission at all, just a loose collection of tutorial areas. Which is fine when you want come back and re-train something, but bad if you want new players to have fun discovering TDM! Yes, the two campaign missions try to do the latter, but in other games the training/tutorial is done much better in a linear fashion (e.g. Half-Life and Opposing Force) or is even integrated in a story (Bloodlines and many others). It would probably be a lot of work, but maybe it would be possible to modify the training mission, so it represents a linear sequence in which you learn one basic principle after another while actually playing a mission that is has a story and is fun! If you really think people are going to replay it, maybe shortcuts could be added to the single areas. Right now all areas start from a central room, maybe they could be connected so that there is one way where you enter a door and go around the whole room to exit at the end? (If people agree, that the training mission should be changed, maybe we should open a new thread for this discussion.)

Fun mission, took me around an hour to do. Multiple points of entry was really nice! Only issue I had was But otherwise, great first mission!

New script for mappers: my flavour of a fog density fading script. To add this to your FM, add the line "thread FogIntensityLoop();" to your map's void main() function (see the example in fogfade.script) and set "fog_fade" "1" on each foglight to enable script control of it. Set "fog_intensity_multiplier" on each info_location entity to change how thick the fog is in that location (practically speaking it's a multiplier for visibility distance). Lastly, "fog_fade_speed" on each foglight determines how quickly it will change its density. The speed scales with the current value of shaderParm3, using shaderParm3 = 1000 as a baseline. So i.e. if shaderParm is currently at 1/10th of 1000, then fade speed will be 1/10th as fast. Differences to Obsttorte's script: https://forums.thedarkmod.com/index.php?/topic/14394-apples-and-peaches-obsttortes-mapping-and-scripting-thread/&do=findComment&comment=310436 my script uses fog lights you created, rather than creating one for you. Obsttorte's script will delete the foglight if entering a fogfree zone and recreate it later more than one fog light can be controlled (however, no per-fog-light level of control) adding this to the map requires adding a line to your void main() script, rather than adding an info_locations_settings entity with a custom scriptobject spawnarg in my script, mappers set a multiplier of fog visibility distance (shaderParm3), while in Obsttorte's script a "fog_density" spawnarg is used as an alternative to shaderParm3 smaller and less compactly written script fogfade.scriptfogfade.map

The devs didn't title this thread, and @datiswous said they're attempting to mislead people by using Russell's name and a retro style to make it resemble Thief, which is cynical. I grew up on forums like I'm sure anyone who likes a game from '98 did. I actually left the Discord immediately after joining it because it was more off-topic doom-posting than anything relevant to the mod. I thought the forums might be better, but it's mostly just grown men yelling at clouds and telling strangers how mature they are, and a few brave souls actually developing anything. Depressing place, I'll just stick to enjoying new missions every 6 months without an account.

True, but, 1. this thread is called "Western stealth FPS with Stephen Russell", and, 2. nothing you said changes anything for me. The gameplay still doesn't look like something I'd enjoy. And, if you really think this forum is cynical, then you don't visit forums much. Actually, the majority of the users are are pretty mature, unlike in other forums.