Crystallize ну это прям грязный хак какой-то. env_sprite для прекэша использовать... Я прекэшу прям в коде. Грузится, работает и осязается. Только не видно.
Ещё в этом туторе есть минус: если на нашей карте есть брашевая модель с именем, таким же как и в загружаемой сторонней карте, тады ой.
Добавлено 17-08-2017 в 14:12:
Обернул ящик в пустой браш, сделал свет. Откомпилил с визом и радом. Теперь его видно. Но вставляется в качестве модели вся карта, а не только ящик. Не смог нагуглить никаких туторов по кваке, как правильно делать итемы маппингом. С параметром hlbsp.exe -nofill компилится нормально, но нет освещения - браш чёрный.
Добавлено 17-08-2017 в 14:42:
Разобрался Вот описание действий вкратце:
1. Создаём пустую карту. В центре создаём нужный нам браш. Обставляем его лайтами со всех сторон, чтобы он был освещён.
2. Компилим hlcsg, hlbsp и hlrad. hlvis не используем, он не сработает, и не даст сработать hlrad (т.к. у нас нет "неба" вокруг ящика). Для hlbsp выставляем параметр -nofill, чтобы компилятор не срезал фейсы нашего браша, как торчащие наружу карты. Игнорируем варнинг с отсутствием prt файла, если он выскакивает (в Джеке так).
3. Собственно, установка на карту. Создаём точечную энтитю с класснеймом брашевой. Добавляем вручную ключ model, и в нём прописываем путь до мини-карты (maps/crate.bsp, например).
3(1). Если у вас чистая халфа, то нужно мини-карту каким-то образом прекэшить. Подойдёт тот же env_sprite, или вообще любая энтить, где можно в свойствах указать путь к модели. Указываем maps/crate.bsp, как и в ключе model нашей браш-точечной энтити.
3(2). Если мод свой, то достаточно в коде нашей брашевой энтити добавить перед вызовом SET_MODEL( ENT(pev), STRING(pev->model) ); строку прекэша: PRECACHE_MODEL((char *)STRING(pev->model));
4. Запускаем и проверяем.
Ограничения всё те же, что и для обычных браш-энтить: не меняется уровень освещённости при перемещении по карте.
Добавлено 17-08-2017 в 14:51:
Тестовые карты в аттаче. Не забудьте про прекэш! Я делал его в коде.
Вложение: maps.zip (2.0 кб)
Этот файл был скачан 202 раз.
Ku2zoff писал: С параметром hlbsp.exe -nofill компилится нормально, но нет освещения - браш чёрный.
китайский рад умеет работать без виза, да и оригинальные вальвовские компилеры тоже умели. Это глючный ZHLT не умел.
Я когда-то хотел эту идею всячески развить и сделать компилируемые префабы на базе вот таких вот мини-мап. Но потом понял что там будет какой-то ужастный принцип неопределённости Гезенберга.
Дядя Миша а что за неопределённость? Как по мне, то вполне неплохо можно делать таким образом зарядники здоровья и брони, поезда и всякое, что повторяется на разных картах.
Добавлено 17-08-2017 в 21:38:
И танк как в инвазионе можно тоже сделать такими же брашами. Башню отдельно, корпус отдельно. Прекэшить и грузить бспшки прямо из кода.
Ну потому что во первых паренты, во вторых переход скрозь уровни. А в третьих (это самое стрёмное) - рекурсия. Начнут вкладывать префабы в префабы, а потом орать что энтити внезапно кончились на карте.
К тому же при таком подходе начнутся проблемы с пространством имён и джек эти префабы не сможет корректно отображать, я уже общался с Ксероксом и он подтвердил - да, не сможет.
Дядя Миша писал: Начнут вкладывать префабы в префабы, а потом орать что энтити внезапно кончились на карте.
Хм. В Халфе в качестве bsp-модели загружается та модель, которая в самой карте имеет имя "*0". То есть, если на миникарте есть мир и брашевая энтитя, то загружаемой моделью будет только мир. А если мира нет, то моделью будет первая брашевая энтитя (первая субмодель мира). Как в рамках халфы запихнуть в таком случае префаб в префаб, я не могу понять, ведь будет грузиться только одна модель с именем "*0".
Добавлено 17-08-2017 в 23:27:
Цитата:
Дядя Миша писал: во первых паренты
Ну так это в спирите и ксаше. Кстати, все эти вещи в мультиплеере жутко лагают, даже у локального игрока.
Ku2zoff писал: Хм. В Халфе в качестве bsp-модели загружается та модель, которая в самой карте имеет имя "*0".
Суть концепции компилируемых префабов в том, чтобы учитывать энтити в таком префабе, а сами префабы ставить на карту через специальную энтить, например func_prefab. И там же прописывать входы-выходы, через которые этот префаб будет фунциклировать с уровнем. То есть имена таргетов и таргетнеймов. Ну там довольно сложная концепция была.
Цитата:
Ku2zoff писал: Кстати, все эти вещи в мультиплеере жутко лагают, даже у локального игрока.
потому что предиктинг надо делать не только игроку, но и энтитям тоже. Тогда ничо логать не буит.
Дядя Миша писал: Ну там довольно сложная концепция была.
О, ну это совсем меняет дело. Я думаю, что такая система будет слишком сложной для мапперов. И сил на её создание будет потрачено больше, чем в итоге будет получено профита.
Вообще, ИМХО, главная польза от использования внешних бмоделей - это уменьшение времени компиляции. Польза от вставки готовых бмоделей в точечную энтитю сомнительна, т.к. такие модели не видно в редакторе, а скопипастить префаб с одной карты на другую и подогнать его на новое место - дело одной минуты.
Цитата:
Дядя Миша писал: потому что предиктинг надо делать не только игроку, но и энтитям тоже. Тогда ничо логать не буит.
Средствами дллок это же не получится сделать, нужна ответка со стороны движка?
Дядя Миша писал: сейчас есть интерполяция, возможно что её будет достаточно.
Её будет вполне достаточно (чтобы только визуально избавиться от лагов), энтити отстают не сильно, максимум на 1 кадр (или сколько-то там юнитов, визуально непонятно). А это в ксаше, или в оригинальной халфе? Если в халфе, можешь ткнуть носом в экспорты дллок, которые этим рулят (или могут рулить)? Хотелось бы всё-таки какой-никакой мовевитч в коопе. Хоть для поездов и дверей со стёклами. Про сложные конструкции я не думал, не знаю где их применить.
Дядя Миша писал: но вот мега-навороченный модельвьювер, поддерживает развесовку из хл2, жрёт модели из хл2 и умеет почти все фишки из хл2, кроме конечно вертексной анимации. При этом бинарно совместим с голдсорсом
Компилит труЪ, скейлит всё как надо. И хитбоксы получаются правильные, и монстры бегают с правильной скоростью... Но. Пам, пара-ра-рам-пам-пам! Порция багов-бажочков в тему.
Короче, новый студиомдл напрочь не понимает AX AY AZR, AZ и прочее, а так же испытывает когнитивный диссонанс при указании fps 0. Предыдущий и оригинальный хавают такие строки в qc что алкаш боярышник, и им ничего.
Ну, например, есть анимация для scripted_sequence. И чтобы не делать для неё анимацию idle (предшествующую самой этой анимации в качестве idle sequence), можно указать в qc-файле то же имя smd-файла, только фпс поставить в 0, чтобы монстр никуда не ходил и действий не делал.
Цитата:
Дядя Миша писал: Модификаторов AX, AY, AZ больше нет. Собственно, они и не юзались никогда.
Ну а чего тогда компилятор ругается на эти модификаторы? Пущай тады игнорит их. Он не может собрать СТАНДАРТНУЮ модель из халфы из-за этих модификаторов. Другие версии собирают без проблем.