Bridge Crew GM Game Manual
Contents

BRIDGE CREW version sw1.12 PROGRAM LICENCE AGREEMENT	1
Acknowledgements	3
Introduction	3
Software installation	4
Setting up the software	4
Environment variables	4
BCREW SET instructions	4
Game Details	5
Hardware Details (using COM1 and COM2)	5
Hardware Details (using AST compatible or Programax-8X card)	6
How Bridge crew handles multi port cards.	6
Support	7
Getting Started	8
Stopping the game	8
Notes about How the Game Plays	8
Ship Recognition or Who sees Whom?	8
Randomness in the Game	10
Game Mastering	10
Running Campaigns	12
Customising Your Universe	13
HELM HIT	13
OVERHEATING	13
INTEGRITY	13
AUTO VIEW	14
DIST SPEED	14
HEAT DAMAGE	14
CLOAK RAND	14
MOVE ENERGY	15
Role-play systems	15
Player Commands	16
ARC angle weapon_list	16
ASSIGN function1 number function2	16
BLOCK target weapon_list	16
BUNLOCK weapon_list	16
CHARGE weapon_list	16
or	16
BCHARGE weapon_list	16
COURSE angle	16
DELETE message_number	16
DETAIL ship	16
DIRECT   end_location   [start_location]	17
ETA  start_location   speed   end_location	17
FROM  ship_id  start_ship_id	17
FUNCTION function_id	17
GET message number	17
LOAD weapon_list	17
or	17
MLOAD weapon_list	17
MUNLOCK weapon_list	17
LOG text	17
MACRO number text	17
MFIRE weapon_list	17
MODIFY dsf_ship  angle  distance	17
MODSPEED dsf_ship  speed  [rotate]	18
ORDER dsf_ship  mission details	18
QUEUE	19
READ message number	19
REPORT CROSSSECTION	19
SCALE number	19
SEND	19
THINGS  ship_id	20
VIEW location	20
WHO	20
ZONE  location1	20
GM Commands	20
ACTIVATE shipid	20
ADJUST CREW|PASSENGERS|CASUALTIES shipid  ship_function  number	20
CAPTAIN shipid new_captain_num	21
COMBAT [start_ship] [dist_ship]	21
COMP message_number line_number text	21
CREW shipid	21
DAMAGE shipid  function  new_value	21
DATE new_stardate	21
DEACTIVATE shipid	22
DMOVE shipid location angle distance	22
DOWN message_number	23
ENERGY shipid	23
EXHUME shipid	23
FREEZE	23
GMGM [virtual_port_number] [COMMS]	23
GUARD shipid	23
IMIT from_ship to_ship message	23
INACT count	24
IUPDATE shipid	24
KNOWN shipid	24
UNKNOWN shipid	24
LOCATE [shipid]	24
MALFUNCTION shipid  function  new_value	25
MISSION shipid  new mission	25
MOD1 shipid  angle  distance	25
MOD2 shipid  speed  [rotate]	25
MOVE shipid  location	25
MPRINT ship_id [file_name]	26
PAUSE message	26
PEOPLE shipid	26
PICT shipid  new_picture	26
QPRINT [filename]	26
REP0 shipid	26
REP1 shipid	26
REP2 shipid	27
REP3 shipid	27
REP4 shipid	27
REP5 shipid	28
REP6 shipid	28
REP7 shipid	28
REP8 shipid	28
REP9 shipid	28
R10 shipid	28
R11 shipid	29
RESTORE file_name	29
RMOVE shipid  location  dist	29
SAVE file_name	29
SCENARIO [number]	29
SCRIPT file name	29
SECURITY  Port_number	30
SETF [ON|OFF|PRESERVE]	30
SETP [HELM|OVERHEAT|INTEGRITY| AUTO|DIST] [ON|OFF]	30
SETV [HEAT|CLOAK|MOVE] [new_value]	30
SIDE shipid FIP|NEU|HOS|DSF|MER|FRE	31
SIGINT shipid	31
SPARE	31
SPRINT [file_id]	32
STATUS shipid	32
TEXT HELLO|QUERY|ID|NEWS|DESC| CLASS shipid new_text	32
UNFREEZE	32
USUS ship_id CONFIRM	32
XDELETE message_number	32
XDOWN message_number	32
XFUNCTION shipid  function_id	32
XGET message_number	33
XHELP command	33
XMEM	33
XMIT from  to  message	33
XPRINT shipid  [file_id]	34
XQUEUE	34
XREAD message_number	34
XRECON shipid	34
XRELOAD shipid number	34
XSEARCH key1 [key2] [key3]	34
XTHINGS number shipid	35
XTRANSPORT CREW num_crew TO|FROM shipid  ship_function  gm_ship	35
XTRANSPORT PASSENGERS num_passengers TO|FROM shipid  ship_function  
gm_ship	35
XUNCLOAK shipid	35
XUPDATE shipid	35
Captaincy styles and tactics	35
Hints and Tips	37
Limits of the Game	38
How Sensors Work	38


BRIDGE CREW version sw1.12 PROGRAM LICENCE 
AGREEMENT



LICENCE

This licence applies to BRIDGE CREW version sw1.12 and all associated files and material 
distributed by Mithril Software.

This software is is protected by copyright law and by international copyright treaty.

You assume responsibility for the selection of the programs to achieve your intended results, and 
for the installation, use and results obtained from the program. Mithril Software is not responsible 
for any damages caused by the use of this software.

Mithril Software provides these programs and scenarios and licenses their use as follows:

You may:

a.	Copy and distribute this version (sw1.12) of BRIDGE CREW to whoever will take it.

b.	Use this software for private use. This includes such use as may be made by a private gaming 
group.

c.	Display this program at a seminar, conference, or convention publicly, provided you are not 
receiving reward for doing so. (i.e. you are not getting paid or charging for the privilege).

d.	Use the supplied terminal emulators VT100.exe and BCTERM.EXE and associated programs and 
files on up to four PCs provided they are connected to a machine running BRIDGE CREW version sw1.12.

e.	Change the medium on which it is distributed or distribute it electronicaly.


You may not:

a.	Charge EXCESSIVE copying fees for the copying of this software.

b.	Package the software in a way that infers to consumers that they are purchasing a registered 
version of the software.

c.	Change the software or any associated files.

d.	Use or demonstrate this program at any convention, seminar, party, meeting or other public or 
private event if as a result of this demonstartion you receive any kind of reward or payment without the 
permission of Mithril Software.

e.	Accept or receive reward for the use of the software, without the permission of Mithril Software.

f.	Use the software in a manner for which it is not intended.

g.	Use the software if a corporation you represent or are employed by will receive payment or reward 
as a result, without the permission of Mithril Software.

TERM

	The licence is effective until terminated.  You may terminate it at any other time by destroying the 
program, data and scenario files and all copies as well as any printed material.

	There is no time limit on this licence provided you keep within the terms and conditions listed 
above you may use this software for as long as you like.

WARRANTY

	This version sw1.12 comes without any warranty at all.

	While the authors have taken all reasonable care in the production of the software, they do not 
accept responsibility for any loss caused directly or indirectly by use of this software.

SUPPORT

	This version sw1.12 comes without any official support at all.

	David Readman has offered to answer questions and provide some limited support for this version 
on the INTERNET but makes it clear that Registered Customers come first. his internet adress is : 
JAGUAR@SUBURBIA.APANA.ORG.AU

REQUEST FROM THE AUTHORS

	If you use this version of BRIDGE CREW for an extended period of time then it would be polite to 
consider (and act upon) getting a registered version. The registered version is superior in many ways and 
comes with printed manuals. It is constantly being updated in all probability by the time you read this it will 
have a new batch of features not found in sw1.12.

COPYRIGHT and TRADEMARKS

BRIDGE CREW is a trademark of Mithril Software.

This product is copyright Mithril Software 1994.



Acknowledgements

Bridge Crew would not have been possible without the assistance of many people who have given their time 
and effort with little expectation of reward.  We would like to thank those who have been involved:

Programming

Robert Cox, David Swan, Brenton Ross,
Peter Mazzarol

Technical Assistance

Robbie Matthews, David Boffinger

Scenario Design

Robert Cox, Roger Nicholls, Peter Wass, Barbara Hall, Trish Crowther.
Documentation

Robert Cox, Trish Crowther, Peter Wass, Barbara Hall, David Swan.

Play Testing

Robert Cox, Roger Nicholls, Barbara Hall, Peter Wass, Catherine Cook, Trish Crowther, David Swan, Michael 
Swan, Craig Alexander, Clinton Moore-Crouch, Brenton Ross, David Boffinger,  Peter Mazzarol, Scott Yates, 
Rodney Kearins, Kevin Maclean, Robbie Matthews, David Readman, Wes Nicholson, Nick Prosser.

