Глава III. Компиляция (ZHLT).

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

Компиляция

Компиляция — процесс преобразования карты из формата MAP в формат BSP. Карту необходимо компилировать, т.к. Half-Life не может использовать карты в формате MAP. В редакторе карт Hammer используется свой формат RMF (Rich Map Format), который является продвинутым вариантом формата MAP. Однако компиляторы не могут его использовать. Им необходима карта только в формате MAP. Именно и только поэтому необходимо перед компиляцией сохранять карту в формате MAP. Делается это в редакторе через пункт меню "File\Export to MAP".
Компиляция осуществляется специальными программами-компиляторами. Всего их четыре. Каждая из этих программ выполняет свою стадию в формировании готовой карты. Лучшими компиляторами считаются утилиты Зонера — Zoner's Halflife Tools (сокращенно ZHLT).

Исходник карты

Исходником карты — называется Ваша некомпилированная карта, сохраненная в формате RMF или MAP. Карты в формате RMF понятны только редактору Hammer (и его предыдущим версиям Worldcraft). Другие редакторы (например, Quark, GtkRadiant) не работают с такими файлами. Они могут открыть исходную карту в более простом, но универсальном формате MAP.
Формат MAP является универсальным форматом, который понятен всем редакторам карт. Также MAP — это единственный формат понятный компиляторам.
Отличие между форматом MAP и RMF заключается в том, что в RMF редактор сохраняет дополнительную информацию, например, о сгруппированных или скрытых объектах. Мы рекомендуем хранить исходники своих карт в формате RMF.

Требования к компьютеру и время компиляции

Компиляция — процесс довольно требовательный к системным ресурсам. Решающими факторами, определяющими время компиляции, являются: количество оперативной памяти и частота процессора, но в не меньшей степени продолжительность компиляции зависит от структуры самой карты. Если карта построена неграмотно, если она не была оптимизирована и к тому же имеет довольно большые размеры, то компиляция может растянуться на несколько часов или даже дней!
Карты, представляющие из себя несколько комнат, компилируются порядка 30 секунд (компьютер: PIII-667 МГц, 128 Мб). Средние, ближе к малым, по размерам карты компилируются порядка 30-40 минут. Крупные карты, с большими открытыми пространствами, с большим количеством источников света (и особенно при наличии светящихся текстур) могут компилироваться на указанном выше компьютере от 3-4 часов и более. Если у Вас компиляция длится более 4 часов, значит со структурой карты не все в порядке или просто не хватает вычислительной мощности компьютера.
Нам известны случаи, когда на Pentium III 667 МГц со 128 Мб оперативной памяти компиляция большой карты длилась 36 часов! Основной причиной такой долгой компиляции является небольшое количество оперативной памяти (128 Мб). Компиляция "застопорилась" на операции "MakeScales" компилятора, просчитывающего освещение, а именно HLRAD. Когда вся оперативная память была исчерпана, стал активно использоваться файл подкачки, что привело к существенному увеличению времени компиляции.
Если у Вас мало оперативной памяти (128 Мб и меньше), а карта довольна большая, то обязательно увеличьте размер SWAP-файла (файла подкачки, определяющий размер виртуальной памяти). Рекомендуем сделать файл подкачки минимум 400 Мб при 128 Мб оперативки. Также можно попробовать откомпилировать карту, добавив параметр -sparse в строку запуска компилятора HLRAD. Это снизит затраты оперативной памяти на 10% за счет увеличения нагрузки на процессор. Ну, а самым лучшим решением проблемы будет покупка дополнительной оперативной памяти :) Необходимо, чтобы в компьютере было "хотя бы" 384-512 Мб.

Изменение размера файла подкачки в Windows

Для Windows 98/Me
Размер файла подкачки изменяется в: "Пуск\Настройка\Панель управления\Система\Быстродействие\Виртуальная память".
Для Windows XP
В XP данный параметр упрятан немного глубже :), а именно в: " Пуск\Настройка\Панель управления\Система\ Дополнительно\Быстродействие - Параметры\Дополнительно\Виртуальная память - Изменить".
В следующей статье данной Главы мы расскажем о лучших компиляторах для карт на движке Half-Life — ZHLT.

Zoner's Halflife Tools (ZHLT) — лучшие в мире компиляторы для карт на движке Half-Life. Также эти компиляторы называют Утилитами Зонера или Утилитами ZHLT. В состав утилит ZHLT входят четыре небольшие консольные программы-компилятора.
Основные отличия компиляторов ZHLT от стандартных, идущих вместе с редактором Hammer:

• бОльшее количество параметров для настройки компиляции
• более качественный просчет освещения
• более быстрая и качественная оптимизация карты
• подробная система сообщений об ошибках
• бОльшая информативность о ходе компиляции
• меньшее количество ошибок

Преимущества компиляторов ZHLT перед стандартными очевидны. Именно поэтому их используют 99% всех мапперов в мире.

Различные версии компиляторов ZHLT

Благодаря открытости исходного кода утилит ZHLT, появилась возможность улучшать их, чем не преминул воспользоваться Энтони Мур (Anthony Moore) aka "Merl". Этот хороший человек улучшил ZHLT и назвал их ZHLT Custom Build.
Итак, компиляторов ZHLT существуют две версии:

1. ZHLT (официальные компиляторы от Зонера);
2. ZHLT Custom Build (улучшенные компиляторы от Мерла).

Официальные компиляторы ZHLT, к сожалению, давно не обновляются (последняя версия 2.5.3 выпущена в 2001г.), однако и по сей день они прекрасно справляются со своей задачей и выдают на-гора великолепные по качеству карты.
Улучшенные компиляторы ZHLT Custom Build, к счастью, обновляются регулярно (о последней версии этих компиляторов Вы можете прочитать в следующей статье это Главы).
Какую версию ZHLT использовать? Наверное, все-таки ZHLT Custom Build, хотя скачать рекомендуем обе, т.к. в простых ZHLT есть полезная программка Ripent для изменения свойств объектов на карте без ее повторной компиляции.

Подробнее о программах-компиляторах

Итак, как мы уже знаем, всего компиляторов четыре:

1. HLCSG.EXE — просчитывает общую геометрию карты и создает 4 hull-файла для их обработки компилятором HLBSP;
2. HLBSP.EXE — создает дерево карты и работоспособный BSP-файл;
3. HLVIS.EXE — создает визуальную часть и оптимизирует карту для более быстрой отрисовки в игре;
4. HLRAD.EXE — просчитывает освещение на карте.

Компиляторы ZHLT в своей стандартной поставке не имеют графического интерфейса и запускаются из командной строки с указанием параметров компиляции. Последовательность запуска компиляторов такая же, как в списке выше. На сегодняшний день выпущено несколько графических оболочек для ZHLT, которые позволяют управлять параметрами компиляции и собственно запускать компиляцию карты по средством привычных меню и диалогов. Сразу на ум приходят несколько из них: ZHLT Compile GUI и Batch Compiler.
В процессе компиляции ZHLT записывают информацию о ходе компиляции в LOG-файл (файл называется по имени карты, к примеру, de_dust.log или de_aztec.log). Если во время компиляции возникнут ошибки, процесс будет прерван, а в директории с компиляторами будет создан ERR-файл с описанием ошибки (файл также называется по имени карты, например, de_dust.err). При обнаружении ошибок, Вы можете попытаться исправить их, и здесь пригодится наша статья, описывающая все возможные ошибки компиляции.
Очень сильно на время компиляции влияют установленные параметры. Например, можно откомпилировать карту очень быстро, но при этом пострадает как качество освещения, так и оптимизация под более высокий FPS (Frames Per Second). Такой вариант компиляции используется для тестирования карты, когда внешний вид не так важен. Можно наоборот выставить параметры, которые сделают карту максимально качественно, но за это придется платить бОльшим временем компиляции. Такой вариант используется для окончательной версии карты, когда она наилучшим образом освещена и оптимизирована.
Параметров компиляции существует довольно много (несколько десятков), но используются далеко не все из них. Описание всех параметров для каждого из компиляторов Вы можете найти в одной из следующих статей данной Главы.

О компиляторе NetVIS

В состав утилит ZHLT входит еще один компилятор — NETVIS.EXE, который является сетевой версией компилятора HLVIS. Если время компиляции HLVIS'ом слишком велико, Вы можете объединить несколько компьютеров и посчитать эту стадию вместе. Для этого один компьютер должен быть сервером, а другие — клиентами.
Запуск сервера: netvis.exe -server mapname, где mapname — имя карты;
Присоединение к серверу: netvis.exe -connect servername, где servername — имя или IP-адрес сервера.
По умолчанию клиенты коннектятся к серверу по 21212 порту, который можно изменить параметром -port.
Обмен информацией с сервером по умолчанию происходит каждые 60 секунд. Изменить этот показатель можно параметром -rate.

Установка и подключение ZHLT к редактору

Скопируйте содержимое архива с компиляторами в какую-нибудь папку. Для удобства можно создать папку ZHLT в директории с установленным редактором (например, "D:\Hammer\ZHLT") и скопировать файлы туда. Если Вы хотите сравнить удобство использования обеих версий ZHLT, то можете создать 2 папки. Во вторую папку (например, "D:\Hammer\ZHLT_CB") можно поместить улучшенные компиляторы ZHLT Custom Build. Однако подключить к редактору можно только одни компиляторы, поэтому удобнее пользоваться для компиляции BAT-файлами. В этом случае не надо будет изменять настройки редактора.
Если Вы планируете компилировать карты, используя редактор Hammer, то компиляторы необходимо подключить. Для этого в меню "Tools\Options" выберите вкладку "Build Programs" и укажите пути к каждому из компиляторов.
Все должно выглядеть примерно так:
Если для компиляции Вы будете использовать пакетный BAT-файл или программы-оболочки (например, Batch Compiler или ZHLT Compile GUI), то подключать утилиты к редактору не надо.

Наряду с официальными компиляторами от Sean Cavanaugh aka "Zoner" существует их улучшенная версия, так называемый Custom Build от Энтони Мура (Anthony Moore) aka "Merl". Версия утилит от Энтони Мура обладает рядом преимуществ, о которых и пойдет речь в данной статье. Все параметры, описанные в данной статье, применимы ТОЛЬКО к ZHLT Custom Build и не применимы к простым ZHLT.
Последней версией ZHLT Custom Build является 1.7. Также можно встретить обозначение 2.5.3-1.7, но т.к. при выходе новых версий Custom Build меняется только вторая часть цифр, то 2.5.3 принято опускать. Ссылки на скачивание обеих версий компиляторов ZHLT приведены в разделе "Программы".
Содержание статьи:

• Новое в версии 1.7
• Null-текстура
• Автоматическое определение wad-файлов
• Режим экономии clipnode
• Рассеянный свет
• Изменение теней объектов
• Конфигурационный wad-файл
• Путь к файлу wad.cfg
• Поддержка объекта info_compile_parameters
• Поддержка объекта info_texlights
• Переключаемые светящиеся текстуры
• Параметр -subdivide
• Максимальное vis-расстояние
• Новые параметры компиляторов ZHLT Custom Build

Новое в версии 1.7

• Поддержка переключаемых светящихся текстур
• Поддержка полупрозрачных и цветных теней для энтитей
• Возможное значение параметра "-subdivide" увеличено до 512
• Обновлена информация об объекте "info_compile_parmeters"

Null-текстура

Null-текстура предназначена для уменьшения количества отрисовываемых игрой полигонов, т.е. для снижения r_speeds и, соответственно, повышения количества кадров в секунду. Эту текстуру необходимо наносить на те стороны объектов, которые игрок никогда не увидит в нормальной ситуации в игре.
При компиляции null-текстуры просто удаляются, таким образом в игре движок Half-Life не отрисовывает поверхности, окрашенные null-текстурой. Применять null-текстуру можно как к обычным брашам, так и к брашевым энтити-объектам.
Пример использования. Допустим у нас на карте есть ящик (func_wall). В игре он будет расходовать 6 epoly по количеству сторон. Нижнюю часть ящика (дно) в нормальных условиях игрок увидеть не может. Окрасив ее null-текстурой, мы снизим показатель epoly на 1 полигон. Если ящик стоит около стены (как на рисунке), то также можно окрасить прислоненную грань.

Второй пример. У нас есть оконный проем со стеклом, сделанным из func_breakable или из того же func_wall. В игре стекло также занимает 6 epoly. Но игрок видит только 2 стороны стекла — другие 4 мы можем спокойно окрасить null-текстурой, таким образом сбережем 4 epoly.

Но это все меры, сберегающие epoly, в то время, как более главным для нас является сбережение wpoly. Поэтому null-текстуру нужно наносить на крыши домов, верхние грани заборов, стен, высоких ящиков — в общем, на те стороны, которые игрок увидеть не сможет. Кстати, вместо null-текстуры с тем же успехом можно использовать обычную SKY-текстуру. В обоих случаях происходит снижение r_speeds.
Если Вы будете использовать null-текстуру, не забудьте скопировать zhlt.wad (идет вместе с компиляторами) в какую-нибудь папку и подключить к редактору через меню "Tools\Options\Textures".

Автоматическое определение wad-файлов

