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

[Artos 99]

_Призрак_, скорее "шутишь" ты...

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

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

Ну и, ты бы почитал последние посты, прежде чем "советовать". Изменять, добавлять 'updates' для костюма, что затеял Shredder, ты тоже собираешься парой строчек by Charsi?

 

Не стОит сводить вопрос заданный для 'общего' случая к упрощениям и частностям. Этот раздел "школа..." не для выдачи на гора пары строчек готового кода, а все же (само)обучение, т.е. как и чем работать в той или иной ситуации.

Надеть шоры никогда не поздно, а вот снять их часто даже не знают как...

 

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

Изменено 5 Октября 2012 пользователем Artos

[Artos 99]

Clayman, а можно узнать откуда этот бред про граф-поинт и тем более о 'нужно создать на другой локации'?

Все необходимыt параметры для коордират и направления задаются по-отдельности (dest_game_vertex_id, dest_game_vertex_id, dest_position, dest_direction) и именно они определяют в какой точке на локакции окажется актор и куда будет смотреть.

Парамет dest_graph_point имеет строковое значение ('start_actor_XX') и может даже быть пустой строкою.

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

К сожалению сканирование ресурсов игр (ТЧ/ЧН/ЗП) на предмет нахождения каких-либо "граф-поинтов" иль чего иного с именами 'start_actor_XX' - ничего не дает, кроме упоминаний этого непонятного параметра в секциях левел-ченджеров...

При экспериментах - задание любой строки-имени для этого параметра не давало никакого видимого эффекта.

Изменено 5 Октября 2012 пользователем Artos

[Artos 99]

Clayman, вот теперь можно дать ответ (спасибо за наводку):

dest_graph_point - имя граф-поинта (точки на карте) которому в SDK сопоставлены dest_game_vertex_id, dest_game_vertex_id, dest_position, dest_direction.

В игре эта точка (как объект) отсутствует и для спавна через скрипт и/или all.spawn не задействуется.

Изменено 5 Октября 2012 пользователем Artos

[Artos 99]

Callisto, можно предположить, что ты просто путаешься в значениях для параметров, отвечающих за координаты спавна.

Или же у тебя где-то срабатывает сторонний скрипт, изменяющий место спавна для актора заданного тобою в all.spawn, т.е. типа:

 db.actor:set_actor_position(vector():set(258.18,29.34,-460.75)) --/ меняем место спавна (телепортируем)

Изменено 5 Октября 2012 пользователем Artos

[Artos 99]

Clayman, не стОит тут затевать дискуссию "SDK vs sripts", выдавая за аксиому свои предпочтения.

Я так не считаю, а в этом уверен и уверен на практическом опыте своем и других. Кстати, наличие многочисленных отключалок в скриптах игры типа if editor() then - уже подтверждает мною сказанное.

Не буду спорить, что основную черновую работу по картам, их населению и т.п. гораздо производительнее делать именно в SDK, но ...

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

Во-вторых, чтобы внести мелкую или даже крупную правку в игру в большинстве случаев более чем достаточно это делать напрямую в скриптах/конфигах или том же all.spawn'е.

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

Хороший мод может быть создан только теми, кто и использует SDK на полную катушку и владеет навыками работы со скриптами/конфигами уже непосредственно созданной заготовки.

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

Отдельные элементы (как поминавшийся тут ранее dest_graph_point) присутствуют порою чисто рудиментарно и нередко только именами...

Да и помимо "всех", которые даны в all.spawn'е - в игре спавнится и можно спавнить еще много чего (в том числе и вей-поинты), о чем уже SDK и не догадывается... ;-)

Изменено 5 Октября 2012 пользователем Artos

[Artos 99]

Callisto, чудес не бывает (как правило). ;-)

Я не пользуюь различными повелителями зон, но их принцип тривиален - или для телепортации задается "ручками" нужная точка (что редко) или используются как раз готовые точки для переходов, совпадающие с сюжетными. Однако все это как правило вызывается "руками", т.е. самим игроком.

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

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

[Artos 99]

Callisto, твое предположение о "накрывающем рестрикторе" скорее всего верно.

