OGSE: КБ разработчиков

[Murarius 10 532]

"Конструкторское бюро" OGSE.
Все о платформе, разработке, использовании материалов Old Good Stalker Evolution, а также всяческие предложения по дальнейшему развитию.

 

Исходники ogse.dll: https://yadi.sk/d/smv9hMa3gqGf5

Собирать только VS 2005 или VS 2008. В противном случае не взлетит.
Вроде бы внешних зависимостей никаких, необходимые файлы уже включены в проект.

 

Создаете файл с именем level.puddles в папке с нужной локацией. Открываете файл в текстовом редакторе и вносите туда записи вида:

[south_blockpost]
center = -84.61,-34.95,-347.90
max_depth = 0.5
radius = 30

[south_blockpost] - имя. Никакой роли не играет, служит лишь для ориентирования. Должно быть уникальным в пределах одного файла.
center - координаты центра лужи на локации
max_depth - максимальная глубина лужи. Выбирается таким, чтобы актор в самом низком присяде не смог в нее "нырнуть" с головой.
radius - размер лужи.
 
Определение координат для луж несколько заморочено. Связано это с тем, что не в любом месте можно поставить лужу - она может быть лишь в локальном углублении. Для выявления таких углублений предлагаю следующий вариант (именно им пользовался я). Декомпилируете локацию, загружаете в сдк. Удаляете ВСЕ объекты, кроме террейна, далее работаете только с ним. В свойствах террейна увеличиваете его вертикальную координату так, чтобы координатная сетка в сдк была полностью под ним. Затем понемногу "опускайте" террейн обратно. В тех местах, где будет появляться координатная сетка, и будут находиться локальные углубления. Киньте там калаш (или другой объект), узнаете координаты. Для большей заметности помогает сделать сетку "погуще".
Другой способ предложил Deathdoor. Сделайте очень большую плоскость в майке, обтяните заметной текстурой. Потом вставьте ее на локацию в LE под террейн, ну и двигайте потом вверх. Принцип аналогичен вышеописанному - там, где будет проступать плоскость, там локальное углубление.

 

При реализации этих эффектов довольно быстро стало понятно, что далеко не каждый источник света с ними выглядит хорошо. Потому была внедрена система пообъектной настройки фларов и объемного света. Для каждого источника можно включать или выключать эти эффекты отдельно двумя способами:
1) В all.spawn. Найдите секцию лампы, возьмите оттуда light_flags. Объемный свет включается путем выставления в light_flags флага 0x40, флары - флага 0х80. Выключаются эффекты снятием соответствующих флагов. Модифицируете флаг, собираете спавн, начинаете новую игру, наблюдаете появившиеся эффекты. Можно новую игру и не начинать, тогда перепишите нет-пакет лампы скриптом в игре. Для новичков в hex-исчислении: открываете виндовый калькулятор, переключаете в программистский режим, выбираете режим Hex. Выставление флагов производится функцией Or, снятие - функцией Xor.
2) В СДК. Поскольку расставление эффектов является больше дизайнерской задачей, сделал небольшую правку СДК: https://yadi.sk/d/3ZujqzlMgqJ6p. С ней просто запускаете LE, в опциях спавн-объекта лампы появятся флажки Enable Flare и Volumetric.

 

Прежде всего, понадобится утилитка, изготавливающая объемный туман, понимаемый OGSE-модом: https://yadi.sk/d/NXAUhXucgqJfP
Далее:
1) Запилите в 3d редакторе модель тумана и экспортируйте ее в obj. Вот простенькая модель, если кому лень запускать майку: https://yadi.sk/d/jvrU3XDjdSRvw
2) Создайте папку meshes в папке с fvolume_maker;
3) Скиньте модельку туда;
4) Запустите fvolume_maker. Параметры для батника:
-config <string> файл с конфигом объемов. Если не указано - будет fvm_config.ltx
-source <string> файл, куда сохраняем готовые объемы. Если не указано - будет level.fvolumes
-append <true|false> экспериментальная опция, позволяет не переписывать, а дополнять существующий файл *.fvolumes
Про файл конфигов. Он содержит записи вида:
[test]
position = 0.267,2.688, 91.776
rotation = 0.0,0.0,0.0
scale = 1.0,1.0,1.0
 
Все очевидно. Имя секции - имя вашей модельки. Position, rotation - позиция тумана на локации и поворот относительно осей.
Scale - растяжение модельки тумана по осям.
 
