Level Design / Mapping For Trepidation

From Trepidation
Revision as of 01:31, 1 April 2017 by Admin (talk | contribs)

Jump to: navigation, search

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.


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

At this time, the new weapons do not have corresponding entities in Trepidation, they use the standard quake 3 weapon names. Here are the replacements:

Flame Thrower – Lightning Gun Singularity Cannon – Rocket Launcher Gauss Rifle – Rail Gun


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!!