Logic

From Mod Wiki

(Difference between revisions)

Current revision

1 Flag system
- 1.1 path_walk, path_look
- 1.2 Paths in-depth
2 Stalker behaviour schemes
3 Sections
4 Overrides
5 Monster schemes
6 Monster overrides
7 spawner section
- 7.1 Spawning day and night monsters
8 Logic script
9 space_restrictor logic scheme
10 Various settings for objects
11 Smart terrains and gulags
12 Helicopter logic
13 Meet_manager
14 Minimap marks
15 Function arguments
16 Sound group configuration
17 Author
18 Source

Flag system

Waypoints can have flags modifying a character's behavior. Flags are set right in the waypoint's name. For instance, for the point named "wp00": wp00|flag1|flag2.

path_walk, path_look

Flags for path_walk waypoints:

a=state: Chooses body state for movement; The list can be found in gamedata\scripts\state_lib.script.
p=percent: Probability of stopping at the point as a percentage (0-100). It is 100 by default. That is, the character never passes the point by.
sig=name: Set signal with the given name on arrival at the point (before turning) for the following check with the logic system field on_signal. To set a signal after turning, use the corresponding flag for a path_look waypoint.

Flags for path_look waypoints:

a=state: Chooses body state for standing (or sitting) at the spot.; The list can be found in gamedata\scripts\state_lib.script.
t=msec: time in milliseconds to look at the point; '*' means unlimited time. Valid values are in the range [1000, 30000], 5000 by default.; For terminal waypoints of path_walk that have no more than one corresponding path_look, the value of t is always considered infinite and does not have to be set.
sig=name: Set the signal with the given name after turning towards the point.
syn: This flag will halt setting the signal until all characters with the given team arrive. The team is set as a text string in customdata. The given character will be play its idle animation until the others arrive.
sigtm=signal: Sets a signal when the time_callback is called by the state manager. If t=0, then the signal will be set after playing the init animation. This is used, for instance, with the press animation, which consists of two parts: 1 — pressing the button, 2 — lowering the arm.; path_look can do: wp00|a=press|t=0|sigtm=pressed.; Then switch the scheme: on_signal = pressed | other_scheme.

Paths in-depth

Configuration

For each walker, you should place onto the map:

path path_walk, used to walk along
path path_look, consisting of points to look towards

There can be one or more walkers. They can act independently, or interract with each other.

[walker]

team: team name — an arbitrary text string. All walkers in a team must have the same team. It is desirable to specify level name and location in team; for instance: escape_bridge, escape_factory — this will reduce the chance of error of giving different teams the same name.
path_walk: name of the path described in "1"
path_look: (optional) name of the path described in "2". If a character needs to only walk along a path, path_look can be ommitted. If a character should stand at places, it needs a path_walk point and at least one path_look point.

The rules for setting flags with examples:

Example 1

A character patrols territory around two houses. Here is how the route is made:

What to do to make the character run or sneak between certain points? There are flags in path_walk just for this purpose.

Each waypoint has a name: wp00, wp01, etc.

Flags are set in the name. They should be separated from the name using the symbol '|'. Write a=anim, where anim is the name of an animation from 2.4.4 of original documentation. If we write a=thread, the character will enter danger mode, if a=raid will run with his weapon at ready, etc.

Note: only animations from the "walk states" section can be used!

Example 2

A character conversation.

To make a character speak while moving along a path, each point must have a list of topic he can speak about. There is the following field for this: s = sound_scheme_name (off by default). Several topics can be separated by commas.t

Example 3

Example 3 uses only the field s to set conversation topics.

It is NOT RECOMMENDED to set the other parameters (sp, sf, st). The default values are acceptable for most scripts.

It is also NOT RECOMMENDED to use the parameter sa. If a sound must be run at the same time as an animation, you should use fields in path_look, which will be described later in this document.

If a character not only walks along the path, but must also stop and play animations, you should set the path_look path.

Example 4

Improve Example 1, so that when the character passes a space between houses, stopped and looked inside it:

What is new? There is now a path_look path with two points. It is recommended to remove the link between these two points of the path in the editor right away, since it is not used anyway.

Forethermore, lets set some flags at the points of path_walk and path_look that are circled with a dashed line. For instance, in the upper pair of points, set the flag 0, and in the lower pair — flag 1.

Now the character will stop at points of path_walk marked with a flag, look towards the point of path_look marked with the same flag.

If a point of path_walk is not marked with a flag, the character will pass it without stopping.

One point of path_walk can correspond to several points of path_look. If this is the case, the character will randomly choose one of the suitable points.

Similarily to path_walk you can use various flags in points of path_look to modify behavior:

p = 100: Probability with which the character will look at that point. The values of all suitable p are added, so if one point has p = 100 and another 300, the character will look twards the point with probability 25% (100 out of 100 + 300).; To avoid confusion, you should set p such that they add up to 100.; By default, all points have p = 100.
t = time in milliseconds: Duration of time for which the character will stop at this point.; By default, the value is 5000.

Example 5

In this example, as the character passes point wp00, he will look at the point wp00 for 5 seconds with probability 30% or at the point wp01 for 10 seconds with probability 70%.

By default, the character plays the idle animation when he stops if he is not crouching, or animation hide if he is crouching.

If you need a different animation, you can set it with this flag:

a = animation name (defaults to idle).

Write a=anim, where anim – is the name of an animation from 2.4.4. of the actual documentation. If we write a=hide, the character will enter the alert mode, if a=guard, will stand with his weapon on ready, etc.

Note: You can only use animations from the section "standing and crouching animations" for path_look!

Stalker behaviour schemes

There is a certain set of schemes that describe a character's behavior. They are set in his custom_data or, in case of a gulag, in corresponding flags, describing the function of a given gulag. The list of these scheme follows.

All of the loaded schemes are listed in the file \gamedata\scripts\modules.script

walker scheme

This is the basic scheme that moves a character along waypoints (path_walk) and stops at certain points and executes certain actions.

[walker]

path_walk = <path name>: the main path the NPC traverses
path_look = <path name>: path the NPC looks towards
team: team to synchronize

The characters stops and looks at a certain points at path_walk points with corresponding path_look points, while playing (or not playing) a certain animation.

def_state_moving1: state in which the NPC moves towards the first point if it is nearby (patrol by default)
def_state_moving2: state in which the NPC moves towards the first point if it is further (rush by default)
def_state_moving3: state in which the NPC moves towards the first point if it is far away (sprint by default)
def_state_standing: default state in which the NPC stands at the point and looks, unless a different state is specified for the point

File: \gamedata\scripts\xr_walker.script

remark scheme

This scheme is used for synchronization and binding with other schemes.

[remark] snd_anim_synс = true либо false. По умолчанию false. Указывает на то необходимо ли синхронизировать звук с анимацией либо нет

snd

remark sounds; nil by default

anim

remark animation; wait by default

target

where the stalker looks; there are the following options

story_id

a number

actor

no comment

nil

position automatically calculated by the AI

<job name>, <gulag name>

look at a stalker that has a certain job in a certain gulag (the second parameter is not required, if omitted, the gulag of the stalker to which the given section applies is used). Example:

target = logic@cit_killers_base_guard, cit_killers

<path name>, <point number>

you can tell him to look at a vertex of a patrolling path

Note: that if this value is not set, it will be equal nil not actor. If you want to make a character look at an actor in a remark, you have to specify it explicitely. Given nil the character will return to an AI-calculated position.

Standard signals for remark:

sound_end: when the sounds finish playing
anim_end: when the animations finish playing
action_end: when both finish, if synchronized

An example of using animation and sound in a remark scheme:

[remark]
anim = animation
snd = sound
snd_anim_sync = true
on_signal = action_end | next scheme

sleeper scheme

Scheme for a sitting or slipping NPC. It must have a path consisting of at least one waypoint. The sleeper will sit down at the zeroth point of the path and face in the direction of the first point.

[sleeper]

path_main: path name
wakeable = true: whether the character can wake up quickly (if true, he will sleep squatting and will mumble in his sleep)

If the path constsists of two points, there should be a link from the first to the zeroth (or a bidirectional one).

File: \gamedata\scripts\xr_sleeper.script

kamp scheme

Scheme for a stalker sitting in a given radius from a given point (by a campfire) and facing this point.

[kamp]

center_point = kamp_center: name of the point at which the NPC will be dislocated
radius = 2: how far the NPC will be from the camp center; 2 by default
def_state_moving = run: default state in which the stalker will go towards the point

File: \gamedata\scripts\xr_kamp.script

If the camp point is inside a campfire, then in offline mode stalkers will approach it, then in online mode they will be inside the fire and will be damaged. To avoid this, in the camp section set path_walk from a point called <path_camp_name>_task.

path_walk = <path_camp_name>_task

If the camp point is located in an open field, then there is no need for adding path_walk.

camper scheme

Camper properties:

campter stands at a spot and looks in the direction in which you set him in the editor or moves along patrol paths
campers switch to all-purpose combat when they see an enemy closer than 30 meters away. If a camper survives, he returns to camper mode.
In all other situations act according to their own scripting scheme. If an enemy is in sight — shoot. If danger is heard — look in its direction. If a grenade is spotted — run away from the grenade. If an enemy was in sight, but disappeard, look in the direction of last sighting of the enemy.
campers do not move and attack. If they see an enemy, they stop, shoot, then continue movement.

[camper]

path_walk = patrol_path
path_look = patrol_path
radius = number: distance in meters; if the distance between the camper and the enemy is less, camper switches to all-purpose combat mode; 20 by default
no_retreat = true/false: true if the character will not go towards the nearest path_walk point upon enemy sighting, but starts attacking him immediately. Needed in case you wont to create a scene with some guys hitting on some others. Set this flag for the campers. They walk along their patrol points and take out the enemies.
def_state_moving = state manager state: a state in which we move to the nearest point upon an enemy sighting
def_state_moving_fire state manager state (sneak_fire): state in which we shoot the enemy while moving towards the nearest path point
def_state_campering = state manager state (hide): state in which we ambush an enemy while remaining on the path
def_state_campering_fire = state manager state (hide_fire): state in which we shoot an enemy while moving along the path
attack_sound = sound scheme name

ability to overwrite attack sound for snipers/campers; it can be disabled by writing "attack_sound="; fight_attack by default

shoot - type

attack type

always: shoot whenever possible; default value
none: do not shoot
terminal: shoot only at the last path point; added to make scripted scene creation easier

The camper has a large drawback — when he is hit and he does not know where the hit comes from (because he does not see the enemy or does not hear the shot), he daftly remains standing at the old spot and wait for the next bullet. In sight of this, you should not set campers to guard a position if there are several directions from which the player or other stalkers can attack the camper. Use walkers in such cases; while setting campers to attack along paths or using them as snipers.

sniper scheme

A variety of camper. Differs by shooting only single shots and not looking along patrol points, but rather scanning space between them. Scan speed between two points is fixed at 20 seconds. Note: set only two look points for a sniper.

Write the following in custom data:

sniper = true

File: \gamedata\scripts\xr_camper.script

follower scheme

NPC follows an NPC leader. If the leader is closer than 5 meters, he walks, if 5 to 20 — runs, if more than 20 — sprints. Paths are not set.

[follower]

leader = number: story id of the leader from game.ltx
formation_line = true/false: try to stay to the side of the leader, otherwise walk behind
distance: distance in meters to keep away from the leader at; 1.5 meters by default, if walks in a chain, then 5 meters
state_if_leader_in_meet: a string with a state name from state_manager, which will be set by the follower if the leader is in the meet state
anim_walk: state for the follower to walk behind the leader in
anim_run: state for the follower to run after the leader in
anim_sprint: state for the follower to sprint after the leader in

File: \gamedata\scripts\xr_ attendant.script

If all of this happens in a gulag, then story_id of the leader should be replaced by his logic sections in the script file. Example:

t = { section = "logic@bar_arena_follower_2",
idle = 0,
prior = 7, state = {0}, squad = squad, group = groups[0],
in_rest = "", out_rest = "",
dependent = "logic@bar_arena_leader",
predicate = function(obj)
		return obj:character_community() == "dolg"
	end
}

zoneguard scheme

There are two zones for the NPC (or one). He walks along paths, but when the player enters the first zone, drops everything, runs up to the player, points a weapon at him (might also yell or talk), if the player enters the second zone — attacks him

[zoneguard]

path_walk
path_look
team: name of a team of synchronized zoneguards (only one from the team will react to the player)
zone_guard: the name of the zone in which the player will be attacked
zone_warn: the name of the zone in which to start a conversation with the player
walker_team: team to set it in walker mode (will be the same as team if not set)
no_move: will yell to the player from the spot, and not run towards him
snd_greet: name of the sound scheme from which to play a sound on finding the player
ignore_friends: if true, will ignore friendly characters
ignore_cond: {+info -info =func !func} conditions for ignoring the player
no_danger: if true, will not play the threat animation to neutrals
anim: animation to play if not hostile to the player
snd_anim_sync: if true, will synchronize sound with animation

File: \gamedata\scripts\xr_zoneguard.script

wounded scheme

[logic]
wounded = wounded
 
[walker]
wounded = wounded
 
[wounded]
hp_state          = HP|condstate@condsound|HP|condstate@condsound
hp_state_see      = HP|condstate@condsound|HP|condstate@condsound
psy_state         = PSY|condstate@condsound|PSY|condstate@condsound
hp_victim         = HP|condvictim|HP|condvictim
hp_cover          = HP|condbool|HP|condbool
hp_fight          = HP|condbool|HP|condbool
syndata           = state@sound|state@sound
help_dialog       = story_id
help_start_dialog = story_id

Where:

condstate: condition list returning the character's state, or true. The NPC will become mad at the player if true is returned.
condsound: condition list returning the sound scheme
HP: health point bounding values
PSY: psychological state boundary values
condvictim: condition list returning the direction to look at. Possible values: nil, actor, number. In case of a number, will look at the player with the corresponding id.
condbool: condition list returning true or false

