*Shoker*

Копался с кодом баллистики и нашёл пару интересных моментов. ЗП. 1) Касательно того почему k_ap ограничивали до 0.75. В СДК у всех моделей сталкеров и монстров прописан материал dead_body. Его "бронебойность" как раз таки равна 0.75. Если патронам прописывали значения больше чем эти - они "пробивали тело" и наносили двойной урон (но второй урон был слабее, т.к. после первого пуля теряла скорость). В СДК вроде максимальное значение бронебойности для материалов 1.0. 2) У материала dead_body в СДК включён рикошет пуль. Из за этого если пуля попадает в живое существо под удачным углом (+ рандом) - она "рикошетит" и наносит урон повторно (также пониженный). Этакий "критический урон" получается. Исправить обе проблемы, без правки материала и конфигов, можно через движок если закомментировать этот код: xrGame\Level_bullet_manager_firetrace.cpp -> DynamicObjectHit()

Привет. Правки движка сделаны через изменения значений в памяти процесса xrEngine.exe прямо во время игры, аналогично тому как делают правки через Cheat Engine / ArtMoney. У каждой правки в скриптах указан "адрес" в памяти процесса, а они после любой пересборки движка меняются. Так что если у тебя именно из исходников пересобранный движок (.exe/dll-ки), то там ничего легко адаптировать нельзя, только заново всё делать уже используя средства движка. Если-же ты используешь X-Ray Extension или ещё любое подобное, что модифицирует оригинальные .exe/dll-ки игры то мод должен в теории быть с ними совместим. Исходников у 2.1 как таковых нет. Все правки движка сделаны в обычных lua-скриптах, а чтобы из скриптов можно было править память я использовать Lua-перехватчик от alpet-а (одного из авторов NLC на ТЧ). Если интересно то вот его исходники (но я не проверял их актуальность, в моде используется заметно старая версия) - https://github.com/alpet83/Lua-Interceptor. А сам автор оригинальную тему на своём форуме то-ли удалил, то-ли сам сайт у него уже отключён. Но в любом случае для твоих целей он вряд-ли понадобится.

Порция новых видео

АК-12 вроде бы никогда не было в этом моде, ты наверно перепутал его с оружейным Shoker Weapon Mod для ЗП. (Первые видео были сняты на ЧН, но сам мод вышел для ЗП) Качай версию Shoker Weapon Mod 2.1 для ЗП и можешь из неё выдернуть, с ЧН совместимо. (конфиги сам адаптируешь, а все анимации рук находятся в файле wpn_hpsa\wpn_hand_hpsa_hud_animation.omf, он пойдёт для ЧН)

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

В любом случае в иконку 1х2 калибр не влезает, так что придётся прочитать название и запомнить как выглядит. Да и зачем оно нужно, всё равно при наведении на оружие\магазин всё подсвечивается. Цифры отображают реальное число патронов в магазине, правда сейчас ломаем голову - полные магазины в инвентаре хочется складывать в кучи, но тогда число патронов нужно будет убирать, т.к оно банально не умещается вместе с числом магазинов в куче. (аля [100]x2) Технически реализуется легко через конфиг (все аддоны идут отдельными моделями, как руки), но конкретно в нашей версии решили так не делать. (за исключением стволов, на которые одеваются все прицелы) Снять нельзя, заменить на другой\глушитель можно. По насадкам - хочется наствольные гранаты сделать. (но если да, то без анимаций и "спец патронов")

@k01jan, По поводу ТБ к сведению приняли, но аниматор на неё клал болт, поэтому видимо останется так. М.б учтёт при анимировании других магазинов. В качестве бонуса - при заходе в электру, во время зарядки магазина, у герой перед лицом будет кровавое светошоу. %) @Mari, м.б сделаем опциональными, правда тогда другие типы магазинов на оружие установить будет нельзя, либо придумаем какое-то ограничение для этого. Что касается их зарядки - в поле заряжать только вручную, а вот рядом с торговцем - будет возможность мгновенной зарядки через инвентарь, Так что зарание перед ходкой запасись ими и проблем не возникнет. Ну и не только ради красоты, например ради всяких барабанных магазинов на 60\100 пуль. Если не использовать магазинное питание, то игрок просто поставит один такой магазин на свой калаш, и у него уже будет вечный пулемёт на 100 патронов, который перезаряжается за 3-4 секунды. А с магазинной системой ему придётся закупить несколько барабанов и зарание снарядить их. И когда они кончатся посреди боя, придётся вместо них ставить обычный рожок на 30.

