Основные преимущества и не только:

• Шесть полностью рабочих конфигураций (Debug, Mixed, Release / x86-x64)
• Полностью настроенная единая система сборки. Всё находится в одном решении и собирается по нажатию на кнопку "Собрать решение"
• Сборка всех шести конфигураций через AppVeyor, что позволяет примерно замерять время сборки и удобно выпускать релизы
• Многочисленные исправления и улучшения кода (Исправление багов, оптимизация, рефакторинг)
• Рабочий BugTrap x64 отправляющий отчёты на почту OpenXRay (если у вас установлен почтовый клиент)
• Рабочие компиляторы: xrAI, xrLC, xrDO_Light
• Последние версии LuaJIT и Luabind, доработанные для работы с движком.

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

Репозиторий на Github (Не забудьте поставить звёздочку!)

Страничка ВКонтакте

Канал на YouTube (Не забудьте подписаться!)

Discord-сервер (на русском и английском языках)

Воу, отличная новость! Больше года уже пилю мод на основе open xray, очень хорошая стабильность в целом, только вот в качестве основы брал старую master ветку под 2013 студию, ибо последние коммиты под новую студию либо не собирались либо были не доделаны(
Правильно ли я понимаю что вы добавили ещё x64 версию? Насколько она рабочая? У меня нет серьёзных технических знаний но некоторые интересные вещи всё же иногда удаётся написать)

Да, действительно, на текущий момент ветка master устарела, но, всё-таки, стабильнее веток dev и xd_dev.


Так и есть. За это спасибо проекту X-Ray Oxygen.
Работает достаточно стабильно, хотя некоторые частицы (партиклы) имеют слишком быструю анимацию. Находимся в поиске остальных багов =)


Вместо послесловия:
Если играть на оригинальной ЗП, то движок стабилен, но при использовании модов возможны проблемы. Они могут быть как из-за движковых изменений, так и из-за обновлённых LuaJIT и luabind.
Если у вас возникнут какие-то проблемы, пишите, обязательно пишите, нам нужна информация о стабильности движка именно при работе с модами.

А где можно почитать подробные изменения движка на русском, есть мысль присоединится к проекту. Править буду в основном то, что достаточно хорошо понимаю, т.е. оружейку, в оригинале(ПЫСы) этим занимался какой-то баклан.
А какая студия потребуется? У меня только 2010.

NanoBot-AMK, на данным момент описания на русском нет, но в скором времени займусь описанием правок. Студия нужна 2017.

Очень хорошая мысль

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

Ну это само собой, правленый движок обязан работать на оригинальном сталкере без проблем. Я да же для включения колбеков использую булевы, если не используются, то и не работают, это что бы меньше ресурсов потребляло. Все фичи по возможности включаться через конфиг, например, гранаты и патроны с пояса и так далее. Само собой надо хорошо документировать, что разработчик смог быстро во всём разобраться.
ЗЫ
Кстати, где лучше VS2017 скачать, что бы сразу заработала? И как именно версия сойдёт, что бы весила по меньше.

С официального сайта качай. Работает она весьма печально, как и все остальные версии студии.

Кто-нибудь пробовал переносить X-Ray на GCC?

Обратная совместимость это всегда хорошо, но не до такой степени)) Как правило, расширение скриптового API не требует каких-то отдельных настроек конфигурации.

А какую версию лучше? Там же целых три: Community, Professional, Enterprise.

Комьюнити, она бесплатная, только учётную запись надо будет зарегать.

Ещё важно, установится ли VS2017 на ХР, семёрка не работает, так и не починил.
ЗЫ
Скачал установщик с оф. сайта, тот не запустился, требует фреймворк 4.6.
ЗЫЫ
В общем, не получится, 2017 не поддерживает ХР, а семёрка не работает, хрен её знает как починить.
ЗЫЫЫ
Во обще мир софта и его разработки катится куда то в ни куда, мечтаю о С-- но что бы с поддержкой классов, т.е. ООП. Долбать 35 ГБ. Не знаю, наверно придётся по прежнему ковырять XRayExtensions, может реально проект на С-- переделать, надо только утилиту доработать, сейчас она умеет адреса релокаций переделывать, надо что бы вторую секцию данных добавляла в целевой файл.

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

Не ври.

Цитата(NanoBot-AMK @ 12.03.2018, 02:46)

В общем, не получится, 2017 не поддерживает ХР

Ну вот, был человек, и нет человека А что с семёркой?

Modera, про GCC: велись работы над портированием OpenXRay на Linux, работали Kaffeine и Vincent-t. Работы не закончены.

mortan, ну, если вспомнишь или найдёшь какие-то проблемы – пиши.

ForserX, если ты про ветку dev, то я её не подразумевал. В ветке xd_dev они рабочие, я же не просто так сказал переключиться именно на эту ветку.
(в мастере тоже должны быть рабочими. Хотя, если я неправ и в мастере они поломаны – исправьте меня)

Неудачное обновление, скорей всего не хватила памяти при установке, в результате ряд важных файлов были не установлены/активированы, короче не грузится. Я в общем то решил потихоньку, переходить на 7-ку. Взяли бы и сразу предупредили, сколько надо свободного места на ЖД для установки этого обновления.

