Hammer Editor v.2

1. Батник (если вы придержитесь моего образца и не станете переписывать его под относительные пути) можно хранить в любом удобном месте. Я лично поместил в %WINDIR%, чтобы было удобно вызывать его из командной строки или с помощью Win+R, но можно просто добавить путь к батнику в %PATH% (или даже присвоить полный путь к батнику к какой-нибудь переменной и вызывать её, обрамив знаками процента, например, %backup%). Можно, конечно, и ярлык сделать, но батник заточен на ручной вызов из консоли, так что толку от такого ярлыка немного, разве что создать по ярлыку к каждой цели, или бэкапить сразу всё (этот момент станет понятнее ниже).

2. С 7-zip'ом можно поступить так же, как и с батником: либо кинуть 7z/7za в %WINDIR%, либо добавить в %PATH%, либо отредактировать батник и вместо set archiver=7z a -t7z написать:
set archiver="C:\Program Files\7zip\7z.exe" a -t7z
Можно вообще поменять на другой архиватор (тот же rar), но из-за этого, как минимум, придётся переписать параметры архивации.

3. Нужно составить файл exclude.lst (можно назвать его по-другому) и вписать путь к нему в следующую строку:
set optionsпы щь=-x@%WINDIR%\exclude.lst -mx9
Вместо %WINDIR%\exclude.lst нужно подставить свой путь (в кавычках, если он содержит пробелы).
Эксклюды могут понадобиться, если нужно забэкапить содержимое каталога, не включая один или несколько файлов и папок. Особенно это полезно, если нужно забэкапить всё, кроме подкаталога/ов, вложенного/ых в каталог. Можно, конечно, решить это по-другому: скопировать нужные файлы в какое-то другое место с помощью copy и уже затем бэкапить, но думаю, что недостатки такого подхода очевидны.
В своём батнике я использую один эксклюд-файл на всё, но можно завести по отдельному списку для каждого архива. В принципе, второй вариант лучше, поскольку точно не возникнет совпадений пути, исключаемого из одного архива с путём, который включается в другой. С другой стороный, первый вариант несколько удобнее. И хоть я и выбрал его, батник всегда можно исправить.
Пример файла-эксклюда:

C:\Demos\theprodukkt\Werkkzeug3Tex\backup\
C:\Demos\theprodukkt\Werkkzeug3Tex\*export\
C:\Games\Mapping\BSPquakeditor\анти матHalf?Life\textures\
C:\Games\Mapping\BSPquakeditor\анти матtutor_bsp.swf
C:\Games\Minecraft\?minecraft\screenshots\
D:\TempGames\Aether\?minecraft\screenshots\
SourceSDK_Content\generic\mapsrc\dec\
SourceSDK_Content\oldarkinterval\mapsrc\alex\
source\zothers\
wads\cof\
wads\Dmitrich!\
wads\hq2\
wads\q3\
workspace\?metadata\
xDDGx\xcompile\

Я старался использовать полные пути, но из-за глюков 7-zip'a методом тыка пришлось исправить некоторые на относительные. Я не знаю, в чём причина, даже думал, что проблема в пробелах, но 7-zip отказывается распознавать пути эксклюда в самые неожиданные моменты. Ещё была проблема с путём C:\Games\Mapping\BSPquakeditor\анти матHalf-Life\textures\, но я догадался, что ему не понравился дефис, и, так скажем, "зацензурил" слово Half*Life, спрятав дефис символом подстановки. Потом я поменял * на ?, потому что в первом случае под маску подходит больше названий. Впрочем, и вопросительный знак — костыль жуткий, с которым нужно быть поосторожнее (например, если там будет папка Half2Life\textures, она тоже окажется не забэкапенной), но что поделаешь...
С папкой .minecraft тоже самое, только тут пришлось зацензурить точку.

4. Конечно же, нужно исправить путь к папке, в которую будут складываться бэкапы:
set prefix=I:\Uploads\Backups
Можно указать каталог Dropbox'a, Яндекс.Диска, Меги и пр., чтобы автоматически заливать бэкапы в онлайн.

5. Батник создаёт архивы с именами вида имя_день_месяц_год.7z. Если нужно делать бэкапы чаще, чем раз в день, можно добавить где-нибудь над этой строкой такой код:

set currtime=%TIME%
set hours=!currtime:~0,-9!
set minutes=!currtime:~3,-6!
set secondsпы щь=!currtime:~6,-3!

А строку
set postfix=%day%_%month%_%year%.7z
Исправить на:
set postfix=%day%_%month%_%year%__анти мат%hours%_%minutes%_%seconds%.7z

6. По идее, батник должен вызываться так:

батник.бат что_бэкапить1 что_бэкапить2 ... что_бэкапитьN

В качестве параметров ему передаются названия меток, каждая из которых представляет собой сокращённое название того, что нужно бэкапить. Для удобства я буду называть их "целями". Например, если мне нужно забэкапить иконки, которые я столько времени старался, рисовал и ваще, мне достаточно набрать backup icons в командной строке или в меню Win+R. Чтобы сбэкапить майнкрафт со всеми модами, сохранками, батниками и т.д., мне достаточно набрать backup mine. Можно даже набрать сразу backup icons mine, чтобы одновременно забэкапить и иконки, и майн, или вовсе набрать backup all, чтобы обработать вообще всё.
Чтобы сделать как у меня, вам нужно, для начала, создать в батнике свои цели, которые представляют собой эдакие батниковые "подпрограммы" или "функции". Каждая такая "процедурка" начинается с метки с названием и выглядит вот так:

:метка
set name=имя_архива
set paths=пути_архивирования
удаление уже имеющихся бэкапов, содержащих имя %name%_
вызов архиватора %archiver%: архивирование %paths%, создание архива %name%_дата.7z в папке %prefix% с учётом заданных %options%
конец

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

if [%1]==[all] (
set cmdline=bsp icons mine src twice
) else (
set cmdline=%*
)

Эта проверка расположена в начале батча. Во вторую строку, после знака "равно" укажите ваши цели. Тогда можно будет просто набрать backup all, чтобы забэкапить всё, иначе работать не будет, поэтому важно не забывать поддерживать этот список в актуальном состоянии...
Ещё полезно перечислить цели в конце батника, там где стоит метка help:

:help

echo.
echo valid options are:
echo all - backup all targets
echo bsp
echo icons
echo mine
echo src
echo twice
echo.

Если вызвать батник без параметров, он выдаст имена всех доступных целей; на случай, если вы забудете, как назвали ту или иную цель, можно дописать короткую расшифровку (чтобы писать по-русски, батник придётся перекодировать в CP-866, в Notepad2 она обозначена как OEM 866).

Перечитав весь форум беты и по-настоящему проникнувшись её духом, мне захотелось запилить свою карту под неё. Тем более, что с бетой и так идёт пара исходников, так что недолго думая подверг истязаниям devtest, решив просто сделать — без претензий на реалистичность, логичность, сюжетность и т.д. — из него по-настоящему играбельный уровень для беты (коих практически нет, хотя я переиграл во все беташные карты, ссылки на которые были живые: алсо, ОГРОМНОЕ СПАСИБО [жаль, что он его не увидит ;( ] Шифровалу, который заботливо перезалил практически весь мелкий стафф на йапапко; к сожалению, многое так и потерялось, а кое-что стало недоступным на самом фолдере... часть оригинальных архивов я храню у себя, пожалуй, перезалью их куда-нибудь ещё...). Так вот, работа над картой шла в полный рост, многое было исправлено, многое — добавлено, изменено и т.д. Правда, я сделал глупость, дело в том, что devtest настолько здоровый и сложный, что у меня Хаммер тормозит из-за него, причём на 2D-видах! Помогало приближение 2D-вида, чтобы видеть меньше объектов на сетке. Или проскроллить куда-нибудь в сторону. И это приходилось делать каждый раз, потому что Хаммер центрирует 2D-виды относительно начала координат, а уровень был построен вокруг него. Чтобы каждый раз не тратить время на скроллинг (который осуществлялся достаточно медленно, чтобы раздражать), я решил выделить всю карту (Ctrl+A) и сдвинуть её в сторону (я не гнушался этим во время голдсорс-маппинга, обычно перетаскивая куски уровней, отдельные комнаты). Зря я это сделал... Проблема в том, что хоть я и двигал уровень по сетке (по самой большой), энтити, мелкие и повёрнутые на нестандартные углы браши нарушали выравнивание, и в результате практически все объекты были смещены относительно сетки, даже самой мелкой, хуже того — их координаты стали нецелыми. Т.е., например, была у нас сторона с координатами 256 256 256 — после сдвига стала, скажем, 511.986 511.986 511.986. В целом, особых проблем это не доставляло: уровень конпелялся нормально, никаких там швов и прочих проблем, ничего не сломалось. Но, во-первых, увеличился размер исходника (сравните запись 256 vs 511.986), во-вторых, время компиляции заметно увеличилось (хотя и не слишком сильно), в-третьих, когда хотелось изменить геометрию, приходилось выравнивать по-нормальному (но всё выровнять, конечно, было нереально, слишком большой был уровень). Частично помогло выравнивание по самой мелкой сетке, но только частично. Так или иначе, исходник я испортил, а ведь мне хотелось отдать его в опенсорс (мне кажется, это и сгубило общество беты: практически весь свой стафф они выкладывали только в конечном виде, да ещё и на ненадёжных хостингах, которые быстро сдыхали, и сами не следили и постоянно теряли свои исходники и результаты; всё-таки хорошо, что сейчас интернет куда лучше и есть столько облачных хранилищ... правда от глупости и все хранилища мира не спасут...). Но мне было влом переделывать всё заново на чистом исходнике, поэтому, пожав плечами ("сэ ля ви"), я продолжил работу над тем, что было.
Пока окончательно не загубил её. Я сам едва понимаю что случилось, но кажется, я одновременно запустил конпеляцию из хаммера и make'ом (по крайней мере, я точно помню как запускал компилинг из Хаммера и консольку с мейком). По-видимому, в результате одновременного обращения к одному файлу, система вылетела в BSOD (хотя не исключено, что причины были другие: у меня постоянно выдёргивался SATA-кабель из нового диска (на котором у меня и была бета со всем стаффом, когда как для обычных (Gold)Source всё лежит на старом); и хотя я жутко недолюбливал IDE (не раз гнул и сам же разгибал его иглы...), от саты у меня не меньший багет, IDE-соединение при всём своём неудобстве хотя бы надёжное); в общем, вполне возможно, что BSOD был результатом сатопроблем).
После перезагрузки, я первым же делом проверил исходник. Попытка загрузки его в Хаммер сфейлилась. Открыл его блокнотом: вместо plain text то ли мусор, то ли вовсе NULы. Открыл vmx — тот тоже оказался повреждён! Хотя в блокноте небольшой кусок выглядел нормальный, но остальное — какие-то бинарные данные, явно мусор. Сделать с этим что-либо не представлялось возможным. Но я не стал сдаваться так просто и решил попытаться восстановить его утилитами для спасения удалённых файлов. Recuva сразу показала свою беспомощность, но я помнил про демонстрирующий неплохие результаты, но платный EASEUS Handy Recovery, крякнутая версия которой в былые времена выручала меня не раз. Программа, походу, старая, заброшенная. В процессе эксплуатирования выяснилось, что с 64-битной XP она не дружит: зависала, приходилось резетать. Тогда я попробовал в 7ке — как ни странно, там она отработала на ура. Но ничего не нашла, она смогла "восстановить" только такой же битый файл, а то и ещё хуже. А перезагрузившись в XP, я внезапно обнаружил, что последний резет оказался фатальным для неё: реестр системы оказался повреждён, система стала неработоспособной. Если бы у меня были бекапы реестра, я бы мог восстановить свою винду, однако у меня их не было, поскольку отключил систему восстановления.
Если кто не знает, реестр Windows — это не что-то эфемерное, а вполне себе файл, вернее, набор файлов, который можно обнаружить в %WINDIR%\system32\config. Какой-то из этих файлов повредился. Шиндошс при установке создаёт резервную копию реестра в %WINDIR%\repair — разумеется, это копия реестра на момент установки, т.е., после восстановления получаем чистую винду, такую, какой она была при установке, без программ, настроек и прочего. У меня уже было повреждение реестра, и я смог экспериментальным путём выявить, какой раздел пострадал и восстановить только этот раздел. Кажется, это был system. Но в этот раз был затронут software (самый большой раздел, где хранится большая часть реестра), поэтому я решил, что лучше уж переустановить Шиндошс с нуля. Что и было сделано.
Стоит отметить, что, будучи не совсем безмозглым, я помнил, что нужно делать бэкапы. И такой бэкап у меня действительно был!.. месячной давности. И за этот месяц я проделал довольно много работы...

                  EPIC FAIL

С другой стороны, во всём есть позитивные стороны. Я задумался о том, чтобы бэкапить не только данные, но и важные файлы ШIИДОШ3, поэтому теперь у меня на линуксе есть скриптик, который я запускаю чуть ли не каждый раз, когда загружаюсь в него (можно вообще в авторан при старте системы добавить, ы), этот скриптик архивирует папку %WINDIR%\system32\config 7-zip'ом в \home линукса (получается немного, что-то около 4-7 метров, в зависимости от размера реестра). Из запущенной винды их архивировать, к сожалению, нельзя, не даёт-с.
Ну и теперь, после переустановки, .NET Framework уже не так тупит.
Я также задумался о том, чтобы автоматизировать бэкапинг результатов работы над картами, для чего написал пару батников и включил их в состав новой версии "нано-беты": быстрый бэкап vmf и bsp, полный бэкап исходников: vmf, qc, modelsrc, materialsrc, rad, lst, scripts, и полный бэкап самой нано-беты. Правда, последний нормально не работает, я так и не понял, как сказать 7-zip'у, чтобы он исключил из бэкапинга саму папку backups, LOL. На -x опцию он что-то ругается, нид хэлп...

В общем вот, традиционные 7z.png с нанобетой:

http://i.playground.ru/i/80/09/79/00/pix/image.jpg
http://i.playground.ru/i/90/09/79/00/pix/image.jpg

Здесь есть ещё пара мелких изменений. Так, я понял, что же было не так с моим мейкфайлом, что он не хотел работать с ритейловой халфой. Оказалось, что виновата была не другая буква диска, а пробел. В Unix'ах принято экранировать пробел обратным слэшем (как пути в виндах; в юниксах в путях используются прямые слэши, как в веб-ссылках). Т.е., на линуксе путь"Games\Half-Life 2\hl2\maps" должен выглядеть как Games/Half-Life\ 2/hl2/maps (можно конечно и в кавычки взять, но мейк такого не понимает). А на винде слешики будут одинаковыми, и поэтому путь D:\TempGames\Half-Life 2\hl2\maps должен быть записан как D:\TempGames\Half-Life\ 2\hl2\maps
Кроме того, я разделил makefile на два файла, один просто подключает другой. Другому приделал расширение mk, чтобы его можно было проассоциировать с программой //хотя вообще говоря, в винде можно сделать так, чтобы файлы без расширений открывались блокнотом и даже имели какой-нибудь значок (для этого в HKCR нужно создать раздел с именем . (точка) и обустроить его по образу и подобию других).
Ещё я добавил во многие текстовики (батники, мейкфайлы и пр.) комментарии, чтобы можно было быстро самостоятельно разобраться/вспомнить что к чему. Все каменты на моём нубоинглише.
А также добавлен файл JFL.NFO с описаниями и ссылками на все используемые ресурсы. Дубоинглиш эген.

// ещё заметил, что на background_example почему-то не компилится нормальное освещение, WTF?!

:bsp

echo C:\Games\Mapping\BSPquakeditor\пы щьHalf?Life\textures\>exclude.lst
echo C:\Games\Mapping\BSPquakeditor\пы щьtutor_bsp.swf>>exclude.lst

set name=BSPquakeditor
set paths=C:\Games\Mapping\BSPquakeditor\*
if exist %prefix%\%name%_* del /Q /F %prefix%\%name%_*
%archiver% %prefix%\%name%_%postfix% %paths% %options%

del/q/f exclude.lst
:: хотя вот это не обязательно, если мы везде используем именно > для добавления первой строки, потому что это создаёт новый файл (а >> просто дописывает в конец)

goto eof

"WorldVertexTransition"
{
$baseTexture "interval_hyper/hyper_breedertexture003"
$baseTexture2 "interval_hyper/hyper_breedertexture001"
"%tooltexture" "interval_hyper/hyper_breedertexture003"

$bumpmap "interval_hyper/hyper_breedertexture001_ssbump"
$bumpmap2 "interval_hyper/hyper_breedertexture001_ssbump"

$ssbump 1

$envmap "env_cubemap"
$normalmapalphaenvmapmask 1
$envmapcontrast 1
$envmapsaturation 1
$envmaptint "[.7 .5 .5]"

$surfaceprop "fleshspecial"

$texoffset "[0 0]"
$texscale "1"

Proxies
{
//TextureScroll
//{
// Texturescrollvar $basetexturetransform
// Texturescrollrate 0.002
// Texturescrollangle $scrollAng
//}

"TextureScroll"
{
"texturescrollvar" "$bumptransform"
"texturescrollrate" 0.05
"texturescrollangle" -90
"texturescale" 1.0
}
}

}

Если вам надоело конпелять карты батниками, а GUI-шные Batch Compiler'ы не труъ, или просто не устраивают функционалом, могу предложить альтернативный инструмент, который называется make. Это стандартная утилита GNU, которая есть в любой POSIX-совместимой системе (Linux, Unix). Для винды она есть в составе Cygwin и портов утилит GNU, напр., GnuWin32. Чтобы не качать весь пакет, вот вам только exe-шник make'a с двумя необходимыми библиотеками. Кроме того, свой make есть в составле Borland C++ Builder'a, и вроде даже в Visual Studio (там он называется nmake, правда, теперь его уже не используют).
Скрипты для make'a называются makefile'ами. И действительно, главная задача мэйка, ради которой он создавался — это как раз "делать файлы". Причём, не важно, какие файлы, и как делать. И хотя обычно мэйкфайлы используются для компиляции C/C++ программ, мы вполне можем приспособить их и для компиляции карт.

Типичный мейкфайл состоит из нескольких частей, которые я назову так: директивы, переменные, скрипты, цели и команды. Это условные названия, я использую их для своего удобства и чтобы вам было понятнее, расшифрую, что под ними подразумевается.
Самыми важными являются "цели". Кроме них, в принципе, можно ничего больше не писать. Цели имеют следующий синтаксис:

результат : исходник
    какие-либо действия
    в результате которых
    из исходника получается результат

Чтобы было яснее, приведу пример:

hello.exe: hello.c
    gcc hello.c -o hello.exe

hello.exe — то, что нужно получить;
hello.c — то, из чего нужно получить (здесь может быть указано несколько файлов, например, если к нашему hello.c подключается hello.h, можно указать и его, в качестве разделителя используется пробел; стоит отметить, что и вместо hello.exe может быть указано несколько файлов, тоже через пробел);
gcc hello.c -o hello.exe — команда, преобразующая hello.c в hello.exe.

Обратите внимание на отступ перед последней строкой — для поста я сделал его неразрывными пробелами, но в самом файле это должна быть табуляция, причём обязательно, без неё работать не будет (и напротив, ставить табуляцию перед целью нельзя ни в коем случае, иначе мейк будет думать, что это команда, которую нужно передать шеллу, т.е., cmd.exe в случае винды). При желании, можно заменить табуляцию на что-то другое, но во-первых, я не вижу в этом смысла, во-вторых, я не разбирался, как вообще это делается.
В остальном код вполне рабочий, если у вас есть Cygwin, вы можете создать в какой-нибудь папке файл hello.c, файл makefile (именно так, без расширения, хотя часто к названию дописывают -1, -2 или .mk, .make, а в принципе, название может быть любым, нужно просто дополнительно указать параметр -f имя_файла) с этим кодом, запустить Cygwin, перейти в папку и вбить команду make (или make -f имя_файла, если оно нестандартное). Результат выполнения команды:

Хотя конкретно в этом случае использовать make как-то слишком жирно, можно тогда уж сразу вбить gcc hello.c. Однако, кроме целей, мэйкфайл может содержать сколь угодное число различных команд и их комбинаций. "Стандартными" являются команды install, uninstall и clean, которые служат для установки и очистки проекта. Для вышеуказанного примера мы можем написать их так:

install:
    cp hello.exe "/cygdrive/c/Program Files/"

uninstall:
    rm -f "/cygdrive/c/Program Files/hello.exe"

clean:
    rm -f hello.exe

Для типичного виндузятника эти команды выглядят жутко, не правда ли? :D На самом деле, команда install всего-навсего копирует файл в нужную папку с помощью стандартной утилиты cp, а clean и uninstall — его удаляют. К сожалению, под цыгвином мы не можем использовать стандартные команды виндовой командной строки, если мы напишем вместо последнего del /Q /F hello.exe, make выдаст ошибку. Но для компиляции BSP мы не будем использовать Cygwin'овский make, так как типичному мапперу не нужен целый линукс в кармане, достаточно той "стандалон-версии", которую я вытащил из GnuWin32. А вот он как раз позволяет использовать родной командлайн.
Но прежде, чем мы обратимся к нему, сперва разберёмся с синтаксисом самого make'а. На первый взгляд кажется, что команды чуть-чуть, но отличаются от "целей", пример которых приведён ещё выше, но на самом деле, команды — это те же самые цели, только упрощённые. Отличие в том, что у команд нет "реального" результата. В результате выполнения make install не возникнет файл install. Соответственно, и указывать, из чего он "получается", тоже не надо, так что после двоеточия мы сразу ставим абзац.
Однако make — он тупой^W^W файло-ориентированная утилита (как, впрочем, и подавляющее большинство других юниксовых утилит, да и сами Линукс и Юникс можно такими назвать), и он каждый раз будет проверять существование файлов install, clean, uninstall. Чтобы этого не происходило, мы воспользуемся директивой .PHONY. Её нужно указать в начале файла, и после двоеточия перечислить все "нефайловые" команды. Для нашего случая она будет выглядеть так:

.PHONY: install uninstall clean

Хотя, если вы её не укажете, ничего страшного не произойдёт, всё будет работать. Тем не менее, рисковать не стоит, кто знает, какие эффекты повлечёт за собой наличие файлов именами совпадающих с названиями команд.
Осталось разобраться, как запустить эти команды. Здесь тоже нет ничего сложного, просто теперь вместо make нужно писать make install, make uninstall или make clean. Ещё один пример из Cygwin:

Если же ввести просто make, то выполнится та команда, которая указана в мейкфайле первой. Т.е., если самой первой стоит цель hello.exe, то простой вызов make запустит компиляцию кода. Но самая приятная возможность make'a в том, что мы можем выполнить сразу несколько целей или команд, например, мы можем ввести make install clean, они выполнятся последовательно. Однако удобнее не вводить всю последовательность вручную (она может быть длинной), а использовать то, что я назвал "скриптами". На самом деле, аналогично командам, скрипты — это те же самые цели, только ещё более урезанные. Сами по себе скрипты ничего не делают, а просто задают последовательность команд и/или целей, которые нужно выполнить. Допустим, мы хотим скомпилировать, установить и очистить проект в одно действие. Пусть этот скрипт называется auto. Выглядеть он будет так:

auto: hello.exe install clean

Если мы укажем этот скрипт в самом начале файла (после .PHONY), то простым запуском make из командной строки (или запуском make.exe двойным кликом из проводника, если вы закинете его в ту же папку, что и makefile) вы скомпилируете, установите и очистите проект. Можно даже добавить автоматический запуск скомпилированной программы для полного счастья. Пример выполнения:

Последнее, что осталось рассмотреть — переменные. Полагаю, объяснять, что это такое, излишне. Объявляются они максимально просто, если не сказать, примитивно:

ИМЯ = ЗНАЧЕНИЕ

Даже проще, чем в батниках. При этом вы можете окружить знак "=" пробелами, это не нарушает работу мейка. Но объявить переменную — это полдела, самое сложное, использовать её. Чтобы подставить значение, хранящееся в переменной, нужно использовать конструкцию вида $(ИМЯ) или ${ИМЯ} (последняя форма вообще-то используется в shell-скриптах, но, как ни странно, в мэйкфалах тоже работает). Тем не менее, как правило используют первую форму, вторая даже не подсвечивается в Notepad2 и Notepad++. Впрочем, в них подсветка мейкфайлов вообще хромает, из всего что у меня было, лучше всего себя показал Sublime (напр., схема Cobalt), да и то там не подсвечиваются переменные.
Переменные помогут нам сделать мэйкфайл более универсальным, и облегчить его редактирование. Даже в нашем простейшем примере, например, что, если вместо hello.exe мы захотим скомпилировать что-то другое? Придётся заменять hello на %что-то-другое% по всему документу. И хотя можно воспользоваться Ctrl+H в блокноте, это плохой и неудобный путь, всё неудобство которого вы испытаете, когда мэйкфайл разрастётся и там появятся десятки вариативных параметров. Поэтому лучше сразу объявить переменную, ну, например, NAME, и присвоить ей значение hello, а в будущем — какое другое. Кроме того, стоит переделать в переменную путь установки. Можно пойти дальше и даже превратить в переменную название компилятора (вдруг мы захотим воспользовать каким-то другим) или даже rm -f на del /Q /F (к сожалению, здесь не всё так просто, но об этом попозже), но в этом примере я ограничусь первыми двумя. Итоговый пример будет выглядеть как-то так:

(из-за несовершенства подсветки я её чуть-чуть дорисовал вручную).
Обратите внимание: даже вместо цели hello.exe теперь значится $(NAME).exe. Переменные могут использоваться где угодно.


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

(к картинке прикреплён архив с мэйкфайлом, просто сохраните и откройте её в 7-zip или WinRAR, или скопируйте его по этой ссылке)
Хотя без пояснений, конечно, не обойтись. Во-первых, этот мэйкфайл предназначен для компиляции карт беты, причём доступна опция конвертирования под релиз. Во-вторых, если запустить make без параметров, то он не будет делать ничего полезного, а просто выведет справку с перечислением полезных команд:

Команда help находится в самом низу и состоит из странных на первый взгляд, строк:

    : make full

Поначалу я использовал привычный echo, но у make'a есть особенность: он всегда выводит то, что делает, т.е., он выведет саму строку "echo make full", а затем сам echo выведет "make full". В результате получается каша из повторяющихся строк. Самый простой выход: вместо echo передать строку какой-нибудь другой программе или команде, которая не будет выводить ничего. В cmd можно просто использовать двоеточие — он воспринимает его просто как метку. Можно также использовать знак комментария ::, или команду rem, но последняя оставляет после себя абзац, да и само "rem" никуда не денется. А двоеточние выглядит как маркировка списка.
Остальные макросы оставим на потом, сперва разберём команды:
 – set устанавливает переменную среды, без которой компиляция не будет протекать нормально. К сожалению, утилита setx может отсутствовать в вашей винде, но простого set, увы, недостаточно. Конпелять-то оно будет, но моделей не увидит. Поэтому самый лучший вариант — это всё-таки установить параметр VProject вручную. В обоих случаях команду set нужно выкинуть из мэйкфайла;
 – что такое full_compile и fast_compile объяснять излишне (хотя они отличаются только параметром -fast у vis'a, а кто-то вообще только с fast'ом и компилит, так что смысла в двух конфигурациях мало);
 – convert конвертирует bsp v18 в bsp v19 для релизной халфы;
 – game просто запускает игру, чтобы потестировать свежеоткомпиленную карту;
 – install копирует карту из папки bin (где должен лежать этот makefile вместе с утилитой make) в папку hl2/maps;
 – остальные три удаляют файлы. Сразу возникает вопрос, почему используется конструкция if exist $(FILE) del $(FILE) вместо просто del $(FILE)? Дело в том, что make останавливает свою работу сразу, как только возникает ошибка. В этом главное отличие make'a от batch'a: если мы просто перечисляем в батнике vbsp, vvis, vrad, и если при компиляции возникает ошибка (например, исходник банально не существует), то vis и rad всё равно отработают, и если далее выполняются какие-либо действия (очистка, копирование, запуск игры), то они выполнятся. Напр., если на карте присутствует утечка, то vrad всё равно будет считать освещение, несмотря на то, что vvis толком не отработал. И получившийся результат скопируется в игру (возможно, заменив нормальную карту, откомпиленную ранее). С make'ом такого сценария не произойдёт, он остановится сразу после того как vvis вывалится с ошибкой.
К сожалению, это не только плюс, но и минус make'a. Впрочем, проблема не столько в нём, сколько в командной строке самой винды. Дело в том, что команда del будет выдавать ошибку (т.н. exit code, если 0 — всё в порядке, другое число — ошибка), если не найдёт файл, который надо удалить. А т.к. данный мэйкфайл удаляет лог компиляции перед началом самой компиляции, то при первой попытке запуска make full дело до неё вообще не доходит. И ключи /Q /F не помогают (в то время, как у rm есть опция -f которая заставляет утилиту молчать). Однако, я обнаружил окольное решение: проверять наличие файла перед его удалением (что, в принципе, в любом случае стоит делать, я постоянно использую это в батниках). И это сработало.
Пожалуй, теперь скрипты вверху описывать незачем, ведь это всего лишь последовательности выполнения предыдущих команд.

Ну что скажете, полезный makefile, удобный?
На самом деле, толку от него немного, потому что он не использует главную особенность make. Посмотрите внимательно на makefile ещё раз и сравните его с самым первым примером. В чём разница между ними? В том, что в новом мэйкфайле нет настоящих целей, только команды и скрипты. Мы нигде не указываем мейку, что ему нужно получить, и из чего, он ничего не знает об этом. Почему это так важно? Суть мейка, его главная фича в том, что он контролирует процесс сборки и делает только те шаги, которые необходимы. Возвращаясь к примеру с hello.exe, если в папке уже присутствует готовый exe-шник, то make не будет его заново переконпелять. Однако, если мы изменим hello.c (совсем чуть-чуть, или просто пересохраним, или освежим дату изменения юниксовой утилитой touch), то компиляция запустится. Я не знаю точно, как это работает, но насколько я понимаю, make просто сравнивает даты создания/изменения. Если у "продукта" дата изменения раньше, чем у исходника — то нужно перекомпиливать, в ином случае, мейк делать этого не будет.
Это очень удобно, особенно на сложных проектах, состоящих из множества файлов. Если часть из них уже находится в готовом виде, то мейк просто пропустит их компиляцию и обработает только изменившиеся файлы. Главное, что нужно помнить, чтобы это работало — не делать автоматическую очистку, как было сделано в вышеприведённых примерах. Если мейк не найдёт промежуточный файл, он обязательно запустит процесс его создания, а т.к. даты нового промежуточного файла и конечного будут разниться, то конечный тоже перезапишется. Поэтому, чтобы это работало в примере hello, оттуда нужно убрать команду clean из скрипта auto (оставив только компиляцию и установку).
Мы можем пойти дальше и усовершенствовать пример с hello.exe ещё больше. Предположим, что мы забыли, что наша программка уже установлена, и запустили make повторно. Что произойдёт в таком случае? Вы могли предположить, что раз мейк такой умный, то он "понял" что hello.exe не изменялся, а значит, не произойдёт ничего. Но это не так. Мейк тупой. Компиляцию hello.exe он не запустит, а вот копирование всё равно произойдёт. Проблема в том, что мейку нужно конкретно указывать, что из чего получается, иначе он просто не увидит связи, не проверит эти файлы, а слепо выполнит предписанное. Команда install не даёт мейку никакой информации, с которой он мог бы оперировать. Но это легко исправить. Нужно просто превратить команду в цель. Для этого, вместо "install:" мы должны написать "продукт: источник". Несмотря на то, что копирование, казалось бы, не имеет ничего общего с компилированием (хотя слова, внезапно, похожи), оно тоже принимает на вход некий источник (копируемый файл) и выдаёт результат (скопированный файл). Осталось это только записать, но здесь тоже нет никаких сложностей, благо мы используем переменные. Скопированный файл (результат) будет выглядеть так: $(INSTALL)/$(NAME).exe, а источник просто $(NAME).exe (потому что наш мэйкфайл находится в той же папке, что и скомпилированный hello.exe). Т.о., инсталляционный код будет выглядеть так:

$(INSTALL)/$(NAME).exe: $(NAME).exe
    cp $(NAME).exe "$(INSTALL)"

К сожалению, если мы захотим выполнить только инсталляцию, это будет сложно, потому что надо будет помнить и установочный путь, и имя файла, итоговая строка будет выглядеть так: make /cygrdive/c/Program File/hello.exe (обратите внимание, что она пишется как есть, с пробелами, если поставите кавычки здесь или в самом мэйкфайле — вылезут ошибки, работать не будет). Весёленькая строчка, не правда ли? Впрочем, под Цыгвином весьма удобно то, что для мейка есть автодополнение по табу, но в любом случае, гораздо удобнее сделать скрипт, который просто вызовет эту длинную команду. Называться этот скрипт будет, внезапно, install. В итоге, у нас получится вот такой makefile:

(к этой картинке прикреплён архив с примером; makefile чуть-чуть отличается, добавил автоматический запуск и убрал везде расширений .exe — и так работает, зато мэйкфайл становится кроссплатформенным, его можно запустить на линуксе без изменений (ну кроме пути, конечно же))

А теперь — сюрприз. Обратите внимание на секцию макросов. auto вызывает только install. По большому счёту, auto теперь вообще не нужен, всё равно install и так идёт следующим, но я оставил его для наглядности. Как же так, make будет сразу инсталлировать программу? Но что он будет инсталлировать, если программа ещё не скомпилирована?
В этом заключена ещё одна особенность make'a. Обнаружив install, он увидит, что в качестве источника (ведь вы же не забыли, что команды, скрипты и цели — это одно и то же?) для этой цели используется $(INSTALL)/$(NAME).exe. make ищет эту цель, и находит её, и видит, что она, в свою очередь, в качестве источника использует $(NAME).exe. Теперь make ищет в мэйкфайле цель $(NAME).exe. Эта цель тоже в наличии, она использует в качестве источника $(NAME).c. Такой цели в makefile нет, поэтому он ищет этот файл на диске, находит, затем ищет файл $(NAME).exe, и если находит — сравнивает даты изменения. Если $(NAME).c свежее, чем $(NAME).exe, запускается выполнение команды для достижения цели $(NAME).exe. Если же нет — make пропускает этот шаг и сразу переходит к следующему, $(INSTALL)/$(NAME).exe, и опять проверяет даты изменения файлов. Если цель старше источника — происходит копирование. Если нет — make завершает свою работу сообщением "цель не требует выполнения команд" (к шагам install и auto он уже не переходит, потому что это не настоящие цели, а всего лишь ссылки, на что указывает директива .PHONY).
Таким образом, нет необходимости подробно описывать каждый шаг выполнения makefile, если цели взаимосвязаны между собой, и одно тянет за собой другое — мейк всё равно проследует по цепочке. В этом принципиальное отличие makefile от bat-ника — последний выполняется последовательно, шаг за шагом, первый же обрабатывается сразу, выясняются зависимости, и затем уже происходит выполнение по цепочке. Поэтому порядок расположения целей в мейкфайле не так важен.

На этом дописывание и разбор примера "hello" закончен. Но это была только разминка перед финалом. Теперь самое сложное — "правильный" скрипт для компиляции карт.

(к картинке прикреплён архив с файлом, или копипастьте с pastebin)
Он заметно отличается от предыдущего "мапперского мэйкфайла". Здесь нет фаст-компиляции, только команда full. Вот как она будет выглядеть компиляция с её помощью:

Если мы попытаемся запустить make full два раза подряд, то во второй раз уже увидим только это:

Потому что все файлы у нас уже есть, мэйку остаётся только запустить игру.
А вот что произойдёт, если на карте присутствует утечка:

И если мы скомпилили и проверили нашу карту под бетой, для релиза нам не придётся её перекомпиливать, сразу пойдёт конвертация:

Как видно из последнего скрина, здесь есть установка и запуск релизной игры. К сожалению, с нею связана небольшая неприятность: несмотря на все ухищрения, make всё равно будет копировать карту для релиза в папку с игрой, причём почему-то два раза подряд (ичсх, в цыгвине присутствует точно такой же баг). С установкой на нанобету такого не происходит, вероятно, проблема в том, что релизная игра находится на другом диске... Из-за этого у меня, кстати, и сама релизная игра не запускается, но проблема в том, что это древнераспак: если находясь на диске C: вбить в командную строку D:\TempGames\Half-Life 2\hl2.exe -steam, игра не запустится, а вот HL2UE6 в аналогичной ситуации работает.
В остальном всё работает (не забывайте про нюанс с setx), и вы можете проверить работу мэйкфайла на бете+, для которой он и создавался. Для этого вам потребуется скачать бету+, мэйк, мэйкфайл, и опционально — какую-нибудь заставочную карту с исходниками, но вообще, в бете+ уже есть мапа-пример, надо только подправить в мэйкфале имя и пути. Не забывайте, что мейк и мэйкфайл нужно ложить в bin\. Запустить его можно несколькими способами:
 – открыть командную строку и вбить "make макрос";
 – создать батник или ярлык, который будет запускать make с нужными параметрами;
 – отредактировать makefile и подставить в auto вместо help то, что нужно, а затем просто запустить make.exe;
 – добавить в Хаммер команду "make.exe макрос". Советую отключить Process window. Во-первых, не будет корректно отображаться, во-вторых, бета при запуске из хаммера зависает (по крайней мере, у меня так), что лечится только сворачиванием хаммера перед запуском, а с активным Process window это не получится (обратите внимание, что при этом make должен выполняться самым последним, после него не должно быть ничего! Первым же действием должна быть смена директории на $exedir\bin).


Выводы.

Нужно наконец-то отметить, чем же make отличается от батников. Все основные особенности уже были озвучены выше, но было бы неплохо собрать их в одном месте и сравнить. Заодно мы посмотрим, можно ли реализовать функционал мейка в батниках (только на словах, но если вас это заинтересует, я могу попробовать составить такие батники в будущем):
1. В одном мэйкфайле можно перечислить сразу несколько разных инструкций, например, компиляция и очистка, установка и удаление. Нужно только задать параметром к make имя нужного действия. Мы можем задавать цепочки действий и выполнять их одной командой.
В принципе, даже в батниках, при желании, мы можем наворотить что-то аналогичное. Для этого достаточно использовать метки, call и goto, а затем вызывать "батник метка".
2. make проверяет время изменения файла, и выполняет действие только если продуцируемый файл старше исходника.
Пожалуй, самая важная функция мейка. Тем не менее, её вполне можно попытаться реализовать на батниках, например, Tupas использовал время создания/изменения для именования конвертируемого файла, но конечно, написание такой функции потребует некоторых усилий и времени и её постоянно надо будет как-то вызывать вручную из батника, make же берёт эту задачу на себя, нам остаётся только правильно составить makefile.
3. make сразу прекращает выполнение при возникновении ошибки.
Пример с возникновением утечки наиболее показателен. Но по-моему, в батниках тоже можно отловить exit code приложения и в случае ненулевого значения оборвать выполнение. Но опять-таки, в мейке ради этого не нужно писать ничего дополнительно, мы можем вообще не задумываться об этом (кроме случаев, когда эта фича мешает, конечно).
4. make сам следит за зависимостями и осуществляет необходимые операции, если чего-то не хватает.
Этот пункт является закономерным результатом второго и третьего. Если не хватает какого-то файла — мейк переходит к действию, которое продуцирует его, например, вызывая команду "install: $(FILE)", мейк проверяет, а скомпилирован ли файл, который нужно установить, не устарел ли он, и если что не так — то запускает компиляцию сперва, а если она невозможна — обрывает выполнение. Главное — правильно составить makefile, чётко указав, что из чего получается. Если всё указано верно, то make сам разберётся, что и в каком порядке выполнять, нам нет необходимости жёстко задавать порядок. В случае батников нам приходится это делать, и чтобы процесс не пошёл не в ту сторону или не выполнялась куча бессмысленных действий, приходится снабжать каждый шаг кучей проверок.

Таким образом, видно, что функционал мейка достаточно прост, чтобы его — более-менее — можно было выполнить на батниках. Однако, такой код будет достаточно нетривиальным, и, скорее всего, сложным, аналогичный makefile будет намного короче и проще для понимания. Поэтому, пользуясь возможностями make'а, легче будет написать более сложный и навороченный скрипт, чем попытаться реализовать аналогичный функционал на голом batch'e.

Напоследок отмечу, что компиляция карт — это, конечно же, не всё, что можно автоматизировать с помощью make, аналогично можно компилировать модели, спрайты, конвертировать текстуры и, конечно же, код, хотя в этом случае лучше уже использовать средства MSVS. Под Linux/Unix make используется весьма широко, но стоит заметить, что сложные makefile'ы в любом случае не пишутся вручную, вместо этого проще использовать специальные утилиты-генераторы, но в нашем случае это излишне.

P.S. Имейте в виду, что на изучение make я пока потратил всего один день (+ ещё день на эксперименты и написание выложенных мэйкфайлов + три дня на написание и подготовку этого поста), так что итоговый makefile наверняка неоптимальный, и, скорее всего, ещё будет дорабатываться.