Jump to content
The Dark Mod Forums

AI alert level too high when noticing a stolen item


 Share

Recommended Posts

When you add absence_noticeability 1 to a loot item in DR, and you steal it in-game, the AI alert level immediately jumps up to 18.1, which is "agitated searching". If you add the absence_alert spawnarg, it does nothing, regardless of its value. Not sure what was the overall intention here, but the description of the absence_alert is incorrect then:

Clipboard01.png.f8ed6ce7a0a4daa333ab7bf10dc35383.png

Link to comment
Share on other sites

Thanks! I wonder how this one has gone unnoticed for so long (since 1.7, apparently 😮), or maybe it hasn't been thoroughly tested in the first place?

Anyway, a somewhat related question: was there a specific model you went after for alertness going down? It seems like it's different for some alert levels, e.g. it goes down very fast for "suspicious" and "observant", while it's very slow for "idle" (0-1.5): around 0.01 units/s, which seems like a very long cooldown.

Link to comment
Share on other sites

2 hours ago, peter_spy said:

Anyway, a somewhat related question: was there a specific model you went after for alertness going down? It seems like it's different for some alert levels, e.g. it goes down very fast for "suspicious" and "observant", while it's very slow for "idle" (0-1.5): around 0.01 units/s, which seems like a very long cooldown.

I didn't design it, but it seems to be governed by these AI spawnargs:

alert_time1	5
alert_time2	8
alert_time3	25
alert_time4	65

So it's meant to take 5s to go from alert1 to 0 - still need to factor in other things though, i.e. grace periods and that it takes 2s before alert level is allowed to go down again after an alert. Also need to consider that AIs that have reached a high alert level are not supposed to go below alert level 1 anymore, so they'll patrol with their weapon drawn.

Link to comment
Share on other sites

41 minutes ago, Dragofer said:

So it's meant to take 5s to go from alert1 to 0

It seems to be doing that, actually.

41 minutes ago, Dragofer said:

Also need to consider that AIs that have reached a high alert level are not supposed to go below alert level 1 anymore, so they'll patrol with their weapon drawn.

It seems like AI can go from level 4 or 5 to 0, it just plays the "agitated search" barks until it reaches Alert 0 on level 0, and it never puts away its weapon since. I thought the very slow cooldown for the 1.5-0 range might be there to add a little variation if player manages to alert the same AI second time in a row, in a time between alerts shorter than 3 minutes.

Anyway, thanks for digging that up, this is interesting :)

Edited by peter_spy
Link to comment
Share on other sites

@DragoferRegarding the bugtracker: It appears that the reason for the issue might be a typo.

if ( alert < ( owner->thresh_4 + 0.1f ) ) // it should be >
{
	alert = owner->thresh_4 + 0.1f; 
}

I guess this code is intented to be used as a cap. In addition, the part of the description stating that the ai goes into agitated searching if absence_alert isn't specified is not implemented. Maybe the above code was also intented to do that but got changed afterwards?!

Regarding your comment on the misinterpretation of the absence_alert spawnarg. The wiki explicitly states what it is intented to do and DarkRadiant explicitly states it to be a float, not a boolean. So either the fm authors who set that to 1 only wanted minor reactions which may accumulate, something we would break that if we use a new spawnarg instead, or they all suffer from dyslexie, which we hardly solve by introducing a new spawnarg. ;)

I would fix that so it does what it is intented to do but leave the spawnarg alone. If other members share your point of view that a new spawnarg should be introduced it can be easely changed afterwards.

Additionally we may consider modifying the description, as "If set, the alert increase of the AI when the entity is missing" sounds odd to begin with and may be the root for misinterpretation. I would suggest "Set the amount, by which the alert level of an AI increases, if it sees this entity missing."

EDIT: I've provided a fix with revision 9953 which can be tested in SVN. Feedback is welcome.

  • 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

2 hours ago, Obsttorte said:

I guess this code is intented to be used as a cap.

I don't think so, considering the accompanying comment in the code/bugtracker that said this line was meant to be a fix so that the AI immediately draws its weapon when an item is missing. It sounds like it's meant to force the AI to always become at least agitated, probably forgetting to consider the absence_alert spawnarg.

2 hours ago, Obsttorte said:

So either the fm authors who set that to 1 only wanted minor reactions which may accumulate, something we would break that if we use a new spawnarg instead, or they all suffer from dyslexie, which we hardly solve by introducing a new spawnarg.

An alert level increase of 1 isn't enough to make an AI reach even alert index of 1, and the player would have to steal something like 5 items in one go to get the AI to pause for a few seconds at alert index 2 before carrying on. It seems much more likely to me that the mapper didn't know the difference between alert level (0-23) and alert index (0-5), or interpreted it as a boolean after misunderstanding or misremembering the description. We would have to clarify the description in any case to better define "alert level".