Эта простая функция дает возможность подключать к редактору любое количество текстурных WAD-файлов, и при этом, только действительно используемые WAD-файлы будут включены в готовый BSP-файл карты.
Чтобы задействовать эту функцию, необходимо в строчку запуска компилятора HLCSG добавить параметр -wadautodetect.

Режим экономии clipnode

Данный режим включен по умолчанию в компиляторе HLCSG, поэтому нет необходимости включать его дополнительными параметрами.
Clipnode — поверхности, определяемые игровым движком, как непроходимые для игрока. Каждый браш на карте (будь-то стена, пол или ящик) "окутывается" clipnode-поверхностями. Благодаря clipnode'ам игрок не проваливается сквозь землю и не может проходить сквозь стены. Помните старый халфовский чит "noclip" (хождение сквозь стены) — вот это оно и есть :)
Количество таких плоскостей, как и многое другое в Half-Life, ограничено. Если число clipnode-плоскостей превышает максимально допустимое значение, то при компиляции возникнут ошибки.
В этой версии компиляторов, CSG анализирует использование clip-плоскостей на карте. Если в каких-то случаях возможно избежать их использования (например, func_illusionary не нуждается в использовании таких плоскостей), то такие clipnode-плоскости удаляются. Однако режим экономии clipnode не исключает появления ошибки MAX_MAP_CLIPNODES при компиляции, а просто уменьшает вероятность ее появления.
Подробнее об ошибке MAX_MAP_CLIPNODES Вы можете прочитать в статье "Ошибки компиляции".

Рассеянный свет

Эта функция позволяет создавать более реалистичное освещение с использованием объекта light_environment. При этом компилятор HLRAD использует информацию о цвете и интенсивности освещения не из стандартного параметра "_light", а из параметра "_diffuse_light" (Вы указываете цвет и яркость света, как обычно, но только в параметре "_diffuse_light"). В этом случае свет будет проецироваться не от солнца, а со всего неба, что должно сделать освещение более реалистичным.

Изменение теней объектов

Это новая функция в ZHLT Custom Build 1.7, позволяющая мапперу изменять прозрачность и цвет отбрасываемой брашевыми энтити-объектами тени.
Чтобы задействовать эту функцию необходимо выставить флаг "Opaque" в свойствах энтити-объекта, в параметре "zhlt_lightflags".
Далее необходимо отжать кнопку "Smart Edit" и добавить новый параметр по имени zhlt_customshadow . Данный параметр определяет прозрачность энтити-объекта, значения от 1.0 до 0.0 (где 1.0 непрозрачный объект (нормальная, полная тень), а 0.0 — абсолютно прозрачный объект (нет теней)).
Чтобы изменить цвет отбрасываемой тени (например, если Вы делаете эффект тени от цветного стекла), необходимо прописать не 1 параметр, а 3, которые определят цвет тени в формате RGB (Красный, Зеленый, Синий). Например, чтобы придать тени красный оттенок, необходимо прописать в свойствах 0.5  0.0  0.0. При указании значений более 1.0, компилятор HLRAD создасть что-то вроде люминисцентной тени.
Чтобы все это заработало вместе с отраженным светом (а по умолчанию с отраженным светом эти эффекты не работают), необходимо в строку запуска компилятора HLRAD добавить следующий параметр -customshadowwithbounce.

• Если вместе с параметром -customshadowwithbounce Вы также используете параметр -sparse, то процесс компиляции может сильно затянуться. Рекомендуется вместе с параметром -customshadowwithbounce использовать параметр -nomatrix ;
• Параметр -customshadowwithbounce работает только с обычными (greyscale) тенями, т.е. с цветными не работает.

Конфигурационный WAD-файл

А вот и существенное нововведение по сравнению с обычными компиляторами ZHLT — конфигурационный WAD-файл.
Конфигурационный WAD-файл используется для хранения различных конфигураций текстурных файлов. Например, Вы можете создать конфигурацию текстур для одной Вашей карты и другую конфигурацию (записать другие текстуры) для другой.
Конфигурационный WAD-файл с именем WAD.CFG должен находиться в одной директории с компиляторами ZHLT Custom Build.
Предположим, что одновременно Вы создаете несколько карт, которые используют различные текстурные WAD-файлы. Что Вы вынуждены делать? Поработав над одной картой, Вы открываете параметры редактора и отключаете неиспользуемые другой картой текстуры и наоборот подключаете используемые. Поработав какое-то время со второй картой, Вы решаете вернуться и доделать первую карту, и опять открываете параметры редактора, отключаете-подключаете текстуры... — в общем очень неудобно.
Справиться с этой проблемой помогает конфигурационный WAD-файл.
Ниже мы приводим синтаксис этого файла.

• имя_конфигурации
  {
  c:\путь\wad1.wad
  c:\путь\wad2.wad
  ...
  include c:\путь\wad3.wad
  }

где:

• Имя_конфигурации — любое имя (удобно называть конфигурацию по названию карты).
  c:\путь\wad1.wad — полный путь к первому WAD-файлу
  c:\путь\wad2.wad — полный путь ко второму WAD-файлу
  include c:\путь\wad3.wad — параметр "include" означает, что текстуры из данного WAD-файла будут включены в BSP-файл карты.

Вы можете использовать любое количество конфигураций и записей о WAD-файлах.
Рассмотрим небольшой пример:
Предположим, что на нашей карте DE_MAP используются 3 стандартных WAD-файла (halflife.wad, liquids.wad и decals.wad) и один нестандартный (MAP.WAD), который мы изготовили самостоятельно. Тогда наша запись в файле WAD.CFG будет выглядеть следующим образом:

• MAP
  {
  c:\Games\Half-Life\valve\halflife.wad
  c:\Games\Half-Life\valve\liquids.wad
  c:\Games\Half-Life\valve\decals.wad
  include c:\Wads\map.wad
  }

Перед компиляцией необходимо добавить следующий параметр к компилятору HLCSG: -wadconfig MAP.
Таким образом, получается, что во время компиляции, HLCSG увидит, что надо использовать конфигурацию по имени MAP, считает информацию из файла WAD.CFG и затем уже будет использовать текстуры из стандартных WAD-файлов, и включит текстуры из нашего WAD-файла (MAP.WAD).

Путь к файлу wad.cfg

Параметр -wadcfgfile позволяет вручную указать путь к файлу WAD.CFG (по умолчанию компиляторы ищут этот файл в своей директории или в директории с Half-Life). Если WAD.CFG находится у Вас в какой-то другой директории, то необходимо добавить параметр -wadcfgfile путь_к_файлу в строку запуска компилятора HLCSG.

Поддержка объекта info_compile_parameters

Данная версия утилит поддерживает использование на карте объекта info_compile_parameters. В свойсвах этого объекта можно указать параметры компиляции, вместо их указания в командной строке. Если у Вас нет данного объекта, информацию о нем необходимо дописать в FGD-файл. О том, как это сделать и вообще более подробно об объекте Вы можете узнать из раздела "Энтити".

Поддержка объекта info_texlights

Данная версия утилит поддерживает использование на карте объекта info_texlights. Данный объект используется вместо RAD-файла, в который записывается информация о светящихся текстурах на карте. Подробнее об этом объекте Вы можете прочитать в разделе "Энтити".

Переключаемые светящиеся текстуры

Отличное нововведение в версии ZHLT Custom Build 1.7 — переключаемые светящиеся текстуры. Теперь любая светящаяся текстура может мигать, пульсировать или просто быть включена/выключена, как обычная лампочка. Раньше это было не возможно, но сейчас с выходом Сustom Build 1.7, это стало реально.
Секрет заключается в следующем, в FGD-файл, в свойства брашевых энтити-объектов (например, func_wall, как самый распространенный) необходимо добавить следующий код:

style(choices) : "Texlight style" : 0 =
	[
		0 : "Normal"
		-3: "Grouped"
		10: "Fluorescent flicker"
		2 : "Slow, strong pulse"
		11: "Slow pulse, noblack"
		5 : "Gentle pulse"
		1 : "Flicker A"
		6 : "Flicker B"
		3 : "Candle A"
		7 : "Candle B"
		8 : "Candle C"
		4 : "Fast strobe"
		9 : "Slow strobe"
		12: "Underwater"
	]

Добавив этот код к объекту func_wall, в редакторе можно будет выбрать стиль для данного объекта.
Стиль Grouped предназначен для создания светящихся текстур, которые можно включить/выключить, как лампочку.
Итак, создаем func_wall, окрашиваем его светящейся текстурой (светящейся текстура станет только, если ее прописать в специальном RAD-файле, который затем подключить при компиляции), даем func_wall имя (например, WALL-1), ставим стиль "Grouped" и (ВНИМАНИЕ!) создаем около func_wall обычную лампочку light с таким же именем (WALL-1). Ставим яркость лампочки в 0.01.
В итоге компилятор, просчитывающий освещение, а это HLRAD будет думать, что свет излучает лампочка (light), а не светящаяся текстура. Чтобы выключить или включить освещение от текстуры необходимо активировать лампочку (light). Всего этого можно было бы не делать, если бы CS поддерживал переключаемые светящиеся текстуры, как это сделано, например, в Spirit of Half-Life.

Параметр -subdivide

Данный параметр компилятора HLBSP позволяет изменить шаг, с которым поверхность карты делится на полигоны. По умолчанию через каждые 240 текстурных пикселей делается разрез, это означает, что сторона объекта с наложенной текстурой 256х256 пикселей будет разбита на 4 полигона (1 большой полигон с размером 240х240 пикселей и 3 маленьких), что в итоге может привести к существенному увеличению общего количества полигонов на карте.
Установив значение параметра -subdivide 256 мы значительно уменьшим количество полигонов на карте, при условии, что мы используем текстуры 256х256 пикселей. Это происходит потому, что теперь поверхность карты будет разрезаться через каждые 256 пикселей текстуры, а значит сторона объекта будет создавать не 4, а всего лишь 1 полигон.
Если мы будем использовать текстуры более 256 пикселей, то стоит попробовать еще увеличить параметр "-subdivide". Однако, как сообщает разработчик ZHLT Custom Build, при увеличении этого параметра, могут возникнуть проблемы с запуском карты в режиме Software. Но, учитывая, что Software режим используется крайне редко (и вообще mustdie :), то можно смело использовать этот прекрасный параметр.
Но здесь существует одно очень большое "НО" — параметр не работает :) Точнее, в некоторых случаях карта компилируется нормально, в других же компиляция прекращается, и выдается сообщение об ошибке на стадии просчета освещения (HLRAD). Так было по крайней мере с ZHLT Custom Build 1.7. Ждем улучшений.

Максимальное vis-расстояние

Максимальное визуальное расстояние (Maximum Distance Visibility — MDV) это новая функция, которая помогает справиться с проблемой отрисовки объектов на дальних расстояниях на Вашей карте. Ведь нет никаких гарантий, что все участки карты будут отрисованы в игре (некоторые дальные участки могут начать скрываться). Используя данный параметр, Вы будете уверены, что карта будет точно отрисована в пределах максимального визуального расстояния (MDV).
Чтобы использовать эту функцию необходимо вписать параметр -maxdistance # в строку запуска HLVIS, где # — максимальное расстояние в юнитах.
Однако существует один побочный эффект при использовании MDV. Работа компилятора HLRAD по оптимизации освещения сильно зависит от размера visibility matrix (размера визуальной матрицы). В итоге обычный RAD-компилятор может как бы "обрезать" свет. Но нам волноваться нечего и вот почему.
Данную проблему решает использование вместо стандартного RAD-компилятора, компилятора HLRAD специальной версии от Адама Фостера (Adam Foster). А в состав утилит ZHLT Custom Build включен компилятор HLRAD как раз от Адама Фостера.
Если параметр -maxdistance у компилятора HLVIS установлен, то будет создан дополнительный файл *.VDT с информацией о размере реальной визуальной матрицы (без использования MDV). Затем этот файл используется компилятором HLRAD для создания правильного освещения карты.

Новые параметры компиляторов ZHLT Custom Build

Данные параметры применимы лишь к улучшенной версии компиляторов ZHLT Custom Build и не будут работать с обычными ZHLT. Естественно, что к улучшенным компиляторам можно применять и все остальные параметры, которые работают в официальных утилитах. Об этих парметрах Вы можете прочитать в соответствующей статье из данной Главы.
HLCSG

• -nonulltex — Отключает использование NULL-текстур;
• -noclipeconomy — Отключает режим экономии clipnode-плоскостей;
• -wadconfig имя_конфигурации — Указывает имя конфигурации wad-файлов в файле wad.cfg;
• -wadautodetect — Включает режим автообнаружения wad-файлов;
• -wadcfgfile путь_к_файлу_wad.cfg — Позволяет вручную указать путь к файлу wad.cfg, по умолчанию компиляторы ищут этот файл в своей директории и в директории с Half-Life;

HLBSP

• -nonulltex — Отключает использование NULL-текстур;
• -subdivide х, где х — значение от 240 до 512; — Изменяет шаг, с которым карта разрезается на полигоны (по умолчанию 240);

HLVIS

• -maxdistance х, где х — расстояние в юнитах; — Устанавливает максимальное vis-расстояние;

HLRAD