Значит ровно то, что написано. У модели нету своих вшитых анимаций, анимации из omf не учитываются. Это не ошибка и не критично, просто предупреждение. Далее как можно из мировой модели сделать худовую, если у них даже скелеты могут отличаться? %) Да и скелет рук в ТЧ другой вроде как, вообщем без переделки анимации и модели нормально не перенесёшь. Знакомый посоветовал один приём - ЗП-шные руки прятать за экраном, прописав им везде анимацию idle. А худовую модель оружия из ТЧ вставить целиком как "оружие" (прикрепить к ЗП-рукам) Само собой о смене визуала рук с этим оружием можно забыть.

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

Нашёл небольшой баг (опечатку) в движке ЗП, скорее всего есть и в ТЧ\ЧН. В файле xrGame\Level_network.cpp в начале функции void CLevel::ClientSend() Перед проверкой GameID() == eGameIDSingle нужно поставить отрицание: if (!GameID() == eGameIDSingle || OnClient()) Тогда при сохранении игры для всех клиентских объектов будет вызываться net_Export (клиентские объекты будут синхронизироваться с серверным чётко при сохранении)

Прошлые видео, которых не было в этой теме:

Ну вот в ЗП я сохранял данные и столкнулся с похожей проблемой, keep_saved_data_anyway() мне помог, но как - уже не помню . В ЗП с этим есть очень неприятный баг к слову. На оружие можно установить разные типы прицелов (ночной, с увеличением и прочее) Так вот - тип прицела сохраняется ТОЛЬКО в клиентском объекте оружия (в save\load). Но в серверном объекте про это забыли. Поэтому пока оружие в инвентаре ГГ или рядом с ним - при сохранениях и переходе с локации на локацию всё хорошо. Но стоит бросить оружие, уйти далеко и вернуться - на оружии прицел сбросится на стандартный.

@Dennis_Chikin, Ну всё правильно. save\load сохраняет в сейв только данные клиентских объектов которые в онлайне. Соответственно если клиентский объект ушёл в оффлайн => он удалился (?), и сохранять у него нечего. Ему на замену приходит серверный объект у которого свой метод сохранения. Я не знаю что там насчёт ТЧ, но в ЗП в этих случаях (кажется) помогала функция серверного объекта keep_saved_data_anyway() - должна возвращать true (в ЗП есть примеры). Тогда там (по моему) данные даже при смене локации сохранялись, но опять же очень давно это всё проверял.

Вообще с пакетами там интересная ситуация в движке. Практически у всех игровых объектов есть две версии - клиентская и серверная (онлайн\оффлайн). Серверные это объекты, которые находятся на другом уровне, либо далеко от игрока (упрощённо), а клиентские это те, которые активны в данный момент. Серверный объект существует всегда, а клиентский лишь на уровне с игроком. Далее к делу: STATE_Write используются (если я ничего не путаю) лишь во время перехода объекта в оффлайн (тут правда на 100% не уверен) и в момент сохранения игры. + иногда при создании объекта. Его суть собственно - записать в сохранение те данные серверного объекта, которые точно нужно хранить. STATE_Read аналогично - при загрузке сохранения считывает данные из него в серверный объект. В остальных случаях они обычно не используются. UPDATE_-пакеты же обновляются (в зависимости от объекта) раз-два в секунду (+\-). Они служит для синхронизации (в реальном времени) некоторых данных клиентского объекта и серверного. (В том числе для мультиплеера, передавая данные между игроками) Например для физических объектов это их текущая линейная скорость, для оружия это текущее состояние, патроны и прочее. Эти данные не всегда сохраняются в сейве (для серверного объекта), но всегда передаются между игроками в мультиплеере. То-есть они обрабатывают те данные, которые нужно обновлять как можно чаще и передавать между игроками. Отсюда и название - update. Кстати по функциям net_Export\net_Import - это как раз те функции, которые собирают\считывают UPDATE_ - пакет. Они экспортированы в Lua и через них можно там в реальном времени этот UPDATE_- пакет править или считывать. Ещё стоит учесть что у клиентских объектов также есть своя функция save\load. При сохранении игры идёт запись данных всех серверных объектов, а потом запись данных всех клиентских (которые существовали на момент сохранения) Соответственно при загрузке игры этот клиентский объект сперва считывает данные из своего серверного объекта, а потом считывает\перезаписывает их сохранёнными данными клиентского объекта. (они имеют приоритет) ------------------------------------------------------- Собственно основная соль в том что в UPDATE-пакетах можно получить доступ к данным, которых нет в STATE-пакетах. Но нужно учитывать что эти данные обновляются с различной небольшой задержкой.

