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), т.е. прописанные для них рестрикты. Восстанавливаются ли эти рестрикты потом - не знаю, но раз вы говорите, что снайперы на Агропроме возвращаются на вышки, то наверное восстанавливаются.

[xStream 86]

восстанавливаются....

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

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

вобще интересно, кто может по гулагам инфу предоставть?

[IG-2007 0]

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

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

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

 

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

[xStream 86]

не, что такое предикат, я в принципе понял

я про wt_predicate_s

это типа некие предопределенные предикаты, которые потом можно юзать?

 

PS тут подумал, что вот этот документик многим пригодиться может - "настройка логики"

[banderos 17]

banderos

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

...

Сам хотел предложить .

 

Спасибо за мысли и инфу IG-2007! ...Перевариваю .

 

PS тут подумал, что вот этот документик многим пригодиться может - "настройка логики"

 

Благодарю, xStream! Очень полезный матерьяльчик. Я его читал как-то на Inside Wiki, но Ваш вариант более удобный в пользовании .

Буду грызть, по мере способностей...

[xStream 86]

на вики он не весь

потому и выложил

[Гость Nekt]

Предикты, содержат ссылки на профили.. Ну, по id расчёта не знаю, но чисто названием мона засунуть. ))

Возможно я не прав, но доказывающий это информации я не нашёл, так-же как и обратно доказывающий что я прав. Хотя практика все расставит на свои места.

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

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

[xStream 86]

про рестрикторы и я писал

in-рестрикторы - в которые запрещено входить

out-рестрикторы - из которых выходить нельзя

 

ты не прав, а IG-2007 прав

по воздуху они ходят в случае сбоев, так как ходят они по АИ сетке, а ее нет в воздухе

[Гость Nekt]

А тогда зафиг рестрикторы? чтоб было?

Я чуть позже объясню почему он не прав.. Если конечно будет время.

Я про случай с воздухом предположил.. Просто я не могу понять, почему нельзя нпс ходить дальше точек.. рестрикторы как я понял в бою запрещают и в погони?

[xStream 86]

я написал зачем рестрикторы нужны, или ты не читаешь?

[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, извиняюсь что так много и не совсем в тему.

[Гость Nekt]

function wt_predicate_g(npc_info)  -- guard
    return npc_info.profile_name == "val_watchtower_bandit_guard"
end

function wt_predicate_g(npc_info)  -- sniper
    return npc_info.profile_name == "val_watchtower_bandit_sniper"
end

Помой-му правильнее.. Если уж говорить об этом.

Или Стрим ты снова будешь говорить, что это все не правильно ?

[xStream 86]

неуниверсальный вариант - отталкиваться от профиля

совершенно неподходящий, ибо любой непись с таким предикатом попасть может, даже если относится к другому гулагу (для тех случаев, когда непись может находиться под несколькими гулагами)

у него же проверка на валидность информации и принадлежности к гулагу, хотя тоже не самый лучший вариант

как раз над проблемой переделки системы гулагов и работаю

[Гость Nekt]

Интересно как можно работать над тем, чего совершенно не знаешь.. Кстати по твоим словам.

Отталкиваться от профиля это как? просто профиль вноситься, профиль оригинальный специально для них делался. Согласен могут быть проблемы если такой профиль засунуть в долг или в свободу. Но зачем их туда сувать? для их персонажей есть своё. Кстати что я писал выше, не совсем идентично оригиналу сталка. Там профиль чуть по другому называется.

[xStream 86]

я быстро учусь или ты сомневаешься?

а профиль - ГЛУПО, ОЧЕНЬ делать спец профиль для гулага. нравится - делай, но другим не навязывай я же не навязываю, я просто люблю универсализм.

[Гость Nekt]

Я не учитель, но не верю совсем другую вещь..

А, как ты предлагаешь универсальность?

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

[Pxan 15]

Задам типичный вопрос " будет ли адаптация под NLC 4.0" ?Мод очень интересный. Особенно настоящие снайперы на вышках.Так держать!!!

[xStream 86]

и ответ скорее всего обычный - будет., если сам скрестишь ИЛИ найдешь кого-то, кому оно тоже надо и кто может скрестить ИЛИ автор скрестит, но я не уверен в этом, совсем не уверен

[TIREX 4]

и ответ скорее всего обычный - будет., если сам скрестишь ИЛИ найдешь кого-то, кому оно тоже надо и кто может скрестить ИЛИ автор скрестит, но я не уверен в этом, совсем не уверен

 

Да вот у меня такая мысль появилась.... но только вот хочется еще все исправления ошибок от Bardakа вставить...

Я когда-то stk10003_bug_fix к Нейтрино прикручивал.. Разнообразило игру. Много заданий восстановилось.

а то вот, к примеру, играет новичок и не понятно ему - от кого сталкеров на складах защищать...

а есть от кого....

самое главное - чтобы время было для этого.

[Гость Nekt]

http://slil.ru/25702512 файл где написаны изменения на мой взгляд патча под сталкер от бардака.. Файлы diff ) открыть мона блокнотом, под патч 1.0004