Jump to content

Frost_Salamander

Member
  • Posts

    473
  • Joined

  • Last visited

  • Days Won

    9

Everything posted by Frost_Salamander

  1. 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.
  2. 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?
  3. 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...
  4. Issue raised: https://bugs.thedarkmod.com/view.php?id=6005
  5. 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?
  6. 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.
  7. Try it with a fleeing AI - like a commoner. Not sure if you saw my last reply but I explained a bit more there....
  8. 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?
  9. 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).
  10. 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.
  11. 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.
  12. 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...
  13. 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
  14. 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
  15. 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
  16. Is it supposed to be all black like this? Anyways, I can kind of see that it's working (this is the warp window I'm looking through here)
  17. That worked. Now, what do I do with this? Move it all to my TDM folder and run it?
  18. Is it because you are signed in to your Google account?
  19. @duzenko I get a 403 when I try to download that - permissions need tweaking?
  20. I got the trigger_look working, but with a couple of problems: The trigger will activate as soon as I get close to the entity even if I'm walking backwards towards it (i.e. not even looking at it). The 'once' spawnarg doesn't appear to work as expected. I'm triggering a script with this via a atdm:target_callscriptfunction entity, and it fires a second time even though I've set the spawnarg 'once' to '1' on the entity with the trigger_look scriptobject. I am able to stop this using a global flag in my script, but that's a hack if this functionality is available in the script object. UPDATE: It seems to work OK with ai_trigger_look. It doesn't fire multiple times or fire when I'm not looking at the AI. The issues seem to be with 'trigger_look' only. UPDATE 2: I'm an idiot - I just realised that tol_angle is 'tolerance', and the page describes what it means. I put in a value of 90 just to make it work which is is obviously totally inappropriate, so I think it's why it was triggering while I was looking away from it.
  21. OK that makes more sense. I'll update the article accordingly. The reason it didn't work when I tried to include it is because I named my script file wrong (tdm_custom_script.script instead of tdm_custom_scripts.script) One more thing though, the article says: what is 'tol_angle' for? I'm guessing that 'tol_distance' is the same as 'distance' in 'trigger_look' in that it's max distance? it says these are 'parameters', but practically speaking does that mean spawnargs on the AI?
  22. I didn't, no. The article doesn't say you need to. It says to add the spawnarg, and then 'that's it'. Also, the 'trigger_look' and 'ai_trigger_look' are both distributed with TDM (in tdm_base01.pk4\script) - why do I have to include it anywhere? The article says: This makes me think one used to have to do that, but not anymore? I get the same error if I try this on an AI with 'ai_trigger_look' as well. I even tried including it in my FM scripts/ folder along with the include statement. Same error.
  23. I'm trying to play around with the 'trigger_look' functionality described here: https://wiki.thedarkmod.com/index.php?title=Triggering_events_when_looking_at_something The page says: however when I do just that, on map start I get the following error: "Script object 'trigger_look' not found on entity <entity name>". Also, the page goes on to say if you want to use this with an AI, then to "merge trigger_look functions with the AI's script object" and gives an example to download. It also says "See also in the TMD distribution: tdm_base01/script/ai_trigger_look.script". Does this mean we can just set the scriptobject on the AI to "ai_trigger_look" instead of "trigger_look", or do we have to write our own 'merged' script object? It's not clear from that page.
×
×
  • Create New...