Гулаги(Динамические LTX) Материал из S.T.A.L.K.E.R. Inside Wiki. Перейти к: навигация, поиск
При создании гулага, не многие знают, что практически всю настройку логики гулагов, можно производить в файле «script». Такой способ построения достигается за счёт динамических ltx. Попробую описать, каким образом это достигается. Я думаю, многие заметили в файлах с гулагами такую функцию:
--'------------------------------------------------------------------------ --' Dynamic ltx --'------------------------------------------------------------------------ function load_ltx(gname, type) return nil end
Это именно та функция, которая и отвечает за динамические ltx. В данном случае, она отключена. Разберём простейший способ построения динамических ltx.
Создаём стандартным способом «smart_terrain» в файле «all.spawn» и гулаг в файле «gulag_уровень.script». Назначим ему имя, например «kakashki». Задаём ему несколько заданий. Например, зададим 3 кампа и двух уолкеров:
if type == "kakashki" then for i = 1, 3 do t = { section = "logic@kakashki_kamp", idle = 0, prior = 8-i, state = {0,1}, in_rest = "", out_rest = "" } table.insert(sj, t) end for i = 1, 2 do t = { section = "logic@kakashki_walker_"..i, idle = 0, prior = 9-i, state = {0,1}, in_rest = "", out_rest = "" } table.insert(sj, t) end end
Так как мы собираемся использовать динамические ltx, то дальнейшая настройка заданий будет производиться не в конфигурационных файлах, а непосредственно в этом же файле. То есть в упомянутой выше функции «load_ltx». Для этого находим нужную функцию «load_ltx», и в ней создаём динамический ltx и прописываем требуемые схемы логики:
--'------------------------------------------------------------------------ --' Dynamic ltx --'------------------------------------------------------------------------ function load_ltx(gname, type) if type == "kakashki" then local ltx = "[logic@kakashki_kamp]\n".. "active = kamp@kakashki\n".. "[kamp@kakashki]\n".. "center_point = kamp\n".. "[logic@kakashki_walker_1]\n".. "active = walker@kakashki_1\n".. "[walker@kakashki_1]\n".. "path_walk = walk_1\n".. "path_look = look_1\n".. "[logic@kakashki_walker_2]\n".. "active = walker@kakashki_2\n".. "[walker@kakashki_2]\n".. "path_walk = walk_2\n".. "path_look = look_2\n" return ltx end return nil end
Где, кавычки обязательны, {\n} назначает новую строку в динамическом ltx, и {..} ставится для привязки строк между собой. В последней строке схем, двоеточие ставить не нужно, так как привязывать больше нечего. Переменная «ltx» может иметь любое другое имя.
Теперь создаём вэйпоинты путей, в файле «all.spawn», и можно смело идти проверять.
Одно из преимуществ динамических ltx - это пакетная настройка логики. Может, я не так выразился, но по ходу действий, я думаю вам станет ясно, что я имел ввиду. Например, нам нужно создать 8 уолкеров, с одинаковыми настройками логики, но при этом, разными поинтами путей. В статических ltx нам понадобится создавать 8 секций [logic]. Тоесть для каждого уолкера, своя секция логики. В динамических ltx, данную проблему можно решить функционально.
Делаем это так:
Создаём 8 уолкеров в функции "load_job". Обязательно с помощью счётчика "for-do":
for i = 1, 8 do t = { section = "logic@kakashki_walker_"..i, idle = 0, prior = 9-i, state = {0,1}, in_rest = "", out_rest = "" } table.insert(sj, t) end
Кто ещё не знает, как это работает, то поясню. Создаётся переменная i, или любое другое имя. Назначается ей два, или три значения, (через запятую). Где:
первое значение = какое число задаётся при первом цикле счёта; второе значение = при достижении или переполнении какого числа, остановить счёт; третье значение = какое значение прибавлять, при каждом цикле счёта.
Если третье значение не задаётся, то при каждом цикле счёта, прибавляется 1.
Переменной "section" задаётся "имя секции"+переменная i. В итоге, при каждом последующем цикле счёта, к имени секции будет приписываться в конце значение переменной i. Тоесть, "logic@kakashki_walker_1"; "logic@kakashki_walker_2"; "logic@kakashki_walker_3" и т.д.
В нашем случае, переменной "prior" задано значение 9-i, что делать не обязательно. Здесь при каждом цикле счёта, вычитается значение переменной i от числа 9. В итоге, при каждом последующем цикле, переменной "prior" задаётся значение на 1 меньше предыдущего.
Итак, уолкеров создали. Теперь нам нужно задать им всем логику действий. Создаём переменную ltx, которую мы будем использовать для динамических ltx. Для этого, подымаемся на самый верх файла, где прописано создание переменной t, и ниже прописываем:
local ltx = ""
Теперь, в функции "load_ltx" создаём ltx файл для нашего гулага:
function load_ltx(gname, type) if type == "kakashki" then return ltx end return nil end
Данным способом, мы возвращаем поиск секций логики, назад в функцию "load_job".
Теперь возвращаемся в функцию "load_job", и в секции нашего гулага, внутри счётчика "for-do" прописываем логику уолкерам. Выглядеть это будет так:
for i = 1, 8 do t = { section = "logic@kakashki_walker_"..i, idle = 0, prior = 9-i, state = {0,1}, in_rest = "", out_rest = "" } table.insert(sj, t) ltx = ltx.. "[logic@kakashki_walker_"..i.."]\n".. "active = walker@kakashki_"..i.."\n".. "[walker@kakashki_"..i.."]\n".. "path_walk = walk_"..i.."\n".. "path_look = look_"..i.."\n" end
Где, так же как и в случае с переменной "section", приписывается в конец имён секций и путей, значение переменной i. В итоге получаем такие имена путей:
walk_1, look_1; walk_2, look_2; walk_3, look_3; и т.д.
Заметим, как мы прописали переменную ltx. Таким способом, мы при каждом цикле счёта, новую секцию логики пришиваем к секциям, пришитым к динамическому ltx при предыдущих циклах. Если прописать просто:
ltx = логика
То при каждом цикле счёта новая секция будет накладываться на предыдущую, что приведёт к нехорошим последствиям.
Ну и создаём соответствующие секции поинтов путей в файле all.spawn. И всё будет работать как часы.
Не забываем, при создании секций поинтов, к именам путей пришить имя смарт террэйна.
Продолжение следует.
Автор: Singapur22
Вот IG-2007 на оф.форуме осенью прошлого года написал такой тутор по гулагам. Здесь показана работа в гулаге для сталкера. Днем он гуляет (walker), а ночью сидит у костра (kamp).
text 1) Пропишите в all.spawn своему смарту такую custom_data:
custom_data = <<END [smart_terrain] type = esc_new_lager capacity = 1 END
2) Пропишите в all.spawn два пути: один из нескольких точек для схемы walker (esc_new_lager_npc1_walk), другой из одной точки (центр кампа) для kamp (esc_new_lager_npc1_kamp)
3) Откройте файл config\misc\gulag_escape.ltx и добавьте в самый конец работу для своего сталкера:
[logic@esc_new_lager_npc1] active = walker@esc_new_lager_npc1
[walker@esc_new_lager_npc1] path_walk = npc1_walk on_info = {!is_day} kamp@esc_new_lager_npc1
[kamp@esc_new_lager_npc1] center_point = npc1_kamp on_info = {=is_day} walker@esc_new_lager_npc1
4) Откройте файл gulag_escape.script и добавьте в него:
4.1) в функцию load_job
if type == "esc_new_lager" then t = { section = "logic@esc_new_lager_npc1", idle = 0, prior = 5, state = {0}, online = false, in_rest = "", out_rest = "" } table.insert(sj, t) end
4.2) в функцию load_states
if type == "esc_new_lager" then return function (gulag) return 0 end end
4.3) в функцию checkStalker
if gulag_type == "esc_new_lager" then return npc_community == "stalker" end
Можно. Сначала нужно исключить возможность попадания в гулаг. Для этого в логике пишется секция : [smart_terrains] none = true Далее логика пишется таким образом : [logic] active = kamp [kamp] center_point = *** (***-это имя точки, вокруг которой НПС садятся. Располагать её можно где угодно, не только у костра. Название этой точки должно быть уникальным, т.к. она прописывается в way_"уровень".ltх) radius = * (*-радиус в метрах от точки center_point, в пределах которого НПС будут садится. Можно не указывать. По умолчанию 2 метра) path_walk = ***_task (Можно не прописывать, если точка center_point находится не в центре костра. *** - то же название, что и указано в center_point, с добавлением _task. Эта точка тоже прописывается в way_"уровень".ltх, но координаты указываются на некотором расстоянии от center_point. Эта строка нужна для того, чтобы при переходе из оффлайн НПС не попадали в костер и не получали хит, а выходили в этой точке)
| 
