Search the Community

Hi folks, and thanks so much to the devs & mappers for such a great game. After playing a bunch over Christmas week after many years gap, I got curious about how it all went together, and decided to learn by picking a challenge - specifically, when I looked at scripting, I wondered how hard it would be to add library calls, for functionality that would never be in core, in a not-completely-hacky-way. Attached is an example of a few rough scripts - one which runs a pluggable webserver, one which logs anything you pick up to a webpage, one which does text-to-speech and has a Phi2 LLM chatbot ("Borland, the angry archery instructor"). The last is gimmicky, and takes 20-90s to generate responses on my i7 CPU while TDM runs, but if you really wanted something like this, you could host it and just do API calls from the process. The Piper text-to-speech is much more potentially useful IMO. Thanks to snatcher whose Forward Lantern and Smart Objects mods helped me pull example scripts together. I had a few other ideas in mind, like custom AI path-finding algorithms that could not be fitted into scripts, math/data algorithms, statistical models, or video generation/processing, etc. but really interested if anyone has ideas for use-cases. TL;DR: the upshot was a proof-of-concept, where PK4s can load new DLLs at runtime, scripts can call them within and across PK4 using "header files", and TDM scripting was patched with some syntax to support discovery and making matching calls, with proper script-compile-time checking. Why? Mostly curiosity, but also because I wanted to see what would happen if scripts could use text-to-speech and dynamically-defined sound shaders. I also could see that simply hard-coding it into a fork would not be very constructive or enlightening, so tried to pick a paradigm that fits (mostly) with what is there. In short, I added a Library idClass (that definitely needs work) that will instantiate a child Library for each PK4-defined external lib, each holding an eventCallbacks function table of callbacks defined in the .so file. This almost follows the idClass::ProcessEventArgsPtr flow normally. As such, the so/DLL extensions mostly behave as sys event calls in scripting. Critically, while I have tried to limit function reference jumps and var copies to almost the same count as the comparable sys event calls, this is not intended for performance critical code - more things like text-to-speech that use third-party libraries and are slow enough to need their own (OS) thread. Why Rust? While I have coded for many years, I am not a gamedev or modder, so I am learning as I go on the subject in general - my assumption was that this is not already a supported approach due to stability and security. It seems clear that you could mod TDM in C++ by loading a DLL alongside and reaching into the vtable, and pulling strings, or do something like https://github.com/dhewm/dhewm3-sdk/ . However, while you can certainly kill a game with a script, it seems harder to compile something that will do bad things with pointers or accidentally shove a gigabyte of data into a string, corrupt disks, run bitcoin miners, etc. and if you want to do this in a modular way to load a bunch of such mods then that doesn't seem so great. So, I thought "what provides a lot of flexibility, but some protection against subtle memory bugs", and decided that a very basic Rust SDK would make it easy to define a library extension as something like: #[therustymod_lib(daemon=true)] mod mod_web_browser { use crate::http::launch; async fn __run() { print!("Launching rocket...\n"); launch().await } fn init_mod_web_browser() -> bool { log::add_to_log("init".to_string(), MODULE_NAME.to_string()).is_ok() } fn register_module(name: *const c_char, author: *const c_char, tags: *const c_char, link: *const c_char, description: *const c_char) -> c_int { ... and then Rust macros can handle mapping return types to ReturnFloat(...) calls, etc. at compile-time rather than having to add layers of function call indirection. Ironically, I did not take it as far as building in the unsafe wrapping/unwrapping of C/C++ types via the macro, so the addon-writer person then has to do write unsafe calls to take *const c_char to string and v.v.. However, once that's done, the events can then call out to methods on a singleton and do actual work in safe Rust. While these functions correspond to dynamically-generated TDM events, I do not let the idClass get explicitly leaked to Rust to avoid overexposing the C++ side, so they are class methods in the vtable only to fool the compiler and not break Callback.cpp. For the examples in Rust, I was moving fast to do a PoC, so they are not idiomatic Rust and there is little error handling, but like a script, when it fails, it fails explicitly, rather than (normally) in subtle user-defined C++ buffer overflow ways. Having an always-running async executor (tokio) lets actual computation get shipped off fast to a real system thread, and the TDM event calls return immediately, with the caller able to poll for results by calling a second Rust TDM event from an idThread. As an example of a (synchronous) Rust call in a script: extern mod_web_browser { void init_mod_web_browser(); boolean do_log_to_web_browser(int module_num, string log_line); int register_module(string name, string author, string tags, string link, string description); void register_page(int module_num, bytes page); void update_status(int module_num, string status_data); } void mod_grab_log_init() { boolean grabbed_check = false; entity grabbed_entity = $null_entity; float web_module_id = mod_web_browser::register_module( "mod_grab_log", "philtweir based on snatcher's work", "Event,Grab", "https://github.com/philtweir/therustymod/", "Logs to web every time the player grabs something." ); On the verifiability point, both as there are transpiled TDM headers and to mandate source code checkability, the SDK is AGPL. What state is it in? The code goes from early-stage but kinda (hopefully) logical - e.g. what's in my TDM fork - through to basic, what's in the SDK - through to rough - what's in the first couple examples - through to hacky - what's in the fun stretch-goal example, with an AI chatbot talking on a dynamically-loaded sound shader. (see below) The important bit is the first, the TDM approach, but I did not see much point in refining it too far without feedback or a proper demonstration of what this could enable. Note that the TDM approach does not assume Rust, I wanted that as a baseline neutral thing - it passes out a short set of allowed callbacks according to a .h file, so language than can produce dynamically-linkable objects should be able to hook in. What functionality would be essential but is missing? support for anything other than Linux x86 (but I use TDM's dlsym wrappers so should not be a huge issue, if the type sizes, etc. match up) ability to conditionally call an external library function (the dependencies can be loaded out of order and used from any script, but now every referenced callback needs to be in place with matching signatures by the time the main load sequence finishes or it will complain) packaging a .so+DLL into the PK4, with verification of source and checksum tidying up the Rust SDK to be less brittle and (optionally) transparently manage pre-Rustified input/output types some way of semantic-versioning the headers and (easily) maintaining backwards compatibility in the external libraries right now, a dedicated .script file has to be written to define the interface for each .so/DLL - this could be dynamic via an autogenerated SDK callback to avoid mistakes maintaining any non-disposable state in the library seems like an inherently bad idea, but perhaps Rust-side Save/Restore hooks any way to pass entities from a script, although I'm skeptical that this is desirable at all One of the most obvious architectural issues is that I added a bytes type (for uncopied char* pointers) in the scripting to be useful - not for the script to interact with directly but so, for instance, a lib can pass back a Decl definition (for example) that can be held in a variable until the script calls a subsequent (sys) event call to parse it straight from memory. That breaks a bunch of assumptions about event arguments, I think, and likely save/restore. Keen for suggestions - making indexed entries in a global event arg pointer lookup table, say, that the script can safely pass about? Adding CreateNewDeclFromMemory to the exposed ABI instead? While I know that there is no network play at the moment, I also saw somebody had experimented and did not want to make that harder, so also conscious that would need thought about. One maybe interesting idea for a two-player stealth mode could be a player-capturable companion to take across the map, like a capture-the-AI-flag, and pluggable libs might help with adding statistical models for logic and behaviour more easily than scripts, so I can see ways dynamic libraries and multiplayer would be complementary if the technical friction could be resolved. Why am I telling anybody? I know this would not remotely be mergeable, and everyone has bigger priorities, but I did wonder if the general direction was sensible. Then I thought, "hey, maybe I can get feedback from the core team if this concept is even desirable and, if so, see how long that journey would be". And here I am. [EDITED: for some reason I said "speech-to-text" instead of "text-to-speech" everywhere the first time, although tbh I thought both would be interesting]

