Compiling:Makefiles

Concept

Because you can do all of the compiling-stuff on the console you can automize everything. Makefiles are a simple way to go as they are basically developed for compiling Sourcecode. They keep track on when the files were changed and do only the necessary recompiles (etc. if you compiled vis and do a light afterwards without changes it will just compile light additionally).

Misato-san introduced this concept some time ago in the official UrT-Forums and it was developed further for more complex tasks.

Installation

Download the Skeleton and extract it inside an empty folder (e.g. ~/mapping/).

Dependencies

This Makefile uses some other tools (mostly available in your distributions repository), namely:

• wput (for uploading)
• wget (for downloading when using multimapping)
• perl (for changing rcon after upload; v5.12.4 works - but earlier versions should work, too).

on debian-based distributions (including ubuntu) this is just a

sudo apt-get install wget wput perl

Configuration

First open the Makefile in your skel-folder and fill out the marked sections. They are abbreviated shown here:

# Map version
MAP_VER           = _dev
>> leave this.

# Paths
#Editor directory for saving maps
ED_MAPDIR         = ~/.q3a/q3ut4/maps/
>> where the *.map-files are stored - in doubt leave it.
#Where to install maps
INSTALLDIR        = ~/.q3a/q3ut4/
>> where the *.pk3-files are stored - in doubt leave it.

# Const variables - no need to change this
>> really: don't!
PROJECT           = $(shell basename `pwd`)
LOCATION          = $(shell pwd)/
WORKDIR           = build/
SRCDIR            = src/
TOOLDIR           = tools/
ARDIR             = archive/
PK3DIR            = pk3/
CONFDIR           = conf/

# Compiler base flags
MC                = /home/juser/netradiant/install/q3map2.x86
>> your q3map2-binary
MC_FLAGS          = -game quake3 -threads 8
>> threads # should match your cpu-cores
MC_FS_FLAGS       = -fs_game q3ut4 -fs_basepath /home/quake3
>> fs_basepath is the path taken for textures etc. pp.
>> if you are going to follow the tutorial, leave it so.

# Stage specific flags
include conf/bsp.conf
include conf/vis.conf
include conf/light.conf
>> configs .. can be changed to i.e. dlight.conf for debug (=dirty) light etc.

# pk3 related
DISTDIR           = distrib/
#dirs to include in pk3, if they exist
DIST_INCLUDE      = maps/* scripts/* textures/* sound/* models/* icons/* env/*
>> don't change.

# deploy
>> for automatic uploading to an ftp-server. should be self-explaining.
DEPLOY_SERVER     = myserver.example.com
DEPLOY_USER       = username
DEPLOY_PASS       = password
DEPLOY_DIR        = /
>> if using NuLL's diff/merge-mapping-tool you need to setup this. normally not needed.
DUSER             = diff-username (e.g. Drezil)
DOTHER            = diff-other_user (e.g. apath0)

# rcon-stuff
>> for reloading the map on a server after its uploaded. normal rcon/server-data.
>> Privatepassword is for joining the server (if its private)
RCON_SERVER       = myurtserver.example.com
RCON_PORT         = 27960
RCON_PASSWORD     = rconpassword
SERVER_PASSWORD   = private_password

# local urt
>> your urt-binary
URT_BINARY        = /home/juser/UrbanTerror/ioq3-urt

Everything after that should not be needed to change.

Setting everyting up

For every map you make you make a seperate folder. Lets say your map is named ut4_uptown. Then you copy the skeleton into an uptown-folder:

cp -R skel/ uptown

now you once do a

make pdirs

a lot of stuff should appear. After everything there are 3 blank lines. After that the errors are posted (usually something like "source map not found"). This will automatically set up stuff and link the .map-file from your ED_MAPDIR directory. Basically you can now start to map (but you shouldn't. There is more!)

Mapper Installation

Normally you want a clean urt-version so you dont conflict with other peoples shaders, textures and whatever. Basically your map should be self-dependend. For this we set up a clean urt-copy. Download UrT (or clean and copy it) to another folder. We will go with /home/quake3/ Extract UrT to there. Then go into the q3ut4-subfolder and extract the zpak000_assets.pk3 and afterwards the (in 4.1.1 new) zpak001_assets.pk3. Everything you use for mapping is in here. Models, effects, textures, shaders etc. And you dont want to have everything copied for every map. Thus symlinks come into play as used later.

Linking Resources

As stated above we just link the resources we need for our map instead of copying them every time. If you have your texturs in your mapfolder (e.g. uptown) you have them stored in your urt-installation (e.g. /home/quake3/q3ut4/textures/uptown). Now you just go into your distrib-folder with

cd distrib/textures/

and link the files correctly:

ln -s /home/quake3/q3ut4/textures/uptown uptown

when you list your files with

ls -lha

you should see something like:

juser@machine:~/mapping/make/uptown/distrib/textures$ ls -lha
insgesamt 8,0K
drwxr-xr-x 2 juser juser 4,0K 2009-07-29 22:13 .
drwxr-xr-x 9 juser juser 4,0K 2009-07-25 21:25 ..
lrwxrwxrwx 1 juser juser   40 2011-11-05 18:01 uptown -> /home/quake3/q3ut4/textures/uptown/

and it should not appear in red (=broken) but in light blue (=linked). Now these files get automatically packed into your pk3. Other files are added the same way (e.g. shader):

cd ~/mapping/make/uptown/
cd distrib/scripts/
ln -s /home/quake3/q3ut4/scripts/uptown.shader uptown.shader

Compiling

If everything is set up correctly you just go to your map-folder and enter

make light pk3 install test

to build a pk3-file with light, pack it, link it in your system (linking doubled dont hurt) and start urt after compiling/packing. You can add/remove options as you like - they are executed in the order they are given. The given makefile includes:

bsp (just build bsp)
vis (does bsp + vis)
light (does bsp + vis + light)
pk3 (package everything. If mapname.bsp is not recent preceed a bsp)
install (link locally)
deploy (put onto configured server via wput and reloads the map after upload via rcon)
test (test locally)
testserver (test remotely)
surface (inject surface-file to bsp - filename: src/mapname.surface)
clean (delete everything generated)
uninstall (remove symlink locally)
getsurface (gets surface-file from server via wget (multimapping))
deploysurface (puts surface-file onto server via wput (multimapping))
getbase (gets the base-map (multimapping))
diff (makes a diff (multimapping))
merge (merges diffs (multimapping))
newbase (deploys a new base (multimapping))

stuff labled with multimapping is explained below.

Multimapping - Diff/Merge on maps

NuLL wrote a little programm for diff/merging maps. Scheme is simple. Both mappers start with the same base map. Both map. Everyone makes a diff. They exchange diffs. If noone interfered with the other one (e.g. edited the same brush) both merge and recieve the new base. In theory this works. Practically it mostly doesnt. We always did it this way:

make getbase

to get the new base. Open in and edit. One person makes a

make diff

and a diff is calculated and uploaded. The other person does a

make merge

and both changes are merged. Conflicts get resolved and a new base is born. This base gets delivered to the other mapper via

make newbase

The other mapper does a

make getbase

to get the new base and works on it. No changes between the diff and the getbase happen for the diffing mapper (as they will be lost). When you hang out on Teamspeak/Mumble it works quite well. When you aren't communicating this closely it gets harder.

Notice: The diff/merge tool supports many mappers but the makefile is currently only set up for two mappers using it.