@Lagos, разрушается только как цельный объект? В идеале хорошо-бы подобно машинам - разрушать модель по джоинтам, чтобы от неё отваливались куски. По видео не совсем ясно.

Дамы и господа. Требуется ваше экспертное мнение по поводу визуальной целесообразности установки тактической рукоятки на FAMAS сим образом. Зарание спасибо. Проще говоря - насколько плохо\хорошо это выглядит с вашей точки зрения.

До АК-12 мы в ближайшее время вряд-ли дойдём. А к тому времени наверняка появятся ещё модели. Возмём самую хорошую, что найдём. И не обязательно релизный вариант. Кто увидит ещё хорошие модели - кидайте сюда ссылку.

@Free_man1994, здесь вопрос баланса. Прицел, который сочетает в себе и ближний и средний бой автоматически делает остальные прицелы данного класса довольно бесполезными. Мало кто будет ставить другие прицелы, когда можно поставить один универсальный.

Даже при использовании fastcall-а "пролетало"? %) ****************** Вообще по сну просто интересная заметка, по крайнем мере работающая в ЗП - для перемотки времени можно использовать банальный "спидхак" из какого нибудь Cheat Engine например. (или реализовать движковый аналог) Он ускоряет все процессы игры в 2-100 раз, тем самым по сути несколько игровых часов пролетают за пару секунд как при перемотке, при этом происходят абсолютно все события как будто игрок эти часы просто стоял на месте и ждал. При этом те же апдейты продолжают вызываться аналогично с ускорением. Это самая что ни на есть "настоящая" реализация сна. То-есть решается проблема когда игрок "засыпает" рядом с бежащим на него монстром и просыпается через 10 игровых часов рядом со всё тем же всё ещё бежащим на него монстром. Правда можно столкнутся с проблемой что после долгого сна в игре может что то слететь. По типу того как слетал game_time() после, кажется, игрового месяца. (Это как если бы стоять на одной локации несколько реальных часов без перезагрузок)

С учётом наличия исходников какими способами можно тестировать сталкерские шейдера на скорость выполнения \ оптимизацию? А точнее конкретно нужный шейдер протестировать.

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

Полезная штукенция. Когда только начинал крутить сталкер приходилось такие файлы по одному за загрузку смотреть. Кстати поиск .anm\.ppe и прочих файлов, как вариант, можно сделать автоматическим через такую шнягу:

Как уже ответил @Viнt@rь, шейдер соберётся но код внутри него нужно вызвать вручную, посмотри на dof.h

@tatarinrafa, ну для начала как твоя игра должна догадаться что ей нужно запустить moy_shader.ps и при этом применить его ко всему экрану. Вызов новых шейдеров прописывается либо в движке, либо, для моделей, в СДК. (ну грубо говоря) Конкретно если ты хочешь окрасить весь экран в красный, то тебе нужно открыть шейдер постпроцесса экрана (combine_2_ххх,ps, их там два больших, не помню какой точно нужен, по моему combine_2_naa.ps), который движком вызывается, и там уже модифицировать код по своему желанию. Только учти что, по крайнем мере в ЗП, в этом файле много закоментированного (отключённого) кода ( /* ... */ ) Туда писать ничего не надо.

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