5) После окончания работы программы получится файл level.fvolumes. Нужно запихать его в папку с локацией. Для каждой локации такой файл нужен отдельный.
6) Правите конфиг туманов. Это файл config/environment/fog_volumes.ltx. 
Он содержит записи вида:
[test]
color = 1.0,1.0,1.0,1.0
max_density = 0.5
Тут еще очевиднее, чем раньше. Color - цвет тумана, max_density - плотность тумана. 
1 - ничего не видно через 1 метр, 0,5 - ничего не видно через 2 метра, и т.д. Обратная зависимость, короче.
7) Включаете опцию r2_volumetric_fog, загружаете локацию и ищете свой туман на локе.
 
Для удобной настройки есть консольная команда reset_fv. При ее вызове применяются изменения color и max_density.

 

Для создания и редактирования диалогов очень удобно пользоваться редактором диалогов за авторством Mlandrinus: https://yadi.sk/d/qmUaU5VIgqKCh. Кидаете в папку со сталкером, запускаете, дальше все в целом понятно. Конфиги должны быть распакованы.

 

Вид текстур в тепловизоре определяется настройкой material в textures.ltx. Имеется два пресета - для морд/тел/брони и для оружия. По сути, различие между пресетами заключается в том, что оружие при стрельбе греется и это учитывается. Если вы хотите применить для текстуры пресет для тела неписей, поставьте material в пределах 0,6-0,7. В данном случае 0,6 - холодная геометрия, 0,7 - горячая. Для оружия применяйте диапазон 2,85-2,95. Впрочем, в случае оружия лучше ставить всегда минимум (2,85), чтобы нормально выглядел эффект нагрева оружия.
Цвета в тепловизоре также можно настроить. Откройте shaders/r2/ogse_config.h. За цвета отвечают параметры IKV_DEAD_COLOR (цвет холодной геометрии), IKV_LIVE_COLOR (цвет горячей геометрии), IKV_MID3_COLOR, IKV_MID2_COLOR, IKV_MID1_COLOR (промежуточные "опорные" цвета). Все параметры приведены в RGB, подбирайте где-нибудь в пэинте.
Далее можно не читать, если вы не понимаете, для чего в игре параметр material. Если же вы понимаете и негодуете насчет того, что приходится менять ваши любимые настройки текстур ради тепловизора, внимайте.
Интервал значений material для тепловизора также можно изменить. За это отвечают параметры IKV_PRESET_1_MIN, IKV_PRESET_1_MAX (первый пресет) и IKV_PRESET_2_MIN, IKV_PRESET_2_MAX (второй пресет) в том же ogse_config.h. Правило конвертации - в ogse_config.h вносится значение (material + 0.5) / 4. Т.е., если нижний предел для первого пресета у вас 0,8, то IKV_PRESET_1_MIN назначаете равным (0,8+0,5)/4 = 0,325. Выглядит, странно, да, но вот так работает движок. И не без причины.

 

Есть такие консольные команды:
Цветокоррекция: r2_color_grading [0.0, 0.0, 0.0, 0.0]
Известный эффект, "подкрашивает" картинку на экране в выбранный цвет. Поставьте какой-нибудь синий цвет, мигом узнаете ранние Battlefield. Фича мощная, однако, требует некоторых усилий дизайнеров, поскольку цвет должен зависеть от локации и игровой ситуации.
 
Оптимизация отрисовки травы: r2_details_opt [0.0, 0.0, 0.0]
Три параметра, все три - расстояние в игровых метрах. Смысл такой: в игре трава рисуется квадратами 2х2, т.е. в одном "гнезде" четыре куста травы. С этим параметром по достижении первого расстояния перестает рисоваться один куст из четырех, по достижении второго - два куста из четырех, по достижении третьего - три куста из четырех. При тщательной настройке позволяет сберечь фпс без ухудшения картинки.

 

 

---

[KD87 718]

@dsh, да, она.

[Malandrinus 615]

За выходные физически не успел завершить систему аддонов, но вчерне всё работает. По результатам экспериментов самый удобный вариант схемы костей дополнительных аддонов получается такой (для случая прицелов. Для остальных аналогично, только имя стандартной кости другое):

wpn_body
    wpn_scope <== кость аддона со стандартным именем и без поверхностей
    wpn_scope1
    scope2
    ironsight

т.е. иными словами:

1. кости нестандартных аддонов растут от корпуса ствола (нет необходимости делать их дочерними к стандартной кости)

2. стандартная кость ВСЕГДА присутствует и она пустая

3. на именование костей нестандартных прицелов не накладывается никаких ограничений

 

Что ещё добавить к этому. Будет возможно делать съемные прицелы не текстурой, а моделью. В этом случае надо будет также настроить положение худа, которое в этом случае отличается от того, что прописано в секции худа.

 

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

[Mirage2000 128]

@Malandrinus, я нельзя еще скриптами  прикрутить раскачку оружия, так же добавить возможность анимирования переключения режимов стрельбы?

[ViNT 132]

