[SoC] Ковыряемся в файлах

[Artos 99]

AndreySol

Во-первых, хватит продолжать викторину "Кто угадает почему у меня НПС не выполняет логику".

Если хочешь получить ответ, то потрудись выложить:

- секцию спавна твоего непися (по крайней мере информацию о ранге и о возможной кастомдате с логикой)

- собственно функцию спавна с координатами ...

- функцию подключения логики (если логика не подключается в секции спавна).

 

Если ты статьи на вики читаешь так же как уже написанное выше, то не удивительно ...

Ведь уже сказано, что схемы AI с их логикой и конфигами логики и гулаги, хоят и связаны в игре, но это совершенно разные вещи!

Любые схемы AI и написаны для одиночек(!), а уж взяты ли эти одиночки в гулаги и розданы ли им схемы гулагом - это уже частность.

AndreySol, По идее, НПС должен идти к этой точке, неважно где именно она расположена ?

Вот как раз и важно! Если НПС в онлайне и точка кампа на текущей локации, то схема активна и он должен пойти к прописанной схемой точке кампа. А вот если он в оффлайне и если тем более на другой локации - то только гулаг может "повести" его к нужной локации и точке.

 

Перебор же "произвольных" точек путей - говорит о полном непонимании вопроса. В схемах вообще как правило точки путей не проверяются на валидность, а отсутствие возможности проверить наличие любой точки не на текущей локации на существование как раз и является препятствием для проведения гулагами неписей к точкам кампа. Любая попытка использовать об'ект пути с непрописанными параметрами ведет к фатальной ошибке.

Изменено 24 Мая 2012 пользователем Artos

[Artos 99]

_Val_, конечно плохое занятие гадать о том, что (в силу языкового барьера) не пояснил автор вопроса ...

Ты говоришь об одном крайнем варианте, т.е. когда заведомо нужно при некоем условии (например актор вошел в некую зону) включить звук и плавно увеличивать его громкость. Конечно де, средствами звукового редактора можно создать трек таким, чтобы звук плавно нарастал и, если нужно и плавно бы затихал.

Но(!) это именно жестко заязанный на это звук. Можно и некий рандом устроить и даже может не рандом, а завязку выбора заранее подготовленных звуков по неким условиям ... Но, во-первых, есть ли требуемые средства в штатных схемах(?) , во-вторых, сколь же звуков нужно наплодить, чтобы увязать со всеми потребными условиями?

Вспомни схему интерактивной озвучки. Рядом с актором появляется враг - включается тихая 'боевая' озвучка. Враг приближается или их становится больше - звук нарастает. Акктор увидел врага - звук лавинно возрастает, враг выстрелил в актора - звук на пределе ... Враг убит, убежал - звук плавно затихает. И т.п. ну как тут рестриктор справится?! Да и не следует забывать, что все(!) схемы с их предикатами жрут ресурсы игры и используют все те же (штатные) скрипты ...

Т.о. если задумано нечто простенькое, типа вошел актор в каморку к Сидоровичу - звук потихонику нарастает, ухотят - затихает (это собственно уже и делает приемник у Сидоровича). Но заставь этот приемник затихать при начале диалога актора с Сидоровичем, и продолжить играть после диалога, иль замолчать при отказе от полученного задания ... ну и т.п. Тут уже не сам звук нужно формировать в редакторе, а именно управлять скриптами (с их алгоритмом) громкостью.

Изменено 24 Мая 2012 пользователем Artos

[Artos 99]

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

И повторюсь, если уже сделано именно на целых композициях и можно задействовать любые потребные условия и их сочетания - стОит ли изобретать способ чесать пяткой нос?

P.S. То, что модуль интерактовной озвучки (by xSream) был написан не как "вообще", а завязан на 'боевку' - конечно ограничение, но взяв его за основу, можно и под "свои" нужды его адаптировать (т.е. завязать на свои условия) и даже написать как "общую" схему с потребными для нее задаваемыми из конфигов иль игры внешними параметрами.

Автор вопроса не силен в скриптах (он как раз дока по звукам), вот кто возьмется написать схему управляемой озвучки? Было бы здорово.

Изменено 24 Мая 2012 пользователем Artos

[Artos 99]

7.9

7.9: Теперь, из-за Вас, придётся доказывать, что я не Сольери!

Вы себе льстите, при всем уважении ... Доказывать чего-то - это похоже Вам сильно захотелось, вот только "кому и чего"? Если приспичило - то подобное "доказывание" - в ЛС.