Introduction

Welcome to the world of computer assisted co-operative role-playing. Bridge Crew is the first of a series of 
computer assisted multi- player role-playing games designed to be played on the current (read previous) 
generation of high power DOS PC's.

BRIDGE CREW is played with a game master who designs a scenario for the players and may get actively 
involved during the playing of the scenario. Whilst non combat scenarios can be built, it is essentially a 
combat driven game, hence most scenarios have starship combat.

Each player has a computer terminal or Personal Computer with which he/she can pull up various reports 
about the state of the ship and the state of the universe.  He/she can also enter commands that relate to the 
player's assigned functions (e.g. the helm officer can set course and speed). 

Like the bridge of a modern warship, the captain gives orders and expects the crew to either obey or make 
sensible alternative suggestions.  The crew is expected to run the relevant parts of the ship without specific 
orders.


Software installation

The software is supplied in compressed (.ZIP) format on high density diskettes.  You can install Bridge Crew 
onto any hard disk drive. By using the shareware program PKUNZIP.  

The software is supplied  and should be placed in a directory C:\BCREW 

The scenario and data files should be  places in C:\UNIVERSE.

If you don't have a drive C: then you will need to set the environment variable BCREW see below.

*****IMPORTANT*****
Before installing the software, read README.TXT.  Any changes have been included in README.TXT.
Setting up the software

A setup program is provided which must be run from the directory to which you copied the program files.  
This program configures Bridge Crew to suit the specific hardware installed (i.e. daisy-chaining or a multi-
port card).  Enter BCREWSET at the DOS prompt:

>BCREWSET

Environment variables

If you do not want to run Bridge Crew from the C:\BCREW directory, then you must set the environment 
variable BCREW using the command 

>SET BCREW=C:\your directory\

Drives other than C are also supported.  Eg:

>SET BCREW=D:\your directory\

Most people would add this command to the AUTOEXEC.BAT file.


BCREW SET instructions

The main screen of the setup program is shown below.

BRIDGE CREW SETUP PROGRAM

  1 - Game Details
  2 - Hardware Details
  3 - Exit and save
  4 - Quit (Dont Save)

  Enter Option  4

Note - remember to exit using 3 if you make changes.

Game Details

BRIDGE CREW SETUP PROGRAM

  GRAPHICS MODE    1     0=VGA      1=EGA     2=CGA
  COLOR SCHEME     1     0=16Colour 1=8Colour 2=2Colour 3=4Colour 4=CGA
  WORLD DIRECTORY  c:\universe\
  GM Port          2

  COM1 (Port 0)  1      COM7  (Port 6)    0    0=Not there
  COM2 (Port 1)  1      COM8  (Port 7)    0    1=Terminal Present
  COM3 (Port 2)  1      COM9  (Port 8)    0    2=PC running BCTERM
  COM4 (Port 3)  1      COM10 (Port 9)    0    3=PC running BCTERM
  COM5 (Port 4)  0      COM11 (Port 10)   0      daisy chained terminal
  COM6 (Port 5)  0      COM12 (Port 11)   0

Note:	It is generally better to use EGA because of the smoother screen refresh even on VGA systems.

Note:	Colour Scheme 1 is designed for use with a 8 shades of grey projection panel.  For a colour monitor 
0 is much better.

Note:	CGA looks crummy and will not be supported in future releases.

Note:	World directory must end with a \  

Note:     The world directory must not have a trailing space

Hardware Details (using COM1 and COM2)

BRIDGE CREW SETUP PROGRAM  (Hardware Configuration)

  Extra Ports  0    0=NONE    1=Multi Port Card   2=DOS (4 port)

  Interupt  IRQ number   5   (Usually 2 or 5)
  Number of extra ports  8   (Usually 2 4 or 8)


  COM3  (Port 2)   180
  COM4  (Port 3)   188
  COM5  (Port 4)   190
  COM6  (Port 5)   198
  COM7  (Port 6)   1a0
  COM2  (Port 7)   1a8
  COM9  (Port 8)   1b0
  COM10 (Port 9)   1b8
  COM11 (Port 10)  1c0
  COM12 (Port 11)  1c8

This shows the setup to use just COM1: and COM2: (the standard dos ports).

The  important bit is to set the Extra Ports to 0  all other parameter will be ignored.

NOTE: the  hardware option 2   DOS (4 port) does not work and will be removed from future versions. 

Hardware Details (using AST compatible or Programax-8X card)

BRIDGE CREW SETUP PROGRAM  (Hardware Configuration)

  Extra Ports  1    0=NONE    1=Multi Port Card   2=DOS (4 port)

  Interupt  IRQ number   5   (Usually 2 or 5)
  Number of extra ports  8   (Usually 2 4 or 8)


  COM3  (Port 2)   180
  COM4  (Port 3)   188
  COM5  (Port 4)   190
  COM6  (Port 5)   198
  COM7  (Port 6)   1a0
  COM2  (Port 7)   1a8
  COM9  (Port 8)   1b0
  COM10 (Port 9)   1b8
  COM11 (Port 10)  1c0
  COM12 (Port 11)  1c8

This shows the setup for a Programax 8X card

the switch settings on the card will need to be set to :

IRQ 5  (Switch S1)
I/O address 180H (switch S2)
Uart latch  1C0H (switch  S3 (optional UART IO))

Note - It should be possible to use interrupt 2 instead of 5 provided you set
"Interupt  IRQ number   2   (Usually 2 or 5)"  in the bcrewset program and IRQ 2 on the card (Switch S1).

How Bridge crew handles multi port cards.

Bridge crew expects COM1 and COM2 to occupy the 'standard' I/O addresses and use the interrupts shown 
below:

COM1
H3F8, IRQ4

COM2
H2F8, IRQ3


There aren't really  standard I/O addresses and interrupts for COM3 and COM4.  The most common 
arrangements seem to have them as shown below:

COM3
H3E8, IRQ4

COM4
H2E8, IRQ3


As you will notice, the interrupts are the same as COM1 and COM2. Unfortunately this arrangement will not 
work with Bridge Crew.

Bridge Crew expects all ports above COM1 and COM2 to share one interrupt and to be using a different 
interrupt to COM1 and COM2.  This is the way that the AST and prograMAX-8 cards work.  Using this 
system, many ports may share one interrupt and Bridge Crew I/O will run happily.  This is also the system 
used by XENIX, UNIX and Coherent so most cards that will support those operating systems will also work 
with bridge crew.  In theory any multi port card that has 2 to 8 ports, can share interrupts and uses a 
standard configuration of (8250 or 16450) compatible UARTS should in theory work.

Some cards are 'intelligent' and operate with UNIX intelligently.  These are generally expensive cards that 
have their own CPU and memory.  They deal with character streams as packets and will not run with Bridge 
Crew unless configured to emulate a dumb card (which some of them can do if you set the right 
jumpers/switches).

Because of the different strategies for the placement of I/O addresses within memory and the use of various 
different interrupt lines, Bridge Crew comes with a set-up program that enables users to configure the 
specific multi-port card that is in use.

Notes about the various multi port cards that we have tried.

AST compatible 4 port cards
	Number of ports: 4
	Works fine if you do not load the drivers supplied.
	Available from Mithril software for $145 (includes postage).

PRONET-8 (prograMAX-8)
	Number of ports: 8
	Works fine if you do not load the drivers supplied.
	Available from Mithril software for $340 (includes postage).

DFI (COM-400)
	Number of ports: 4
	This card refuses to share interrupts across its second 2 ports so can at best be used as a 2 port card. 

GW451C 
	Number of ports: 2
	This card works fine as COM1 and COM2 but will not operate as COM3 and COM4. It is not suitable to 
add 'extra' ports to Bridge Crew. This card is typical of most cheap 2 port cards.

Support

For the shareware version of Bridge Crew support is limited to the 'Self Help' system. If you can't find 
somone to help you then that's too bad.

To register and get your questions answered contact:
	Mithril Software Pty Ltd
	PO Box 225
	Kippax
	ACT 2615

FAX  within  australia (06) 254 6280

Eg   (international access code) 61 6 254 6280

Eg from the USA  011 61 6 254 6280


Getting Started

To start your first scenario, run the setup program to tell BRIDGE CREW about your serial port 
configuration, and about the terminals on which the game will be run.

if you are running daisy-chained terminals you will need to load the files BCTERM.EXE, BCTERSET.EXE 
and BCTERSET.DAT onto the PCs running in the daisy chain.

We also provide a dumb terminal emulator called VT100.EXE which you can used to make a PC emulate a 
dumb terminal.

The communications software is pre-set for 9600 BAUD, 8 data bits and 1 stop bit.  No flow control is used, 
so configure the VT100 emulators or compatible terminals to these settings.