• -colourgamma r g b — Устанавливает значение гаммы (gamma) в формате r, g, b (красный, зеленый, синий);
• -colourscale r g b — Устанавливает значение lightscale в формате r, g, b (красный, зеленый, синий);
• -colourjitter r g b — Добавляет шум (помехи) различных цветов, используется для размытия (dithering);
• -jitter r g b — Добавляет шум (помехи) монохромного (одного) цвета, используется для размытия (dithering);
• -nodiffuse — Выключает diffuse hack для объекта light_environment;
• -nospotpoints — Выключает точечный режим отображения объекта light_spot;
• -softlight r g b d — Устанавливает значения для backwards-light hack (хака для отраженного света);
• -customshadowwithbounce — Позволяет использовать полупрозрачные тени для энтити-объектов при отраженном свете;

NETVIS

• Нет изменений

В данной статье описаны все параметры для компиляторов ZHLT. В улучшенных компиляторах ZHLT Custom Build помимо этих параметров используются некоторые дополнительные. О них Вы можете прочитать в одной из предыдущих статей об улучшенной версии ZHLT. Данная статья является переводом официального документа, идущего вместе с ZHLT. Статья взята по адресу: http://alexnd.narod.ru/. Благодарим автора за отличный перевод!
Каждый из четырех компиляторов имеет как свои собственные параметры, так и 9 общих, которые применимы к любому из компиляторов.
Содержание:

• 1. HLCSG (8 параметров + 9 общих)
  • -nowadtextures
  • -wadinclude file
  • -noclip
  • -onlyents
  • -noskyclip
  • -tiny #
  • -brushunion #
  • -hullfile file
  • +общие параметры

• 2. HLBSP (6 параметров + 9 общих)
  • -leakonly
  • -subdivide #
  • -maxnodesize #
  • -notjunc
  • -noclip
  • -nofill
  • +общие параметры

• 3. HLVIS (2 параметра + 9 общих)
  • -fast
  • -full
  • +общие параметры

• 4. HLRAD (25 параметров + 9 общих)
  • -sparse
  • -nomatrix
  • -extra
  • -bounce #
  • -ambient r g b
  • -maxlight
  • -circus
  • -nopaque
  • -smooth #
  • -chop #
  • -texchop #
  • -notexscale #
  • -coring #
  • -dlight #
  • -nolerp
  • -dscale
  • -fade #
  • -falloff #
  • -scale #
  • -gamma #
  • -sky #
  • -lights file
  • -noskyfix
  • -incremental
  • -dump
  • +общие параметры

• 5. Общие для всех компиляторов параметры (9 параметров)
  • -texdata #
  • -chart
  • -low / -high
  • -nolog
  • -threads #
  • -estimate
  • -verbose
  • -noinfo
  • -dev #

---

1. HLCSG

Пример запуска: hlcsg.exe -estimate -nowadtextures karta.map
-nowadtextures
Включить все используемые текстуры в конечный файл с картой (.bsp). Эта опция бесполезна с введением параметра -wadinclude и оставлена только для обратной совместимости.
-wadinclude файл
Включить текстуры из указанного .wad-файла в конечный файл с картой (.bsp). Этот параметр позволяет включать текстуры из указанного .wad-файла в конечный файл (.bsp). Позволяет использовать частичное совпадение имени, не реагирует на регистр букв, способен распознавать не только имена файлов, но и названия папок. Если необходимо вставить несколько файлов с текстурами, необходимо указать несколько параметров -wadinclude, по одному на каждый файл с текстурами. Только текстуры, действительно используемые в карте, удут вставлены в .bsp-файл.
-noclip
Не создавать "ограничительную" область для карты. Карты в Half-life, как и Quake1, имеют 4 замкнутые области (hulls), используемые движком игры: 1 область — видимая (для отрисовки видимых участков карты), и 3 области — ограничительные (для ограничения движения игроков на карте). Этот параметр позволяет отключить создания ограничительных областей на карте, делая ее "воздушной". Игрок не только сможет ходить сквозь стены, но и провалиться сквозь землю (если гравитация включена). Полезно для экономии времени при тестовой компиляции. Наблюдать за сделанными изменениями на карте можно будет только в режиме Зрителя (Spectator).
-onlyents
Обновить значение параметров объектов из исходника (.map) в готовой карте (.bsp) Данная опция обновляет объекты в уже созданной карте (файл .bsp). В большинстве случаев, однако, объекты нельзя редактировать. Добавление или удаления объекта может дезорганизовать остальные объекты, "испортив" брашевые объекты, особенно триггеры.
-noskyclip
Отключить автоматическое ограничение карты небом. По умолчанию hlcsg ограничивает доступное игроку пространство брашами с текстурой CLIP, а также удаляет все полигоны за пределами карты или "внутри" неба, что ускоряет выполнение программ hlvis и hlrad.
-tiny #
Установить минимальную площадь браша, меньше которой браши удаляются. Поверхности с маленькой площадью удаляются при компиляции. По умолчанию порог составляет 0,5 квадратных "юнита" (единица измерения в Half-Life, редакторе Worldcraft/Hammer). Довольно опасно удалять поверхности таким образом, так как карта может стать нерабочей, могут возникнуть ошибки LEAF PORTAL SAW INTO LEAF или HALL-OF-MIRRORS (зеркальный коридор — эффект, когда игрок выходит за границы карты в режиме наблюдателя).
-brushunion #
Установить порог для сообщений о пересекающихся брашах. Эта опция дана для отладки. Ее значение устанавливает процентное соотношение объемов пересекающихся брашей, при достижении которого выдается предупреждение. Для начала неплохо использовать довольно высокое значение (95% и выше), так как уменьшение этого параметра приводит к сотням и даже тысячам сообщений. Для каждого пересечения брашей выводится информация о номерах брашей и о проценте перекрытия. Данная опция выключена по умолчанию; ее включение значительно замедляет работу hlcsg.
-hullfile
Загрузить собственный файл с информацией об ограничительных областях. Загружает собственный файл с информацией об ограничительных областях. Файл состоит из 3 строк с 3 числами в каждой, которые обозначают размеры области по осям X Y Z. Эта опция дана для авторов и мапперов определенных модов для Half-life, так что вам не следует слишком беспокоиться о ней.

---

2. HLBSP

Пример запуска: hlbsp.exe -estimate karta.map
-leakonly
Запустить HLBSP только для поиска "утечек" (ошибка LEAK). Если Вы знаете, что карта имеет "дыры" (LEAK), используйте данный параметр для поиска дыр и создания специального файла с информацией о дырах (.pts-файл).
-subdivide #
Установить размер делителя поверхностей. Поверхности в Half-life разбиваются на полигоны указанного в данном параметре размера (в юнитах). По умолчанию и максимальное значение параметра равно 240. Однако улучшенные компиляторы ZHLT Custom Build позволяют увеличить данный параметр, но при этом практически всегда возникают всевозможные ошибки :) Так было, по крайне мере, до версии ZHLT Custom Build 1.7. Обычно не стоит уменьшать этот параметр, так как это ведет к увеличению r_speeds.
-maxnodesize #
Установить максимальный размер портала. Этот параметр изменяет максимальный размер портала. Его уменьшение приводит к разбивке карты на большее количество порталов и, как следствие, к увеличению значения r_speeds. Однако r_speeds может фактически быть снижен за счет более быстрого или более точного расчета видимых участков на карте в процессе выполнения vis.
-notjunc
Не разбивать браши на более мелкие при соприкосновении (Т-соединения)(не для окончательной компиляции). Эта опция для отладки/настройки и не должна использоваться при обычной компиляции.
-noclip
Не обрабатывать ограничительную область (не для окончательной компиляции). Этот параметр — продолжение опции -noclip в компиляторе hlcsg. Он говорит hlbsp, что hlcsg скомпилировал карту с опцией -noclip и что не следует обрабатывать ограничительные области, так как они отсутствуют в .bsp файле.
-nofill
Не "заполнять" внешний мир (игнорирует утечки LEAK) (не для окончательной компиляции). Этот параметр позволяет не "заполнять" пустоту "снаружи" карты, в результате чего все наружные поверхности сохраняются. Не стоит запускать расчет освещения для карты, скомпилированной таким образом, хотя vis будет работать нормально.

---

3. HLVIS

Пример запуска: hlvis.exe -estimate -full karta.map
-fast
Ускоренный анализ (не для окончательной компиляции). Ускоренный анализ видимых областей на карте удобен для быстрого обследования создаваемой карты. Однако значение r_speeds оставляет желать лучшего, равно как и число объектных полигонов (epoly — entity polygons). Карту можно "осветить" с помощью hlrad, однако качество освещения и время компиляции освещения такой карты "пострадают". Разрабатываемую карту нужно регулярно компилировать с полным анализом видимости, так как ускоренный анализ может помешать вам заметить внезапное увеличение времени полного анализа, что свидетельствует о неправильной архитектуре и большому результирующему значению r_speeds.
-full
Полный анализ. Этот параметр задействует дополнительный блок расчета видимых областей на карте, что позволяет уменьшить количество ошибок по сравнению с обычным анализом (hlvis без параметров). Время компиляции увеличивается примерно на 30%. Значение r_speeds остается примерно таким же, с некоторым уменьшением в одних местах карты, и увеличением - в других (в основном из-за устранения ошибок при анализе).

---

4. HLRAD

