X-Ray extensions

[Malandrinus 624]

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

 

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

[Malandrinus 624]

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

PS: мне кажется, ты просто не видел наш телепорт.

PPS: Вообще же, вопрос, что должно быть в движке, а что в скриптах (или точнее что в части движка написанной на C++, а что - в части движка на Lua) - это вопрос отдельный и заслуживает отдельного разговора. Правда не здесь.

[Malandrinus 624]

Зашибись! Гугл прикрывает лавочку с гуглкодом. До лета надо будет перегнать проект на другую платформу. Впрочем, у меня есть сильное желание не делать ничего просто потому, что проект себя изжил.

 

Что думаете?

[Malandrinus 624]

Можете такую же в будущем и для r1 запилить?

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

[Malandrinus 624]

 

 

А про jump_speed забудь. Не меняется он с помощью x-ray extensions. Точнее, поменять не сложно, но это изменение никакого эффекта не оказывает.

Не совсем так. Если поставить jump_speed в 0, то прыгать всё-таки не будет, т.е. позволяет решить проблему обездвиживания. С другой стороны действительно факт, что любое значение, отличное от нуля, в итоге приводит к тому, что скорость прыжка просто остаётся постоянной из конфига. Если глянуть исходники, то там скорость прыжка при загрузке копируется куда-то в менеджер физики актора и видимо там уже используется. Поэтому и эффекта от перезаписи нет. При этом и то первое поле в самом объекте актора тоже в одном месте читается и используется, видимо поэтому нулевое значение всё-таки влияет. Короче, разработчики пыс тут в своём репертуаре, запутали и накосячили.

 

 

камера все-равно будет дрыгаться при ходьбе, как при обычном движении

Не будет, я проверил. Эффект покачиваения (боббинг) походу начинается с какого-то порога скорости.

[Malandrinus 624]

Прошу обратить внимание!

 

Я добавил в проект xrGame для ТЧ (это который в папке master/3312_shoc_10006) систему конфигурирования патча. В двух словах:

• В папке tools добавлен инструмент GPP.exe и описание к нему. Это текстовых препроцессор общего назначения, в целом напоминающий препроцессор от С/С++. Ежели кому интересно, подробнее здесь.
• Созданы две конфигурации: general и OGSE. Батник патчера patch.cmd соответственно изменён и добавлен второй patch_ogse.cmd. Также добавлены два файла с опциями каждой из конфигураций: config_general.txt и config_ogse.txt.
• Файл corrections_list.txt тоже изменён. Ряд патчей в нём обнесены условной конструкцией #ifdef <СИМВОЛ> ... #endif. Соответственно, <СИМВОЛ> должен быть определён как #define <СИМВОЛ> в соответствующем файле конфигурации (config_general.txt или config_ogse.txt).

 

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

 

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

 

PS: Надо было это сделать сто лет назад.

PS2: git - отстой,  сильно переусложнён и избыточен для целей этого проекта.

Ещё хочу уточнить несколько моментов по процессу сборки и заодно напомнить тем, кому интересно, как это всё работает:

Для сборки я в своей практике использую файлы make_src_dll.cmd, patch*.cmd, clean.cmd которые находятся в папке проекта. clean.cmd - это необязательный файл, который просто чистит временные файлы. Можете его игнорировать.

 

Процесс сборки я обычно делаю в два этапа: сперва make_src_dll.cmd, затем patch*.cmd.

 

make_src_dll.cmd - выполняет сборку dll-заготовки с патчами и секцией нашего кода. Он сперва вызывает ml.exe и компилирует файл mydll.asm, который на самом деле включает в себя инклюдами все остальные файлы. Затем собирает dll линковшиком link.exe. Поскольку все ошибки обычно возникают на этом этапе, то я специально поставил в конце этого батника pause, чтобы видеть ошибки компиляции, если таковые случаются.

 

patch*.cmd выполняет несколько действий:

• В версии с конфигурацией (на данный момент только xrGame для ТЧ) первым действием является вызов tools\gpp.exe, который на основе нужной конфигурации сгенерирует из corrections_list.txt временный файл corrections_list_tmp.txt, т.е. урезанный список патчей. В остальных проектах файл corrections_list.txt используется без изменений
• Далее вызывается tools\bspatch.exe, который из файла xrGame_orig.dll и xrGame.diff, собирает файл xrGame.dll, который представляет собой чистую dll из игры с добавленной секцией для нашего кода. Вообще говоря, с технической точки зрения этот шаг не является обязательным. Вы у себя можете собрать эту dll раз и навсегда и вырезать этот фрагмент из батников. Сделано это было для того, чтобы не включать в проект проприетарные файлы (по этой же причине не включены ассемблер и линковщик).
• Наконец, собственно вызывается патчер tools\patcher.exe, который переносит патчи из dll с патчами в целевую с добавленной секцией в соответствии со списком патчей из файла corrections_list.txt (или временного corrections_list_tmp.txt)

 

Ряд замечаний:

1. Если вы понимаете происходящее, то ничто не мешает настроить процесс сборки по-своему, например за один клик без пауз, пересоздания чистой dll и т.д.

2. Касательно версий исполняемых файлов, не включённых в проект.

• Чистая DLL, которая должна лежать в проекте xrgame ТЧ под именем xrGame_orig.dll - это файл от американской версии игры. Имеет размер 6246400 байт.
• Ассемблер (ml.exe) нужен версии не ниже 10-й. Берём его из Visual Studio.
• Линкер (link.exe), к моему удивлению, оказался нужен именно старый от MASM32 (версия 5). Я как-то не заморачивался на его замену, но недавно поэкспериментировал и с удивлением выяснил, что более новые версии вызывают смещение секций, которые не учитывает наш патчер. В итоге ничего не работает.

[Malandrinus 624]

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

 

 

Можно ли использовать уже существующие дефайны, которые лежат в defines.asm (например OGSE_BUILD), для corrections_list?

 

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

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

 

Вот ещё к этому вопросу. В ассемблере ml.exe, как и в препроцессоре gpp, можно в аргументах командной строки определять символы препроцессора. Как-то так /DOGSE_BUILD. Так что выбор конфигурации тоже можно делать, не меняя код.

 

имена дефайнов должны быть написаны, хотя бы с разделением на слова:

 

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

 

 

стоит убрать файлы конфигов в подпапку configs (3312_shoc_10006\configs\), дабы не искать постоянно их в списке всех файлов.

 

Ну, тогда уж надо выносить в отдельную папку все файлы, связанные с билдом: список патчей, заготовку под dll и diff-файл, все батники и прочее. Лично у меня уже батник для сборки не найти, поскольку список исходников сильно длиннее окна TC.

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

Так а что мешает подключить и посмотреть на эффект?

Изменено 19 Ноября 2015 пользователем Malandrinus

[Malandrinus 624]

 

 

Все выполняется, но в окне торговли и обыска никакой раскраски я не увидел.

Да, это кто-то закомментил правки на этот счёт, поэтому скриптовые действия, которые только ставят флажки с помощью хаков общего назначения, не работали. Я правки раскомментил, внёс в конфигурацию OGSE. Сейчас должно работать. У меня по крайней мере работает.

 

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

 

Ещё, создал там же батник для ассемблирования под конфигурацию ogse. Компилировать надо именно им, иначе немало всякого не попадёт в сборку.

 

 

ничего там не изменилось с правовым статусом link.exe и ml.exe?

 

Я этого не знаю. Сомневаюсь, что что-то изменилось.

[Malandrinus 624]

 

 

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

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

 

 

И кстати.

 

 

Не самая идеальная реализация

А как бы сделал ты?

 

 

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

Хм. Да там половину незакомменченных правок можно отнести ко второй категории, да и по части "нужности" - это дело индивидуальное. Мне однако вообще непонятно ранжирование правок. Проект для всего. Что хотим, то и добавляем. Главное - друг другу не мешать.

[Malandrinus 624]

@RayTwitty,

ага, нашёл косяк. Спасибо за наводку. Хоть логика фильтрации и раскраски и отключена, но цвет подсветки по умолчанию всё равно берётся из первого элемента пользовательского массива цветов, а массив инитился из скрипта, т.е. там были нули (и соответственно полностью прозрачный цвет). Поэтому "покрасневшие" предметы были невидимы. Сейчас я там заполнил первый элемент, так что покрасневшие предметы не пропадают.

 

 

 

Я про скрипт говорил

Так и я про скрипт. Заметны какие-то косяки?

[Malandrinus 624]

обновление флагов для предметов достаточно делать в трех случаях - на событиях take\drop (при открытом окне обыска\торговли) и при открытии окна инвентаря\обыска\торговли для всех предметов сразу

 

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

 

 