Story: "Sir Barrington, as he likes to be known, enjoys a prestigious reputation of having lavish yet intimate dinner parties. I've heard the tales about what goes on in the noble's dining room, but I believed none of them 'till now. Orbach, a local shop-keep who makes special deliveries to the people of 'high stature' heard Sir Henry Hughbellow raving about Sir Barrington's special 'Elixir', It cures your ails and gives you vigor... By the Hammer, it extends your very life! he exclaimed. Orbach begged Sir Henry for a small sample, and after one sip he was sure that the potion was nothing more than mineral water and spirit. He asked Sir Henry if other folks were as fond of the elixir as he was, and he found out that folks are paying handsomely for these small vials on a weekly basis. Some lords pay for exclusive treatments and bathe in the tonic. Lord Barrington even brings in an occult expert every month, where supposedly the power of the elixir is renewed by the full moon. Never one to pass up the opportunity for a good scam, Orbach has decided to take a cut of this 'elixir' business. He has made an elixir of his own, but needs to convince Sir Henry that it's really the same as the 'magical' tonic that Lord Barrington has been selling. And that's where I come in. Its rumered that Sir Barrington's prized possession is a painting of the revolutionary inventor 'Guillermo de Sohase' the day after he won the Battle of Billinsdune. If I can steal this painting, Orbach can use it to 'prove' that he also got the elixir from Sir Barrington. Once Sir Henry tells all his friends that Orbach's stolen elixir is healing his heart, soothing his pains, and igniting his libido, they'll be lining up at his shop. Its time to go." Build Time: Version 1.0 was speed build of sorts, to build upon Springheels video's with the new modules. Took roughly 20hrs to build but this ended up happening over the space of a few months.http://forums.thedarkmod.com/topic/18808-bikerdudes-speedish-build-using-the-new-modules/?hl=%2Bspeed+%2BbuildThanks: Co-auther: Obstortte for all his custom entities, scripting and showing me a thing or two about perfing.Resource: Springheel - new modulesReadables: nbhor1moreTesters: Bienie, Judith, Abusimplea, Cambridge Spy, Gerberox, MayheM, Amadeus, Goldwell, nbhor1more.Download: - mega Info: Repeat after me, "Read and explore, Read and explore"Known issues: This mission has been heavily tweaked and worked on to provide a playable experience for even low end machines.For very low end PC's please make use of the in-game LOD slider, as not only are details reduced, but the ambient_world fog is removed at the lowest setting.The medium difficulty is partially broken, the mission wont end when the player gets to the exit location. As this is the only issue with that difficulty level, I will fix this when I next update it to include the intro.