Пример запуска: hlrad.exe -estimate -chart -extra -smooth 100 -dscale 1 -bounce 4 karta.map
-sparse
Задействовать алгоритм с матрицей с ограниченной памятью. Hlrad разбивает карту на множество блоков — патчей, из которых, в последствии, создается матрица для расчета освещения на карте. Изначально матричный алгоритм ограничен 65535 "патчами" или блоками. Использование памяти этим алгоритмом растет в геометрической прогрессии по мере увеличения количества патчей (требуемая память в байтах вычисляется как кол-во патчей в квадрате деленное на 16. Данный параметр hlrad задействует алгоритм сжатия матрицы, который за счет дополнительного использования процессора позволяет преодолеть предел в 65535 патчей, а также снизить потребность в оперативной памяти до 10% от объема, требуемого для обычного матричного алгоритма.
-nomatrix
Отключить использование матрицы полностью В связи с тем, что использование "урезанной" матрицы (параметр -sparse) приводит к сжатию данных, требуется четкая синхронизация процессов, чего сложно добиться на машинах с количеством процессоров более 2-х. Опция -nomatrix была добавлена для решения такой проблемы. Однако добавление "непрозрачных брашевых объектов" в ZHLT 2.2 очень сильно повлияло на производительность данного метода компиляции освещения в сторону ухудшения. Данный метод не подразумевает использование матрицы вообще, поэтому и не требует памяти для хранения такой структуры данных.
-extra
Включить более точный расчет освещения (9 point oversampling). Позволяет компилировать карту с наиболее реальным и красивым освещением.
-bounce #
Установить количество "отражений" света. Этот параметр устанавливает число раз отражений света. К моменту выполнения данной операции все данные уже предварительно посчитаны, так что дополнительное число отражений не займет много времени. Увеличение числа отражений приводит к сглаживанию теней и освещению темных мест на карте более реальным образом.
-ambient r g b
Установить освещенность окружающего мира (от 0.0 до 1.0, r g b). Эта опция устанавливает минимальную "яркость" каждой поверхности карты для того, чтобы ни одна из них не была полностью черной. Параметры соответствуют красному, зеленому и синему со значениями от 0.0 до 1.0.
-maxlight #
Установить максимальную интенсивность света. Этот параметр используется для ограничения яркости на хорошо освещенных участках, делая карту темнее.
-circus
Разрешить режим 'circus' для обнаружения неосвещенных участков. Это отладочная опция, которая заменяет все черные точки на любой поверхности на случайный яркий цвет. Для расчетов принимается во внимание только прямое освещение и игнорируется отраженный свет.
-nopaque
Отключить блокирование света обектами. Это отладочная опция, которая позволяет отключать блокирование света объектами (отбрасывание теней), у которых установлены флаги свещения (2). Блокирование света объектами замедляет работу hlrad, поэтому данная опция полезна для отладочной/промежуточной компиляции.
-smooth #
Установить порог сглаживания (в градусах). По умолчанию hlrad освещает каждую поверхность отдельно, что приводит к визуальному разграничению поверхностей в готовой карте. Если же угол между двумя поверхностями меньше указанного в этом параметре, расчет освещения будет сделан с использованием технологии сглаживания (имитации плавного перехода — округлости — между поверхностями).
-chop #
Установить размер патча для обычных текстур. Каждая поверхность разбивается на сетку с шагом, равным размеру патча. Получаемые блоки используются для расчета освещения поверхности. Увеличивая размер патча можно ускорить выполнение hlrad и уменьшить потребность в памяти, однако это приведет к потере качества на готовой карте (неровные, угловатые, нереалистичные тени). Уменьшение же размера патча наоборот приведет к более качественному освещению карты, но потребует больше ресурсов компьютера.
-texchop #
Установить размер патча для светящихся текстур. Светящиеся поверхности (текстуры описаны в lights.rad и испускают свет) разбиваются на блоки другого размера, нежели обычные поверхности. Обычно, размер блоков должен быть равен половине размера блока обычной поверхности (-chop) для того, чтобы освещение выглядело хорошо. Включение параметра -extra автоматически устанавливает значение данного параметра равным половине от значения -chop.
-notexscale #
Не изменять размеры патчей при изменении размеров текстур. По умолчанию hlrad использует данные о масштабе текстур при создании сетки и разбиении поверхностей на освещаемые патчи. Этот параметр отключает масштабирование патчей для масштабируемых текстур, что почти всегда приводит к увеличению числа патчей, так как на многих картах текстуры стен увеличены в 2-3 раза.
-coring #
Установить минимальный порог освещения. Эта опция управляет количеством требуемого освещения поверхности, чтобы она не была полностью черной.
-dlight #
Установить максимальную яркость прямого (неотраженного) света. Эта опция аналогична параметру -maxlight за исключением того, что она позволяет "нормализовать" свет вместо того, чтобы "обрезать" излишнюю яркость.
-nolerp #
Параметр nolerp отключает смешивание значений отраженного света для близлежащих патчей (использует ближайшее значение вместо этого). Добавлено автором для внутреннего тестирования кода освещения карты.
-dscale #
Установить множитель для освещения. Из-за ошибки в оригинальной программе компиляции освещения qrad, расчет прямого освещения во время компиляции производился дважды. Для создания наиболее реалистичных карт необходимо производить такой расчет только один раз, однако в связи с тем, что в течение длительного времени карты создавались с указанием этого параметра вручную, он был оставлен и в этой версии компиляторов. Использование значения "1" приведет к созданию наиболее реалистичных теней и освещения. Однако, так как этот параметр изменяемый, он имеет несколько других применений. Так, использование значения "0" полностью удалит прямое освещение из карты и оставит только отраженный свет. Таким образом, мы получили возможность проверять качество только отраженного света (противоположность параметру -bounce 0). Использование значений "3-4" создаст очень сильный контраст между тенями и освещенными участками, что может пригодиться на картах с пустынями или арктическими льдами.
-fade #
Установить уровень затемнения для всех источников света на карте (большее значение приводит к меньшему распространению света). Этот параметр является коэффициентом к формуле расчетов затемнения (1/[квардрат расстояния]). С его помощью можно регулировать расстояние, на которое распространяется прямой свет на карте. Отдельные объекты освещения могут иметь собственные значения затемнения. Данный параметр влияет только на прямое освещение, так как отраженный свет всегда имеет формулу затемнения (1/[квардрат расстояния]).
-falloff #
Установить формулу расчета затемнения (1 = 1/расстояние, 2 = 1/[квардрат расстояния]). Эта опция позволяет изменить формулу расчета затемнения.
-scale #
Установить множитель для конечного освещения на карте. Этот параметр влияет на конечные значения источников света после того, как все расчеты освещения выполнены. Уменьшение этого параметра приводит к затемнению карты, увеличение — к осветлению.
-gamma #
Установить глобальное значение цветов. Эта опция влияет на конечные откомпилированные данные, внося коррекцию по цветности.
-sky #
Установить влияние солнечного света на затененные поверхности. Многие поверхности на карте обращены к небу, но находятся в тени других объектов. Эта опция регулирует, какое значение "солнечного" ("небесного") освещения должно быть добавлено к затененной поверхности.
-lights имя_файла.rad
Указать файл со светящимися текстурами вручную (.rad файл). Один .rad файл можно добавить вручную, помимо автоматически используемых файлов lights.rad и <имя_карты>.rad
-noskyfix
Отключить глобальное применение объекта light_environment. ZHLT 2.1 добавил более простую в использовании систему "небесного" освещения с помощью объекта light_environment. По новым правилам на карте требуется только один объект light_environment, причем его месторасположение не играет роли - все небо начинает излучать свет. Параметр -noskyfix отключает это поведение и задйствует старый алгоритм, когда на разных участках карты требовались отдельные объекты light_environments для правильного освещения наружных участков карты.
-incremental
Использовать или создать файл с данными об освещении на карте. Это удобная отладочная опция для настройки освещения карты, особенно для медленных машин с ограниченной системной памятью. Такие этапы компиляции освещения как BuildVisLeafs, MakeScales и SwapTransfers можно пропустить при втором и последующих запусках hlrad используя этот параметр. Использование файла с данными об освещении требует выполнения несложных, четких операций:

• Запустите hlrad как обычно, включив параметр -incremental. Карта скомпилируется и осветится нормально, вдобавок создастся файл с данными об освещении (размером до нескольких десятков мегабайт).
• Точечные объекты освещения (light, light_spot, light_environment) могут быть изменены произвольным образом (передвинуты, изменены яркость, цвет и т.д.)
• Значения объектов обновляются в файл .bsp с помощью компилятора hlcsg с параметром -onlyents.
• Запустите hlrad как обычно опять с параметром -incremental. Необходимо сохранить точно такие же значения параметров -extra, -chop #, -texchop #, -notexscale #. Другие параметры можно менять как угодно.

-dump
Сохранить информацию о патчах для отладки hlrad. Это опция для разработчиков ZHLT, для сохранения информации о патчах, созданных на этапе разбиения карты на блоки и проверки правильности такого разбиения.

---

5. Общие параметры

-texdata #
Изменяет максимальный размер памяти, выделяемый для текстур (в Кб). Half-life был построен с лимитом текстурной памяти в 2Мб, так же как и Opposing Force. Утилиты ZHLT по умолчанию имеют лимит в 4Мб. Такой объем памяти, выделяемый для текстур, может быть великоватым в совокупности с текстурами моделей, графикой на экране, и т.д., особенно для владельцев с устаревшими видеокартами типа Voodoo 1 и 2.
-chart
Показывает статистику bsp. Этот параметр заставляет программы выдавать на экран статистику bsp перед тем, как записать в файл. Наиболее полезно применять данную опцию с программами hlrad и hlvis. Утилита ripent всегда отображает статистическую диаграмму.
-low / -high
Запускает программу с низким/высоким приоритетом. Установка низкого приоритета (-low) очень удобна, так как вы можете выполнять несколько других приложений одновременно без ощутимого воздействия компиляторов на производительность системы. Рекомендуется использовать при наличии достаточного количества оперативной памяти.
-nolog
Не создавать файлы отчета. Этот параметр отключает автоматическое создание файлов отчета (.log) и файлов с сообщением об ошибке (.err)
-threads #
Вручную указать количество процессов. Эта опция используется для указания количества процессов, в основном, на машинах с операционной системой, отличной от Windows, когда невозможно автоматически определить количество процессоров. На машинах с операционной системой Windows эта опция позволяет задать меньшее число процессов, чем имеющееся количество процессоров.
-estimate
Показывает расчетное время компиляции. Этот параметр заменяет стандартный индикатор прогресса (10...20...) на указатель с расчетным временем компиляции, количеством выполненной работы и оставшейся для выполнения. Предсказание времени часто бывает неточным, однако в целом такой индикатор более подробен, нежели стандартный.
-verbose
Компилировать с дополнительными сообщениями. Большинство утилит выдают "второстепенные" сообщения и информацию, если установить данную опцию. С развитием утилит версий 2.х, такие сообщения, связанные с работой самих утилит, отображаются при включенном параметре -dev, тогда как сообщения, связанные с картостроением, отображаются при включенном параметре -verbose.
-noinfo
Не показывать настройки утилит. ZHLT 2.1 добавил свойство вывода на экран текущей конфигурации каждой утилиты перед началом работы. В таблице настроек показывается текущее значение и значение по умолчанию каждого параметра. Из-за большого объема текстовой информации это может вызвать проблемы компиляции, например, в Worldcraft, так как последний иногда зависает от большого объема текста, скроллирующегося в его окне компиляции.
-dev #
Компилировать с включенными сообщениями разработчика. Внутренние отладочные сообщения в утилитах ZHLT регулярно добавляются в комплект инструментов. Данный параметр позволяет регулировать степень отображения таких сообщений, и имеет значения начиная с 0 (не показывать), и кончая 6 (показывать даже избыточные сообщения). Данная опция практически не используется, за исключением случаев по запросу разработчика для диагностики компьютера пользователя.

В этой статье мы рассказываем о компиляции BAT-файлом, компиляции в редакторе Hammer (Worldcraft) и компиляции при помощи графической оболочки для ZHLT программы Batch Compiler. Также мы рассказываем о нескольких типах компиляции (тестовой и окончательной).
Содержание статьи:

• Полная компиляция
• Тестовая компиляция
• Компиляция BAT-файлом
• Удаление лишних файлов после компиляции
• Компиляция в редакторе Hammer
• Компиляция в программе Batch Compiler

ЧАСТЬ 1. Типы компиляции

Так как компиляция процесс довольно длительный, а результат проделанных изменений на карте лучше смотреть как можно чаще (чтобы иметь возможность вовремя что-то исправить), то появляется необходимость как-то уменьшить время компиляции. А как уменьшить время компиляции? Можно купить более мощный компьютер, а можно "поиграть" с параметрами компиляции. Во втором случае карта довольно ощутимо потеряет в качестве (будет похуже освещение, побольше тормозов и т.п.), однако для тестовой компиляции это прекрасно подходит.
Необходимость уменьшения времени компиляции привела к появлению тестового режима компиляции. При использовании тестового режима указываются параметры, существенно уменьшающие время компиляции, но при этом ухудшается качество итоговой карты. Также при тестовой компиляции возможно использование всего двух программ-компиляторов из четырех.
Итак, существует 2 типа компиляции:

• Полная компиляция
• (максимальное качество карты, но бОльшее время компиляции);
• Тестовая компиляция
• (время компиляции существенно меньше, но качество карты на порядок хуже).

1.1 Полная (окончательная) компиляция

Если нам необходимо получить максимально качественную карту (окончательную версию) или, если время компиляции особого значения не имеет ("можем и подождать"), то полный режим компиляции, то, что нам нужно. Мы рекомендуем проводить полную компиляцию карты не только для окончательного ее варианта, но также для проверки качества освещения и определения скорости отрисовки карты.
При полной компиляции задействованы все 4 компилятора: HLCSG, HLBSP, HLVIS, HLRAD.
Самый ресурсосберегающий способ компиляции — компиляция BAT-файлом. При этом способе компиляции создается BAT-файл (по сути простой текстовый), в котором записываются очередность и параметры запуска компиляторов.
Ниже приведенны строки, которые нужно скопировать в Блокнот и сохранить файл как full.bat (или с любым другим названием, но с расширением именно *.bat). Затем этот файл необходимо поместить в директорию с компиляторами, туда же скопировать карту в формате MAP и запустить full.bat.

1 строка: убирает сообщения с экрана (к компиляции не относится);
2 строка: сюда пропишите путь к директории Half-Life (компиляторы и HL должны находится на 1 диске);
3 строка: имя Вашей карты (не забудьте расширение .map на конце);
4 строка: запуск компилятора HLCSG;
5 строка: запуск компилятора HLBSP;
6 строка: запуск компилятора HLVIS с параметром -full (полная оптимизация карты);
7 строка: запуск компилятора HLRAD с параметром -extra (просчет освещения с наилучшим качеством).
Подробнее об этих и других параметрах Вы можете прочитать в соответствующей статье из данной Главы.

1.2 Тестовая компиляция

Тестовая компиляция применяется, когда не хочется ждать много времени, чтобы всего лишь проверить правильность работы энтити-объектов (все ли двери закрываются, ездиет ли машина, опускается ли лифт и т.д.) или просто с целью побегать по карте, потестировать геймплей, засечь время появления команд в разных местах — в этом случае качество освещения и оптимизации отходят на второй план.
При тестовой компиляции возможен запуск лишь первых двух компиляторов: HLCSG и HLBSP, то есть можно не оптимизировать карту (HLVIS) и не просчитывать освещение (HLRAD). Но мы все-таки рекомендуем запускать все четыре компилятора, просто установив для последних двух "щадящие" параметры (см. ниже).
Ниже приведенны строки, которые нужно скопировать в Блокнот и сохранить файл как fast.bat (или с любым другим названием, но с расширением именно *.bat). Затем этот файл необходимо поместить в директорию с компиляторами, туда же скопировать карту в формате MAP и запустить fast.bat.

Отличие от полной компиляции наблюдается лишь в последних двух строках.
1 строка: убирает сообщения с экрана (к компиляции не относится);
2 строка: сюда пропишите путь к директории Half-Life (компиляторы и HL должны находится на 1 диске);
3 строка: имя Вашей карты (не забудьте расширение .map на конце);
4 строка: запуск компилятора HLCSG;
5 строка: запуск компилятора HLBSP;
6 строка: запуск компилятора HLVIS с параметром -fast (быстрая оптимизация карты);
7 строка: запуск компилятора HLRAD с параметром -chop 128 (быстрый более грубый просчет освещения).

ЧАСТЬ 2. Способы компиляции

Итак, карты, как мы уже знаем, можно компилировать BAT-файлом или программами-оболочками для ZHLT (редактор карт, кстати, тоже можно назвать оболочкой для ZHLT). Нужно понимать, что в любом случае карту компилируют утилиты ZHLT, а не BAT-файл, редактор карт или любая другая программа (ну, это так... на всякий случай :)

2.1 Компиляция BAT-файлом

Собственно, компиляцию BAT-файлом мы уже рассмотрели в первой части статьи. Вы уже можете создать два пакетных файла для быстрой и полной компиляции. Но, как гласит народная мудрость: "Повторение — мать учения", поэтому остановимся на этом способе еще чуть-чуть.
BAT-файл — это файл текстового формата, при запуске которого, выполняются записанные в нем команды (например, копирование или удаление файлов). Чтобы создать BAT-файл надо скопировать в Блокнот команды запуска компиляторов, приведенные в этой статье и сохранить файл под любым именем с расширением BAT. Или можно сохранить файл как обычный *.TXT, а затем поменять расширение на *.BAT.
При использовании BAT-файла его необходимо поместить в директорию с компиляторами, например, "D:\Hammer\ZHLT". Туда же необходимо скопировать свою карту в формате MAP.
Мы рекомендуем создать два BAT-файла для двух разных типов компиляции (полной и тестовой). Для удобства их можно назвать full.bat и fast.bat, соответственно.

Удаление лишних файлов после компиляции

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

	*.BSP — готовая карта (необходимо скопировать в папку "cstrike/maps")
	*.MAP — исходник карты в формате MAP (если есть резервная копия, то можно удалить)
	*.ERR — файл создается, если на карте есть ошибки
	*.LOG — файл с информацией о ходе компиляции (так же в него записываются ошибки)
	*.LIN — файл нужен для нахождения ошибки LEAK, если таковая имеется на карте
	*.PTS — то же, что и выше
	*.P0  — можно удалить
	*.P1  — можно удалить
	*.P2  — можно удалить
	*.P3  — можно удалить
	*.PRT — можно удалить
	*.WIC — можно удалить
		

Чтобы не удалять каждый раз лишние файлы вручную, предлагаем автоматизировать это. Нужно добавить несколько строк в BAT-файл (мы приводим пример с файлом для полной компиляции).
Обратите внимание: в строке, где указывается имя карты, расширения .map уже нет.

Благодаря команде del мы удаляем лишние файлы, а командой copy копируем готовую карту в папку с игрой (подправьте путь на свой).

2.2 Компиляция в редакторе Hammer/Worldcraft

Редактор Hammer позволяет проводить как тестовую, так и полную компиляцию карты. Чтобы иметь возможность компилировать из Hammer'а, необходимо подключить к нему компиляторы ZHLT. Как это сделать Вы можете прочитать в статье "Компиляторы ZHLT".
Мы бы не сказали, что компилировать карты в редакторе легче и удобнее, чем BAT-файлом, однако многие начинающие мапперы с упорством спрашивают, как компилировать карты именно в редакторе :) К счастью, все они вскоре переходят на компиляцию BAT-файлом, потому что это проще и требует меньше cистемных ресурсов.
Если компиляторы ZHLT уже подключены к редактору, можно приступать.
Нажимаем F9 в редакторе. Перед нами появляется небольшое окошко с параметрами компиляции.
Это режим "Normal", в котором мы можем выбрать минимум параметров компиляции.
Run CSG
No — не запускать HLCSG
Normal — обрабатывать все объекты на карте
Entities only — обновить информацию о свойствах энтити-объектов
Run BSP
No — не запускать HLBSP
Normal — обычный режим
Run VIS
No — не запускать HLVIS (не для окончательной компиляции)
Normal — обычный режим
Fast — быстрая оптимизация карты (не для окончательной компиляции)
Run RAD
No — не запускать HLRAD (не для окончательной компиляции)
Normal — обычный режим
Extra — включает наиболее качественный просчет освещения (рекомендуется)
Don't run the game — не запускать карту сразу же после компиляции
Save visible objects only — обрабатывать только видимые (нескрытые) объекты
Expert — переключение в расширенный режим компиляции, где параметры задаются вручную.
2. Режим Expert
Теперь рассмотрим компиляцию в режиме "Expert" для этого нажмем на кнопку Expert внизу окна.
Появится следующее окно. На первый взгляд тут разобраться невозможно. Вы все еще хотите компилировать в редакторе? :) Объясним все подробно.
В этом окне используются настройки, указанные нами при установке редактора, а именно из меню "Tools/Options..." закладки "Game Configurations" и "Build Programs". Только здесь вместо путей к программам и директориям Half-Life используются переменные, начинающиеся со знака доллара "$".
В списке "Configurations" выберем "Counterstrike (full)".
Теперь рассмотрим каждую строчку в поле "Compile/run commands".
Change Directory $exedir — здесь устанавливается директория, в которой находится файл hl.exe
$csg_exe $path\$file — эта строчка запускает первый компилятор HLCSG
$bsp_exe $path\$file — эта строчка запускает второй компилятор HLBSP
$vis_exe $path\$file — эта строчка запускает третий компилятор HLVIS
$light_exe $path\$file — эта строчка запускает последний компилятор HLRAD
Copy File $path\$file.bsp $bspdir\$file.bsp — копирует готовую карту в директорию с игрой (она указывается в "Tools/Options.../Build Programs/Place compiled maps...")
Copy File $path\$file.pts $bspdir\$file.pts — копирует *.pts файл в вышеуказанную директорию (можно не делать)
$game_exe +map $file -game cstrike -dev -console +deathmatch 1 — автоматически запускает откомпилированную карту с параметрами -dev -console +deathmatch 1
Run with visible objects only — обрабатывать только видимые объекты (если на карте есть скрытые объекты, то они обработаны не будут)
Можно добавить и другие параметры компиляции, рассмотрим пример для полной компиляции:
Выберем слева строчку $light_exe. В окошках справа появятся параметры запуска этого компилятора (на самом деле это HLRAD , просто он так обозначен). По умолчанию в параметрах записано лишь $path\$file, что указывает компилятору путь к нашей карте.
Добавим в поле "Parameters" через пробел следующие параметры: -extra -dscale 1 можно также добавить -smooth 100. Теперь компилятор HLRAD будет запущен в режиме самого качественного просчета освещения. Также устанавливаются параметры и для остальных компиляторов. Просто смотрите в статье "Параметры компиляторов" необходимые параметры и прописывайте их в строчки запуска компиляторов.
Компиляцию в редакторе Hammer нельзя назвать самым удачным решением. При этом способе компиляции требуется больше ресурсов компьютера, т.к. Hammer загружает в память как карту, так и используемые текстуры, да и сам требует определенного количества системных ресурсов.