Однозначно: актор переходит на Припять по указанным тобою координатам, но ... срабатывает рестриктор 'pri_a15_sr_cutscene' (пока не разобрал деталей, а радиус у него менее 8 метров. Логика этого рестриктора запускает в конечном итоге телепорт актора по указанным этим рестрикторам путям:

%=teleport_actor(pri_a15_actor_walk:pri_a15_actor_look)%

Т.о. выдерживается именно заданный изначальный сюжет... и актор оказывается "в бане".

 

Clayman, повторю, что dest_graph_point имеет значение только для SDK, в котором является по сути организационной единицей. Исходные для него и основные для игры параметры именно dest_game_vertex_id, dest_game_vertex_id, dest_position, dest_direction - и именно они (и только они) определяют в игре место спавна и направление взгляда актора после перехода по левел-ченджеру.

Модмейкерам, которые не предполагают работать с добавленными переходами в SDK можно в распаковке алл.спавна иль при скриптовом спавне переходов просто не указывать этот параметр или оставлять/задавать его с пустой строкою.

Изменено 6 Октября 2012 пользователем Artos

[Artos 99]

Batment, нет никакой ругани в твоем логе. is_unregistered - "отрегистрирован", т.е. объект уходит в оффлайн (net_destroy) и движек его отрегистрирует из онлайновой базы объектов.

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

 

KD87, с "рудиментарностью" уже разобрались, Для игры и моддинга "без SDK" - не задействовано - значит "рудимент", тем более левел-ченджеры (в исходном вопросе о них была речь) никак не связывают сетки локаций, по ним только актор ходит. ;-)

Ну а для SDK'шников - важный и необходимый параметр.

Изменено 6 Октября 2012 пользователем Artos

[Artos 99]

Callisto, присутствие в логике - еще не означает что 'это' будет выполнено... В логике pri_a15_sr_exit для телепортации стоИт кучка условий и до телепотрации еще "далеко", т.е. это все же "вторичный" сюжетный рестриктор, зависимый от ситуации.

А вот pri_a15_sr_cutscene - это как раз жесткий менеджер, управляющий сюжетом на локации Припять.

Как только актор оказывается в Припяти, этот рестриктор активизируется и безусловно(!) начинает командовать.

1. По первой же активной секции (run_black) запускает "черный экран" и выполняет еще кучку всячинки...

2. Через 5 секунд телепортирует актора (pri_a15_actor_walk)

3. При наличии инфопоршня pas_b400_done - начинает рулить различным спавном сюжетных персов и групп...

При отсутствии инфопоршня - вновь телепортитует актора (pri_a15_actor_start_walk)

4. В конце концов снимает "черный экран" и игра продолжается по сюжету.

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

 

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

Можно и вариантом с инфопоршнем, но чтобы именно самая первая активная секция pri_a15_sr_cutscene, не успев закрыть все черным экраном и не телепортнув куда ей прописано актора, узнала бы про твой инфопоршень и перешла на sr_idle@nil ... иль как-то иначе... тогда актор останется по координатам, которые заданы для левел-ченджера. Однако, сюжет на Припяти будет поломан.

Изменено 7 Октября 2012 пользователем Artos

[Artos 99]

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

Вероятно ты имеешь ввиду телепорт (секция zone_teleport) у которого форма (визуал) определяется не моделью, а партиклами.

В игре есть, например, name = zat_b20_teleport_horiz

Изменено 7 Октября 2012 пользователем Artos

[Artos 99]

KD87, это явно не тот случай...

И версия игры CoP, а не SHoC, на который расчинан зоне-едитор (ZE), и для временного тестирования устанавливать ZE - больно хлопотно... Пилить DLL-ку, компилировать партиклы, добавлять и адаптировать скрипты - ради одного "увидеть" один переход...

Изменено 8 Октября 2012 пользователем Artos

[Artos 99]

Callisto, для того, чтобы актор после перехода на др.локацию смотрел куда задано требуется для level_changer'а задать параметр 'dest_direction' (см. пример в "labx8_level_changer").

Этот параметр, как и 'direction' задается как 'f32v3' - т.е. как вектор с тремя значениями (x,y,x) каждое из которых задано в радианах(!)

 

С параметром [pt_move_if_reject] , как и с silent_mode = 0 в ЗП похоже придется распрощаться, т.к. из движка это вырезали.

Все переходы в ЗП имеют silent_mode = 1, и попытки сделать их "с запросом" (=0) заканчиваются неудачей, т.е. игра просто при входе в зону перехода не выдает никакого окна-запроса...

Изменено 10 Октября 2012 пользователем Artos

[Artos 99]

Информация для тех, кто задавался вопросом: "Как определить какой прицел надет на оружие?"

 

Удалось определить место прописки метки, которая отвечает за информацию о секции прицела (из списка scopes_sect). Эта метка (флаг) пишется аналогично типу патронов (ammo_type), но не в 'state'-часть нет-пакета и не в 'update', а в 'abstract', т.е. в ту часть которая недоступна обычными способами чтения/записи для нет пакетов.

Если посмотреть структуру 'abstract'-части пакета, то, напомню, что помимо всем известных параметров 'section_name', 'name', ..., 'script_version' в конце имеются еще некие параметры. В модуле m_netpk.script (далее буду писать применительно именно к этому модулю), между 'script_version' и 'spawn_id' имеется параметр переменной длины 'unused_pad', который пока никто вроде бы нигде не использовал...