7.9: То что я написал - можно применять!

...

Так что здесь не так?!

Применять то может и можно - да кому это нужно? Ну а "что не так" - перепрочти исходный вопрос и, как минимум, именно отсутствующее у тебя управление уровнем звука, и превращает тобою понаписаное в никчемный оффтопик.

 

 

 

ColR_iT, прав все же Sync, указав на некорректность твоих слов: "... в оба параметра необходимо вписывать одинаковые координаты", ну и то что ни ГГ в оффлайне ни собственно ни одного серверного об'екта никто из игроков не видит в игре, не обязует писать именно одинаковые параметры.

Ранее как-то давал кратное пояснеие по параметрам upd:***, но т.к. их немало и относятся часто совсем к разному, то общего описания нет и врядли кто даст. Учитывая же еще и завязки на движек, который обрабатывает разницу между двумя частями нет-пакетов ('state' и 'update') можно только гадать когда важно указывать именно одинаковое, а когда именно наоборот.

Примечание: Конечно в контекстве заданного вопроса по спавну актора - координаты могут быть и одинаковыми, но важен именно второй (upd:)

Изменено 25 Мая 2012 пользователем Artos

[Artos 99]

malandrinus, наверное точнее volume для sound_object назвать не параметром, а свойством (property), а запись - изменением, т.к. производится простым присваиванием (snd_object.volume = number).

Именно так и меняется уровень звука в уже не раз упоминавшемся модуле "интерактовной озвучки". Так же в этом модуле управляется (если требуется) и уровень амбиента, дабы доп.озвучка не проигрывалась при открытом главном меню ... О реверберации вроде как пока ни кто не говорил, кроме неясного упоминания от 7.9.

Изменено 25 Мая 2012 пользователем Artos

[Artos 99]

malandrinus, мое уточнение было вызвано простой причиной:

Многие, в особенности недостаточно опытные модмейкеры, начинают 'переменные' смотреть в скриптах, 'параметры' искать в конфигах об'ектов, а 'запись' воспринимают в лучшем случае отдельной функцией/методом ... а то и в pstor'ы иль вообще в нет пакеты. И, ИМХО, 'изменение' несколько точнее понятнее отображает характер операции по 'записи' нужного значения в параметр/свойство об'екта.

Изменено 25 Мая 2012 пользователем Artos

[Artos 99]

AndreySol

О 'необходимости' и создании самому в словах ColR_iT'а было сказано излишне. Подразумевалось, что точка кампа обязательно должна быть прописана в игре, т.к. в противном случае (как ты и писАл по свему горькому опыту) - вылет. Ну а использовать уже имеющуюся валидную точку - это подразумевалось возможным.

Функция подключения логики - в твоем случае отсутстует, т.к. логика автоматически подключается из секции спавна (см. custom_data)

 

P.S.

AndreySol: camp_center - это, если я правильно понял, одна из точек, прописанная в файле путей all.spawn для локации Кордон. Неужели я не могу использовать ее для логики своего НПСа ?

Ткни нас пожалуйста носом туда, где ты отыскал точку с названием camp_center!?

Нет такой точки во всем оригинальном all.spawn! Вы батенька, совершенно не читаете топик и даваемые в нем пояснения/разяснения. Даже не знаю, стОит ли продолжать в очередной раз повторяться ...

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

Особенность именно этих конфигов в том, что ко многим наименованиям и в частности для путей к указанной строке в названии параметра соответствующий гулаг пристыковывает суффикс - название гулага. Т.о. например для костра в деревне новичков, соответствующий этой деревне гулаг (esc_lager) выдаст имя для точки кампа: esc_lager_camp_center и именно эта точка имеется в алл.спавне.

Так что если бы ты потрудился бы найти именно точку esc_lager_camp_center и именно ее указать в логике - то вопросов бы и не возникало.

Итого, "правильная" логика для активной схемы kamp у отвязанного от гулагов непися будет такой:

[smart_terrains]
none = true

[logic]
active = kamp
trade = misc\trade_technic.ltx

[kamp]
center_point = esc_lager_camp_center

- и твой НПС спокойно идет к костру и усаживается возле него.

Ну или позаботься, как и писал ColR_iT, создать свою точку с названием camp_center и прописать ее в алл.спавн.

Изменено 25 Мая 2012 пользователем Artos

[Artos 99]

