The Complete Radiant Handbook

[MadGypsy]

I have come to realize something. I have played around with a bunch of Quake modding and learned a lot. However, even though I could probably make my own TC at this point, I still do not consider myself a Quake Modder.

Why? You may ask. Well, it's just not in my heart. I am not passionate about it. What I have always been (oddly) passionate about is modding radiant. From making the build menu my bitch, to creating my own game packs and more, I am always looking for that next little thing in radiant that most people would never even consider.

I know that I still don't know everything about radiant but I promise you I know a whole friggin lot. I am going to use this thread to expose everything that I know...I mean EVERYTHING. From the interface all the way down to what every single thing in local.pref does and more.

This is going to take time and it is going to be very very long. I will even go as far as to write an error list that will explain how to fix everything you are going to break.

My goal is to make you a Kung Fu master at radiant. I will begin tutorials later today and then follow up as I have time every day thereafter.

[MadGypsy]

Lesson 1: Understanding the Radiant File Structure

In this first lesson we are going to build a custom gamepack (your.game).

First create a folder named your.game ( C:/path/to/radiant/your.game/ ). Now open your.game and create a folder inside of it named Game. ( C:/path/to/radiant/your.game/Game/ ).

Back out of the folders to the radiant root and open the games folder ( C:/path/to/radiant/games/ ). Inside of this folder you will notice .game files for all of the game packs you have installed for radiant. Create a new text file and rename it entirely to your.game

This file will contain load configuration directives. What that means is, when Radiant loads your game pack it is told what assets it can use and should look for. It is also told the directories which the game files will be stored in and what map features are available to this game type. In short, your.game is the definition file for your game type.

We are going to build a custom Quake 1 game definition file that actually expands the possibilities of the standard one. Open your.game and let's begin.

first copy and paste the below

<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>

Don't even worry about what any of that means. It has to be there for compliant markup and really has nothing to do with radiant.

now we have to add the one and only tag we will use

<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
<game />

That tag opens and closes itself so, all of our data is going to be in the form of attributes within that tag.

<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
<game 
	name="value"
	name="value"
	name="value"
	name="value"
/>

The name="value" lines represents where we will put all of our information and how it should be written.

Ok, let's finally get down to what actually goes there and what it does. I will do a varying handful at a time and then explain.

type="your"
name="Mod Game"
enginepath_linux="c:/usr/local/games/quake/"
enginepath_win32="c:\Quake\"
engine_win32="darkplaces.exe"
engine_linux="darkplaces-sdl"

type - this always seems to be named after the game pack.
name - whatever you write here will be the name used to select your game type by, upon radiant start-up

Set the path that matches your system to the proper one for the Quake folder and set the engine executable as well.

basegame="Game"
basegamename="Quake"
unknowngamename="Custom Quake Modification"
shaderpath="scripts"

basegamename - Quake/
basegame - Quake/Game/
shaderpath - Quake/Game/scripts/

edit: I am not saying you should write these paths. When I initially wrote this I felt it was self explanatory that this illustrated how the path was building due to your input.

ex: basegamename/basegame/shaderpath/

archivetypes="pak pk3 wad"
texturetypes="tga jpg png"
modeltypes="mdl md2 md3 obj"

archivetypes - these are files that radiant will look for/through when loading your game type. For instance, let's say that all of your quake files are in PAK0 and let's say you deleted pak from archivetypes - radiant now cannot find any of your game.
texturetypes- this only matters if you intend to display actual models in radiant. If you are using the default boxes then this is useless to you.
modeltypes- same as above. This tells radiant which model types you want to display in radiant.

maptypes="mapq1"
shaders="quake3"
entityclass="quake3"
entityclass="xml"
entities="quake3"
brushtypes="quake"
patchtypes="quake3"

There is a bit of confusion here. All of the things I defined here as quake3 are also defined as quake3 in the standard q1.game. This is like one of those "if it ain't broke, don't fix it" situations.

If you wanted to go full blown quake 3 you would change maptypes to "mapq3" and change brushtypes to "quake3". Those 2 simple changes unlock everything for quake 3 mapping in radiant. However, these tutorials do not cover the rest of the stuff necessary to map Q3 style.

I feel the only thing that needs explanation here is entityclass. XML tells radiant to use .ent files for the entity definitions, there is an alternative - I have never used or needed it, nor will it be explained by me in any of my tutorials, nor is it used by any current game packs.

your final .game file should be very similar to this:

<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
<game
	type="your"
	name="Mod Game"
	enginepath_linux="c:/usr/local/games/quake/"
	enginepath_win32="c:\Quake\"
	engine_win32="darkplaces.exe"
	engine_linux="darkplaces-sdl"
	basegame="Game"
	basegamename="Quake"
	unknowngamename="Custom Quake Modification"
	shaderpath="scripts"
	archivetypes="pak pk3 wad"
	texturetypes="tga jpg png"
	modeltypes="mdl md2 md3 obj"
	maptypes="mapq1"
	shaders="quake3"
	entityclass="quake3"
	entityclass="xml"
	entities="quake3"
	brushtypes="quake"
	patchtypes="quake3"
 />

