ORBIT Documentation


Home | Overview | System Requirements | Documentation | Contact Me | Credits

Introduction

ORBIT is a Space Combat Simulator. If you've ever played the Wing Commander games, the X-Wing or TIE fighter games, Descent Freespace, or any of many other such games, you're already familiar with the basic idea: You must fly around space destroying enemies.

ORBIT is a bit different from these other games in these ways:

Installation

Installation under Windows

  1. Create a directory for ORBIT. You might use C:\ORBIT
  2. Unzip the ORBIT.ZIP file into the directory you created. Be sure to use a zip program that understands long file names and creates subdirectories. WINZIP will work fine.
  3. Double-click on the ORBIT icon to start the game.
  4. If you like, you can drag the ORBIT icon to your desktop to create a shortcut.

Installation under Linux

  1. Create a directory for ORBIT. You might use /usr/orbit
  2. Move the orbit.tar.gz file to the directory you created.
  3. Change your working directory to the orbit directory.
  4. Uncompress the file: gunzip orbit.tar.gz
  5. Extract the tar file: tar xvf orbit.tar
  6. Run the orbit binary to play the game.

Installation under AmigaOS

  1. Unpack the Orbit_dat archive to your harddisk.
  2. Unpack the Orbit_exe archive to the same location (Orbit_exe always contains the latest updated executable and documentation).
  3. Double-click on the ORBIT icon to start the game.

Getting Started

When you start the game the first time, you will begin the first training mission. The instructions in the training missions try to give you step by step guidance, but it might be useful to be aware of some of the most commonly-used command keys:

Hopefully that's enough to get you started. There are many more keyboard commands described in the next section.

Keyboard Commands

Keep in mind that there are upper and lower case command keys. In some cases the upper case key performs a different function than the same lower case key. Command keys must be used in the case they are shown here.

Heads Up Display (HUD)

The HUD shows all sorts of useful information as shown here:

  1. Throttle. Shows the amount of forward thrust (green) or reverse thrust (red) currently being applied. The number is the ship's current velocity in kilometers per second. If the number is green, the ship is moving forward (into the screen). If it's red, the ship is moving backward. The velocity will be a blue zero if the ship is perfectly at rest.
  2. Radar. The radar shows the direction to each planet, and to each nearby moon, object, and missile. Objects near the center of the radar are toward the front of the ship, while objects near the edge of the radar are behind the ship. Planets are shown as blue dots, moons are shown as cyan (light blue), missiles are shown as small yellow dots, enemies are shown as red dots, and friendlies are shown as green dots. The currently locked object is shown as a slightly larger dot. The current waypoint, if any, is shown as a white dot.
  3. Shield status. Shows the condition of your ship's shields. Full, undamaged shields are shown as a bright green bar. As the shields take damage, the bright part of the bar gets smaller. As the shields receive considerable damage, the indicator turns yellow, then red.
  4. Enemy shield status. Shows the shield status of the currently locked enemy.
  5. Weapon. Shows the name of the current weapon. If the weapon is recharging, the text will be grey. If the weapon is ready to fire, the text will be magenta.
  6. Target. Shows the name and range, in kilometers, of the currently locked target. Friendly targets are shown in green, enemy targets in red, planets in blue, and moons in light blue.
  7. Waypoint. Shows the number and range of the currently selected waypoint, if any.
There are several other useful indicators which can appear in the actual viewing area of the screen:

Weapons

Your ship is equipped with a number of weapons which differ with respect to a number of characteristics:

You will want to experiment with the different weapons to decide which weapon is best for each specific situation.

Shields

Your ship, and the ships of enemy pilots, are protected by shields. The shields can absorb a considerable amount of destructive energy before that energy can damage or destroy the protected ship. If you receive damage greater than the amount your shields can currently absorb, your ship is destroyed.

Shields automatically regenerate. Damaged shields will eventually return to complete capacity as long as they receive no additional damage.

The status of your ship's shields and the shields of the currently locked target are displayed on your HUD.

