HLFX.Ru Forum (https://hlfx.ru/forum/index.php)
- Half-Life SDK (https://hlfx.ru/forum/forumdisplay.php?forumid=8)
-- Увеличение размеров карты (https://hlfx.ru/forum/showthread.php?threadid=5033)

Увеличение размеров карты

Доброго времени суток всем, кто ещё моддит, ну или просто почитывает периодически этот форум. Так как в разработке своего долгостроя я достиг критической точки, после которой внесение каких-либо масштабных изменений в код будет грозить массовой переделкой всех карт, сейчас нужно определиться, в каком масштабе эти карты строить.
Можно ничего не трогать, и работать со стандартной сеткой 8192х8192х8192, но есть несколько наработок, которые требуют, как минимум, более длинных (в одном измерении) карт. Выходов из ситуации есть два. Первый: обойти ограничение на 8192 юнита в дллках и delta.lst. Второй: уменьшить все объекты в игре в два раза, и работать со стандартной сеткой в уменьшенном масштабе.
И то, и другое реализуется без особых проблем. Но и то, и другое имеет различные минусы. Минус обхода ограничения - надо писать свою собственную мессагу для темпэнтить. А возможно, и ещё какие-то мессаги переделывать, чтобы координаты правильно передавались по сети. Минус уменьшения масштаба - нужен хак с размерами хуллов, и задержка падения энтить на пол до спавна первого игрока на сервере.
В общем, куда ни кинь - всюду клин. Вариант с масштабом на самом деле предпочтительнее, т.к. если уж вдруг придётся ЕЩЁ увеличить карту, то можно будет применить поверх него снятие ограничения на размер. Правда, такой сценарий мне слабо представляется, разве что за пределами 8192 юнитов будет не игровая, а декоративная часть карты с плавным переходом в 3д небо.
Собственно, к чему все эти рассуждения? При каком из вариантов выше шанс вылезти за лимиты компиляторов? Я не о том, чтобы заваливать всю карту деталями, а о неожиданных ошибках, связанных со скейлом текстур/лайтмап и лимитах. Есть у кого-нибудь соображения? Конечно, я ещё сам протестирую пару карт на предмет оптимизации, но хотелось бы услышать мнения.

В разумных пределах масштабирование даёт сравнимый эффект, например, в халфе камера на высоте 72 юнита, а в кваке - 56 юнитов, но громадные квейковские карты с халфовской точки зрения кажутся тесными и игрушечными А ведь хуллы даже почти совпадают.

Добавлено 09-08-2017 в 10:52:

Изменения для корректной потдержки больших размеров карт можно поискать в ксаше по строчке ENGINE_WRITE_LARGE_COORD.
Их там весьма немного: длина трассы до скайбокса, чтобы взять освещение от неба, а не с земли. sv_zmax максимальный становится 131070 или около того ну и пресловутый WriteCoord. Внутри халфы он используется, например для декалей, звуков и партиклей. Ну их тоже можно переделать на кастомные, а на клиенте вызывать эти звуки или партиклы. А амбиент саунд, это обычный саунд с каналом CHAN_STATIC.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Дядя Миша спасибо, что упомянул про некоторые изменения. Работы выходит довольно много, особенно с кастомными мессагами. Так что я использую уже отработанный вариант с масштабированием. И если уж захочется ещё увеличить, то сниму ограничения на размер, но темпэнтити, декали и всякое разное за пределами старых размеров располагать не буду, пусть там будет только ландшафт.
В общем, буду активно мапать "маленькие" карты.

Дядя Миша у меня попутный вопросец возник: я в теме про глобальное изменение масштаба упоминал про неправильный скейл хитбоксов по ключу $scale при компиляции моделей. То есть сама модель скейлится, а хитбоксы остаются тех же размеров, что и прописаны в qc-файле. Только если отскейлить модель во вьювере и пересохранить, они уменьшаются.
Ты не выкладывал сорцы своего studiomdl с поддержкой тайлинга и увеличенными лимитами? Я бы попробовал исправить для себя этот баг. Ну и по Motion Extraction хотелось бы что-то придумать тоже на этапе компиляции. А то уч0ные ростом 36 юнитов бегают со скоростью как при 72 юнитах, приходится в самом коде монстров использовать хак:

1

DispatchAnimEvents( flInterval );

2

#ifdef _HALFSCALE

3

flInterval *= 0.55;

4

#endif

5

if ( !MovementIsComplete() )

6

{

7

  Move( flInterval );

8

}

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

__________________

Ну я создал тему, но всем было настолько наплевать, что я не стал её продолжать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

А, это... Ну понятно.
Да у нас тут вообще всем на всё наплевать по большей части.

__________________

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!

FiEctro
Если я правильно понимаю, то донаты должен засылать не я, а мне. Так?

__________________

Ещё один вопрос. Есть жёсткий лимит на 512 моделей (браши + спрайты + студио), на больших картах это может быть весьма актуально. Со спрайтами просто: можно запаковать несколько с одинаковой палитрой в один файл и управлять рисованием с помощью кадров. Со студийными тоже просто: бодигруппы + секвенции = несколько моделей в одной. А как быть с брашами? Квейк может грузить маленькие bsp файлики как модели, некоторые итемы там так и сделаны. Халфа по-моему не дублирует одинаковые брашевые энтити как разные модели. А что, если она умеет грузить bsp модели как Квака? Знаю, что ксаш умеет, а вот в халфе не пробовал.

Добавлено 16-08-2017 в 12:12:

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

Ku2zoff "использование BSP ресурсов" на КСМ

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Crystallize а можно прямую ссылку? Что-то не гуглится и поиском по форуму не находится.