Сповіщення
Очистити все
03.11.2023 23:38
При створенні гулага, не всі знають, що практично все налаштування логіки гулагів, можна робити у файлі «script». Такий спосіб побудови досягається рахунок динамічних ltx. Спробую описати, як це досягається. Я думаю, багато хто помітив у файлах з гулагами таку функцію:
--'----------------------------------------------- ------------------------- --' Dynamic ltx --'----------------- -------------------------------------------------- ----- function load_ltx ( gname, type ) return nil end
Це саме та функція, яка відповідає за динамічні ltx. У цьому випадку вона відключена. Розберемо найпростіший спосіб побудови динамічних ltx.
Створюємо стандартним способом " smart_terrain " у файлі " all.spawn " і гулаг у файлі " gulag_уровень.script ". Призначимо йому ім'я, наприклад, «noobiki». Задаємо йому кілька завдань. Наприклад, поставимо 3 кампа і двох уолкерів:
if type == "noobiki" then for i = 1 , 3 do t = { section = "logic@noobiki_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@noobiki_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 == "noobiki" then local ltx = "[logic@noobiki_kamp] \n " .. "active = kamp@kakashki \n " .. "[kamp@noobiki] \n " .. "center_point = kamp \n " .. "[logic@noobiki_walker_1] \n " .. "active = walker@kakashki_1 \n " .. "[walker@noobiki_1] \n " .. "path_walk = walk_1 \n " .. "path_look = look_1 \n " .. "[logic@noobiki_walker_2] \n " .. "active = walker@kakashki_2 \n " .. "[walker@noobiki_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@noobiki_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@noobiki_walker_1" ; "logic@noobiki_walker_2" ; "logic@noobiki_walker_3" і т.д.
У разі, змінної " prior " задано значення 9-i , що робити необов'язково. Тут при кожному циклі рахунку віднімається значення змінної i від числа 9 . У результаті, при кожному наступному циклі, змінної " prior " задається значення на 1 менше попереднього.
Отже, уолкер створили. Тепер нам потрібно поставити їм усім логіку дій. Створюємо змінну ltx , яку ми використовуватимемо для динамічних ltx. Для цього піднімаємося на самий верх файлу, де прописано створення змінної t і нижче прописуємо:
local ltx = ""
Тепер, у функції " load_ltx " створюємо ltx файл для нашого гулага:
function load_ltx ( gname, type ) if type == "noobiki" then return ltx end return nil end
У такий спосіб ми повертаємо пошук секцій логіки, назад у функцію " load_job ".
Тепер повертаємось у функцію " load_job ", і в секції нашого гулага, усередині лічильника " for-do " прописуємо логіку уолкерам. Виглядатиме це так:
for i = 1 , 8 do
t = { section = "logic@noobiki_walker_" ..i,
idle = 0
prior = 9 -i, state = { 0 , 1 } ,
in_rest = "" , out_rest = ""
}
table.insert ( sj, t )
ltx = ltx.. "[logic@noobiki_walker_" ..i.. "] \n " ..
"active = walker@noobiki_" ..i.. " \n " ..
"[walker@noobiki_" ..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 . І все працюватиме як годинник.
Не забуваймо, при створенні секцій поінтів до імен шляхів пришити ім'я смарт террейну.