At the DOS prompt, type 
>CD \BCREW

where BCREW is the directory that contains the Bridge Crew program.
Type 

>BCREW PUB1.SSW

The program will display a title screen.  Press Enter to proceed - the title screen will disappear.  The program 
will initialise the COMM ports, and display their status.  If a COMM port shows a negative status, it would 
normally mean a communications error.

If all goes well, the main console display will be shown.  This will update every two seconds (check the 
charging of the shields to confirm this).  The terminals will now respond to the pressing of the enter key with 
a '>' prompt.  Type the command WHO on the GM's terminal to ensure that the GM starts with all security 
codes assigned to him or her. If not, rerun bcrewset.

Tell the person who will be playing the part of the security officer to enter the command WHO, (this will 
return his or her port number),the GM should then use the SECUR port_number command to assign 
security to the security officer on this port.

Stopping the game

To stop the game, enter a # (Shift 3 on most keyboards) on the main keyboard (not the GM's terminal).

To restart the game after a pause (eg Helm Hit) use the shift 7 or andpersand (&) character.


Notes about How the Game Plays

Ship Recognition or Who sees Whom?

The Bridge Crew software maintains five lists of ships.  These are: 

Visible ships:

These can be seen by the command 'RECON' and have two visibility states; 'Clearly Visible' and 'Visible'.  If a 
ship is clearly visible, it will display on the main screen as a silhouette.  If not, it will appear as a blob 
(normally of varying size).  This list is used by the 'MODE TACTICAL' display.

Known Ships:

This is a list of ships that are known to the players.  It is the list shown by the 'THINGS' command and 
contains all objects that are known to the player's side.  Known ships are always displayed at their last 
known location.  This is the list used by the MODE STRATEGIC display.  As DSF Command knows about 
these ships, it will periodically update their positions based on subspace radio intercept and sensors, or 
sightings.  This action causes the strategy officer to receive the message "Position update  shipid".  The 
GM may at any time update the last known position of a ship on this list by using the IUPDATE command.

Unknown ships:

This is a list of ships that are in the game but that are not known to the players.  They are noted on the 
LOCATE command as unknown.  Note:  Unknown ships will become known if they are within sensor range 
of a friendly ship or if they are made known by the GM (using the KNOWN command).

Inactive ships:

These ships have been taken out of play by the GM using the DEACTIVATE command, or have been 
destroyed by enemy fire.  They can be listed using the INACTIVE and the LOCATE commands.  Ships that 
have been deactivated (rather than killed) can be re-introduced into the game by the command ACTIVATE.

Non-Player Location list:

The non player (Hostile and Neutral) ships also maintain a list of the last known positions of the players' 
ships.  This list (which always contains all ships) also contains the visibility status of the players' ship(s).  
The GM commands XTHINGS and XRECON use this list.  The last known location of the players' ship(s) is 
periodically updated on this list, but since this only occurs randomly about every 10 minutes, the GM may 
force the position to be updated for a specific ship using the XUPDATE command.  This command 
immediately updates the position of the requested ship for the (computer moderated) non-player ships.  This 
prevents the non-player ships endlessly circling the last known position of the player ship(s).

When using transporters or giving orders, you will discover that player commands are at times ignored by 
the subject ship.  The most common reason for this is that the non-player ships report to a different admiral.  
The GM can find the admiral by using the REP8 command.  Valid admirals are:

	0	Free and Independent
	1	FIP Deep Space Fleet
	2	FIP Merchant Marine
	3	Hostile.

The players can only ORDER ships that come under the command of Admiral 1 unless a CONDITION RED 
is declared, in which case, ships under the command of Admiral 2 will also obey the ORDER command.

Randomness in the Game 

There are several actions where randomness is used to add to the game play and ensure that the same 
scenario will rarely play in the same way twice.

1.	Non player crew efficiency.  This is the probability that the non-player crew will make the correct 
decisions in a given two second turn.  There is a different crew efficiency figure for all of the ten 
imaginary crew functions (helm, missile, beam, etc.).  This can be determined using the REP2 command

2.	Damage allocation.  When hits get through the shield one function (chosen randomly) can take up to 
1/2 the damage.  The rest is spread around more or less evenly (i.e. for each point, a random function is 
selected).

3.	Position updates.  These occur at random intervals.  For example, in the FIP universe, they average one 
update every ten minutes, (depending on the race, ship, class, etc.).

4.	Damage chances.  The percentage probability of function failure (eg a misfire) is 100 less the current 
performance of the weapon.

5.	There is a pseudo-random time delay - e.g. how rapidly other ships respond to messages - "ID" 
"STATUS" etc.

Game Mastering

As the GM you have limited control of the game during play.  One of the important things to remember is the 
fact that once combat is entered into, things happen very quickly and the players can be destroyed before 
you can react.  This is a game where strategy is real time (though not hurried or heavily dependent on 
reflexes, as in an arcade game).

The basic scenarios supplied give you a universe and a series of campaigns to take the players through. 
YOU are expected to embellish the play by intervening at various intervals to keep the game exciting and 
even to modify the scenarios before play begins in order to change them to fit in with your view of the 
universe.

Your job as the GM involves the following steps:

1.	Study the System (so that you know what you are doing).
2.	Set the Stage.
3.	Running a Campaign.
4.	Awarding OER ratings, Developing the characters and giving Decorations
5.	Keeping Characters that Play Well Alive.
6.	Mercilessly Killing Characters That Play Badly.
7.	Keeping the Players Happy.

1.	Study the system

	You have quite a few extra commands to learn as the GM.  In addition, you should know all the player 
commands. You will need to have a working knowledge of the way non-player ships react and why, as 
well as some understanding of starship tactics.

	It is sensible to play PUB1.SSW as a player to get a feel for the duties of each position and to become 
familiar with all the commands.

	Do not expect to understand the system in less than twenty hours of play.

2.	Set the stage

	Think out each scenario, keep records of players' achievements, ranks, etc.  Don't let the game become 
boring (or "What shall we kill this week, Captain?") 

	Think about the universe:  The game includes several variables that affect the entire universe.  These 
are set using the SETV and SETP commands and should, in theory, be constant for the entire universe.

3. Only relevant in the Registered (Full) version.

	In the shareware version only limited campains are possible due to the limited number of ships

4. Awarding OER ratings.

Characters' Tour of Duty:

	We have conveniently placed a tour of duty at 3 scenarios.  There is no need for a GM to stick to this 
number, however it is a lot harder to keep the players alive (while keeping the game exciting) in this kind 
of world than in a traditional role-play world.  For example, making a tour of duty consist of 25 scenarios 
would make it unlikely that you would have any surviving players!

	Officer Efficiency Rating:

	The OER is designed to fill in for the common or garden variety experience point system found in the 
traditional role-play games.  It gives the players some feedback and assists the GM in assessing how a 
player / character is performing.

Score	Meaning

	5	The Character has performed excellently.  Virtually all decisions and actions were correct and 
timely.

	4	The character has performed well, but not excellently.  Decisions and actions were generally 
correct and timely.

	3	The character has performed adequately.  This rating is a pass and should not be looked down 
on.  The character is competent and can be trusted to perform well.

	2	The character failed in a minor way.  This is specifically a manner that did not result in loss of life 
or property.

	1	Fail.  Bad, very bad, not good.  Get the picture?

Decorations:

	Decorations may be recommended by the captain (or any 2 bridge officers) and the Admiralty (GM) will 
decide if the decoration should be awarded.

	Decorations for any universe are listed in the Player World books. The shareware version does not 
come with a world book.

5.	Keeping characters that play well alive.

	This actually requires a bit of skill.  First of all, you must be able to judge good play and secondly, you 
must avoid overmatching (pitting the players against an unbeatable foe).

6.	Mercilessly Killing Characters that play badly.

	This function is relatively easy since the way to tell if they are playing well is to give them a difficult live 
scenario with a heavy accent on combat.

7.	Keeping the players happy.

	Whilst the novelty of the game will amuse the players for a while, to run an interesting ongoing 
campaign, you will need (as with all role-playing) to ensure that the majority of players enjoy the 
majority of scenarios.  Look for signs of disquiet.  These would include:

	Players not turning up.
	Players griping about the unfairness of the scenarios.
	Players griping about other players without a lot of cause.
	Players feeling that the GM is out to get them (Actually a little of this feeling is quite good since it 
permits the player to feel triumphant when they succeed or survive.  GMs could learn to act 
defeated if the players succeed in a difficult scenario.  This is good for player morale.)
	
	The GM must also ensure that all players get a chance to play captain and other bridge functions if they 
desire.  Play testing has shown that not all players want to be captain.  GMs should be aware of players 
feelings of responsibility towards other players.  In the event of limited terminals being available, ensure 
that they get a fair run at the game (share of the terminals).

	While some gaming groups take easily to computer gaming, others will need significant running of 