остался нерешенным вопрос с правкой

 

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

 

Короче, эту правку как раз надо убирать из "не ОГСЕ" конфигураций.

 

 

Возможно, как-то связано с функцией set_ignore_game_state_update() которая вызывается в OGSE, но непонятно для чего

 

Эта функция идёт как затычка к механизму прокрутки времени, который в ОГСЕ используется для сна. Я обнаружил, что после прокрутки времени происходят косяки с пересчётом состояний актора. Подробностей уже не помню, но лечилось это разовым игнорированием соответствующего обновления сразу после приращения времени. Для установки этого разового игнора и предназначена эта функция. Вполне допускаю, хотя уже и не помню точно, что вместе с актором пропускается обновление чего-то ещё. В любом случае, это не используется нигде больше, кроме как в реализации сна.

[Malandrinus 624]

Значит придумать, как исправить баг, а эту правку в топку

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

 

как ты относишься к Mercurial репозиториям?

Я мало про них знаю. Ну вот открываю вики, читаю слова:

"разработанная для эффективной работы с очень большими репозиториями кода"

"является распределённой (децентрализованной) системой контроля версий"

"поддерживает полностью децентрализованную работу, ветвление"

 

Это всё замечательно, но конкретно этот проект - полная противоположность этих требований. XE - проект на самом деле очень маленький (особенно если рассматривать каждый подпроект по отдельности). Количество разработчиков - также очень небольшое. Ветвление - может где-то и полезно, но конкретно в этом проекте, IMHO, фича вредная. Сам проект XE вертится вокруг предельно конкретных DLL, правки обычно сугубо локальные и никак не могут, точнее не должны, вести к созданию изолированных сборок. Более того, форки в контексте нашего проекта вообще противоречат его изначальной задумке аккумулировать все правки. Вот конфигурирование проекта - дело полезное, но ветки для этого не нужны.

 

Поэтому нам больше подходит система контроля версий централизованная и желательно как можно более простая, типа SVN.

 

ЗЫ: Я всё же хочу уточнить на всякий случай, что "git - отстой" я имел в виду только в том смысле, что "для этого проекта - отстой". Так-то наверное замечательная система.

Изменено 21 Ноября 2015 пользователем Malandrinus

[Malandrinus 624]

 

 

не которые классы оружия можно спокойно вырезать

В целом не могу не согласиться. Не знаю насчёт полусотни багов, упомянутых RayTwitty (звучит как некоторое преувеличение), но ОО архитектура оружия в движке действительно корявая. Согласно канонам ООП, новый класс вводится тогда, когда необходимо создать новое поведение, а большинство стволов никаким принципиально отличным от других стволов поведением не отличаются. В принципе, ничто не мешает создать один универсальный класс оружия, который всецело бы настраивался конфигами: сколько стволов, чем они стреляют, в каком режиме, есть ли на каждый ствол режим отсечки, затворная задержка и т.п. Это всё спокойно можно настроить конфигами. И аддоны можно было бы сделать динамические, а не зафиксировать только три. Вот только это вряд ли можно сделать в рамках ассемблерных правок.

[Malandrinus 624]

Тебе все 50 назвать?

Ну-у, назвался груздем... =)

 

Один из моих знакомых, насколько я знаю уже реализовал это на ЗП.

 

А кто и в каком проекте?

Изменено 28 Декабря 2015 пользователем Malandrinus

[Malandrinus 624]

Что-то развели оффтопик.

[Malandrinus 624]

@НаноБот,

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

[Malandrinus 624]

@НаноБот,

ты обозначил проблему:

Компилить надо целиком, ... Иначе работоспособность совсем не гарантируется.

 

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

[Malandrinus 624]

Да, без правок работать не будет. Худ и сцена отрисовываются в двух разных очередях и при этом с разным FOV (из-за этого и смещение вперёд). Разрабы ТЧ сделали так, что шейдер самосвечения всегда срабатывает в очереди сцены, даже если принадлежит худовой модели. Свинтусы они, разрабы эти. Косяк в исходниках лечится парой строк, а так вышла одна из самых мерзких и нудных правок.

[Malandrinus 624]

@macron, а это разве не чисто шейдерная правка?

[Malandrinus 624]

@macron, по сути правки конечно надо у KD уточнять, но почему её для r1 нет вполне понятно. Правки делались в рамках OGSE, а первый рендер мы оттуда убрали.