Jnon

As you suspected, activating g_lightQuotientAlgo 0 makes AI notice missing objects again. Whatever the issue is, it seems tied to the new light estimate system.

Any time you can spare would be greatly appreciated. Thank you both. I've created a post with more detailed information in the Beta Testing forum here:

Hello again. I haven't posted much in the last year or so, mostly because I've been busy working on a new FM (one that's occupied all my time since almost immediately after "The Threepenny Revue"), and it's finally in a state where I want some outside help in playtesting and bug-hunting. This is a significantly larger map than my first outing, and as such I'm sure there's plenty of rough edges that still need sanding off. If anybody's willing to help out, please reply here and I'll make a thread in the Beta Testing subforum afterwards. Thanks.

Bug Report created, and can be found here: https://bugs.thedarkmod.com/view.php?id=6623

I retried, setting the loot object to absence_noticeability 1 and absence_alert_increase 23 (which should be "agitated searching") and still get zero reaction from patrolling AI, so bug report it shall be

I tried removing absence_alert and adding absence_alert_increase at various levels, but there was no change in behavior. v2.12 AI go to alert, v2.13 AI do not. It might be anecdotal, but I felt that the AI in v2.12 were more sensitive to getting alert than v2.13. Guards in the latter just commented on footstep sounds in the same room, whereas the former actually came to look around and investigate.

If I understand this bug correctly, adding the absence_alert spawnarg causes the entire absence alert to stop working. I'm not seeing that behavior here. I have absence_noticeability 1, absence_alert 10 set on this loot item, and the patrolling AI successfully enters alert when the map is run in TDM v2.12, but does not enter alert at all in TDM v2.13 I did notice this note in the bugtracker which suggests absence_alert_increase instead of absence_alert as a spawnarg, but this was noted back in 2022... if this were the case, that'd be reflected in v2.12, yet absence_alert still seems to function fine. Unless the proposed change never got worked in until just now. In either case, I'll try putting absence_alert_increase in the v2.13 map and see if that changes anything.

Okay, I installed v2.12 and copy-pasted the map files from my 2.13 /fms/ folder. No modifications or changes. In v2.13, the AI ignores the stolen loot item. In v2.12, the AI is alerted as expected. Based on this, I can only conclude that something in 2.13 has changed with the absence_noticeability spawnarg, or else something else is borked. Nothing gets output in TDM's console that I can see, if there are other logs I can pull to troubleshoot I can try to provide them. I would be interested to see if this can be replicated by other people. v2.13 only came out very recently, has anybody tried playing a map with absence_noticeability in it, or creating one and testing it? Also, would be this a good candidate for a report on the DarkMod bug tracker?

I almost forgot the installer lets you pick older versions... I'm installing 2.12 now, I'll report if there's any difference. There's no issue with running a map made in latest DarkRadiant on an older version of TDM, is there?

Just to follow up on this, in case anybody has similar problems in DarkRadiant and needs to troubleshoot, I found several other instances of massive framerate drops. While I originally thought they were caused by AI trying to navigate busy terrain, I found that in almost every instance so far they're caused by vocal alerts from AI being heard by other AI on the far sides of doors, which they could not traverse (either because of locks and keys, because of monsterclip, or because of ai_should_not_handle flags). The AI trying to run and investigate the suspicious area could not pathfind to it, and the game suffered sharp lag because of it. I found an easy fix for this was to use sound_loss on the infoLocationSeperator for visportals on doors causing problems. I set them to 60, which made it impossible for AI on the far side of the door to hear anything. So far, this has reliably fixed all my framerate drop troubles.

During testing of a map, I've noticed that objects I had previously flagged with "absence_noticeability" spawnargs are no longer altering AI when stolen/removed. I had four separate items in my map that, in previous test runs, had always alerted NPCs when stolen and subsequently noticed. Now, these same objects (unchanged in any way since the last time they were tested) suddenly no longer function. They are in the same positions, they are well lit, they should be triggering suspicion, but they no longer do. I recently upgraded TDM to v2.13, I'm not certain if this had any influence on anything. My DarkRadiant version is 3.9.2 amd64 on Ubuntu, which I believe is latest. Has anything changed about the absence_noticeability system? And if not, what would be the best way to go about troubleshooting this?

From what I could tell, ai_should_not_handle prevents the AI from ever trying to open the door and prevents it from considering the area behind it traversible, so long as the door remains closed. If it's ever opened (by the player) they are then able to pathfind through it. Monsterclip would be a permanent invisible wall for them, even if the door were opened. Based on my last round of tests, even when alerted they couldn't open the door or go through it. There was some odd behaviour where they milled around in front of the door as though they wanted to go through it, but they never actually tried.

Actually, I take it back. ai_should_not_handle on a few key doors is a much better solution. Inside guards stay inside, outside guards stay outside. Doesn't make sense for the City Watch to burst into a manor house uninvited just because they think they saw a thief on the ledge outside after all.

Unfortunately, this would block all the AI, and there are some I'd like to still be allowed through. I assume this would also block all AI and not just those without keys or a can_unlock flag... Thank you for the suggestions. For the time being, I'm going to just give all AI in the same area as that door the "can_unlock" flag and hope nobody from too far away gets kited into that area. I assume what's happening is that the AI wants to get to the other side of the door, can't, and tries to map alternate paths to get inside which ends up scouring the entire "outdoor" area (one large zone for the entire map not including visportaled/location boundaried "indoor" areas) which taxes system resources. In future I'll make sure to read the fine manual before I sink six months into a map

I'm doing the final passes on a map I'm working on, but I've encountered a behaviour that I'm not sure how to deal with. Whenever AI try to pathfind through locked doors they can't open (for example fleeing to a flee_point, guards searching after spotting the player) my framerate drops dramatically. I can usually get a pretty consistent 50-60 fps, sometimes small dips to 30-40 when looking at complex/distant areas, but when the pathfinding problem happens the framerate drops down to 10 or 11, noticeably slowing gameplay. The framerate dips are temporary, and usually end when the AI either stops trying to go through a locked door or just gives up and returns to patrol. This is generally happening in the "outdoor" part of my map. I admit I've made a cardinal error in not properly optimizing the outdoor areas as per best practices (visportals and dividing areas into blocks with curved entrances etc), but the map runs just find when AI are on their regular patrol routes. Only when they're trying to get through a door they can't open do I have problems. I would have thought the AI wouldn't even try to pathfind through a locked door, but in any case... is there anything I can do to address this? Any flags I can put on doors or visportals to discourage AI from even attempting to go through doors they aren't supposed to?

For now, I've settled to swapping the unarmed NPC for an armed one. If his default reaction to the player is Combat, everything seems to work normally (he actually pathfinds his way through the door to chase the player easily this way). Thanks for the advice, maybe I'll puzzle this out later.

I tried snapping visportals to grid, and I changed rotation on the door in spawnargs (changing physical position of the door would be very difficult as it would block off the passage based on the layout right now). This seems to have partially solved the problem... if the door opens outwards instead of inwards, the NPC can now sometimes handle the door and escape as expected. If he's panicked while in close proximity to the door, he escapes just fine, though he does have the odd behavior of walking calmly to the door, opening it, stepping outside, and then running to escape. However, if I panic him while he's far away from the door, he starts running, then gets stuck on the door as before. Something about the Flee state seems to make him stop recognizing doors. tdm_ai_debug_blocked was a little helpful. He seems to count as NotBlocked while he's running into the door, but it briefly switches to "PossiblyBlocked" before going back to NotBlocked. Occasionally the door gets framed in red, but also it frames a couple of spots outside that seem unrelated. Red outlines appear very briefly, though, and vanish after only a moment. The main state seems to be 90% "NotBlocked", with 10% flickering briefly into "PossiblyBlocked". I'm starting to think I should just remove the NPC completely.. I must have done something weird with the brushes in the area that makes the AI freak out when trying to navigate it in Flee mode.

Using this yields interesting results. If I place a path_corner outside, the NPC navigates with no difficult. Movement to Path Corner, followed by HandleDoor to open and close behind him, then the same again if he goes back in. However, if I panic him while he's inside, he goes to Flee mode, with his target set as the expected Flee Point... however, he never enters a HandleDoor state, so keeps bumping into the door. For pathfinding, he's acting like the door isn't there, but for collision purposes it is, so he can't move. Even more interesting, under certain conditions (not sure yet which) if I try opening the door for him mid-Flee, the door remains stuck in the open position. It remains frobbable, and the door handle rotates when I click on it, but it no longer closes. I still need to narrow down what circumstances trigger this, though. EDIT: if I leave him stuck long enough, he eventually enters "Resolve Movement Block" state, but never resolves it, and rotates back to "Flee Task" EDIT 2: Even weirder, if I leave his stuck like this, then open the door, the door opens but the visportal (sometimes) ignores the door open state, and blocks rendering of the area outside.

I actually do have a Path Flee Point set outside the basement he's in, which he seems to want to flee to. The door is just standing in his way, and he refuses to open it while fleeing. Interestingly, if I open the door for him while he's fleeing, he then passes through it and runs to the flee point as expected. The door, and the act of opening it, seems to be the major issue. I seem to recall reading that there was a Door Open Point path somewhere in the editor? Or am I misremembering that.

I'm working on a map right now, and I'm having a problem with fleeing NPCs going through doors. NPCs following path_corners have no difficulty navigating the walkmesh and opening/closing doors. However, once they spot the player (and aren't armed) they can't open a door to save their life. They flee, but they ignore doors, just running in place, face-first into the door. I'm not certain how to address this behavior, since they obviously can handle doors under normal circumstances. Is there a type of path to help guide fleeing NPCs? Or is there something else I could do to troubleshoot this?

I'll give this a shot, that sounds like it might work.

I have a room in a building that's guarded by a fire elemental. For lore and bug reasons, I want the fire elemental to be bound to that room... as in, there are exits to the room but the fire elemental cannot leave it. If I use monsterclip I can confine him to the room, but of course this also blocks other NPCs from being able to enter or exit. Is there a way to selectively block AAS elemental to keep the fire elemental stuck to that room without interfering with other AI?

It's instinct at this point... as soon as I saw it opened up into the second floor, I knew it was the best access option. Normal inhabitants might use the stairs, but they'd never go up the chimney. I felt pretty clever and comfortable, until the wizard teleported right in front of me, lol

Took me a while to get to this, but I had fun with this map. When I first loaded it up I thought "this looks like a pretty small location, probably clean it out quickly and leave". Then the wizard teleported into the room and I had to panic-flee down the chimney. Really caught me by surprise, well done. The custom skybox was nice, and I was really impressed with the magic orb mini-universe platforming section... the only time I remember seeing something similar was in The Painter's Wife, with the pixie terrarium in the wizard tower. I really need to load that up in DR and see how that's done, because I want to try it myself. Nice work!

I have no idea how I could spend 20 minutes scouring a room, knowing exactly what I'm looking for, and still miss it. Thank you.