abramcumner

@Silver Raven, может из-за пробела между двоеточием и l01?

С ап-про: Кроме фундаментального копания было ли сделано банальное профилирование? Если да, то из-за чего фризы? Что-то мне кажется, в этих фризах нет ничего фундаментального.

Локации из ЗП распаковываются с префиксом "cop", то есть cop:jupiter. Если распаковывается для СДК ТЧ, то в converter.ini в секции 3870_config заменить строку spawn_version = cop на spawn_version = soc. Как быть с локациями из маппака для ТЧ - не знаю. По логике должно работать с default:jupiter. Но скорей всего там был перенос без перекомпиляции, так что все-таки префикс cop.

Ну вот ты сказал Прошло всего 9 лет. Ну так и есть. Кому-то что-то не нравится - тот этим и занимается.

Декомпилировал с неправильным профилем.

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

@AKKK1, все же написано в шапке темы. Какой пункт у тебя вызывает затруднения?

@UnLoaded, а что сразу не написать, как напрямую работать с all.spawn из СДК. И как с помощью СДК подключать новые локации, не переводя всю игру в формат СДК.

Сурвариум именно что "делают с нуля". Посмотри исходники xray 2.0. По слухам сурвариум построен на них.

Можно попробовать после того, как откроются, спавнить открытые, а старые удалять. Ну и наоборот, как закроются, спавнить закрытые

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

Cлинкован только с xrRender_R4.

Должен р4

Мне кажется, в ТЧ и не заработает. В ТЧ колллизия не пересчитывается при анимациях. Хотя у тебя и проигрывается анимация раздвинутых дверей, для физического движка они закрыты. Надо писать свой скрипт и физикой расталкивать кости дверей в стороны

Весь движок в одном экзешнике и даже работает: https://yadi.sk/d/jRoSLVs8uUqY9 Распаковать в папку с ЗП, запускать start_monolith.bat. Для запуска требуются библиотеки c++ 2015.

Это обычные ХОМы. Для движка это просто не один объект, а много мелких. Разбери локацию с опцией le2(так геометрию видит движок) и проверь. Бесшовность не в смысле одна большая локация, а в смысле много маленьких, подгружающихся по мере необходимости. Тут и большая аи-сетка будет не нужна.

Совсем не факт. там все это усредняется, хранится по секторам(север, юг, запад восток). Или даже лучше так. Сейчас обрабатывается где-то около 3.14 * 30 *30 / (0.7 * 0.7) = 5767 нод. Можно случайным образом выбирать 500 нод и по ним считать. Мне кажется точность будет получаться не сильно хуже.

Что лучше бесшовность сделать, а сетку оставить как сейчас к примеру Это же не аи-секта уже. Аи-сетка только для прокладки пути нужна. Ну в сталкере ее еще для укрытий используют. Кстати в сталкере настраивается же разница высот между нодами. Перепрыгивать не будет конечно, но может ИК отработает А так это уже анимации и смарткаверы. Лично мне мешает то, что сдк в билдере собирается Вот пытаюсь в студию перетащить. Сейчас алгоритм такой: для каждой ноды берутся все ноды в радиусе 30 метров и для каждой делается выстрел. Если не долетает, значит укрытие есть. Все это потом складывается, усредняется. В ЗП делается два выстрела: в сидячего и в стоячего. Можно тупо взять ограничить радиус. Будут по идее проблемы с укрытиями в ямах, типа сразу за ящиком не попадешь, а сверху ямы все простреливается. Но время уменьшится квадратично: уменьшим радиус в 2 раза(до 15м), время сократится в 4 раза. В идеале конечно надо на ГПУ выносить - самое место такому там. Подъемы настраиваются в ЛЕ. Узкие места да - проблема: размер ноды фиксированный и достаточно большой. Просто совсем в узких местах и другие системы навигации не должны проводить НПЦ. Аттач к динамически объектам точно не аи-сетка. Это уже логика. Для статики там что-то вроде смарткаверов можно ставить.