Компиляция в программе Batch Compiler

Batch Compiler — это графическая оболочка для компиляторов ZHLT. При помощи различных меню мы выставляем параметры и запускаем компиляцию.
Batch Compiler является чем-то средним между компиляцией BAT-файлом и компиляцией в редакторе. Ресурсов потребляется значительно меньше, чем при компиляции в Hammer'е, но все же больше, чем при использовании BAT-файла. Еще один недостаток программ-оболочек приведен в заключении статьи, там говорится о постоянной необходимости обновлять эти программы.
Так выглядит интерфейс программы:
В верхней строчке флажками отмечаются те операции, которые будут выполнены. При полной компиляции необходимо отметить:

• CSG
  BSP
  Visibility
  Radiosity

Флажок напротив букв HL запустит Half-Life на откомпилированной карте сразу же после компиляции.
После первого запуска программы необходимо указать пути к программам-компиляторам, а также, при необходимости, путь к Half-Life. Делается это через меню Options/Setup.
Указав пути к компиляторам, необходимо проделать тоже самое с картой в формате MAP — укажите к ней путь, отметив флажок в самом низу окна программы напротив надписи "MAP File Path".
Затем настает черед выставления параметров компиляции, делается это в закладках (CSG, BSP, Visibility и т.д.). Чтобы выставить нужные параметры, необходимо понимать, что они означают, так что учите :)
Для начала компиляции нажимаем кнопку Compile.

В заключении

С нашей точки зрения, наиболее быстрым и простым способом компиляции является использование BAT-файла. Обычно, чтобы откомпилировать новую карту, необходимо всего лишь поменять название карты. При этом не надо устанавливать дополнительных программ, занимающих место на диске. Трудно сказать какой процент мапперов использует BAT-файл, но, если судить по высказываниям в форумах, BAT-файл рулит! :)
К тому же при использовании программ-оболочек, наподобие рассмотренной Batch Compiler, мы находимся от них в зависимости. Пример: вышла новая версия компиляторов ZHLT с какими-то новыми функциями, а старая программа их, естественно, не поддерживает. Приходится ждать новой версии, следить за новостями, скачивать N-ое количество мегабайт, устанавливать... Так не лучше ли использовать BAT-файл?

В данной статье мы подробно рассматриваем наиболее частые ошибки компиляции, рассказываем как их избежать и как исправить. В конце статьи мы приводим сводную таблицу всех возможных ошибок, причем в той форме, в которой они выдаются компиляторами ZHLT Custom Build. С небольшими изменениями данные ошибки выводятся и в официальных компиляторах ZHLT.
Итак, известно, что далеко не все ошибки, имеющиеся на карте, обнаруживаются в редакторе карт при проверке на ошибки по [Alt-P]. Большинство серьезных ошибок обнаруживается только во время компиляции.
Утилиты ZHLT при наличии ошибки создают файл *.ERR, в который записывается тип ошибки, номер объекта, вызвавшего ее, а также краткое руководство по исправлению, но, естественно, на английском языке.
Содержание статьи:

• ЧАСТЬ 1. Наиболее часто встречающиеся ошибки компиляции
  

  Plane with no normal

  Brush with coplanar faces

  Leaf portal saw into leaf

  Brush 'outside world'

  Mixed face contents

  === LEAK in hull 0 ===

  Exceeded MAX_PATCHES

  Причины медленной работы HLVIS

  Причины медленной работы HLRAD (проблемы с MakeScales)

  HLRAD failled to allocate a block of memory

  Bad Surface Extents

  Missing [ in texturedef

  MAX_PORTALS_ON_LEAF

  MAX_MAP_CLIPNODES

• ЧАСТЬ 2. Обзор всех ошибок компиляции

• Сводная таблица всех ошибок компиляции

ЧАСТЬ 1. Наиболее часто встречающиеся ошибки компиляции

1. Plane with no normal

• Пример:
  Entity 10, Brush 0, Side 4: plane with no normal
  Entity 10, Brush 0, Side 5: plane with no normal
  Данная ошибка возникает при неправильной манипуляции с вертексами. Как известно, любая плоскость определяется 3 точками. Если одна или несколько точек плоскости имеют одинаковые координаты, то это будет уже не плоскость, а линия или точка.
  Как исправить? Удалить неправильный объект и заменить его новым.

2. Brush with coplanar faces

• Пример:
  Entity 10, Brush 0, Side 5: has a coplanar plane at (-753, -9, 251), texture CA1X_CON1B
  Entity 10, Brush 0, Side 6: has a coplanar plane at (-753, -32, 251), texture CA1X_CON1B
  Данная ошибка возникает при неправильной манипуляции с вертексами. Давайте рассмотрим случай возникновения такой ошибки. Предположим, что на карте у нас есть такой объект (см. рис. ниже).
  
  На виде сверху (2D top) в режиме работы с вертексами объект будет выглядеть, как показано на рисунке внизу, слева. Предположим мы решили сделать из этого объекта куб. Для этого верхнюю точку (вертекс) опускаем вниз (см. рис. ниже).
  Так делать нельзя! Так как мы получаем, что на одной стороне объекта расположено 2 плоскости, а этого быть не должно. Вот как эта не правильная операция выглядит в 3-х мерном виде (см. рис. ниже).
  
  
  Как исправить? Можно, узнав номер неправильного браша или энтити-объекта из ERR-файла с ошибкой, перейти к нему, нажав [Shift-Ctrl-G] в редакторе. При этом Вы увидите небольшое окошко (см. рис. ниже), первая строка которого позволяет перейти к определенному энтити-объекту,
  вторая — к брашу. Номер неправильного объекта указывается в ERR-файл в следующем виде:
  "Entity 10, Brush 0, Side 5....", это означает, что ошибка у 10-го энтити-объекта на 5 стороне.
  После нахождения неправильного объекта, его можно удалить, а можно попытаться исправить. В приведенном выше примере необходимо переместить верхний средний вертекс направо или налево, таким образом, мы превратим две грани, лежащие в одной плоскости, в одну (см. рис. ниже).
  После переноса точки Вам будет задан вопрос: "Merge Vertices?" ("Совместить вершины?"), обязательно отвечайте "Да".

3. Leaf portal saw into leaf

• Данная ошибка возникает, когда компилятор HLVIS пытается сравнить 2 портала (leaf portals), которые принадлежат одной видимой вершине (visibility node). Посмотрите на картинку ниже:
  
  Красный и желтый порталы на самом деле были одним порталом, которыл был разбит на два. Оба показанных портала должны лежать на одной прямой, но учитывая ограниченную точность компьютеров при осуществлении операций с плавающей точкой, эти порталы могут слегка наклониться по отношению друг к другу (угол наклона порталов настолько мал, что его невозможно заметить невооруженным глазом — только в бинокль :).
  Если возникает такая ситуация, когда два портала принадлежат одной вершине и образуют кривую линию, то получается ошибка "Leaf portal saw into leaf". Вот как это выглядит:
  
  На рисунке выше угол наклона одного портала к другому сильно преувеличен (для наглядности). Также существуют несколько других похожих ситуаций, когда возникает данная ошибка, все они — результат ограниченной точности компьютеров в осуществлении операций с плавающей точкой.
  Как исправить? Лучше всего загрузить карту с ошибкой и попытаться отыскать, так называемый, эффект зеркального отражения (hall of mirrors effect). Эта ошибка может легко вызываться тем, что координаты одного из вертексов браша немного отклоняются от координатной сетки. В этом случае проще всего пересоздать неправильный браш, но также можно попробовать использовать параметр -full для компилятора HLVIS, который помогает уменьшить количество возможных vis-ошибок. Время компиляции с параметром -full обычно увеличивается на 30%. R_speeds (количество полигонов) при этом остается приблизительно таким же, как и при нормальной vis-компиляции.

4. Brush 'outside world'

• Пример:
  Entity 10, Brush 0: outside world(+/-4096): (-9000, -64, 216)-(9000,23,283)
  Существует несколько причин, по которым возможно появление данной ошибки. Во-первых, такая ошибка возможна при наличии поврежденного браша (из-за неправильной манипуляции с вертексами). В этом случае необходимо внимательно посмотреть на координаты поврежденного объекта, которые сообщаются в ERR-файле с описанием ошибки. Если какая-то из координат равна -9000 или 9000, то такой объект должен быть удален и заменен новым.
  Во-вторых, такая ошибка может возникнуть из-за того, что объект находится вне зоны, доступной для редактирования или около ее границы. Объекты, находящиеся ближе 64 юнитов к границе, также могут вызвать данную ошибку, поэтому следите, чтобы Ваша карта не сильно приближалась к границам рабочего пространства в редакторе.

5. Mixed face contents

• Пример:
  Entity 0, Brush 12: mixed face contents
  Texture ROCK_X1 and SKY
  Каждый отдельный объект в Half-Life может быть окрашен в текстуру только одного типа (например, только в текстуру воды). Например, объект, окрашенный с пяти сторон обычной текстурой, а
  с шестой — текстурой воды, вызовет данную ошибку.
  Всего существует несколько типов текстур, которые не могут быть нанесены на объект вместе с другими. К таким текстурам относятся: SKY, CLIP, ORIGIN и текстуры воды. А самую подробную информацию о типах текстур и их совместимости Вы можете получить из соответствующей статьи: "Типы текстур в Half-Life/CS".
  Как исправить? Перейдите к объекту, вызвавшему ошибку, по [Shift-Ctrl-G] и закрасьте его со всех сторон текстурами одного типа.

6. === LEAK in hull 0 ===

• LEAK — дырка на карте. Это самая известная и, пожалуй, самая нелюбимая ошибка. А все потому, что ее трудно обнаружить и легче не допускать, чем потом часами искать (прям стихи :)
  А причиной такой ошибки является дырка (зазор) на уровне. Например, есть два браша, между которыми существует зазор (по неосторожности Вы не состыковали эти браши вплотную). Эти браши могут быть, например, стенами или землей Вашей карты. При компиляции программы-компиляторы, обнаружив такую дырку, начинают думать: "А что же за этой дыркой?". Они видят зазор, а за ним ужасающая пустота :) — в итоге возникает ошибка.
  Ниже на картинке мы приводим пример такой ошибки.
  
  Но не всегда LEAK виден так явно, как на рисунке выше. Зачастую LEAK имеет очень маленькие размеры, гораздо меньше даже 1 юнита. Особо много LEAK'ов в декомпилированных картах. Например, Вы решили немного изменить De_Dust, разумеется, декомпильнули его, затем попытались вновь скомпилировать и получили кучу ошибок LEAK.
  Второй причиной вызывающей появление LEAK ошибки, является нахождение точечного энтити-объекта за пределами карты. Например, Вы сделали карту, построили вокруг нее небо и случайно поместили какой-нибудь там ambient_generic снаружи карты. В итоге получаем LEAK. Но это лучше, чем искать дырку на карте, т.к. объект найти гораздо проще.
  Как исправить? Можно воспользоваться специальной утилитой LeakMarker. А можно попытаться найти LEAK при помощи самой игры. Для этого нужно скопировать файл *.PTS, который создается в директории с компиляторами при обнаружении ошибки LEAK, в директорию "cstrike/maps", где лежит Ваша недокомпилированная карта, которая тем не менее способна запускаться. Далее нужно запустить консоль и ввести: map имя_карты. После загрузки карты, пишем: pointfile.
  После ввода этих команд на своей карте Вы обнаружете тонкую извивающуюся линию из черно-белых точек (см. рис. ниже).
  
  Эта линия располагается около места с ошибкой LEAK. Запомнив место, открываете редактор и внимательно смотрите на границы брашей, четко ли они состыкованы. Попробуйте инструментом Vertex Manipulation выровнить вершины подозрительных брашей по координатной сетке.
  Если при попытке загрузить pointfile Half-Life вылетает — значит этот файл слишком большой. Придется применять другие методы.
  Если ничего не помогает и найти LEAK не удается, создайте вокруг карты небо коробкой, т.е. поместите всю свою карту в большую "комнату", окрашенную со всех сторон текстурой SKY. Это поможет 100% :)
  Кстати, если Вы вдруг не заметили, что компиляторы выдали ошибку и подумали, что карта нормально откомпилировалась, то обнаружить неладное можно по жутким тормозам на карте (т.к. HLVIS не успел дойти до оптимизации карты), а освещение на карте будет очень светлым и монотонным (см. рис. выше). Теней от объектов не будет, т.к. HLRAD даже не приступил к работе из-за ошибки.

7. Exceeded MAX_PATCHES

• Когда начинает работу компилятор HLRAD, обрабатывающий освещение на карте, он разбивает все видимые поверхности на небольшие участки, называемые патчами (patches). Существует ограничение на максимальное количество патчей — их не должно и не может быть больше 65535.
  По умолчанию размер каждого патча составляет 64х64 юнита. Если масштаб (scale) текстуры больше или меньше (речь идет не о размере текстуры, а именно о масштабе), то это сказывается на количестве патчей. Это означает, что текстура с масштабом 2, будет иметь в 4 раза меньше патчей, нежели текстура с масштабом 1.
  Когда Вы делаете вокруг карты небо в виде большой коробки, чтобы избежать ошибки LEAK (см. выше), компилятор HLVIS обрабатывает все поверхности снаружи карты, которые игрок в игре не видит (а значит зря он их обрабатывает :). На больших уровнях это может вызвать данную ошибку, т.к. количество патчей может превысить порог в 65535 штук.
  Как исправить? В строку запуска компилятора HLRAD можно прописать параметр "-chop 96" или "-chop 128". Этот параметр устанавливает минимальный размер патча в юнитах. Напомним, что по умолчанию минимальный размер патча составляет 64 юнита. При установке размера патча более 96 юнитов, происходит заметное ухудшение качетсва освещения карты, может появиться эффект "лесенки" на тенях, отбрасываемых объектами.
  Также для уменьшения числа патчей можно увеличить масштаб (scale) текстур, например, больших текстур на скалах или земле. Большие по масштабу текстуры создают гораздо меньше патчей. Ну, а если небо у Вас сделано большой коробкой вокруг карты — закрасьте все внешние стороны и дно карты текстурой SKY. При компиляции такие поверхности не просчитываются на освещение и не создают патчей.

8. Причины медленной работы HLVIS

• Время компиляции карты, а именно расчет ее визуальной части компилятором HLVIS, не должно быть слишком большим. На грамотно сделанных картах оно не должно превышать 40-45 минут при использовании машины класса PII-300.
  Причиной долгой работы HLVIS может быть окружение карты небом в виде большой коробки с целью избежания ошибки LEAK. В этом случае HLVIS обрабатывает большие территории снаружи карты, что увеличивает время его работы.
  Второй причиной увеличения времени компиляции HLVIS'ом может стать архитектура на карте. Это довольно трудно объяснить, поэтому приведем несколько примеров:
  • корридоры, пересекающие стену не под прямым углом;
  • браши, развернутые на произвольный угол;
  • большие, высокие комнаты с неперпендикулярными к земле стенами;
  • большое количество мелких брашей (не энтити) на обширных, открытых пространствах

Третья причина: большие открытые территории, которые имеют большое число проходов в различные помещения, при условии, что движок их все прорисовывает.
Как избежать долгой компиляции HLVIS? Просто не делайте описанного выше: не создавайте больших, открытых пространств; не делайте небо коробкой вокруг карты; корридоры разворачивайте на 30, 45 или 90°. Да, это все серьезные ограничения, но ничего поделать невозможно. Необходимо просто это принять. Half-Life далеко не новая игра и ее движок не расчитан на большое количество полигонов. Да, и нужны ли все эти "красоты" игроку? Главное — интересный геймплей. 9. Причины медленной работы HLRAD (проблемы с MakeScales)

• У Вас долго проходит операция "Make Scales" или "Swap Transfers"? Тогда читайте ниже.
  Компилятору HLRAD необходимо довольно большое количество оперативной памяти. Количество памяти необходимое для обработки визуальной матрицы (vismatrix) компилятором HLRAD экспоненциально зависит от размера этой визуальной матрицы. Формула для расчета количества необходимой vismatrix-памяти такова: (количество патчей)²/16 = количество vismatrix-памяти в байтах. Если число патчей максимально 65535, то памяти потребуется 256 Мб.
  Но память необходима не только для просчета визуальной матрицы. Она также нужна для выполнения операции MakeScales. Количество необходимой памяти для этой операции приблизительно равно половине vismatrix-памяти, т.е. на обе операции вместе, в самом наихудшем случае с 65535 патчами, компилятору HLRAD может понадобится 256+128=384 Мб памяти.
  При выполнении операции MakeScales на больших детализированных картах можно часто наблюдать следующую особенность: сначала MakeScales доходит до 90%, скажем за 20 минут, а следующие 10% обрабатываются несколько часов или даже дней! Это происходит при исчерпывании ресурса оперативной памяти, при этом начинается активное обращение к файлу подкачки. Данную ситуацию можно поробовать разрешить, добавив параметр -sparse в строку запуска компилятора HLRAD. Это снизит затраты оперативной памяти на 10% за счет увеличения нагрузки на процессор. Ну, а лучше всего установить дополнительную оперативную память.
  Для ускорения работы HLRAD подходят те же методы, которые применяются для устранения ошибки "Exceeded MAX_PATCHES", рассмотренной выше. Используя эти методы, можно уменьшить количество патчей, тем самым уменьшить потребность HLRAD в памяти. Также можно использовать параметр -bounce 0 для компилятора HLRAD. При этом на карте останется лишь прямое освещение, а отраженное попросту не будет просчитано. Но этот параметр можно применять только для тестовой компиляции. При окончательной компиляции парметр -bounce всегда должен быть больше 0.
  Также можно посоветовать использовать параметр -incremental для компилятора HLRAD. При этом при повторной (но не при первой!) компиляции будут "пропущены" стадии: BuildVisLeafs, MakeScales, SwapTransfers. Использовать этот параметр очень просто. В первый раз Вы компилируете карту как обычно, но добавив параметр -incremental. При этом будет дополнительно создан файл размером до нескольких десятков мегабайт. При повторной компиляции карты с этим же параметром данный файл будет использован и позволит пропустить перечисленные операции. Таким образом, если у Вас мало оперативной памяти, то можно помучиться только один раз (при первой компиляции), дальше все пройдет значительно быстрее. Кстати, если Вы поменяете свойства или расположение источников света (объекты: light, light_spot и light_environment), то не забудьте обновить эту информацию в MAP-файле при помощи параметра -onlyents, прописанного в компиляторе HLCSG.

10. HLRAD failled to allocate a block of memory

• Программа HLRAD (просчитывающая освещение) не смогла продолжить работу из-за недостатка памяти. В этом случае необходимо увеличить размер виртуальной памяти (файла подкачки) или (что гораздо лучше) установить дополнительную оперативную память на компьютер.
  Если Вы не знаете, где в Windows изменяется размер виртуальной памяти, прочитайте об этом в статье "Что такое компиляция?".

11. Bad Surface Extents

• Обычно данная ошибка возникает при нанесении текстур со слишком большим масштабом (более 10, а обычно более 100). Эту ошибку можно обнаружить и в редакторе Hammer. Там она будет найдена, как "Texture axis perpendicular to face". А иногда в редакторе ничего не отображается, вроде бы все чисто. Здесь надо попытаться вспомнить, чего такого необычного Вы сделали на своей карте в последнее время :) Может быть Вы сможете найти какой-то подозрительный объект или вспомните, что раньше были какие-то проблемы с текстурами у какого-то объекта. В общем поищите немного, и Вы наверняка найдете причину данной ошибки.

