Banderos_add_for_AMK_MOD

[IG-2007 0]

banderos

Отпишусь тут.

 

Я сделал вот так:

...

(37.97,11.18,-99.77), 221455, 820

Вроде всё как надо.

 

Вот только аналогичный снайпер в all.spawn имеет такие параметры:

name = val_watchtower1_bandit_sniper

position = -49.6784553527832,11.208517074585,8.38117504119873

game_vertex_id = 819

level_vertex_id = 116044

хотя, это не очень важно, если позиция не та, то дойдёт ножками до нужной.

 

Там ещё есть такая строка: predicate = wt_predicate_s, её тоже надо убирать

Можно не убирать. Работа для снайперов не назначится как с этой строкой, так и без неё. При добавлении этой работы, проверяется наличие путей для снайперов в all.spawn, а путей этих там нет. Пути прописаны только для первой работы - для часовых.

 

нужно ли начать "новую игру", чтобы изменения в этом файле действовали?

Точно не знаю, но думаю, что начинать новую игру не надо.

 

Если я правильно понял, Вы такой пример уже приводили...

Да, правда тут возможна некоторая путаница, т.к. я не доконца понимаю весь этот механизм:

у npc два поля для рестриктов base_out_restrictors и base_in_restrictors (?рестрикты, внитри/снаружи которых можно ходить?), может нужно было прописать название рестрикта в другое поле?

 

Рестрикты в данном случае - это область пространства, ограничевающая перемещение. Зачем это нужно? точно не знаю, может для того, чтобы случайные неписи не ходили в этом месте. Вот один из рестриктов, для первой вышки:

[2303]
; cse_abstract properties
section_name = space_restrictor
name = val_watchtower1_restr
position = -49.0167427062988,7.3995189666748,8.30681037902832
direction = 0,0,0

; cse_alife_object properties
game_vertex_id = 811
distance = 0
level_vertex_id = 316473
object_flags = 0xffffff3e

; cse_shape properties
shapes = shape0
shape0:type = box
shape0:axis_x = 5.8149995803833,0,0
shape0:axis_y = 0,16.1853523254395,0
shape0:axis_z = 0,0,5.8149995803833
shape0:offset = 0,0,0

; cse_alife_space_restrictor properties
restrictor_type = 2

Собственно - это некий box, который закрывает собой всю или почти всю вышку. Npc, у которого нет разрешения ходить в этом рестрикте, не сможет подняться на вышку. Похоже у вас это и происходит.

 

 

Прописать рестрикт npc можно:

1) в all.spawn. Помоему, так делается для тех неписей, у которых нет терейна. Например, военные часовые на вышках Агропрома.

[1455]
...
name = agr_tower3_soldier
...
custom_data = <<END
...
[smart_terrains]
none=true
END
...
[b]base_out_restrictors = agr_space_restrictor_tower3[/b]

 

2) можно попробывать сделать через net_packet, если нет клиентского объекта (то что я предлагал)

 

3) в работах гулага. Так делается много где, например, для ваших снайперов:

-- добавляем должность
t = { section = "logic@" .. idstr,
    idle = 0,
    prior = 1, state = {0}, squad = squad, group = groups[1],
    position_threshold = 10,
    in_rest = "", [b]out_rest = gname .. "_restr"[/b]
}
table.insert(sj, t)

 

4) если есть клиентский объект, то можно вызвать функцию npc:add_restrictions(in_restr, out_restr). Таким способом kstn в ArenaExtensionMod привязывал неписей и монстров к арене. Только вот отловить момент появления нужного клиентского объекта бывает проблематично. Либо нужно переписывать функцию net_spawn для нужного binder-а, либо делать свой binder.

 

Есть ещё такая особенность, глобальные схемы поведение, вроде реакции на выброс, первым делом отключают неписям все идиотские ограничения (комментарий Red75), т.е. прописанные для них рестрикты. Восстанавливаются ли эти рестрикты потом - не знаю, но раз вы говорите, что снайперы на Агропроме возвращаются на вышки, то наверное восстанавливаются.

[IG-2007 0]

вот сижу и не понимаю, что за предикаты...

объяснили б, что-ли

predicate - это просто функция, которая участвует в проверке и распределении работ гулага для приходящих в него неписей. Назначение вроде можно примерно понять по вызовам функций и комментариям разработчиков (xr_gulag.script + smart_terrain.script). Основная задача отправлять конкретных неписей на конкретные работы.

 

Кстати, мысля появилась пока писАл ответ. Не перепутают ли снайперы, если совсем убрать predicate, свои вышки? Возможно этот predicate придётся оставить, но немного переделать...

[IG-2007 0]

Предикты - это имена функций, сами функции определены парой строчек выше в том же файле скрипта gulag_dark_valley.

-- Predicates ------------------------------------------------------------
function wt_predicate_g(npc_info, gulag) -- guard
    return string.find(npc_info.name, gulag.name) ~= nil
end

