text:
Sonic Heroes/Enemies

Dr. Eggman: The egg-shaped, mustached antagonist of the series. Eggman has a passion for building robots and weapons which he attempts to use to conquer the world. In this game, he has built the Egg Fleet, a giant army of battleships that resemble fish. However, Eggman is not the main villain in the game and has fallen to the wrath of one of his own creations.

Metal Sonic: Metal Sonic is the robotic counterpart of Sonic, built by Dr. Eggman. Metal Sonic has betrayed Eggman in this video game, taking the destruction of Sonic into his own hands. He has obtained a data-copying ability as well as an emperor-like design. In the Final Story, Metal Sonic transforms into a giant metal dragon called the Metal Overlord.

EggPawn: Grunt Soldiers of the Eggman Army, and the ones you will encounter the most often. These guys bear the most resemblance to Eggman himself, and carry all manner of weaponry: Automatic Rifles, Rocket Launchers, Shields, Lances, and more.

Flapper: Similar to EggPawns, you will encounter Flappers extremely often. Generally, they hover in one place, stationary, although some fly around with search lights in order to call in re-enforcements upon spotting you.

Rhino Liner: Found only in the Rail Canyon/Bullet Station stages, Rhino Liners travel along grind rails in an effort to knock you off.

Falco: Smaller versions of the Egg Hawk boss. Usually only found in the Egg Fleet stage.

Klagen: Giant purple and blue squid-like robots. If a Klagen catches a teammate in it's capture beam, that teammate will be unusable until the Klagen is defeated.

Cameron: Turtle robots. Generally can only be defeated by flipping them over on their backs and striking their stomachs. Have giant cannons mounted on their backs.

title: Sonic Heroes/Enemies


text:
Sonic Heroes/Other Characters

Froggy: Big's "polliwog pal" who lives with him in the Mystic Ruins. Froggy has been kidnapped by Metal Sonic, along with Chocola Chao. Metal Sonic copies Chaos' data from him.

Chocola: Chocola is a brown Chao and Cheese's brother. Chocola was kidnapped along with Froggy, by Metal Sonic. Metal Sonic copies Chaos' data from him.

Chaos: A mysterious liquid lifeform who protects the Chao from harm. He is not shown in the game, but does have a role to play in the game, as Metal Sonic kidnaps Froggy and Chocola and copies Chaos' data from them, as they have both encountered Chaos. Chaos' power allows Metal Sonic to melt into a weird liquid.

Chao: Cute creatures who can be bred and trained by you in Sonic Adventure and Sonic Adventure 2. They appear in some of the levels with Team Chaotix, as well as some bonus stages.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: Sonic Heroes/Other Characters


text:
ETF Mapping/Overview

Purpose
The ETF entities are intended to be an extension to existing entities rather than replacing the current entities (at least, as far as possible). Currently, they're both incomplete and potentially bug-ridden. Many features we'd like to add haven't yet been added, and some entity types will not coexist happily with the extensions.

Initially the entities info_notnull, func_goalitem, func_commandpoint and func_goalinfo defaulted to a 30 second wait when there was NO wait field given. This default wait has been removed since Beta1f to stop some serious issues and make the entities more logical. If your map was based around this default wait, a recompile is needed.

Some of the worldspawn fields have changed, to make them shorter. Q3 couldn't parse the long keys and gave errors on compile. Finally, the ammo_bullets is now called ammo_nails, which is more logical, too.

You can now use the mapinfo files to set atmosphere and class names, names, team names, allied teams, etc. throughout the whole map or for a specified gameindex.

Basic Principles
Essentially, each entity has a 'state', as follows:

When successfully touched by a player, an entity will attempt to go to carried/active state. After a set time, active entities will automatically go back to inactive.

Entities can also trigger other entities in a 'cascade' of triggers, by using target keys, e.g. on a flag entity you might have "carriedtarget" "alarms" - that would activate all 'alarms' entities when a flag became carried.

There are a set of criteria checked before an entity can be triggered (although triggers can also be 'forced' to ignore criteria, more on this later).

In addition to this, players can be 'given' bonuses, and teams can be given scores, as well as having messages and sounds played.

What it can do

 * It can be used to create complex map effects and the like (think of Team Fortress), as well as some degree of 'scripting'.

What it can't do

 * It can't be used as a language in its own right - it will maintain no variables, parse no scripts. This may become available in a future release, but not right now (also, there would be performance questions in a scripting language).

title: ETF Mapping/Overview


text:
ETF Mapping/Examples

