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

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.

To make AI notice, become suspicious or alert if an object is missing or moved add the following property and value to any kind of entity:

absence_noticeability: defines the probability of noticing that the item has gone missing.

If this is > 0, an absence marker will be spawned 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.

absence_location_1: instead of the original location, you can define a place where the entity should be. Simply creating a brush textured with clip and converting it to func_static will do. (At the moment, only the _1 will work, making multiple locations possible is still TODO)

absence_bounds_tolerance: expands the testing bounds (both of the original location and the absence location)

team: This spawn arg can be set on all entites now. If it is set, only AI with friendly team will react to the missing entity. Entites without this spawnarg will be noticed by all AI.

absence_alert: Alert increase the AI will get. If this is not set, the AI's alert level will be set to just below agitated searching.