Frost_Salamander

I couldn't get the commoner to open the door directly either - and I admit I didn't actually test that on this map. What I was trying to say was if the commoner didn't have a path to the controller he would try to open it directly. But he does have a path to it in this case which is why it works. What I missed was that even though the door was locked, technically the path is still there. So, I think in real (as in mapping) scenario you'd always have a path between the door and the controller because obviously whoever opened the door would need to be able to travel to it after they handled the controller. So basically my imagined scenario doesn't make any sense. So maybe it's OK? If so, a Wiki entry on the doors page warning of this behavior and how to solve it would do the trick I think. You said it worked for secret doors as well - what did you do there just put the door handling entity on both sides of the door? In my map I used the func_aas_obstacle and that worked for this. Not sure what the better solution is.

For my scenarios, the answer is yes. But surely there might be others where you'd want to be able to do both, like in real life (e.g. my flimsy wooden door example). This is why the mapper needs total control of this ability. Maybe we should just treat is as a new feature request? You're right in that those other solutions have their reasons for existing, and I don't have a problem with them really because they are meant to solve different issues (although the bit with the AI not being able to go through the door after it's opened needs fixing).

nice - new thread here with download link:

Hi everyone! I have a fan mission ready for beta test if anyone is interested in helping out. It's a standalone city mission unrelated to the Hare in the Snare (which is on hold indefinitely). I will start a beta testing thread once I get a few replies. Thanks!

If you use a door handling position entity it stops the AI from using a controller as well. This makes sense in a way, as you are basically saying 'don't enter the door from that direction'. My requirement is different - I want to be able to say 'only open the door using the mechanism I want to be used'. If I have a gate that is 20 feet tall and weighs a ton, nobody is going to be opening it by touching it. I've attached a test map to illustrate. A guard sees you behind a gate that he should be able to open with a lever. However he can't because I've had to put a door handling position entity in front of it to stop the commoner AI from being able to open it. If you take away the door handling position, the guard will able to open the gate, but then you get the commoner able to open it with his magic hands. The other nuance here is that the commoner can't get to the controller because it's behind a locked door that only the guard can operate because it's his station and not open to the public. It's a perfectly reasonable setup. aidoors.map

So I just tested this, and it stops the fleeing AI from opening the door, but he still won't walk through it after it's been opened. Other AI do though (for example a guard chasing me did go through it). Not the end of the world but still strange. Yes I remember and thanks. I wasn't too enthusiastic about it because I don't like the default behavior and these all seem like workarounds. I had made a mental note to try it if nothing else worked though. Maybe there is a good reason for not calling this a bug, or not changing it but I'm not sure what it is. Fear of breaking existing missions maybe? Anyways, I'll put something in the Wiki about it once I'm 100% sure about what's going on here. thanks @Obsttorte for looking into this.

perhaps, but do we agree it probably should be up to the mapper though? In one of my scenarios, the 'door' is actually one of those large iron gates that slides upwards. The AI shouldn't be able to open it without some sort of mechanical assistance. But yeah, if we're talking about a flimsy wooden door then sure why not.

I was just about to report back and say that func_aas_obstacle is a good workaround, but that's not the case (yet anyways). For some reason that I can't figure out, it worked fine for the 'secret door' scenario, but gets totally ignored in the 'lever door' scenario. Ignored as in they still open the door and walk right through the obstacle. I'm not asking for help, we'll need a proper test map and everything for that and I'll make one if I get around to it. It must be something to do with the positioning of the obstacles, because they behave as expected if I put them in a difference place. The wiki is very light on information about this subject, but I updated it to mention the texture you need to use for it. That wasn't mentioned previously and I couldn't figure out why it wasn't working until I looked at the elevator prefab: https://wiki.thedarkmod.com/index.php?title=Pathfinding#Dynamic_blocking.2Fclipping_with_func_aas_obstacle. Other than the weirdness I mentioned above, it works as you'd expect. Also, I can confirm that non-fleeing AI (i.e. guards) will operate non-frobable doors as well. They do this if they are chasing you and can't reach the lever.

Thanks - I only asked because I know you are frequently updating the Wiki - I can do it otherwise but wanted to make sure I was understanding it correctly I think for the 'ai_should_not_handle' problem I am going to try the func_aas_obstacle. I could leave it as is with the AI refusing to go into it, but I don't like that and it looks silly. Also, I don't get why 'ai_should_not_handle' blocks off the pathing instead of just preventing the AI from using the door - perhaps there is some technical reason but it seems like a weird way to do it. If we wanted to stop AI from pathing somewhere we can just use monsterclip.

