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.

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

Doors ajar, torches exgtinguished

Missing Objects

Pasted from forum. to be re-edited.....

Absence markers are working now (although still a little bit WIP). All entites can have this functionality. (So AI could also notice a missing corpse for example)

There are the following spawn args for defining the properties on the entity that should be noticed when gone missing (which needs documenting in the defs, I know ):

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.