The change was added in 2011, so most maps will probably have been created and tested with the "instant agitated" behaviour. The authors never saw how the AIs behave when they have a working, low-value "absence_alert" spawnarg, so there's a high potential for creating unexpected behaviour by retroactively fixing the spawnarg.

Link to comment
Share on other sites

27 minutes ago, Dragofer said:

I don't think so, considering the accompanying comment in the code/bugtracker that said this line was meant to be a fix so that the AI immediately draws its weapon when an item is missing. It sounds like it's meant to force the AI to always become at least agitated, probably forgetting to consider the absence_alert spawnarg.

Well, the bugtracker is about alerts spreading too fast among ai. I don't see any relation to the above code, to be honest. It is likely that it was changed afterwards. Nevertheless we don't want that behaviour anyways.

39 minutes ago, Dragofer said:

An alert level increase of 1 isn't enough to make an AI reach even alert index of 1, and the player would have to steal something like 5 items in one go to get the AI to pause for a few seconds at alert index 2 before carrying on. It seems much more likely to me that the mapper didn't know the difference between alert level (0-23) and alert index (0-5), or interpreted it as a boolean after misunderstanding or misremembering the description. We would have to clarify the description in any case to better define "alert level".

There are missions who used the spawnarg correctly, too. Although the ones pointed out by @stgatilov are rather high. So your suggestion may be the one doing the least harm, if any.

 

I would then introduce a new spawnarg as suggested by you. absence_alert_level_increase is probably quiet long, but at least descriptive. absence_scale as proposed by you on the bugtracker is shorter but counterintuitive, as a scale to me implies a multiplicative behaviour, not an additive. Thoughts?

  • 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

1 hour ago, Obsttorte said:

I would then introduce a new spawnarg as suggested by you. absence_alert_level_increase is probably quiet long, but at least descriptive. absence_scale as proposed by you on the bugtracker is shorter but counterintuitive, as a scale to me implies a multiplicative behaviour, not an additive. Thoughts?

Could go for absence_alert_increase as a compromise between length and descriptiveness, with this tooltip:

"The amount by which the AI's alert level increases when it notices this item is missing, up to 23. Defaults to 18 (agitated searching)."

The old spawnarg tooltip could be:

"Non-functional. Use absence_alert_increase instead."

  • Like 2
Link to comment
Share on other sites

I've made the necessary modifications. absence_alert_increase replaces absence_alert, the above posted code got reversed to its original state and commented out, as it is unclear what the intention was but is causing the unwanted behaviour.

The tooltips are as proposed by @Dragofer , in a modified form for absence_alert_increase:

The amount by which the AI's alert level (NOT alert index)
increases when it notices this item is missing. 
If not set the ai goes into agitated searching state.
  1. I added a mention of alert index, as mappers may not be aware of the difference and may misinterpret a value of 1 to get the ai from searching to agitated searching for example, which is NOT the case. Hopefully this will cause them to either look the terms up or ask in the forum if unsure.
  2. There is no cap in regards to how high the value can get. In addition point (3).
  3. The last line reflects the actual code better. The alert levels at which an AI changes from one stage to another aren't fixed values, but spawnargs. They are therefore subject to future changes in the core mod and modifyable by mappers.

I've marked the bugtracker entry as closed. Should there be remarks or issues I can make modifications nevertheless.

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

Thanks, but I'd still note that now the alert level is only modified if this condition is fulfilled:

if (stimSource->IsType(CAbsenceMarker::Type))

In my understanding the invisible absence marker entity left behind by a missing item is what actually alerts the AI, but the code foresees the possibility that another type of entity can also emit the "missing item" stim. In that case the alert level wouldn't change, whereas previously it would always get set to "agitated searching".

Also, if no "absence_alert_increase" is set, the alert level is set to "agitated searching" even if it's already higher than that. I don't think it's right that an AI should become less alerted in this case.

My suggested structure would be this:

  1. initialise the "alert" local variable
  2. if the alert variable is lower than "agitated searching", raise it to "agitated searching
  3. check whether the stim source is an absence marker. If yes, and it has the "absence_alert_increase" spawnarg, set "alert" to (current level + spawnarg value).

Regarding point 3, it might make more sense to always check for the "absence_alert_increase" spawnarg on the sending entity, regardless of whether it's an absence marker.

Link to comment
Share on other sites

32 minutes ago, Dragofer said:
  1. In my understanding the invisible absence marker entity left behind by a missing item is what actually alerts the AI, but the code foresees the possibility that another type of entity can also emit the "missing item" stim. In that case the alert level wouldn't change, whereas previously it would always get set to "agitated searching".
  2. Also, if no "absence_alert_increase" is set, the alert level is set to "agitated searching" even if it's already higher than that. I don't think it's right that an AI should become less alerted in this case.
  1. That is true. But actually the only obvious reason to replace the absence marker with another entity is to alter the stim range or to add some custom behaviour. In that case one would derive the custom entity from the default one, though, so the condition would still be fulfilled. I don't see any other work case, to be honest, and therefore can only guess what behaviour may be desired by fm authors.
  2. I just checked and it seems you are right. I actually thought that this wouldn't be possible. Will tweak that. (EDIT: Done)
