Map Entities

From Exterminatus Manual

Jump to: navigation, search

++ Mapping ++ Translation File

Here you will find a full list of all the custom map entities in Exterminatus.

Contents

ex_gameplay

Required - Logical Entity


Sets up the start of the round and allows you (the mapper) to tell the game which team won the round.


One (and only one) of these is required by exterminatus per map. A temporary ex_gameplay will be created by the mod at run time if you don't include one in the map.

Specify the names of the ex_objectives where each team starts spawning in the "Human Start Objective" and "Tyranid Start Objective" properties.

Each EX map has it's own translation file (see ex_mission), by default the name of the BSP file is used to determine the name of the translation file to load, you can override this behaviour by specifying the file name in the "Translation File Name". This is usefull if you have ex_mymap_version_1.bsp, ex_mymap_version_2.bsp and ex_mymap_version_3.bsp etc and have them all get their translations from ex_mymap_english.txt.

If you specify the name of a ex_mission entity in the "Start Mission" property then that mission will be active as soon as the map loads.

Fire the "Imperials Won" or "Tyranids Won" inputs to dictate who won the game. The ex_gamplay entity can also tell you when each team is due to start spawning via it's "OnTeamSpawnWaveReady" outputs.

ex_objective

Required - Camera Entity


Co-ordinates game flow, in-game objectives and team spawning.


Formerly there was only one type of objective, now there are 3 choices you can have. You still need at least one of these objective type entities for each team.

Objectives occur in a fixed series, a particular objective's position in the series is determines by it's order property. the Human team starts at objective 1 and work up the sequence until victory while the Tyranids (or Chaos) start at the highest objective order and work there way down to 1. Side objectives that can occur at any time have an order of 0.

Objectives can name a camera entity from whose point of view players will see while they are waiting to respawn (Not all types of entity work for this, but we know prop_dynamic does). If no camera is specified the POV of the objective is used.

All objective names are listed on the Players tactical overview (F1 by default) with an that represents that team owns it.

ex_start_objective

Optional - Camera Entity


Co-ordinates team spawning.


This type of objective only appears in the tactical overview and is simply used to collect a set of dropzones for player spawning. Start objectives are only intended to be used as the initial objective in maps where the team starts should not be captureable (such as Thunderhawk and Space Hulk). Even if you use ex_start_objective's you should still speciufy the inital objectives in your map's ex_gameplay.

ex_capture_objective

Optional - Model Entity


Co-ordinates game flow, in-game objectives and team spawning.


This is the main type of objective used in EX and appears as a metal control console in-game and an icon on the HUD. The icon and the color of the light on the console depends on which team owns it, Players must aim at the objective and hold their USE key down for a time to capture it for their team. The time it takes to capture an objective is determined by the server console variable ex_capture_time, the default is 5 seconds. You can prevent one team or the other from capturing an objective using the "Imperium can Capture" and "Tyranids can Capture" objectives.


The Outputs : OnStartCapture, OnCancelCapture, OnHumanCapture and OnTyranidCapture are all available to respond to capture events. These last 2 are particularly usefull for triggering ex_mission activation.

ex_break_objective

Optional - Brush Entity


Co-ordinates game flow, in-game objectives and team spawning.


This type of objective appears as whatever kind of brushwork you care to build and an icon on the HUD. Breakable objectives combine all the functions of an func_breakable with the game flow and spawning functions of an objective, plus damage filtering. The team that owns this type of objective cannot harm it and the enemy cannot harm it unless they have captured all the objectives in the order before it. Because they can only be broken once (and never repaired) ex_break_objectives are best used only as final objectives and side-quests. Valley and Ichar IV both use breakable objectives as the final objectives for the tyranid team.


The OnBreak output is particularly useful for triggering the ex_gameplay victory inputs for final objectives.

ex_mission activation.

ex_dropzone

Required - Location Entity


Spawn points associated with ex_objectives.


When a teams spawn timer hits 0 and dead players on that's team are respawned ex_dropzones with an "Objective" that was last captured by the team. Dropzone's containing other solids will not be used by the game (to prevent telefragging or players getting stuck in geometry) so make sure your dropzones don't stick into the walls, floors or ceilings.


NOTE : There needs to be enough of these for an entire team of 8 players to spawn at once for each ex_objective. Players cannot be spawned at drop zones that are blocked by any kind of solid (including other players). The objective with the least number of drop zones determines the greatest number of players the map can support.

ex_mission

Optional - Logical Entity


Tells the players what their mission is.


Fire the "ActivateMission" input to assign missions to both teams, and notify all players that their mission has changed.

ex_mission entities rely on the map's Translation File to locate the actual mission text from a token specifed by the ex_mission.

Sample mission file:

"lang" 
{ 
	"Language" "English" 
	"Tokens" 
	{
		"neutral_tyranid" "USE the button on the skull console to capture the neutral objective"
		"neutral_human" "USE the button on the skull console to capture the neutral objective" 
		"tyranid_tyranid" "Defend your console and capture the neutral objective"
		"tyranid_human" "USE the button on the tyranids console to stop them spawning" 
		"human_tyranid" "USE the button on the humans console to stop them spawning"
		"human_human" "Defend your console and capture the neutral objective" 
	} 
}


The "Imperial Token" and "Tyranid Token" properties relate to "token" names in the text file for this map. The value of each the tokens describes the respective team's mission. If the text file doesn't exist the token will be used instead of the translation.

While it is not absolutely necessary to keep an ex_mission with it's respective ex_objective, ex_dropzones it's probably a good idea to avoid confusion. Player's can find their team's current mission by checking the tactical overview screen.

NOTE: it's up to the mapper to provide and activate the appropriate entities to allow the player to achieve their mission.

ex_random_branch

Optional - Logical Entity


When it's "Randomize" input is triggered a random branch output will be triggered, all specified outputs have an equal chance of being triggered.


Intended to introduce some unpredictability into the paths of dropships and missions, by toggling alternative ex_dropship_paths or ex_missions

ex_award

Optional - Logical Entity


Give a player extra reward points (on top of kills and captures)


ex_award has a single input "Activate" that takes a parameter override, when a player activates the ex_award (via a button or trigger) the parameter determines how many points they should be given.

Use this entity to reward players for performing mission objectives other than capturing objectives and attacking the enemy.


NOTE: the normal points limit and overflow mechanism applies to this award too.

ex_filter_team

Optional - Logical Entity


Make any standard trigger team specific


When it's "Activate" input is triggered it compares the activating players team with it's "Tyranid Blocked" and "Humans Blocked" properties to decide if it should fire it's "OnActivate" output or it's "OnBlocked" input.


ex_filter team also has specific outputs for each team activating or being blocked, so you can have an input trigger a different output depending on the team of the player who activated it.


The "<team> Blocked" properties can be toggled in-game using the "Toggle <team>" inputs to un-block or start blocking a specific team.

ex_filter_one_team

Optional - Logical Entity


A (second, complementary) way to make a standard trigger team specific


When it's "Activate" input is triggered it compares the activating players team with it's "Filter Team" property and it's blocking state (set by the "Start Blocked" property) to decide if it should fire it's "OnActivate" output or it's "OnBlocked" input.


The blocking state can be controlled using the "Start Blocking" and "Stop Blocking" inputs.

Navigation