Ребята, прошу прощения, если не в тему, но у меня вопрос "новичка" по звуковому наполнению. Есть у меня подборка, выдранная из мода фотограф и состоящая из реплик и историй сталкеров, а также гитарных композиций, вытащенных отовсюду. Подкинул я их в мод (их там в среднем около 30 штук на папку, ради примера - истории сталкеров idle_1, idle_2 и т.п. до idle_30). Постоянно, даже из новых, одни и те же фразы. Подкидываю композиции, например, в OLR - попадается большинство. А тут как будто не обрабатываются вообще. Ничего в плане вышеописанного не менялось?

Изменено 16 Февраля 2015 пользователем ViNT

[Malandrinus 615]

@Mirage2000, Этим сейчас заниматься не буду, но вообще возможно. Переключение - это просто анимация. Для скриптового управления анимациями сейчас всё есть: проверка их наличия, проигрывание, проверка длительности. Также есть колбеки на нажатия клавиш и проверка режима бега/прицела и т.п. Так что визуальное переключение режимов стрельбы реализуется довольно просто:
1. добавляем анимацию к модели худа, имя прописываем в секцию худа
2. по колбеку на нажатие клавиши, связанной с командой переключения режима стрельбы, проверяем наличие оружия в руках, и отсутствие проигрывания других анимаций, запускаем анимацию переключения, блокируем ввод на время проигрывания.

С раскачкой (во время ходьбы) всё сложнее. Если это сделать анимацией как для спринта, то собственно, а как стрелять? Ну т.е. как одновременно махать стволом и прицеливаться? Если актор в спринте и начинает стрелять, то переходит в режим бега (хода). Хотя проиграть анимацию при ходьбе (точнее беге, поскольку у всех и всегда включён "всегда бег" =) несложно по описанной выше схеме. Даже ещё проще, поскольку блокировка ввода не нужна.

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

[dsh 3 824]

Вчера в своей адаптации движка OGSE к ОП-2 я исправлял переставшие работать телепорты и заметил одну вещь. Вот кусок скрипта:

db.actor:give_info_portion("biznes_remove_special_item")
amk.remove_item_from_inventory(obj, db.actor)
db.actor:disable_info_portion("biznes_remove_special_item")

Как мы здесь видим, выполнение значимого кода помечается флажком. Этот код выполняется в коллбэке получения предмета. Судя по использованию флажка, автор предполагал, что после выполнения remove_item_from_inventory() немедленно начнется выполнение коллбэка на потерю предмета, которые обратит внимание на установленный флажок. И судя по тому, что с чистым движком это работает более-менее правильно и уже много лет, автор был недалек от истины и чистый движок действительно вызывает коллбэки немедленно при возникновении события. Так вот, пытаясь заставить этот код работать на движке OGSE, я обнаружил, что в нем коллбэки ставятся в некоторую очередь и вызываются строго друг за другом. Как минимум это относится к коллбэкам получения/потери предметов. Т.е. пока полностью не отработает коллбэк на получение предмета, не будет вызван коллбэк на потерю предмета, если мы что-нибудь удалим при получении предмета. Это действительно так? Это в движке OGSE менялось?

[kamikazze 266]

dsh

 

 

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

 

Да никогда такого не было. И в страшном сне такое не приснится никогда. Колбэки никогда нигде друг из друга не вызываются, только исключительно по очереди. Если бы они из друг друга вызывались, была бы возможна ситуация закольцовывания колбэков бесконечного друг на друга.

 

Т.е. пока полностью не отработает коллбэк на получение предмета, не будет вызван коллбэк на потерю предмета, если мы что-нибудь удалим при получении предмета. Это действительно так? Это в движке OGSE менялось?

 

Да, это так. Нет, это никогда не менялось, всегда так было и в оригинале тоже. Больше скажу, если бы это было не так, у нас всех с модификацией скриптов было бы на порядок больше проблем.

[BFG 7 582]

Уважаемые разработчики.

Разрешается ли использовать наработки по геометрии локаций из мода ОГСЕ 0.6.9.3 в своих работах, модах, правках ?

Естественно с указанием авторства.

 

p.s. Хотелось бы БАР попробовать адаптировать .

Изменено 17 Февраля 2015 пользователем BFG

[kamikazze 266]

BFG

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

[k01jan 816]

самый удобный вариант схемы костей

понимать как единственно возможный в рамках скрипта? На стандартную кость крепить дополнительные нельзя?

Будет возможно делать съемные прицелы не текстурой, а моделью.

А в чём прикол-то? Естественно будет, раз к wpn_body аддоны крепить.

В связи с:

1) А приближение при прицеливании тоже скриптом регулироваться будет? В секции, независимо?

