Ku2zoff писал: И чтобы не делать для неё анимацию idle (предшествующую самой этой анимации в качестве idle sequence), можно указать в qc-файле то же имя smd-файла, только фпс поставить в 0, чтобы монстр никуда не ходил и действий не делал.
При компиляции значение fps используется для деления на него, поэтому ноль там быть никак не может. Если компилятор вместо нуля будет сам подставлять дефолтные 30 фпс, тебе сильно легче станет? Так что не выпендривайся и делай нормальную idle.
Цитата:
Ku2zoff писал: Ну а чего тогда компилятор ругается на эти модификаторы? Пущай тады игнорит их.
Так он и игнорит. Но любой незнакомый токен воспринимается как имя .smd файла...
Дядя Миша писал: поэтому ноль там быть никак не может
Однако ж в других студиомдл может. Кто в этом случае не прав? Тот, ко писал эти студиомдл, или авторы математических законов, в которых деление на ноль невозможно?
Цитата:
Дядя Миша писал: Так он и игнорит. Но любой незнакомый токен воспринимается как имя .smd файла...
Судя по логу, не игнорит. Документации нету, вдруг новомодный студиомдл собирает исходную модель коряво. Кто его знает, может эти токены отвечают за что-то невероятно важное. И если их удалить, будет пипец. Неужели на КСМ никто не пытался собрать обычные халфовские модели этим компилятором? (Ах да, там они обычно предлагают отключить второй монитор. Им нет дела до моделей, лишь бы срач разводить). Спасибо за пояснение, если новой версии с багфиксами не будет, буду компилить монстров, удаляя незнакомые токены из QC-файла.
Однакож другие студиомдл не умеют и сотой доли того, что умеет этот. Они вообще этот фпс просто в модель пишут, никак не используя. Вот и могут.
Впрочем есть простой способ: пишешь имя своей секвенции и добавляешь команду frame 0 1. И будет тебе idle с нулевого по первый кадр. Так даже корректнее будет.
Цитата:
Ku2zoff писал: Судя по логу, не игнорит.
Ну он не может их воспринимать как известные, поскольку это запускает совсем другие механизмы обработки исходника. Учитывая что это компилятор, я не могу от балды проглатывать какие-то ошибки. Неизвестный токен, значит неизвестный. Исправляй исходник.
Перед тем как дать это компилятор народу я протестировал около сотни различных моделей, и в просмотровщике и в реальной игре. На данный момент есть совершенно точно одна проблема с компиляцией тентаклей, но навряд-ли кто-то из вас вообще поймет в чём она заключается, если я не ткну носом. А всё остальное превосходно собирается.
Цитата:
Ku2zoff писал: Кто его знает, может эти токены отвечают за что-то невероятно важное
Это остатки системы авто-анимации, да. Видел движковую функцию AnimationAutomove (которая в самом движке пустая)? Вот это оно и есть.
В студиорендере тоже есть немного кода, результаты которого умножаются на ноль и в компиляторе есть немного кода, результаты работы которого не попадают в конечную модель.
Цитата:
Ku2zoff писал: буду компилить монстров, удаляя незнакомые токены из QC-файла.
Кроме этих AX, AXR и прочих, проблем возникнуть не должно.
Дядя Миша писал: пишешь имя своей секвенции и добавляешь команду frame 0 1
Ого, вон даже как можно. Так указываются только первый и последний кадр, или можно несколько ключевых указать?
Блин, вот что значит нет подробной документации по сборке моделей.
Ku2zoff писал: Блин, вот что значит нет подробной документации по сборке моделей.
Як это нету?
Я же написал, вот команды от сорса: https://developer.valvesoftware.com...ory:QC_Commands
совпадает практически всё. И там унутре команд еще параметры. Конечно не всё будет иметь эффект на чистой халфе.
Добавлено 01-09-2017 в 11:09:
И еще можно запускать с ключом -dev как движок, чтобы посмотреть о чём он там ругается.
Добавлено 01-09-2017 в 11:11:
Цитата:
Ku2zoff писал: Однако ж в других студиомдл может. Кто в этом случае не прав?
исходники, написанные для шестой студии не компиляцца без правок в 2010-й. И обратное тоже верно. Кто в этом случае не прав?
Дядя Миша ладно, так и быть почитаю Подскажи мне, пож, можно ли не отправляя мессагу с сервера, активировать ScreenShake на клиенте? Или таки придётся писать свою собственную кастомную мессагу, чтобы движок её не перехватывал?
Итак, провёл эксперимент. Объединил шесть карт из Ретрибьюшена (сорцы жы есть) в одну. В принципе, всё нормально. Компилится правда долго, но это из-за некоторых косяков на самих картах. Почти упёрся в лимит по клипнодам. Это решаемо использованием текстуры clip где надо. И таки упёрся в лимит по моделям. Ну это решаемо либо использованием всяких func_wall по минимуму (довольно много из них я перегнал в мир), либо использованием студийных пропов. И моё предположение подтвердилось: одинаковые брашевые модели довольно часто дублируются. Так что смысл в подгрузке внешних BSP есть. Ещё можно самой дллкой прекэшить по минимуму моделей и спрайтов.
Добавлено 07-09-2017 в 00:10:
Кстати, зачем юзать func_wall для избежания разбиения поверхностей, когда VHLT умеет func_detail? func_wall в таком случае нужны только для объектов с особыми рендермодами или с переключающимися текстурами (выключаемые лампы, например).
Добавлено 07-09-2017 в 00:12:
Короче говоря, пора мапперить в полную силу, дописывая по пути нужный код
Это очень здорово, т.к. я предпочитаю брашевую детализацию. Всякие там провода на стенах, мелкие трубы, таблички, лампочки и проч. Детайлы в этом случае убивают двух зайцев: во-первых, не занимают драгоценную таблицу моделей, которых не только на карте, а вообще движком может быть прекэшено не более 512 шт. А во-вторых, экономят клипноды, если делать их несолидными.
С моделями выходит вообще интересно. Их у меня получилось в самой карте чуть более 400 шт - уже словил Host_Error на прекэше. И это при том, что все монстры, кроме снарков, барников, учёных, крыс и тараканов временно вырезаны. Когда я перегнал кучу иллюжнарей и валлов (просмотрев треть карты) в мировые полигоны, удалось снизить кол-во моделей примерно на 100шт (того лога под рукой нет, точную цифру не помню). Но возросло количество клипнодов где-то до 70% от максимального. Тут я конечно подумал про текстуру clip и вспомнил про детайлы. Умело используя инструменты оптимизации можно уложиться в лимиты даже на очень сложных и детализированных картах.
C++ Source Code:
1
models 387/512 24768/32768 (75.6%)
2
planes 7259/32768 145180/655360 (22.2%)
3
vertexes 16014/65535 192168/786420 (24.4%)
4
nodes 6358/32767 152592/786408 (19.4%)
5
texinfos 4397/32767 175880/1310680 (13.4%)
6
faces 11549/65535 230980/1310700 (17.6%)
7
* worldfaces 8194/32768 0/0 (25.0%)
8
clipnodes 18693/32767 149544/262136 (57.0%)
9
leaves 4430/32760 124040/917280 (13.5%)
10
* worldleaves 1726/8192 0/0 (21.1%)
11
marksurfaces 14511/65535 29022/131070 (22.1%)
12
surfedges 53901/512000 215604/2048000 (10.5%)
13
edges 27029/256000 108116/1024000 (10.6%)
14
texdata [variable] 4781628/33554432 (14.3%)
15
lightdata [variable] 0/50331648 ( 0.0%)
16
visdata [variable] 0/8388608 ( 0.0%)
17
entdata [variable] 143527/2097152 ( 6.8%)
18
* AllocBlock 28/64 0/0 (43.8%)
Вот кусок лога от другой компиляции (здесь всего 4 карты в 1, а не 6, и нет оптимизации). Получается, самой большой проблемой остаётся маленький скейл текстур, влияющий на MAX_MAP_PATCHES и AllocBlock. Чтобы обойти это, придётся попотеть.
И самое главное: все шесть карт у меня предположительно уместились в игровое пространство 4096x4096x4096. То есть их можно даже не уменьшать в масштабе. Но карты маленькие, коридоры короткие, открытых пространств нет.