Field values:

hp_state: character's behavior in absense of the player in site
hp_state_see: character's behavior on seeing the player
psy_state: character's behavior on psy attacks
hp_victim: point to look at depedning on HP
hp_cover: go to cover or not, based on HP
hp_fight: combat allowed or not, based on HP
syndata: synch pairs, for effect
help_dialog: story_id of a dialog to use instead of teh default actor_help_wounded. If the plot demands that you replace this dialog with another, you specify the id in this field.; We also add a dialog for the wounded. If we set it, all actor's dialogs for the wounded should have this precondition: dialogs.allow_wounded_dialog.

The default settings for example:

hp_state     = 30|help_me@help|10|wounded_heavy@help_heavy
hp_state_see = 30|wounded@help_see|10|wounded_heavy@help_heavy
psy_state    = 50|{=best_pistol}psy_armed,psy_pain@wounded_psy|20| {=best_pistol}psy_shoot,psy_pain@{=best_pistol}wounded_psy_shoot,wounded_psy
hp_victim    = 30|actor|10|nil
hp_cover     = 30|true|10|false
hp_fight     = 30|true|10|false
syndata      = wounded@help

Where:

best_pistol: a check to make sure the NPC's best weapon is not a pistol

File: \gamedata\scripts\xr_wounded.script

rest scheme

The dude walks, eats, sleeps.

Does not really work yet.

File: \gamedata\scripts\xr_rest.script

heli_hunter scheme

Helihunter might shoot or not shoot at a helicopter, depending on conditions. This is how it works:

[camper@bar_freedom_attack_sniper_1]
path_walk         = camper_1_walk
path_look         = camper_1_look
on_info           = {+bar_freedom_attack_ecolog} camper1@bar_freedom_attack_sniper_1 %= bar_freedom_angry_actor%
meet_talk_enabled = true
meet_dialog       = bar_svoboda_dialog
heli_hunter       = {-bar_ecolog_crush_heli_down} true, false

patrol scheme

Here is a preliminary patrol system. It is a variety of kamp, except in walking mode. To make it work, add the following to custom data:

[patrol]

path_walk = path_walk

path_look = path_look

formation = back

describes the formation type, and is required. Can be one of the following

back
line
around

commander = true: sets the commander; there should be only one
move_type = patrol: sets the initial movement mode, patrol by default. This value is a walking animation from state_mgr_lib

When the commander stops at meet, the guys stop

If the commander dies, another one is chosen automatically. The first to enter the scheme is chosen. Formation at waypoints is done like this:

ret=0...2

0 - line
1 – around
2 – to the sides

When the commander moves, he works like a regular walker, and the others follow his actions. That is, if the waypoint is set to a=assault, the commander will rush forward with his weapon at ready, and the others copy him.

What does not really work:

there is no way to modify formation
everyone is quiet
commander does not give commands
it is not recommended to use sprinting

Sections

combat section

Shows what happens when the NPC goes into battle.

on_combat = combat

[combat]

on_info = %+info -info =func%: affects for each round of combat

To set up the various types of scripted battles use the parameter combat_type

In the following example, the stalker fights:

as a campter, if enemy=actor and is further than X meters
as Monolith, if any enemy is further than Y meters
engine-controlled otherwise

[logic]
active    = walker
on_combat = combat
 
[walker]
path_walk = ...
 
[combat]
combat_type = {=fighting_actor =fighting_ge_X_meters} camper, {=fighting_ge_Y_meters} monolith

An example of such a function: we need the NPC to switch to campter combat when distance is above 20 meters.

function fighting_dist_ge_20(actor, npc)
	return db.storage[npc:id()].enemy:position():distance_to ( npc:position() ) >= 400
end

400 is 20 m. We specify the square of the necessary distance to conserve system resources.

One more example. The stalker moves under the simulation, but his combat is not engine-controlled, but always zombie-style.

[logic]
active = nil
on_combat = combat
 
[combat]
combat_type = zombied

If different character sections require different types of combat or different conditions, you can use the override combat_type.

Remember: the override will always take priority over the combat section settings. That is, if you have logic for five sections and you need camper combat, but monolith combat in fifth, you can do it like this:

[logic]
active = walker1
on_combat = combat
 
[walker1]
...
[walker2]
...
[walker3]
...
[walker4]
...
[walker5]
...
combat_type = monolith
 
[combat]
combat_type = camper

scheme: sets combat type: monolith, camper, zombied; otherwise, all-purpose combat is used

disable_combat_handler: the function disables the combat section.

File: \gamedata\scripts\xr_combat.script

death section

The section shows what happens when an NPC dies.

on_death = death

[death]
on_info = %+info -info =func%

File: \gamedata\scripts\xr_death.script

hit section

Shows what happens when an NPC is damaged. Note that on_hit does not react to the sound of a shot, but only a direct hit! This is done, because the sound of a shot should not be percieved as aggression in general (the player might be shooting dogs, but ending up provoking guards, for example).

on_hit = hit

[hit]
on_info = %+info -info =func%

File: \gamedata\scripts\xr_hit.script

actor_dialogs section

Shows which dialogs will be available to the player when speaking with this NPC. Can be used in almost any scheme.

actor_dialogs = actor_dialogs

[actor_dialogs]

id: comma-separated list of available dialogs
disable: comma-separated list of disbled dialogs

File: \gamedata\scripts\xr_meet.script

use section

This section shows what will happen if the player tried to "use" the NPC.

on_use = use

[use]
on_info = %+info -info =func%

File: \gamedata\scripts\xr_use.script

combat_ignore section

If an NPC is in this scheme, then he enters into combat mode. In any other scheme:

[walker]

combat_ignore_cond = {+info –info =func !func}: condition for ignoring combat (if you write always then the character will always ignore combat in this schema, untill switching to a scheme that does not ignore combat)

There are no additional fields in the scheme:

[walker]

combat_ignore = combat ignore

[combat_ignore]

Functions used for wark with the combat ignore condition list:

fighting_dist_ge_20: current enemy at distance equal to or greater than 20 m
fighting_dist_ge(distance in meters): all-purpose function for combat_ignore, checks for distance from the player
fighting_actor: is actor the current enemy?
check_fighting: check (by story_id) to see if anyone from the list is an enemy

File: \gamedata\scripts\xr_combat_ignore.script

dont_spawn_character_supplies section

If this section is set, then the standard set of loot specified in the profile won't span inside him.

[dont_spawn_character_supplies]

no_smart section

If this section is present, the NPC cannot be controlled by the smart terrain, even if it fits all the parameters.

[no_smart]

treshhold section

There is a way to change stalkers' parameters that determine how they attack monsters. There are two such patameters:

max_ignore_monster_distance: (currently 15 m by default). The stalker will always attack monsters within a certain radius.
ignore_monstre_threshold: (currently 0 by default) Parameter 0 to 1. If the monster is evaluated at below this parameter, and the monster is outside the given radius, it will be attacked. Currently, stalkers never attack anything outside the 15-meter radius.

In the logic section or in the current sheme set:

threshold = threshold@tratata
 
[threshold@tratata]
max_ignore_distance = <number>
ignore_monster      = <number>

Be very careful about changing the second parameter.

Danger section

Settings can only be set in some scheme, such as:

[walker]
danger = danger_condition
 
[danger_condition]
ignore_distance          = 50
ignore_distance_grenade  =
ignore_distance_corpse   =
ignore_distance_hit      =
ignore_distance_sound    =

Distance is set in meters. You can also set the amount of time to wait for danger, depending on type:

danger_inertion_time_grenade =
danger_inertion_time_corpse  =
danger_inertion_time_hit     =
danger_inertion_time_sound   =

Default setings:

danger_inertion_time_grenade = 20000
danger_inertion_time_corpse  = 10000
danger_inertion_time_hit     = 60000
danger_inertion_time_sound   = 15000

Note! These settings also apply to the camper scheme. That is, danger_radius does not work in camper settings. The data is taken from the danger section.

The algorithm works like this: first check if distance to the source of danger is not matched by ignore_danger. If the danger is closer, then its type is analyzed and is matched against the corresponding distance. If the danger is closer, then reaction to it is permitted.

The following defaults are currently used:

ignore_distance         = 50
ignore_distance_grenade = 15
ignore_distance_corpse  = 10
ignore_distance_hit     = 50
ignore_distance_sound   = 50

Note: if you need a stalker to react to different types of dangers in different situations, create several danger sections: danger_condition@1, danger_condition@2, etc.

danger_expiration_time: the amount of time after which danger can be disregarded; 5000 by default
danger_inertion_time: the amount of time after which a character can forget about a danger he has reacted to; 10000 by default

stories section

Camps do not tell stories automatically. You have to "teach" certain stalkers a few stories. To do this, add the following section to custom data:

[game_info]
stories = "story_01, legend_01"

The quotation marks contain a comma-separated list of stories and legends. There are currently the following stories and legends:

story_01: edge of the Zone and grenade in one move
story_02: about the anomaly and the rocks
story_03: about Vilnov's group's return
story_04: about the time Kostia Fedorin encountered an artifact and disappeared from the radar
story_05: about the fight with a controller
story_06: about the door, the vodka, and the house
legend_01: about the alien experiment in the Zone
legend_02: about secret laboratories in the Zone
legend_03: legend of the guide
legend_04: legend of the Dark Stalker
legend_05: legend about not sleeping deep in the Zone

dont_spawn_loot section

All sorts of storyline characters might have to be empty after dying; for example: the wounded and the captive. To accomplish this, use the section:

[dont_spawn_loot]

Overrides

Settings that modify behavior of general schemes, depending on the currently active scheme (all optional).

meet_enabled = true: fire a flare for a metting
meet_talk_enabled = true: adds a possibility of a dialog to the current scheme
meet_dialog = <dialog name>: dialog to fire on use
meet_state = <state name>: sets the character's state for when a dialog opens
wounded_enabled = true: enables the NPC to use the wounded scheme
combat_ignore_cond: see above
combat_ignore_keep_when_attacked = true: the character ignores combat, even if shot at (but only if shot at by the player!)
combat_type = {condition} scheme: combat type to be used NPCs from this scheme
on_combat: see above
companion_enabled = true: free stalkers will join you as companions (will also charge for it in future)

Monster schemes

mob_walker scheme

Works the same way as the regular walker, except for a few differences:

path_walk flags:

s=sound scheme: (idle, eat, attack, attack_hit, take_damage, die, threaten, steal, panic, growling)
с: crouch from then on
r: run
sig=signal_name: set the given signal for xr_logic

path_look flags:

t=time: time to wain in milliseconds while looking at a point
a=anim_set: animation (stand_idle, sit_idle, lie_idle, eat, sleep, rest, attack, look_around, turn)

In custom data set:

[walker]

path_walk
path_look
no_reset = true/false: (required) do not reset the action of the previous scheme (sound, for instance); false by default
actor_friendly = true/false: (required) the monster never attacks first, although if the monster is attacked by the player, this flags is disabled; false by default
npc_friendly = true/false: (required) the monster never attacks first, even if the player is hostile
friendly = true/false: (required) the monster does not attack the player or other monsters. If they act aggressive, remembers them as enemeies and remains friendly to all; false by default

File: \gamedata\scripts\mob_walker.script

You can also control the bloodsucker's invisibility:

[mob_walker] ...

state = vis

state = invis

Also, the flag b (behavior) can be used in a mod_walker's path with the same parameters:

wp00|b=vis
wp00|b=invis

mob_eluder scheme

The monster moves along the patrol waypoints (without considering connections between points), keeping at a distance from the player, keeping its course, exiting the scheme upon getting too close to the player and returning back when the distance increases.

path: works as path_walk
Time_capture: (required) the time in seconds the monster spends in this scheme; 10 by default
Time_release: (required) the time in seconds the monster spends in the all-purpose scheme; 10 by default
Min_dist: (required) distance in meters under which the monster switches to the all-purpose scheme; 5 by default
Max_dist: (required) distance in meters over which the monster switches to the eluder scheme; 10 by default

Note: unstable.

File: \gamedata\scripts\mob_eluder.script

mob_remark scheme

Remarking scheme, but for monsters, not stalkers.

state: a specific state for the given monster (invisibility for a bloodsucker)
dialog_cond = {+info, =func, -info, !func}: conditions for opening a dialog
anim: comma-separated list of monster's animations
anim.head: comma-separated list of head animations
tip: which symbol is highlighted when the cursor is over it
snd: which sound it emits
time: animation playback time, used only for debugging

File: \gamedata\scripts\mob_remark.script

The trader is made using this scheme.

mob_combat, mob_death schemes

Works exactly the same way as the corresponding schemes for stalkers.

Files: \gamedata\scripts\mob_combat.script, \gamedata\scripts\mob_death.script

mob_jump scheme

Serves to make monsters jump without any checks and limitations (such as distance, angle). Position is set with a patrol path, offset and the physical jump factor.

Example:

[logic]
active = mob_jump
 
[mob_jump]
path_jump      = path
ph_jump_factor = 2.8
offset         = 0,10,0
on_signal      = jumped | nil

path_jump: path, wich which we set 1 target jump point (with zero index). The real point accounts for the position path_jump[0] + offset.
offset: displacement along axes x,y,z, with which the a real point in space is set (might not be located at an AI node)
ph_jump_factor: affects jump timing. Visually, it sets the curve of the jump. The higher it is, the sharper and faster the jump. This scheme allows creating a jump from one roof to another, jumping out a window, jumping over a barrier, etc. 1.8 by default

Note: mob_jump is more of an action than a state. When a monster switches into it, it turns in the direction of the jump and jumps, raising the signal jumped. That is, on_signal=jumped|<scheme name or nil> is a necessary parameter in the scheme, so that it is known what to transition to next.

