Редактирование движка X-Ray

[Forser 47]

@Graff46,не понял ничего.

[Graff46 596]

Можно ли собрать репозиторий не со всеми правками которые он добавляет.

[Карлан 1 049]

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

 

@Forser, думаю не стоит удалять.

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

[Forser 47]

@Карлан,как по мне - дефайны самый красивый и оптимальный вариант. Это лучше, чем ковырять метры кода в поисках нужно правки.

[Graff46 596]

этот репозит возможно собрать без правок с шейдерами?

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

[Forser 47]

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

[Карлан 1 049]

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

 

@Graff46, какие именно правки шейдеров?

[Graff46 596]

 

 

какие именно правки шейдеров?

 Игра с репозитом отказывается запускаться без нескольких "своих" файлов в папке shaders, когда я добавил файлы все нормализовалось, но поставив шейдерный пак (без пересечения файлов) игра начала крашиться снова, явно с шейдерами что то "нахимичино".

Я вроде нашёл причину 

 

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

[RayTwitty 486]

Дефайны ещё можно использовать в разных опциональных вещах. Например, если предполагается, что возможны разные конфигурации\наборы фич на выходе.

 

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

 

Я вроде нашёл причину

Там насколько я помню, много ресурсов (в геймдате) требует параллакс, детальный бамп и некоторые замененные шейдеры. Логично это сделать опциональным. Изменено 3 Декабря 2015 пользователем RayTwitty

[Карлан 1 049]

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

[Forser 47]

Ребят, кто может помочь: нужна коротенькая(хотя сойдёт любая) инструкция, о том, как средствами MASM вставить кусок кода в exe. 

RayTwitty, в конец не подходит, к сожалению.

[Карлан 1 049]

На самом деле, чтобы убрать дин.зум в режиме подствольника, нужно кастовать в CWeapon дочерний класс и уже смотреть чему равен флаг активности, а это не совсем хорошо. Лучше, наверно перегрузить функции отвечающие за зум в WeaponGL и сделать пустышки.

У WeaponGL может быть и прицел (wpn_fn2000, wpn_ak74, wpn_groza), так что я думаю придется так или иначе проверять режим "в подствольнике". Я не кастовал дочерний, а просто ввел новую переменную, ее же из WeaponGL можно напрямую поднять.

 

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

 

 

 

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

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

[-StalkMen- 159]

в конец не подходит, к сожалению.

Почему нет?

Есть вариант inject dll

Но суть то всё равно одна. Там, где мы хотим перехватить управление ставим jmp/call на адрес нашего кода, а в нашем коде (в конце) jmp обратно/ret.

Изменено 5 Декабря 2015 пользователем -StalkMen-

[RayTwitty 486]

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

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

[Карлан 1 049]

@Forser, очевидно - в мессенджере, но мне он уже полгода не отвечает, зато сам учишься . Конкретно что интересует, может мы поможем?

 

Карлан, исходники host.exe из состава перехватчика.

Перехватчик переписан под исходники, и host.exe там нет вообще (там другой исполнительный файл), исходники перехватчика (и не только) до момента "полгода после релиза NLC" публиковаться не будут, так что запасись терпением, то что сейчас за ширмой - там пока и остается. Постепенно открыватся будут только файлы, и то если Сяк разрешит, альпет собирался это сделать еще год назад, но видимо все же не выходит.

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

[Forser 47]

@Карлан, исходники host.exe из состава перехватчика.

что запасись терпением, то что сейчас за ширмой - там пока и остается

Терпением придётся запостись тов.Sla-Sla и его проекту. Ладно, будем ждать.

Перехватчик переписан под исходники

Я пока не под 1.0007 RC1 работаю.

[RayTwitty 486]

У WeaponGL может быть и прицел (wpn_fn2000, wpn_ak74, wpn_groza), так что я думаю придется так или иначе проверять режим "в подствольнике". Я не кастовал дочерний, а просто ввел новую переменную, ее же из WeaponGL можно напрямую поднять.

