Jump to content
The Dark Mod Forums

Newbie DarkRadiant Questions


demagogue
 Share

Recommended Posts

22 minutes ago, Obsttorte said:

Yeah, the formulation is misleading. You don't need to ship the script with your fm as it is now part of the core mod, but still need to include it.

Well, it works fine on my end. Here are the steps:

  • Create a folder script in your fm folder
  • in that folder, create a file tdm_custom_scripts.script
  • in that file, add the line
#include "script/ai_trigger_look.script"
#include "script/trigger_look.script"

That's it.

It is not included by default as some missions released before it was added to the core mod may have already used the script.

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:

Quote

Because of naming conflicts, instead of "tolerance" and "distance", you must specify these parameters (which have no defaults):

  • tol_angle
  • tol_distance
  • 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?
Edited by Frost_Salamander
Link to comment
Share on other sites

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.

Edited by Frost_Salamander
Link to comment
Share on other sites

  • 3 weeks later...

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:

  1. 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.
  2. 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.

Edited by Frost_Salamander
Link to comment
Share on other sites

I think door handling position entities give you some more control over how and from which side AIs can interact with a door. But it is a tricky scenario.

Link to comment
Share on other sites

10 hours ago, Frost_Salamander said:

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:

  1. 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.
  2. 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.

For an ai to be able to operate a door they need to know that it is one. This is mainly controlled by AI_USE. If it is not set to AI_USE_DOOR, the ai will probably not recognize it. If you want the ai to walk through a secret door after it has been opened (assuming you set it up so the ai doesn't know it is a door), you would have to let the secret door or the switch opening it trigger a func_aas_obstacle entity.

You can check here as well as in the elevator prefab to see how it works.

10 hours ago, Frost_Salamander said:

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.

I don't understand that. Either you want the ai to operate the door or not. If you set it to don't operate, why should it operate the lever that operates the door?

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

50 minutes ago, Obsttorte said:

For an ai to be able to operate a door they need to know that it is one. This is mainly controlled by AI_USE. If it is not set to AI_USE_DOOR, the ai will probably not recognize it. If you want the ai to walk through a secret door after it has been opened (assuming you set it up so the ai doesn't know it is a door), you would have to let the secret door or the switch opening it trigger a func_aas_obstacle entity.

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?

 

52 minutes ago, Obsttorte said:

I don't understand that. Either you want the ai to operate the door or not. If you set it to don't operate, why should it operate the lever that operates the door?

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:

  1. If a door is marked as non-frobable, the AI shouldn't be able to open it by frobbing it.
  2. 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).
Link to comment
Share on other sites

36 minutes ago, Frost_Salamander said:

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?

You need something to tell the ai when it can pass the area blocked by the secret door and when not, similar to how you have to tell the ai when it can step into an elevator shaft or not. There are probably other ways to create the setup you want, but I would have to test it.

38 minutes ago, Frost_Salamander said:
  • 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).

First off, ai don't frob doors. That's what the player does. So the frobable spawnarg has no relevance to them I assume. By default, if a door is operated by a lever, the ai should automatically use the lever. If that is not the case, then probably something is wrong with your setup. Does the lever use the correct entity class?

Again, I would have to test it to be sure.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

There'd imo be some value in maintaining the AIUse setting of the door, since in my view it should be suspicious to an AI if they suddenly see a secret door ajar. It'd also permit them to escape if they're lured into the secret compartment and the player then shuts the door on them. I believe door handling position entities either side of the door give that kind of control.

The AAS obstacle entity is probably not necessary if going the AIUse route since the code already recognises door spawnclasses and generates dynamic monsterclip around them. AIUse is mostly for the benefit of the AI scripts and some code functions, if Im not mistaken.

Link to comment
Share on other sites

3 minutes ago, Obsttorte said:

You need something to tell the ai when it can pass the area blocked by the secret door and when not, similar to how you have to tell the ai when it can step into an elevator shaft or not.

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?  

 

5 minutes ago, Obsttorte said:

First off, ai don't frob doors. That's what the player does. So the frobable spawnarg has no relevance to them I assume. By default, if a door is operated by a lever, the ai should automatically use the lever. If that is not the case, then probably something is wrong with your setup. Does the lever use the correct entity class?

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? 

Link to comment
Share on other sites

@Frost_SalamanderI've just tested it with a mover_door and a switch_rotate_lever. It works exactly like you want it, without the necessity to change anything. So obviously your setup is wrong.

Correction, the default lever works, too. My bad.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

1 minute ago, Obsttorte said:

@Frost_SalamanderI've just tested it with a mover_door and a switch_rotate_lever. It works exactly like you want it, without the necessity to change anything. So obviously your setup is wrong. (Note: The default lever entity does not work with ai, but I don't know why. The spawnargs seem to be identical 🤔).

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

Link to comment
Share on other sites

1 minute ago, Frost_Salamander said:

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

I did, it works.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Just now, Obsttorte said:

I did, it works.

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.  

 

Link to comment
Share on other sites

Now I understand what you mean. I just tested and can second this. Well, that's obviously a bug. You should file a bugtracker. I will take a look at the weekend to see whether that's somewhat intented and fix it if not.

  • Thanks 1

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

1 minute ago, Obsttorte said:

Now I understand what you mean. I just tested and can second this. Well, that's obviously a bug. You should file a bugtracker. I will take a look at the weekend to see whether that's somewhat intented and fix it if not.

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?

Link to comment
Share on other sites

26 minutes ago, Obsttorte said:

Now I understand what you mean. I just tested and can second this. Well, that's obviously a bug. You should file a bugtracker. I will take a look at the weekend to see whether that's somewhat intented and fix it if not.

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

Link to comment
Share on other sites

I seem to remember struggling slightly with this issue in my map A House Call. If I remember right I just cheated a bit and prevented the commoner from going into the secret room by painting the area behind it with monsterclip.

{ 0 | 🞵 } = funk_tastic

My missions:           Stand-alone                                                      Duncan Lynch series                              

                                      Down and Out on Newford Road              the Factory Heist

                                                                                                  A House Call

                              

Link to comment
Share on other sites

12 minutes ago, thebigh said:

I seem to remember struggling slightly with this issue in my map A House Call. If I remember right I just cheated a bit and prevented the commoner from going into the secret room by painting the area behind it with monsterclip.

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

Link to comment
Share on other sites

3 hours ago, Frost_Salamander said:

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"

Just to understand, the outcome  of this discussion (and bugtracker post) so far is that:

- The wiki post is correct as is. "frobable" on the door IS considered by the AI. So if "frobable 0" and the door has a controller that accessible to the AI, the AI will use it.

- except if fleeing, and that is a bug.

Link to comment
Share on other sites

3 minutes ago, Geep said:

Just to understand, the outcome  of this discussion (and bugtracker post) so far is that:

- The wiki post is correct as is. "frobable" on the door IS considered by the AI. So if "frobable 0" and the door has a controller that accessible to the AI, the AI will use it.

- except if fleeing, and that is a bug.

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?

Link to comment
Share on other sites

3 minutes ago, Frost_Salamander said:

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?

Yes, I read it as just citing an example. But I'll change the wording to be less ambiguous.

Also, for

Quote

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.

I also would have thought that setting ai_should_not_handle on the secret door would still allow the AI to go through it if its open. But if not, and by design, then an easy workaround (once established) should be documented.

Link to comment
Share on other sites

1 minute ago, Geep said:

Yes, I read it as just citing an example. But I'll change the wording to be less ambiguous.

Also, for

I also would have thought that setting ai_should_not_handle on the secret door would still allow the AI to go through it if its open. But if not, and by design, then an easy workaround (once established) should be documented.

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.

Link to comment
Share on other sites

13 minutes ago, Frost_Salamander said:

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.

Agree with that, but I suppose there could be some backward compatibility issues if changing that behavior.

BTW: Wiki wording changed RE controller on just 1 side of door

Edited by Geep
  • Thanks 1
Link to comment
Share on other sites

5 hours ago, Frost_Salamander said:

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.

I thought so because I consider frob as an equivalent to "interacting with a highlighted object". That's a player specific thing, but I may think of the term wrong.

However, the ai in my test scenario uses the lever independent from whether the door is frobable or not, even if the door itself is closer to the ai then the frobable door, which underlines the assumption.

But as you wrote: without looking at the code that is more guessing then knowing.

9 hours ago, Frost_Salamander said:

Thanks. Will take a look this weekend.

  • Like 1

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share


  • Recent Status Updates

    • peter_spy

      What a lovely game, perfect way to relax before sleep.
      · 3 replies
    • STiFU

      Anyone here clocking in some times in Neon Light?
      · 0 replies
    • JackFarmer

      Boris Johnson's resignation does not change the fact that Australia is home to 29 million kangaroos and Wales has a population of just over three million.

      If the Australian kangaroos were to invade Wales, one resident would have to fight almost ten kangaroos at a time.
      · 8 replies
    • peter_spy

      Deathloop – what a mess of a game. I'd love to see a post-mortem on it some day. I hope Arkane is doing okay though.
      · 27 replies
    • OrbWeaver

      I like house-cleaning and taking out the trash.
      · 3 replies
×
×
  • Create New...