Главная » Статьи » Статьи » Моддинг

Гулаги (4)
Гулаги(Динамические 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. Эта строка нужна для того, чтобы при переходе из оффлайн НПС не попадали в костер и не получали хит, а выходили в этой точке)
Категория: Моддинг | Добавил: Hardtmuth (13.07.2012)
Просмотров: 1529 | Рейтинг: 0.0/0
Всего комментариев: 0
Добавлять комментарии могут только зарегистрированные пользователи.
[ Регистрация | Вход ]

Меню сайта

Свежие прохождения






Категории раздела

Мини-чат

Наш опрос
Какое прохождение писать следующим?
Всего ответов: 2932

Поиск

Статистика

Онлайн всего: 62
Гостей: 62
Пользователей: 0








Тот самый S.T.A.L.K.E.R.







Форма входа

Войти Зарегистрироваться