So here is basic info of what is usually needed to create a character:

ID - character ids are usually consisted of name of smart terrain, in which they reside

Name – you can use generated name or you can define one in configs\text\*lang*\st_character.xml (lang is your game language – rus, eng, etc.)

Icon – which icon will NPC use in trade, upgrade and other windows. Generic and unique ones are defined in configs\ui\textures_descr\ui_actor.xml. Icon and Visual should match.

Class – this is important, because character class is what need in squad definition. We define it later on.

Community – important, defines in which community will our NPC spawn

Snd_config – there are 3 profiles, which you can use (human_01, human_02, human_03), dolg is for Duty stalkers

Visual – defines how will our NPC look, again to know which visuals can be used, you should take look in meshes\actors\stalker_*faction*\. Icon and Visual should match.

Supplies – define what will NPC carry with himself. Items, food and drugs are defined in those 3 XML files, so you don't have to write them down manually. NPC need only one box of ammo – that only defines, which type of ammo to use, because they have unlimited ammo

Of course there are other things you can change like money, rank, reputation or bio, but they're not important, unless you want your NPC to be wealthy. Usually you would also want to add dialogs here, but that's beyond scope of this article. You should read dedicated article.

For clarity sake, use same ID and same Class – to avoid unnecessary crashes of game, because of unexisting NPC class or character ID.

Now we are going to create NPC profile. NPC profiles are defined in configs\gameplay\npc_profile.xml:

Here just use same values as we used in charater_desc_jupiter.xml file.

After that we need to create spawn section, again in appropriate file. Spawn sections are located in configs\creatures\spawn_sections_*.ltx, again splitted by location. We are going to edit spawn_sections_jupiter.ltx:

story_id – important thing as in spawn_sections_jupiter.ltx – we will identify our squad with this ID

target_smart – defines which smart terrain is destination for our squad. You can use condition list here to define multiple target smart terrains.

You can (and also would like to) use spawn_point parameter – defines where squad will spawn. Again, you can use condition list in it.

(note: spawn_point is a waypoint defined in way_*.ltx files).

Also, there are other parameters: npc_in_squad and npc_random. Those are used for simulation squads – to generate random NPCs from given list and given number of them (npc_in_squad) and shouldn't be used in unique squads, because some problems could appear, e.g. if there's a leader in a squad, he doesn't have to be necessarily spawned.

Creating space restrictor

Creating space restrictor around place where task takes place is preferable, because you get a centralized control over the task.

In order to create space restrictor, you need to add it's definition into one of alife_*.ltx files of all.spawn. In our case it is alife_jupiter.ltx.

You need to assign it unique ID and preferably unique name, consisting of smart terrain name and your designed string.

We take for example jup_b212, which is Ventilation complex in south part of Jupiter location. Our space restrictor name will be jup_b212_sr_task (sr is shortcut for space restrictor).

Position – position of our space restrictor. In our case I took position of jup_b212 smart terrain.

Game_vertex_id – defines vertex id in whole game (not important term here – vertex). Again I took it from jup_b212 smart terrain.

Level_vertex_id – defines vertex id in current level. From jup_b212.

Cfg – defines that configuration for our space restrictor is located somewhere else. It could be defined here, but we would always have to recompile all.spawn if we wanted to change something.

Radius – radius of space restrictor. In this case, it is a sphere. Don't make it too big, because obviously FPS will drop down.

Spawning squad

We will spawn our squad very simple – when actor enters Yanov station. Why don't we use our newly created space restrictor? Because that one is for the control over our task. You are free to create another somewhere else and use that one instead of weapon restrictor over Yanov.

So open up configs\scripts\jupiter\jup_a6_sr_noweap.ltx logic file and edit sr_no_weapon@wait section:

section activates when actor enter space restrictor around and in Yanov (that is in sr_idle@wait section)

on_info fires when:

infoportion jup_b212_duty_squad_created is not set and squad jup_b212_duty_squaddoesn't exist

when on_info fires:

infoportion jup_b212_duty_squad_created is set

squad jup_b212_duty_squad is created

2. Setting up NPCs logic

First, we need to know something more about smart terrains. Smart terrains have different kind of jobs, which they assign to NPCs. Example is some stalkers patroling around smart terrain, sitting, eating, sleeping. Just everything they do in smart terrain.

So here in config file of jup_b212, there are settings for respawn, but they're commented out by GSC. If you want to you can use it, but beware once you enable respawn params, save game with it and then try to remove them game will crash, because respawn params are saved to game save.

Max_population is self explanatory – maximum number of squads that can occupy given smart terrain.

What is more important is jup_b212_duty_leader and its set config file. It is not necessary to use same ID of NPC as its story id, but it is recommended. You'll understand it better from example:

close_anim – animation which will NPC use – in our case, when actor has weapon shown we use threat animation, otherwise guard

far_* parameters – same as close_* parameters, except that actor is further than range defined in far_distance

Note: if you want to add jobs for other NPCs in squad, I strongly suggest to create their own character profile (e.g. in character_desc_*.xml, npc_profile.xml, spawn_sections_*.ltx). Otherwise any simulation (e.g. sim_default_duty_1 or even sim_default_bandit_1) can use the job and that might not what you want.

3. Conclusion

Most of logic and paths are explained in Logic article and you can learn a lot from GSC scripts. Those who are familiar with Lua can always check something in scripts, like checking/adding condition functions in xr_conditions.script or effect functions xr_effects.script.