You have just completed the first step in creating your own game pack for radiant. Radiant now knows what to look for/use and how to act upon loading your game type. There is still more to do, but we are going to put this lesson on pause for a bit. I will return later with the next steps.

[MadGypsy]

Ok, I am back and we are going to add some important things to our file. open games/your.game.

This was a bit of a mistake on my part but it will be simple to add.

default_scale="1.0"
no_patch="1"
no_bsp_monitor="1"
show_wads="1"

default_scale - honestly, with a value like 1.0, I would assume this line is absolutely useless. Know it's there.
no_patch - this is q1 mapping so we can't use patches.
no_bsp_monitor - this is so important. This is like a failure in the original q1.game. They have this set to 0. Which means it is monitoring your bsp and it will kill your build menu. It will tell you that file paths don't exist even though they do. You do not want bsp monitoring on for mapq1 compiling (at the least).
show_wads - yeeeah...we want to see these.

this data can be added after unknowngamename

<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
<game
	type="your"
	name="Mod Game"
	enginepath_linux="c:/usr/local/games/quake/"
	enginepath_win32="c:\Quake\"
	engine_win32="darkplaces.exe"
	engine_linux="darkplaces-sdl"
	basegame="Game"
	basegamename="Quake"
	unknowngamename="Custom Quake Modification"
	default_scale="1.0"
	no_patch="1"
	no_bsp_monitor="1"
	show_wads="1"
	shaderpath="scripts"
	archivetypes="pak pk3 wad"
	texturetypes="tga jpg png"
	modeltypes="mdl md2 md3 obj"
	maptypes="mapq1"
	shaders="quake3"
	entityclass="quake3"
	entityclass="xml"
	entities="quake3"
	brushtypes="quake"
	patchtypes="quake3"
 />

I assure you we are done with this file.

Save and close your.game. Back out to the radiant root folder and now open the your.game folder (I know this is annoying, name-wise. It's Radiant's naming convention. There is nothing we can do). Inside of your.game/ you should have a folder named Game/

open that folder and create a new text document named "entities.ent". This is going to be your entity definitions file and we are going to make one right now. Open the file and paste the below into it

<classes>
	<point name="info_player_start" color="1 0 0" box="-16 -16 -24 16 16 24">
		<angle key="angle" name="'Yaw Angle"/>
	</point>
	<point name="light" color="0 1 0" box="-8 -8 -8 8 8 8">
		<real key="light" name="Light Value"/>
	</point>
	<group name="worldspawn" color="0 0 0">
		<string key="wad" name="Wad Files"/>
	</group>
</classes>

This is the least amount you can have and still make a working map. Save this file as entities.ent and close it. If you would like to learn more about how to extend an .ent file, I wrote a tutorial here

Back up one level to ../radiant/your.game/. Create a text document and name it "default_build_menu.xml". Open it and paste the below into it.

<?xml version="1.0"?>
<project version="2.0">
	<build name="Empty">
	</build>
</project>

This is the barest of bones for a build menu. It does nothing but trick radiant into not throwing an error upon start-up. If you want to learn about the radiant build menu, I have actually written 2 tutorials - ver1 and ver2

One thing to always remember about the build menu is: If you are getting errors saying that directories don't exist, but they do, you have build process monitoring on. You would turn that off in edit/preferences/ scroll down to build/uncheck Enable Build Process Monitoring and apply. You shouldn't get that error if you have no_bsp_monitor="1" in games/your.game.

For absolute clarity, these are all the paths and files that you should have created so far.

radiant/your.game/ - folder
radiant/your.game/default_build_menu.xml
radiant/your.game/Game/
radiant/your.game/Game/entities.ent
radiant/games/your.game - text file

For all intents and purposes, you have a finished game pack. The only thing left to do is go create the directories and dump some of quake in it.

You will need:


1) Quake/Game/
2) Quake/Game/scripts/ - if you intend to use shaders
3) Quake/Game/progs.dat
4) Quake/Game/some_wad.wad
5) Quake/Game/maps/

That is the absolute bare bones according to your entities.ent, and expected wad.

And there you go. You have just completed your own game pack for Radiant. You should now be able to make maps based on your custom game type. Simply start radiant and when prompted to choose a game type, choose "My Mod" or whatever it was that you wrote for name in games/your.game. In it's current state you could build a world with light that a user could navigate.

[MadGypsy]

Lesson 2: how your gamepack affects preferences

Radiant stores all of your preferences in a file named local.pref. Depending on which Radiant you are using and how it is set up, there are varying degrees of complication in finding local.pref.

If you are using NetRadiant and you have made it portable, you will find local.pref in RADIANT_ROOT/settings/1.5.0/your.game/local.pref

if you are using anything other than a portable NetRadiant, I know of one easy way to find this path, but it will only work if you have the build menu working.

1) drop a brush on the canvas and build
2) look at the radiant info panel that spans the bottom of the GUI, you will see:

"Build information will be saved to path/to/settings/1.5.0/junk.txt"