Так вот, именно в этом параметре записываются различные метки/флаги и вероятно еще что-то, что характеризует онлайновое состояние объекта записанное в нет-пакет серверного объекта.

Пояснение по флагу прицела, надетого на оружие (только для ЗП!):

1. Флаг "прицел одет-снят" пишется в 14-й байт параметра 'unused_pad', т.е. 0-снят, 1-одет (это помимо штатного флага 'addon_flags');

2. Тип прицела, точнее численный индекс соответствующий порядковому номеру в строке из конфига оружия scopes_sect - пишется в 13-ый байт.

Например для оружия wpn_ak74 это будет так: 0 - ПСО-1, 1 - ПСУ-1, 2 - ПСС-2, 3 - НСПУ-3

 

Т.о. прочитав 'abstract'-часть нет-пакета и получив табличку байт для 'unused_pad' можно определить индекс прицела и по строке из конфига соответствующего оружию определить какой же прицел установлен на оружии, если конечно установлен.

Остается дело за малым - научиться читать 'abstract'-часть нет-пакета и писать в нее.

[Artos 99]

KD87,

'Зря' - тут некорректно, т.к. когда неизвестно что за байты , но назвать их как-то было нужно -> любое понятное название подойдет. В тот момент "неиспользованное" - было по сути верным, ну а теперь вероятно настало время и дать более подходящее название и вероятно расписать на более удобные и используемые блоки... :-) О том как считать этот кусок - все давно ясно, интересует наполнение, т.е. значения каждого байта/бита и группировка байтов в этой 'unused_pad'.

А откуда информация про "Это клиентские данные объекта.объекта. ... и состоит из двух частей - движковый кусок (как правило, небольшой) и то, что сохраняется в биндерах." ?

Собственно я уже помянул вскользь про это, но пока исследую... Есть ли какие наработки по этой части?

 

 

Shredder,

1. Для того чтобы прочитать 'abstract'-часть нет-пакета требуется чтобы движек(!) вызвал метод STATE_Write для серверного объекта. И вызывать должен именно сам движек, а не читалка/писалка нет-пакетов, только тогда можно прочитать 'abstract'-часть.

Подобный вызов происходит либо в самом начале игры, при появлении в игре серверных объектов (еще до спавна актора) и при выходах объектов в онлайн.

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

Как уже сказал KD87, далеко не всегда можно прочитать 'abstract'-часть у нужного объекта. Например если объект у актора, то когда актор вышел в онлайн - уже прочитать невозможно, т.к. для этого требуется чтобы и предмет и сам его владелец ушли в оффлайн - только тогда возможен их выход в онлайн и перечтение данных, но актора отправить в оффлайн не удастся... К сожалению в ЗП, в отличии от ТЧ, даже активный предмет в руках не обновляет своего нет-пакета... Так что в ЗП придется мудрить, типа трансферить предмет куда-то и тогда оффлайн-онлайнить или иное придумывать.

2. Учитывая, что невозможно одиномоментно менять сразу и 'abstract'-часть и 'state'/'update' - то все зависит от последовательности. Пока могу сказать, что если ствол валяется на земле - то установка 'addon_flags' сбивает значения для 'unused_pad', т.е. аддон будет снят (0) или одет (1). Учитывая, что индексты для аддонов идут с 0 (нуля), то этому индексу соответствует первый аддон (прицел) из строки конфига - вот он и будет "надет".

 

Внимание: Менять 'abstract'-часть следует очень аккуратно и максимально корректно, в противном случае могут быть самые разные баги. Данная информация появилась именно в следствии некорректностей в 'unused_pad', когда в ТЧ обычное взятие обычного ствола приводило к исчезновениям из рюкзака только что "взятого" и вылетам...

 

Примечание: Для тех кто использует m_netpk для чтения 'abstract'-части следует пользоваться последней версией, в которой подправлен алгоритм (доступен пока в минификсе 121012 от Симбиона). По мере появления новой информации вероятно формат чтения различных байтов 'abstract'-части может быть изменен...

Изменено 12 Октября 2012 пользователем Artos

[Artos 99]

KD87, большое спасибо за ответ.

Невостребованность save_unpacker'а скорее обусловлена тем, что и мало кто играет в чистую игру, и самим моддмейкерам, отошедшим от "штатного" формата сэйвов уже оказалась мало пригодной для использования.

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

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

Наверное нет особенного смысла в топике обсуждать и выкладывать "сырые" данные и предлагаю пока перенести это в оффлайн (ЛС, аська, скайп...). Ну а если будет интересно не одиночкам, то возможно стОит в "Модификации в разработке" открыть соответствующий топик по "Ковыряем нет-пакеты" ;-)