Prefabs don't exist in the original Doom 3 or D3Edit as far as I know. But I don't understand what is the issue being reported. As far as I can see, creating a light entity and setting a "model" key works as expected, with the model becoming visible in the 2D and 3D views in addition to the light bounding box. I'm not sure what else is meant by "having a specified model for the lights". Perhaps vanilla D3 does this in some other way than by setting a "model" key.

https://www.youtube.com/watch?v=uG3E9BDdoak Look at the amount of fog. It's not light and shadows, interesting contrasts, etc.. It's mostly just grey, not even dark. I guess this way they don't need fancy details.

I saw an announcement for this and I thought it was some little fan project, but this is a legit new game. The aesthetic was respectable but a bit too "clean". How is it that modern graphics can never quite capture the dingy authentic look of the days when light was baked in? I don't have experience with VR, but in principle the hands gameplay is an interesting innovation. Well, I'll give it the same hope I've given every Thief game since TDS.

Hidden Hands: Vitalic Fever Filename : hhvf.pk4 Date of release: 20/07/2019 Latest Version: 5 (21/04/2025) Version 5 - changes: - fixed defective ambient light - added subtitles (thanks to @datiswous) - added compressed briefing video (thanks to @datiswous - fixed/replace (defective) textures - added a few new models and items - added new title & loading screen - ...made a few tasks a little easier - dmap with 2.13 Hidden Hands Series: I. Initation - II. Vitalic Fever Jack Farmer: mapping & drafts Amadeus: alpha testing, geometry fixes, performance checks, drafts for gameplay and objectives, revision of all readables, dialogues & narrator texts Grayman: AI fixes, gameplay fixes, trap fixes Duzenko: alpha testing, performance checks and improvement tips Beta Testers: - Joebarnin - Cambridge Spy - Boiler's Hiss (aka "The architect's darling") - Jedi_Wannabe (aka "The man of many voices") - Amadeus (aka "The Writer") Voice actors: Malasdair Narrator Jedi_Wannabe All four guards chatting about the guests, chickens, inventions and unusual job interviews New Horizon The educated Builder Goldchocobo The naive Builder Special thanks to: - Springheel, Sotha, and Fidcal for the tutorials. - VanishedOne, Stumpy, Destined, Grayman, Joebarnin and ERH+ for patiently answering my questions solving all the in-game problems. - PsymH (aka "Stringer Bell") for connecting me with the right guys on TTLG for additional voice acting. - Goldwell for teaching me how to integrate a custom video in a fms and helping me with troubleshooting during the integration of one of the Builder's voices. - all voice actors & beta testers for their great support. - all others not mentioned here who answered my questions in the Newbie thread or via PM. Contributors from the Inventor's Guild: - Destined wrote a new definition for the "spidsey-babsies", enabling those beasts to move through tunnels. - Grayman wrote a script enabling Halfrid to hold the quill only when it is needed. He also fixed several other AI problems with respect to path finding, damages and interaction with light switches. Pilfered items: - Portal sky with hills and trees originally developed and arranged by Sotha for "Thomas Porter: The Transaction". - Frobbox booster re-created from a map originally developed by Grayman All new ambient music and sound effects written, performed and mixed by Jack Farmer. Briefing video by SirSmokeAlot Pictures Version 5 - changes: - fixed defective ambient light - added subtitles (thanks to @datiswous) - added compressed briefing video (thanks to @datiswous - fixed/replace (defective) textures - added a few new models and items - added new title & loading screen - ...made a few tasks a little easier - dmap with 2.13

I decided to share my in-depth thoughts on this. On one side I don't want to be discouraging or throw lessons like I know better... on the other side I want to encourage other creators to make awesome content. I think you have the basics in order, but would advice practicing more for the next FM. I'll address everything of importance that I noticed... some of these are important for creating a working FM, others are based on my experience and how I do things. Visual: Most areas appear pretty simple and rough, the rooms look too much like cubes textured with flat materials that lack detail. While not everything needs to look AAA all the time, I'd encourage adding more detail to the world and using fitting textures with more complexity where appropriate. I'd also check out the building modules. Skybox: A big problem is you can see and touch the skybox. Being able to see the world edge and walk into an invisible wall isn't recommended. You usually want some kind of wall or structure between the player and any portal_sky surface. Portals: You aren't using visportals. This is a small mission with few entities so performance happens to be good, but every FM requires portals. You add them by filling spaces in and between walls with a brush that has a nodraw texture on all sides and a visportal texture on one face, every interactive door and window should have one, the brush must perfectly fit in those spaces without leaving gaps or you'll get a dmap error. You can press N in-game to see them, I'd use that to look at how other missions portal their maps. Just think of them as virtual windows that only show entities and other portals that can be seen through them, your goal is to design the architecture in such a way that they cover each other as much as possible from any position and angle. Clips: Since you likely haven't used those either, clip brushes are another aspect worth mentioning. Apart from the standard clip texture that used to keep the player from reaching certain areas, encase all large static models (eg: furniture) in a brush textured with monsterclip or AI won't detect collisions and attempt to walk into them. Lighting: Light placement was okay. I'd be careful about putting too many candles next to each other, lights are performance intensive so you want to have as few as possible covering an area. Only issue was ambient light which is too strong, both visually and in making the player visible, I suspect I alerted everyone because it's so bright I scared the whole map when jumping through the window. When the player is crouched without moving in a completely dark area, the light gem should be at its minimum value, adjust ambient light based on that. Ambiance: The map has no music, this isn't a big deal but for a good FM you'll need to learn about locations and using the location_info / location_separator entities to separate portal rooms and give each one an unique song and ambient color. Objectives: Having just two objectives is fine for a tiny FM, usually you'll also want a loot objective based on difficulty level. Only issue with the main objective was that it's difficult to grab the leg; It's lit by a lamp that can't be turned off, lots of AI walking around at once so it's also hard to catch a break when no one is looking... always be on the lookout for those things and what options the player is given. The final objective telling the player to leave once all is ready should use a location check rather than interacting with an item. Tools: The FM doesn't provide any of the starting items that are normally available... blackjack and sword, lockpicks, spyglass, lantern, compass. This isn't always a bad thing, in mine I like having the player pick them up from the world, but generally you'll want them to be available. Navigation: The layout was good and navigates well. There was only a problem at the end, where the map requires you to take a fall that deals damage; If this is intended I don't think it's a problem, there's one FM I played recently that requires you to take some damage as you proceed, but most aim to let the player have a no-damage run without having to confront any AI if you can help it (excluding knockout or assassination objectives). I hope this helped, let me know if I can help with more info. Here's a screenshot of the world edge I was referring to, you can also tell the excess ambient brightness which is reflected in the lightgem.

Sorry, didn't find a thread for praise yet. You guys did an absloutely great job with 2.13. Not only did the loading times improve massively, the light gem/A.I. visibility is much more consistent now, but, also the changes to the Training Mission are great. Thanks for still maintaining the mod, and improving it with literally every new version.

I think this is not exactly how it happens, because the algorithm is CPU-only, and it definitely works for invisible areas (e.g. guards detect bodies even if player is inside a locked room). But the issue 6546 and the aforementioned commit messages are a good place to start. Basically, the engine can now sample light intensity at any point at any moment, without any usage of graphical API. It computes all the shaderparms, conditions, settings, it uses raycasting to take hard shadow into account, it samples the light textures on CPU to take projection/falloff into account. Luckily, we only need consider to lights, we never touch surfaces. Computing surface properties on CPU would be unfeasible. The procedure is cheap for a single point, but very expensive for every screen pixel / mesh vertex. So just as you said, the meshes are sampled randomly, with samples distributed over short time. Some kind of average is computed. This spreading over time is unfortunately necessary to make results both fast and reliable. And this is the ugly part: if you request light value and use it the same frame, you'll just get zero. You need to continuously request light value of an entity in order to get meaningful value soon after you start. In principle, we can use this system to implement CPU-only lightgem (aka "weak lightgem" of the past). But its values will never match perfectly with the values of the current GPU lightgem, and I have a feeling that the switch might be traumatic due to behavior change.

Got around to trying this out. The winter skybox and landscape were excellent, especially when viewed from the rooftop. You mentioned using 16-bit terragen to build the terrain. I wonder if there's a more modern (but free) tool these days? Crafty use of teleporting+FX. (The Boy Lag playthru video does a KO early on, so doesn't show any of those. His loss.) Like others, I had some performance issues at the start. With my weak GPU, I had frame stutter under fresh-download 2.13 and so downgraded my settings. Sounds like 3 hypotheses have been floated for that - you mentioned parallel moon light translucent exterior windows needs visportaling Only other problem I saw: 2 instances of the movable rough oak chair sunk into desk or floor. I thought the light-leak under the wizard's gown was a feature, not a bug... radioactive shoes or underwear? I enjoyed the straightforward story and colored lighting, and always go for rats. My dexterity and patience were a bit strained in two places (landing on windowsill; rock hopping), so I used magic (cough *noclip* cough). Don't hate me. EDIT: After seeing your hint about the 2nd secret, I went back to look for 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