Trigger Types
There are six main sorts of triggers you'll use:

Sample Flag
A 'flag' is an entity that can only be carried, but only by one team, and does various effects when carried. {   // The red flag

"classname" "func_goalitem" // this one is set by the editor when you position the entity: "origin" "1248 1984 -328"

// What it looks like "model" "models/flags/r_flag.md3"   // Model to use "light" "200"                       // Dynamic light "color" "1 0 0"                     // Pure red "sparkle" "1 0 0"                   // Generate smoke puffs around carrier

// What it's called "groupname" "redflag"

// Criteria "allowteams" "blue"   // Only blue players can trigger (i.e. carry)

// Messages on trigger // Centerprint message to activator: "carried_message" "~You have taken the ^1RED^* flag!" // Tell everyone activator has done it: "carried_all_message" "~%N has TAKEN the ^1RED^* flag!" // Tell everyone activator dropped the flag: "active_all_message" "~%N has DROPPED the ^1RED^* flag!" "inactive_all_message" "The ^1RED^* flag has returned." // Play Sound to team: "carried_team_sound" "~sound/teamplay/voc_team_flag.wav" // Play Sound to non-team players: "carried_nonteam_sound" "~sound/teamplay/voc_enemy_flag.wav" // Play Sound to activator: "carried_sound" "~sound/teamplay/voc_you_flag.wav"

// Flaginfo (shown on \flaginfo command) "carried_flaginfo" "%N has the ^1RED^* flag." "active_flaginfo" "The ^1RED^* flag has been dropped at $l." // Flags must use $l for active_flaginfo and active_all_message "inactive_flaginfo" "The ^1RED^* flag is at the red base."

// Misc // Reveal spies on trigger, show flag above player when carried: "flags" "revealagent,showcarry" // Wait 45 seconds before going inactive (i.e. back to base): "wait" "45" }

Sample Capture Point
Now we have a flag, we need somewhere to capture it.

{   // The capture point in the blue base

"classname" "trigger_multiple" // Origin/size defined by brush (never set) "model" "*10"

// Criteria // Only trigger if activator holds redflag: "holding" "redflag"

// Messages // Centerprint message to everyone: "active_all_message" "~%N has CAPTURED the ^1RED^* flag!" "active_message" "You have scored 2 frags for capturing the flag." // Play sound to activator: "active_sound" "~sound/teamplay/voc_blue_scores.wav" // Play sound to activator's team (apart from activator): "active_team_sound" "sound/teamplay/flagcap_blu.wav"

// 'Give' bonuses "give" "score=+2,health=+100,armor=+200,ammo_shells=+200,ammo_nails=+200,ammo_cells=+200,ammo_rockets=+200,ammo_medikit=+50,gren1=+4,gren2=+2" // Give activator's team 10 points (the teamscore, not the players on the team): "teamscore" "10"

// When activated, force redflag to inactive (back to base), // trigger scorer (optional extra 10 points entity): "activetarget" "redflag=~inactive,scorer" }

Sample Command Point
To make things a little more interesting, why don't we have a 'scorer' command point that gives players an extra 10 points when they capture the flag?

{   // A button to press to claim the command point

"classname" "func_button" "model" "*1" "angle" "-2" "wait" "5" // Trigger the scorer command point when activated: "activetarget" "scorer_cp" }

{   // The scorer command point (no model, so must be triggered by another entity)

"classname" "func_commandpoint" "origin" "448 832 -128"

// Misc "groupname" "scorer_cp"

// Messages "active_all_message" "~%N has claimed the\ncapture bonus for the %T!"

// On activation (i.e. touch if we have a model, or trigger by a button   // or something otherwise) // All entities named 'scorer' are locked to activators team: "teamset" "scorer" // Set scorer to inactive (i.e. ready to be activated): "activetarget" "scorer=inactive" }

{   // An untouchable 'scorer' entity "classname" "info_notnull" "origin" "444 828 -84"        // Hardly 'essential' in this case...

// Misc "groupname" "scorer"          // So other entities can reference // Prevent scorer from being triggered initially // (i.e. until command point is claimed): "initialstate" "disabled"

// On activation "teamscore" "10"              // Give the activator's team 10 points // Go inactive after 1 second (the chances of someone capturing twice   // in under a second are pretty slim...): "wait" "1" }

Sample Hud
We've forgotten something - we need to show a player if he's carrying the flag or not, or he's liable to get confused (and upset if he finds he's had it for the last 5 minutes without capturing). We need a HUD entity.

{   // A HUD entity shown to the red flag carrier "classname" "func_hud" "origin" "1252 1980 -292"

// Entity never actually activates, just show this model: "inactive_model" "models/flags/r_flag.md3" "slot" "1"           // Display it in slot 1 (top left) "holding" "redflag"  // Only player holding redflag can see this entity }

title: ETF Mapping/Examples


text:
ETF Mapping/References

Entity States
Essentially, each entity has a 'state', as follows:

When a player touches an entity and the criteria are passed, it will be triggered to carried (if it's a carryable entity), or active.

Unless forced (see targets), only certain state changes are permitted (note that you cannot change state to the current state (nothing at all will happen):

When an entity changes state, it will trigger any messages or sounds for that state, as well as executing give (only when in carried/active state, depending on whether it can be carried), teamscore (again, only in carried/active) and target (see targets).

An entity can have its state changed a maximum of 5 times (currently) per-frame single frame - this is to prevent infinite loops from hanging the server - but you would be wiser to avoid any situations where this kicks in (since you cannot always be sure what state the entity will end up in, particularly if the limit changes).

Messages
When an entity changes state, messages and sounds can be sent out to various players, optionally with the 'force' flag (prefixing the string with a ~ symbol). The force flag causes messages to be centerprinted and sounds to be global (i.e. no attenuation). Messages can be sent to four different groups: The activator, the activator's team (excluding activator), all players not on the activator's team, or all players.

in the above strings means the state to play on, e.g. active_message. For sounds, currently only sounds everyone can hear ( _all_sound) can be played 'unforced' (i.e. fades with distance from the entity).

Additionally, there is another prefix that is not a state. This is the kill prefix. It is used just as the other messages, but useful for o.a. trigger_hurt entities. Example: "kill_all_message" "%n shouldn't have been here." as a keypair on a trigger_hurt will display "Dummy shouldn't have been here." as a deathmessage when the player called Dummy gets killed by the trigger_hurt.

Messages can also contain tokens that are expanded as required. Tokens in UPPERCASE represent the activator (if present). Tokens in lowercase represent the entity itself:

For example, you could say: "active_flaginfo" "The ^1RED^* flag has been dropped at $l." // $l is used for locations of the goalitem entity dunno why but it is.

Incidentally, you can use these tokens in communications as well (case does not matter), save that you require $ instead of %. If you want to annoy everyone on the server, just say "Hello $r, I'm $n of the $t." (I wouldn't really recommend it, though). $r is readers name now instead of $n.

Flaginfo
Flaginfo is sent to players who execute a \flaginfo command. All entities that have a _flaginfo will have that info sent to the client. Normally, it's flags and the like that keep flaginfo, hence the command name. For flags, you'd expect a carried, active, and inactive flaginfo string, e.g.

Give
Entities can 'give' bonuses to affected players when set to carried (if a carryable entity) or active (if not). The give string is of the form "give" "stat=value,stat=value,stat=value". The following stats are available:

If not forced (with a ~ prefix), these values are limited to player maximums. If + or - is prefixed, they're added or removed from existing values rather than set, e.g. "give" "health=~500,armor=+50,score=+3,quad=10,haste=10,aclass_fire=1" Would give a player 500 health (no matter their class max), 50 more armour (up to class max), three points, ten seconds of quad and haste (no matter what they had before), and fire-resistant armour.

If armortype is not specified and armour is given (i.e. the player gets more armour than they had before the command), it is automatically assumed that their armour type should be set to the maximum. For their armour type to remain unchanged, put in a key like "armortype=+0".

There are also a set of entity keys that affect the command:

Note that the way the criteria work, it first checks affectteams and the affectteam/affectnonteam flags for players to affect, and them limits this based on the lineofsight/environment flags.

Flags
An entity's key "flags" can be used to specify a comma-separated list of boolean flags that affect the entity's behavior in multiple areas, as follows. These can be categorised as criteria/effect/command flags:

Targets
The targeting system is what binds all the entities together into something more. When an entity's state changes, it checks for target and then attempts to set each named target to the specified state (default state if not specified is always 'active'). If forced by prefixing the state with a ~ character, criteria (and 'give'/'teamscore') are ignored, e.g.

"carriedtarget" "redalarms,escapedoors=~disabled"

Will cause the alarms to go to active (default if not specified), and forces all escape doors to be disabled, even if they're currently active (i.e. open).

To be targetable, entities must have either a targetname or a groupname key, the differences are as follows:

Wherever possible, please use groupname instead of targetname - it's much more flexible and less prone to side-effects.

Please note that unforced triggers (i.e. without a ~) will pass the same activator on to the triggered entity (i.e. the player rather than the entity passing the trigger on). Also, the criteria are still check against the activator).

If you find yourself having problems with this, try setting g_mapentDebug to 1 at the console - be warned that you'll get a lot of junk out of this, and it may not help much.

See the Entity States section for more information.

Criteria
Criteria are checks on whether or not the activator can actually trigger this entity. The following fields apply, as well as some flags:

The clientstats value is a list of evaluators build up like this: [keyword][evaluator][value], with the evaluator being '=', '<', '>', '<=' or '>='. The value is an integer or '!' (indicates activators' class maximum) and the keys can be the following: health, armor, ammo_shells, ammo_nails, ammo_rockets, ammo_cells, score, gren1, gren2, quad, regen, flight, battlesuit, invis, haste, ammo_medikit, ammo_charge, invuln, aqualung, gas, stun, flash, tranq, fire, skill.

If the criteria fail (after the reversecriteria flag is applied), the 'failtarget' key will be executed - note that there's no 'wait' on failures, so don't do anything processor intensive.

Map Info
Each map should be accompanied by a "mapinfo" file, which lives in the maps directory with its map, e.g. maps/etf_map.bsp should be accompanied by a maps/etf_map.mapinfo file.

The mapinfo defines assorted properties describing the map, as well as overriding world-spawn attributes. The file format is something like:

mapinfo { map		"etf_map";					// BSP name longname	"Mapname";					// Long name for map, general description of it	type		"etf";						// Game it is for (all etf maps are marked with "etf") gameindices	"1,2,3";					// Available gameindices atmosphere	"T=RAIN,B=5 10,C=0.5,G=0.5 2,BV=0,GV=0 100,W=1 2,D=300";	// Atmospheric effects

gameindexDef 1 {						// Gameindex Definition longname	"Mapname CTF";	// Long name for this gameindex

// Map info (former .mpi) mapinfo		"Blablabladebladebla";

// Class limits etc green_limit		"0"; yellow_limit		"0"; sniper_limit		"2"; grenadier_limit		"3"; red_soldier_limit	"5"; blue_soldier_limit	"6";

atmosphere	"T=SNOW"; }

gameindexDef 2 { longname	"Mapname 1-flag CTF"; mapinfo		"Blablabladebladebla"; green_limit	"0"; yellow_limit	"0"; } } Entries in gameIndexDef blocks override the default entries (which are not associated with any particular gameindex, and apply to all). Note that the gameindices field is required, and will default to "1" if not specified (however many gameIndexDef blocks there are).

Each map+gameindex combination is treated as a completely separate map in voting lists. Gameindexes should be a single digit from 1 to 9.

Any fields not mentioned here will override worldspawn keys instead (for example atmosphere).

Gameindices
Gameindices make it possible to have multiple scenarios in one map. Basically, all entities with a 'gameindex' key spawn only when the server has g_gameindex set to the same value.

For example, when an entity has "gameindex" "1,2", it will only spawn when g_gameindex (which defaults to 1) is 1 or 2 on the server.

Also, for the server to know which gameindices are allowed for this map, there is a new key for the .arena file. This key is called 'gameindices' and has as value an array of the allowed gameindices. For example "1,2,3", which results in g_gameindex 1, 2 and 3 being valid for this map. If it has a different value during the loading of the map, it defaults to 1.

Custom Infoparms
Q3F uses the -custinfoparms parameter of q3map 1.1-TA-beta and newer being distributed with GtkRadiant to extend Quake3's shader language.

Current custom infoparms:

particleclip 	Particles collide with this surface. forcefield 	Used in combination with the func_forcefield entity to create forcefields. footprints 	If a client walks over a shader with the footprints parameter set, he leaves a trail of footprints. stone 	Stone footstep and ricochet sounds. wood 	Wood footstep and ricochet sounds. seethrough 	Translucent surface a sentry can track through even if it's solid.

To use these parameters, you need to add a 'custinfoparms.txt' file to your scripts directory (where your shaders live) and execute the bsp stage of the compile process with the additional -custinfoparms command line parameter.

The contents of the textfile used with Q3F:

// Custom Surfaceparms file

// Custom Contentsflags {	particleclip 0x2000 forcefield 0x4000 } // Custom Surfaceflags {	footprints 0x80000 stone 0x100000 wood 0x200000 seethrough 0x400000 }

title: ETF Mapping/References