Search the Community

Something I just ran into, so I figured I'd share what I learned. I had an AI doing a path back and forth from A to B to A, etc. It would work fine for a while, and then suddenly he would stop and just stand there. At that point he would never proceed on the path. I cranked up the logging and saw something in darkmod.log about "handle door task" associated with that AI. I realized the problem. I had a dummy door nearby - it is a "door to nowhere" (solid wall behind it). But instead of using a door model, I had cloned a nearby atdm:mover_door and set it to frobable=0 (and removed the handles). That certainly keeps the player from using the door, but apparently it confuses the AI pathfinding. I replaced it with a model door, and now the AI path works fine. Bottom line: always use a model for dummy doors. Sounds obvious, I know.

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

If the "mission fails as soon as stealth score turns non-zero," that would not be good for ghost players. They might need to find out "how" they failed and experiment to avoid alerting guards. They might need to take those score points as a "bust". They might need to take those score points to complete an objective. Then, mission authors would need to encode exceptions into their missions, which would be a lot of work (if they decide to do it at all). However, part of what makes ghosting challenging and fun is when mission authors do not create their missions with ghosting in mind. Please see: Official Ghosting Rules: https://www.ttlg.com/forums/showthread.php?t=148523 Writing code for these rules would be a huge undertaking. Ghost Rules Discussion: https://www.ttlg.com/forums/showthread.php?t=148487 Creating an official mode could alienate these dedicated ghost players, because it would clash with what is considered ghosting in the community. Including the Stealth Stat Tool mod in the official release would be more useful. Or, making the audible alert states of guards quick and easy to recognize could help as well. For these reasons, I don't agree with an official "Ghost" mode. If the dev team were to do it, we should consult with @Klatremus so we get it 100% correct or not pursue it at all. (This ghosting bit should probably be in its own thread.)

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.

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/

https://github.com/Acly/krita-ai-diffusion Generate images from within Krita with minimal fuss: Select an area, push a button, and new content that matches your image will be generated. Or expand your canvas and fill new areas with generated content that blends right in. Text prompts are optional. No tweaking required! This plugin seeks to provide what "Generative Fill/Expand" do in Photoshop - and go beyond. Adjust strength to refine existing content (img2img) or generate images from scratch. Powerful customization is available for advanced users. Features Features are designed to fit an interactive workflow where AI generation is used as just another tool while painting. They are meant to synergize with traditional tools and the layer stack. Inpaint: Use Krita's selection tools to mark an area and remove or replace existing content in the image. Simple text prompts can be used to steer generation. Outpaint: Extend your canvas, select a blank area and automatically fill it with content that seamlessly blends into the existing image. Generate: Create new images from scratch by decribing them with words or existing images. Supports SD1.5 and SDXL. Refine: Use the strength slider to refine existing image content instead of replacing it entirely. This also works great for adding new things to an image by painting a (crude) approximation and refining at high strength! Control: Guide image creation directly with sketches or line art. Use depth or normal maps from existing images or 3D scenes. Transfer character pose from snapshots. Control composition with segmentation maps. Resolutions: Work efficiently at any resolution. The plugin will automatically use resolutions appropriate for the AI model, and scale them to fit your image region. Upscaling: Upscale and enrich images to 4k, 8k and beyond without running out of memory. Job Queue: Depending on hardware, image generation can take some time. The plugin allows you to queue and cancel jobs while working on your image. History: Not every image will turn out a masterpiece. Preview results and browse previous generations and prompts at any time. Strong Defaults: Versatile default style presets allow for a simple UI which covers many scenarios. Customization: Create your own presets - select a Stable Diffusion checkpoint, add LoRA, tweak samplers and more.

I'm happy to present my first FM, The Spider and the Finch. There may be a spider, but no ghosts or undead. It should run a couple hours. It's now available on the Missions page or the in-game downloader. Many thanks to the beta testers Acolytesix, Cambridge Spy, datiswous, madtaffer, Shadow, and wesp5 for helping me improve and making the mission to the best of my abilities. This would not be have been possible without Fidcal's excellent DarkRadiant tutorial. Thanks also to the many people who answered my questions in the TDM forums. Cheers! 2023-12-13 Mission updated to version 3. Fixed a bug where the optional loot option objective was not actually optional. Updated the animations for Astrid Added a hallway door so the guards are less likely to be aggroed en masse.

