Zagolski, а в движке от abramcumner можно .dll собирать по отдельности? там все .dll собраны и скрипты подправлены, а я бы хотел собрать только .dll в которые правки внесу например xrGAME.dll а остальные оставить родные.

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

Zagolski, я конечно в движке новичок, неотричаю. я пробывал собирать исходники engine.vc2008 на Visual Studio 2008, собрал сначала 3rd_party потом xrGAME.dll, кинул готовую .dll в оригинальную игру с заменой и игра норм запустилась. а вот с xrGAME.dll от abramcumner игра не запускаеться.

У него луабинд новый, да и под 2017 студию двиг. Конечно ничего со старым несовместимо. Собирай все вместе и не забудь правленые под новый луабинд скрипты заменить.
Если собрал под 2008 родные сорцы, так этот двиг и используй. Как-никак оригинал.

Спасибо за советы. Буду пробывать

По экспериментам c ai-транспортом двигающемся по вейпоинтам, заметил, что иногда застревает при ph_frequency 100. Выставил 133, и проблема ушла.

Оно не влияет совершенно, даже если поставить 10000 (по дефолту 100). Да и понятно, в исходниках достаточно прозрачно указано, что эта команда изменяет.

Зато если поставить единицу, то можно чотко занизить машину по всем правилам жанра)))

Приветствую всех, возник один вопрос касаемо анимаций в игре. Я использую исходники движка morrey с адаптацией рендеров ЗП под ТЧ, по немногу исправляю баги и дополняю его и вот у меня возникла проблема, подключил тени от ГГ и обнаружил что при взятии в руки болта анимация визуала ГГ проигрывается не корректно, точнее сказать совсем не та что прописана в ActorAnimation.cpp может кто нибудь подсказать где искать корень проблемы.

Вот скриншот.

Конкретно в ТЧ аналогичная проблема была вроде в анимациях (omf) модели.
https://www.gameru.net/forum/index.php?s=&a...t&p=1648038

Уже решил данную проблему, надо было просто в конфигах болта изменить параметр animation_slot но спасибо за помощь)

Забавная ситуация при использовании /permissive- или насколько сильно двиг привязан к компиляторам VS. Ни одна из библиотек не собралась без переписи кода.

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

Ошибки я исправил, а warning'и остались, особенно в луабинде, более 10000 штук. Я уж хотел луабинд на опенхреевский заменить, он без предупреждений собирается, и быстрее. Жалко только он напримую с оригинальным не совместим, а разбиратся мне было лень. Так и оставил.

Мои попытки порта закончились luabind'ом. Не люблю шаблоны. И луа. По xrEngine включительно, окси можно собрать любым нормальным компилятором.

А вообще, есть ощущение, что этот ключ через пару версий VS нельзя будет вырубить. С 2015 версии он ставится автоматически при создании проекта. До этого оно было вырублено.

Надо заменить луа на другой язык. Гиперион вроде пытался питон прикручивать, как там у него дела?

Молния в вакууме, у нас шарп прикручен. Только ко ещё не всё API вынесли

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

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

Я бы вообще API порезал, оставив лишь самое необходимое (ИМХО).

RayTwitty, не будет одинаково, питон медленне чем ЛУА.
Зато он объектно-ориентированный, в отличии от луа, в котором ооп добавляется луабиндом. На одну библиотеку меньше придётся использовать.
Кроме того стандартный интерпретатор питона написан на pure c, без всяких шаблонов, его проще переносить между компиляторами, можно например будет собрать СДК борландом полностью, без зависимости от других компиляторов.
Луа конечно тоже на pure c, но луабинд на c++, увы, и борландом не собирается.

Там для этого есть очень-очень гибкие таблицы.

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

RayTwitty, да это так, мысли в слух. До реализации вряд-ли доберусь.

RayTwitty, в окси нет особого рвения на поддержку сталка. Нам сам xray интересен. Как закончим со спектром, сделаем небольшую демку движка, мини игра на 15-20 минут.

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

NanoBot-AMK, лучше бы установку растяжек сделал с динамической веревкой.