The first point of the path (0 index) is used to pick the position.

Mob_camp

Mechanic:

Crouches, looks at a point.
Can set several positions and times of changing position.
Runs between positions.
Switches to an all-purpose scheme (combat, panic) at the sight of an enemy.
Minimum and maximum distances from the enemy to the current camp position are set.
If the enemy walks away too far, the monster returns to position.

Usage:

[logic]
active = mob_camp
 
[mob_camp]
path_look         = way_look
path_home         = way_home
time_change_point = 30000
home_min_radius   = 20
home_max_radius   = 50

skip_transfer_enemy: if this is added to custom data, the monster will not get an enemy from other monsters, if sees him (monsters have to be in different groups for this)

Parameters:

path_home: path consisting of the monster's locations
path_look: path consisting of locations for the monster to look at
time_change_point: time in milliseconds to change the current camp point; 10000 by default
home_min_radius: minimum radius in meters from the enemy to the camp point; 30 by default
home_max_radius: maximum radius in meters from the enemy to the camp point; 40 by default

Special features:

Minimum and maximum radii are necessary for ignoring enemies that run too far away to return to the current position. The enemy's distance to the current position is considered. If the distance is greater than home_min_radius, attack the enemy until the enemy disappears or distance exceeds home_max_radius. Two distances are needed to avoid the situation in which the player stands on the border of the radius and enters/exits the zone, and makes the monster run off and back.

the current position is chosen randomly
path_home and path_look path indices must coincide (monster sits at a point of path_home and looks at a point of path_look)

The only required parameter is path_look. If path_home is not set, then the current node and the object's spawn node are concidered.

To make the monster look in different points at a camp position, path_look can consist of several points.

Requirements:

home_min_radius < home_max_radius
path_look and path_home must have equal number points

P.S.: mob_camp can be used as an alternative to monsters under restrictors

Mob_home

This scheme is another way to replace restrictors. I recommend to make all monster gulags with mob_home.

Example:

[mob_home]
path_home       = path1
home_min_radius = 10
home_max_radius = 30

aggressive_home: monsters run, not walk towards the designated path_home

Monsters keep the path_home points. They attack an enemy if the enemy is within the home_min radius, otherwise hide. This implies that home_min should be made such that there would be enough covers inside. In idle they typically also go to cover. Home_max should be made like the largest restrictor in the "nest" scheme.

Added the ability to set minimum and maximum radius for the mob_home scheme in flags of the first point (path_home). Flags minr and maxr have been added for this purpose. In case radii are set both in the section and in the flags, the radius is taken from the section. Is neither is set, the values 20 and 40 are used, respectively.

Mob_fake_death

Is necessary for scenes in which zombies rise around the player as he walks.

Usage:

[logic]
active = mob_fake_death
 
[mob_fake_death]
on_actor_dist_le = 5 | nil

The zombie stands up when the scheme begins, falls down when it ends.

Monster overrides

actor_friendly: if true, the monster does not attack the player until attacked first
npc_friendly: if true, does not attach the player or other monsters until attacked first
friendly: if true, does not attack anyone until attacked first
braindead: if true, ignores all attacks

Monster sections:

[mob_death], [mob_hit]

spawner section

This section, which both NPCs and monsters have, spawns them (makes online) with a given codition. To make them appear in a given point, they should have the flag no_move_in_offline in the level editor and can_switch_offline should be off. The spawner is added to custom data before the logic section. It works like this:

[spawner]
cond = {+info -info =func  !func}

Note: if the spawn condition is not met, the object is not spawned, but if it has been spawned and the condition stops being met, the object will be made offline by the spawner.

Example:

[spawner]
cond = {=is_day} ; object spawns during the day and moves into offline during the night

After the object is spawned, it is taken under control by the logic script.

Spawning day and night monsters

[spawner]

cond = {=is_day}: only spawn the monster at day; to make it night only, write !is_day
check_distance = true: check to see if the player is nearby
min_distance = 100: do not spawn if the player is closer than this (150 by default, but this is really too much)

Logic script

Overview

Note: If you want to spawn some object for an NPC from custom data, the description for this is in the "general" section of character profile settings (do not write the supplies tag!)

Script logic controls scheme switching. Customdata for every character (except the free ones) must have a [logic] section.

Functions references by the [logic] section must be placed in files \gamedata\scripts\xr_effects.script or \gamedata\scripts\xr_conditions.script.

The section must contain one of the fields:

active: the active scheme to be ran first
cfg: name of the Ltx file with settings

If cfg is set, then the file contents will be used for the character's settings. For example, settings of a regular walker:

[logic]
active = walker
 
[walker]
path_walk = walk1
path_look = look1

Scheme switching is carried out with the additional conditions of the logic scheme, which are set in the section of the current active scheme. There exist the following switch conditions:

Note: If logic switches between several schemes having the same names (such as several walkers), then they can be numbered (walker1, walker2) or more informative names can be given after @ (walker@day, walker@alarm).

on_actor_dist_le = number | scheme: distance to the player <= number
on_actor_dist_le_nvis = number | scheme: distance to the player <= number without a visibility check
on_actor_dist_ge = number | scheme: distance to the player > number
on_actor_dist_ge_nvis = number | scheme: distance to the player > number without a visibility check
on_signal = signal | scheme: fires on signal from the active scheme
on_info = scheme: always fires
on_timer = msec | scheme: fires after the given number of ms after the scheme becomes active
on_game_timer = sec| scheme: fires after the given number of game seconds after the scheme becomes active
on_actor_in_zone = restrictor_name | scheme: if the actor is in the zone (restrictor name is given)
on_actor_not_in_zone = restrictor_name | scheme: if the actor is not in the zone (restrictor name is given)
on_npc_in_zone = npc_story_id | restrictor_name | scheme: if an NPC is in the zone (NPC id and restrictor name is given)
on_npc_not_in_zone = npc_story_id | restrictor_name | scheme: if an NPC is not in the zone (NPC id and restrictor name is given)
on_actor_inside = scheme: the zone checks if the player is inside
on_actor_outside = scheme: the zone checks if teh player is outside

You can work with any of the parameters listed above like this:

on_info  = {....} %...%
on_info2 = {....} %...%
on_info3 = {...} %...%

And so on.

You can also use conditions:

combat_ignore_cond =
on_hit             =
on_death           =
on_combat          =
on_use             =

Logic script syntax

Example: to make a character walk along the path walk1, but switch to path walk2 when the player comes within the distance of 5 meters (given that he sees the player), you should write the following:

[logic]
active = walker1
 
[walker1]
path_walk        = walk1
path_look        = look1
on_actor_dist_le = 5 | walker2
 
[walker2]
path_walk = walk2
path_look = look2

That was unconditional section switching. Before the section name in curly braces {} you can set additional conditions, and after the section name the so-called "effects", which should be enclosed between percent signs %%. Effects will be applied only in case a section is activated. You can omit section name and only set conditions and/or effects. Then only the old section will remain active, but the conditions and effects will nevertheless be processed. If all conditions in curly braces fail, the section will not be activated.

Example:

on_actor_dist_le = 5 | {условие} walker2 %effects%

You can have the following conditions:

+infoportion: the actor must have the infoportion
-infoportion: the actor must not have the infoportion
=func: the function must return true
!func: the function must return false

You can have the following effects:

+infoportion: the actor will get this infoportion
-infoportion: the actor will loose this infoportion
=func: the function will be executed

Several conditions or effects should be separated with spaces:

on_actor_dist_le = 5 | {+info1 -info2 +info3} walker2 %+info4 =func%

You can set several sections separated by commas. They will be hanled from left to right. After the first condition fires, the handling stops. In the example below, if info1 is set, then walker2 is enabled, if info2 is set, then walker2, otherwise walker4:

on_actor_dist_le = 5 | {+info1} walker2, {+info2} walker3, walker4

You can calso set conditions in the above field active of section logic, such us:

[logic]
active = {=actor_friend} walker@friendly, walker@enemy

You can use the keyword never in logic sections, which means that the condition is false. For example:

combat_ignore_cond = {=actor_enemy =actor_has_suit} always, {=actor_enemy} never %...effects...%

The above section enables combat ignoring if the NPC's enemy is the player is wearing a suit, but disables it if the player is not wearing suit. In this case the effects of the never section will work. Choosing the never section is equivalent to not having a section, but effects between percentage signs work.

Here is an example of work with the nil section. The nil section takes a character, monster, or object from under a scripted scene and puts him in the engine's control. This is necessary if some condition does not need to be checked again after firing off once. This saves resources that would otherwise be wasted on checking the condition.

[logic]
active = sr_idle
 
[sr_idle]
on_actor_inside = nil %+esc_actor_inside%

That is, after the actor enters the restrictor, he gets an infoportion, and the restrictor moves into the nil section, not checking for the player anymore.

Note: scripts cannot be returned from the nil section!

An example of fairly complex logic

[logic]
active        = walker
combat_ignore = combat_ignore
on_hit        = hit
on_death      = death
 
[hit]
on_info = %+alert%
 
[death]
on_info = %+alert +trup3%
 
[walker]
path_walk          = walk_svoboda3
path_look          = look_svoboda3
combat_ignore_cond = {-alert}
on_timer           = 25000 | remark
 
[remark]
anim               = idle
snd                = stalker_talk_kampfire
no_move            = true
no_rotate          = true
on_hit             = hit
on_death           = death
combat_ignore_cond = {-alert}
 
[combat_ignore]