Sorry if this was already reported, but Ive experienced pulling back the bow and the arrow model just disappearing. The bow will still be there, ill fire and the projectile will still launch, but not arrow on the view model. Strangely it doesn't always crash when that happens. This was definitely already mentioned Just confirming the arrow disappearing, shooting, but then not crashing, which is odd. EDIT: Ill start attaching the debugger. I have lots of guards in the mission but none of them are using the urinate animation. Does it happen randomly somewhere in the code? I can just try adding 50 guards lol.

Yes, I left it a little ambiguous as to what I meant; in that Both there is 1 particular model over-used AND that there are more lamp/lantern options available now. (more and some form of Modular-lamp would be neater) I think that is a 'Naval / Marine' "Den Haan Holland" brand lamp; for yacht use...and apparently STILL-MADE (today). [or its not and its a 'Tung Woo' from the late 19th century, Marine/Ship wall-lamp...its hard to tell them apart]

Wasn't sure if I should still post this since the mystery was somewhat solved, but just to confirm this case can be found in the wild with FM's other than mine: Yesterday I played Chronicles of Skulduggery 0: To Catch a Thief. There's a door up on a terrace (I can reinstall it and go there to get a viewpos if anyone's interested) which upon picking and opening will cause the light on the back of the wall indoor to slightly shine on the floor outside through the entire wall. Exact same camera position / angle in both images so you can just overlap the two screenshots to see the difference, though if you look at the bottom left ground it's pretty clear what happens once the door is opened. It's still a bit weird: The wall module model should still be casting a shadow, even if the wall brush uses caulk and not shadow caulk. Whatever the case a few FM's out there seem to have this problem, even if it's not an issue the engine or building modules can resolve I wonder if mappers can be better put on notice about it since like me most are likely not aware this is a thing or what causes it. Looked at the first post again and the video attached to it: Definitely seems like the same thing. Most importantly it wasn't doing this in earlier versions which I didn't realize... I'm seeing the clarification by Stgatilov as well which I initially missed, I definitely prefer the performance optimization but now I do wonder if something can also be done about this eventually.

I'd like to ask a (hopefully) easier favor from the DR devs on this, considering it's such an issue and making me struggle to keep mapping normally. I know the root issue seems to rely on WxWidgets and may not be solvable on our end, but at least one part of it I consistently run into should be. Like I said I can initially avoid the problem by exporting the "GDK_BACKEND=x11" variable in my shortcut, this makes it go away for the 2D and 3D viewports and only persist in the model viewers which I can care less about. There's just one exception: The moment I press X to use the clipper tool and cut a brush, the 2D view starts experiencing the issue and becomes impossible to drag normally. Because of this I need to avoid using the clipper as much as possible, and whenever I have to in order to get a triangle brush I must restart Radiant immediately after. Would it be possible to figure out what the clipper does that's so unique to triggers this? Does using it reset the 2D views and somehow gets them reloaded by Wayland? If yes could this be avoided so in the meantime it doesn't break that workaround? If at least this can be solved and the GDK_BACKEND workaround keeps otherwise working, it will be a lot easier to wait for the proper full fix. Sorry for the annoyance with this... just want to make some good FM's and using DR this way is running on a handicap that makes the already complex process of mapping even slower.

