Difference between revisions of "Compiling:Makefiles"

From Custom Map Makers Wiki
Jump to: navigation, search
(Multimapping - Diff/Merge on maps)
 
(2 intermediate revisions by the same user not shown)
Line 210: Line 210:
 
  make light pk3 install test
 
  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:
+
to build a pk3-file with light, pack it, link it in your system (linking doubled dont hurt) and start urt after compiling/packing with the map automatically loaded. 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)
 
  bsp (just build bsp)
Line 231: Line 231:
  
 
stuff labled with multimapping is explained below.
 
stuff labled with multimapping is explained below.
 +
 +
=== Examples ===
 +
Lets say you have your map and want to test it.
 +
make light surface pk3 install test
 +
compiles your map (with surface-sounds), packs it and starts urt for testing.
 +
After you tested the map you want to show it off to the "public" on your private, passwordprotected server.
 +
make deploy testserver
 +
Make recognizes that the map has not changed, thus all files are up2date and just uploads your version to the server, reloads the server via rcon and connects on it with the password given in the makefile.
 +
This way you can rapid-test your map with many people easily. You could also combine it and compile a
 +
make light surface pk3 install deploy
 +
over night and as soon as its finished everyone on the server gets the new version (if auto-download is set up correctly). They can already test it while you are still sleeping/at work/busy elsewhere and you get test-reports as soon as possible (if you depend on them).
 +
You can also shortcut your urt-launch with a
 +
make testserver
 +
so you dont have to select your map and everything.
  
 
== Multimapping - Diff/Merge on maps ==
 
== Multimapping - Diff/Merge on maps ==
Line 246: Line 260:
 
  make merge
 
  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
+
and both changes are merged (a backup with the current timestamp is created before merging in case something goes horribly wrong). Conflicts get resolved and a new base is born. This base gets delivered to the other mapper via
  
 
  make newbase
 
  make newbase

Latest revision as of 11:57, 10 January 2012

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
PROJECT           = $(shell basename `pwd`)
LOCATION          = $(shell pwd)/
WORKDIR           = build/
SRCDIR            = src/
TOOLDIR           = tools/
ARDIR             = archive/
PK3DIR            = pk3/
CONFDIR           = conf/

really: don't change!

# 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
DEPLOY_SERVER     = myserver.example.com
DEPLOY_USER       = username
DEPLOY_PASS       = password
DEPLOY_DIR        = /

for automatic uploading to an ftp-server. should be self-explaining.

DUSER             = diff-username (e.g. Drezil)
DOTHER            = diff-other_user (e.g. apath0)

if using NuLL's diff/merge-mapping-tool you need to setup this. normally not needed.

# rcon-stuff
RCON_SERVER       = myurtserver.example.com
RCON_PORT         = 27960
RCON_PASSWORD     = rconpassword
SERVER_PASSWORD   = private_password

for reloading the map on a server after its uploaded. normal rcon/server-data. Privatepassword is for joining the server (if its private)

# local urt
URT_BINARY        = /home/juser/UrbanTerror/ioq3-urt

your urt-binary

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


An example of a more complex linking is presented here (taken from my map ikarus):

sdressel@Behemoth#173:~/mapping/make/ikarus/distrib$ la *
env:
insgesamt 8,0K
drwxr-xr-x 2 sdressel sdressel 4,0K 2009-11-08 12:44 .
drwxr-xr-x 9 sdressel sdressel 4,0K 2009-07-25 21:25 ..
lrwxrwxrwx 1 sdressel sdressel   36 2011-11-05 18:01 apath0_storm -> /home/quake3/q3ut4/env/apath0_storm/
lrwxrwxrwx 1 sdressel sdressel   35 2011-11-05 18:01 hip_violent -> /home/quake3/q3ut4/env/hip_violent/
lrwxrwxrwx 1 sdressel sdressel   31 2011-11-05 18:01 horizon -> /home/quake3/q3ut4/env/horizon/

levelshots:
insgesamt 8,0K
drwxr-xr-x 2 sdressel sdressel 4,0K 2012-01-02 19:57 .
drwxr-xr-x 9 sdressel sdressel 4,0K 2009-07-25 21:25 .. 

maps:
insgesamt 8,0K
drwxr-xr-x 2 sdressel sdressel 4,0K 2012-01-02 19:57 .
drwxr-xr-x 9 sdressel sdressel 4,0K 2009-07-25 21:25 ..

models:
insgesamt 12K
drwxr-xr-x 3 sdressel sdressel 4,0K 2011-12-10 00:15 .
drwxr-xr-x 9 sdressel sdressel 4,0K 2009-07-25 21:25 ..
lrwxrwxrwx 1 sdressel sdressel   33 2011-12-10 00:15 ikarus -> /home/quake3/q3ut4/models/ikarus/
drwxr-xr-x 2 sdressel sdressel 4,0K 2011-12-10 13:00 mapobjects
lrwxrwxrwx 1 sdressel sdressel   38 2011-11-05 18:01 streetlight -> /home/quake3/q3ut4/models/streetlight/

