[CoP] Вопросы по SDK

[Rolan 22]

Software Development Kit для движка X-Ray 1.6 (версия S.T.A.L.K.E.R.: Зов Припяти)

---

Полная версия, позволяет работать с модификациями любой сложности, вплоть до тотальных конверсий с полностью новым содержимым. Инструментарий предоставляется "как есть" (as is), при этом компания GSC Game World не предоставляет какой-либо технической поддержки по данному SDK. Ниже приведены основные изменения по сравнению с предыдущими версиями SDK.

---

В отличие от SDK 0.5 (ЧН), предназначенного исключительно для работы с мультиплеерными уровнями и содержавшего лишь LevelEditor с основными компиляторами, SDK 0.7 содержит полный набор инструментов последних версий: -- ActorEditor -- LevelEditor -- ParticleEditor -- ShaderEditor -- Postprocess -- DialogEditor -- ScriptDebugger А также компиляторов: -- xrAI -- xrDO -- xrLC (+ coordinator + agent)

---

---В компиляторах новой версии улучшена поддержка многопоточной работы на многоядерных процессорах, и они используют до 4гб памяти (для сравнения: компиляторы ЧН хоть и поддерживали 4 ядра, но в них еще не была реализована адресация памяти, а в ТЧ и вовсе использовался только один поток). Скорость компиляции при полной нагрузке, соответственно, может вырасти до двух раз по сравнению с ЧН. ---Также стоит заметить, что именно невозможность адресации компилятором более, чем 2гб RAM, была причиной ряда ограничений, с которыми сталкивались разработчики модов: на максимальный размер ai-сетки (и, следовательно, размер играбельной площади уровня) и на максимальное количество вершин, - причем в ситуациях, когда сама игра бы вполне выдержала уровень. Разумеется, это не означает, что стоит пробовать делать уровни в 5х5км или 20 миллионов полигонов, но ситуаций, когда движок может работать с уровнем, а компилятор - не в состоянии его собрать из-за ошибок переполнения памяти, - происходить уже не должно. --- Нельзя не упомянуть о реализации для всех редакторов SDK поддержки Windows Vista и Windows 7.

---

---Важное нововведение - возможность компиляции уровня на нескольких компьютерах одновременно. Выполняется она с помощью xrLC и дополнительных приложений. Один компьютер выполняет роль "координатора", остальные, "агенты", работают с определенными им задачами. Для простоты работы к SDK приложены уже настроенные исполняемые файлы, с которыми достаточно лишь указать имя уровня и IP координирующего компьютера. Смысл использования такой компиляции понятен - она позволяет собирать сложные уровни с очень высокими установками качества за куда меньшее время, чем на одном пк. Разумеется, со времен xrLC ТЧ, у которого уходило до недели чистого времени на сборку крупного уровня в высоком качестве, скорость работы компилятора возросла до четырех раз, но время компиляции всё равно не назовешь быстрым.

---

---

--- Совершенно кардинальных изменений нет - движок создан не вчера, и большинство инструментов подходит для работы в неизменном виде уже который год. Главным является то, что все инструменты присутствуют в полном объеме, и совместимы с последними версиями форматов, используемых в X-Ray 1.6 (ЗП). --- Отличия, о которых стоит упомянуть отдельно, могут быть приведены как по сравнению с SDK 0.5 (ЧН), так и с SDK 0.4 (ТЧ), так как в SDK ЧН целый ряд инструментов отсутствовал.

---

--- Доработан инструмент Move: теперь необязательно переключаться нужную ось для перемещения объекта: на объекте отображаются контроллеры, за которые достаточно просто потянуть курсором. --- Появилась отсутствовавшая в SDK ЧН возможность использования spawn element классов: ---- actor ---- camp ---- smart_terrain ---- smart_cover ---- и им подобных Таким образом, в SDK появилась возможность работы со смарткаверами (которые хоть и появились впервые в ЧН, но в его SDK были недоступны) в частности и уровнями для одиночной игры в целом (имевшаяся в LE ЧН, но достаточно ограниченная). --- Убран ряд устаревших классов spawn element, добавлены задействованные в ЗП классы. --- Появился инструмент Simulate / UseSimulatePositions, предназначенный для проверки физики прямо в редакторе. --- Для ряда классов spawn element отображаются вспомогательные модели, упрощающие работу в ситуациях, когда в сцене много объектов.

---

