Search the Community

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.

Yes - that's what I found (it's all in the bug report). There are 2 test maps, one with the a single entity and one with them divided. In the one with the divided entities it works properly.

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

Though this is a more general question and less related to light leaking bugs per say, I'd still like to ask to be sure: Does using shadowcaulk instead of caulk teach lights to better detect rooms and ignore entities behind such brushes, thus texturing walls with it improves performance? At first I thought that's the case but likely not since I think the recent light optimizations use visportals to check rooms outside of the light's field of vision.

As usual this is mainly intended as a discussion and to hear opinions: It's not an expectation that the feature will happen soon or at all. Especially as this would be complicated to achieve, but if it could be done I think it may be a fun capability to consider. The idTech engine had several features that got removed since we aren't using them like multiplayer. One used to be the ability to record a demo of your matches, which makes sense in multiplayer DeathMatch games. Yet recently I started to wonder: How would it be like to have a demo capability designed for TDM? Imagine being able to record your playthroughs or share your recordings for others to watch, for when you'd like to relax watching a FM like a film instead of playing it like a game. You could fly as a detached camera, observing yourself wonder around the map and watching the things you did... or stay in 1st person and see the game play itself like in a Youtube video. The coolest thing would be the ability to see through the eyes of any NPC: Imagine being able to click on a guard in floating camera mode to embody them, seeing through their eyes as they patrol the area and at some point notice the player hiding in a corner through that guard's eyes (even if the AI didn't notice you). The biggest challenge would be a way to record store and reproduce every input from the player, with every AI decision and other entity actions just as they occurred, which includes preserving object physics to represent the exact movements of all entities: Parts of the demo system from Quake would likely need to be reimplemented, wonder how much it knows to handle on its own. Saves and loads would be another tricky one: Each demo should erase what you did after last loading to produce a seamless run... alternatively it could record that as an action and include reloading in the playback. There's probably other challenges but if it's within the realm of possibility, would anyone else use this and think it's worth thinking of?

It didn't work. I tried a couple of different trigger brushes pointed to atdm:target_callscriptfunction, but the AI body just won't won't trigger them so the script is never called. I noticed in the description for trigger_entityname, it says "... Only works on entities that can enter trigger under their own power...if player drops them, there is no effect." This seems to be the case for the other triggers as well. I think I'm out of luck on this one, but it was just a nice-to-have, not important.

I have an idea. From time to time, these kind of guard create a penis during animation. This penis creates a thread during spawn, but it starts it as DelayedStart(0 ms). Instead of running the script immediately, it stores its entityNumber onto the callstack of the script thread. Let's suppose that for some reason penis gets destroyed immediately, and bow attachment gets spawned at this exact moment: then the bow attachment reuses entityNumber of the penis. At some moment suicide thread wakes up, reads entityNumber from stack, and kills the entity with this index --- but now it is bow attachment instead of penis. That's a simple explanation why dangling pointers are dangerous! However, if this really works like this, the whole scripting should be completely broken, since scripts in general often wait long time, and all the entities they reference might die during waiting. I can hardly believe this situation is always handled that bad. I'd like to ask people who have used scripting a lot. What happens if you have a local variable X of type "entity", then you do "sys.wait(1.0);", and then try to use X but it has died during waiting?

Indeed, but I imagined it was removed with the other stuff... now I hope it won't be, and if need be can be fixed to be compatible with TDM. The question is if it knows to work with our AI and entities, if we haven't done anything too radical to break it maybe we're lucky and it does! I should finish the FM I'm currently on, then I'll reload a previous one and give it a quick try to at least ensure nothing crashes or goes crazy.

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

After some further research, it really seems to be caused by the inbuilt trigger behaviour for any entity that has a "gui" spawnarg. I created a random func_static, gave it a valid "gui" spawnarg and triggered it twice which resulted in flashing a blank parchment for a frame (after some reloading). So it's unlikely the fault is with the scriptobject.. The question is: does any entity in any map rely on this inbuilt "gui" behaviour? If no we can just remove TriggerGUIs from idEntity::Activate. Do we have a way to extract all entities from all released maps that have a "gui" spawnarg? Edit: extracted all existing "gui" spawnargs from released maps, removed duplicates and removed those that contain words like "message", "map", "text" etc. in order to look for potential non-message GUIs. I looked up the remaining 32 entries in their respective maps to check what kind of entities they're given to with the following results: Turns out that quite a few of these entities (i.e. the func_statics) rely on TriggerCall being part of the base idEntity::Activate method in order to call up their GUIs. So it's not some forgotten legacy code we can remove. We could add a custom spawnarg to the entityDef for atdm:gui_message to disable this behaviour for them - no FM overrides this entityDef, btw, so it'll apply to all FMs - but it won't fix other entities that call GUIs and don't have this spawnarg.

In case of stencil shadows, there are two parts: computing shadow volume (on CPU) rendering shadow volume (on GPU) Shadow volume computation is cached in interactions table for each light+entity pair. It is recomputed only when at least one of them changes. Rendering shadow volume cannot be cached because it depends on camera too much. So with stencil shadows it is already good. Yeah, it is possible to skip shadow volumes computation for distant lights. In case of shadow maps, there is also some CPU filtering and actual rendering on GPU. CPU filtering is also cached and only recomputed on light or entity change, but on GPU shadow maps are rendered from scratch every frame. And this is not good: at the very least, static light which has static set of shadow casters should not have its shadow map recomputed every frame. Perhaps it is also good to have shadow map of static entities saved persistently, then every frame copy it and render only dynamic entities on top. I have this issue in my mind for some time already. There are some issues here, since shadow maps which are not recomputed must not change their location in shadow map atlas, and thus they can block other shadow maps from taking proper space (basically, typical memory allocation issues). Also if we try caching only static portion of shadow map, then we have to create another shadow atlas for them, which raises memory requirements dramatically. Right now it is not possible to skip anything for shadow maps at all. It might become possible after I implement reusing shadow maps in static cases. Overall, I can't say I like this idea. Even if light is distant, it is still ugly when shadow does not move in sync with shadow caster. But shadow maps should definitely be optimized for static cases.

Does anyone know how to create x-ray screens? In the x-ray demo they work, but when I try to create them myself they either don't work, or only show entities. The lamp has no x-ray spawnargm the rat has skin_xray: visible. If I set it to invisible it doesn't show, so that's good, but the background and light doesn't show. The otheer side of the screen is set to texture milky glass. Edit: This is solved. Xray screens need to be an entity (for example func static). Wiki page is updated with info.

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

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

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." }

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!

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

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

This may have been discussed long ago on Discord and I since forgot the details. It's an option that seems so simple and effective it kept itching me to ask in more detail. The latest dev version increases performance by +20 FPS which has me excited to know more on what seems like it could be a final huge optimization. At the moment we have view frustum and visportal culling but no form of occlusion culling. I wonder how much FPS we'd gain if we also used world geometry to derender what the player can't see. Would it be worth the effort to add this even as a hidden setting to experiment with? Given it was never attempted in all those years (to my knowledge) I imagine there's a reason and I may be excited for nothing, I'm sure @stgatilov and other devs can offer more insight but I'm happy to hear what anyone thinks. Here's my exact proposal: Occlusion culling would be done after portal culling (which wouldn't change in any form) ensuring only entities and geometry in the same room are compared. Only world geometry (solid brushes) are used to mask: A counter-argument was that calculating this mask will be costly... world geometry is almost always very simple, checking a few boxes should cost almost nothing compared to the gain of hiding every light / model / portal behind any wall. We can probably iterate through all world surfaces facing the camera within a distance limit if necessary, then use the resulting rectangles to preform the same overlap calculation as portal faces but in reverse (they close behind them instead of opening); Especially now that we have entity scissors and efficient 2D detection of 3D projections this could be huge My reasoning is no matter how well you portal your map, you'll always have many entities hidden behind a wall but not a portal, the engine still renders so much stuff you can't see: To even try getting close to this level of efficiency, every single edge and corner would need to radiate portals in each complementary direction, an impossible nightmare for the mapper to even attempt which would destroy dmap if they tried (I got close with limited success). Visportals will always be the simplest and most effective form of culling, but they're ultimately markers to separate rooms and represent openings thus can't cover all situations: If on top of that we also masked by world brushes the gains could be remarkable.

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

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!

Hi, I need to know what the code is to use Spoiler Tags. I am using my tablet and I don't have the options to use anything, like spoiler tags, quote tags, text changes etc. Thanks

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:

I tried not to get too ambitious with my first map. If I can figure out how to flag entities for spawning on triggers, I might work that into a Version 2. In hindsight, putting the tavern beyond the theater so you can't encounter it before reaching the target building might have been wiser, but I think I'll chalk this up to a learning experience for now. He shouldn't, perhaps I didn't edit his listening acuity spawnarg correctly. I'll have to look into that.

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.