Alert & Suspicion Triggers

TODO PLACEHOLDER

AI will alert if they see or hear the player but alerts and suspicion (low alert) can be triggered by the AI noticing suspicious or missing objects and other situations. This article describes how to control this.

Controlled Alerts

Alarms etc.

One thing I'd like to know is how to start AI off (at map start) at an elevated alert level rather than their default, casual state.

alert_initial is the spawnarg you need. This is a floating point value.

These are the thresholds.

idle: 0 ... 1.5 observant: 1.5 ... 6 suspicious: 6 ... 8 searching: 8 ... 18 agitated searching: 18 ... 23 combat: >23 (but alert_initial doesn't work in this case, AI need an enemy to go into combat)

Which number is the one they go to after having spotted the player? The one where they go back to their regular patrols but keep their weapon out?

This is still idle < 1.5.

The code switches to a different AlertIdle state when the AI has encountered an enemy before. There's no difference in terms of the numbers.

Suspicious Objects

TO DO noisemaker arrow on floor

CHECK OUT AIUSE_ STIM_VISUAL

That's what is issued by STIM_VISUAL on arrows, doors and AI by default. The AI code reacts to those stims based on the AI_USE spawnarg.

NOTES PASTED FOR REF TO REWRITE. SOME OF THIS MAY BE OBOSOLETE OR IRRELEVANT FOR THE MAPPER - I'VE GOT TO FIGURE IT OUT YET...

script function for responding to STIM_VISUAL in ai_darkmod_base, and made some tweaks to the visibility tests in the dll (not in the pk4 yet). By adding a visual stim to the arrow and arrow result defs, I've got the AI reacting to arrows that it sees (only the first time it sees each one, using the ResponseIgnore script function.)

However, I'd like to have the AI react differently to different sorts of objects.

variable to classify the response to stim_visual: IMO, I think it's easier to just create different stims for these different cases, with the functionality in the response. E.g., stim_body, stim_suspicious_item, stim_missing_item, etc.

Ok, I've implemented a bunch of .def variables that contain what I need. I have them all documented in a file that is intended to be included by scriptors that I will check in with the source.

Here are the contents that I've added so far

// This is the key name for the AIUse spawn arg

1. define AIUSE_KEY "AIUse"

// And below are values in use

1. define AIUSE_WEAPON "AIUSE_WEAPON"

1. define AIUSE_LIGHTSOURCE "AIUSE_LIGHTSOURCE"

1. define AIUSE_BLOOD_EVIDENCE "AIUSE_BLOOD_EVIDENCE"

1. define AIUSE_SEAT "AIUSE_SEAT"

1. define AIUSE_COOK "AIUSE_COOK"

1. define AIUSE_EAT "AIUSE_EAT"

1. define AIUSE_PET "AIUSE_PET"

1. define AIUSE_CATTLE "AIUSE_CATTLE"

1. define AIUSE_PERSON "AIUSE_PERSON"

1. define AIUSE_PEST "AIUSE_PEST"

1. define AIUSE_DRINK "AIUSE_DRINK"

//----------------------------------------------------------------------------------------

All the FOLLOWING are in effect are strings. The AI scripts look to see what strings are attached as spawnargs under the specified keys, and use those to decide what "type" of entity it is. So if its a noble, they can adress it as a noble. If its a rat, they can address it as a pest.

// The following strings define classes of person, these are used if AIUse is AIUSE_PERSON

// This is the key value

1. define PERSONTYPE_KEY "personType"

// And these are values in use, add to this list as needed

1. define PERSONTYPE_GENERIC "PERSONTYPE_GENERIC"
2. define PERSONTYPE_NOBLE "PERSONTYPE_NOBLE"
3. define PERSONTYPE_CITYWATCH "PERSONTYPE_CITYWATCH"
4. define PERSONTYPE_MERC_PROGUARD "PERSONTYPE_MERC_PROGUARD"
5. define PERSONTYPE_BUILDER "PERSONTYPE_BUILDER"
6. define PERSONTYPE_PAGAN "PERSONTYPE_PAGAN"

//---------------------------------------------------------------------------------------- // The following strings define genders of person, these are used if AIUse is AIUSE_PERSON // I don't want to get into the politics of gender identity here, this is just because the recorded // voices will likely be in gendered languages. As such, I'm just including the categories // that are involved in word gender selection in many languages.

1. define PERSONGENDER_KEY "personGender"

1. define PERSONGENDER_MALE "PERSONGENDER_MALE"
2. define PERSONGENDER_FEMALE "PERSONGENDER_FEMALE"
3. define PERSONGENDER_UNKNOWN "PERSONGENDER_UNKNOWN"

//---------------------------------------------------------------------------------------- // The following key and values are used for identifying types of lights

1. define AIUSE_LIGHTTYPE_KEY "lightType"
2. define AIUSE_LIGHTTYPE_TORCH "AIUSE_LIGHTTYPE_TORCH"
3. define AIUSE_LIGHTTYPE_GASLAMP "AIUSE_LIGHTTYPE_GASLAMP"
4. define AIUSE_LIGHTTYPE_ELECTRIC "AIUSE_LIGHTTYPE_ELECTRIC"
5. define AIUSE_LIGHTTYPE_MAGIC "AIUSE_LIGHTTYPE_MAGIC"

//---------------------------------------------------------------------------------------- // The following defines a key that should be non-0 if the device should be on

1. define AIUSE_SHOULDBEON_KEY "shouldBeOn"

//---------------------------------------------------------------------------------------- // The following defines a key that should be non-0 if the device should be closed

1. define AIUSE_SHOULDBECLOSED_KEY "shouldBeClosed"

torch and candle flames turning on a visual stimulus if they are marked as supposed to be on and get doused. The stimulus turns off if it is relit.

I'm adding the following spawn args. Note that they are spawn args, not variables, so they can't be changed other than in a .def file.

"canLightTorches" : > 0.0 indicates the AI can light torches "canOperateSwitchLights" : > 0.0 indicates AI can turn on switched lights

"chanceNoticeWeapon": 0.0 to 1.0, probability of noticing a seeable weapon not belonging to a friend "chanceNoticePerson": 0.0 to 1.0, probability of noticing (reacting to) a seeable person be it friend, foe or enemy. "chanceNoticeBlood": 0.0 to 1.0, probability of noticing a see-able patch of blood. "chanceNoticeLight": 0.0 to 1.0, probability of noticing a visible light source that is in the wrong state "chanceNoticeMissingItem": 0.0 to 1.0, probability of noticing a visible missing item "chanceNoticeDoor": 0.0 to 1.0, probability of noticing a visible open door that should be closed

New values "AIUSE_MONSTER" "AIUSE_UNDEAD" "PERSONTYPE_THIEF"

They are in the .def files. The defintions of the tags are in the AIUseValues.script file for inclusion in scripts.

Suspicious Changes

TO DO

Doors ajar, torches exgtinguished

If an AI is looking at a torch and the player shoots it out, will the AI react to it with more suspicion than just a general 'when did this go out?'?

No, they won't react any different than for normal torches. Chances are they will notice the visual stim from the water arrow projectile, but this is not always the case.

Missing or Moved Objects, Absence Markers

By default AI will take no notice if loot or other objects are missing or moved so it is up to the mapper to judge whether any prominent items ought to be noticed by their absence. The contents of a jewellery box or just a broom moved in a cupboard need not be a cause for attention whereas a guard protecting a precious artifact on a plinth in the middle of a hall should react if it is stolen or even moved off the pedestal onto the floor.

Making AI Notice a Missing Object

To make AI notice, become suspicious or alert if an object is missing or moved add to any kind of moveable entity including loot, corpses, any moveable object you think the AI should notice is missing, the following property and values:

absence_noticeability

...with a decimal fraction anywhere in the range from 0 to 1. The closer to 1 then the more likely the AI will notice. Examples:

• 1 means the AI will always notice the object is missing 100% of the time
• 0.5 means the AI will only notice the object is missing 50% of the time
• 0 means the AI will never notice the object is missing (default)

It works this way: If the object is moved or taken away then an absence marker is created at the original location (at the center of the bounds) which emits a visual stim. When the item is put back at its original location (within the original bounds of the entity), the absence marker is destroyed again.

Currently the AI will notice at a range of 500 units. Check later if this is changed. It may even become a spawnarg you can adjust to AI do not alert too far away if a tiny ring is missing 25 metres away.

How Far Can the Object can be Moved Without Suspicion?

By default the player can move an object (with the absence_noticeability property) within the original boundaries of the entity's start position without arousing suspicion. So a crate that is only pushed a foot or so to one side will not arouse suspicion. If it is pushed further than half its own width then it will. But this can be controlled:

You can add to the object the property:

absence_bounds_tolerance

...with any value in doom units and this will be added to the boundaries of the entity's start position. So a crate sized 30 units cube even without this property can be pushed one foot and still clip its original boundaries and so not be noticed. But set this spawnarg to 100 and now it can be moved an extra 100 units in any direction without being noticed.

If you want it to be moveable anywhere within a set area, eg, anywhere on a table top, then see next section....

Moving within a Location or to a New Location Without Suspicion

What if you want the player to be able to move a vase anywhere on a table top or to a separate location completely - to another table or another room - without arousing suspicion? You can define the location: Do the following:

• Create a brush entity to cover the table top and at least the height of the vase.
• Texture the brush with clip texture, convert it to func_static, then give it a suitable name, eg 'vase_area'.
• To the original vase add the property absence_location_1 and give it the name of the brush, eg, 'vase_area'.

So long as the vase is partly within that brush then the AI will not be concerned it has been moved about (eg, by a servant for cleaning.)

And you can put the location brush elsewhere too so the vase can be given the property absence_bounds_tolerance (see above) to extend its coverage around its original location plus the new location brush might be placed on another table or in the kitchen sink if you want.

It is planned to enable multiple alternate locations where it is OK for the object to be (eg, the cleaner put the vase on the next table.) Check at a later time if you can use absence_location_2, 3, etc.

Restricting Alerts to one Type(team) of AI

Normally all AI will respond to an absence marker. If you only want one AI team to react then give the object the team property with the value of the team type (see teams.) Missing objects without this property may be noticed by all AI on all teams.

Controlling AI Reactions to Missing Objects

The reaction of AI on noticing an object is missing can be controlled from slight suspicion up to full alert. Add this property to the object:

absence_alert

And give it a value in the range:

• 0 to 1.5 = idle
• 1.5 to 6 = observant
• 6 to 8 = suspicious
• 8 to 18 = searching
• 18 to 23 = agitated searching

If this property is not set then the AI's alert level will be set to a default of just below agitated searching.