12. Missing [ in texturedef

• Возможно несколько причин появления данной ошибки:
  • Одна или несколько поверхностей объекта не имеют текстуры (в редакторе такие объекты изображаются абсолютно белыми), или же имя текстуры состоит только из пробелов.
    Проверьте карту на ошибки [Alt-P], редактор покажет такую ошибку как "Invalid texture"
  • В имени текстуры присутствуют пробелы (это недопустимо). Замените такие текстуры.
  • Данная ошибка возникает при импорте карт из WorldCraft 3.3 в WorldCraft 2.1, 2.0
  • Данная ошибка возникает при импорте карт из WorldCraft 3.3 в QuArK
  • Карта сохранена в формате *.MAP, но в поле worldspawn отсутствует: "mapversion" "220" (встречается очень редко)

13. MAX_PORTALS_ON_LEAF

• Обычно такая ошибка возникает из-за больших комнат с большим количеством ведущих в нее корридоров. Также причиной может быть поврежденный (неправильный) браш. Такой браш можно отыскать по [Alt-P].
  На картинке сверху изображена комната на виде сверху. Розовое — комната, синее — ее стены. Розовая комната является одной большой плоскостью, пространством (leaf). Данная комната соединяется с 32-мя небольшими комнатками (углубления в стенах), таким образом, у одного leaf образуется 32 портала (portals).
  Так как в Half-Life "MAX_PORTALS_ON_LEAF" может быть равным 256, то данная ошибка чаще всего случается из-за "битого" браша.

14. MAX_MAP_CLIPNODES

• Clipnodes — поверхности, определяемые игровым движком, как непроходимые для игрока. Каждый браш на карте (будь-то стена, пол или ящик) "окутывается" clipnode-поверхностями. Благодаря clipnode'ам игрок не проваливается сквозь землю и не может проходить сквозь стены. Помните старый халфовский чит "noclip" (хождение сквозь стены) — вот это оно и есть :)
  Слишком большое число этих плоскостей может вызвать ошибку. В улучшенных компиляторах ZHLT Custom Build по умолчанию включен режим экономии таких плоскостей. Это означает, что при использовании этой версии компиляторов, количество clipnode-плоскостей будет меньше, чем обычно, но это не застраховывает Вас от появления данной ошибки.
  Когда Вы делаете вокруг карты небо в виде большой коробки, чтобы избежать ошибки LEAK, создается большое число clipnodes, что может привести к появлению ошибки MAX_MAP_CLIPNODES, к тому же это приведет к увеличению времени работы компилятора HLVIS.
  В архиве с официальной версией (неулучшенной) утилит ZHLT 2.5.3 есть пример (карта clipnode.map), в котором показано, как можно сберечь большое количество clipnodes.
  Давайте посмотрим на картинку с этой карты:
  
  На данном рисунке CLIP и HINT браши представлены в разрезе. Они имеют абсолютно одинаковый размер и расположены аккурат по размерам объекта. Если бы мы не поместили эти браши, то вокруг такого объекта с большим числом сторон было бы образовано большое количество clipnode-плоскостей, которые должны были бы точно указать форму объекта, через которую игрок не может пройти. А используя данный метод, мы значительно уменьшаем количество clipnodes, тем самым уменьшаем вероятность возникновения ошибки MAX_MAP_CLIPNODES и уменьшаем время работы компилятора HLVIS.
  Мы провели эксперимент и скомпилировали карту с CLIP-брашем и без него. И вот результаты:
  • Clipnode-плоскостей с CLIP-брашем (как на рисунке): 30
  • Clipnode-плоскостей без CLIP-браша: 149
  Как видите, результат более чем интересный. Получается, что используя CLIP-браш вокруг объектов с большим количеством сторон, мы сохраняем приличное количество clipnode-плоскостей. Конечно, если карта небольшая и clipnode-плоскостей порядка 10.000-15.000, то особого смысла экономить нет, но это может пригодится при создании большой карты. Кстати, оказалось, что HINT-браш никоим образом не влияет на количество clipnodes, его можно не использовать.

ЧАСТЬ 2. Обзор всех ошибок компиляции

Компиляторы ZHLT обладают хорошей информативностью о ходе процесса компиляции. Вся информация записывается в log-файл, который создается в директории с компиляторами. В этой статье мы рассмотрим основные операции, происходящие во время компиляции карты.

1. Просчет геометрии (HLCSG)

Первым в работу вступает компилятор HLCSG, который выполняет просчет общей геометрии карты.
В строке Command line: друг за другом перечислены параметры для данного компилятора.
При использовании компиляторов ZHLT Custom Build возможно использование параметра -wadconfig , который указывает имя конфигурации текстур.
После строки с параметрами идет таблица, в которой перечислены все возможные параметры для компилятора HLCSG, установленные значения этих параметров (столбец Setting) и их значения по умолчанию (столбец Default).

Информация о текстурах

В подчеркнутой строке сообщается о том, что используется конфигурация текстур с именем dm_aztec_maso32 (в нашем случае). В этой конфигурации используется 11 wad-файлов.
Затем идет перечисление всех используемых при компиляции текстурных файлов.
В следующей подчеркнутой строке сообщается, что 145 брашей (и 866 их сторон) избавлены от clipnode-плоскостей. Это работает режим экономии clipnode, который стандартно включен в ZHLT Custom Build.
Далее выводится подробная информация об использовании текстур.
Using Wadfile — означает, что данный wad-файл просто подключен.
Including Wadfile — означает, что текстуры из данного wad-файла включаются в BSP-карту.
Также здесь Вы можете видеть сколько именно текстур из wad-файла используются на карте, сколько процентов занимают эти текстуры от общего числа всех текстур и сколько всего текстур находится в каждом wad-файле.
Warning — не более, чем просто предупреждения. Они сообщают Вам, что некоторые текстуры слишком большие по размеру и, что количество используемых wad-файлов больше 8 (если это так).
В нижней подчеркнутой строке сообщается какое количество памяти используется текстурами.
В данном случае это 1.53 Мб из 4.00 Мб максимум.

2. Создание BSP-файла (HLBSP)

Теперь за работу принимается второй компилятор HLBSP, который создает дерево карты и работоспособный bsp-файл.
Если данная операция пройдет успешно, то шанс окончить компиляцию без проблем (при наличии достаточного количества свободной оперативной памяти) довольно большой.
Об успешности операции сообщается в строке BSP generation successful.

3. Оптимизация карты (HLVIS)

Настает черед третьего компилятора HLVIS, который занимается созданием визуальной части и оптимизацией карты.
Наиболее хорошего результата позволяет добиться полный просчет, который включается параметром -full.
В подчеркнутой строке ниже сообщается о количестве leafs (что-то вроде отдельных пространств на карте).

4. Просчет освещения (HLRAD)

Ну, и наконец, за работу берется последний компилятор HLRAD, который просчитывает освещение на карте.
Это наиболее продолжительная по времени и наиболее требовательная к ресурсам операция.
Полезно к параметрам HLRAD добавить такой параметр как -chart, для вывода в самом конце компиляции подробной статистической информации о BSP-файле.
Для наиболее качественного просчета освещения и создании реалистичных теней необходимо включить также параметр -extra.
Также полезно увеличить параметр -smooth, который по умолчанию равен 50 (измеряется в градусах). Этот параметр задает максимальный угол между двумя поверхностями, при котором расчет освещения производится с использованием технологии сглаживания.
Chop и texchop устанавливают размер патча (площадь поверхности), на которые разбивается поверхность для просчета освещения. Чем больше значение этих параметров, тем грубее просчитывается освещение. По умолчанию установлены оптимальные значения.
В этой строке сообщается, что на карте используется 2 светящиеся текстуры.
5796 видимых сторон объектов
28411 патчей
38 сторон объектов блокирующих свет
1292 источника света (такое большое значение получается при использовании светящихся текстур)
Основная операция по освещению.
Размер визуальной информации, чем больше значение, тем больше требуется оперативной памяти для выполнения операции.
MakeScales — данная операция так же, как и следующая Swap Transfers, не занимает много времени при наличии свободной оперативной памяти, но при ее отсутсвии может затянуться вплоть до нескольких дней!
Освещения заканчивается просчетом установленного параметром -bounce заданного числа отражений света. Чем больше число отражений, тем более сглаженными будут тени и тем реалистичнее будет освещены темные места на карте. По умолчанию значение параметра -bounce равно 1. Рекомендуется увеличить этот параметр до 4 или более.

В этой статье мы рассмотрим быстрый и довольно удобный способ внесения изменений в готовую откомпилированную карту без запуска компиляции. Таким способом можно вносить изменения в любые карты, даже не имея их исходников.
Прежде всего, необходимо, чтобы у Вас была в наличии официальная версия утилит ZHLT 2.5.3. Сами компиляторы нам не понадобятся, но вместе с ними, в архиве, находится утилита Ripent (ripent.exe), которую мы будем использовать.

В каких случаях полезна утилита Ripent?

• Если Вы хотите поменять прозрачность стекла, воды, других объектов
• Указать правильный угол открытия двери
• Изменить скорость движения машины
• Сделать объект невидимым
• Подправить или добавить места рождения игроков
• Изменить название картинки неба

... и так далее, примеров можно привести огромное множество.
Представьте ситуацию, когда Вы компилируете карту в течении 2-3 часов, и совершенно случайно в ее свойствах забыли указать название картинки неба. Это означает, что на карте будет использовано стандартное небо (desert), вместо того, какое хотели использовать Вы.
Чтобы не компилировать карту заново, можно воспользоваться утилитой Ripent и дописать в нужном месте название неба.

Как это работает?

Информация об энтити-объектах в готовых картах (файлах BSP) содержится в простом текстовом виде. Вы и сами можете в этом убедится, открыв любую BSP карту в текстовом редакторе, например, во встроенном редакторе файлового менеджера FAR или TotalCom. После нескольких тысяч строк, состоящих из непонятных нам символов, начнется текстовое описание всех энтити-объектов, используемых на карте.
Наша задача, а, точнее, задача утилиты Ripent заключается в изъятии всей текстовой информации из BSP-файла и обратное внесение измененных данных.
Описание энтитей любой карты начинается так:

• "wad" "c:\games\hl\valve\halflife.wad;c:\games\hl\valve\liquids.wad;"
  "mapversion" "220"
  "classname" "worldspawn"
  "MaxRange" "8192"
  "skyname" "dm3hackd_"
  "message" ""
  "classname" "worldspawn"

Более подробно о значении этих и других параметров мы рассказываем в конце статьи.

Применяем Ripent

Ripent — утилита, работающая из командной строки, не имеющая своего графического интерфейса.
Извлекаем текстовую информацию об энтити-объектах

1. Скопируйте готовую BSP-карту в папку, где находится утилита Ripent
2. Выберите команду "Пуск -> Выполнить..." ("Start -> Run...")
3. Нажав кнопку "Обзор" ("Browse"), укажите путь к утилите Ripent
4. В конце пути после кавычек допишите след. параметры: -export -texdata 1 имя_карты

Строка запуска программы для карты de_dust будет выглядеть так:
Буквально через несколько мгновений в директории с утилитой и картой появится новый файл, в нашем случае это был бы de_dust.ent, а в общем случаем имя_карты.ent.
Не смотря на расширение, это обычный текстовый файл, который можно отредактировать в любом текстовом редакторе, например, Блокноте. Единственное, не забудьте после внесения изменений сохранить файл с расширением *.ent, а не txt.
Вносим измененную информацию обратно в BSP-карту
Давайте сразу же посмотрим, как проделывается обратная операция по внесению измененных данных в карту.
Выполняем первые 3 пункта, как описано выше, но теперь вместо -export пишем -import (см. рис. ниже).
В этом случае вся информация из файла имя_карты.ent будет внесена в откомпилированную BSP-карту. Изменения Вы сможете увидеть уже при следующей загрузке карты. Файл *.ent можно удалить.

Свойства энтити-объектов внутри BSP-файла

Внешний вид свойств энтити-объектов внутри BSP-файла несколько отличается от того, что мы привыкли видеть в редакторе. Например, вместо параметра Name используется запись в виде "targetname", вместо флагов (small radius, start on, toggle и т.д.) используются цифровой код и т.д. Чтобы Вы могли найти и правильно изменить нужную информацию, необходимо знать соответствия между этими параметрами.
Ниже мы приводим таблицу, где представлены основные свойства энтити-объектов в том виде, как они отображаются в редакторе и внутри BSP-карты.
Таким образом, если нам требуется изменить название картинки неба, мы находим в файле *.ent строку со словом "skyname" и после этого слова точно также в кавычках вписываем название неба.
     Например: "skyname" "desert".
Чтобы изменить степень прозрачности стекла (например, func_breakable с именем glass1), необходимо в файле *.ent найти объект с "targetname" "glass1" и изменить параметр "renderamt" "". Точно также изменяются и все остальные свойства энтити-объектов.
После того, как все необходимые изменения будут внесены, сохраняем *.ent файл и запускаем утилиту Ripent с параметром -import.

Недостатки Ripent

Достоинства Ripent очевидны — не нужно повторять многочасовую компиляцию, если допущена незначительная ошибка в свойствах энтити-объектов. Но есть и свои недостатки.
Используя Ripent, Вы должны помнить, что исходник карты в формате RMF или MAP не обновляется! Обновляется лишь готовая BSP-карта. Соответственно, если затем Вы будете повторно компилировать карту, то сделанные изменения в свойствах энтити-объектов просто пропадут, т.к. исходники карты не меняются! Поэтому или используйте Ripent для внесения незначительных изменений (исправления досадных ошибок и пр.) в окончательный вариант карты, или же записывайте все сделанные изменения и затем в редакторе правьте исходник карты.

Несколько интересных фактов

Думаем Вам интересно будет узнать, что список свойств энтити-объектов каждый раз передается клиенту при подключении к серверу.
Благодаря Ripent мы можем изменить свойства энтити-объектов на любых BSP-картах. Можно, например, сделать мост на De_Aztec (из CS 1.5) прозрачным. Для этого нужно найти объект func_illusionary, отвечающий за изображение моста и выставить параметры: "rendermode" "2" и "renderamt" "0" (в редакторе это выглядело бы как: Render Mode: "Texture" и FX Amount "0"). Мост "исчезнет". Правда, найти нужный func_illusionary, который и является мостом, довольно трудно, т.к. на Ацтеке этих объектов (func_illusionary) несколько.
Помните одно — при подключении к игровому серверу с нормальным Ацтеком, ваш мост НЕ будет прозрачным, т.к. на сервере обычная карта с неизмененными энтити-объектами. Также необходимо знать, что такие параметры, как цвет источника света (light; light_spot; light_environment) менять бесполезно, т.к. освещение просчитывается при компиляции. Ну, а такие параметры, как степень прозрачности объектов, режимы их отображения (texture; solid; additive и т.д.), скорость движения машины, время до автоматического закрытия двери, список объектов внутри multi_manager, просто имена объектов, поле target, название неба и некоторые другие параметры можно менять.
Так что Ripent довольно забавная и полезная штука, если знать как ее использоваться. Ну, а Вы уже знаете :)

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