Scroll of Remembrance was my first FM years ago: I made some bad design choices, it is very slow because of large areas with bad portals. Not sure if I'll ever be updating this again, working on other missions too at the moment. Gem of Souls shouldn't be that slow, especially being such a small FM. Does this only happen outside? Likely the grass and / or rain if so. I also use cubemap lighting there, apparently Gem is one of the first FM's to do so, but I didn't notice a performance impact from that.

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

@BoilerDunce, in the past, I've sometimes had similar problems. Often, it's because something outside the perimeter was invisible, e.g., the center of an area light. That's usually because I forgot to turn off DR Filters. Or if you use DR Layers, similar potential for hiding. Other times, there really is some tiny crumbs or shards of brush or patches out there in space. Just really hard to see them. Don't strain your eyes too much. Just make a big box around the suspect "empty space", use DR "select inside" or "select touching", and delete. That can occur if, say, you import a prefab, then move it to where it needs to go while some DR filters are on, so you don't realize you're only moving part of it.

First, I understand that changes to stealth mechanics can be a tough decision, since it will affect Ghost runs, old records will have the caveat of their version, some missions may become outdated and impossible to ghost. They can however be great fun if they are optional. While playing the Thief games, I thought about what I would look like from the perspective of the guards and realized, "I should not really be hidden! I look very obvious!" Not because I thought the light was calculated wrong in the world or anything, but because the shadow I was hiding in would only hide me against the dark wall that was also in shadow. Down the hallway was brightly lit, so anyone approaching from down the hall instead of across would see me due to the contrast of Garrett's dark silhouette and the light behind him. So, there is just something epistemically wrong with the light gem system. There is no "one amount of hiddenness" that a thing can have, but an amount of hiddenness for every perspective. I couldn't find anything about this, but maybe it's because I only checked here. Feel free to indict my ability to search for things if I overlooked a predecessor's topic on the same thing. What came to my imagination about a light gem that would really represent how visible the player is to multiple perspectives was this: Like the original, the gem is dark in darkness, and faintly bright when brightly lit. But, if the player is in a guards line of sight, the number of guards who have him in line of sight will be the number of sparkles that appear inside the gem. If the player has a very low contrast from a guards perspective, that guard's sparkle will remain very small and still. But, if one of the guards sees a high contrast between the player and what is behind him at any distance from that guard's perspective, that guards sparkle will be very large and shimmer. On the side, I think that player movement should definitely provide a penalty to how hidden the player is even in fairly low contrast, and this penalty will apply more to closer guards than to very far ones, but when standing up, even very far ones should be able to ignore the "fully illuminated" requirement to see you at long distance if you move any faster than a casual walk.