AndreySol, 3. НПС отрабатывает схему "kamp", все вроде нормально - сидит у костра ест, пъет и т.д. Но если сделать сохранение\загрузку игры, то он, после загрузки, у костра не садится, а стоит тупо, ни на что не реагирует. В чем причина, как это можно исправить ?

Причина в тупом (бездумном) отношении моддера к собственно процессу моддинга (внесения изменений в игру). Хочется в очередной раз спросить в ответ: "Что тобою понимается под моддингом?". Использование копипастом наработок других и вопрошание к другим, если чего-то не знаешь иль не нашел в туторах? А своя голова для чего?

Во-первых, в игре много чего завязано и возникновение коллизий/ошибок может возникать по самым разным причинам, в особенности при внесении "своих" правок. Что тобою (самим) сделано, чтобы понимать отчего и где возникает ошибка? Или только уповаешь на ответы "ясновидцев" на форуме?

Во-вторых, схема кампа, как было ранее показано, работает и при слхранениях и загрузках. Да, порою в игре встречается, что некоторые камперы тупо стоят у точки посиделок, пока не произойдет некоторое событие, после которого схема нормально активизируется ... Но эта помарка пока не решена ни в чистой игре ни в модах и причина не ясна.

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

 

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

Изменено 26 Мая 2012 пользователем Artos

[Artos 99]

ColR_iT, все же чуть продолжу "оффтопик" т.к. забыт немаловажный момент:

Помимо наличия собственно AI-сетки для каждого непися/монстра существует и параметр в конфигах 'terrain', который ведает доступными зонами.

Да и никто не отменял того, что в активной схеме боевки неписи могут "плевать" на накоторые ограничения наложенные на них в "спокойных" схемах/состояниях.

Изменено 26 Мая 2012 пользователем Artos

[Artos 99]

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

Ты просто напросто заспавнил в нужную точку об'ект вертушки и прописал этому об'екту реагировать на хиты после вхождения актора в рестриктор, т.е. загораться от полученного хита и проигрывать звук. Ну и кто должен хитовать вертушку?

Да и "висит" твой вертолет из-за свойств самого об'екта и не подумает упасть пока не взорвется. А гореть он может сколь угодно долго ...

[Artos 99]

MgVolkolak, ну ... писать схему - громко сказано. ;-)

Можно все "записать" в path_move для твоей вертушки.

1. Создаешь точку где висеть вертушке.

2. Создаешь путь с точками координаты которых описывают траекторию падения твоей вертушки, в нужной точке включаешь флаг "flame" (загореться), а в конце - "die" (взорваться).

Т.е. все решается имеющимися средствами heli_move.script. Остается привязать переключение созданных точек/путей твоим инфопоршнем вхождения актора ...

Изменено 27 Мая 2012 пользователем Artos

[Artos 99]

DiSo95, тут все же раздел "Школа моддинга", а не "дайте мне готовую функцию"!

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

По спавну НПС есть целая тема.

Присвоить story_id при спавне скриптом можно только через нет-пакеты, методы работы с которыми в "одну функцию" не влезают. Примеров в готовых модах предостаточно вместе с функциями работы с нет пакетами.

[Artos 99]

(возвращаясь к прошлым вопросам)

SkyLoader Частенько мешает данный вылет: ! error in stalker with visual actors\bandit\stalker_bandit_5