The Preferences File

ORBIT remembers many of the different options you control, such as whether the HUD is displayed and the density of the star field. These preferences are stored in a file named prefs.txt, located in the directory where you installed ORBIT. (If you're running under Unix, the file is stored in your current working directory when you execute the program.)

In addition, there are some options which are stored in the preferences file but which cannot be controlled from within the program. To manipulate these options, you must edit the preferences file directly.

Of particular note is the mission directive in the preferences file. This is the name of the current mission. If you want to change which mission you want to fly, or want to try flying a custom-designed mission, you will need to change the value of this directive before starting the game.

The preferences file consists of a number of text lines, with two fields per line. The first field is the name of a directive and the second field is the value of that directive.

Here is a complete list of directives in the preferences file. Directives that you cannot control from within the game are marked with an asterisk (*).

The Log File

Every time ORBIT runs it creates a log file named orbit.log. The log file is created in the same directory in which ORBIT was installed (or the current working directory on Unix machines).

The log file contains all sort of useful information about things which occur while the game is running. If the game behaves oddly, if you think you've discovered a bug, or if you're trying to debug a complicated mission file, the log file is the first place you should look to help determine the problem.

If you wish to report a bug, you should include the orbit.log file from a session which demonstraties the problem.

Network Play

Up to sixteen players can participate in a network game.

To set up a network game, you need to have ORBIT installed on at least two computers which can communicate via TCP/IP (most likely using the Internet). One computer is designated as the server, and the rest of the participants are designated as clients. You will need to know the IP address of the server before setting up a network game.

Here are the specific steps to set up a network game:

  1. Be sure all participants know the IP address of the server machine.
  2. Start up ORBIT on all participant's machines.
  3. On the server machine, type S (upper-case 'S'). This makes the machine an ORBIT server.
  4. On each client, type C (upper-case 'C'), enter the IP address of the server, and press return. This will connect the client to the server.
  5. Go frag some butt, Sparky!
  6. To end a network game, type C again on a client to disconnect that client from the game, or type S again on the server to disconnect all clients.

Here are some points to keep in mind regarding network play:

To make it easier to find opponents in a network game, it is possible to lock on to enemy targets regardless of their distance. In normal mission play, only nearby targets can be locked.

The player name used in network displays is controlled by the name preferences variable, and the spaceship model is controlled by the model variable.

The Mission File

Introduction

ORBIT is based on the concept of a mission. The player is presented with specific objectives which must be met for a mission to be successful. The objectives vary for each mission, and depending on the player's performance, different subsequent missions can be assigned.

Each mission in ORBIT is controlled by a mission file. The mission file is a simple text file which controls the placement of objects, the objectives of a mission, and events which may take place during a mission. All mission files are expected to be found in the missions subdirectory.

When the game is run, the value of the mission directive in the preferences file determines the mission to be loaded. If the preferences file does not exist or does not contain the mission directive, the default mission train01.msn is loaded.

Format

The mission file consists of tokens separated by white space. White space is spaces, tabs, and newlines. A variety of tokens control all aspects of the mission being defined. Line breaks are ignored; you may break lines anywhere you like, as long as you do so between tokens.

Some tokens require extended arguments which must be enclosed in braces ({ and }). The braces must be surrounded by white space. For example, this is a valid statement:

        Cursor { Earth +10000 }
but this IS NOT VALID:
        Cursor {Earth +10000}                (BAD!!!)

Comments may be included anywhere in the mission file by beginning the comment with /* and ending with */. These tokens must also be surrounded by white space.

The mission loader is fairly forgiving and will ignore most errors (but an error message will be printed). If you are designing a mission and it isn't working the way you expect, the loader may be ignoring a simple error in the mission file.

Tokens are case-insensitive. That is, Event is the same as event is the same as EVENT.

A great way to learn about missions is to examine the mission files included in the distribution. They are in the missions subdirectory and can be viewed with any text editor, like Notepad.

What follows is an exhaustive list of all the tokens along with descriptions and examples.

Cursor

Quite often while defining a mission you will need to refer to a position in space. Rather than have separate commands for the locations of objects, events, etc., the mission loader uses the concept of a mission cursor, a location in three-dimensional space. Whenever a token needs a location, it uses the current value of the mission cursor.

You manipulate the mission cursor with the Cursor token, which must be followed by a position enclosed in braces. You may specify absolute and relative positions, and may use the names of planets, moons, and objects to represent their positions.

You specify a position with up to four parameters: The (optional) name of a planet, moon, or object, followed by up to three coordinates (x, y, and z). If the coordinates begin with a + or -, they are interpreted as being relative to the current mission cursor, otherwise they are interpreted as absolute coordinates. Coordinates are specified in units of kilometers.

Here are some examples:

Set the mission cursor to the position of Earth:

        Cursor { Earth }
Set the mission cursor to the position of Earth, plus ten thousand kilometers in the X direction:
        Cursor { Earth +10000 }
Set the mission cursor to a few hundred kilometers along each axis from the old cursor:
        Cursor { +300 -200 +400 }

If the name of an object is used in the Cursor statement, the object must have been defined earlier in the mission file.

Player

The initial position of the player is controlled by the Player command. The player's initial position will be set to the current value of the mission cursor.

The Player token must be followed by braces with only white space between them. In other words it must look like this:

        Player { }

In the absence of the Player command, the initial player position is inherited from the position at the end of the previous mission.

Object

The Object command controls the placement of an object in the mission. Objects may be enemy ships, friendly ships, space stations, etc.

A complete Object description might look like this:

	Object
	{
		Name Fighter1
		Model light1.tri
		Score 1
		Strategy Hunt1
	}
The object's position is set to the current value of the mission cursor.

The Object token must be followed by a number of parameters enclosed in braces. Each of these parameters, which describe the appearance and behavior of the object, are described below:

Name

The Name token assigns a name to an object. The name will be displayed in the HUD when the object is targetted, and may be refered to by various events.

The format is:

        Name object-name
Object names are limited to 32 characters and cannot contain white space characters.

Model

The appearance of an object is controlled by the Model token. The value, which must follow the Model token, is the name of a file found in the models subdirectory. If the model name ends in ".tri", it is assumed to be in the triangle format. If the name ends in ".ac" it is assumed to be in AC3D format.

Here's an example:

	Model platform.tri

Score

The Score specifies the number of points the player receives for destroying the object. The player's score can control events, described later.

Here's an example:

	Score 1

Strategy

The behavior of an object is controlled by the Strategy command. The token is followed by the name of a strategy, like this:

	Strategy DoNothing
These are the currently available strategies:

Hidden

Objects may be declared to be hidden. Hidden objects will not appear on the HUD, cannot be hit, do not fire, and do not use any strategy. Typically, a hidden object would at some point be unhidden by an event.

The token takes no arguments:

	Hidden

Weapon

By default objects are armed with Weapon number four, which is a weak weapon. Objects may be given a different weapon with the Weapon command. The argument is a number from 0 to 9, like this:

	Weapon 3

Friendly

Normally, objects behave as enemy objects and attack the player according to the Strategy they have been assigned. But you can use the Friendly token to declare an object to be a friendly object. Friendly and unfriendly objects can be made to attack each other by assigning appropriate strategies to the objects.

MaxShields

MaxShields specifies the maximum level of the object's undamaged shields. The default value is 100. The token is followed by the value to be assigned to the maximum shield level:

	MaxShields 200.0

ShieldRegen

The rate at which an object's damaged shields regenerate can be controlled with the ShieldRegen token. The default is 5.0 units per second. Follow the token with the regeneration value:

	ShieldRegen 2.0

TurnRate

The rate at which an object turns is specified with the TurnRate token, which is followed by the turn rate expressed in radians per second:

	TurnRate 0.5

The default turn rate is 0.3 radians per second.

Speed

An object's acceleration is controlled by the Speed token. The default speed is 0.02. Follow the token with the new speed:

	Speed 0.04

Invisible

The Invisible token makes an object invisible. Invisible objects do not appear in the HUD or on the viewscreen. Invisible objects can be hit by weapons and can be assigned a strategy.

The token takes no arguments:

	Invisible

Briefing

Once a mission is loaded, the player is presented with the mission briefing. The briefing should tersely inform the player of the situation and clearly state the mission objectives.

The Briefing token is followed by the text of the briefing inside braces. You may force a line break in the briefing with a backslash (\). Briefings are limited to 4096 characters, but you should keep them short to be sure they can be displayed on small screens.

Here's an example briefing:

        Briefing
	{
        	Mission 001:  Lunar Patrol\\
        	Welcome to the ship, Captain.\\
        	We have had some reports of enemy activity in orbit above
        	Earth's Moon.  If the aliens establish a stronghold so close
        	to the earth it may be impossible to withstand an attack.\\
        	Your mission is to travel to the moon, eliminate any hostile
        	forces you encounter, and return to the earth.\\
        	Briefing concluded.  Godspeed!\\
	}

Verbose

The mission loader can print lots of useful diagnostic information. To receive all such messages, turn on verbose reporting with the Verbose token, which should appear near the top of the mission file.

The Verbose token takes no arguments:

	Verbose

Terse

To turn off verbose reporting from the mission loader, use the Terse command, which takes no arguments:

	Terse

Event

In order to make more interesting missions it's possible to define events. The mission situation can be changed by events when certain circumstances occur. You can give messages to the player when a certain object is approached or destroyed, new objects can be created in response to mission conditions, etc. There are many possibilities which allow you to create rich, complex missions.

Events can also be used to load other missions depending on circumstances. This allows you to create vast, branching campaigns in which the story line is directly affected by the player's performance.

Each event has a trigger and up to 64 actions. The condition which causes the event to occur is the trigger. The things that happen as a result of the event are the actions.

The Event token is followed by the definition of the event enclosed in braces. The definition consists mostly of token-value pairs, where the token is the name of some aspect of the event, and the value is the value to be assigned to that aspect.

Each event can occur at most once. When an event has occurred, it is marked as inactive and cannot occur again.

Each event has a position associated with it, even though the particular event may not make use of the position. The position assigned to an event is taken from the current mission cursor.

A complete event definition might look like this:

	Event
	{
		Name e1

		Trigger Approach
		Value 10000

		Action Message
		Value
		{
			Welcome home!
		}
	}
This event will cause the message "Welcome home!" to be displayed when the player moves to within 10000 kilometers of the current mission cursor.

Descriptions and examples of all the supported event tokens follow:

Name

An event can be assigned a name using the Name token. The token is followed by the name of the event, like this:

	Name e1
Event names cannot contain white space.

In general you do not need to name an event. However, if you intend to refer to the event from another event, most likely with an Enable or Disable action (described below), then you need to give the event a name.

Trigger

The specific condition which will cause an event to occur is specified using the Trigger token. The token is followed by the name of the type of trigger. An example might be:

	Trigger Approach
This statement makes this event triggered by the player's approach to a certain point.

Descriptions and examples of each of the trigger types follow:

Approach

An event with a trigger type of Approach will occur when the player comes within a specified distance from a specified point.

The point to be approached is set to the current mission cursor.

The distance is specified with the Value token, which must immediately follow the Trigger statement, like this:

	Trigger Approach
	Value 20000
This event will occur when the player approaches within 20000 kilometers of the current mission cursor.

Depart

Depart is the opposite of Approach. An event with a trigger type of Depart will occur the first time the player moves further than a specified distance from a specified point.

Like the Approach trigger, the point in space comes from the current mission cursor, and the distance is specified with the Value token:

	Trigger Depart
	Value 100000

True

An event with a trigger type of True will occur the first time it is checked. Unless the event has been disabled, it will occur as soon as the mission begins.

There is no value associated with a trigger type of True:

	Trigger True

Score

An event with a trigger type of Score will occur the first time the player's score is greater than or equal to a specified amount.

The amount to compare is specified with the Value token:

	Trigger Score
	Value 10

This event will occur the first time the player's score equals or exceeds 10.

Destroy

An event can be triggered when a specified object is destroyed. The name of the object (specified with the Name token in the Object definition) must be given with the Value token:

	Trigger Destroy
	Value fighter1

This event will occur when the object named fighter1 is destroyed.

Alarm

An event can be scheduled to occur when a given number of seconds has elapsed. The number of seconds is given with the Value token:

	Trigger Alarm
	Value 30.0

Unless this event has been disabled, it will occur 30 seconds after the start of the mission. If it has been disabled, it will occur 30 seconds after it is enabled.

StopNear

Similar to the Approach trigger, an event with a trigger type StopNear will occur when the player has approached a certain point and come to a full stop.

The point comes from the mission cursor, and the distance comes from the Value token:

	Trigger StopNear
	Value 2000

This event will be triggered with the player comes to a full stop within 2000 kilometers of the current mission cursor.

Shields

An event with a trigger of type Shields will occur the first time the specified object's shields drop below a certain value. The name of the object and the value must follow the token in braces:

	Shields { Fighter1 50 }

This event will occur when the shields of the object named Fighter1 drop below 50 units.

Action

The things that happen when an event occurs are specified with Action tokens. An event can have up to 64 actions. All of an event's actions take place when the conditions specified in the event's Trigger are met.

The type of action must follow the Action token. A complete action specification might look like this:

	Action Message
	Value
	{
		One more to go!
	}

This will cause the message "One more to go!" to be displayed when the event's trigger condition is met.

Descriptions of all the possible action types follow:

Message

The Message action causes the specified message to be displayed on the player's screen when the event's trigger condition is met.

The text of the message is specified using the Value token, enclosed in braces, like this:

	Action Message
	Value
	{
		Go get 'em Sparky!
	}

This will cause the message to be displayed when the event's trigger condition is met.

You can insert line breaks in the message using a backslash (\).

Hide

A Hide action causes an object to be hidden. Hidden objects behave as if they had been declared Hidden in the object definition.

The name of the object to Hide is given with the Value token:

	Action Hide
	Value fighter1

This action will cause the object with the name fighter1 to be hidden when the event is triggered.

Unhide

The opposite of the Hide action, the Unhide action causes a hidden object to become unhidden.

The name of the object to Unhide is specified with the Value token:

	Action Unhide
	Value fighter1

This action will cause the object with the name fighter1 to be unhidden when the event is triggered.

Destroy

When an event with an action of Destroy is triggered, the named object will be destroyed:

	Action Destroy
	Value fighter1

When this event is triggered, the object named fighter1 will be destroyed.

Score

When an event with an action of type Score occurs, the player's score is increased by the specified amount (which may be negative).

The amount to increase the score is given with the Value token:

	Action Score
	Value 1

This action causes the player's score to be increased by one point.

Enable

An action of type Enable will cause the specified event to be enabled. The name of the event to enable is given with the Value token:

	Action Enable
	Value e2

This action will cause the event named e2 to be enabled with the event is triggered.

Disable

An action of type Disable will cause the specified event to be disabled. The name of the event to disable is given with the Value token:

        Action Disable
        Value e2

This action will cause the event named e2 to be disabled with the event is triggered.

Stop

The Stop action causes the player's ship to come to a complete stop. This action does not take a value:

	Action Stop

This action will cause the player's ship to come to a full stop when the event's trigger condition is met.

LoadMission

An event can cause another mission (or even the same mission) to be loaded and played. The mission to be loaded is specified with the Value token:

	Action LoadMission
	Value train04.msn

This action will cause the mission file named train04.msn to be loaded when the event's trigger condition is met.

Boom

The Boom action will cause an explosion of the specifed size to occur at the position of the current mission cursor. The size of the explosion is specified with the Value token:

	Action Boom
	Value 1.0

An explosion of size 1.0 is a medium-sized explosion. Greater values will cause bigger explosions; lesser values will cause smaller explosions.

Flash

The Flash action causes the screen to flash white for one frame. The token takes no value:

	Action Flash

MoveObject

The MoveObject action causes the position of the specified object to be moved to the current value of the mission cursor. The name of the object to be moved is specified with the Value token:

	Action MoveObject
	Value Fighter1

MovePlayer

The MovePlayer action will change the location of the player to the value of the current mission cursor. The token takes no value:

	Action MovePlayer

MovePlanet

The MovePlanet action changes the location of the named planet to the value of the current mission cursor. The token must be followed by the name of the planet to move:

	Action MovePlanet
	Value Jupiter

HidePlanet

The HidePlanet action causes the named planet to become hidden, just as if the Hidden token was used in the planet's definition. The token is followed by the name of the planet to hide:

	Action HidePlanet
	Name Jupiter

UnhidePlanet

The UnhidePlanet action caused the name planet to become unhidden. The name of the planet is specified with the Value token:

	Action UnhidePlanet
	Name Jupiter

Betray

The Betray action will change the friendly status of the named object. If the object was friendly, it will become an enemy object. If it was an enemy, it will be changed to a friendly object.

The name of the object to change is specified with the Value token:

	Action Betray
	Value Fighter2

Value

The Value token is used to provide required information to the Trigger token and many of the Action tokens. The token is followed by a number, a name, or text enclosed in braces, depending on the particular token it is being used with.

When used to specify some text, line breaks may be included in the text by using backslashes (\).

Enabled

Disabled

It can be useful to declare an event to be disabled, and then have it enabled at some later point by another event. The trigger conditions of a disabled event are not checked until the event is enabled.

To declare an event to be disabled, include the Disabled token in the event definition:

	Disabled

You can declare an event to be Enabled, but this is the default.

Planet

The Planet command can be used to control the placement and appearance of the planets and moons in the game.

Here are some things to keep in mind if you plan to start moving planets around:

The Planet token is followed by a number of token-value pairs enclosed in braces. A complete Planet definition might look like this:

	Planet
	{
		Name Saturn
		NewName Tralfamadore
		Map tralfam.ppm
		Radius 12000.0
	}

What follows is a list of all the tokens which can be used to modify the planets:

Name

The Name token is used to identify the planet to be modified. It must be the first token in the definition of a planet. The token is followed by the existing name of the planet:

	Name Saturn

This statement specifies that the rest of the planet definition applies to the planet currently named Saturn.

NewName

The NewName token is used to assign a new name to a planet. Planet names cannot contain spaces and are limited to 16 characters. The token is followed by the new name to be assigned to the planet:

	NewName Magrathea

This will assign the name Magrathea to the planet specified with the most recent Name directive.

Reposition

You can change the position of a planet with the Reposition token. The new position of the planet will be taken from the current mission cursor. The token requires no arguments:

	Reposition

Hidden

A planet which has been Hidden cannot be seen, does not appear on the HUD, and cannot be collided with. A hidden planet effectively does not exist. The token takes no arguments:

	Hidden

Map

The texture used to render a planet can be controlled with the Map token, which must be followed by the name of the texture file:

	Map fractal1.ppm

This would assign the map file named fractal1.ppm to the planet most recently Named. Map files are expected to be found in the maps subdirectory. Map files must be in the Portable Pixel Map (PPM) "rawbits" format, must have a resolution of 256 by 256, and cannot contain comments in the PPM header.

Oblicity

The Oblicity of a planet is the inclination, in degrees, of its equator to its orbital plane. Most planets have a low oblicity. (Earth's is about 23 degrees, Jupiter's is 3 degrees.) An oblicity of 90 degrees would place the planet's poles on the orbital plane. An oblicity of 180 degrees will turn the planet upside down, making it appear to rotate backwards.

The token is followed by the planet's oblicity in degrees:

	Oblicity 23.5

A planet's moons and rings inherit its oblicity.

Radius

The size of a planet is controlled by its Radius. The token is followed by the planet's radius in kilometers:

	Radius 8000.0

The radius of a planet also controls its mass, which is used if gravity is turned on.

Weapon

The weapons in ORBIT can be customized with the Weapon token. The token is followed by token-value pairs enclosed in braces. A complete Weapon specification might look like this:

	Weapon
	{
		Index 2
		Name BFG9000
		Speed 1.0
		Color 0xff0000
		Yield 30.0
		Idle 0.1
		Expire 2.0
		Renderer 3
	}

Descriptions and examples of all the Weapon specifiers follow:

Index

The Index token identifies the weapon to be modified. There are ten weapons with indices from zero to nine. The Index token is followed by the numeric index of the weapon to be modified:

	Index 2

Name

The name of a weapon is specified with the Name token, which must be followed by the new name of the weapon:

	Name Hyperlaser

This will assign the name Hyperlaser to the weapon most recently identified using the Index token.

Weapon names are limited to 16 characters and cannot contain white space characters. The name of the weapon appears in the HUD when that weapon is selected.

Speed

The velocity with which a weapon's projectiles travel is specified with the Speed token, which is followed by the velocity specified in kilometers per second:

	Speed 5000.0

Yield

The amount of damage caused by a weapon's projectile when it strikes a target is controlled by the Yield token. The amount of a weapon's yield is subtracted from the current value of the target's shields. If the shields are reduced to below zero, the target is destroyed.

The token is followed by the value of the yield:

	Yield 30.0

Idle

The Idle token specifies the amount of time, in seconds, required by a weapon to recharge once it has been fired. The weapon cannot be fired while it is recharging.

The token is followed by the idle time in seconds:

	Idle 0.6

Expire

The Expire token is used to specify the amount of time before a projectile which has been fired times out. The Expire and Speed values together determine the range of a weapon.

The token is followed by the expiration time in seconds:

	Expire 3.0

Renderer

The appearance of a weapon's projectiles is controlled by the Renderer token.

There are currently five renderers:

The token is followed by the index of the renderer to be used to draw the weapon's projectiles:

	Renderer 3

Color

The Color token controls the color of a weapon's projectiles. The red, green, and blue components of the color can be specified as six-digit hexadecimal number preceded by "0x".

The color specification must follow the Color token:

	Color 0xff8000

This specifies a projectile color with a red component of 255 (hexadecimal ff), and green component of 128 (hex 80) and a blue component of zero.

Include

A mission file can include commands from another file by using the Include statement, which is followed by the name of the file to include, like this:

	Include fighter.inc

Included files are also expected to be in the missions subdirectory. Include files may be nested to 16 levels.

Waypoint

The Waypoint token defines a new waypoint with coordinates equal to the current mission cursor. The token must be followed by braces with only white space between them:

	Waypoint { }

Adding New Models

You can easily add new object models to ORBIT, and then include them in missions using the Model token in an Object definition.

Model files are expected to reside in the models subdirectory. Triangle and AC3D format models are supported. The file names of triangle models must end with ".tri" and the names of AC3D format models must end with ".ac".

The AC3D file format is documented here. The home page for the AC3D modelling program is here. If the AC3D model includes textures, the texture files must also reside in the models subdirectory. Only textures in the SGI "rgb" format are supported.

A triangle file has one record per triangle in the object. The line contains ten fields. For example:

	1.3 -0.5 -0.6  -1.5 -0.5 0.2  1.3 -0.5 0.2  0xCCCCCC

The first nine fields are the X, Y, and Z coordinates of the triangle's three vertices, in counter-clockwise order as viewed from the exterior of the object. The tenth field is the 24-bit color of the triangle in hexadecimal format.

Here are some points to keep in mind when adding new models to ORBIT:


Home | Overview | System Requirements | Documentation | Contact Me | Credits