Для семёрки это нормальная ситуация. А ещё бывает так что после обновления перестаёт запускаться вообще всё.
Короче это говно лучше не использовать. Переходи сразу на 10 или сиди дальше на XP, альтернативы НЕТ.

А что с текстом на x64? Не пропадает?

chriotmao, пропадает. Это общий баг х64 движков, не видел, чтобы кто-то исправил его..

Каналы исправил?

ForserX, да, компиляторы были починены, исправлены и протестированы Intorr'ом.

хм, ну ка по подробнее, не замечал такого

Раз через раз пропадает часть текста.

Tron, тот факт, что в движке от Im-Dex, Oxygen и здесь в OpenXRay пропадает текст дал мне основания полагать, что это общий баг. Хотя, честно говоря, кроме этих трёх движков я другие не тестил.. Может это и не совсем общий баг Подробнее здесь.

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

Shadovs, начал здесь работу над новым СДК. Он ещё не сделан и находится в начальной стадии, но работа уже начата.
Помимо этого, если на OpenXRay будут основываться движковые моды, то здесь будет в помощь настроенная система сборки. (это первые два пункта основных преимуществ, которые я указал)
Остальные правки задокументирую несколько позже.

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

Tron, а не знаешь ничего о такой проблемке: https://bitbucket.org/borscht/xray-csky/iss...ad-node-in-heap ?

Абсолютно случайный вылет, за ~1000 запусков игры ловил всего три раза.

Shadovs, это надо переписывать функцию для подсчёта используемой памяти и проверки кучи, она сама косячная.

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

В смысле программная ошибка или пролёт горячей частицы сквозь мой комп?

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


Надо будет посмотреть у тебя

Переписывать всё-ровно надо, в документации ясно сказано, PROCESS_HEAP_ENTRY при работе с HeapWalk трогать нельзя.
А потом уже пробовать ловить эту ошибку.

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

Что касается ошибки, то соглашусь с saas

Можно взять код из ЗП, но я бы добавил ещё блокировку кучи.

О как! Буду знать.

Так ведь это же итак ЗП.

Shadovs, изначально спрашивал про CS, там кривоватая реализация.

Neo][, а, точно

Нет, не ловил.

Возможно задам наиглупейший вопрос.
Но как запустить x64 сброку? Скачал для пробы R версию. Переименовал bins в bin. Запускаю с экзешника в корневике игры - стабильный вылет с руганью "OpenAL: Can't create sound device". х86 запускается нормально.

Antnigm, нисколько не глупый вопрос. Нужно 64-битные бинарники для OpenAL, которые не включены в поставку. Домой приду - скину файлики.. Несколько позже сделаю новый релиз с исправлением этой недоработки.

А попробуй удалить файлы wrap_oal и eax.dll, возможно, поможет и без скидывания файлов. И OpenAL попробуй установить.

Принял. Так же вылетает последняя M х86 сборка когда меняешь настройки графики.

Antnigm, как именно меняешь? Что в логе?

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

Я так понял что ХР не поддерживается. Смысл использовать 2017 студию, ничего она кроме гемора не даёт.

NanoBot-AMK, ну, как минимум: последний компилятор, удобство/скорость работы среды на проекте такого размера.

А про какой геммор говоришь ты? )

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

jamakasi, 7-ка сдохла. А ХР кое как, но работает. Новые студии просто загромождают проект всякими тупыми библиотека, которые вроде как должны повысить скорость, но конечно, такой скорости не дают*. Я про анализировал код IDA Pro 6.8, куча мёртвых функций, синусы по прежнему не инлайн, в общем не вижу смысла использовать VS2017. Я даже не использую в XRayExt SSE2, что бы Athlon XP могли работать.

* - если нет кеша 3-го уровня, то промах кеша съест всё преимущество.

Да ну что за гон, есть же версия под х86-64.

Не думал что скорости и не будет на старом железе?) А то что есть колоссальная зависимость "мусора" в зависимости от компилятора и ключей при компиляции?)




Гыг Попробуй её! Когда найдешь хоть одну софтинку которая просто сможет на ней запуститься то зови, ну или если запустишь на ней х32 софт ХРх64 такое же мертвое чудо как и XP 64-Bit Edition(версия для Itanium такая же мертвая как и эти камни), такое же как Win RT.

Вот прям сейчас, для домашнего юзания а не корп спецухи где это необходимость, юзать ХР это уже просто аут, софт медленно но верно прекратил развитие как и дрова, директа нового нет, дырявая, нормальной поддержки нового железа нет, новых игр нет в конце концов. Тут если железо настолько убогое то хотябы на висту\7ку переезжать, в крайнем случае на 8.1 которая на удивление отлично умудряется впахивать даже на 2х гб рам и обычном харде не самом шустром.

Прикинь, с 2014 года только её и пробую. 32-битный софт весь работает на ура, из х64 юзал 2009 майю, фаерфокс, клиент для меркуриал, какую-то игрушку на юнити, крузис2, оперу и ещё дофига чего. Лучше ты действительно сам попробуй, а потом пиши.

Надеюсь на момент написания поста ты был в курсе про особенности различных платформ и реализация тригонометрических функций на них, о интринсиках, о том, что компилятор имеет настройки, а также о том, что Athlon XP по меркам it это примерно ископаемое!?

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