Similar: My suggestion is getting rid of needing tdm_custom_scripts.script as a requirement. The problem is that unlike every other asset, be it a def or a skin or model or texture, scripts need to be referenced from a core script file for execution: FM's each need to contain a file with that exact name including their custom scripts. The problem with this is that no mods containing scripts can work out-of-the-box as a drag-and-drop pk4, the same way that say a custom character (just AI model or skin) can: Each individual FM needs to integrate it manually, universal mods aren't possible since the last pk4 loaded will override tdm_custom_scripts.script or tdm_user_addons.script breaking all previous mods referencing their own scripts from those files. The ideal solution would be just auto-loading scripts like everything else. But I imagine this may no longer be possible as it could break a lot of existing things like older FM's. One compromise I believe I suggested was allowing a dynamically named script to be auto-loaded by the engine, which would make it so different pk4's don't override the exact same file and conflict with each other: If your mod is named "whatever.pk4" for instance, the engine should auto-execute the script named "scripts/whatever.script" located in that archive... this would provide an elegant and equally sandboxed solution to this long standing issue.

DarkRadiant is presently suffering from huge slowdowns when editing complex maps. They appear to increase the more models and entities are added to a map: With the building modules used in a lot of places, one of my maps is at the point where DR freezes for over one second whenever I merely toggle a filter which is very annoying for every repeated action. The lag occurs both when moving the 2D or 3D camera or viewport around, as well as enabling or disabling filters or using Control + F to go in and out of editing a group. From what I can tell as an end user, this seems to occur because DR drops models that are no longer being rendered from memory, so whenever a change in the camera or viewport is made everything that pops into view or is recalculated floods back in. While this may be nice to save on RAM, my suggestion would be a change or at least an option to disable this behavior and keep everything precached: Like TDM itself, DR should maintain every model and texture used by the map in memory, only removing it once every last instance has been changed or deleted from the map being edited.

Thanks to Stgatilov for fixing the head model change crash! Though the fix will be featured after next dev snapshot, I'll likely update this mod again once that's out. While few maps have mirrors, remember some may be designed with this mod in mind as the goal is to have it working as both a FM and universal mod. Thanks: I'm glad you like it even if it may not be featured in the mod pack, though I'll likely attempt some of your suggestions at least. I tried to make it intuitive, hence I didn't add special circumstances (like running) for wearing out the disguise even faster so players aren't left wondering what triggers it, however it may be featured next time: I don't remember if there's a way to check if the player is sprinting or crouched, so I'll likely use the player speed thus the faster you're moving the more quickly you're spotted... I might even make it so being seen picking locks or stealing loot instantly makes your disguise fail! Making a helmet no longer usable after being caught once is tricky: Helmets all look the same, therefore guards wouldn't notice if you stole another hat and used that to trick them again... they don't use energy either so needing a special way to recharge them wouldn't make much sense. Remember also that being seen by an alert guard makes the disguise drop faster, and part of the alert level is permanent meaning guards will always catch you a bit more quickly if they were alerted once. The logical solution would be that once you're caught, you can't ever disguise yourself to trick that team again... this would make them too useless and irreversible so no. A good middle ground instead is having a long cooldown timer, so once caught you can't disguise yourself for say 5 minutes. What does everyone think about that?

It's not that no: I didn't modify the properties of the default entity or its flame, in this case it's the standard atdm:lamp_oil_wall_lit entity... also I have player shadows enabled, the player as well as other architecture elements cast shadows fine. Walls are the building modules, eg: model models/darkmod/architecture/modules/interior_set01_corner.lwo with skin diamond_wallpaper as a test. This is the closest to the setup I still have: The origin of the light is well beyond the face of the module surface for shadow casting. Though this shouldn't even matter since the light is in the other room and the caulk brush should itself mark this. I think I noticed this on other maps too while playing, but only now saw it obviously enough to realize there's likely an issue somewhere. I remember seeing the glow of a light from another room shining on the floor / ceiling when it shouldn't, though I didn't document it at the time.

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!

Good work! I enjoy short missions because things are nice and focused - you get in, you get out. Also I tend to do better with the loot amounts and I was able to get all the loot without too much trouble, which is rare for me. If I were to make a suggestion though - I found the intro briefing sequence a bit distracting because it was so obvious the narration was pitch-shifted to make a deeper voice. If you felt the original voice wasn't deep enough for your needs, I would either get someone on the forums to record it for you or just leave as is. That's my only real complaint and it's not even about the mission itself, so pretty good first start!