Потестил, в случае фикса подствольника, лучше да, использовать переменные, нежели добавлять функции-пустышки в CWeaponGL, так будет корректнее (можно будет переключать активное оружие колесом мыши). Только вводить надо не новую переменную, а перенести m_bGrenadeMode в родительский класс CWeapon.

[Карлан 1 049]

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

---

Немного философии по поводу интерфейсов. Довольно долго я в них ковырялся, и скажу что верстать интерфейсы в движке куда удобнее, кроме того, у таких интерфейсов гораздо большая скорость по сравнению с теми окнами, которые Вы сверстаете на скриптах. Но! Почему я не буду адаптировать систему апгрейдов из ЗП в ТЧ? В ЗП хорошо сделан функционал для создания интерфейсов, на нем очень удобно создавать все что угодно. И почему же я не буду адаптировать систему апгрейдов из ЗП в ТЧ? Нет, к оформлению и коду оформления претензий нет (оно как-раз, возможно, и перекочует), есть претензии к самим внутренностям этой системы, по сути эти апгрейды ничем не отличаются от того, что мы можем видеть в некоторых модах с подменами самих объектов, здесь нет подмены объектов, зато есть та же куча секций, это категорически отталкивает от затеи делать апгрейды как в ЗП. У меня есть одна идея, если будет что продемонстрировать - я продемонстрирую.

 

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

 

 

 

 

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

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

[RayTwitty 486]

хм, как оказалось, эта правка не исцеляет весь баг, там есть еще косяк, который тоже нужно поправить

У себя поправил по озвученному способу - вроде все норм. Или там какой-то нюанс есть?

 

здесь нет подмены объектов, зато есть та же куча секций, это категорически отталкивает от затеи делать апгрейды как в ЗП

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

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

[Карлан 1 049]

Или там какой-то нюанс есть?

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

void  CWeaponMagazinedWGrenade::PerformSwitchGL()
{
m_bGrenadeMode = !m_bGrenadeMode;
m_fZoomFactor = g_fov; // Karlan: сбрасываем зум
...

 

@RayTwitty, по апгрейдам примерно подобная идея и у меня, но без подмены секций и переспавна -также две карты, доступная и текущая, все будет сохраняться в памяти (при таком подходе не нужно делать биндеры, и, возможно, для самих внутренностей обойдемся без ООП) и каждое улучшение будет высчитываться в процентном соотношении из базовых характеристик, и в таком случае, возможно, удастся избежать сохранения текущей карты потому что плясать так или иначе будем от констант.

---

Небольшая правка и разъяснения по классу документов. Не так давно некто тут спрашивал на каком классе корректнее всего делать документы, в оригинале сделано на II_ATTCH, что допустимо, но лучшим вариантом это назвать нельзя. Также можно увидеть класс II_DOC, что же это за класс? Этот класс по сути тот же II_ATTCH, только с дополнительным параметром - выдачей инфопоршня при обретении этого предмета, но в движке то ли забыли, то ли нарочно недоделали этот ключ, который придает уникальность и какую-то осмысленность данному классу. Конечно, в этом совершенно нет необходимости, но, поскольку я рассмотрел и разобрался, думаю этот рассказ кому-то будет интересен. Итак, как же исправить этот класс? Довольно тривиально, идем в xrServer_Objects_ALife_Items.cpp, затем находим следующий код:

CSE_ALifeItemDocument::CSE_ALifeItemDocument(LPCSTR caSection): CSE_ALifeItem(caSection)
{
m_wDoc = NULL;
}

И меняем на:

CSE_ALifeItemDocument::CSE_ALifeItemDocument(LPCSTR caSection): CSE_ALifeItem(caSection)
{
//m_wDoc = NULL;
m_wDoc = READ_IF_EXISTS(pSettings,r_string,caSection,"document_info",NULL); // fixed by Karlan
}

Готово, теперь в ключе document_info в предметах класса II_DOC можно прописывать идентификатор информации, и эта информация передастся игроку при обретении этого предмета.

 

upd:

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

Изменено 15 Декабря 2015 пользователем Black Hawk