Changelog of 2.13 development: beta213-05 (rev 17312-10946) * Removed back menuLastGameFrame feature because of random texture popup (post). * Console font minor tweak to avoid artifact under P. * Minor fix for Catalan language. beta213-04 (rev 17306-10940) * Fixed bug with compass + X-ray glasses combination. * Fixed two buttons displayed in menu objectives during game (post). * Added new smoking animation. * Added menuLastGameFrame image to show game footage in in-game main menu (6608). * Changed install/uninstall mission to select/deselect in main menu. * Fixed editor images for HD carpets (6607). * More fixes for Catalan language. beta213-03 (rev 17294-10935) * Fixed crash in WS3 due to script name collision in invisibility potion. * Added praying animation. * Fixed heat-haze shaders with nontrivial Render Scale. * Restored back tonemapping in the menus. * Allow settings hotkeys for gasmine, slowfall, invisibility, made strings translatable. * Fixed double-cursor in game console on 1920x1080 (post). * Applied noise reduction to new vocals for drunk "jack" AI. * Added support for Catalan language. * Fixed UV maps on stove models (6312). beta213-02 (rev 17281-10932) * Fixed HOM-like artifacts in AT1 Lucy and trash frames on TDM start on Linux (post, post). * Disabled tonemap compression curve and reverted settings to 2.12 defaults (post). * Added menu options to disable volumetric lights and parallax mapping. * Fixed varioius issues with largesquare01 materials (6579). * Fixed several issues in the new parallax materials (6604). * Deleted plain_redgreen_design_HD material which references non-existent textures (6601). * Some main menu buttons during game start replaced with generic "Next" (post). * Climbing sounds now depend on material (4991). * Added shaded_lamp_with_grill model (6589). * New fabric_ornate and fabric_fleur materials. beta213-01 (rev 17262-10927) * Improving the fonts continued (thread). * Fixed unwanted mine deployment when player eats the last bit of food in hands (6598). * Removed old hack to fix for scripted savegame crash (4967). * Added a model ext_timber01_window01_empty.lwo (6600). * Fixed missing skin for atdm:ai_revenant_spirit (6595). dev17251-10920 * Added slowfall potion. * Added invisibility potion. * New tonemap settings are now default (post). * Added Texture Quality settings in the main menu. * Added pipes_industrial_modular models. * Minor adjustments to colored versions of gen3 environment maps. * Default value of inv_count is back at 1 to fix issues with inventory counts. * Fixed rare crash on loading collision models (post). * Refactored heatHaze shaders. dev17234-10914 * Added many new high-res materials, half of them with parallax mapping. * Implemented optional HDR compression in tonemapping + other improvements (post). * Implemented interactionSeparator syntax in materials (post). * Added new entityDef: atdm:radio. * Added colored versions of gen3 environment cubemaps for metallic materials. * Added new environment cubemaps: sparkles, studio, blurry. * Added coat_commoner_hanging and coat_inventor_hanging models. * Added mantle_clock_ticking sound. * Improved lightgem calculations while leaning (post). * Fixed regression with double-sided materials (5862). * New sorting of inventory grid items (6592). * Reduced font size of mission list, which allows to see more missions and longer names (post). * Added scrollbar to "notes" of a mission in the main menu. * Optimization: don't render interaction groups with black diffuse & specular. * Improved "scepter" material (thread). * Fixed normal map of ornament_relief_mold_eaglelshield (6585). * More tweaks to starry2 materials. * Made material noshadows: moon_full_shaded, shooting_star, moon_glow. * Added "inv_count" "1" spawnarg to atdm:playertool. * Gas mine now costs 125 instead of 75. * Added min/max builtin functions to game scripts. * Added script events about gravity, health, in-air movement. * Added script events setUserBy, setFrobActionScript. dev17171-10894 * Added entityDef archery_target01 with hit detection, it is now used in Training Mission. * Fixed missing steam_pipe02_straight in Training Mission. * Hiding mouse cursor during briefing in official missions (6576). * Cleaned up the code for extracting interaction groups in material. * Parallax mapping: supported "translate", self-shadows are disabled properly (6571). * Fixed meshes generator_big, generator_small, generator2, warehouse_front_doorframe (6581). * Fixed material on model stove_open02 (6580). * Fixed decals on ext_timber01_window01 (5782). * Improved largesquare01 materials with bumpmap and specular (6579). * Added skybox materials clouds3 and clouds_4_small + prefabs. dev17152-10890 * Major update of Training Mission, including vine arrows (4352). * Added TDM version + engine revision in lower-left corner of main menu. * Experimental implementation of parallax mapping (6571). * Fixed frob interaction with candle holder that's initially extinguished (6577). * Better icons for scrollbar thumb in menu, fixed author search (6339 6570 6449). * Fixed hiding mouse cursor during video briefing/debriefing (6576). * Fixed map immobilization not applied if opening map with inv use key. * Forbid adding missions to download when download is in progress (6368). * Skip disabled bump stages in environment mapping (6572). * Disabled texture compression for light images: falloff and IBL cubemaps. * Minor change in shadow map acne / blur radius computation (6571). * Added banner01_edgar and banner01_viktor banners, along with long versions. * Fixed UV map for longbanner_ragged model (6573). * Added missing jack/drunk_idle13.ogg sample (6507). * Fixed handle_curved02_latch prefab, deleted pull_handle (6286). * Replaced normal map of cobblestone_blue_black with high-res version (6574). * More detailed editor images of some materials (6575). * Added small_dresser_openable prefab. * Added banner_sword + tdm_bannerlong_sword materials. * Increased size of secret message overlay GUI. dev17121-10869 * Massive improvements in mission select & download menus, added search (6339 6570 6449). * Improvements and fixes for "builder priest" animated mesh. * Improvements of idle01 animation. * Improved newspaper01 model (6568). * Added gas mine to "map start pack" prefabs (6559). * Fixed text alignment in save/load menus. * Minor CI/build fixes. dev17104-10844 * Enabled the new system for tracking light value by default (6546). * New light value tracking integration covers ropes and doors + optimized shadow rays (6546). * Added atdm:playertools_gasmine (6559). * Workaround for compiler bug which broke particle collisions with texture layout (post). * Fixed r_showTris: color, values 2 and 3 (6560). * Minor improvements to drunk vocals (6507). * More tweaks to sculpted/girard_relief_pho. dev17095-10833 * Major improvements in drunk AIs: setting "drunk" spawnarg is enough now; new sounds, animation improvements, greetings, etc. (6507). Fixed drunk women AI (5047). * Incorporated stone font updates by Geep (thread). * New footstep sounds for ice and broken glass (6551). * Fixed light culling bug on elongated models with non-identity rotation (6557). * Added new system for tracking light value of entities (6546). It is disabled yet. * Technical change in loading of particle collisions (6546). * Now AI follower settings can be set as spawnargs, added prefab (6552). * Added proper dmap error message if map file contains an entity before worldspawn. * Fixed water_medium_running sound (5384). * Fixed window/metal_irregularpanes_moonlit material. * Fixed wood/boards/rough_boards_scratched (4157). * Fixed wall/ship_wheel model (6549). * Fixed gaps in awning_cloth_01_large model (6550). * Added weather particles with static collisions enabled (6545). * Added a pack of new factory_machines models (6537). * Added fabric/cloth_baize materials (red and purple). * Added window/diamond_pattern01_moonlit_bright material (6133). * Added AO and specular maps to sculpted/girard_relief material. * Added musicbox sound, added prefabs for it and for victrola. * Added wood/panels/mary_panel model. * DarkRadiant now knows about parallelSky param (6496). dev17056-10800 * Supported "efx_preset" spawnarg on location entities (6273, thread). * Fixed rendering of volumetric light and particles in X-ray views (6538). * Fixed rendering of particles in mirrors (6538). * Improved volume estimation for subtitles, very quiet subtitles are hidden (6491). * Fixed bug in idClip::Translation of non-centered models. * Third-party integration greatly reworked for better integration with conan (6253). * Stone/subtitle font improvements by Geep. * Fixed sleeping sounds for drunk AIs (6539), and other sounds for them too (6507). * Fixed missing shadow on endtable_001 model (6288). * Added girard_relief material. Known issues: * Shadows of Northdale Act 1 does not start (6509). (mission has been updated) dev17044-10746 * Supported mission overrides for cvars which are tied to gameplay state (5453). * Fixed crash on start with 32-bit Windows build. * Rebuilt all third-party libraries with conan 2 system (6253). * Reverted improvements of capped FPS to fix video/audio desync (5575). 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 now 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: thread (only in this dev build) 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.