Изменено 12 Октября 2012 пользователем Artos

[Artos 99]

Не согласен что 'проще', если конечно кто-то не даст готовые варианты под все патчи ТЧ и ЧН/ЗП, чего нет на 'сейчас' (или я ошибаюсь?) и... неизвестно будет ли когда-то.

Да и не только вышеуказанными данными ограничены аппетиты моддейкеров... ;-)

Изменено 13 Октября 2012 пользователем Artos

[Artos 99]

Все же выскажусь в "оправдание" программистов GSC:

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

А что происходит когда отработавшее свое логика (за'нил'енная) пишется в сэйв и с этого сэйва игра и объект вновь стартует?

А все тоже просто: в сэйв пишется параметр 'active_section' и в случае, если этот параметр отсутствует - пишется пустая строка.

Т.о. если объект имеет логику, которая отработала и встала на 'nil' - то в сэйв будет прописана пустая строка для активной секции... что при загрузке сэйва приведет к тому, что вновь(!!!) будет активизирована дефолтная [logic] active = ... и вновь начнется цикл действий/проверок/... При чем, все это на старте игры при выходе "кучки" различных объектов в онлайн, что уже создает лаги.

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

Способ, который избрали программисты GSC, хотя и несколько ресурсо-затратен, т.к. постоянно выполняется холостой апдейт пустой секции схемы (никаких проверок условий или действий!), но именно это и снижает "стартовое" взбрыкивание, когда ресурсов съедается гораздо больше на уже ненужные проверки и действия.

ИМХО, более правильно, писать логику таким образом, чтобы стартовала некая простенькая секция, которая минимальными проверками определяла бы необходимость запуска полного цикла логики или же вставать на "nil". Предполагаю, что 'пустая' секция от SGC - просто недоделка этой идеи.

А еще лучше - если объект отработал свою логику, то в более 90% случаев его (рестрикторы и т.п.) можно просто удалять из игры за ненадобностью. Так и ресурсы сохранятся и никакого гимора с отработанной логикой... ;-)

 

Nostrik, а по 1-му вопросу, почитай шапки тем топиков "Ковырялок", почитай факи и пр., где уже немало раз писАлось на тему "усилений" неписей. Обрати внимание на правки визуалов и файлов damages.ltx и immunities.ltx в папке \gamedata\configs\creatures\.

[Artos 99]

Nostrik, неужели из моего ответа и твоих собственных размышлений на тему "не глупее нас" невозможно сделать простой вывод:

Нет и не может быть на подобный вопрос однозначного ответа.

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

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

- да/нет, или жертвуем расходами на холостые апдейты, или получаем лаги на старте игры и в игре точках вброса в онлайн объектов.

- вообще ни так ни так, а переписать и логику и схемы, чтобы ни лагов не было и ресурсы экономились!

- ...

Выбирай по-вкусу...

 

Удалить же скриптом (из игры) из all.spawn'а ничего нельзя! А вот на старте игры (или в процессе) ничего не мешает это делать. Способов привеликое множество и даже в имеющихся модах, да и в соседнем топике по ТЧ не так уж давно был разговор.

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

И не путай конфиг логики или объект сам ничего не делает, а в любом случае делают что-то сторонние функции (хоть и из диалогов, хотя почему такая тяга к диалогам? Да еще и ... "диалог с рестриктором" - абсурд!)

Изменено 13 Октября 2012 пользователем ColR_iT

[Artos 99]

TORR, в ЗП, как и в ТЧ, за сидение на корточках и травлю анекдотов отвечает схема 'kamp'. Если у тебя не получается - разбирайся что не так делаешь.

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

[Artos 99]

Clayman, схема 'kamp' в ЗП активна (см. в modules.script), вся система обвязки этой схемы сохранена и даже привязана к кострам (campfire), а не только к гулагам. Так что задействовать не сложно. Не могу сказать точно, требуют ли правок исходные коды (врядли), т.к. модифицировав в ТЧ - портировал и пробовал готовое.

Ты говоришь уже про третий вариант, который тоже вполне может быть задействован. Есть правда нюанс, т.к. в вопросе говориться о "сидеть и травить анекдоты", и если для kamp'а уже есть из ТЧ готовые рабочие наработки, то для camp'а еще придется поискать и/или покумекать как прикрутить анекдоты (jokes) и реакции на них...

Так что все зависит от того, что же захотелось сделать.

- для одиночки - и вполне remark'ом можно обойтись,

- если отдельные посиделки понадобились - то можно и kamp задействовать,

- ну а если всюду в игре - то предпочтительнее доработать camp, хотя что-то не встречал, чтобы кто-то sr_camp.script ковырял...