Lets look at this step by step. At first, the stalker works according to the walker scheme. While at it, he ignores combat until the alert infoportion is set. Then he waits 25 seconds and switches to the remark scheme. In remark he plays an idle animation, chats on specified subjects, does not turn, does not move, still ignores combat. If he is hit or killed (on_death), he will get an alert infoportion and stops ignoring combat (obviously, if he is a corpse, that won't help, but there are three of them on the scene, and then the rest will spring into action). If he is killed, he will also get a trup3 infoportion, which will announce that this stalker is dead.

Now, here is his opponent's logic:

[logic]
active        = walker
combat_ignore = combat_ignore
 
[walker]
path_walk          = soldier_walk1
path_look          = soldier_look1
combat_ignore_cond = always
team               = assault_group
on_signal          = assault | camper
 
[camper]
path_walk = soldier_walk1_2
path_look = soldier_look1_2
radius    = 5
on_info   = {+trup1 +trup2 +trup3} walker2
 
[walker2]
path_walk = soldier_walk1_3
path_look = soldier_look1_3
 
[combat_ignore]

He is in the walker scheme, ignores combat (in any situation, by the way). He is part of the assault_group. When he comes to the endpoint of his route (where he is synchronized with the rest of the group, as is specified in the paths) he gets the assault signal and switches to the camper scheme. In this scheme he does not have combat_ignore specified and, therefore, starts shooting at the enemy. After all three oppponents are dead, with them setting infoportions trup1, trup, and trup3 upon dying, he switches to walker2 (goes to the campfire).

space_restrictor logic scheme

General comment: to avoid situations, in which the actor rushes through a restrictor before it goes off, try to make restrictors at least 2 meters wide.

[sr_idle] scheme

The purpose of this scheme is to switch to another scheme when one of the standard logic conditions is met. It does not do anything on its own. Example of a restrictor's settings:

[logic]
active = sr_idle
 
[sr_idle]
on_actor_inside = nil %+esc_actor_inside%

Note that when the check goes off, the active scheme switches to nil, so that it does not continue the useless check on each update. You do not have to set nil. Often this scheme works together with a spawner. The restrictor gives out an infoportion upon entry into the zone, and the spawner uses it to spawn something.

File \gamedata\scripts\sr_idle.script

[sr_no_weapon] scheme

This scheme removes the player's weapon uponn entry into its zone. Example of a restrictor's settings:

[logic]
active = sr_no_weapon

[sr_no_weapon]

File \gamedata\scripts\sr_no_weapon.script

[sr_sound] scheme

snd: comma-separated list of all sound names
type: comma separated list of sound types. For convenience, sound sets were introduced. For instance, to avoid listing the full set of wood floor sound types, you can specify floor_wooden.
delay: delay before playing the sounds in seconds of real time; 0 by default
idle: duration of time to ignore entry into the zone after the last sound begins. For instance, to make sure howling is no more frequent than once every few minutes. In seconds of real time. 0 by default.
rnd: percent probability of playing the sound; 100 by default
position: name of the path the points of which to play the sound at. Could be random, meaning a random place in the radius of 15-50 meters of the player. If this parameter is not set, then the player's position is assumed.
slide_velocity: speed of movement of the sound along the path; 3 by default
slide_sound_once = true\false: true - play the sound once, even if it does not reach the last point; false – if the sound has ended, but not reached the last point, play it again; false by default
play_at_actor = true/false: forces the sound play continuosly at actor's location. If this is true and the path is set (or is random) the game will crash.

This scheme is meant to be used to play sounds at the actor's entrance in a restrictor.

Supports sound_end.

You must set either snd or type. You can set both. The list of sounds is created based on these parameters. When the actor enters a restrictor, a random sound from this list is played.

Example:

[logic]
active = sr_sound
 
[sr_sound]
type     = floor_wooden
snd      = ambient\wind1, ambient\sparks1
rnd      = 50
position = random
idle     = 120
delay    = 3

You can make a "sliding" sound. You need a patrol path. The sound will start playing at the beginning of the path and move from one point to another (in the order they are set in the path) with the speed slid_velocity.

[logic]
active = sr_sound
 
[sr_sound]
type             = random
position         = way
slide_velocity   = 8
slide_sound_once = true

File \gamedata\scripts\sr_sound.script

[sr_tip] scheme

The purpose of this scheme is to give the player a tip on entry into a restrictor.

name: news name
type: news to send as global news, tips to send with the sender's name; news by default
sender: if type is tips then this is the string identifier of the sender character's icon; the dealer's icon by default
cond: condition for firing; set to entry into the restrictor by default
single = true/false: whether the tip should only be given once; false by default

Example:

[logic]
active = sr_tip
 
[sr_tip]
name     = tips_esc_trader_about_pda
type     = tips
cond     = {+infoportion1 –infoportion2 }
showtime = msec ; time in seconds the tip will be displayed for; does not work properly

If it should be played only once, and this happens often, you can add the following line:

on_actor_inside = nil

File \gamedata\scripts\sr_tip.script

Sr_light

Zone in which NPCs turn on their flashlights no matter what time of day it is.

Works like this:

[logic]
active = sr_light
 
[sr_light]
light_on = true/false

Also works with a condition list:

[logic]
active = sr_light
 
[sr_light]
light_on = true/false
on_info  = {+info1} section %+info2%

Sr_territory

Catches various events within a restrictor.

Right now, it only catches hits and stalker deaths. It can be used somewhat like this:

[logic]
active = sr_territory@outside
 
[sr_territory@outside]
on_actor_inside = sr_territory@inside
 
[sr_territory@inside]
on_actor_outside = sr_territory@outside
territory_hit = {-bar_dolg_territory_1_hit} %+bar_dolg_territory_1_hit%, {-bar_dolg_territory_2_hit}
%+bar_dolg_territory_2_hit%, {-bar_dolg_territory_3_hit} %+bar_dolg_territory_3_hit%
territory_death = {-bar_dolg_territory_kill} %+bar_dolg_territory_kill%

You can see that when the player is inside the restrictor, the number of hits is counted, and also whether anyone died is considered. Since the scheme only works with the player, only the player's death and hits are counted.

Sr_mapspot

When entering a restrictor, it highlights itself on the map.

Parameters:

hint: hint id in string table (required)
location: highlight type name; crlc_small by default

Example:

[logic]
active = sr_mapspot
 
[sr_mapspot]
hint     = “gar_swamp”
location = crcl_big

Sr_particle

This scheme shows particles, static or moving, in the given place at the given time. It works like this:

For a particle system with a camera path

[sr_particle]

name = explosions\campfire_03: particle system name
path = particle_test.anm: camera path
mode = 1: (required !!!)
looped = true/false: whether the partcle playback should loop

(must have extension ANM !!!) Here particles will silently move along a path.

For a particle system with a regular patrol path

[sr_particle]

name = explosions\campfire_03: particle system name
path = part_points: patrol path name
mode = 2: (required !!!)
looped = true/false: whether the particle playback should loop

You can set the s=<sound scheme name> and d=<delay time in milliseconds> at waypoints. A sound will be rendomly chosen from the specified scheme. Sound does not loop and plays only once. As a result, particles play in all waypoints simultaneously (with delay, as described above).

When looped=true particles will play again after finishing, but without a delay. There will be no particle_end signal. When looped=false there will be a signal when all particle sources finish playing.

Condition list is supported. If a restrictor switches to a different section, then particles stop playing automatically and their sounds die. This restrictor is an object tracking particles, and there is no reason for the player to enter it.

Sr_sound_act

Scheme playing sounds in the actor's head. Various PDA conversations and other fakes.

[sr_sound_act]

snd = ambient\random\new_drone1: sound file name
delay = 2000: delay before playback
delay_max = 4000: a random interval between delay and delay_max will be used
on_signal = sound_end | nil: we can move to another section on signal
theme = &lt: from ph_sound_themes
stereo = true/false: When this parameter is set for a file that is set using the single parameter snd, the sound scheme will be automatically appended with suffexes _r and _l for left and right channels, and all that junk will be played; false by default

If a theme is set, then the sound will loop, randomly choosing one of the sounds from the theme. If a sound is set, then it is played once. The scheme supports a condition list.

Sr_timer

Example of use:

[logic]
active = sr_timer@1
 
[sr_timer@1]
type        = dec
start_value = 10000
on_value    = 0 | sr_timer@2
 
[sr_timer@2]
type     = inc
on_value = 15000 | nil %+info1%

Fields:

type: counter type: inc or dec; inc by default
start_value: starting value in REAL milliseconds. For decrementing counters, settings this is required. For incrementing it is 0 by default.

Switches from section sr_timer can be caused by regular conditons (on_timer, on_info) or by the special condition on_value. In general, on_value should be used for performing some actions based on the counter's state. For example:

on_value = 5000| %+info1% | 1000| %+info2%

Sr_psy_antenna

Zones with this section can control psy-control effects (on Yantar and Radar). Right now you can control radiation intensity and hit intensity.

To use: set the zones, in each zone specify percentage increase/decrease for radiation and intensity. Zones can be nested inside each other and intersect each other.

eff_intensity: increase or decrease % of radiation relative to base intensity
hit_ intensity: increase or decrease % of hits relative to base intensity

Example of a zone that adds 70% of radiation:

[logic]
active = sr_psy_antenna
 
[sr_psy_antenna]
=_intensity    = 70
hit_ intensity = 70

Example of a zone that removes 30% of radiation:

[logic]
active = sr_psy_antenna
 
[sr_psy_antenna]
intensity = -30

Sr_teleport

A teleporter. Is configured like this:

[logic]
active = sr_teleport
 
[sr_teleport]
timeout = 0
 
point1 = point1
look1  = look1
prob1  = 10
 
point2 = point2
look2  = look2
prob2  = 20

where:

timeout: delay in milliseconds before the teleporter activates
point: one-point patrol path to teleport into
look: one-point patrol path to turn towards

Settings for destination points with weights follow. That is, in the example above the probability of teleportation into the second point is twice as high as into the first. The maximum number of destination points is 10. Teleporters should be set together with a special anomalous zone.

Sr_sleep and sleep configuration

Makes it possible to set sleep zones.

[sr_sleep]

cond = <condlist>
type = nightmare/normal/happy/all: Sets the type of sleep allowed in the current zone; affects only non-storyline sleep; all by default
dream_prob = <number 0 from 100>: probability of non-storyline dreams in the given zone; 80 by default

The optional field cond sets a condition for sleeping in this zone. There is currently an indicator for zones in which sleep is allwed. In bottom left corner a small lungs icon is shown upon entry into such a zone. This icon will possibly be replaced later.

Dreamcast can be either storyline or not. Storline dreams are played when necessary conditions are met. Regular dreams are played when there is no storyline dreams or none of the conditions for them have been met. It is possible to set probabilty of playing regular dreams in general, and also set likelyhood of seening any given dream separately. Regular dreams can have set types, and types can be used to limit sleeps in sr_sleep.

Dream settings are set in file misc\dream.ltx

Videos section

Fields set paths to video fiels with dreams.

Dreams section feilds

regular_probability = <number from 0 to 100>: probability of playing regular dreams in general
regular: a list of sections with settings for regular dreams
scene: a list of sections with settings for storyline dreams

Settings for regular dreams

dream: name of a field from the videos section
probability = <number greater than 0>
type = nightmare/normal/happy

Settings for storyline dreams

dream: name of a field from the videos section
cond = <condlist>
to_regular = <probability, type>: an optional field; gives you the ability to convert a storyline dream into a regular dream; probability and type are analogous to those for regular dreams

Sr_cutscene

This scheme is for animating camera with certain effects.

(pp_effector). Sequence of actions carried out by the scheme consists of immediate placement of the player into the beginning of that path and orientation of his sight towards the look path. The player looses control until cam_effector finishes.

[sr_cutscene]

point = <path name>: path into the beginning of which the player is placed
look = <path name>: path towards which the player faces
pp_effector = <effect filename>: file located in folder gamedata\anims and containing an effect (filename is written without the extension)
cam_effector = <camera animation filename>: file located in the folder gamedata\anims\camera_effects and containing a camera animation (filename is written without the extension)

Various settings for objects

[ph_idle]

A section for all physical objects. Supports a condlist. Could be used to transfer objects into when needed.

Doors, [ph_door] section

All folding doors work the same way.

locked = false\true: false by default
Closed = false\true: true by default
tip_open = (if locked == false, then tip_door_open, else tip_door_locked): the tip that shows up when the door is targeted if the door is closed
tip_close = (if locked == false, then tip_door_close, else empty value): the tip that shows up when the door is targeted if the door is open
snd_init: the sound that will be played when the scheme is initiated
snd_open_start: the sound that will be played on attempts to open the door
snd_close_start: the sound that will be played on attempts to close the door
snd_close_stop: the sound that will be played when the door is closed shut

Example:

If you need to make a door that will open with a click on some event, then you can use the snd_init field and switching schemes. In this example, when the ph_door@unlocked is iniated, the snd_init sound is played, that is, trader_door_unlock:

[logic]
active = ph_door@locked
 
[ph_door@locked]
locked         = true
snd_open_start = trader_door_locked
on_info        = {+esc_trader_can_leave} ph_door@unlocked
 
[ph_door@unlocked]
locked          = false
snd_init        = trader_door_unlock
snd_open_start  = trader_door_open_start
snd_close_start = trader_door_close_start
snd_close_stop  = trader_door_close_stop

File \gamedata\scripts\ph_door.script

Buttons, [ph_button] section

When you press a button, this switches sections and gives out an infoportion.

[logic]
active = ph_button@locked
 
[ph_button@locked]
anim_blend  = false
anim        = button_false
on_press    = ph_button@unlocked %+cit_jail_door_opened%

on_press: what happens when the button is pressed
anim: animation to play when the button is pressed
anim_blend: smooth animation

File \Gamedata\scripts\ph_button.script

tooltip: is there to show a textual hint when the button is targeted. The hint is needed to at least explain that it can be presseed.

Example:

[logic]
active = ph_button@active
 
[ph_button@active]
anim     = lab_switcher_idle
tooltip  = tips_labx16switcher_press
on_press = ph_button@deactivated %+terrain_test%
 
[ph_button@deactivated]
anim = lab_switcher_off

To make sure the message stays valid with different keyboard settings, you should use tokens. For example:

<string id="tips_labx16switcher_press">
	<text>To disable this magical contraption press ($$ACTION_USE$$)</text>
</string>

Here is an example of a button that does not work each time, but only if a certain condition is met:

[logic]
active = ph_button@locked
 
[ph_button@locked]
anim     = button_false;  an animation for disabled buttons
on_info  = {+val_prisoner_door_unlocked} ph_button@unlocked
on_press = ph_button@unlocked %+val_prisoner_door_unlocked%
 
[ph_button@unlocked]
anim     = button_true
on_info  = {-val_prisoner_door_unlocked} ph_button@locked
on_press = ph_button@locked %-val_prisoner_door_unlocked%

Projector

In points of the path towards which the projector points you should write:

sl=<projector name>

For instance: wp00|sl=esc_sl1.

Then when the character turns towards this point, so will the projector.

Combination locks

When a certain code is entered, gives out an infoportion.

[logic]
active = ph_code@lock
 
[ph_code@lock]
code    = 1243
on_code = %+infoportion%

File: \gamedata\scripts\ph_code.script

Ph_gate

Same as ph_door, but for gates made from two halves.

state

state in which the door is in after initialization

open
closed
none: current (default or remaining after the previous scheme)

locking

none by default

stick

whether the door is attracted to the farmost positions (this is still being set up)

soft

the door is blocked by force, so it can be forced or broken through

open: blocked in open state
closed: blocked in closed state
none: unused

hard

the door is blocked with boundaries; can only be broken

open: blocked in open state
closed: blocked in closed state
none: blocked in current state

none: the door is unblocked

General parameters:

left_limit, right_limit: sets the angle [0-180] for opening each half of the gate; 100 by default
breakable = true/false: determines whether the gate can be broken; true by default

The sound parameters are the same as for ph_door.

Examples:

[ph_gate@locked] ; blocks in open mode, undestructable
state      = opened
locking    = soft
left_limit = 130
rigt_limit = 60
breakable  = false
 
[ph_gate@opened]
state   = opened
locking = stick
 
[ph_gate@closed]
state = closeded

File: \gamedata\scripts\ph_gate.script

Ph_sound

Is specified for every physical object to emit sounds (was initially made for swearning).

[ph_sound]

snd: name of a theme from file sound_theme.script from table ph_snd_themes
looped = true/false
min_idle: minimum idle time before the sound is turned on, in ms
max_idle: maximum idle time before the sound is turned on, in ms
random: if true, then random sounds will be picked from the theme

Note! Setting random=true and looped=true will crash the game.

A condition list is also supported.

This scheme works through the ass, so the looping sound will continue playing, even if the object becomes nil. This means that you should create a new section to play a single short sound, after which (since it will play again and again) set on_signal=sound_end|nil.

An example of such twisted logic:

[logic]
active = ph_sound
 
[ph_sound]
snd              = gar_seryi_shooting
looped           = true
max_idle         = 5000
on_actor_in_zone = gar_seryi_factory| ph_sound@end
 
[ph_sound@end]
snd       = gar_seryi_shooting_2
looped    = false
on_signal = sound_end| nil

Besides, the sound scheme is created in a particular way. In sound_theme.script at the beginning of the file there is section ph_themes in which themes for physical objects are described.

For example:

ph_snd_themes["gar_seryi_shooting"] = {[[characters_voice\human_01\scenario\garbage\distance_shooting]]}

Besides, (undocumented feature) ph_sounds can be set for restrictors. Although, no one is responsible for this working correctly.

File: \gamedata\scripts\ph_sound.script

Ph_force

This scheme allows one to kick an object in a given direction. Is written in custom data of an object.

force: force applied to the object, measured in dead badgers
time: durationi of time the force is applied to the object, measured in seconds
delay: delay in seconds before the force is applied
point: name of a patrol path that is to be used as the target (where the object will point)
point_index: index of a point of the patrol path towards which the object will fly

Ph_on_death

Scheme for tracking destruction of physical objects and producing various effects.

Example:

[logic]
active = ph_on_death
 
[ph_on_death]
on_info = %effects%

To be used only with destructable physical objects.

Ph_car

Settings to let the player control a car.

[ph_car]

usable = condtion list: list of conditions returning true (by default) or false

Example:

[logic]
active = ph_car
 
[ph_car]
usable = {+val_actor_has_car_key}

Based on this scheme, you can make a car that will start only if the actor has a key for it.

Ph_heavy

Is set for physical objects, which are forbidden for throwing by burers and poltergeists. For instance, they should lay in a certain place (such as storyline-related documents) or are too massive to be thrown nicely. В кастом дате пишем:

[ph_heavy]

Ph_oscillate

This scheme is meant for gentle rocking of physical objects (lamps, hanging zombies, etc).

Logic example:

[ph_oscillate]
joint  = provod ; name of the bone to which force is applied
force  = 5      ; force (in newtons)
period = 1000  ; time at which force is applied

The force is applied to a bone of the object with linear increase. That is, during a period of time the force grows from 0 to the specified magnitude. After this a pause is made (force is not applied) for the time period/2. After the pause ends, the force is applied at the same place, but in opposite direction.

Smart terrains and gulags

Smart terrain

By a smart terrain we mean a zone that, upon entry, captures a stalker in a gulag and makes him do work for this gulag. After a period of time he escapes the gulag and walks free.

How to set a smart terrain? For every smart terrain you have to:

Set a smart terrain with the required shape. It is not recommended to make them large, since size affects performance.
Specify the settings in its custom data.
Set paths for the corresponding behavior schemes.

Custom data parameters:

[gulag1]

type
capacity: max number of people
offline: if the gulag can go offline; false by default
squad: the squad to set for all stalkers in the gulag (level #)
groups: comma-separated list of groups
stay: duration of time the NPC remains under the smart terrain; permanently by default
idle = min, max: duration of time the smart terrain remains active after the last NPC leaves
cond: list of conditions necessary to create a gulag; {+info -info = func !func} - if the condition is not met, the gulag is disbanded and all its inmates begin to be controlled by logic specified in their custom_data

Gulag type should not be quoted. If either squad or groups is not set, then the corresponding properties of stalkers will not change. All time is set in hours of game time and can be fractional

Path names should always start with the name of the given smart terrain. For instance: esc_smart_ambush_vagon_sleep.

If paths for a smart terrain are for several people (campers, walkers), then their names should always end with a number (esc_smart_ambush_vagon_walk1, esc_smart_ambush_vagon_walk2).

There can be several gulags under a single smart terrain. They can be set in several sections [gulag2], [gulag3], etc. After a stalker enters the smart terrain, one of the available gulags will be chosen at random.

Standard smart terrain types

If you want to prevent a stalker from being captured, add the following line to his custom data:

[smart_terrains]
none = true

If the stalker is already under some smart terrain's control, he will ignore the others.

campers

Custom data:

[gulag1]
type = campers
capacity = от 1 до 3

Paths:

camper_walk1, camper_look1
camper_walk2, camper_look2
camper_walk3, camper_look3

walkers

Could be used to conduct searches, and lots of other stuff.

Custom data:

[gulag1]
type = walkers
capacity = от 1 до 3

Paths:

walker_walk1, walker_look1
walker_walk2, walker_look2
walker_walk3, walker_look3

search

Custom data:

[gulag1]
type = search
capacity = 1

Paths:

search_walk, search_look

Works like this:

The character walks through waypoints, looks about.
Stops at certain points, searches (caution, search, hide)
Utters some phrases while at that

rest

A stalker switches between sleeper, walker, and rest (eats, drinks vodka).

Custom data:

[gulag1]
type = rest
capacity = 1

Paths:

rest – two-vertex path (possibly one). He sits in one, looks towards the other.
sleep - two-vertex path (possibly one). He sleeps in one, looks towards the other.
rest_walk, rest_look

Gulags

A gulag is a means of joining several stalkers under centralized control. Main features:

A gulag has a task list. A task is a set behavioral scheme, or a chain of schemes.
Tasks have priorities.
A gulag assigns entering stalkers to jobs with highest priority first.
Gulags have states. Each condition corresponds to a unique set of tasks, different from the set of any other condition.

A gulag is created like this:

1. First, a list of states for the gulag has to be determined: day, night, calm, active, etc. Simple gulags might have only one state, a complex one should have many. This introduces more variety and looks better.

2. Determine the maximum number of people that can be controlled by the gulag. That is, determine the gulag's capacity. It should be such that in any state the gulag should be able to find a task for every person.

3. For every state the gulag should have a list of tasks. These tasks can be active (centry, patrol, etc) or passive (sitting at a campfire, sleep). Each job has its own priority. Correspondingly, passive tasks should have lower priority.

4. Use the editor to set the number of people to be in the gulag and cover it with a smart terrain (it is an error to use space_restictor). The terrain should be given a meaningful name. This name will also serve as a prefix for all patrol paths for this gulag. For instance, if you call the terrain esc_blockpost, then all patrol paths should start with this prefix, as esc_blockpost_guard_walk, for instance. Custom data for the zone should contain settings for the gulag.

[gulag1]

type
capacity: maximum number of people
offline = true/false: whether the gulag can go offline
squad = squad: the squad stalkers under the gulag are assigned to
groups: comma-delimeted list of groups
stay: duration of time the NPC remains under the smart terrain; permanently by default
idle = min, max: duration of time the smart terrain remains active after the last NPC leaves
cond: list of conditions necessary to create a gulag; {+info -info = func !func} - if the condition is not met, the gulag is disbanded and all its inmates begin to be controlled by logic specified in their custom_data
respawn: respawn name (calls the respawner with the given name every time someone from the smart terrain starts working on a task)

Capacity should always be set. It should be less than or equal to the number of tasks.

Gulag type should be unquoted.

The offline field could be used to prevent the gulag from going offline. That is, it can exist in offline mode, but cannot go into it.

Gulag type should not be quoted. If either squad or groups is not set, then the corresponding properties of stalkers will not change. All time is set in hours of game time and can be fractional

5. In script \gamedata\scripts\gulag_<level name>.script you should set the condition under which stalkers are captured by the gulag. The function checkNPC should be appended with the condition:

if gulag_type == "gar_dolg" then
	return npc_community == "dolg"
end

This function takes two parameters: gulag type and character's community. In this case, the the gulag with type gar_dold will accept all characters in faction Dolg.

6. In file \gamedata\scripts\gulag_<level name>.script you should desribe how gulag states should switch.

function loadStates(gname, type)

Takes the name of a zone and gulag type. The gulag's state is described as a function returning gulag state number. For example:

if type == "gar_maniac" then
	return function(gulag)
		if level.get_time_hours() >= 7 and level.get_time_hours() <= 22 then
			return 0  -- day
		else
			return 1  -- night
		end
	end
end

In this case, if it is between 07 and 22 hours, the gulag is in daytime mode, otherwise in nighttime mode.

8. In file \gamedata\scripts\gulag_<level name>.script you should describe a gulag's tasks. The function loadJob loads all the allowed tasks. The function itself takes the following parameters:

function loadJob(sj, gname, type, squad, groups)

sj: the gulag task table itself
gname: smart terrain name; used as a prefix
type
squad, groups: squad and group table, if we need to override the native stalker groups with some other ones. For each task you should set a squad and a group to assign a stalker to upon recieving a task.

Approximate description of gulag tasks:

The following gulag describes behavior of a single person, but there is usually many more. The given person in zero state (daytime) performs one task, in first state (nighttime) another task.

--' Garbage maniac
if type == "gar_maniac" then
	t = { section = "logic@gar_maniac_camper",
	idle = 0,
	prior = 5, state = {0},
	squad = squad, groups = groups[1],
	in_rest = "", out_rest = "",
	info_rest =  ""
	}
	table.insert(sj, t)
	t = { section = "logic@gar_maniac_sleeper",
		idle = 0,
		prior = 5, state = {1},
		squad = squad, groups = groups[1],
		in_rest = "", out_rest = "",
		info_rest =  ""
	}
	table.insert(sj, t)
end

Field descriptions:

Idle: pause between repeated execution of the same tasks. There is no pause in this case. Pause is usually set for patrols.
Prior: task priority. At first stalkers occupy the higher priority tasks. The higher the number, the higher the priority.
In_rest, out_rest: restrictors set for the character for this task
Section: section in \gamedata\config\misc\gulag_<level name>.ltx, in which the real behavior scheme corresponding to this task is set.; the stalker's group will be chosen from the group array set in custom data. The array is indexed starting with 1.
Info_rest: sets the name of the restrictor, inside of which the person performing the task is guarded from all dangers

The task description may also contain additional conditions for when the stalker can recieve the task. For example:

predicate = function(obj)
	return obj:profile_name() == "soldier_commander"
end

That is, the given task can only be carried out by a person with the soldier_commander profile.

9. В:\gamedata\config\misc\gulag_<level name>.ltx you should specify which behavior schemes correspond to each task. FOr instance, for the aforementioned gar_maniac:

;----------------------------
;-- GARBAGE MANIAC
;----------------------------
[logic@gar_maniac_camper]
active = camper@gar_maniac_camper
 
[camper@gar_maniac_camper]
path_walk = walk1
path_look = look1
 
[logic@gar_maniac_sleeper]
active = sleeper@gar_maniac_sleeper
 
[sleeper@gar_maniac_sleeper]
path_main = sleep
wakeable  = true

Here settings correspond to regular stalker custom data, with the followin differene:

paths should be specified without a prefix. THat is, if the zone was called gar_maniac, a path on the level might be called gar_maniac_walk1, but gamedata\config\misc\gulag_<level name>.ltx should be specified as simply walk1.
section names should be appended with @ and the gulag name and, possibly, additional information (such as walker2@rad_antena_gate)
for each taask, logic section names should be appended @ and the gulag name, additional data, and active behavior scheme for (such as logic@rad_antena_gate_walker2

There is no leader field for gulag tasks. There is the dependent field. A task can only be taken if the dependent task is taken first. For instance, follower can be set only after someone is set to work as the leader (leader's name is now in the dependent field). Correspondingly, the task priority for tasks on which others dpeend should be greater than theirs.

New smart terrain capabilities

New capabilities

Does not keep stalkers online. The standard online radius works.
Stalkers go to the nearest task.
Stalkers go to their workplaces without respect to whether they are online or offline.
In offline an ST works the same way as in online: switches states, allocates tasks.
Stalkers can be given conditions for entering certain STs (see below). If a stalker enters an ST, then he will remain in it until his time elapses and the condition is met.
Tasks can be located in different levels.
Scripting ST zone is not used for capturing characters anymore.
Simulation is manifested in migration of characters between different STs.

Allowing characters to enter certain ST

Permissions for characters to enter sertain STs are set in the [smart_terrains] section. In it you can set pairs ST_name = condlist, such as:

[smart_terrains]
strn_1 = condition1
strn_2 = condition2

If a condition is met for some smart terrain, it is called exclusive.

If a character has at least one exclusive smart terrain, then he will only agree to go to that one.

If he has no exclusive ones, he will agree to go to any.

There is a reserved combination none=true. If it is set, then the character will not go to any ST. This character will only rely on his own logic.

It is also possible to specify who is accepted by a ST. In addition to the old mechanism (function checkNpc() in files gulag_*.script) you can write in custom data for ST:

communities = group1, group2, ...

If this field is not set, then the old mechanism is used. If it is set, then the ST will only accept characters from the specified groups (but the old mechanism will also be called).

Modifying predicate() functions

In these functions a character information table will be passed instead of game_object. There are fields:

name
community
class_id
story_id
profile_name

If you only need snipers to take the task, write the following in the predicate:

predicate = function(npc_info)
	return npc_info.is_sniper == true
end

Online and offline work modes

t = { section = "logic@ЧЧЧЧЧЧЧЧ",
	idle = 0,
	prior = 5, state = {0}, squad = squad, group = groups[1],
	online = true,
	in_rest = "", out_rest = ""
}
table.insert(sj, t)

Options for this field:

online = true: the character is always online on this job
online = false: the character is always offline on this job
online not set: the character might switch between online and offline as deems appropriate

A more accessible description of smart terrains

Now, smart terrains for designers. That is, no LUA, just plain English.

To move a smart terrain to a new scheme, do the following:

Change inside custom data [gulag1] -> [smart_terrain]

In custom data of comrades by smart terrain write:

[smart_terrains]
sar_monolith_sklad(gulag name) = {condition list}
[smart_terrains]
none = true

Helicopter logic

General information

The helicopter has "logic"
The helicopter does not react to anomalies
The helicopter cannot collide with level geometry until shot down
Hits in the area of the cabin in which the first pilot sits are dozens of times more damaging for the helicopter
Like stalkers, the helicopter has an all-purpose combat scheme
Helicopter pilots have replicas for the following events: hit, enemy sited, damaged (smoking), falling.

heli_move scheme

General information

Allows the helicopter to fly along a patrol path, control speed, hover, shoot at various targets. The scheme must have path_move set — the path along which the helicopter will fly. It may contain just one point, if the helicopter should hover. It is allowed, but not necessary to set path_look — the path into the points of which the helicopter should look.

The vertices of these points can be anywhere within the boundaries of the level's bounding box. They do not depend on AI nodes.

The helicopter will fly along points without respect of connections between them. It will fly from vertex to vertex in order of increasing number (that is, in the order they were set in the level).

The helicopter will try to follow path vertices exactly. If needed, it can fly precisely under a bridge.

The helicopter will fly as fast as possible. That is, if you set its speed at the next vertex at 10 m/s, while its maximum speed is set to 30 m/s, then it will not start flying 10 m/s right away. It will first speed up to 30 m/s, then on approach of the vertex it will slow down such that it gets to the vertex at 10 m/s.

If a path_move vertex has some flags, the helicopter will look into any of the path_look vertices for which the same set of flags is specified. It will start turning towards the point starting at the previous point of the path. The helicopter cannot currently look towards several path_look points while hovering.

Settings

engine_sound = true/false
invulnerable = true/false
immortal = true/false: if true the helicopter will calculate damage, but not recieve it
mute = true/false: disable default helicopter phrases
rocket_delay = msec: is taken from ltx by default; currently 1250
default_velocity = m/sec: the helicopter speed, unless other parameters are set

path_move point parameters:

e: sets enemy. The helicopter will start firing at this target starting at the previous vertex. If the value is not set, it will fire at the point form path_look corresponding to the given vertex. If e=actor (or e=a) is set, then fire will target the actor. If e=number fire will target the object with the given id.
w: which weapon to use. The possible values are: w=1 to use the machien gun only; w=2 to use rockets only. Shoots with everything by default.
v: maximum speed in m/s on the path from the given vertex to the next. If this parameter is not set, the value from helicopter.ltx is taken by default.
dv: destination velocity in m/s that the helicopter should have on arriving at the given vertex
die: kill the helicopter
flame: set the helicopter on fire, as if it was damaged

path_look point parameters:

e: works the same way as in path_move. The difference is that the helicopter will only start firing at it when it gets to the point of path_move that corresponds to the given vertex.
w: works the same way as in path_move
t: duration of time during which the helicopter will look at the given point. If this parameter is nto set, then the helicopter will fly by without stopping, but will try to face the vertex while moving.

All-purpose combat scheme

General information

In the general combat scheme, a helicopter is not tied to a path.

The helicopter does not see anyone. The helicopter can only find someone upon recieval of damaged or from a parameter in custom data.

The helicopter shoots at an enemy upon detection. Until then, looks for him, circling the points of last citings. If it does not see the enemy for a long time — forgets him. If the enemy is specified in the current behavior section, he will not be forgotten while the section is in effect.

Settings

There is no separate section for this behavior scheme. Therefore, settings are given in the current behavior scheme:

combat_ignore = true/false

true means ignore hits. That is, the helicopter will not try to "take revenge" on whoever hits it.

combat_enemy = nil/actor/StoryID

This parameter could be used to give the helicopter a specific enemy:

nil: no enemy
actor: player
SID: id number of the enemy

combat_use_rocket = true/false: Whether the helicopter is authorized to use rockets.
combat_use_mgun = true/false: Whether the helicopter is authorized to use the machine gun
combat_velocity = <number>: Speed in m/s at which the helicopter will circle.
combat_safe_altitude = <number>: Height, relative to the highest point of the geometry of the level, below which the helicopter will not decend (can be negative)

The helicopter has the xr_hit scheme. It words the same way as for stalkers. There is a group of functions for working with a helicopter and its custom data in xr_effects:

heli_set_enemy_actor: make the actor the helicopter's enemy
heli_start_flame: set the helicopter on fire
heli_die: destroy the helicopter

Meet_manager

Syntax

[logic]
meet = meet
 
[walker]
meet = meet
 
[meet]
meet_state     = 30| state@sound| 20| state@sound| 10| state@sound
meet_state_wpn = 30| state@sound| 20| state@sound| 10| state@sound
victim         = 30| nil| 20| actor
victim_wpn     = 30| nil| 20| actor
use            = self
use_wpn        = false
zone           = name| state@sound
meet_dialog    = dialog_id
synpairs       = state@sound|state@sound
abuse          = true/false

All of the meeting settings are in a single section. The logic section or the current scheme can be used which section to use. The section set in the logic section affects processing of meetings for free stalkers.

Fields:

meet_state, meet_state_wpn

sets animation and voicing for the character, depending on distance to the actor; for when the actor is unarmed or armed, respectively

victim, victim_wpn

sets the object at which the character will look; can be:

nil: does not look anywhere
actor: looks at the player
story_id: number of the character at which to look

use, use_wpn: use settings; can be one of: true, false, self; if self is used, the NPC will use the player
zone: contains a set of restrictor names, as well as animations an sounds the NPC will play, if the player is sighted within a restrictor
meet_dialog: starting dialog for the NPC
synpairs: contains a set of pairs body_state@sound_theme. If at some set of conditions the meeting plays this condition and this sound theme, they will be synchronized via random body state animations
аbuse: true by default; if false, unused opponent will not become bitter

Any line can be set via a condlist. ( {+info1 –info2} ward %+info% )

To make meetings easier to set up, there is a simplified default:

[walker]
meet = default_meet

You do not have to set the [default_meet] section itself. All of the settings will be used as default, anyway.

Now to explain how all of this can be used to construct the reaction to the actor that you need.

Situation 1

The character beckons us with his hand, on approach asks us to hide our weapon, then agrees to talk.

[meet]
meet_state     = 50| hello@talk_hello| 20| wait@wait| 10| ward@wait
meet_state_wpn = 50| hello@talk_hello| 20| threat@threat_weap
victim         = 50| actor
victim_wpn     = 50| actor
use            = true
use_wpn        = false

Situation 2

On sight the stalker asks us to hide our weapon. After this he approaches and talks to us. If we start to walk away or take the weapon out — starts shooting at us.

[meet]
meet_state     = 50| {+info} threat_fire %= killactor%, walk@ {+info} talk_abuse, wait | 10 | walk %+info%; wait | 2 | threat;state
meet_state_wpn = 50| {+info} threat_fire %= killactor%, threat@ {+info} talk_abuse, wait
victim         = 50| actor
victim_wpn     = 50| actor
use            = {-info2} self, false
use_wpn        = false

Here:

info: infoportion that says that we have lowered the weapon or are close enough to the NPC
info2: infoportion that is set in the dialog and records that the character has said to us everything he wanted
Killactor: function in xr_effects that makes the NPC hostile

Situation 3

The character walks along a patrol path on camp guard. If the player has a pass to the camp, greets him and lets him pass, otherwise first warns, then, if the player gets into the camp, becomes hostile. The dialog depends on whether the player has a pass into the camp or not.

[camper]
path_walk = path_walk
path_look = path_look
meet = meet
 
[meet]
meet_state     = 30| {+info} wait, threat@ {+info} talk_hello, threat_back
meet_state_wpn = 30| {+info} wait, threat@ {+info} talk_hello, threat_back
victim         = 30| actor
victim_wpn     = 30| actor
use            = true
use_wpn        = true
zone           = warnzone| {-info} threat@ {-info} threat_back|kampzone| {-info} true@ {-info} talk_abuse
meet_dialog    = {+info} dialog1, dialog2

Here:

true: attack the player instead of animation
info: infoportion saying that we have a pass to the camp
warnzone: restrictor within which he warns us
kampzone: restrictor in which he kills us
dialog1: starting dialog if we have a pass
dialog2: starting dialog if we do not have a pass

Default settings

By default, meeting has the following parameters:

meet_state     = 30|hello@hail|20|wait@wait
meet_state_wpn = 30|backoff@threat_weap
victim         = 30|actor
victim_wpn     = 30|actor
use            = true
use_wpn        = false
syndata        = hello@hail|backoff@threat_weap

Note: if you need to make it so that a stalker does not speak to the player in this section, set meet=no_meet.

Minimap marks

There is a way to avoid showing stalkers on the minimap and the map (hide blue and red dots). For this, the logic section or the current scheme should have the parameter:

[camper]

show_spot = false: to hide stalkers in this section

[walker]

show_spot = {+info1} false: a stalker will be hidden if he has infoportion info1

Function arguments

Below we list the set of functions that can be accessed from custom data and to which variables can be passed.

xr_conditions

fighting_dist_ge(p): all-purpose function for combat_ignore, checks distance to the player (in meters)
distance_to_obj_le(sid:dist): checks distance to the object with the given story_id; this can be used, for instance in the follower section to switch to another section when a stalker walks within a certain distance of the leader (the leader is then somwehere in remark). This situationi occurs when one stalker should approach another while we do not know their positions. If this is used in the follower section, dist should be larger than the follower's distance, since if they are the same, this function will not always work.
health_le(health): checks that NPC's HP <= health
heli_health_le(health): like the above, but for a helicopter
enemy_group(group1:group2:...): checks membership of the enemy to a group (we did not check whether it works correctly)
hitted_by(sid1:sid2:...): checks if a hit was made by one of the listed NPCs. The NPCs are set using their story_id. This function is convenient for in the hit section. Example:

[hit]
on_info = {=hitted_by(407:408)} %+val_escort_combat%

killed_by(sid1:sid2:...): like the preceeding, but for a kill; used in the death section
is_alive(sid)
is_alive_one(sid1:sid2:...)
is_alive_all(sid1:sid2:...): checks if one, one of serveral, or all NPCs in a list are alive
is_dead(sid)
is_dead_one(sid1:sid2:...)
is_dead_all(sid1:sid2:...): like the preceeding, but for death
check_fighting(sid1:sid2:...): checks if any from the list are enemies of the current NPC; typically used in combat_ignore_cond
gulag_empty(gulag_name): checks if a gulag is empty or non-existant
gulag_population_le(gulag_name, num): checks if the number of people in the gulag is <= num
gulag_casualities_ge(gulag_name:num): checks that the casualties in the gulag are => num; Note! Gulag casualties are not reset, so you should be careful with this function
signal(string): checks if the NPC has the given signal set in the current scheme

xr_effects

heli_set_enemy(story_id)

make the NPC with the given story_id an enemy of the helicopter. Only one enemy can be set in one section.

set_gulag_enemy_actor(gulag_name)

make the actor an enemy of the current gulag

hit_npc(direction:bone:power:impulse:reverse=false)

incur a hit to the NPC. Parameters:

direction = string/number: the name of path in the direction of first point of which to hit or the story_id number of a character from which the hit originates
bone = string: the name of the bone that is hit
power
impulse
reverse = true/false: whether the direction should be reversed; false by default

Example:

[death]
on_info = {=killed_by(404)} %=hit_npc(404:bip01_spine1:100:2000)%, {=killed_by(405)} %=hit_npc(405:bip01_spine1:100:2000)%

set_friends(sid1:sid2:...)

set_enemies(sid1:sid2:...)

set the character with the listed story_id numbers friends or enemies of the given NPC

play_snd(snd_name:delay=0)

play a sound in the actor's head

snd_name

sound path relative to the sounds folder

delay

delay before playback; 0 by default, to start playback immediately

play_snd_now (sid:snd_name)

play the sound from the given object

the sound is played from the object with the given story_id without delay with volume 1; the file name, not sound schme name is specified

hit_obj(sid, bone, power, impulse, hit_src=npc:position())

incur a hit on the object with the given story_id. Is distinguished by being able to be specified in any custom data. Parameters: actor, npc, p[sid, bone, power, impulse, hit_src=npc:position()]

sid: story_id of the object to incur the hit on
bone: name of the bone that is hit
power
impulse
hit_src: optional; the waypoint from which the hit is made on the object; if it is not specified, then the position of the object calling the function is taken

actor_has_item(section): check if the player has this object; the check is made via the ltx section

Functions for working with HUD

disable_ui_elements(...), enable_ui_elements(...)

enables/disables HUD elements

weapon: show/hide hands with the weapon
input: enable/disable keyboard
hud: show/hide screen indicators
all: enable/disable all elements

Example:

on_info = %=disable_ui_elements(weapon:input)%

There are also shortened versions:

disable_ui, enable_ui: called without parentheses and parameters; analogous to the calls disable_ui_elements(all), enable_ui_elements(all), respectively

Example:

on_info = %=enable_ui%

Function for running camera_effector

run_cam_effector(file_name)

file_name: animation file name from folder s:\gamedata\anims\camera_effects without extension

Example:

on_info = %=run_cam_effector(prison_0)%

Functions for running postprocessing

There are two functions for working with postprocessors:

run_postprocess(file_name:id:loop)

starts posprocessing

file_name: name of a postprocessing file (without extension) from folder s:\gamedata\anims. Write without the extension.
id: number of the postprocess; optional; is used in stop_postprocess
loop - true/false: whether the posprocess should loop; optional; false by default

stop_postprocess(id)

forces postprocessing to stop

id: number of the postprocess set in run_postprocess

Function for emptying the actor's inventory into a certain spot

drop_actor_inventory(path_name)

Example:

on_info = %=drop_actor_inventory(drop_point)%

Sound group configuration

The way to create sound groups:

Each character is considered to be in a unique soundgroup by default.
To put several characters into a single sound group, the logic section of each one must contain soundgroup = <text string>
Sound groups must be unique within each level, or, better yet, within the whole game. For this, add level and scene identifiers to the name of the group, as in: soundgroup = bar_dolg_kampfire1.
Characters sitting at a camp or walking together in patrol groups or in such similar situations should be put into sound groups.
To avoid errors, all NPCs logically belonging to a group should have the same team, squad, group.

Example:

[kamp@esc_bridge_post1]
center_point = kamp_point
soundgroup   = esc_bridge_soldiers

Author

GSC Game World

Source

Retrieved from "https://legacy-sdk.stalker-game.com/en/index.php?title=Logic"

Category: Articles

 [wounded]
-hp_state           = HP|condstate@condsound|HP|condstate@condsound
+hp_state          = HP|condstate@condsound|HP|condstate@condsound
-hp_state_see       = HP|condstate@condsound|HP|condstate@condsound
+hp_state_see      = HP|condstate@condsound|HP|condstate@condsound
-psy_state          = PSY|condstate@condsound|PSY|condstate@condsound
+psy_state         = PSY|condstate@condsound|PSY|condstate@condsound
-hp_victim          = HP|condvictim|HP|condvictim
+hp_victim         = HP|condvictim|HP|condvictim
-hp_cover           = HP|condbool|HP|condbool
+hp_cover          = HP|condbool|HP|condbool
-hp_fight           = HP|condbool|HP|condbool
+hp_fight          = HP|condbool|HP|condbool
-*syndata           = state@sound|state@sound
+syndata           = state@sound|state@sound
-*help_dialog       = story_id
+help_dialog       = story_id
-*help_start_dialog = story_id
+help_start_dialog = story_id
 </source>
 Where:
-; Condstate
+; condstate
 : condition list returning the character's state, or <tt>true</tt>. The NPC will become mad at the player if <tt>true</tt> is returned.
-; Condsound
+; condsound
 : condition list returning the sound scheme
 ; HP
 ; PSY
 : psychological state boundary values
-; Condvictim
+; condvictim
 : condition list returning the direction to look at. Possible values: <tt>nil</tt>, actor, number. In case of a number, will look at the player with the corresponding id.
-; Condbool
+; condbool
 : condition list returning <tt>true</tt> or <tt>false</tt>
 Where:
-; Best_pistol
+; best_pistol
 : a check to make sure the NPC's best weapon is not a pistol
 [danger_condition]
 ignore_distance          = 50
-ignore_ distance_grenade =
+ignore_distance_grenade  =
-ignore_ distance_corpse  =
+ignore_distance_corpse   =
-ignore_ distance_hit     =
+ignore_distance_hit      =
-ignore_ distance_sound   =
+ignore_distance_sound    =
 </source>
 The monster moves along the patrol waypoints (without considering connections between points), keeping at a distance from the player, keeping its course, exiting the scheme upon getting too close to the player and returning back when the distance increases.
-; path  = ...
+; path
 : works as <tt>path_walk</tt>
-; Time_capture = ....
+; Time_capture
 : (required) the time in seconds the monster spends in this scheme; 10 by default
-; Time_release = ....
+; Time_release
 : (required) the time in seconds the monster spends in the all-purpose scheme; 10 by default
-; Min_dist = ....
+; Min_dist
 : (required) distance in meters under which the monster switches to the all-purpose scheme; 5 by default
-; Max_dist = ....
+; Max_dist
 : (required) distance in meters over which the monster switches to the eluder scheme; 10 by default
 ===Overview===
-:''Note: If you want to spawn some object for an NPC from custom data, the description for this is in the "general" section of character profile settings (do not write the <tt>supplies</tt> tag!)
+:''Note: If you want to spawn some object for an NPC from custom data, the description for this is in the "general" section of character profile settings (do not write the <tt>supplies</tt> tag!)''
 Script <tt>logic</tt> controls scheme switching. Customdata for every character (except the free ones) must have a <tt>[logic]</tt> section.
 <source lang="ini">
-on_info = {....} %...%
+on_info  = {....} %...%
 on_info2 = {....} %...%
 on_info3 = {...} %...%
 <source lang="ini">
 combat_ignore_cond =
-on_hit =
+on_hit             =
-on_death =
+on_death           =
-on_combat =
+on_combat          =
-on_use =
+on_use             =
 </source>
 ===Logic script syntax===
-Example: для того, чтобы персонаж ходил по пути walk1, а при приближении игрока на дистанцию 5 метров, переключался на путь walk2 (но только при условии, что он видит игрока), нужно написать следующее:
+Example: to make a character walk along the path <tt>walk1</tt>, but switch to path <tt>walk2</tt> when the player comes within the distance of 5 meters (given that he sees the player), you should write the following:
 <source lang="ini">
 [walker1]
-path_walk = walk1
+path_walk        = walk1
-path_look = look1
+path_look        = look1
 on_actor_dist_le = 5 | walker2
 </source>
-Выше рассмотрено безусловное переключение секций. Перед именем секции в фигурных скобках {} можно задавать дополнительные условия, а после имени секции - так называемые "эффекты", которые заключить в знаки процента: %%. Эффекты будут применены только в случае активации секции. Можно не задавать имя секции, а задать только условия и/или эффекты. Тогда активной останется старая секция, но условия и эффекты будут все равно обработаны. Если все условия в фигурных скобках не выполняются, секция активирована не будет.
+That was unconditional section switching. Before the section name in curly braces {} you can set additional conditions, and after the section name the so-called "effects", which should be enclosed between percent signs %%. Effects will be applied only in case a section is activated. You can omit section name and only set conditions and/or effects. Then only the old section will remain active, but the conditions and effects will nevertheless be processed. If all conditions in curly braces fail, the section will not be activated.
 Example:
 <source lang="ini">
-on_actor_dist_le = 5 | {условие} walker2 %эффекты%
+on_actor_dist_le = 5 | {условие} walker2 %effects%
 </source>
-Условия могут быть следующими:
+You can have the following conditions:
-* +infoportion  - требуется присутствие infoportion у actor
+; +infoportion
-* -infoportion  - требуется отсутствие infoportion у actor
+: the actor must have the infoportion
-* =func  - требуется, чтобы func вернула true
+; -infoportion
-* !func  - требуется, чтобы func вернулся false
+: the actor must not have the infoportion
+; =func
+: the function must return <tt>true</tt>
+; !func
+: the function must return <tt>false</tt>
-Эффекты могут быть следующими:
+You can have the following effects:
-* +infoportion  - в случае включения секции у actor будет установлен infoportion
+; +infoportion
-* -infoportion  - в случае включения секции у actor будет убран infoportion
+: the actor will get this infoportion
-* =func  - в случае включения секции стартует функция func
+; -infoportion
+: the actor will loose this infoportion
+; =func
+: the function will be executed
-Несколько условия или эффектов разделяются проблемами:
+Several conditions or effects should be separated with spaces:
+<source lang="ini">
 on_actor_dist_le = 5 | {+info1 -info2 +info3} walker2 %+info4 =func%
+</source>
-Можно задавать сразу несколько секций, разделенных запятыми. Порядок обхода при этом - слева направо. После срабатывания первого из условий, обход прекращается. В примере ниже, если установлен info1, будет включена схема walker2, иначе, если установлен info2, будет включена схема walker3, иначе будет включен walker4:
+You can set several sections separated by commas. They will be hanled from left to right. After the first condition fires, the handling stops. In the example below, if <tt>info1</tt> is set, then <tt>walker2</tt> is enabled, if <tt>info2</tt> is set, then <tt>walker2</tt>, otherwise <tt>walker4</tt>:
+<source lang="ini">
 on_actor_dist_le = 5 | {+info1} walker2, {+info2} walker3, walker4
+</source>
-В описанном выше поле active секции logic, можно также задавать условия, например:
+You can calso set conditions in the above field <tt>active</tt> of section <tt>logic</tt>, such us:
 <source lang="ini">
 </source>
-В логических условиях теперь принимается ключевое слово never, которое означает, что условие ложно. For example:
+You can use the keyword <tt>never</tt> in logic sections, which means that the condition is false. For example:
-combat_ignore_cond = {=actor_enemy =actor_has_suit} always, {=actor_enemy} never %...эффекты...%
-Вышеприведенная конструкция включает игнорирование боя, если у NPC враг - игрок в костюме, но отключит его, если врагом является игрок, но без костюма, при этом сработают эффекты (%%) секции never. Таким образом, выбор секции never равносилен отсутствию секции (несрабатыванию условия), но эффекты в знаках процента при этом срабатывают.
+<source lang="ini">
+combat_ignore_cond = {=actor_enemy =actor_has_suit} always, {=actor_enemy} never %...effects...%
+</source>
+The above section enables combat ignoring if the NPC's enemy is the player is wearing a suit, but disables it if the player is not wearing suit. In this case the effects of the <tt>never</tt> section will work. Choosing the <tt>never</tt> section is equivalent to not having a section, but effects between percentage signs work.
-Пример работы с секцией nil. Секция nil выводит из-под скриптовых схем персонажа, монстра или объект и отпускает его под управление движка. Это надо если какое-либо условие выполнившись 1 раз больше не нуждается в проверке, при этом экономятся ресурсы машины, которые на каждом апдейте проверяют это условие.
+Here is an example of work with the <tt>nil</tt> section. The <tt>nil</tt> section takes a character, monster, or object from under a scripted scene and puts him in the engine's control. This is necessary if some condition does not need to be checked again after firing off once. This saves resources that would otherwise be wasted on checking the condition.
 <source lang="ini">
 </source>
-То есть, при входе актера в рестриктор выдается инфопоршн и рестриктор уходит в секцию nil, больше не проверяя наличие игрока.
+That is, after the actor enters the restrictor, he gets an infoportion, and the restrictor moves into the <tt>nil</tt> section, not checking for the player anymore.
-NB: Обратно из секции nil под скрипты объект вернуть уже невозможно! Учитывайте это, используя
-ее.
+''Note: scripts cannot be returned from the <tt>nil</tt> section!''
 ===An example of fairly complex logic===
 ==space_restrictor logic scheme==
-Общее замечание: Чтобы исключить ситуацию, когда актёр проскакивает через рестриктор и тот не успевает сработать, старайтесь ставить рестриктор так, чтоб минимальная ширина была больше 2 метров.
+General comment: to avoid situations, in which the actor rushes through a restrictor before it goes off, try to make restrictors at least 2 meters wide.
 ===[sr_idle] scheme===
 [sr_light]
 light_on = true/false
-on_info = {+info1} section %+info2%
+on_info  = {+info1} section %+info2%
 </source>
 [sr_timer@1]
-type = dec
+type        = dec
 start_value = 10000
-on_value = 0 | sr_timer@2
+on_value    = 0 | sr_timer@2
 [sr_timer@2]
-type = inc
+type     = inc
 on_value = 15000 | nil %+info1%
 </source>
 ; type = nightmare/normal/happy/all
 : Sets the type of sleep allowed in the current zone; affects only non-storyline sleep; <tt>all</tt> by default
-; dream_prob = <число от 0 до 100>
+; dream_prob = <number 0 from 100>
 : probability of non-storyline dreams in the given zone; 80 by default
 ====Dreams section feilds====
-; regular_probability = <число от 0 до 100>
+; regular_probability = <number from 0 to 100>
 : probability of playing regular dreams in general
 ; regular
 [ph_door@locked]
-locked = true
+locked         = true
 snd_open_start = trader_door_locked
-on_info = {+esc_trader_can_leave} ph_door@unlocked
+on_info        = {+esc_trader_can_leave} ph_door@unlocked
 [ph_door@unlocked]
-locked = false
+locked          = false
-snd_init = trader_door_unlock
+snd_init        = trader_door_unlock
-snd_open_start = trader_door_open_start
+snd_open_start  = trader_door_open_start
 snd_close_start = trader_door_close_start
-snd_close_stop = trader_door_close_stop
+snd_close_stop  = trader_door_close_stop
 </source>
 <source lang="ini">
 [logic]
-active      = ph_button@locked
+active = ph_button@locked
 [ph_button@locked]
 [ph_button@active]
-anim = lab_switcher_idle
+anim     = lab_switcher_idle
-tooltip = tips_labx16switcher_press
+tooltip  = tips_labx16switcher_press
 on_press = ph_button@deactivated %+terrain_test%
 [ph_button@locked]
-anim = button_false ; an animation for disabled buttons
+anim     = button_false;  an animation for disabled buttons
-on_info = {+val_prisoner_door_unlocked} ph_button@unlocked
+on_info  = {+val_prisoner_door_unlocked} ph_button@unlocked
 on_press = ph_button@unlocked %+val_prisoner_door_unlocked%
 [ph_button@unlocked]
-anim = button_true
+anim     = button_true
-on_info = {-val_prisoner_door_unlocked} ph_button@locked
+on_info  = {-val_prisoner_door_unlocked} ph_button@locked
 on_press = ph_button@locked %-val_prisoner_door_unlocked%
 </source>
 File: \gamedata\scripts\ph_code.script
-===Ph_gate:===
+===Ph_gate===
-То же самое, что и ph_door, но для ворот, состоящих из двух дверей:
+Same as <tt>ph_door</tt>, but for gates made from two halves.
-Вместо параметров closed и locked сейчас используются параметры:
-state: состояние, в котором дверь находится при инициализации (по умолчанию none)
-* open - в открытом
-* closed - в закрытом
-none - в текущем (дефолтном или оставшемся от предыдущей схемы)
-locking: блокировка дверей (по умолчанию none)
+; state
-stick - прилипание дверей к крайним состояниям (пока в процессе настройки)
+: state in which the door is in after initialization
+:; open
+:; closed
+:; none
+:: current (default or remaining after the previous scheme)
+; locking
+: <tt>none</tt> by default
+; stick
+: whether the door is attracted to the farmost positions (this is still being set up)
+; soft
+: the door is blocked by force, so it can be forced or broken through
+:; open
+:: blocked in open state
+:; closed
+:: blocked in closed state
+:; none
+:: unused
+; hard
+: the door is blocked with boundaries; can only be broken
+:; open
+:: blocked in open state
+:; closed
+:: blocked in closed state
+:; none
+:: blocked in current state
+; none
+: the door is unblocked
-soft - дверь заблокирована с помощью силы, т.е. можно ее открыть/пробить машиной
+General parameters:
-Состояния в этом положении:
-* open - блокировать в открытом состоянии
-* closed - в закрытом
-none - не используется (мягкая блокировка возможна только в крайних положениях)
-hard - блокировка двери с помощью границ. Ворота можно только сломать
+; left_limit, right_limit
-Состояния в этом положении:
+: sets the angle [0-180] for opening each half of the gate; 100 by default
-* open - блокировать в открытом состоянии
+; breakable = true/false
-* closed - в закрытом
+: determines whether the gate can be broken; <tt>true</tt> by default
-* none - в текущем
-none - дверь не заблокирована
+The sound parameters are the same as for <tt>ph_door</tt>.
-Общие параметры:
-left_limit, right_limit - задают угол [0-180] открытия каждой из створок ворот. По умолчанию - 100 градусов.
-breakable - (true/false) определяет можно ли сломать ворота. По умолчанию true.
-Звуковые параметры аналогичны ph_door
 Examples:
 <source lang="ini">
-[ph_gate@locked] ;блокировка в открытом состоянии, неразбиваемые.
+[ph_gate@locked] ; blocks in open mode, undestructable
-state = opened
+state      = opened
-locking = soft
+locking    = soft
 left_limit = 130
 rigt_limit = 60
-breakable = false
+breakable  = false
 [ph_gate@opened]
-state = opened
+state   = opened
 locking = stick
 Is specified for every physical object to emit sounds (was initially made for swearning).
-'''[ph_sound]''''
+'''[ph_sound]'''
 ; snd
 : name of a theme from file sound_theme.script from table ph_snd_themes
 [ph_sound]
-snd = gar_seryi_shooting
+snd              = gar_seryi_shooting
-looped = true
+looped           = true
-max_idle = 5000
+max_idle         = 5000
 on_actor_in_zone = gar_seryi_factory| ph_sound@end
 [ph_sound@end]
-snd = gar_seryi_shooting_2
+snd       = gar_seryi_shooting_2
-looped = false
+looped    = false
 on_signal = sound_end| nil
 </source>
 ; cond
 : list of conditions necessary to create a gulag
-: {+info -info = func !func} - if the condition is not met, the gulag is disbanded and all its inmates begin to be controlled by logic specified in their custom_data
+: <tt>{+info -info = func !func}</tt> - if the condition is not met, the gulag is disbanded and all its inmates begin to be controlled by logic specified in their custom_data
 ; respawn
 : respawn name (calls the respawner with the given name every time someone from the smart terrain starts working on a task)
 ; gname
 : smart terrain name; used as a prefix
-; yype – тип гулага
+; type
 ; squad, groups
-: squad and grouip table, if we need to override the native stalker groups with some other ones. For each task you should set a squad and a group to assign a stalker to upon recieving a task.
+: squad and group table, if we need to override the native stalker groups with some other ones. For each task you should set a squad and a group to assign a stalker to upon recieving a task.
 Approximate description of gulag tasks:
 That is, the given task can only be carried out by a person with the <tt>soldier_commander</tt> profile.
-. В \gamedata\config\misc\gulag_<level name>.ltx you should specify which behavior schemes correspond to each task. FOr instance, for the aforementioned gar_maniac:
+. В:\gamedata\config\misc\gulag_<level name>.ltx you should specify which behavior schemes correspond to each task. FOr instance, for the aforementioned gar_maniac:
 <source lang="ini">
 [sleeper@gar_maniac_sleeper]
 path_main = sleep
-wakeable = true
+wakeable  = true
 </source>
 ===xr_conditions===
-* fighting_dist_ge(p) – универсальная функция для combat_ignore, проверка расстояния для игрока (в метрах)
+; fighting_dist_ge(<nowiki>p</nowiki>)
-* distance_to_obj_le(sid:dist) - проверка дистанции до обьекта заданного story_id.<br>Можно использовать, например, в секции follower для определения того, что сталкер подошел на нужную дистанцию к лидеру и     переключать в другую секцию (лидер при этом стоит где-то в ремарке). Эта ситуация возникает, когда после боя надо подогнать одного сталкера к другому, а ихних позиций мы не знаем. Если используется в секции follower, то dist надо ставить большим    distance фолловера, поскольку если поставить их одинаковыми, то данная функция не всегда будет срабатывать.
+: all-purpose function for <tt>combat_ignore</tt>, checks distance to the player (in meters)
-* health_le(health) - проверка того, что здоровье npc &lt;= health
+; distance_to_obj_le(<nowiki>sid:dist</nowiki>)
-* heli_health_le(health) - аналогично предыдущему, только для вертолета.
+: checks distance to the object with the given <tt>story_id</tt>
-* enemy_group(group1:group2:...) - Проверка на принадлежность врага к одной из групп (правильность работы пока не проверялась)
+: this can be used, for instance in the <tt>follower</tt> section to switch to another section when a stalker walks within a certain distance of the leader (the leader is then somwehere in <tt>remark</tt>). This situationi occurs when one stalker should approach another while we do not know their positions. If this is used in the <tt>follower</tt> section, <tt>dist</tt> should be larger than the follower's <tt>distance</tt>, since if they are the same, this function will not always work.
-* hitted_by(sid1:sid2:...) - Проверка того, что удар был нанесен кем-то из npc, указанных в списке. npc задаются с помощью story_id. Функцию удобно использовать в секции hit.
+; health_le(<nowiki>health</nowiki>)
+: checks that NPC's HP &lt;= health
-Example:
+; heli_health_le(<nowiki>health</nowiki>)
+: like the above, but for a helicopter
+; enemy_group(<nowiki>group1:group2:...</nowiki>)
+: checks membership of the enemy to a group (we did not check whether it works correctly)
+; hitted_by(<nowiki>sid1:sid2:...</nowiki>)
+:checks if a hit was made by one of the listed NPCs. The NPCs are set using their <tt>story_id</tt>. This function is convenient for in the <tt>hit</tt> section. Example:
 <source lang="ini">
 [hit]
 on_info = {=hitted_by(407:408)} %+val_escort_combat%
 </source>
+; killed_by(<nowiki>sid1:sid2:...</nowiki>)
-killed_by(sid1:sid2:...) - Аналогично предыдущему, но для случая смерти npc. Используется в секции death.
+: like the preceeding, but for a kill; used in the <tt>death</tt> section
+; is_alive(<nowiki>sid</nowiki>)
-is_alive(sid)
+; is_alive_one(<nowiki>sid1:sid2:...</nowiki>)
-is_alive_one(sid1:sid2:...)
+; is_alive_all(<nowiki>sid1:sid2:...</nowiki>)
-is_alive_all(sid1:sid2:...) - проверка того, что один, один из нескольких или все из списка соответственно npc, заданные по story_id живы
+: checks if one, one of serveral, or all NPCs in a list are alive
+; is_dead(<nowiki>sid</nowiki>)
-is_dead(sid)
+; is_dead_one(<nowiki>sid1:sid2:...</nowiki>)
-is_dead_one(sid1:sid2:...)
+; is_dead_all(<nowiki>sid1:sid2:...</nowiki>)
-is_dead_all(sid1:sid2:...) - аналогично предыдущему, только проверка на "мертвость".
+: like the preceeding, but for death
+; check_fighting(<nowiki>sid1:sid2:...</nowiki>)
-check_fighting(sid1:sid2:...) - Проверка того, не является ли кто-то из перечисленных (с помощью story_id) npc врагом даного. Как правило используется в combat_ignore_cond.
+: checks if any from the list are enemies of the current NPC; typically used in <tt>combat_ignore_cond</tt>
+; gulag_empty(<nowiki>gulag_name</nowiki>)
-gulag_empty(gulag_name) - проверка того, что гулаг пуст или вообще не существует.
+: checks if a gulag is empty or non-existant
+; gulag_population_le(<nowiki>gulag_name, num</nowiki>)
-gulag_population_le(gulag_name, num) - проверка того, что количество народу в гулаге &lt;= num
+: checks if the number of people in the gulag is <tt>&lt;= num</tt>
+; gulag_casualities_ge(<nowiki>gulag_name:num</nowiki>)
-gulag_casualities_ge(gulag_name:num) – проверка того, что гулаг понес потери => num
+: checks that the casualties in the gulag are <tt>=> num</tt>
-NB! Потери гулага не обнуляются, так что с этой функцией работать аккуратно.
+: Note! Gulag casualties are not reset, so you should be careful with this function
+; signal(<nowiki>string</nowiki>)
-signal(строка) – проверяет, установлен ли у данного НПС в текущей схеме указанный сигнал
+: checks if the NPC has the given signal set in the current scheme
 ===xr_effects===
-heli_set_enemy(story_id) – сделать npc с указанным story_id врагом веротелу. В одной секции можно задавать только 1 врага.
+; heli_set_enemy(<nowiki>story_id</nowiki>)
+: make the NPC with the given <tt>story_id</tt> an enemy of the helicopter. Only one enemy can be set in one section.
-set_gulag_enemy_actor(gulag_name) – сделать актера врагом для данного гулага
+; set_gulag_enemy_actor(<nowiki>gulag_name</nowiki>)
+: make the actor an enemy of the current gulag
-hit_npc(direction:bone:power:impulse:reverse=false) - нанести хит по npc. Параметры:
+; hit_npc(<nowiki>direction:bone:power:impulse:reverse=false</nowiki>)
-* direction - если строка, то считается, что это имя пути и в сторону первой точки производится толчек. Если же это число,  то оно рассматривается как story_id персонажа от которого должен поступить хит.
+: incur a hit to the NPC. Parameters:
-* bone - строка. Имя кости, по которой наносится удар.
+:; direction = string/number
-* power - сила удара
+:: the name of path in the direction of first point of which to hit or the <tt>story_id</tt> number of a character from which the hit originates
-* impulse - импульс
+:; bone = string
-* reverse (true/false) - изменение направления удара на противоположное. по умолчанию false.
+:: the name of the bone that is hit
+:; power
-Example:
+:; impulse
+:; reverse = true/false
+:: whether the direction should be reversed; <tt>false</tt> by default
+: Example:
 <source lang="ini">
 [death]
 on_info = {=killed_by(404)} %=hit_npc(404:bip01_spine1:100:2000)%, {=killed_by(405)} %=hit_npc(405:bip01_spine1:100:2000)%
 </source>
+; set_friends(<nowiki>sid1:sid2:...</nowiki>)
-set_friends(sid1:sid2:...)
+; set_enemies(<nowiki>sid1:sid2:...</nowiki>)
-set_enemies(sid1:sid2:...) - установить друзьями/врагами данного npc и указанных в списке по story_id.
+: set the character with the listed <tt>story_id</tt> numbers friends or enemies of the given NPC
+; play_snd(<nowiki>snd_name:delay=0</nowiki>)
-play_snd(snd_name:delay=0) - играть звук в голове актёра.
+: play a sound in the actor's head
-* snd_name - путь к звуку относительно папки sounds
+; snd_name
-* delay - задержка перед проигрыванием. По умолчанию 0 – проигрываем сразу.
+: sound path relative to the <tt>sounds</tt> folder
+; delay
-play_snd_now (sid:snd_name) – играть звук от указанного объекта
+: delay before playback; <tt>0</tt> by default, to start playback immediately
-*звук играется об объекта с указанным story id, без задержки с громкостью 1. Указывается не имя звуковой схемы, а имя файла
+; play_snd_now (<nowiki>sid:snd_name</nowiki>)
+: play the sound from the given object
-hit_obj(sid, bone, power, impulse, hit_src=npc:position())
+: the sound is played from the object with the given <tt>story_id</tt> without delay with volume 1; the file name, not sound schme name is specified
-Дать обьекту, заданому story_id, хит. Отличается тем, что может прописываться в любой кастом дате. Параметры: actor, npc, p[sid,bone,power,impulse,hit_src=npc:position()]
+; hit_obj(<nowiki>sid, bone, power, impulse, hit_src=npc:position(</nowiki>))
-# sid - story_id обьекта, по которому наносится хит.
+: incur a hit on the object with the given <tt>story_id</tt>. Is distinguished by being able to be specified in any custom data. Parameters: actor, npc, p[sid, bone, power, impulse, hit_src=npc:position()]
-# bone - строка. Имя кости, по которой наносится удар.
+:; sid
-# power - сила удара
+:: <tt>story_id</tt> of the object to incur the hit on
-# impulse - импульс
+:; bone
-# hit_src (необязательный параметр) - точка (waypoint), из которой по объекту наносится хит. Если не задано, то берется позиция обьекта, из которого была вызвана данная функция.
+:: name of the bone that is hit
+:; power
-actor_has_item(section)
+:; impulse
-Проверка на наличие у игрока соответствующего предмета. Проверка проходит по секции в ltx
+:; hit_src
+:: optional; the waypoint from which the hit is made on the object; if it is not specified, then the position of the object calling the function is taken
+; actor_has_item(<nowiki>section</nowiki>)
+: check if the player has this object; the check is made via the ltx section
 ===Functions for working with HUD===
 [[ru:Настройка логики (часть 1)]]
+[[Category:Articles]]

Logic

From Mod Wiki

Current revision

Contents

Flag system

path_walk, path_look

Paths in-depth

Configuration

Example 1

Example 2

Example 3

Example 4

Example 5

Stalker behaviour schemes

walker scheme

remark scheme

sleeper scheme

kamp scheme

camper scheme

sniper scheme

follower scheme

zoneguard scheme

wounded scheme

rest scheme

heli_hunter scheme

patrol scheme

Sections

combat section

death section

hit section

actor_dialogs section

use section

combat_ignore section

dont_spawn_character_supplies section

no_smart section

treshhold section

Danger section

stories section

dont_spawn_loot section

Overrides

Monster schemes

mob_walker scheme

mob_eluder scheme

mob_remark scheme

mob_combat, mob_death schemes

mob_jump scheme

Mob_camp

Mob_home

Mob_fake_death

Monster overrides

spawner section

Spawning day and night monsters

Logic script

Overview

Logic script syntax

An example of fairly complex logic

space_restrictor logic scheme

[sr_idle] scheme

[sr_no_weapon] scheme

[sr_sound] scheme

[sr_tip] scheme

Sr_light

Sr_territory

Sr_mapspot

Sr_particle

For a particle system with a camera path

For a particle system with a regular patrol path

Sr_sound_act

Sr_timer

Sr_psy_antenna

Sr_teleport

Sr_sleep and sleep configuration

Videos section

Dreams section feilds

Settings for regular dreams

Settings for storyline dreams

Sr_cutscene

Various settings for objects

[ph_idle]

Doors, [ph_door] section