Thank you. I see two different models: Hearing Impaired (HI) and Hearing Unimpaired (HU). The HI model includes low-hearing, deaf, and players with audio turned off for which all sounds are relevant: Plot (key conversations, special effects such as footsteps upstairs...) Surroundings (generic barks, doors...) Environment (machinery, thunders...) You somehow have to let players know how an event (sound) relates to them and their actions. I understand italics and colors are not available so you probably have to use brackets, in example, for anything that is of no concern to the player (but still relevant). You then have to let players know where sounds are coming from and it seems this is going in a good direction (congrats). A different story is how to make HI players know how much noise they are making... The HU model would be for: Players for whom English is not native Translations for obscure ai dialects or accents Support for bad audio or recordings I think we don't need effects in this model, players can hear effects already. I have a question at this point, what happens if a key conversation and general barks take place at the same time?

Beta 11 Fix finished-on state auto-update was unreliable Slighty improve scanner title/author detect Tags are now named some whatever regular-version-looking thing to force GitHub to put the newest at the top

Front ends- still work (Piped, Invidious..), also FreeTube, SMPlayer also permits to view videos in streaming from YT and others, the Feed Reader of the Vivaldi browser also permits view YT videos embedded, Andisearch can reproduce YT sandboxed in the search results, all this still without ads. Only real alternative to YT don't exist, maybe the nearest is Odysee with way better privacy and ethical business model, not related to Google.

In the mission, Tears of St. Lucia, the boarded up door is missing nail textures. At viewpos: 1954.81 3414.48 -377.75 24.1 -127.7 0.0 The model: models/darkmod/architecture/doors/door_boarded_up01.lwo

I'd like to better understand what you want. The design of dragging bodies is to hold frob (key down) to drag and release frob (key up) to let go. That way it's impossible to walk away while unintentionally dragging a body. Plus, it's quick to grab and move several body limbs in rapid succession. This is thought to provide a better experience, especially for new players. Towards the beginning of this thread, I created a "tdm_frobhold_drag_body_behavior" cvar. https://forums.thedarkmod.com/index.php?/topic/22198-feature-proposal-frob-to-use-world-item/&do=findComment&comment=487580 "tdm_frobhold_drag_body_behavior", default:"1" Which drag body behavior? 1 --- on frob key up, drop body (limb). 0 --- on second frob, drop body (limb), TDM v2.11 (and prior) behavior. That cvar was removed shortly afterwards, because it was said that it wasn't needed. With that cvar set to 0, a second frob would be required to let go of the body. Is that the behavior that you want? If so, I can add that cvar back. Also, I saw elsewhere that you want the ability to revert back to the old way. If you mean that all of the controls match TDM 2.11, that can be done with "tdm_frobhold_delay 0" and there will be a menu setting to disable it as well.