Приложение для создания и редактирования файлов .ppe (постпроцесс-эффектов). Достаточно просто в освоении: семь классов эффектов, ряд параметров в каждом, возможность строить последовательности и другие возможности.

---

Приложение для редактирования диалогов игры в формате .xml с поддержкой условий и проверок has_info, dont_has_info, give_info, disable_info, precondition, action.

---

Отладка Lua скриптов, проверка синтаксиса и их валидности, поддерживает работу с Source Control Center.

---

--- Формат уровней (за исключением данных, относящихся к xrAI), практически не менялся, поэтому результаты работы xrLC могут быть использованы и в ЧН. Разумеется, это относится только к мультиплеерным картам либо использованию геометрии. Таким образом, если вы хотите использовать SDK 0.7 для компиляции одиночного уровня к ЧН (скажем, из-за скорости работы xrLC), то это возможно, - но, соответственно, только с xrAI от ЧН. ---Файлы, собранные xrDO, совместимы как с ЗП, так и с ЧН и ТЧ. Файлы .thm совместимы со всеми версиями игры вплоть до ТЧ 1.0004. Формат скелетных объектов .ogf в ЗП и ЧН одинаков, - результаты работы в ActorEditor можно использовать в обеих играх.

---

--- Благодарим всех поклонников S.T.A.L.K.E.R.-a за интерес к нашей игре. --- Особая благодарность модмейкерам и @bac9-flcl за помощь в сборке этого SDK.

---

---

Причины вылета Invalid vertex for object: 1. В секции этого объекта position или level_vertex_ud НЕ соответствуют game_vertex_id. Решение простое - загрузите локацию и замерьте нормальные координаты. 2. В секции этого объекта неправильный object_flags. Берите его от объекта такого же типа. Для компиляции карты (в xrLC) с нормальным освещением используйте ключ -nosmg

xrLC.exe -nosmg -f test_map

---

---

X-Ray SDK v.0.7 (размер файла: 446 мб) Зеркало (спасибо @stunder) Патч 1.0 (размер файла: 3,82 мб) Документация к SDK

---

Плагин импорта статики формата object в 3ds Max (плагин кривоватый, автор Neo][) Плагин импорта статики формата geom в 3ds Max (surfer, Neo][): Плагины импорта/экспорта геометрии в Milkshape 3D (bardak, Kamikazze): Плагины импорта/экспорта геометрии в Maya (bardak, surfer): Плагины экспорта геометрии из 3ds Max/Maya/Lightwave (официальные от GSC):

---

Ускоренные компиляторы для ЧН-ЗП, присутствует обход ошибки Invalid Face (@macron, drvoodoo-guru)

---

Конвертер уровней в формате СДК ТЧ в формат СДК ЧН и ЗП (S_P_S), зеркало (спасибо @genior) Декомпилятор уровней, конвертер моделей и анимаций и пр. (bardak, x-ray engine toolset team) Конвертер файлов thm из формата ТЧ в формат ЧН/ЗП (Kln) Конвертер scene_object.part любой карты из SDK ТЧ в формат SDK ЧН/ЗП

---

---

Перед тем, как задать вопрос, пожалуйста, прочитайте вот это и это. Поверьте, там есть ответы на многие ваши вопросы. Также используйте поиск по форуму. Bопросы, на которые уже были ответы, будут нещадно удаляться. Если пишете сообщение об ошибке или вылете, то обязательно прикладывайте лог: без него весь смысл вашего сообщения теряется и оно, скорее всего, будет удалено.

[BFG 7 582]

О чём спор неясно мне, может кто разъяснит для нуба.

Один говорит про hom в СДК который ДО компила, другой - который после ДЕкомпила. У одного синий, у другого белый.

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

Изменено 16 Декабря 2016 пользователем BFG

[sneik 341]

@BFG, И белый полупрозрачный с типом объекта НОМ это НОМ и синий не прозрачный с материалом осс это тоже НОМ. Разницы нет, при билде результат один, поучаем фаил level.hom в котором "запекаются" эти объекты.

[Expropriator 2 118]

осс

что то тут явно не правильно. Соунд оклудер тоже имеет тип материала occ. Материал не должен влиять на перемену свойств статики в хом. Правильный хом, заранее белый до компиляции, должен быть сразу после редактора и это делается в Левел Эдиторе в свойствах библиотеки объектов.

Изменено 16 Декабря 2016 пользователем Дизель

[sneik 341]

@Дизель, 

[Akello 175]