training scenarios to develop keyboard and strategy skills. GMs should assess the special needs of 
new players entering a currently running campaign.

Running Campaigns

The Registered version is better suited to running campains because of the larger number of ships and ship 
classes it supports.

GMs are advised to review the multi-line messages prior to play.  Multi line messages use the commands:

	COMP
	GET
	REPORT COMPUTER
	DOWN
	XDOWN

For further details, see the GM's COMP command.

Customising Your Universe

ecause no two GMs imagine the same universe,  small degree of customising is possible in the BRIDGE 
CREW game.  This customisation should, in theory, be consistient within a given universe.  Therefore GMs 
should either modify all scenarios, or write a common script file to set all the universe parameters to the 
settings he or she is happy with.

The following universe parameters are supported:

	HELM HIT
	OVERHEATING
	INTEGRITY
	AUTO VIEW
	DIST SPEED
	HEAT DAMAGE
	CLOAK RAND
	MOVE ENERGY

HELM HIT

Possible values: YES or NO

Function:
To stop play when a crewmember is killed in the helm of the players' starship.

Effect on play :
Allows the GM to remove dead players as they are killed.  We suggest a saving throw for all players on the 
bridge.  The one that fails by most points is removed.  This affects combat immediately, since security etc, 
will need to be re-assigned.  Other role-playing effects are possible.  Eg if you have spare crew in the ready 
room, you may wish to have a replacement walk in and take the dead crew member's place.  The ship's doctor 
could be involved - the possibilities are limited only by your imagination.

To continue when the helm has been hit, type a single & (shift 7) character on the main console.

OVERHEATING

Possible values: YES or NO

Function:
To cause the warp engines to malfunction when the engine temprature reaches 100.

Effect on play :
Slows non player ships.  Allows the GM to force the crew to manage the engine temperature as well as 
energy.  With the scenario designer's kit, it allows the creation of ships with crews gungho enough to blow 
up their own engines.  Engine temperature may rise on any turn when both the requested speed and the 
ship's actual speed is above the ship's maximum safe speed. See the player game manual on "Heat Strain".

INTEGRITY

Possible values: YES or NO

Function:
To cause the ship to fall apart if the function 'Hull' reaches 0.

Effect on play:Reduces the average amount of damage that ships can sustain.  Forces the crew to repair the 
hull function.  The INTEGRITY parameter is best used in conjunction with the scenario designer's kit to 
enable variations on the damage control strategy required to keep ships alive.

AUTO VIEW

Possible values: YES or NO

Function:
To allow the helm comand AUTOVIEW to work.

Effect on play :
Gives the helmsman the option of not having to center the starship at regular intervals.  Reduces the visual 
feedback associated with the players ship moving - this can can confuse new players.

DIST SPEED

Possible values: YES or NO

Function:
To cause the detail command to display last known heading and speed.

Effect on play:
Increases information available to the players.

Note:  The rationale behind this variable is that the technology used to track starships may or may not 
provide this level of detail.  As an historical note, radio intercept during world war two did not provide any 
information other than aproximate location.

HEAT DAMAGE

Possible values: 0 to 32000 

Function:
This value is the maximum damage that will be done when an engine overheats.  The actual damage is a 
random number between 1 and the value set with the command.

Effect on play :
If this value is high, it seriously increases the risk of major engine damage when overheating of the engine 
occurs.

Eg, if the value is set to 100, then up to 100 points of damage can be done in one turn.  If the engines are 
allowed to overheat, the average damage will be 50.

CLOAK RAND

Possible values: 0 to 1000

Function:
To give a fixed probability (in tenths of percent) that a cloaked vessel will de-cloak on a given turn.

Effect on play :
To vary the visibility of cloaked vessels by making them de-cloak more often.

Example values:
	0	Ships will not randomly de cloak
	10	Ships will decloak 1% of the turns (roughly once each 3 mins)
	100	Ships will decloak 10% of the turns (or about once each 20 seconds)

MOVE ENERGY

Possible values: 0 to 100

Function:
To to alter the calculation of energy used; by allowing the calculation of energy used at a given speed to be 
based on actual speed or requested speed.

Effect on play:
Removes or enables a technique coined by the player that discovered it as 'Speed Osciliation'.  This relies 
upon setting speed 80 till the battery is flat then setting speed 0 until the battery is recharged (which on a 
monarch takes about 3 turns) then setting speed 80 again.  By doing this, a Monarch can maintain an 
average speed of about 77 and never run out of energy.

Example settings:
	0	Energy usage is entierly based on requested speed.
	50	Energy usage is based half on the requested speed and half on the actual speed.
	100	Energy usage is entierly based on actual speed.
Role-play systems