Это правится. Хотя особого смысла нет. Логично. Вся аи-навигация такая. Ну это не недостаток аи-сетки, а недочеты алгоритма генерации или редактирования. Долго просчитываются укрытия. На драфте сетка мгновенно же считается. А просчет укрытия наверное можно и пооптмизировать. А там и альтернативы не пролезут. То есть руками расставлять? Ручное редактирование же и не нравится в аи-сетке

@Дизель,@HellRatz, а что не так с аи-сеткой, укрытиями и управлением ботами?

Прямого вызова между объектами не должно быть, особенно если вдруг планируется многопоточность на уровне объектов. Представь, что объект непосредственно вызывает функцию у другого объекта, который в это время обрабатывается в другом потоке. И не должно быть делегатов/сигналов скрывающих такие прямые вызовы. Делегаты/сигналы подходят, если у тебя все объекты работают в одном потоке. Иначе ты скоро запутаешься в синхронизациях на каждый чих. Запросто в движке могут быть такие места, где вместо отправки нет-пакета можно вызвать функцию. А может нет-пакет там и не просто так. У нет-пакетов простая абстракция: создаю сообщение, записываю все что надо, отсылаю. Ничего ужасного в ней нет. Естественно для большого количества параметров нужны обертки, чтобы с порядком паковки/запаковки не путаться. Для малого можно и так отправить.

По-моему нет. Но я за ним не слежу. Пока там не будет условно говоря ПВЕ, он мне не интересен. Ну примерно как возиться с движком сталкера. Тоже непонятно зачем и бесперспективное занятие при куче открытых развивающихся движков. Глобально если смотреть, переносу на другие платформы мешает только ДХ. Если осилить рендер, то остальное по сравнению с ним ерунда. Кооп - мне кажется, все хотели бы пройти сталкер в коопе Skyloader делает что-то похожее(на скрине видна сетка и вейпоинты???) на базе встроенного ЗПшного редактора погоды. Как-то все в куче неудобно обсуждать. Надо или отдельные темы завести или вообще проект на гитхабе и там обсуждать каждую идею по отдельности. В OpenXray сделали отдельные xrAICore, xrScriptEngine. Читал кстати обсуждения там? Статические либы и единый экзешник вообще технический вопрос. Должно собраться без сильных правок.

@Malandrinus, нет-пакет - это просто буфер с удобными методами для записи в него. Какая разница как он называется. Можно написать над ним обертки для паковки/распаковки конкретных сообщений. Обмен сообщениями между объектами - это хорошо. Надо и дальше его развивать. Выкинуть g_actor. Оффлайн/онлайн и два вида объектов нужны по-любому. Это очень здравая идея. Ну и сначала, конечно надо определиться, что ты хочешь сделать в движке. Вон RoH пилят кооп в сталкере, им выбрасывание сетевой архитектуры совершенно не в кассу. > сетевая архитектура движка - Все эти сообщения, объекты и все такое - это зародыш многоагентной системы. Это один из тех элементов, из-за которых мне нравится сталкер. > разные среды разработки (и в сущности разные языки) самого движка и SDK + Вообще это не очень плохо. Луа, с++, шейдеры, конфиги, хмл как-то переживаются. Проблемы в билдере. Сам пробую перенести СДК в студию, пока все печально. > архитектура, основанная на dll, а не на статических библиотеках + Тут плохи не сами длл, а то, что движок по факту монолитен, но раскидан по разным длл. Достаточно легко можно собрать один экзешник, но зачем? > разные версии рендера + Но они по-любому будут. Уберешь р1, добавятся как минимум р5(дх12) и вулкан. На гитхабе к примеру пилят опенгл рендер. Главное меню заводилось полгода назад. > абсолютная недокументированность кода +

@FonSwong, только у тебя очень странная функция. Она из таблицы x={t=5} делает таблицу y={5}.

@Silver Raven, одна ошибка из-за описки =test_lift_doors_onening. Другие сходу не нашел.