(оригинал вопроса: #8683)

Похоже связана ошибка с изменениями состояний mental_state и body_state.

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

Похоже менеджеру состояний (state_mgr) не нравится когда скрипт постоянно перебивает его установки - и следует или им самим воспользоваться втой или иной ситуации или отключать его. Т.к. ситуаций множество и в самых различных скриптах/схемах - конкретный рецепт лечений зависит от контекста.

[Artos 99]

Saruman, а откуда такая уверенность в том, что НЕ используются(?), тем более сам же противоречишь себе: "с учетом защиты артов и броника". Так как-же учитывается с учетом защиты броника, как не из соответствующих секций?!

Все файлы инклюдов, указанные в моделях, считываются и параметры обрабатываются, и в конечном итоге ведут к \gamedata\config\creatures\damages.ltx и immunities.ltx, откуда и берутся коэф-ты защиты/урона костюмов.

 

utc, а что удивительного в том, что разные костюмы имеют одинаковую защиту? Во-первых, костюмов много, а секций описывающих параметры защиты - немного. Во-вторых, актор в игре надевает костюмы не только из папки actors/hero/... . И, наконец, ничто не мешает прописать любому костюму свою секцию и в ней задать нужные модмейкеру параметры (примечание: разработчикам игры хватило имеющихся).

[Artos 99]

Saruman, читая написанное не искажай сказанное и не превращай "белое в черное".

Мною сказано, что все инклюды из моделей броников читаются и обрабатываются. То, что в секциях броников продублирован параметр bones_koeff_protection (как в прочем и immunities_sect), мною не забыто. Это всего лишь переназначение, которого может и не быть в конфиге, т.к. первичен именно инклуд из модели. Суть же в любом случае та же - все ведет в указанный damages.ltx.

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

Углубляться (пока) в вопрос "это визуалы только для неписей, а это только для актора" - пока не вижу причины (вопрос пока вроде как не об этом).

Ну а по поводу твоих тестов, позволь улыбнуться Чем и в чЁм меряем, хотелось бы знать?! В "попугаях"?

Повторно обращаю твое внимание на то, что если следовать твоим словам: "вывод для гг вообще работают параметры распределения урона по костям только из actor.ltx" - то актору вообще нет смысла носить какой-либо костюм, все одно ведь ты утверждаешь толку для защиты от него ноль.

Не путай себя и других, защита костюма не дает бессмертие/пуленепробиваемость(!), а всего лишь ДОБАВЛЯЕТ к распределению урона дополнительные значения. Выстрелив в грудь бронебойным - убьешь и в экзоскелете, а вот от дробины урон здоровью будет нулевым, если надет соотв.костюм. Так что тестируя, проверяют не будет ли убит иль нет, а каков урон именно актору от одинакового по значению хита по одним и тем же костям с тем иль иным костюмом иль вовсе без ...

Изменено 2 Июня 2012 пользователем Artos

[Artos 99]

Saruman, да в общем можно упрощенно сказать и так.

Тебе нужен "фиксированный выстрел" (хит), т.е. с заведомо известными параметрами хита. Тогда, имея полученные (например из коллбэка) именно актором (иль неписью)значения по кости (bone) и величине (amount) и сколько это отняло здоровья, ты получишь сколько на себя взяла "защита костюма" ... Вот тогда можно говорить о (не)влиянии.

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

 

Но суть ответа на вопрос utc не изменится. Т.е. у разных костюмов могут быть одинаковые секции для защиты, что не мешает иль костюмы актору менять или секции защиты изменять, меняя тем самым коэф-нт защиты от надетого костюма.

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

Изменено 2 Июня 2012 пользователем Artos

[Artos 99]

Priboj37, не следует с одной стороны мешать все в одну кучу, как и не следует отделять взаимосвязанное.

"Комбeз идeт, кaк доп. зaщитa к имунитeту" - достаточн глупая фраза. Комбез дает дополнительный иимунитет, а не идет к нему ...

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

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

Ну и не стОит тут еще устраивать какофонию из "хитов ствола" и пр ... ;-)

Хит он и в африке хит и может быть нанесен и когтем и костром/аномалией и прочими неогнестрелами. "Комбез" же защищает и в этих случаях в той или иной степени.

 

Если есть что по делу сказать - так и говори, а не бросай невнятные фразы в воздух ...

Изменено 2 Июня 2012 пользователем Artos

[Artos 99]

Saruman, которая (тема) и подтверждает:

Параметры зашиты броников определяются указателем bones_koeff_protection из outfit.ltx для каждого броника.

Однако, автор (frags) проводил тестирование именно акторских костюмов, т.е. тех броников, которые имеются в конфигах как "костюмы/броники", т.е. хотя и широкий, но все же ограниченный ассортимент.

В более общем случае bones_koeff_protection берется из модели (визуала). Для неписей это обязательно, для актора - если нет в конфиге броника.

Все остальное в теме - по-аналогии.

Изменено 2 Июня 2012 пользователем Artos

[Artos 99]

