[SoC] Ковыряемся в файлах

[ed_rez 16 111]

gruff,

один вариант задать вес объекту в файле спавна:

; cse_visual properties
visual_name = physics\test\buldozer
; cse_ph_skeleton properties
skeleton_name = idle
skeleton_flags = 1
; cse_alife_object_physic properties
mass = 10000

Второй вариант задать вес скелета в SDK.

[ed_rez 16 111]

 

 

Я так понимаю?

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

[ed_rez 16 111]

 

 

Добавлял динамический обьект.

Тогда однозначно через SDK, я бы так сделал: *.ogf->*.object->SDK-*.ogf. 

[ed_rez 16 111]

 

 

А xdb-отстой, без компрессии, и гамедату перекрывает.

Но сколько мы имеем плюсов, при редактировании. Предположим, мы имеем какую-то часть своего проекта (рабочую), но требуется внести значимые изменения. Чтобы не запоминать каждый файл и не выписывать в сторону, что правили, а править мы будет многое, то пакуем игровой архив-файл для папки mods и тестируем запуском игры. Если происходит сбой, то нам не нужно поднимать записи, что правили, а правили многое и не за один день. Сложновато ковыряться в 10 тыс. файлах и сортировать их по датам, хоть как-то отделяя от не редактированных. В том варианте, когда правки отдельно и лежат в mods, то после распаковки и дальнейшего поиска ошибок, куда более продуктивный метод. А после тестирования, объединяем с файлами мода и пакуем в игровые архивы *.dbX.

 

 

Есть способ заставить игру читать их из нескольких мест?

Не очень понятен смысл, когда можно переименовать файлы, тем самым выделить их... Чисто теоретически вопрос конечно интересен.

[ed_rez 16 111]

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

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

Да, есть минус, кто играет в многие моды, требуется откладывать игровые архивы в сторону, чтобы установить такой мод. 

Загрузка игры происходит изначально с игровых архивов *.dbX, затем папка gamedata и наивысший приоритет у папки mods. Значит тем способом, как ты описываешь, мы подписываемся на загрузки одних файлов, затем других, которые перезапишутся в памяти, а затем уже добьем третьей перезаписью с папки mods. Время на загрузки будет выше.

Вижу и в твоих словах плюсы. Если мне требуется распотрошить какой-то мод, то понятное дело, что твой подход удобен. Но вот задача, где больше плюсов, во времени загрузки или в удобстве потрошения!?

Мне интересно, как другие думают.

Изменено 8 Марта 2016 пользователем ed_rez

[ed_rez 16 111]

но и выгодно, в плане производительности.

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

Оптимизация в нашем случае- это качество упаковки, где *.dbX, превосходит *.xdbX, я про последние наработки упаковщиков. Я пишу, как удобно работать при создании модов и постоянном их редактировании. Редакция в одном месте, причем только те файлы, которые мы редактировали. Но после теста правок их лучше упаковать в обычные игровые архивы и не просто добавочным игровым архивом, а слить с уже существующими. Да и многим приятнее качать скачать мод, который будет весить не больше ТЧ+мод, т.к. сейчас тенденция такая, что почти все файлы ориг. ТЧ заменяются. А что остается не правленным- это смехотворный объем в Мб.

по идее это должно влиять на порядок загрузки в ее пользу.

Теоретически, время проверки наличия папок gamedata и mods- это не то время, на которое стоит уделять внимание. Либо есть, либо нет.

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

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

гораздо удобнее, будь возможность назвать .db архивы любыми именами, а не только фиксированным и обезличивающим gamedata.

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

 

 

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

Я полностью обложился "удобством" работы с игровыми архивами. Распаковщиками не пользуюсь давно. Запаковщикам, тут да, никак иначе.

Изменено 9 Марта 2016 пользователем ed_rez

[ed_rez 16 111]

Silver Raven,

кто-то уже писал, повторюсь, упаковку файлов лучше делать секциями папок. Первыми должны идти конфигурации, скрипты, шейдеры... Все файлы, которые являются скелетом мода. Затем модели, локации и текстуры.

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

Многие пожали руку человеку, который вычистил ориг. ТЧ от мусора. 

[ed_rez 16 111]

что творят ваши мододелы?

Бесспорно, т.к. любой мод- это сборка наработок + свои. Вот разработчики и тянут один за другим из в мода в моды этот хлам. 

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