function wt_predicate_s(npc_info, gulag) -- sniper
    return string.find(npc_info.name, gulag.name) ~= nil and npc_info.is_sniper == true
end

npc_info - это структура, заполняется в файле "se_smart_terrain.script" в функции se_smart_terrain:fill_npc_info

 

Вот, набросал то, что знаю про гулаги. Всё ИМХО, 100% правильность не гарантирую.

 

Гулаги - это только часть несколько большей темы. Желательно, для начала, взглянуть на всё это в общих чартах.

 

Распределение живности по Зоне.

Первое, что делается, выбирается место, где должна обитать живность. В этом месте создаётся smart_terrein - это специальный объект игры.

Потом создаётся гулаг (это уже не объект, а скрипты и ltx), в котором для каждой живой души прописывается, что она должна делать в разных ситуациях: сидеть у костра, стоять в дозоре, прятаться под кустом, штурмовать базу и т.д.

Затем создаётся сама живность. Тут возможны варианты: либо разовый спавн через all.spawn, либо респавнер, либо и то и другое.

Все регулярные скопления живностей (стаи, стоянки сталкеров, заставы) работают по этому принципу. Некоторые скопления могут появляться или пропадать по мере развития сюжета, делается это добавлением специальной строки в кастам дату smart_terrein-а, в которой содержиться условие его существования (наличие или отсутствие сюжетных инфопоршинов). Как правило включение и отключение терейнов производится синхронно с респавнерами, которые генерят подходящих терейну персонажей.

Ещё одна особенность использования терейнов заключается в том, что подходящий ему персонаж, где бы он ни был, будет движком игры переведён в нужное место. Т.е. это такой движковый метод перевода персонажей как внутри одной локации, так и между локациями. Причём перемещение будет производиться как в онлайне, так и в офлайне. После того как персонаж дойдет до своего терейна, движок его оставляет в покое, теперь им начинают управлять скрипты гулага, соответственно только в онлайне.

 

Теперь о гулагах.

Гулаги используются в игре повсеместно, как для регулярных скоплений живности, так и для разовых скриптовых сцен.

Когда существо зачисляется в гулаг, ему назначается некая работа. Работа - это текстовая последовательность секций, каждая секция служит для задания схемы поверения. Принцип такой же, как и при прописывании последовательности напрямую в кастом дату существа. Отличие, помоему, лишь в задание путей. Если в прямой записи название пути читается схемами как есть, то в случае гулага к названию пути прибавляется название гулага. Более конкретную информацию по различным схемам и их настройкам можно посмотреть в оффициальном документе: Настройка логики (часть 1) Там же есть немного и о гулагах.

Помимо задания последовательности, при назначении работ работнику могут быть добавлены особые способности: рестрикты, не переводимость в офлайн... Эти способности задаются в параметрах работы.

Есть в гулагах возможность синхронного перевода работников с одной работы на другую. Для этого используется статус гулага и в параметрах работ указывается для каких статусов она подходит. Используя такой механизм, можно сделать смену активности в зависимости от времени суток (день/ночь), можно сделать зависимость от численности (рейды, как только все участники прибывают в гулаг) и т.д.

Гулаги бывают двух видов: обычные (general) и... не обычные.

Обычные гулаги сделать проще, т.к. создание списка работ происходит автоматически по заданному в "gulag_general.script" шаблону. Чтобы такой гулаг заработал достаточно сделать терейн, указать для него тип general_lager (для людей) или general_lair (для мутантов). После этого нужно в all.spawn прописать несколько путей с предопределёнными именами:

gname.."_kamp_"..1, gname.."_kamp_"..2, ... - если нужно, что бы были посиделки,

gname.."_sleep_"..1, gname.."_sleep_"..2, ... - если нужно, что бы были спящие,

и т.д. (полный список можно составить анализируя "gulag_general.script")

gname - это название гулага (или терейна)

Нужно ещё прописать предусловия для приёма в такой гулаг, это делается в файле misc\general_lager.ltx или misc\general_lair.ltx. В качестве предусловий выступает ранг персонажей. Группировка тоже является предусловием, но задаётся она в настройках терейна, там же задаётся и максимальная вместимость.

Необычные гулаги используются везде, где шаблонных возможностей недостаточно. Например, требуются более сложные работы, проигрывание анимаций, дополнительные условия для приёма и т.д. Для таких гулагов создаётся терейн с типом, отличным от обычного. После этого нужно внести необходимые изменения в скрипт гулагов для нужного уровня или можно добавить свой. Например, для Темной Долины изменения нужно делать в скрипте gulag_dark_valley.script. Все работы прописываются вручную, есть возможность прописать работы непосредственно в скрипте или прописать в ltx и подгрузить из него.

 

PS: banderos, извиняюсь что так много и не совсем в тему.

[IG-2007 0]