Ты лучше загляни в СДК и все увидишь своими глазами. А лучше для эксперимента сделай мини локу.

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

Изменено 16 Декабря 2016 пользователем Akello

[Expropriator 2 118]

@sneik, это хом (недоделаный), и не хом. Это фейковая плоскость, для чего я не знаю, возможно для защиты от прожига, возможно для защиты визуала нпс, что бы через дом не бесились.

Изменено 16 Декабря 2016 пользователем Дизель

[abramcumner 1 159]

По исходникам ЛЕ ЗП sneik полностью прав: HOM`ом считаются и объекты с object type = HOM и объекты с материалом occ

 

SOM`ом считаются только объекты с object type = Sound Occluder, а материал надо прописывать по нужному Sound Occlusion Factor`у.

[Expropriator 2 118]

@abramcumner, спорить не буду. Всё возможно.

[Серый Волк 841]

кто-нибудь может мне объяснить почему удалённые вручную порталы потом невозможно воссаздать ни оптом (compute all portals), ни по одному (compute sel. portals). после создания любым из этих способов, пишет в логе, что всё хорошо, но порталов не видно, ни в сдк, ни в игре.

 

[Expropriator 2 118]

@Серый Волк, ноги порталов растут из секторов. Портал - это дырка из сектора в мир иной. Значит у тебя сектора нет.

 

Хомы думаю не хуже справляются с подобной задачей.

 

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

Изменено 16 Декабря 2016 пользователем Дизель

[Серый Волк 841]

 

 

Значит у тебя сектора нет.

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

[Expropriator 2 118]

@Серый Волк, неправильно сделана геометрия внутренняя для сектора. Ничего не должно мешать во-первых, даже торчащая лестница, во вторых геометрия сектора создаваемого не должна соприкасаться с дефолтным сектором.

 

Край сектора должен проходить внутри помещения, в центре проёмов.

 

Может я не прав. Короче, я нуб. Я всегда Хомами всё это делаю.

Изменено 16 Декабря 2016 пользователем Дизель

[sneik 341]

@Akello, Сделай мне тоже одолжение, потрать 5 минут своего драгоценного времени и сам все проверь. Сразу отпадут все вопросы.

 

никогда фейк не становился хомом

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

[Серый Волк 841]

 

 

неправильно сделана геометрия внутренняя для сектора

это ПЫСовское здание мною не тронутое, за исключением удаления портала на месте скрина.

[Expropriator 2 118]

@Серый Волк, а ты как и где добыл это пысовское здание? Это из исходников СДК или распаковка конвертором Бардака? При распаковке геометрии многие сектора нарушаются, потому что геометрия сшивается велдом при компиляции локации.

 

В исходниках есть корабль с геометрией под сектора - глянь как там сделаны зазоры.

Изменено 16 Декабря 2016 пользователем Дизель

[SoP 119]

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

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

 

Попробуйте просто на локации поставить в видимом месте HOM-плоскость и скомпилить тестовый уровень на драфте. Побегайте вокруг этой плоскости и все становится понятно, как это работает.

 

Так что ХОМ делается из одиночных плоскостей, он работает в обоих направлениях. И ХОМ-ы нужно делать как можно более "грубые", Low-Poly, чтобы движок не парился на обсчете этих хомов, а то вместо оптимизации получите обратный эффект.

З.Ы. Да, и abramcumner правильно сказал - СДК одинаково корректно запекает объекты с типом HOM и с материалом occ в ХОМЫ, это проверено неоднократно. Это удобно, когда делаешь например объект подвала в 3ds Max - я лично все включаю в этот объект сразу - статику, HOM-у с материалом occ, объект nosun  и sound occluder - потом сразу экспортирую весь блок одним объектом в СДК. При компиляции потом все отлично работает, хома с материалом occ.

Изменено 16 Декабря 2016 пользователем SoP

[Expropriator 2 118]

@SoP, да я помню - бегал, просто мало ли что, кто то писал, что надо вторую плоскость - я со всеми соглашаюсь.

[Серый Волк 841]

 

 

а ты как и где добыл это пысовское здание?

стандартная сцена затона - лесопилка. из исходников.

[WizziGun 376]

Товарищи, при експорте в огф вот такой лог выходит.
invalid file path.
В чём проблема?

[Vlador 36]

Приветствую всех. Есть проблемка, и решить бы ее: новые объекты формата .ogf не видны в SDK. Что делать? Может, их где-нибудь надо прописать?
А вот статические объекты работают все без проблем.