Jump to content
The Dark Mod Forums

AIUSE_DOOR broken?


fllood

Recommended Posts

Use case is: AI should take notice of some doors and open chests.

 

Testing doors with property hash "shouldBeClosed" value "1" to alert AI for doors and chests that aren't closed by the player do fail to trigger as long as a door is placed in a shadowed area. Only when you light a door the flag do properly tigger. I tested with a female AI: atdm:ai_guard_female_rogue and atdm:ai_pagan_common_armed. Both behave the same to AIUSE_DOOR .

 

Testing with a chest on the atdm:mover_door: No AI reactions if the chest is in a fully shadowed area like with the doors. If slightly or fully lit behaviour is different regarding which AI is used: While the pagan AI do notice the open chest, close the mover_door and goes for a search as expected the female AI does not take notice of the open chest at all even if fully lit.

 

Talked to Sotha and he think that certainly is a bug.

 

Please can you guys double check if AIUSE_DOOR is broken?

"To rush is without doubt the most important enemy of joy" ~ Thieves Saying

Link to comment
Share on other sites

AI can't see doors, bodies or anything else if it isn't lit.

 

Not sure why the female AI would not take notice of it...what team is she on?

Link to comment
Share on other sites

AI can't see doors, bodies or anything else if it isn't lit.

 

It's by design, I see. Thanks.

 

In my opinion that doesn't make much sense though. It's very unrealisitic if an AI don't notice that a unlit door is open it knows it should be closed. Also it limit reasonable usability for mappers setting this AIUSE arg for gameplay.

Probably something to think about to change?

 

Not sure why the female AI would not take notice of it...what team is she on?

 

She is in a different team (team 4)

 

Maybe that (very old) issue bring some idea back to mind?

"To rush is without doubt the most important enemy of joy" ~ Thieves Saying

Link to comment
Share on other sites

The AI should certainly spot, even in the darkness, that the door is left open if he is using it.

 

I got the impression that AI walks through a open door which should be closed without noticing that the door was left open if the door is in darkness. That's kind of silly.

 

It is entirely different matter if the AI is not using the door portalway, but just walks by: then it is okay if the AI does not spot the open door. But he should realize the door is open if he is using it, even if it is dark there.

Clipper

-The mapper's best friend.

Link to comment
Share on other sites

Just to clarify: The design goes along these lines:

 

* If something is in darkness, the AI can't see it. So they won't react to it.

* The level of darkness means that the more light is, the higher the chance is, that the AI notices something.

* The AI must look towards an object to see it, and they have some narrow vision cones, so they might not even see a chest on the floor when they look straight ahead.

* Yes, if the AI tries to use something, it should notice that the door is open. However, "must_be_closed" for doors usually means the door is either locked, or not used by AI, so the AI should technical never use the door - until they spotted the player f.i. and followed him through the very door. Otherwise (the AI uses this door regularly in a patrol) the other AIs would all go haywire when they see the door closing just because one of them went through:)

 

That all means the AI might walk by a dimly lit chest/door several times before noticing it.

 

There might be bugs in this, but you'd need to build a testmap with controlled conditions to see if this works as designed, or not.

 

As for the "use case", yes, they definitely should distinguish between "I am not seeing the door, but using it". As for the pagan, it might be because he is a commoner with a weapon, but I am not sure if these have different behaviour from a guard.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

they have some narrow vision cones, so they might not even see a chest on the floor when they look straight ahead.

 

The rest of what you say is true, but no AI have vision cones narrow enough that they can't see the floor right in front of them (unless something has been messed up since I set them).

Link to comment
Share on other sites

The rest of what you say is true, but no AI have vision cones narrow enough that they can't see the floor right in front of them (unless something has been messed up since I set them).

 

I was more thinking a chest by the side, not one they approach. Do we have a drawing (or could produce) to which extend the AI can see the A: floor, B: something 20cm high, something 50cm high etc? while they walk and look straight ahead?

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

There's a spawnarg to turn on their vision cone but I forget what it is off the top of my head.

Link to comment
Share on other sites

There's a spawnarg to turn on their vision cone but I forget what it is off the top of my head.

 

It is tdm_ai_showfov but this shows a line drawing of the cone, which is rather hard to see in 3D what it really hits and how far it extends. I had hoped for some sort of "flashlight" display where you see a projected light cone hitting the area, to see what the AI actually "hits" with his eyes.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Good to know Tels. :)

 

Thank you guys for looking into this!

 

So ... in most situation the property won't do the trick I want and disussed without odd AI behaviour :mellow:

 

I made some more tests with a chest (chest_wood.pfb)

 

1) One light in line of sight doesn't trigger the alert state of the female AI for the open chect (light entity has brightness 100, radius 100, 40 units away). A second light set further to the back finally triggers the female AI :-) but strangly sometime now not for the male AI.

Do the AI have different awareness levels for light / line-of-sight? or may it be about the head movement?

 

2) But what really breaks AIUSE_DOOR for my use case: If the chest is closed the female AI now opens it (why?) and as soon AI does the spawnarg triggers the alert state of the AI by increasing 18 points. This make it a self-alerting intelligence ;)

The same self-alert if true for a fully lit closed door marked "shouldBeClosed" within AI path.

 

(see details in spoiler for AI path and lightning)

 

 

 

shouldBeClosed-1.jpg

 

 

 

shouldBeClosed-3.jpg

 

 

 

shouldBeClosed-5.jpg

 

 

This makes the spawnarg rather pointless to set for gameplay to AI's to react on chests and doors left open by the player.

Edited by fllood

"To rush is without doubt the most important enemy of joy" ~ Thieves Saying

Link to comment
Share on other sites

Yes, as mentioned earlier the spawnarg is not working perfectly and alerts AI regardless of who opened the door. It does work fine for safes and other doors that AI don't generally open, however.

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.

  • Recent Status Updates

    • OrbWeaver

      Finally got round to publishing a tutorial on baking normal maps in Blender, since most of the ones we have are inaccessible or years out of date.
      · 0 replies
    • nbohr1more

      The FAQ wiki is almost a proper FAQ now. Probably need to spin-off a bunch of the "remedies" for playing older TDM versions into their own article.
      · 1 reply
    • nbohr1more

      Was checking out old translation packs and decided to fire up TDM 1.07. Rightful Property with sub-20 FPS areas yay! ( same areas run at 180FPS with cranked eye candy on 2.12 )
      · 3 replies
    • taffernicus

      i am so euphoric to see new FMs keep coming out and I am keen to try it out in my leisure time, then suddenly my PC is spouting a couple of S.M.A.R.T errors...
      tbf i cannot afford myself to miss my network emulator image file&progress, important ebooks, hyper-v checkpoint & hyper-v export and the precious thief & TDM gamesaves. Don't fall yourself into & lay your hands on crappy SSD
       
      · 7 replies
    • OrbWeaver

      Does anyone actually use the Normalise button in the Surface inspector? Even after looking at the code I'm not quite sure what it's for.
      · 7 replies
×
×
  • Create New...