I think so. Obsttorte seemed to think that 'frobable' didn't apply to AI, but maybe we need to wait for him to look into the code to see if that is the case or not. Also I don't think I've ever seen non-fleeing AI use non-frobable doors, but I can't say I am 100% certain they can't. If you are planning a Wiki update, can you change this sentence: "You may have a controller on only one side of the door" To this: "Let's say you have a controller on only one side of the door" (or similar) Up until this very moment, I thought it was trying to say you can only have a controller on one side of the door, which is obviously nonsense. I think it's just citing an example scenario - is that correct?

Yeah, I mean there will be workarounds but they all seem like hacks. In my example, I want AI to be able to get through the door once it's been opened. I was going to say, I can't believe nobody has run into this before...

Issue raised: https://bugs.thedarkmod.com/view.php?id=6005

OK so I'm not going crazy I was trying to think of why we might actually want this or if it was somehow by design, but I'm struggling. The only thing I can think of is if you wanted the AI to 'know' about the secret door (perhaps because it's in their house)? But again, I think you'd just want them to use a controller like the player would?

So here's what I have: non-frobable door with a controller the controller is not reachable by the commoner AI With that setup: now alert the commoner AI the commoner runs up the door and opens it without using the controller If my setup is wrong, I don't know what it could be.

Try it with a fleeing AI - like a commoner. Not sure if you saw my last reply but I explained a bit more there....

But why? if the door is closed, the AI shouldn't be able to walk through it. If it's open, it should be able to walk through it. Why do we need anything else in this particular case? What I mean by 'frob' with AI is them walking up to the door and opening it as if it was frobable. If 'frobable' doesn't apply to AI that would explain the whole problem. However this line in the wiki might need to be updated: "You may have a controller on only one side of the door. Note that, since the door is not frobable, the player and the AIs won't be able to operate the door from the non-controller side, even if that side has a door_handling_position entity" Actually, everything works correctly with regards to the door controllers, except for fleeing AI. If I alert a guard, they will use the controller to open the door. I've never seen them open the door without using the controller. It's only the fleeing AI that do this. Maybe there is an issue there?

If the AI won't recognize it if AI_USE_DOOR isn't set, why do you need a func_aas_obstacle entity? I get that triggering it off would allow the AI to walk through it after it's been opened. Or are you saying forget about the spawnargs and just rely on the func_aas_obstacle? I want the AI to be able to use the lever door, just not by frobbing it. That's why I have 'frobable' set to '0'. However this gets ignored by fleeing AI. In the scenarios I listed above, both doors are being opened by fleeing AI by frobbing them, which shouldn't happen. This is why I was asking if 'ai_should_not_handle' is the right way to do it (which doesn't seem to be the case). In short, this is what I think the game should do: If a door is marked as non-frobable, the AI shouldn't be able to open it by frobbing it. If a door is marked as non-frobable and has a controller, the AI should only be able to open it by using the controller (if they can reach it).

I didn't realise this until very recently, but AI can open doors when they're not frobable. They do this when their alert level is raised. For example if it's an unarmed AI and they see you and start running away. What's the best way to prevent this? I've tried "ai_should_not_handle" but there are issues with that. I have 2 scenarios: A door controlled by a lever. If I set ai_should_not_handle on the door, the AI won't use the lever to open it either. Fine for unarmed AI, but not for guards, etc. a secret door controlled by a trigger that I only ever want the player to be able to open. If I set ai_should_not_handle on that, the AI won't open it (good) but they won't walk through it when they are chasing you (bad). Again, fine for unarmed AI but not for guards. Is there another way to do this? Also, if this is the default behavior it feels like a bug.

Yes thanks for that. I didn't realize the glass materials were 2-sided. I've changed the windows in my WIP FM to patches instead now. In the test map, 3 of the windows are brushes, but the last one (on the far right) is a patch.

Isn't that in the latest dev build though (which is what I'm using for the TDM install that I'm running @duzenko's exe from)? Also his download included a 'glprogs' folder that I also copied into my TDM installation...

Sorry finally got around to trying this - it still looks like this: https://forums.thedarkmod.com/index.php?/topic/21477-water-effects-not-rendered-through-warp-glass/&do=findComment&comment=475732

When I tried your .exe, I got this: https://forums.thedarkmod.com/index.php?/topic/21477-water-effects-not-rendered-through-warp-glass/&do=findComment&comment=475732 You also suggested trying the 'latest development build'. I asked if that can be obtained using tdm_installer, and you said 'yes'. That's what I reported here: https://forums.thedarkmod.com/index.php?/topic/21477-water-effects-not-rendered-through-warp-glass/&do=findComment&comment=475856 So - I am probably doing something wrong but not sure what

So just tried with latest dev version and it looks the same as 2.10. That is, still can't see the water through warp glass. I tried both the test map (render.map) and my current WIP map. The console says my version is 2.11/64 #9944

Will do - I can get that from tdm_installer right?