Level Design / Mapping For Trepidation
There is a Compatibility layer so that Quake 3 and Star Trek Voyager Elite Force Maps will run on Trepidation. For the best luck mapping for Trepidation is to use EF Radiant, GtkRadiant or Q3Radiant.
More information on the compatibility layer and known issues can be found here: Map Compatibility Layer for Quake 3 and Star Trek Voyager Elite Force.
SkareKrow has put together a kit to aid in mapping for Trepidation with Q3 Radiant. You can get that here: trepradiant.rar. There are several threads in our forums as far as using this file. Check them out..
We’ll eventually have to recompile GtkRadiant itself with some new tools for the vehicles and whatever weapons we come up with…
The current development build has a lot of textures in the pk3 files.
Contents
MAPPING: LADDERS
Trepidation offers Ladder support that the original Quake3 code lacked. Map designers should make a box around your ladders. This box should be given a texture of “common/ladderclip”. Make the box a lot smaller than you would in EF.
Unlike EF, the ladderclip cant take up a lot of space. It needs to be just over the ladder because it acts as a clip that stops you but you can still climb up. This means you cant go onto the ladder and hold the jump button to go up like EF. You have to face the ladder and move forward.
MAPPING: LIQUID, LAVA, AND FOG.
textures/liquids/pool2 textures/liquids/lavafloor textures/liquids/kc_fogcloud3
Only one is water, the other too are (obviously) lava and fog. So far I’ve got them all at least scrolling correctly and bobbing up and down.
There is a testmap for water called liquid_test
MAPPING: WEAPONS
Trepidation // Quake 3 // Elite Force
Gauntlet // Gauntlet // Phaser
LFO Rifle // Machine Gun // Stasis Weapon
Shotgun // Shotgun // Scavenger Rifle
Grenade Launcher // Grenade Launcher // Grenade Launcher
Singularity Cannon // Rocket Launcher // Quantum Burst
Flame Thrower // Lightning Gun // Imod
M42 Gauss Rifle // Rail Gun // compression Rifle
Gata Gun // Plasma Gun // Tetrion Disruptor
Devastator // BFG // Arc Welder
REVOLVING DOORS
QUAKED statement for the mappers to use.
/*QUAKED func_door_rotating (0 .5 .8) START_OPEN CRUSHER REVERSE TOGGLE X_AXIS Y_AXIS This is the rotating door... just as the name suggests it's a door that rotates START_OPEN the door to moves to its destination when spawned, and operate in reverse. REVERSE if you want the door to open in the other direction, use this switch. TOGGLE wait in both the start and end states for a trigger event. X_AXIS open on the X-axis instead of the Z-axis Y_AXIS open on the Y-axis instead of the Z-axis You need to have an origin brush as part of this entity. The center of that brush will be the point around which it is rotated. It will rotate around the Z axis by default. You can check either the X_AXIS or Y_AXIS box to change that. "model2" .md3 model to also draw "distance" how many degrees the door will open "speed" how fast the door will open (degrees/second) "color" constantLight color "light" constantLight radius */
Your mapper should know how to deal with this, but the programmer should also have a little insight on this as well. This is an entity definition for Q3Radiant. When added into the file, entities.def (via a text editor) , this will appear as an option available to the mapper when adding objects into the map, such as spawnpoints, weapons, and in this case, doors. The first line is very important as that tells the function in our actual code what spawnflags will be used for this particular object. The order of objects in the first line must not be altered in anyway, as that will cause instructional problems between the map's options and the code's functions.
The remaining lines in the statement gives the mapper extra information on what to add to the object to actually make it work. Should the mapper forget some required values, such as the speed, we have placed a condition in our code so that a default value is used if this happens.
MAPPING: BREAKABLE ITEMS
Mappers need to first, make it a func_door(anything will do) then press “n” and change the func_door to func_breakable, or optionally edit the “entities.def” file and add in func_breakable, so you can just select it from the normal drop down list in Q3Radiant. They also need to set the life of the glass by pressing “n” while selecting the entity and in the key box type in “health” and in the value box type in whatever NUMBER of life it should have. If you dont it defaults to 5 life.
Your mapper needs to add the ifx.shader into their base/scripts directory
You will want he/she to edit the shaderlist.txt in their base/scripts directory and add at the VERY bottom ifx
Your mapper needs to have done that so upon compile it does the lightmap and everything correctly.
AREAS OF A MAP WITH UNIQUE SPEED AND/OR GRAVITY
It is possible with trepidation for level designers to specify specific areas of their map that have a completely different movement speed or gravity than other parts of the map. Here is some information on this new functionality:
//============================================================================= /*QUAKED target_gravity_change (1 0 0) (-4 -4 -4) (4 4 4) GLOBAL By Vincentk, for instructions read the info at the spawnflags. -------- KEYS -------- GLOBAL - Apply to the entire world, and not just the activator -------- SPAWNFLAGS -------- gravity : Normal = 800, valid range: >= 0 surfaceFlag : Important setting. With this you can define on what surface the gravity_change will work. As soon as the player hits another surface, the gravity_change will be stopped. Don't change the surface too close below, since this check will go down! The gravity_change also stops at player-respawn. Possible values: CONTENTS_NODROP 0 -> Recommended and default value, since lower-gravity will make things float anyway. CONTENTS_SOLID 1 CONTENTS_LAVA 2 CONTENTS_SLIME 3 CONTENTS_WATER 4 CONTENTS_FOG 5 CONTENTS_DETAIL 6 -> Can easily be set in Radiant, so also quite easy. CONTENTS_STRUCTURAL 7 -> " " (also recommended as grav-surface, so something else can be set as detail (to reset)) CONTENTS_TRANSLUCENT 8*/ //=============================================================================
/*QUAKED target_speed_change (1 0 0) (-4 -4 -4) (4 4 4) GLOBAL By Vincentk, for instructions read the info at the spawnflags. -------- KEYS -------- GLOBAL - Apply to the entire world, and not just the activator -------- SPAWNFLAGS -------- speed : Normal = 320, valid range: > 0 surfaceFlag : Important setting. With this you can define on what surface the speed_change will work. As soon as the player hits another surface, the speed_change will be stopped. Don't change the surface too close below, since this check will go down! The speed_change also stops at player-respawn. Possible values: CONTENTS_STRUCTURAL 0 -> Recommended and default value, so something else can be set as detail (to reset) CONTENTS_DETAIL 1 CONTENTS_LAVA 2 CONTENTS_SLIME 3 CONTENTS_WATER 4 CONTENTS_FOG 5 CONTENTS_NODROP 6 CONTENTS_SOLID 7 CONTENTS_TRANSLUCENT 8*/ //=============================================================================
A sample map is included called "gravtest"
TEXTURE NAMING PROTOCOL
I use a prefix to split the textures into category and easy reference.
Here the list of prefix:
al_ = alpha chanel b_ = building d_ = decalc deco_ = decoration ex_ = exterior s_ = structure sy_ = system only texture m_ = mecanic f_ = furniture sh_ = shader only texture t_ = terrain fx_ = special f/x
Here some examples of texture names:
A grass texture will be name: t_darkgrass01.jpg
A glowing light fixture will be name: f_mainlight01.jpg, f_mainlight01_glow.jpg
A see-though crate texture will be name: al_crate01.jpg
That's it, that's how I work... If you think it make sense, feel free to use this naming protocol too!!