RayTwitty, ну это не слишком сложно, вот только верёвку делать я не буду, т.к. не умею. А так, были мысли сделать растяжку по типу как автор "Боевой подготовки" советовал, проще конечно с партикловой верёвкой сделать. Ну и совсем просто сделать мину с сейсмическим взрывателем, НПС подходит к ней и она взрывается.

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


Эта хрень вообще не отличается от стандартной аномалии-мины и никому не нужна.

RayTwitty, всё это сложно, и не понятно как рисовать верёвку, так что делать пожалуй не буду.

Есть ли исходники чистой релизной версии движка v1.0006?

xrModder, нет

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

xrModder, отключи линковку и посмотри

Не могу собрать тч на vs2017 - куча предупреждении и ошибок

xrModder, способ для ленивых/непроггеров: ставим 2005-2010 студию, выставляем в 2017 тулсеты от 2005-2010 студии, радуемся.

Тут кое кто, ну не тут, а на АМК-форуме, писал о проблеме потери патронов в шотгане при загрузке.

Ещё надо в заголовках не забыть прописать этот метод.

Да если кто не заметил, то при загрузке в шотгане оказывается заряжен последним типом патрона, наследник РГ-6 соответственно тоже.

В R1 в ЗП в CLightR_Manager::render_point есть такой участок кода:



Сомнительно заккоменчена вот эта строка: //L_pos.y += _camrange; (причем в ЧН она функционирует). Я бы посоветовал раскомментировать ее, иначе свет от точечного света на R1 может некорректно считаться. Это явно видно по коду.

Кто-нибудь мне может объяснить, почему сталкер не умеет показывать сообщения на худе в 5 строчек? Сообщения в Журнале ПДА при этом отображаются.
ТЧ, разрешение экрана 1920х1080.



Когда сменил разрешение на 1280х1024, всё заработало

RayTwitty, 1920х1080:


Обсуждали это очень давно здесь https://www.amk-team.ru/forum/topic/5525-so...;comment=749363 и ниже.

ЗЫ. Что-то я не совсем понял как здесь файлы прицепить.

Нажмите для просмотра прикрепленного файла

Marafonec, первое что я и сделал когда обнаружил проблему - увеличил на 100 пикселей sp_log_list по высоте и отдельный айтем сообщения. Но оно, конечно, не сработало, поскольку 6 строк показывается, а они больше чем 5, следовательно проблема не в высоте.

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

З.Ы. ты приложил файлы оригинального ТЧ.

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

Они полностью идентичны оригинальному ТЧ Проверял WinMerge через сравнение папок.


Хорошо, надеюсь это мой локальный глюк.

X-Ray Oxygen ищет C++/CLI разработчиков.
Задача проста:
Перенос таблиц экспорта в Lua в Managed код.

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

Батник с предварительным удалением кеша перед запуском игры.

Проверить даты изменения файлов. Или в скомпиленный шейдер класть crc32 исходника. Если исходник изменен позже скомпилированного или crc не совпало, надо перекомпилировать.

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

Zagolski, отключали. Такое себе, постоянно рекомпилятся, сейчас у нас вариант с crc32.

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

ForserX, А там у вас как сделано, к тем опциям "111265453" добавляется crc в название файла? Ну в принципе да, такое можно и на постоянку сделать. Весьма удобно и работать будет быстрее, чем с полной перекомпиляцией.

А с другой стороны кэш вообще можно убрать. Какая от него польза? Ну на пару сек дольше старт игры. Да и то только при наличии в коде шейдеров навороченных [unroll]. Зато сколько проблем доставляет. Разработчику - постоянно чистить. Игроку - тоже чистить при установке шейдеров. К тому же многие игроки забывают кэш очищать или не знают, потом на форумах много ненужных вопросов.

ТЧ
В хедере level.h имеется глобальная ф-ция:
Ну и в различных местах, довольно массово используется, типа
Захотел ее использовать в CEntityCondition, но получил от студии "error: недопустимый неполный тип". В EntityCondition.h подключение вроде имеется: #include "Level.h".
А что не так-то ?

Все остальные типы тоже нужно проинклудить: CHUDManager, CFont, ...

Вопрос - никто ли не пытался исправить в двигле ТЧ баг с солнцем? Либо я не там копаю либо все дружно плакали кололись но продолжали юзать скриптовый костыль.