32 minutes ago, Dragofer said:

if the alert variable is lower than "agitated searching", raise it to "agitated searching

That would be exactly the behaviour that was in place to begin with, and which we want to fix. The AI should NOT go to agitated searching everytime it spots a missing item.

I would not want to make any changes to the absence marker related code. It is used by default and there may be a reason why the code is only executed in that scenario. So unless someone can come up with a scenario why it should be different...

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

14 minutes ago, Obsttorte said:

That would be exactly the behaviour that was in place to begin with, and which we want to fix. The AI should NOT go to agitated searching everytime it spots a missing item.

In my view the problem is that the code first checks the spawnarg, then sets alert level to agitated searching, so you always get agitated searching.

If this order were switched around you'd have agitated searching as the default, which the spawnarg would override if it's been set by the mapper.

17 minutes ago, Obsttorte said:

I would not want to make any changes to the absence marker related code. It is used by default and there may be a reason why the code is only executed in that scenario. So unless someone can come up with a scenario why it should be different...

Yeah, I don't really see how other entities than absence markers would emit this stim. However, the old code always modified the alert level regardless of whether it's from an absence marker, and it seems to have worked alright these past years (apart from the spawnarg not working). The proposed revision changes this to only occur if that condition is met, which I don't know what consequences it'll have.

Link to comment
Share on other sites

1 hour ago, Dragofer said:

If this order were switched around you'd have agitated searching as the default, which the spawnarg would override if it's been set by the mapper.

That's how it is now.

1 hour ago, Dragofer said:

The proposed revision changes this to only occur if that condition is met, which I don't know what consequences it'll have.

It's will only have a consequence if some mission author has replaced the absence marker with something else (unlikely). And the only consequence would be that the AI's level isn't increased, while still noting something has been taken (not necessarely a mission breaker).

I really don't consider this an issue. And if it is, we can deal with it once it occours and can talk to the respective mission author to see what his intentions were.

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

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

    • duzenko

      Please, can we finally group the missions by year in the game menu?
      · 3 replies
    • duzenko

      I vaguely recall someone recently complained about two-sided materials (curtains?) not getting lighting from both sides
      I just found a piece of code that's supposed to do just that
      Where was that discussed? (@nbohr1more?)
      · 8 replies
    • Xolvix

      I still play classic Doom (albeit with user-made mods and maps rather than the original campaign) on a regular basis. A game from the early 90's which has still got a healthy following in 2022. Pretty amazing.
      · 3 replies
    • Nort

      I'm beginning to understand why people who aren't into social clubbing "don't last long" on this project, and why it's so full of holes. When moderators are siding with bullies, by closing down threads that they derail, then I start to wonder if I should support the platform to begin with.
      I'm sure that the core development is solid, but when you're constantly tone policed and bullied, and moderators are playing into it too, then the project will just drive away talent, and replace it with socialites instead. ...and without talent, you only end up with a small skeleton crew trying to do everything themselves.
      ...so Dragofer and Airship Ballet, and all you other socialites, you win. From now on I'll just keep to myself. You'll never be able to do my work, but at least you'll be happy together, and that's what matters to you.
       
      Update
      Actually, I have to revise my statement:
      I actually messaged greebo - the top dog, I gather - about nbohr1more's outburst of insanity below, and since I haven't even heard back from him, I just have to assume that there's not a single core programmer here, who's not backing nbohr's threats. ...and that's bad.
      ...so if you're a newbie reading this, or an honest soul like ZergRush, then just slowly back out of these forums, run, and don't look back. This is nothing more than a cult posing as a game development project, using Thief and IDTech4 to sucker hopefuls in, to do work for them, while trying to cajole them into something going on behind the scenes, which apparently - according to nbohr - is something that should be hidden from the state. These people aren't programmers - they don't even understand things like how to fix the simplest bugs. All they have, is an engine, and an IP, and some sort of fascist social cult. There was some other project I saw being made in the Unreal Engine. Try joining that project. ...or start a project of your own. Anything but this asylum.
      Hopefully that was "divisive" enough for a final post, because at this point I really want people to leave this place. This project is, on a management level, just awful garbage, run by garbage people, apparently from the top down, and I'm just glad that they have a garbage place to stay, together, and hopefully forever.
      Nort
      · 9 replies
    • The Black Arrow  »  Araneidae

      A spidey! I love spideys 🕷️
      · 0 replies
×
×
  • Create New...