Проводил тут один эксперимент, и пришёл к выводу, что единственная возможность "научить" моих снайперов залезать обратно на вышку, это разрешить им находиться в рестрикторах "родных" снайперов\дозорных. По другому, думаю, никак не получится. В ходе эксперимента пробовал создать рестриктор специально для моих снайперов по аналогии с рестриктором для "родных" снайперов через all.spawn, изменив название рестриктора. Но, потом понял, что это бесполезно, т.к. первоначальный рестриктор то остался .

Создавать новый гулаг также бесполезно, т.к. рестрикторы старого остаются.

Всё вроде правильно.

Рестрикт, если уж очень мешает, можно удалить скриптом (release)

 

Рассматриваю ещё такой вариант. Это присвоить своим снайперам имена, похожие на имена "родных". Например, "родной" с именем val_watchtower_bandit_sniper, а своего назвать val_watchtower_banderos_sniper, т.е. чтобы название в начале (val_watchtower_) и в конце (_sniper) совпадало с "родными" снайперами. Также, по аналогии и с _guard'ами, и в кустом дате прописать [smart_terrains]\nval_watchtower1 = true, соответственно позиции и вертексам существующих снайперов и мной созданных (т.е. подобрать smart_terrains - val_watchtower1, val_watchtower2 и т.д.)

Как я понял, рестриктор "пускает" в области вышек только неписей с определённым именем, в котором, согласно гулагам в gulag_dark_valley.script должны присутствовать val_watchtower_ и _sniper (или _guard), и только в этом случае неписи буду допущены до работы в гулаге.

Возможно ли, что такой вариант, со сменой имён моих снайперов, прокатит? И стоит ли копать в этом направлении?

Если я не прав, то какие могут быть варианты обхода (включения моих снайперов) этих рестрикторов ещё?

В именах должна быть ещё цифорка после watchtower.

А как вы собрались присваивать им имена? Насколько мне известно этого уже через net_packet-ы от АМК не сделать. Сделать такое можно только через all.spawn или изврат с перепаковкой cse_abstract. Хотя в вашем случае будет достаточно сменить название секции спавна, т.к. полностью задавать имя не требуется.

 

Идея рестриктор "пускает" в области вышек только неписей с определённым именем не правильная. Рестрикт пускает тех у кого он прописан. Прописывается он тем, кто назначается на работу часовых в гулаге. В гулаг попадают только те, кто в кастом дате имеет соответствующую запись со смартом и прошёл проверку предикатов (если вы её оставили), а вот проверку может пройти только тот чьи имена содержат val_watchtowerN. Вывод такой: если хотите использовать гулаг, то либо вы настраиваете персонажей под текущие предикаты, либо настраиваете предикаты как вам удобно.

 

Если спавн снайперов будет разовый, то можно сделать ещё так.

Пропишите родным снайперам в кастом дату в секцию [spawn] (точно уже не помню, может в какую другую) условие спавна. Например, наличие некого инфопоршина. Снайперы будут созданы при старте игры, но сидеть в офлайне до той поры пока этот инфопоршин не появится. А появиться он должен в тот момент, когда вы сочтёте нужным, например, после некого диалога. Так себе вариант: (1) требует начала новой игры, (2) возможно, точно не знаю, что АМК офлайн-алайф их укокошит...

[IG-2007 0]

А что за скрипт? Как на него посмотреть? И как он работает? Я имею ввиду, с его помощью можно совсем удалить мешающий рестрикт, или можно удалить этот рестрикт в определённый момент, например, запуская его из диалога?

local sobj = alife():object("имя_объекта_нужного_рестрикта_из_all.spawn")
alife():release(sobj, true)

 

Про персонажей, если правильно понял, нужно сделать, примерно так:

function spawn_sniper_banderos()

local obj = alife():create("val_watchtower4_banderos_guard",vector():set(37.97,11.18,-99.77),221455,820)

local params=amk.read_stalker_params(obj)

params.custom="[smart_terrains]\nval_watchtower4 = true"

params.sid=481519

amk.write_stalker_params(params,obj)

end

 

Четыре (val_watchtower4), это потому как по позиции и вертексам (почти точно) мой снайпер и этот "родной" guard совпадают. И прописать такое же val_watchtower4_banderos_guard в соответствующих (spawn_sections.ltx, npc_profile.xml и character_desc_darkvalley) файлах. И так сделать с каждым из четырёх снайперов, присваивая им соответствующие номера в именах согласно занимаемой позиции и вертексов.?

Примерно так...

 

А вот как предикаты настроить под своих персонажей я даже не представляю . Если возможно, подскажите, IG-2007.

Самый простой способ - уберите их. Это именные смарты с единственной работой, посторонние npc сюда попадать не должны, только те, у кого прописаны данные смарты. Накой эти предикаты здесь вообще нужны - не понятно.

Второй вариант, меняйте функцию предиката, например так:

function wt_predicate_g(npc_info, gulag) -- guard
    if string.find(npc_info.name, gulag.name) ~= nil then
        return true
    elseif <своё_условие> then
        return true
    end
    return false
end

 

PS: замучили меня совсем... попробую всё сделать сам, как будет результат отпишусь.