scripts:
insgesamt 52K
drwxr-xr-x 2 sdressel sdressel 4,0K 2011-12-11 19:33 .
drwxr-xr-x 9 sdressel sdressel 4,0K 2009-07-25 21:25 ..
lrwxrwxrwx 1 sdressel sdressel   40 2011-11-05 18:01 camera.shader -> /home/quake3/q3ut4/scripts/camera.shader
lrwxrwxrwx 1 sdressel sdressel   44 2011-11-05 18:01 horizonsky.shader -> /home/quake3/q3ut4/scripts/horizonsky.shader
lrwxrwxrwx 1 sdressel sdressel   49 2011-11-05 18:01 ikarus_fountain.shader -> /home/quake3/q3ut4/scripts/ikarus_fountain.shader
lrwxrwxrwx 1 sdressel sdressel   40 2011-11-05 18:01 ikarus.shader -> /home/quake3/q3ut4/scripts/ikarus.shader

sound:
insgesamt 8,0K
drwxr-xr-x 2 sdressel sdressel 4,0K 2009-07-21 15:37 .
drwxr-xr-x 9 sdressel sdressel 4,0K 2009-07-25 21:25 ..
lrwxrwxrwx 1 sdressel sdressel   32 2011-11-05 18:01 ikarus -> /home/quake3/q3ut4/sound/ikarus/

textures:
insgesamt 8,0K 
drwxr-xr-x 2 sdressel sdressel 4,0K 2009-07-29 22:13 . 
drwxr-xr-x 9 sdressel sdressel 4,0K 2009-07-25 21:25 ..
lrwxrwxrwx 1 sdressel sdressel   40 2011-11-05 18:01 alpha_trees -> /home/quake3/q3ut4/textures/alpha_trees/
lrwxrwxrwx 1 sdressel sdressel   35 2011-11-05 18:01 camera -> /home/quake3/q3ut4/textures/camera/
lrwxrwxrwx 1 sdressel sdressel   42 2011-11-05 18:01 ikarus_decals -> /home/quake3/q3ut4/textures/ikarus_decals/
lrwxrwxrwx 1 sdressel sdressel   42 2011-11-05 18:01 ikarus_detail -> /home/quake3/q3ut4/textures/ikarus_detail/
lrwxrwxrwx 1 sdressel sdressel   41 2011-11-05 18:01 ikarus_floor -> /home/quake3/q3ut4/textures/ikarus_floor/
lrwxrwxrwx 1 sdressel sdressel   41 2011-11-05 18:01 ikarus_light -> /home/quake3/q3ut4/textures/ikarus_light/
lrwxrwxrwx 1 sdressel sdressel   43 2011-11-05 18:01 ikarus_liquids -> /home/quake3/q3ut4/textures/ikarus_liquids/
lrwxrwxrwx 1 sdressel sdressel   40 2011-11-05 18:01 ikarus_misc -> /home/quake3/q3ut4/textures/ikarus_misc/
lrwxrwxrwx 1 sdressel sdressel   39 2011-11-05 18:01 ikarus_sfx -> /home/quake3/q3ut4/textures/ikarus_sfx/
lrwxrwxrwx 1 sdressel sdressel   39 2011-11-05 18:01 ikarus_sky -> /home/quake3/q3ut4/textures/ikarus_sky/
lrwxrwxrwx 1 sdressel sdressel   42 2011-11-05 18:01 ikarus_terrain -> /home/quake3/q3ut4/textures/ikarus_terrain
lrwxrwxrwx 1 sdressel sdressel   41 2011-11-05 18:01 ikarus_walls -> /home/quake3/q3ut4/textures/ikarus_walls/

as seen there are also resources linked that are needed in many maps (skys, models, camera (mirrors etc.), trees, ...) but they are only present one time on your harddist and upon change you change them in EVERY single project in one go.

Compiling Maps

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 with the map automatically loaded. 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.

Examples

Lets say you have your map and want to test it.

make light surface pk3 install test

compiles your map (with surface-sounds), packs it and starts urt for testing. After you tested the map you want to show it off to the "public" on your private, passwordprotected server.

make deploy testserver

Make recognizes that the map has not changed, thus all files are up2date and just uploads your version to the server, reloads the server via rcon and connects on it with the password given in the makefile. This way you can rapid-test your map with many people easily. You could also combine it and compile a

make light surface pk3 install deploy

over night and as soon as its finished everyone on the server gets the new version (if auto-download is set up correctly). They can already test it while you are still sleeping/at work/busy elsewhere and you get test-reports as soon as possible (if you depend on them). You can also shortcut your urt-launch with a

make testserver

so you dont have to select your map and everything.

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 (a backup with the current timestamp is created before merging in case something goes horribly wrong). 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.