Что такое декомпиляция?

Декомпиляция — процесс обратный компиляции, т.е. это преобразование карты из формата BSP в формат MAP. Декомпиляция осуществляется специальными программами, которые мы рассмотрим чуть ниже.

Цели декомпиляции

Декомпиляция карт осуществляется с двумя целями:

1. Посмотреть устройство карты, как сделан тот или иной объект, узнать его свойства
2. На основе оригинальной карты сделать свою версию

Что касается первого пункта, то в этом случае декомпиляция весьма полезна в особенности для начинающего маппера. Есть мапперы, которым легче прочитать статью, чтобы узнать, например, как сделать лестницу, а есть такие, которым интереснее самим посмотреть устройство и свойства объектов. Кстати, мы считаем, что мапперы-самоучки гораздо быстрее начинают разбираться что к чему в маппинге и лучше запоминают свойства объектов. Поэтому декомпиляция с этой стороны вещь чрезвычайно полезная.
Немало и тех, кто хочет "малой кровью" создать свою карту. Они просто берут декомпилируют de_dust, добавляют повсюду ящики, строят новые проходы и называют свою карту de_dust7500 или de_dust_best_forever... Чтож, остается только посочувствовать таким "мапперам". Жаль, что у них не хватает собственных мыслей, чтобы придумать интересную карту, хотя желание создавать есть, а значит еще не все потеряно :)
Мы надеемся, что знания, полученные на нашем сайте, помогут Вам стать настоящим маппером, имеющим свой узнаваемый стиль в создании карт; маппером, на картах которого с удовольствием будут играть многие люди. А когда это произойдет мы вместе с Вами скажем: "Долой плагиат!" :)

Программы для декомпиляции

Нам известны две программы для декомпиляции карт: WinBSPC и BSP2MAP. Описание по работе с ними Вы можете найти в разделе "Программы". Хочется только заметить, что работают они одинаково и никакой разницы в качестве получаемой декомпилированной карты нет (а качество весьма низкое, об этом ниже).

Качество декомпилированных карт

• Большое количество битых, неправильной формы брашей
• Ошибки LEAK, т.е. дырки на карте
• Невыровненные текстуры
• Отсутствие оригинальных CLIP-брашей
• Различные глюки с брашевыми энтити-объектами

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

Почему не декомпилируются некоторые карты?

Этот вопрос интересует многих начинающих мапперов. Опытные же мапперы, создающие свои карты, интересуются наоборот тем, как защитить свое творение от чужих рук, как бы сделать карту недекомпилируемой?
К сожалению, а может и, к счастью, мы не знаем ответов на эти вопросы. Однако было замечено, что не декомпилируются большие по размеру карты. Из известных не декомпилируются: de_torn и de_survivor, однако это не помешало узнать нам устройство авиудара и летающей птицы на этих картах (статьи об этом Вы можете найти в разделе "Продвинутый маппинг"). Действительно, если Вы прочитаете статью о том, как узнать устройство карты без декомпиляции, то поймете, что карту необязательно декомпилировать.

В этой статье мы рассказываем о том, как можно узнать устройство какого-либо события на карте, которая не декомпилируется. Под событием мы подразумеваем систему взаимосвязанных объектов, которые создают какой-то один эффект, например, летающая птица на De_Survivor или авиаудар на De_Torn.
Для опытных декомпиляторщиков не секрет, что некоторые карты не декомпилируются :) Возможно, это происходит из-за каких-то ограничений внутри программ-декомпиляторов, потому как не декомпилируются, в основном, большие по размеру карты.
Мы не будем декомпилировать карты, а узнаем ее устройство более цивильным методом. Возмем, к примеру, авиаудары на карте De_Torn. Как они сделаны? (Если Вы не знаете, о каких авиаударах идет речь, то можете прочитать об этом в статье из раздела "Секреты".

Консольная команда: developer 2

Загружаем интересующую нас карту карту и вводим в консоли: developer 2. Теперь у нас на экране будут отображаться сообщения обо всех события на карте (активации объектов, где что нажалось, какой звук проигрался и т.д.).
Бегая по карте, мы обнаружили, что активируется некий объект jetmulti. Им оказался multi_manager. При этом на экране появилась строчка:
Found: multi_manager Firing: jetmulti
Затем мы открыли карту (de_torn.bsp) во втроенном редакторе менеджера FAR (можно использовать и TotalCom) и, так как информация об энтити-объектах хранится внутри карт в чистом виде, то можно отыскать объект по имени jetmulti, что мы и сделали. В свойствах multi_manager'а мы нашли имена всех объектов, которые он активирует в игре. Это были и самолеты (которые на поверку оказались обычными дверями, которые func_door :), и звуки, и прочие объекты. Дальше мы составили схему работы всего авиаудара — "кто" "кого" и когда активирует.
Подобным же образом можно определить устройство объектов и на других картах.

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

Мощность компьютера

Конечно же, в первую очередь, время компиляции зависит от мощности компьютера. Если быть точнее, то от частоты процессора и количества оперативной памяти. Чем больше и того, и другого, тем лучше. Если оперативной памяти мало, то здесь время компиляции начинает зависеть и от скоростных характеристих винчестера. Действительно, если при компиляции свободная оперативная память закончилась, то начинает использоваться SWAP-файл (файл виртуальной памяти). И чем быстрее винчестер передает данные из него, тем быстрее пройдет компиляция.
Что касается конкретных цифр, то, по опыту, для компиляции средней карты (средней как по размерам, так и по сложности внутреннего строения) необходимо порядка 256 Мб оперативной памяти. Лучше 384 Мб. Под словом "средней" следует понимать карту типа De_Inferno. Для более крупных карт памяти может понадобится еще больше. В общем, чем больше памяти у Вас установлено, тем быстрее пройдет компиляция.

Замедление компиляции из-за нехватки памяти

Если Вы наблюдали такую картину: компиляция идет довольно быстро, доходит до 90%, а затем каждый процент преодолевается чуть ли не часами, то это верный признак нехватки оперативной памяти. При этом Вы можете заметить мигание лампочки винчестера, указывающее на использование SWAP-файла.
Часто такая ситуация начинается на операции MakeScales и SwapTransfers компилятора HLRAD. Исправить данную ситуацию можно резким упрощением карты (уменьшением ее размеров, изменением внутреннего строения) или установкой дополнительной оперативной памяти. Выбирайте из этих двух вариантов по своим возможностям. Или же, как третий вариант, попросите откомпилировать свою карту друга :)

Остановка компиляции из-за нехватки памяти

Бывает и так, что компиляция завершается раньше времени из-за полного исчерпания всех видов памяти (и оперативной, и виртуальной). При этом компиляторы ZHLT выдадут примерно такой текст ошибки: "HLRAD.EXE failed to allocate a block of memory". Выходом из ситуации может быть увеличение SWAP-файла или установка дополнительной оперативной памяти.

Программа для компиляции

Скажите НЕТ компиляции через Hammer или Worldcraft. Если у Вас слабый компьютер, используйте для компиляции только пакетный BAT-файл. Дополнительно перед компиляцией уберите все программы из автозагрузки, увеличьте размер SWAP-файла, перезагрузитесь и начинайте компиляцию.

Комплексность карты

Под словом "комплексность" карты следует понимать совокупность размеров карты и сложность ее внутреннего строения. Прекрасными примерами комплексных карт служат довольно известные карты: De_Volare, De_Laguna, Cs_Shogun и др. На каком-нибудь PII-400 при 64 Мб памяти эти карты могут компилировать днями!
Обширные открытые пространства, изобилие наклонных поверхностей различной формы (например, горы), большое количество источников света — все это заметно (!) увеличивает время компиляции. К тому же без должной оптимизации, карты, подобные перечисленным выше, будут несщядно тормозить на любой машине просто потому, что старый движок Half-Life не способен обрабатывать уровни таких размеров и такой сложности.
Чтобы хоть как-то ускорить компиляцию больших карт необходимо, во-первых, закрашивать все невидимые игроком поверхности (крыши домов, обратные стороны стен карты, дно карты) SKY-текстурами, во-вторых, стараться делать дно и внешние стены карты плоскими, без впадин и ям, идеально, чтобы стены и дно образовывали непрерывную плоскость. Первый совет поможет ускорить просчет освещения (одну из основных операций), т.к. при компиляции SKY-текстуры не просчитываются на освещение; второй совет пригодится, если Вы строите небо карты одной большой коробкой, в этом случае между небом и картой не останется "пустот", что ускорит оптимизацию карты компилятором HLVIS.

Источники света

Замедление компиляции может вызвать большое количество источников света, собранных в одном месте. А если они еще будут мигающими или выключающимися, то время компиляции возрастет еще значительнее.
Очень сильно на скорость компиляции влияет количество светящихся текстур, т.е. текстур, излучающих свет. Если Вы используете светящиеся текстуры, то при компиляции программой HLRAD, можно будет заметить существенное увеличение количества источников света (Direct Lights). Например, может быть так, что у Вас на карте используется всего 20 лампочек и несколько светящихся текстур, тем не менее количесво Direct Lights будет около 1000 или даже больше. Конечно же, это существенно замедлит компиляцию на компьютерах с малым количеством оперативной памяти, так как светящие текстуры используют в несколько раз больше памяти, нежели обычные иточники света (light, light_spot и light_environment).
Вывод: не увлекайтесь светящимися текстурами и не размещайте очень много разнообразных (как по цвету и мощности света, так и по состоянию: мигающая, обыная, выключаемая) лампочек в одном месте карты.

Ускорение просчета освещения

Как Вы должно быть уже знаете из предыдущих статей Учебника, компиляцию можно проводить двумя способами: быструю с щадящими параметрами и полную с настройками на максимальное качество. Повторяться не будем. Напомним только, что при тестовой компиляции можно указать для компилятора HLRAD параметр -chop 128 и при этом убрать параметр -extra. Это заметно ускорит компиляцию на обширных картах. Так же можно вообще отказаться от просчета освещения (HLRAD) и оптимизации карты (HLVIS), если компиляция действительно тестовая и служит только для проверки работоспособности энтити-объектов и таймингов карты, т.е. проверки времени встречи команд в разных местах.
Очень полезным может оказаться параметр -incremental для все того же компилятора HLRAD. Этот параметр при первой компиляции и, соответственно, при первом просчете освещения создает файл с информацией об освещении карты. Размер файла будет зависеть от размеров карты, но обычно он занимает нескольких десятков мегабайт (до 100-150). При повторной компиляции с этим же параметром, утилиты ZHLT найдут ранее созданный файл и пропустят некоторые требовательные к ресурсам операции освещения. Данный метод позволяет существенно уменьшить время полной (самой качественной) компиляции больших карт.

NetVIS: или компилируем с другом

Еще несколько ускорить компиляцию поможет проведение операции по оптимизации карты вместе с другом. Если Вы хотите использовать эту возможность, то вместо компилятора HLVIS следует запускать NetVIS. Тогда один из компьютеров (допустим, Ваш) будет сервером, а компьютер друга — клиентом. При наличии очень большой (комплексной) карты время компиляции может быть существенно уменьшено.

Еще не все используют ZHLT!

К великому сожалению, это так... Не все мапперы знают про компиляторы Zoner's Half-Life Tools и продолжают использовать стандартные устаревшие компиляторы. Это тем более удивительно, что в интернете и у нас на сайте постоянно упоминаются именно ZHLT, как самые лучшие компиляторы.

В качестве заключения

Конечно же, время компиляции карты очень сильно зависит от мощности компьютера, но и на слабых компьютерах вполне возможно создавать очень качественные карты. Вспомните, какие компьютеры были осенью 1999 года, когда был создан De_Dust или весной 2001 года, когда появился De_Dust2. Разве обязательно делать огромную карту, ждать часами ее компиляции, а потом разочароваться из-за того, что в эту карту никто не играет? :)