(опять возвращаясь к прошлому вопросу: см. #8683 и http://www.amk-team.ru/forum/index.php?sho...st&p=704064)

 

Т.к. ошибка в алгоритме оттаскивания трупов в схеме 'kamp' может возникать во многих модах, использующих коды by xStream, и в ЛС просят поделиться решение проблемы, решил привести его тут:

 

1. Алгоритм отттаскивания трупов является встроенным в схему кампа, но при активизации собственно процесса оттаскивания менеджер состояния тел (state_mgr.script) не блокируется/переназначается, а перебивается постоянными апдейтами на новые значения для состояния тела. Смотрим в xr_kamp.script (взят из NLC6):

function action_moving_deadman:execute()
  action_base.execute(self)
  --/...
  -- смотри мне в глаза!
  local dir=gi:position():sub(npc:position())
  dir.y=0
  npc:set_movement_type(move.walk) --/ принуждаем неспешно идти
  npc:set_mental_state(anim.danger) --/ принуждаем "опасливо"
  npc:set_body_state(move.crouch) --/ принуждаем присесть
  npc:movement_enabled(true)
  npc:set_sight(look.direction,dir,true) --/ принуждаем посмотреть и ожидать сигнала
  --/...
end

 

Обычно все проходит нормально и труп оттаскивается, но ... Порою (не всегда и не часто) возникают ситуации, когда тело/труп по какой-то причине "застревает" (уткнулся в порог, попал в яму, ...) и непись начинает "дергаться", постоянно возвращаясь в дефолтное для кампа состояние ("def_state_moving" - идти к точке посиделок) и вновь получая другие состояния для оттаскивания. В основном именно "встать-присесть" и приводит вероятно к переполнению менеджера состояний и движек рушит игру с сообщением типа:

! error in stalker with visual actors\bandit\stalker_bandit_5

- т.е. ошибка с визуалом некоего сталкера, который занимается оттаскиванием.

 

2. Решение довольно простое. Зачем постоянно дергать визуал, заставляя то вставать то приседать? Раз решил непись заниматься оттаскиванием - то и состояние тела нужно именно переключить/изменить, а не дергать из дефолтного в "рабочее".

Заменяем указанные строки на такие:

function action_moving_deadman:execute()
  action_base.execute(self)
  --/...
  -- смотри мне в глаза!
  if state_mgr.get_state(npc) ~= "sneak_no_wpn" then --/ если еще/уже не в состоянии "тащить"
    --/ состояние: тащить неспешно, убрав оружие, с опаской, в присяде, смотря на труп
    state_mgr.set_state(npc, "sneak_no_wpn", nil, nil, {look_object = gi}, {animation = true})
  end
  --/...
end

 

Т.е. исходное состояние для схемы kamp заменяем на нужное нам. Взято уже имеющиееся в игре состояние "sneak_no_wpn", которое и задает телу непися требуемые параметры (move.walk,anim.danger,move.crouch), но желающие могут подобрать что-то "свое" ... Теперь стейт-менеджер не будет дергаться, а будет именно отслеживать "тащит" или нет и вмешиваться только при необходимости.

По окончанию процесса оттаскивания трупа для НПС вернетсяи его дефолтное соостояние, чтобы мог проследовать к точке кампа и заняться своими делами, т.к. в action_moving_deadman:finalize() уже имеется возврат к self.a.def_state_moving.

 

Данное решение пригодно для всех модов использующих дополнение по оттаскиванию трупов в схеме kamp.

 

Добавлено через 105 мин.:

P.S. Данная ошибка с визуалами может возникать не только в схеме модифицированной 'kamp', но и в других аналогичных (добавленных) схемах, где возникает 'конкуренция' задаваемых различными активными схемами состояний тела для управляемого об'екта (непися). Следует или недопускать периодических переключений или фильтровать подобные переключения по некоему периоду (~1sec).

Изменено 2 Июня 2012 пользователем Artos

[Artos 99]

Morder07, Priboj37, Digefal

Раз упомянут бы алгоритм то и следует именно его знать и понимать, а не методом тыка нащупывать иль погадалками заниматься.

1. Неписи, хотя и могут стрелять, но оружие от этого никак НЕ изнашивается.

2. Алгоритм менеджера лута (death_manager.script) таков:

- все предметы имеющиеся в трупе проверяются на наличие в секции [keep_items], и если имеются - обязательно остаются в трупе "как есть";

- все, которые не в секции подпадают или под обязательное или рандомное удаление;

- оружие в трупе, которое не в списке keep_items - проходит операцию разрядки и/или поломки (зависит от модов);

- по окончании итерации по имеющимся в трупе предметам, в труп спавнится лут, состав которого определяют различные death_items_by_ХХХ.ltx.

Т.о. не стоит удивляться поломкам/исчезновениям или появлениям тех или иных предметов в трупах.

Изменено 7 Июня 2012 пользователем Artos