2) Использование прицела "стандартно" (с текстурой и увеличением, задаваемыми конфигом), как я понимаю сохранится (в секции wpn_scope = 1 писать если)?

Для подствольных гранатомётов увеличение будет убрано? Бесит с оригинала.

Ну, а о "двойном" прицеливании а-ля GWR можно хоть помечтать?

P.S.: Ваш новый шейдер для линзы, hud_reddotsight1 как в SDK подгрузить? В  wipe_2_stable его нет. В up8\shaders\hud тоже не нашёл.

P.P.S.: Стандарт рук (=анимаций) принят? R74?

P.P.P.S.: Можно партиклы оружейки Amik'a добавлять?

Изменено 17 Февраля 2015 пользователем k01jan

[kamikazze 266]

P.S.: Ваш новый шейдер для линзы, hud_reddotsight1 как в SDK подгрузить? В  wipe_2_stable его нет. В up8\shaders\hud тоже не нашёл.

 

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

P.P.S.: Стандарт рук (=анимаций) принят? R74?

 

Тоже го скайп, я там тебе отослал приглашение в конференцию нашу по оружию.

[Malandrinus 615]

понимать как единственно возможный в рамках скрипта? На стандартную кость крепить дополнительные нельзя?

Единственное железное ограничение: стандартная кость должна быть и быть пустой (без поверхности). Т.е. выходит, что её использовать для одного из аддонов нельзя. Это связано с тем, что движок форсирует её видимость/невидимость. При этом никто не мешает использовать стандартные модели, если прицел всего один.

 

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

 

А в чём прикол-то? Естественно будет, раз к wpn_body аддоны крепить.

Прикол в том, что для снимаемого прицела движок показывает вместо него текстуру этого прицела в режиме увеличения. Поэтому коллиматоры все делают не просто несъёмными, а вообще как интегрированный ironsight просто хитрой формы.

 

1) А приближение при прицеливании тоже скриптом регулироваться будет? В секции, независимо?

Да, конфигом и скриптом с использованием хака. Всё по той же причине, у движка по умолчанию такой вариант не возможен и независимая настройка смещения худа для прицела отсутствует (он просто скрывается). Будет своя настройка, надо будет соответственно настраивать.

 

2) Использование прицела "стандартно" (с текстурой и увеличением, задаваемыми конфигом), как я понимаю сохранится

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

 

Система конфигов ещё дорабатывается. Детали опишу позднее.

 

Для подствольных гранатомётов увеличение будет убрано?

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

 

Ну, а о "двойном" прицеливании а-ля GWR можно хоть помечтать?

Думаю, ответ здесь в ключе предыдущего вопроса. Если будет контроль FOV, то можно будет и переключать его скриптом для конкретного ствола. Но не прямо сейчас.

[k01jan 816]

У-у-у!!! Да это ж сбыча мечт!
 

Саша, смысл в дочерних костях ох как есть! Как пример - увеличительная насадка для известного буржуйского коллиматора.
Да и, кроме того, это ж можно ж на новую кость (конфигом) механический прицел посадить, а потом в этом же конфиге второй прицел (текстурой) -- п.2.0. -- 7 А?

Изменено 18 Февраля 2015 пользователем malandrinus

[Malandrinus 615]

@k01jan, речь насчёт дочерних костей шла только в одном смысле, нет резона делать организацию костей так:

wpn_body
    wpn_scope
        wpn_scope1
        scope2
        ironsight

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

[kamikazze 266]

Если будет контроль FOV, то можно будет и переключать его скриптом для конкретного ствола. Но не прямо сейчас.

 

Так есть же уже. И скриптовый, и консольный и какой хочешь.

[Malandrinus 615]

@kamikazze, да, но там довольно топорно сделано прямо через глобальный FOV, а хотелось бы, чтобы ствол этим управлял. Ну т.е. подменять то значение зума, что прописано в прицеле ствола. Понимаешь, тогда движок всё сделает сам: плавный наезд/отъезд и пр.

[kamikazze 266]

malandrinus,

А вот это да, было бы очень удобно.

[V92 417]

Не совсем проблема, но всё же. Можно вернуть твёрдые провода в Припяти, как в оригинале, чтобы по ним можно было ходить? В ОГСЕ отличные локации, но в ОП-2 многие квесты завязаны на ходьбу по проводам, а в Припяти из ОГСЕ этого сделать нельзя. Не хотелось бы возвращаться к оригинальной багованной локации, поэтому если возможно вернуть твёрдые провода, было бы замечательно.

[Mari 1 990]

Вопрос к  @kamikazze.

 

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

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

Изменено 18 Февраля 2015 пользователем Mari

[killersan6 184]

@Malandrinus, 

А озвучка к новым анимациям прикручивается?