If you are using GURPS , Traveller , or any other SF (or fantasy?) role-play system then you can ignore the 
role-play rules supplied with the registered version and use the ones supplied with the role-play system you 
are using.  Note however, that long tours of duty of (E.g. 25 missions) are very unlikely to have any 
survivors, so I would suggest that a dice roll be used to determine how many 'interesting' missions go into a 
tour of duty (i.e. you don't play 25 missions, only the one to six interesting ones).  GMs should not disclose 
how many interesting missions are in a particular tour of duty if this method is adopted.

Roll two six sided dice

2-3		1 interesting mission
4-5		2 interesting missions
6-8		3 interesting missions
9-10	4 interesting missions
11		5 interesting missions
12		6 interesting missions
	



Obviously with alternate game systems some thought will need to be given to the required qualifications 
and stats for bridge officers.


Player Commands

The player commands are included in the Bridge Crew player manual.  The GM must be familiar with the 
player commands and their function.  This chapter contains supplementary information about those 
commands that is useful to the GM.

ARC angle weapon_list

Sets the dispersion angle of the beam weapons.  In the current version of Bridge Crew, no advantage can be 
gained from setting it to anything other than the default (10). In the current universes (FIP and Shareware)

ASSIGN function1 number function2

Note that if the DC function is damaged you can only order crew to and from the bridge (HELM) until it is 
repaired.

BLOCK target weapon_list

It can take the computer up to ten (10) turns to unlock from a destryed vessel.

BUNLOCK weapon_list

This command has no effect on non-player ships, but has been added to enhance role-playing.

CHARGE weapon_list
or
BCHARGE weapon_list

The crew will get the rather vague message 'no ammo' if there is insufficient energy to start the charging 
process.  On an energy starved ship, it can take a very long time to charge the beam weapons.

COURSE angle

This command is affected by the performance of the HELM function, so if you are not turning check your 
helm for damage or lack of crew.

DELETE message_number

Don't confuse this player command with the GM command XDELETE.

DETAIL ship 

This command is affected by the setting of the DIST SPEED parameter.

DIRECT   end_location   [start_location]

This command is really useful when you are setting up scenarios.

ETA  start_location   speed   end_location

Another command that is useful when you are setting up scenarios.

FROM  ship_id  start_ship_id

Remember that inactive and unknown ships do not appear on this report.  Remember that  the last known 
location is displayed (not the current location)

FUNCTION function_id

You may find that players complain the a function is not repairing or that transporting or assigning to a 
function do not work.  This command can be used to assist you in determining why these things are not 
happening.

The function_id can be found from the command REPORT FUNCTIONS.

GET message number

Don't forget that messages can be set up using the COMP command.

LOAD weapon_list
or
MLOAD weapon_list

Crew will get the rather vague message 'no ammo' if there is insufficient energy to start the charging process.  
This message can also mean that the missile magazine is empty.

MUNLOCK weapon_list

This command has no effect on non-player ships, but has been added to enhance role-playing.

LOG text

This is stored in a file called BCREWLOG.DAT, which can be viewed after play using the usual DOS 
commands for text file viewing.

MACRO number text

As the GM, you can use any command as a MACRO

MFIRE weapon_list

Don't forget that ships carry a limited number of missiles which you can reload at any time with the 
XRELOAD command.

MODIFY dsf_ship  angle  distance

These parameters are not used once combat is entered except for ships currently governed by the FLEET 
command.

MODSPEED dsf_ship  speed  [rotate]

These parameters are not used once combat is entered except for ships currently governed by the FLEET 
command.

ORDER dsf_ship  mission details

Orders a ship to a specific mission type.

Where mission details include the following commands.

ATTACK target ship
The ship will move toward and try to intercept the target ship.  If the ship is not detected by the 
sensors, it will move towards the last known location of the target ship.  It will engage other targets of 
opportunity within threat distance if the target ship is not within threat distance. While in combat, 
hostile ships that are very close will cause the crew to 'Panic' and set other close hostiles as a priority 
target.  This tendency to target other close hostiles rather than the ship that they have been told to 
attack, can be rather annoying, especially if the close hostile is trying to run away.   This problem can 
be reduced by the clever use of the FLEET and TRADE commands.  (Eg Make the ship FLEET rather 
than attack the target)

ESCORT ship

This command is similar to fleet; however if a hostile ship comes within threat distance, the ship will 
actively seek out the hostile ship and attack it.

FLEET ship

The ship will move towards and maintain station on ship if the ship is hostile it will shoot at it. If the 
ship is friendly then it will shoot at any hostile within threat distance.

GOTO location

The ship will move towards location, but accept combat on the way, ie it will head out and attack other 
craft.

If you wish to cut a path to a location and not be deviated from your goal then use TRADE location 
same_loaction

LOWER

Lowers shields on friendly starships for ten turns so that the transporters can be used.

	Future versions may allow some variation on the ten turn limit.

PATROL  location1 location2

The ship will move from location1 to location2 and will attack any hostile within threat distance.

RETREAT location

The ship will move towards location and avoid combat

SCOUT location1 location2

The ship will move from location1 to loacation2, but will attempt to avoid combat.

SHADOW ship

This command allows the ship to follow another ship at a distance.  The distance is defined by the 
captain's threat distance and for this reason ship is often defined as having captain 20, who has a 
suitable threat distance for shadowing in the FIP universe.

TRADE location1 location2

The ship will ply the trade routes between the 2 locations pausing only long enough to 
transport/unload cargo at each destination.  If the vessel is armed, it will shoot at any hostile it can 
without deviating from its course.

WAIT

The ship will wait at speed 0 until a hostile ship comes within the threat range of the current captaincy 
style,  then it will attack the hostile ship.

QUEUE

If you are GMing you have the XQUEUE command as well.  Don't get them confused!

READ message number

Dont confuse the command with XREAD.

REPORT CROSSSECTION

See the section on How Sensors Work.  Note:  In the current release of Bridge Crew, frequency ZZ is not 
actually used.

SCALE number

You can simulate a damaged ship's view screen by periodically changing the scale.

SEND

The non-player ships will automatically respond to the SEND command for the following message:

	HELLO, STATUS, ID, and NEWS.

The responses may be set with the TEXT command.

The responses may be seen with the REP8 command.

THINGS  ship_id
Remember that inactive and unknown ships do not appear on this report.  Remember that  the last known 
location is displayed (not the current location).

VIEW location

You can simulate a damaged ship's view screen by periodically viewing from a different spot.

WHO

Sometimes, if security is not assigned correctly, players entering valid commands will receive the message 
'Syntax Error'.  You can use the REPORT SECURITY command to check if this is the problem, or advise the 
player to use the WHO command to check his or her security.

ZONE  location1

This command is generally used in live play only and players may need to be reminded of its existence. In 
the shareware version only PUB9.SSW has zones set up correctly.


GM Commands

Throughout the section on commands, the following applies:

Location:	is the location in co-ordinates eg 303.21125 is the location where x=303 and y=21125.
	or	it is the name of a star system
	or	it is the Id of a starship
	or	it is the name of a starship.

	In the  last two options, the last known location of the starship is used by the program to determine 
the location.

	If location is the id of a starship, then actual location, rather than last known location can be 
specified by using the '/' character.  Eg 
	/X3 
	is the actual loaction of X3.

Shipid	is the two letter code of a ship, or the name of a ship

Any portion of a command placed within square brackets is optional.

__________________________________________________________________________________

ACTIVATE shipid

Where shipid is the shipid of the ship you wish to activate.

Makes the ship able to effect play.  A badly damaged ship that is inactive through 'death of ship' will 
deactivate itself again on the next turn.

ADJUST CREW|PASSENGERS|CASUALTIES shipid  ship_function  number

Set a new level of crew or passengers for the shipid.  This will not allow you to over-fill the ship.

CAPTAIN shipid new_captain_num

Change the captaincy style.  Especially useful in conjunction with MISSION SHADOW.  Captaincy styles 
mainly affect the combat characteristics of a non-player ship.

Note that captain 20 is very good for shadowing, but is not good for attacking.

See the section on  Captaincy Styles in this manual.  

COMBAT [start_ship] [dist_ship]

This comand has two functions.  Firstly it shows whether a non player ship is in combat.  If it is in combat, 
the ship it is in combat with is shown under the heading combat.

Secondly it shows all distances from dist_ship based on actual (as opposed to last known) location.

Other than these differences the command is simmilar to the LOCATE command.

COMP message_number line_number text

This allows you to alter the multi line computer messages that have been loaded by the scenario.  If no 
message exists in the message_number you select, it will create one there.  This allows you to add extra 
messages when you want to. The text should have less then seventy characters.  As this can take some 
time, it is better to run the scenario, create the messages and then save it, rather than trying to enter it during 
play.

CREW shipid

GM's equivalent of the player command REPORT CREW.  Performs the command for the shipid.

DAMAGE shipid  function  new_value

Set a given shipid's function damage to a new value.  Values are never set higher than the maximum original 
damage permitted (see player game manual Chapter How the Game Plays, subheading Ships Functions) or 
lower than 0.  Players are not informed.  This can also be used to fix a function quickly if so desired.

This command can also be used by the GM to rule on spares.  The normal method is for the GM to set the 
damage in a totally destroyed function of a player ship to one, then to send a message to explain that the 
jury-rigging is in place.

See Also: MALFUNCTION

DATE new_stardate

This command allows the GM to change the stardate.  this is normally used during a campaign to add 
continuity.

EG  >DATE 1146.678

DEACTIVATE shipid

Where shipid is the shipid of the ship you wish to remove from play.

Stops the ship from actively affecting play.

DMOVE shipid location angle distance

This command moves shipid to a position defined by location, angle and distance.  Eg 

DMOVE F1 X3 200 500

will place F1 500 TSU from the last known location of X3, at an angle of 20 degress (200).

DMOVE F1 /X3 200 500

will place F1 500 TSU from the actual location of X3, at an angle of 20 degress (200).



DOWN message_number

This downloads a multi line message into the ship's computer and allows the players to GET it.

ENERGY shipid

List the energy used at various speeds.  GM's equivalent of the player command REPORT ENERGY.

EXHUME shipid

Where shipid is the shipid of the ship you wish to exhume.  Eg

	EXHUME X3

will repair all of X3's functions and stock them with crew.  It will also make a guess at a suitable number of 
extra Damage Control crew.  EXHUME will not affect the active flag, so exhumed ships will remain active or 
inactive as they were prior to the command EXHUME being issued.  Note that shields are not recharged by 
the command, nor are missiles reloaded.

NOTE: exhume does not adjust casualties ut will in version 1.14

FREEZE

Halts movement.  This command only freezes movement, not combat, stardate, etc.

GMGM [virtual_port_number] [COMMS]

Enables virtual_port_number as a second GM terminal.  If the word COMMS is added then the "Message 
not read" reminders will be directed to the secondary GM terminal rather than to the primary GM terminal.  If 
virtual_port_number is omitted then the current second GM prot is listed.

GUARD shipid

Lists the shield status and energy state for the given shipid.  The energy crisis flag is useful because it 
assists the GM in predicting non-players' energy management strategies.  The resultant report is shown 
below:

Front :1120 200 100% UP  
Right :1120 200 100% UP  
Back  :1120 200 100% UP  
Left  :1120 200 100% UP  
Battery 4000
Energy  1080
Energy Crisis 0

NOTE:  if energy crisis is greater than zero then the non-player crew may be taking action to reduce energy 
usage in non-essential systems.  The higher the value the more drastic the action.

IMIT from_ship to_ship message

This is a command that sends a message to the player's ship, but it is sent as a message intercepted enroute 
between two other ships.  The message will appear in the ships message queue with the to_ship being any 
ship and the text INTERCEPT appended to the front of the message.  At the same time, the positions of the 
from_ship and to_ship will be updated as if an IUPDATE had been done.

INACT count

Where 'count' is the number of the first ship to be listed.

List up to ten inactive ships at a time.

IUPDATE shipid

Updates the last known location of a ship to its present location.  Non-player hostile ships have a flag set in 
them to update their position at random intervals.  If the GM specifically wants the last known position 
updated then he or she can use IUPDATE.  The command will not work on UNKNOWN ships.

KNOWN shipid 
UNKNOWN shipid

These two commands add or remove the ships from the players' THINGS display.  Ships will automatically 
become known when a ship friendly to the players can scan them.  Only known ships have their position 
updated periodically on the THINGS report.  Ships that are unknown will be listed and indicated as such by 
the LOCATE command.  The important play factor is that position updates are never received for unknown 
ships.  It is polite therefor if the GM, after making a ship 'known' were to perform the IUPD command to 
advise the players.  Also note that ships automatically become known as soon as they enter sensor range of 
a friendly ship.

LOCATE [shipid]

Where shipid is the first ship to be listed.

The GM's version of the THINGS command.  Lists actual position of all ships.  

Id Heading Distance   Xpos.Ypos   Known Status Class
F0     0        1   500500. 195500 Yes  Alive  MONARCH CLASS
M1  3326      917   500077. 196314 Yes  Alive  LIBERTY CLASS
F1   900      896   501396. 195542 Yes  Alive  LARSON CLASS
X1   160    10439   503384. 205533 Yes  Alive  C-7A CLASS
X2   231     9779   504346. 204492 Yes  Alive  HC10
X3   209    10729   504344. 205517 Yes  Alive  F-23 CLASS
S1   167    10440   503500. 205500 No   Inact. MERCURY CLASS
S2   167    10440   503500. 205500 No   Inact. MERCURY CLASS
S3   167    10440   503500. 205500 No   Inact. MERCURY CLASS
More

MALFUNCTION shipid  function  new_value

Where shipid is the shipid; function is the function you wish to damage and new_value is the new amount 
of damage points that the function has.

Sets the damage for a function to a new value and sends a communication to the player ship if shipid is 
under the command of the same admiral as the player ship.

This will not let you put more than the maximum value, or less than 0 points into a function, even if you try.

MISSION shipid  new mission

Where 'shipid' is the ship you wish to change its orders and 'new mission' is one of the following standard 
missions:

Command
Meaning

wait
Do nothing till further orders.

escort shipid
Escort and defend

trade  location  location
Move to and from pausing to load/unload

shadow shipid
Follow, hide, don't attack (Works best for captain 20)

attack shipid
Attack

patrol location  location
Defend and watch

scout  location  location
Just watch

goto   location
Go there

fleet  shipid
Join a fleet and keep station

retreat location
Get the hell out of here

lower
Lower shields for ten turns.


GM's version of ORDER command.  See player manual.

MOD1 shipid  angle  distance

Just like the player command MODIFY but works on any ship.

MOD2 shipid  speed  [rotate]

Just like the player command MODSPEED but works on any ship

MOVE shipid  location

Where shipid is the ship to be moved and location is a ship id, a system id or an  x.y  co-ordinate.

Move ship to the location indicated.  This does not update the last known location of the ship. 

For example,

MOVE F1 /X3

will place F1 at the actual location of X3.

MOVE F1 1339.6774

will place F1 at the location 1339.6774.

MPRINT ship_id [file_name]

MPRINT is used to produce ships' technical details for inclusion in a manual.  File_name is optional and if 
left out, the details will be sent to the printer.  If a file name is supplied, the resultant file will be a standard 
dos text file.

The printer is connected to LPT1 and must be a text printer (ie not a postscript printer).

Note:  Not all of the ships in the supplied universe are included in the manuals, only the more commonly 
used ones.  Customers who buy the Scenario Designer's Kit will find this command useful when they are 
designing ships for their universe.

PAUSE message

Pauses the game, sending a message to the players' terminals.  Eg:

	PAUSE TEMPORARY STOP

will pause the game until an & (shift 7) is entered on the main keyboard.  The message TEMPORARY STOP 
will appear on the main display and on all terminals.

PEOPLE shipid

GM's equivalent of the player command REPORT PEOPLE.  Performs the command for the shipid.

PICT shipid  new_picture

Allows the alteration of the various ship shapes.  If you want a Monarch that looks like a Starbase, you can 
have a Monarch that looks like a starbase.  Picture numbers vary from 0 to 69 - try them!

QPRINT [filename]

QPRINT will print a quick listing of the scenario to the printer or to a file.  This is useful when you are 
designing or modifying scenarios.

REP0 shipid

This is the Gm's version of the 'REPORT ENGINES' command.

REP1 shipid

Lists speed, heading and mission details.  The report is shown below:

req_speed      80  act_speed 80
req_heading    3068  act_heading 3068
mission        ESCORT  current_move 2
mission_ship   M1   combat_ship NONE
combat_curr_angle 1800  decel_dist 1066 lower 0
mission_speed 80   tactics 3 
xpos  501396  ypos  195542
change_mind -1 mission rotate 0 
posx1,y1  1 1   Captain 3
posx2,y2  1 1  mission_timer 0
Mission_dist 500 mission_angle 450 mission_rotate 0

Some of the more useful information on this report is requested and actual heading and requested and actual 
speed.

This screen was used for testing, so some of the information shown may not be useful for normal play.  It 
will be tidied up in future versions of Bridge Crew.

REP2 shipid 

Lists crew efficiencies and reactions to energy crisis.  The report is shown below:

ID  efficiency  energy_crisis  strategy
  HELM   80         7            15
    DC   80         5             1
  BEAM   80         3             0
  MISS   80         3             0
 COMMS   80         5             0
   ENG   80         5             0
   SEC   80         5             1
SHIELD   80         4             0
   SCI   80         3             0
 STRAT   80         5             0
  COMP   80         5             1

This report will be tidied up in future versions of Bridge Crew.  The lower the energy crisis amount the lower 
the priority that the item has for energy distribution.  The strategy column defines the non-player crew 
strategy for that function.  Since there is no way to change these without the Scenario Designer's Kit, their 
values are described in the Scenario Designer's Kit's documentation

REP3 shipid

Ship's missile report.  It is the same as the Player Command REPORT MISSILE, but can be performed for any 
shipid. 

Id   Prox Ammo  Function Perform Dam   Sp End  aim Status  Lock
 PT1   0    30      MIS1 100%    300   120 10    0 Empty   none
 PT2   0    30      MIS2 100%    300   120 10    0 Empty   none
End report

REP4 shipid

Ship's beam report.  It is the same as the Player Command REPORT BEAM, but can be performed for any 
shipid. 

Id  Arc Firing-Arc Function Perform Dam   Aim Status  Lock
 LP   0 2699-1          PH1 100%    300    0   Empty  NONE
 FP   0 3149-451        PH2 100%    300    0   Empty  NONE
 RP   0 900-0           PH3 100%    300    0   Empty  NONE
End report

REP5 shipid

Ship's echo.  Reports the amount of reflectivity for that sensor type.

EM          62
WS          66
SR          79
SE          61
PS          60
ZZ          64

This is a representative figure not a percentage, generally the lower the figure the harder the ship is to see.  
See the section on "How Sensors Work."

REP6 shipid

Reports sensors on another ship.  Same as the player command REPORT SENSORS, but can be performed 
for any shipid.

  Id State Sensitiv Cost Range Speed Perform Function
0 SR ON       40    300   9500 0-100   100%  SENS0
1 SE ON       40    100   6000 0-180   100%  SENS1
2 EM ON       40     20   3500 0-9     100%  SENS2
REP7 shipid

Same as the player command REPORT TRANSPORTERS, but can be performed for any shipid.

REP8 shipid

This lists the queries, chats, hellos and other set messages in the non player ships. They can be changed 
using the TEXT command.  Note that query is updated with each new mission from the ORDER and 
MISSION commands.

REP9 shipid

This is the gm's version of the 'REPORT SHIP' command; it is the same as the players' report ship command, 
but works for any ship.

R10 shipid

This is the GM's version of the REPORT DC command.  It can be run for any ship.

R11 shipid

Reports on the status of the cloaking device(s) installed on shipid.

RESTORE file_name

Restarts the game from a previously saved file.

RMOVE shipid  location  dist

Randomly move shipid to location at the given distance in TSUs.

RMOVE F1 /X3 500

will place F1 at exactly 500 TSU from the actual location of X3, at a random heading.

RMOVE F1 X3 500

will place F1 at exactly 500 TSU from the last known location of X3, at a random heading.

SAVE file_name

Saves the game to a file for later reloading.
This has been disabled in the shareware version sw1.12.

SCENARIO [number]

Scenario is used to change the scenario number for the ship's computer functions.  If number is omitted, 
then the current scenario number is displayed.  Number must be between 0 and 19.

Note:  The information in the ship's computer is part of the scenario file.  If you wish to modify the 
information in the ship's computer, you will need a copy of the Scenarion Designer.

There is little of value in the ships computer in the shareware version sw1.12.

SCRIPT file name

Where file_name is the name of the script file to be used.  File_name will always end with '.scr'

A script file is made up of a series of GM commands which the GM would ordinarily have to type in himself 
or herself.  Any command usable by the GM can be put into a script file.   It can be quite useful for the 
programming of your personal macros as it can be used in any scenario.  This command starts processing a 
GM script file.  Script files may be written with any text editor (or word processor that produces DOS text file 
format).  They contain lists of commands that will be executed in sequence.  Errors will be ignored so the GM 
must watch for them.  (Script files are often provided with the scenarios for special events.)

To stop a script file that you have started inadvertently, press % on the main computer console (not the 
GM's terminal).

SECURITY  Port_number

Each player (except the captain) has a terminal (or PC running a terminal emulator) which is connected to a 
port on the computer running Bridge Crew.  The ports have ids 0, 1, 2, 3, etc.

The GM assigns security to one of the players using this command.  E.g.

	SECURITY 0

will give the SECURITY function to the player whose terminal is plugged into port 0 on the main computer.
Note that the easiest way to find the port number is to use the WHO command.
SETF [ON|OFF|PRESERVE]

When entered with no parameters, this command displays the current value of the fake helm hit

This command displays or sets fake helm hit.  If it is set to ON, the next hit will be directed to Helm with 
exactly one casualty.  If it is set to OFF, hits on the players' ship will be allocated randomly, as normal.  If it is 
set to PRESERVE, future hits on the helm of the players' ship will be prevented.

If this command is used too often, players may become suspicious.  We recommend that it only be used 
when role-playing requires its use.

SETP [HELM|OVERHEAT|INTEGRITY| AUTO|DIST] [ON|OFF]

When entered with no parameters, this command displays the current values of the universe parameters.

This command displays or changes the setting of the following GM universe paramaters:

	HELM HIT
	OVERHEATING
	INTEGRITY
	AUTO VIEW
	DIST SPEED

For a full description see the section headed "Customising Your Universe".

Eg	SETP OVERHEATING ON

	sets the universe parameter OVERHEATING to on which allows engines to overheat and get damaged.

SETV [HEAT|CLOAK|MOVE] [new_value]

When entered with no paramaeters, this command displays the current value of the universe parameters.

This command displays or changes the setting of the following GM universe paramaters:

	HEAT DAMAGE
	CLOAK RAND
	MOVE ENERGY

For a full description see the section headed "Customising Your Universe".

E.g	SETV HEAT 50 

	sets the universe parameter HEAT DAMAGE to a value of 50

SIDE shipid FIP|NEU|HOS|DSF|MER|FRE

Changes the side of shipid 

	FIP	makes it part of the Federation of Independent Planets and gives it admiral 0.
	NEU	makes it a neutral vessel answerable to nobody
	HOS	makes it hostile to the FIP
	DSF	makes it part of The Deep Space Fleet (admiral 1)
	MERchant makes it part of the FIP merchant marine (admiral 2)
	FRE	makes the ship a free trader, but is in all ways similar to FIP.

If SIDE is entered without parameters, then it will display the current side of the ship.

Unfortunately in version sw1.12 these are 'hard coded' and FIP must represent the Humans Trade fleet and 
DSF must represent the Human military fleet.

SIGINT shipid

Each ship has a flag attached to it which controls the probability of the ship giving its position away via an 
xupdate or iupdate-like process.  This is a single integer between 3 and 32000; for most ships it starts at 30, 
which will randomly update the position, with an update occuring, on average every ten minutes.

The probability of an update in a given turn can be found by the formula:

	PROBABILITY = 1/(SIGINT*10)

	Eg if sigint = 60
	probability(0.0017) = 1/(60*10)

This means that (on average) the ship will have a 0.17% chance of disclosing its position every two seconds 
(this is equally true of player and non-player ships).

To convert this to the average delay until a position update, apply the following formula:

	TURNS = SIGINT*10
	MINUTES = SIGINT/3

NOTE: The default period of ten minutes is quite long; the result of this is that non-player ships will tend to 
aim towards the spot where the ship was 5 minutes ago.

TECHNICAL NOTE :- The probability of update follows a geometric distribution with one event every 10 
turns.  For example, if SIGINT = 60, an approximate 95% confidence interval for updates is 1 to 1799 turns, ie. 
less than 60 minutes.  This means that for SIGINT = 60 there is a 95% probability that an update will occur in 
within the period of 60 minutes.

SPARE

This command will display the spare time available to the CPU (Central Processing Unit) of the computer on 
which you are running Bridge Crew.  This command is only really needed by scenario/game designers to tell 
them when the number of active components of a scenario have exceeded the capicity of the CPU to deal 
with them in the course of a two second turn.  
The SPARE command can be reset as follows:
	>SPARE RESET

SPRINT [file_id]

Print a summary listing of all ships in the Scenario.  The file_id is the name of a DOS file that the ship details 
will be sent to instead of to the line printer.  Note:  file_id is optional.

STATUS shipid

Equivalent of the player command REPORT FUNCTIONS for a given shipid; it lists damage status.

TEXT HELLO|QUERY|ID|NEWS|DESC| CLASS shipid new_text

This command allows you to alter the set message texts for the various ships. The text can be up to sixty 
characters in length, except for Class, which can be 30 characters in length.

UNFREEZE

Allows movement.  Undoes the FREEZE.

USUS ship_id CONFIRM

This switches the player ship to the ship_id ship.  Thus if you wanted the players to play the Xingon cruiser 
X1 in a particular scenario, type USUS X1 CONFIRM.

This command is designed to be used by the GM while setting up a new scenario.  It is not designed to be 
used while the players are playing.

XDELETE message_number

Deletes a message from the GM's Queue.  Similar to the player command DELETE, but works on the GM's 
queue rather than the player's queue.

XDOWN message_number

Message_number is betwwen 0 and 9.

XDOWN removes one of the ten line messages from the players' access.  This command is the opposite of 
DOWNLOAD (DOWN). 

Removes message access from the players.

This command has no effect in version v1.12 and sw1.12 this is a bug and will be fixed in v1.13 (registed 
version)

XFUNCTION shipid  function_id

Just like the player command FUNCTION but for non player ships.

Note:  the function_id cannot be abbreviated and may be determined by using the "status" command.

XGET message_number

Using this command you can access and read any of the computer messages that have been loaded into the 
scenario.

See the section on ten-line messages.

XHELP command

This is identical to the player HELP command except that it will only work for GM commands.

XMEM

The amount of available (unused) memory is listed by the XMEM command.

XMIT from  to  message

Where from is the shipid from which the message originates; to is the shipid your message has to go to; and 
message is the message to be transmitted; normally of one line.  E.g.

	XMIT T1 F0 We are on route to trade at Sol.

will give the player ship a message from the trading vessel "T1".  Be warned that any backward arrows in the 
message will also be transmitted and may not behave correctly on a different terminal, so be sure to use the 
Back Space key for correction, not the arrow keys.

Note that the message is limited to 69 characters in length.

This is the GM's version of the SEND command.  See the Player manual for more details.



XPRINT shipid  [file_id]

Print the shipid on the line printer or send it to a file.  The file_id is the name of a DOS file that the ship 
details will be sent to instead of to the line printer.  Note:  file_id is optional.

XQUEUE

Lists the communications messages that have been queued to the GM.  This command is similar to the 
player command QUEUE, but reads from the GM's queue, rather than from the player's queue.

XREAD message_number

Reads a communications message from the GM's Queue.  Similar to the player command READ but works on 
the GM's queue rather than the player's queue.

XRECON shipid

Just like a RECON from another ship.

This command is useful when you want to see the effects of cloaking and stealth technologies.
XRELOAD shipid number

GM's command to reload all missiles on a ship.  You cannot load more than the maximum allowed in the 
magazine.

It can also be used to remove missiles - simply set number to 0.

XSEARCH key1 [key2] [key3]

GM's equivalent of the player command SEARCH.  Lists the first ten entries in the players' ship's computer 
with key1, key2 or key3.  Key2 and key3 are optional.

XTHINGS number shipid

Similar to a THINGS for an enemy ship.  Number should be the start ship number.  Try 0  10  20  30 etc.

This command is useful because it lists where the ship thinks that other ships are to be found.  This can 
explain strange behaviour of non-player ships.  Use XUPDATE to update the current locations on this list.

A sample report is shown below:

Ship head   dist vis  pos
 F0 2700     896 Vis  500500. 195500
 M1 3004    1528 Vis  500077. 196314
 F1    0       1 Vis  501396. 195542
 X1  119   10177 Inv  503500. 205500
 X2  191    9480 Inv  504500. 204500
 X3  173   10430 Inv  504500. 205500

XTRANSPORT CREW num_crew TO|FROM shipid  ship_function  gm_ship

Enables the GM to remotely transport non-player crew and passengers.  The command:
	XTRANSPORT CREW 5 TO T1 HELM X1
could be used to move a repair crew from a Xingon ship to the helm of a stranded trader.  It is sometimes 
easier to type in two ADJUST commands.

XTRANSPORT PASSENGERS num_passengers TO|FROM shipid  ship_function  
gm_ship

Enables the GM to remotely transport passengers.  As above, but taking the numbers from the passengers 
instead of crew numbers. To modify crew or passengers without restrictions, use the ADJUST command.

XUNCLOAK shipid

Lowers cloaking on shipid.  The effect of this command is temporary; non-player crews will try to put 
cloaking back up at the first possible oportunity.  See the section on 'CLOAKING' for details of the play 
mechanics of cloaking.  Note that this command will have no effect on ships that have a 'stealth' technology 
rather than cloak technology (such as the OWL class).

XUPDATE shipid

Updates all ships with the current location of the shipid.  Just as the players have a list of known ships, so 
do the non-players.  The function of this command is to inform the neutral and hostile non-player ships of 
the last known location of a player ship.  The command can also be used to update player-friendly ships.

Captaincy styles and tactics

Each non player ship has a specific captaincy style, the main effect of which is in combat.  Basically a given 
captaincy style has a preferred attack angle and distance when reacting to the ATTACK, ESCORT, WAIT, 
and PATROL commands.  The ship will enter combat and try to manoeuvre into the position dictated by the 
captaincy style.

Two of the captaincy styles are variable and the attack angle changes after a certain number of turns.  This 
changing tactic is useful for swooping attacks and suits certain classes of ships.  More captaincy styles will 
be available in future releases.

Some captains have a tendency to rotate around the target ship, either clockwise or anti clockwise, at 
varying speeds.

Thirty captain types are supplied with Bridge Crew.  Each captain has his or her own style, which affects 
how the non-player ships under his or her command manoeuvre.  The captaincy style can be determined by 
using the GM's command REP1.  The table over-leaf shows the favoured style.  The headings are explained 
as follows:

Distance	Favoured combat distance

Angle	Favoured attack angle

Rotate	Whether the ship will tend to rotate, and if so, in which direction.

Speed	Preferred combat speed.  Most ships have a maximum speed of 80, so all captains in those ships 
will travel at the same speed.  There are some ships, however that can travel faster.  If a captain 
with a speed of 80 is assigned to a ship with a greater maximum speed, he or she will then tend to 
travel more slowly than a captain with a speed of 85.



Captain
Distance
Angle
Rotate
Speed

0
400
1800
No
85

1
500
1800
Clockwise
80

2
500
1800
Anticlockwise
85

3
200
1800
No
85

4
600
2500
No
80

5
400
900
No
85

6
700
2700
No
80

7
1500
1800
No
85

8
1000
1800
No
85

9
1500
1800
No
85

10
1000
1800
Clockwise
85

11
4500
0
Clockwise
85

12
4500
0
No
85

13
2000
1800
Clockwise
85

14
2000
0
Clockwise
85

15
600
900
No
50

16
500
0
No
85

17
500
1800
No
85

18
1000
900
No
85

19
1000
2700
No
85

20
6000
1800
Very Slow Clockwise
85

21
2000
1
No
0

22
2000
1
No
120

23
2000
2700
No
120

24
2000
1800
No
120

25
2000
900
No
120

26
1000
1
No
0

27
1200
1
Fast Clockwise
90

28
1500
1
Slow Clockwise
70

29
1450
1
No
100


Notes on Captain Types

Ship No	Description
0	Default captain for most ships.
8	Tends to slow to speed 50 in combat.
16 & 17	Captains 16 and 17 are effectively the same - the captain style changes every 32 turns, providing 
the ability for the ship to swoop up and down.
18 & 19	Captains 18 and 19 are the same - the captain style changes every 39 turns, providing the ability 
for the ship to swoop from left to right.
20	Optimised for shadowing.
21	A speed 0 captain, suitable for FIP ships facing C7 class Xingon vessels.
22 & 23	Suitable for Rheman ships with plasma bolts.
26	This captain is less easily distracted.
28	Suitable for DDMs.
29	Suitable for double ended ships.
Hints and Tips

Use the SIDE command to make yourself neutral and run a few combats just to see how non-player ships 
react with different captaincy styles.

As the GM, several things can help you to control a combat:

1.	Vary the captaincy styles.  This stops non-player ships from lining up and getting blasted by one 
weapon (NB, missile weapons affect all ships witin the blast distance in the direction that the weapon is 
aiming.)

2.	Use captaincy styles that use a greater 'favoured combat distance'.  Ships under the command of such a 
captain will tend to hit less often with missiles and less effectively with beams; this effectively slows 
the combat.

3.	Use swooping captaincy styles for ships with missile systems that have low manoeuvrability.  Eg 
captains 16 and 18.

4.	Use the 'FLEET' or 'TRADE' commands to break up non player ships locked in to chasing ships of equal 
or slightly greater speed.  Eg MISS X1 TRADE XING XING

5.	Use the 'DAMAGE' command to reduce the capacity of non-player ships to react sensibly, shoot, etc.

6.	Use the DAMAGE command to restore non player ships in situations where it would add to the 
excitement.

7.	Make use of 'SHADOW' where it can be used to lure the players' ships away from the ships that they 
are escorting.  Players can then be court-martialed after the action for 'leaving the transports 
unprotected'.

8.	If you are clever, you can load a 'DEACTIVATE' command, (to take one of the players' opponent's ships 
out of combat), but not press enter until a missile and/or beam weapon hits nearby.  This makes the 
players believe they have killed the ship concerned and is useful when you have overmatched the 
players.
Limits of the Game

Unless you have the scenario designer's kit you cannot:

*	Add or Delete ships from a scenario.  (De-activated ships are still in the scenario.)
*	Design new ships.
*	Change the star background.
*	Re-configure any ship's performance other than by damaging it or removing crew.
*	Change crew strategy or performance.

	Only 30 ships can be shown on 'recon' at any time.  GMs must avoid situations where more than 30 
ships are visible at one time.

	GMs should avoid setting scenarios outside the square defined by the points (1,1) and (999999,999999).  
The point (0,0) does not exist in the universe as we know it, nor does any other point outside the 
square.  No testing has been performed outside this area.  Even if the game system is found to work 
outside these points, future releases may not.  It is hoped, in the future, to increase the size of this 
square, but for the moment please stay within it.

This is a game:

	It is important to note that this game system is for gamers who enjoy role-playing or combat simulation.  
If you really want a realistic simulation, most of the time would be spent travelling between star 
systems.  The strategic mode robs players of information they would otherwise have in a 'Highly Real' 
Game System.  BRIDGE CREW has been written to be fun as a game and does not have its roots in any 
Reality, especially the actual laws of physics.
How Sensors Work

There are six types of sensors in the game.  The FIP universe uses 5 of these, as EM, SE, WS, PS,and SR.  
The sixth is left unused for creative GMing by those GMs who have the Scenario Designers Kit.

The shareware release ships do not use all 5 sensor types and sensors have different characteristics. 

Each starship has a basic reflective strength in each of the 6 types.  To this is added a random factor (based 
on the reality that radar signatures on consecutive passes are rarely exactly the same due to atmospheric 
conditions and the way in which the aircraft is facing).  This base reflective strength is shown by the 
"REPORT CROSSSECTION" report.

Each starship sensor has a basic sensitivity in one specific type and a speed range which applies to the 
speed of objects it can detect.  If the object's reflective strength plus the random factor is greater than the 
sensitivity of the sensor and the object is traveling within the sensor's speed range, then it will be visible to 
that sensor. 

Cloaking devices reduce the base reflective strength of one specific type while the device is turned on.  (The 
only cloaking technologies I can actually think of were the de-gaussing coils on allied transports during 
World War II, the function of which was to prevent the triggering of magnetic mines)). 
Chameleon/camouflage techniques are, in a way, cloaking devices.

Stealth techniques reduce the base reflective strength of the starship all the times and cost no energy (this 
is similar to modern aircraft technology).

Eg

Say a starship has a base SE reflectivity of 60.
The viewing starship has a SE sensor with a sensetivity of 30
Because reflectivity is greater than sensitivity the ship will always be visible; this is because the 
maximum random addition is 20 and (60+20) is greater than 30.

Say a starship has a base SE reflectivity of 10.
The viewing starship has a SE sensor with a sensitivity of 40
Because reflectivity is less than sensetivity the ship will never be visible because the maximum random 
addition is 20, and (10+20) is less than 40

Say a starship has a base SE reflectivity of 15.
The viewing starship has a SE sensor with a sensetivity of 30
Because reflectivity is within 20 less than sensitivity the ship, will sometimes be visible.  This is 
because the maximum random addition is 20 and (15+20) is greater than 30.  However, the minimum 
addition is 1 and (15+1) is less than 30.  This ship will tend to blink on and off - this is the type of 
situation used in the Rheman OWL class ship in the FIP universe.

 GURPS is a registered trademark of Steve Jackson Games Incorporated.
 Traveller is a registered trademark of Game Designers' Workshop.


* Copyright Mithril Software Pty Ltd 1993	iii

* Copyright Mithril Software Pty Ltd 1993	4