That is the path your local.pref will be in. If you do not have the build menu working do a system search for local.pref file or 1.5.0 folder.

local.pref is essentially the final Radiant config for all preferences. Almost all of these preferences can be set in edit/preferences. Some of them however are initially set by games/your.game. These are the ones we'll be covering. You should know how your game pack is affecting your preferences.

If you have found local.pref open it in your text editor of choice. You will notice it is just another xml document and the items are all labeled epair. Honestly, I don't know what "epair" means, but I know what all of this does. Luckily, we aren't going to go over what everything does. We will only focus on how your game pack initially influences it.

One thing to understand before I go on is, this file was created by Radiant when you began a project using your game pack. And that's something you need to consider cause, that means Radiant may decide to overwrite this file. If you edit this file with radiant open, when you close Radiant, it overwrites it. It's a fickle mistress.

EnginePath - is set by the enginepath_(linux/win32) you provided in games/your.game and this directly ties into being a token in your build menu.
GameName - is set by the value you provided in games/your.game for basegame. This epair can also be used as a token in the build menu. The GameName epair does not exist in GTKRadiant
WatchBSP - is set by the value you provided in games/your.game for no_bsp_monitor, but this can be changed in preferences or by changing WatchBSP.

That's it.

[MadGypsy]

I'm pretty serious about writing this handbook and I was thinking about taking all my Radiant tutorials thus-far, polishing them up and converting them to a single pdf. This would mean that I would need a cover...

whatdyathink?

[Syluxguy28O3]

do it. 1 more guide will create a resource people can peek at, as well as answer alot of common questions.

[MadGypsy]

My goal is to initially write it all here and then make a totally polished PDF from it and sell it for $3. I'm not trying to make any money (per se) but if I go as far as I see in my head... my completely finished PDF will be worth a hell of a lot more than $3. The price and the fact it costs anything at all is more for people to be able to show support. If someone didn't have $3 and really wanted it I would give it to them for free.

If I can look back on it all and say "Wow, I made an average of .27 cents an hour" It would be .27 cents more an hour than I've made writing anything else.

[bluntz]

You can only fail by not doing it.

[MadGypsy]

I know, but I completely abandoned Quake projects due to lack of participation and being told to take breaks. I'm under the impression that nobody wants me to make Quake stuff so, I stopped.

[gdiddy62]

Cover looks good and a single polished pdf would be great!

[MadGypsy]

The cover was a joke. It's not obvious?

I thought the incomplete version of the complete handbook was funny. However, maybe in the future I will like quake again and actually finish it. Calling it the complete handbook is a bit retarded though. Radiant already comes with a complete manual. This is more like a pamphlet of the background radiant stuff - like the build menu, ent file, etc. Basically this could be summed up to me teaching you how I made virtuoso_q1 game pack and what all the different settings for that do.

[bluntz]

The cover was a joke. It's not obvious?

I thought the incomplete version of the complete handbook was funny. However, maybe in the future I will like quake again and actually finish it. Calling it the complete handbook is a bit retarded though. Radiant already comes with a complete manual. This is more like a pamphlet of the background radiant stuff - like the build menu, ent file, etc. Basically this could be summed up to me teaching you how I made virtuoso_q1 game pack and what all the different settings for that do.

So change the name to something like :
Adventures in Radiant
The hitchhiker's guide to applications in mapping for virtual reality.
You only fail the plan if you plan to fail.
You have set yourself a goal so don't forget what goal actually stands for:
GET OUT AND LOOK=goal
A resource that has practical examples and ease of understanding is sorely needed for not only this old game but many many others using radiant.A cheap PDF may make your time doing it far more rewarding than you realize.Certainly more than some cheap praise from a few gawkers.

[Dutch]

This tutorial has reinforced what I gained from pouring over the gamepack you gave me. Thank you.

Honestly, I can't believe the lack of interest in Radiant. I think people are intimidated by the setup it takes. But after a few hours of messing with it, it is hands-down the most powerful map editor out there. The tutorials offered by you and golden_boy take a lot of the guess-work and learning curve out of it.

It's a shame because people are still, to this day, cranking out Quake maps with sub-par editors in comparison to Radiant. Not using this software to its potential is like buying a Shelby GT500 and never going above 25mph.

I was stuck on Qoole 2.50. You could not make build menus (not even sure you could use any compilers besides the old school BSP1 compilers included), .ENT files were only recognized through code (forget mapping for mods if you don't have the source and a compiler for the editor), awful bugs and glitches with geometric floating point issues...the list goes on. In short, Radiant is pure gold compared to what I was used to.

Rest assured, despite the lack of interest, you've managed to get one more mapper/modder on board.

If I have any questions, I'll throw them in one of your threads. Hopefully mappers can start formulating a better opinion about the editor.

[talisa]

love radiant myself, i always use GTKradiant myself to map.

used GB's tuts on how to set it up and get started with mapping, and with gypsy's and GB's and spike's help i been able to get started and make fancy stuffs

like i once for fun completely remade skulltags invasion1 map for quake once using GTKradiant, including spawning monsters

http://quakeone.com/forums/quake-tal...tml#post135070