SoC. Гулаги (динамические LTX) — различия между версиями
Материал из S.T.A.L.K.E.R. Inside Wiki
Строка 1: | Строка 1: | ||
− | При создании гулага, не многие знают, что практически всю настройку логики гулагов, можно производить в файле | + | При создании гулага, не многие знают, что практически всю настройку логики гулагов, можно производить в файле «script». |
Такой способ построения достигается за счёт динамических ltx. | Такой способ построения достигается за счёт динамических ltx. | ||
Попробую описать, каким образом это достигается. Я думаю, многие заметили в файлах с гулагами такую функцию: | Попробую описать, каким образом это достигается. Я думаю, многие заметили в файлах с гулагами такую функцию: | ||
Строка 14: | Строка 14: | ||
Разберём простейший способ построения динамических ltx. | Разберём простейший способ построения динамических ltx. | ||
− | Создаём стандартным способом | + | Создаём стандартным способом «'''smart_terrain'''» в файле «'''all.spawn'''» и гулаг в файле «'''gulag_уровень.script'''». Назначим ему имя, например «kakashki». |
Задаём ему несколько заданий. Например, зададим 3 кампа и двух уолкеров: | Задаём ему несколько заданий. Например, зададим 3 кампа и двух уолкеров: | ||
Строка 41: | Строка 41: | ||
end</pre> | end</pre> | ||
− | Так как мы собираемся использовать динамические ltx, то дальнейшая настройка заданий будет производиться не в конфигурационных файлах, а непосредственно в этом же файле. То есть в упомянутой выше функции | + | Так как мы собираемся использовать динамические ltx, то дальнейшая настройка заданий будет производиться не в конфигурационных файлах, а непосредственно в этом же файле. То есть в упомянутой выше функции «'''load_ltx'''». |
− | Для этого находим нужную функцию | + | Для этого находим нужную функцию «'''load_ltx'''», и в ней создаём динамический ltx и прописываем требуемые схемы логики: |
<pre>--'------------------------------------------------------------------------ | <pre>--'------------------------------------------------------------------------ | ||
Строка 87: | Строка 87: | ||
Где, кавычки обязательны, {\n} назначает новую строку в динамическом ltx, и {..} ставится для привязки строк между собой. | Где, кавычки обязательны, {\n} назначает новую строку в динамическом ltx, и {..} ставится для привязки строк между собой. | ||
В последней строке схем, двоеточие ставить не нужно, так как привязывать больше нечего. | В последней строке схем, двоеточие ставить не нужно, так как привязывать больше нечего. | ||
− | Переменная | + | Переменная «ltx» может иметь любое другое имя. |
------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------ | ||
− | Теперь создаём вэйпоинты путей, в файле | + | Теперь создаём вэйпоинты путей, в файле «'''all.spawn'''», и можно смело идти проверять. |
------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------ |
Версия 07:36, 20 мая 2009
При создании гулага, не многие знают, что практически всю настройку логики гулагов, можно производить в файле «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», и можно смело идти проверять.
Продолжение следует.
Автор: Singapur22