Отрываем файл xr_kamp.script, все манипуляции происходят в нём.
Идём в функцию set_scheme. Дописываем в неё следующую строку:после строки:
Далее, чуть ниже, измените вот эту строку:вот так:
Теперь перемещаемся вверх и находим следующую строку:И слегка изменяем её плюс дописываем дополнительную строчку:
И в заключении, изменим проверку:Вот так:
Всё. Осталось только в нужной секции схемы kamp, дописать параметр со значением false:

! Unknown command: *INFO:ВНИМАНИЕ! Ошибка! Информация по ошибке в строках ниже !
* Log file has been saved successfully!
! Unknown command: *INFO:ERROR!: Can't find script switching information in storage, scheme '<NOT_arg!>'
* Log file has been saved successfully!

FATAL ERROR

[error]Expression : fatal error
[error]Function : CScriptEngine::lua_error
[error]File : E:\stalker\sources\trunk\xr_3da\xrGame\script_engine.cpp
[error]Line : 73
[error]Description : <no expression>
[error]Arguments : LUA error: ... publishing\s.t.a.l.k.e.r\gamedata\scripts\_g.script:86: ВНИМАНИЕ! Игра прервана! Информация в строках выше.

stack trace:

function cfg_get_switch_conditions(ini, section, npc)
local l = {}
local t
local n = 1
if not ini:section_exist(tostring(section)) then
return
end
local line_count = ini:line_count(section)

local function add_conditions(func, cond)
for line_number = 0, line_count - 1 do
local result, id, value = ini:r_line(section,line_number,"","")
if string.find( id, "^"..cond.."%d*$" ) ~= nil then
c = func(ini, section, id, npc)
n = add_condition(l, n, c)
end
end
--[[ local c = func(ini, section, cond, npc)
while c ~= nil do
n = add_condition(l, n, c, npc)

i = i + 1

c = func(ini, section, cond..i, npc)
end]]--
end

add_conditions( cfg_get_number_and_condlist, "on_actor_dist_le" )
add_conditions( cfg_get_number_and_condlist, "on_actor_dist_le_nvis" )
add_conditions( cfg_get_number_and_condlist, "on_actor_dist_ge" )
add_conditions( cfg_get_number_and_condlist, "on_actor_dist_ge_nvis" )
add_conditions( cfg_get_string_and_condlist, "on_signal" )
add_conditions( cfg_get_condlist , "on_info" )
add_conditions( cfg_get_number_and_condlist, "on_timer" )
add_conditions( cfg_get_number_and_condlist, "on_game_timer" )
add_conditions( cfg_get_string_and_condlist, "on_actor_in_zone" )
add_conditions( cfg_get_string_and_condlist, "on_actor_not_in_zone" )
add_conditions( cfg_get_condlist , "on_actor_inside" )
add_conditions( cfg_get_condlist , "on_actor_outside" )
add_conditions( cfg_get_npc_and_zone , "on_npc_in_zone" )
add_conditions( cfg_get_npc_and_zone , "on_npc_not_in_zone" )

return l
end

Как многие знают, можно использовать в одной секции какой-либо схемы логики несколько условий, таких как: on_info, on_signal, on_actor_dist_le и т.д. (при условии, что сама схема их поддерживает) дописав в конце имени параметра цифру: on_info, on_info2, on_info3... - и это не является секретом. Но вот не многие знают, что в ТЧ эти цифры должны идти строго по порядку, а в ЗП - нет.
Это было сделано по одной простой причине - наследование. Те кто знаком с этим понятием должны понять меня уже сейчас, те кто нет ... будет сложнее.
В ТЧ наследование применяется исключительно в конфигах объектов, а вот в настройке логики - ни разу. В ЗП, разработчики нашли наследование весьма удобным (а оно действительно таковым является) и применяют его повсеместно.
Давайте определим основное свойство наследования.
Предположим, что в нескольких секциях логики, должны присутствовать одни и те же условия (для примера возьмём всего две секции и схему walker):Если таких секций много (лично для меня много - 4 и более), то приходится заниматься копи-пастом, что я считаю не есть "гуд".
Так вот наследование позволяет избежать много строчного копирования следующим образом:Как видите, такой способ позволяет меньше заниматься "писаниной", к тому же, я нахожу его более удобным.

А что, если в одной из секций нужно изменить одно из условий? Выход очень простой:Таким образом, в секции walker@1 будет использоваться собственный параметр on_info, а on_info2 - останется неизменным и будет взят из секции common_walker.
Это, так сказать, общий принцип. Но в ТЧ, без небольшой правки функции cfg_get_switch_conditions, возможно появление ситуации, когда наследуемая секция очень большая (скажем десять условий on_info), а в одной из наследуемых секций, нужно не просто изменить одну из имеющихся, а добавить свою - а это обязывает точно знать сколько, а главное какие, условий есть в общей секции, что затруднительно. Ко всему ситуация усугубляется и тем, что в ТЧ нумерация параметров должна идти подряд.
В ЗП разработчики избавились от этого недостатка слегка изменив функцию cfg_get_switch_conditions, что позволяет не соблюдать порядок при нумерации параметров:Это позволяет добавлять в наследуемые секции свои условия, небоясь, что одно или несколько условий будут перекрыты, и все условия будут успешно прочитаны и выполнены, чего в чистом ТЧ не произошло бы (т.к. обязателен порядок чисел по возрастанию). Действует это на все параметры переключения.

Вот собственно и вся суть моей с BeeRsek'ом дискуссии. Но повторюсь - у меня никогда не было по этому поводу проблем и тем более вылета.