Interesting, didn't think about that. Yeah the compass uses that trick, I could just use a model of the helmet instead. If it looks good and is worth maybe I'll consider that, though it might be distracting and not make enough sense. The heads are modeled that way: Hoods and helmets are part of the head mesh as they aren't attachments. This is normally a good thing since performance isn't wasted rendering the head or hair under the helmet, but complicates things for my approach as the only way is changing the head models at runtime which may break precaching and stuff. Only a few hats are attached as a separate entities, like the little red hat some merchants wear or the straw hat... those aren't ideal for disguises though and I don't plan on supporting both approaches. Technically I could try attaching the independent helmet model to the player head, but that would surely look awful and clip through the hood and stuff... only right way is to give the player the Citywatch head once that error is fixed. For AI there is no other way apart from also changing the head model: Stealing the helmet from a guard implies taking it off them, which means they need to switch to a helmetless head which can only be done by setting a different head mesh upon frobbing... no idea if that triggers the same crash as the player head, if so I'm out of luck till a dev can take a look at my report. The base disguise system can be used that way too, it's just not the theme I went for by default as I wanted them to be physical wearables. You can define a magical disguise too that implies creating an illusion which tricks other AI into seeing you as one of them. In fact I thought of including one for undead using a magic skull that makes them think you're also dead, might add that in the next version if others think it makes sense and is worth it? Note that the spawnargs are documented via editor vars in case anyone wants to make their own: As long as you have a moveable model and inventory icon it's just a few tweaks to define any disguise. Simply inherit from the base "atdm:playertools_disguise" entity def and customize the team and other spawnargs... remember to use the proper mass / friction / impact sounds. Let me throw them here for anyone who wants a quick preview: atdm:playertools_disguise { "inherit" "atdm:playertool" "editor_usage" "Don't use. This is the base class for disguise inventory items." "editor_usage1" "Individual hats and helmets will derive from this." "scriptobject" "playertools_disguise" "gui" "guis/tdm_hud_disguise.gui" //"model" // to be defined in subclass //"clipmodel" // to be defined in subclass "inv_name" "Disguise" "inv_category" "Disguises" "inv_icon" "" "inv_droppable" "1" "inv_map_start" "0" // Disguise "team" "0" "rank" "0" "personGender" "PERSONGENDER_MALE" "personType" "PERSONTYPE_THIEF" "regen" "0.25" "rate" "0.5" "rate_alert" "0.1" "distance" "500" "speed_move" "1" "speed_turn" "1" "overlay" "" "snd_wear" "player_rustle_short" "snd_remove" "player_rustle_short" "model_head" "head_thief" "skin_head" "" // Disguise editor vars "editor_float team" "The team the player disguises into when the disguise is active." "editor_float rank" "Rank while the disguise is active." "editor_var personGender" "Person type while the disguise is active." "editor_var personType" "Person gender while the disguise is active." "editor_float regen" "The disguise regenerates over time at this rate." "editor_float rate" "The disguise degrades at this rate when the player is seen by a member or ally of the team." "editor_float rate_alert" "The disguise further degrades by this amount when an AI is alert, increases gradually with alert level." "editor_float distance" "Maximum distance at which being seen by the AI can degrade your disguise, offsets with AI visual acuity." "editor_float speed_move" "Movement hindrance while wearing the disguise." "editor_float speed_turn" "Turning hindrance while wearing the disguise." "editor_var overlay" "Overlay image while wearing the disguise." "editor_snd snd_wear" "Sound to play when putting on the disguise." "editor_snd snd_remove" "Sound to play when taking off the disguise." "editor_model model_head" "The player's head changes to this model while the item is worn, can be seen in mirrors." "editor_skin skin_head" "The player's head changes to this skin while the item is worn." }

Btw. I think gui supports 3D models, like can be seen with the compass. I thought for immersion it would be cool to have a small 3d model on screen of the player's look when the disguise is used. Maybe it's nonsense, just something that came up.. Why is that actually necessary? If an item can be attached to an ai head it could maybe also be attached to your head? Can a helmet not be attached to a head? Well I guess it depends how you want to implement it.

Biggest problem is a full outfit would require changing the player's body model including the 1st person hands, and I'm having trouble getting even the head to change for mirrors so likely never happening. Unless massive changes are done in the engine to make it possible... meaning never happening The disguise changes the player's team, so all AI on any team will treat you as the team you're disguised as... however only AI on that team or allies of it can make your disguise wear out and risk exposing you. Currently the only risk is AI is seeing you, the bar dropping faster the closer you get to them... that's gradually accelerated by the AI alert level, being seen by an alert AI can immediately break disguises: Technically I could add drawing a weapon or picking locks or stealing, but I'm not sure if the extra complexity is worth it. When putting the disguise on or after being exposed, you do need to wait for the bar to charge back up... if an AI isn't seeing you this takes about 5 seconds on the default helmets. As for the suspicion meter it's universal, making it per-AI would be confusing as the bar needs to switch to represent the closest one... it also didn't make sense because the player's team is universally modified so you can't trick one AI while being known to another, that would require doing it a different way. BTW: Don't be afraid to check out the script if anyone wants... it's surprisingly small, only 148 lines of code were needed! What I'm doing is actually pretty simple, it's mainly the AI sight that's crammed into a longer if statement. Also I commented the important parts to explain what they do. If anyone's curious you can check it out here: https://pastebin.com/7rU6DAAc