Дополню. Существуют скрипты, которые выделяют файлы, которые используются, к примеру, локации, модели... Также слышал, что написан скрипт по звуковой части. Что мешает использовать все эти рычаги для зачистки своих наработок!?

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

Изменено 8 Марта 2016 пользователем ed_rez

[ed_rez 16 111]

MegaStalker,

game_relations.ltx

Silver Raven,

я думаю, что у Charsi, т.к. он разработчик этих скриптов, вроде.

[ed_rez 16 111]

 

 

Какой наболее оптимальный размер .db архивов?

Боюсь утверждать. Я также, как и ПЫС использую 700 мб. С новыми возможностями движка, думаю нужно повышать размер игрового архива, но на сколько, тут вопрос тем, кто занимается движковыми правками.

[ed_rez 16 111]

 

 

гигабайтные архивы должны быть наиболее оптимальными

Теоретически- да, а практически- не могу знать, даже не тестировал такой вариант. Одно помню, что старые упаковщики портили архив, который превышал 1 Гб, поэтому привычно набираю вес архива до 700 метров. 

[ed_rez 16 111]

 

 

Мне твои методы кажутся странными/не вполне понятными.

Мне по крайней мере легче отследить, что игрок мода установил, т.к. каждый новый патч- это новый файл *.xdbX. Также проще делать откаты, установил, к примеру, какой-то граф. адд-он и еще всяких геймплейных правок. Что обычно получает игрок- папку gamedata, где все сложено вместе. Но не подошла игроку текстурная часть, он взял и удалил один архив из папки mods, а геймплейные правки устраивают- их оставил.

Очень удобно и быстро меняется та часть, которая не нужна на альтернативную.

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

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

[ed_rez 16 111]

nasar75,

проверил, да, работает! А я прочитал где-то, что не "кушает" плагин эти игровые архивы и даже не удосужился проверить. Благодарю!

Возможно в памяти осталось описание второго, который открывает все архивы папки (прописанной в файле конфигураций) через "Сеть". 

P.S. Пост отредактировал, чтобы не вводить в заблуждение.

Изменено 9 Марта 2016 пользователем ed_rez

[ed_rez 16 111]

паковались с ключом -store, т.е. без сжатия.

Пользуюсь конвертером от Бардака, *.xdbX запакованы без этого ключа, но открыл...

Команда так выглядит:

converter -pack -xdb c:\gamedata\ -out c:\*.xdbХ
pause

Интересно, а будет плагин открывать, когда запакованы xrCompress.exe игровые архивы *.dbX?

 

Изменено 9 Марта 2016 пользователем ed_rez

[ed_rez 16 111]

Charsi, 

какие плюсы у запаковки с компрессией, помимо уменьшения размера? Или может наоборот минусы?

Изменено 9 Марта 2016 пользователем ed_rez

[ed_rez 16 111]

Shennondoah,

с запаковкой, тут понятно. А вот компрессия что дает к производительности!?

[ed_rez 16 111]

 

 

Другое дело, что на современных системах разницу уже сложнее проверить/заметить.

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

Какой оптимальный размер архива, если взять среднестатистические 4 ГБ ОЗУ на х64, да и вообще из соображений ТЧ движка (1.0004-1.0006) из патча 1.0008?

[ed_rez 16 111]

Worklad,

actor.ltx

health_hit_part = 1.0 ;процент хита,уходящий на отнимание здоровья

power_hit_part = 0.1 ;процент хита,уходящий на отнимание силы 0.1= 10%

[ed_rez 16 111]

Jekyll,

;=========================================================================================
; Damage Params
;=========================================================================================
[m_giant_damage]
;bone_name  = <hit_scale>,-1,<wound_scale>
;<hit_scale> - коэфф. изменения хита (уменьшения здоровья) 
;<wound_scale> - коэфф. изменения величины открытой раны


default = 1, -1, 0.1
bone01 = 1, -1, 0.1
bip01_pelvis  = 1, -1, 0.1
bip01_spine  = 1, -1, 0.1
bip01_neck  = 1, -1, 0.5
bip01_head  = 2, -1, 0.2, 10

[ed_rez 16 111]

 

 

то есть нужно вместо "2" поставить "0"?

Именно так. Параметры выставлены в виде коэффициента: 0= 0%, 0.5=50% и т.д. И параметр 0 будет обозначать, что хита вообще не будет.