I'll try and go through the history over the weekend. Like I said, I'm just experimenting to see what sticks. The crouch offset, for example, is perfect if you want to keep the gem as close to the ground without clipping into it, but may have the unintended side-effects for gameplay - either way, I don't think that's the main issue here. That cam adjustment is throwing me off, though. I don't understand why moving the gem a bit left/right/forward would result in it darkening so hard. I've moved the gem's rendering to PLAYER_VIEW to test where it is (not expecting accurate calculations), and it moves around as expected. I get the feeling that there's some engine machinations happening under the hood that mess this up, but that's why I called it superstition in the first place. In the meantime, maybe someone more experienced could try and discern if this is coming from some other unexpected/unintended part of the player/entity/physics/leaning/camera/culling/etc interaction.

idTech4 engine has used on Doom 3 already had a destructible entity system for the destructible barrels, was that removed? In Doom3 you can create debris entities and they become physics entities, never heard of this "flinder" stuff so I assume is a new TDM entity type. Don't know if this is useful for TDM, if not ignore, but who knows could give some hints. This was how I created a simple destructible wood barrel in Doom 3 engine. First I defined the broken debris peace's: (yes they are individual entities and models) entityDef debris_woodbarrel_1 { "spawnclass" "idDebris" "mins" "-3 -3 -3" "maxs" "3 3 3" "model" "models/maps/temple/mapobj/pipo broken/pipo_debri_1.lwo" //"skin" "skins/exp_barrel_red" "health" "0" // amount of damage projectile can take if damaged (0 means it can't be destroyed) "velocity" "1 1 450" // how fast the projectile leaves the gun (or distance if fuse is 0) "random_velocity" "1" "angular_velocity" "105 215 10" // how the projectile is rotating when it leaves the gun "thrust" "0" // the rate of acceleration (always in the direction of the projectiles model) "thrust_start" "0" // when to start accelerating "thrust_end" "0" // when to stop accelerating "linear_friction" "1.0" // "air" friction "angular_friction" "0.1" "contact_friction" "0.9" "bounce" "0.1" // how much speed a projectile retains when it bounces off of objects (coefficient of restitution). 0 means no bounce. "mass" "50" "gravity" "1066" // how much gravity affects the trajectory. gravity direction is same as the entity that fired it. "fuse" "10" // how long before the projectile is removed or self-detonates. Use 0 for beam weapons (velocity == distance). "detonate_on_fuse" "1" // whether projectile should detonate when it's fuse runs out "detonate_on_death" "0" // whether projectile should detonate when it's "killed" (health runs out) "detonate_on_world" "0" // whether projectile should detonate when it hits an obstacle "detonate_on_actor" "0" // whether projectile should detonate when it hits a character in the game "smoke_fly" "debristrail.prt" // particle effect while in the air "snd_bounce" "tray_impact" // parametric particles -- temp "model_detonate" "" "smoke_detonate" "" // particle effect when detonates "smoke_fuse" "" "smoke_bounce" "" } entityDef debris_woodbarrel_2 { ... } etc, then I define the main entity: entityDef moveable_woodbarrel { "editor_color" "0 .5 .8" "editor_mins" "-16 -16 0" "editor_maxs" "16 16 48" "editor_rotatable" "1" "editor_usage" "Moveable woodbarrel. Works just like a func_moveable. However the barrel" "editor_usage1" "has special handling to make it appear more round. This version also explodes when damaged enough." "editor_usage2" "Only add model, model_detonate or model_burn or health to override defaults" "editor_var burn" "number of seconds to burn before exploding." "editor_model model_damage" "model to leave as damaged base" "editor_model model_detonate" "ips model to switch to for explosion." "editor_model model_burn" "ips model to show when on fire." "editor_var def_debris" "add as many as you like, debris1, debris2, etc.. " "editor_var health" "how much health the barrel has, default is 5. If burn is set to 1, the health is effectively doubled so you have to kill it twice to get the explosion" "editor_var respawn" "if non zero the number of seconds to respawn after killed" "editor_var respawn_range" "no player in distance range to actually respawn - default 256" "editor_var respawn_again" "try again in seconds if player in range - default 10" "editor_var triggerTargets" "if set to 1 will trigger targets after being killed" "editor_mat mtr_lightExplode" "light shader to use for explosion" "editor_mat mtr_lightBurn" "light shader to use for burning" "spawnclass" "idExplodingBarrel" "density" "0.02" "friction" "0.2" "bouncyness" "0.4" "def_splash_damage" "damage_moverCrush" "ignore_player" "1" "model" "models/maps/temple/mapobj/pipo.lwo" "def_debris" "debris_woodbarrel_1" "def_debris1" "debris_woodbarrel_2" "def_debris2" "debris_woodbarrel_3" "def_debris3" "debris_woodbarrel_4" "def_debris4" "debris_woodbarrel_5" "def_debris5" "debris_woodbarrel_6" "def_debris6" "debris_woodbarrel_7" "def_debris7" "debris_woodbarrel_8" "def_debris8" "debris_woodbarrel_9" "health" "35" "snd_explode" "wood_barrel_breaking" "snd_bounce" "woodimpact" } This was the effect: https://drive.google.com/file/d/1lsXwNssxp-QO3MZKOmUiBd1DWhd0V7HY/view?usp=sharing Hope this helps.

I really hope there won't be a complete lack of consistency in the future, with everything FM authors or contributors to coding want to change about the mod the whole time... Some FMs already play as if they were from a parallel universe. To illustrate the problem: Imagine a new player getting into the mod. He will play The Training mission, and maybe some of the older missions, which don't modify weapon, enemy, or light gem/shadow behavior. Then he gets into some of the new missions, and needs to re-learn in every mission the conditions, because the FM author chose to modify weapons, make the player always visible, change A.I. behavior, or even change or introduce new weapons. I appreciate the cerativity, and understand that some want to extend the gameplay possibilities. But, it always comes with the, in my eyes, big penalty of making the player adapt to the new conditions, and every single mission, and, some things he can't know, and he'll be very surprised that the mission behaves the way it does. I really hope FM authors go back to the roots again one day, and don't overwhelm the player with thousands of changes and additions, which make the missions and the Dark Mod unvierse less coherent and uniform, and confuse the player.

a belarusian band : i found another secret gem : another lullaby by vashti bunyan (apart from just another diamond day), this song makes me lost in reverie : ============ well these twos are from my country, always on my loop list in the last 7-8 years :

1) Visible body when looking down 2) Lot's of weapons in maps like axes, daggers etc, why not let the player wield them rather than them be mere objects? 3) Ability to go prone 4) Text readability to depend on external light source. 5) Headshots / direct face shots should be instakill, whether player or NPC. 6) Option to adjust objectives brightness. 7) Option to disable "a new mission is available" popup.

uh they would not what!!! if the card is overheating and you clean it regularily they cant just write it off, its either a design flaw or someone forgot to add thermal paste to the gpu. either way its they're problem not yours. sadly i seen this before like on my old 1080 ti on which they used the 1070 cooler. for light games it was ok but it overheated on some of the more demanding titles. sadly i bought it used so there was no insurance left. i fitted it with a a rajintek morpheus cooler instead, and it runs the heaviest games while newer getting above 45 " now.

I've just raised this: https://bugs.thedarkmod.com/view.php?id=6334 If you have lights randomly extinguishing on map start and you can't figure out why, it might be because the light is surrounded by a merged water entity and the engine thinks it's submerged. There are links to test maps I've made available in the bug report. Screenshot below illustrates the issue. The arrow is pointing to the water line, and the circled torches are below the water line. The walls are made of glass so it's easier to see what's going on. If you run into this, the workaround is to simply not merge your water entities!

Yes, that's just a func_static with a "model" key set to the entity name, which means it's brushwork converted to a func_static (so DR just renders the brushes). My guess is that DoomEdit does something specific when you "connect" a model and a light, which we're not doing in the same way. I thought that all that "connect" did was set a target key to point to another entity. Maybe it's supposed to have special handling for models and lights.