1










			BRIDGE CREW GM GAME MANUAL



			BRIDGE CREW version sw1.12d








Bridge Crew is a trademark of Mithril Software.

This product is copyright Mithril Software 1994, 1995 All rights reserved.































 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, Ian Windorf.

 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.




Copyright Mithril Software                           Page 1
 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.

Specific instructions on how to wire and setup BRIDGE CREW are included 
in the files GETSTART.TXT and ONESTART.TXT.  

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 (Bcrewset.bat)

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:

>C:
>CD \BCREW
>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.










Copyright Mithril Software                           Page 2

The main screen of the setup BCREWSET 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.
--------------------------------------------------------------

A display of the Game details screen is shown below:
--------------------------------------------------------------
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=No terminal (or mouse)
  COM2 (Port 1)  1      COM8  (Port 7)    0    1=Dumb Terminal Present
  COM3 (Port 2)  1      COM9  (Port 8)    0    2=PC running BCTERM 
  COM4 (Port 3)  1      COM10 (Port 9)    0      With or without
  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











Copyright Mithril Software                           Page 3

 Hardware Details (using COM1 and COM2)

The following is a setup for just 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. 






















Copyright Mithril Software                           Page 4

The following setup is for a uninteligent multiport card with 8 ports
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).






















Copyright Mithril Software                           Page 5
 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).





Copyright Mithril Software                           Page 6

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.
However David Readman has sugested you contact him on the internet 
on JAGUAR@WERPLE.MIRA.NET.AU 


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

























Copyright Mithril Software                           Page 7
 Getting Started

To start your first scenario, set up the system as described in 
GETSTART.TXT or ONESTART.TXT

Alternativly run the setup BCREWSET 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.



Copyright Mithril Software                           Page 8


 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.











Copyright Mithril Software                           Page 9

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 
DSF (side DSF). However if a CONDITION RED is declared, Ships under the 
command of Admiral FIP (SIDE MER and SIDE FIP) will also obey the ORDER
command.


























Copyright Mithril Software                           Page 10

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.






























Copyright Mithril Software                           Page 11
 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.

1 Your job as the GM involves the following steps:
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






Copyright Mithril Software                           Page 12

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 
		matter 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).



Copyright Mithril Software                           Page 13

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.






Copyright Mithril Software                           Page 14

 Customising Your Universe

Because 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:
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.















Copyright Mithril Software                           Page 15

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.













Copyright Mithril Software                           Page 16

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)






Copyright Mithril Software                           Page 17




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.






























Copyright Mithril Software                           Page 18
 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.






























Copyright Mithril Software                           Page 19
 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.


Copyright Mithril Software                           Page 20
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.

Copyright Mithril Software                           Page 21
 The ORDER 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.


Copyright Mithril Software                           Page 22
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.

Copyright Mithril Software                           Page 23

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.

































Copyright Mithril Software                           Page 24
 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.  





Copyright Mithril Software                           Page 25
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









Copyright Mithril Software                           Page 26
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.







Copyright Mithril Software                           Page 27
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.







Copyright Mithril Software                           Page 28
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.












Copyright Mithril Software                           Page 29
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

















Copyright Mithril Software                           Page 30
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.


Copyright Mithril Software                           Page 31
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







Copyright Mithril Software                           Page 32
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.






Copyright Mithril Software                           Page 33
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.













Copyright Mithril Software                           Page 34
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.











Copyright Mithril Software                           Page 35
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



Copyright Mithril Software                           Page 36
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.





































Copyright Mithril Software                           Page 37
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.



Copyright Mithril Software                           Page 38
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.


Copyright Mithril Software                           Page 39
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.












Copyright Mithril Software                           Page 40
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.






Copyright Mithril Software                           Page 41
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.








































Copyright Mithril Software                           Page 42
 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       270  No                  80
7       150      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

Copyright Mithril Software                           Page 43
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.

























Copyright Mithril Software                           Page 44
 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.















Copyright Mithril Software                           Page 45
 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.
























Copyright Mithril Software                           Page 46
 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).

 Examples

Say a starship has a base SE reflectivity of 60.

The viewing starship has a SE sensor with a sensitivity 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 

Copyright Mithril Software                           Page 47
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.


 Footnotes

GURPS, and Traveller are trademarks  of  Steve Jackson Games Incorporated.
and Game Designers' Workshop.

There are probably other trademarks owned by other companies in this document
their presence is not infringe their owners rights in any way.

Copyright Mithril Software Pty Ltd 1993,1994,1995 All rights reserved       







































Copyright Mithril Software                           Page 48

				CONTENTS

   Acknowledgements..........................................1
   Introduction..............................................1
   SOFTWARE INSTALLATION.....................................2
   Setting up the software (Bcrewset.bat)....................2
    Hardware Details (using COM1 and COM2)..................4
   How Bridge crew handles multi port cards..................6
   Getting Started...........................................8
   Notes about How the Game Plays............................9
   Game Mastering............................................12
   Characters' Tour of Duty:.................................13
   Running Campaigns.........................................14
   Customising Your Universe.................................15
   Role-play systems.........................................19
   Player Commands...........................................20
    The ORDER command.......................................22
   GM Commands...............................................25
   Captaincy styles and tactics..............................43
   Hints and Tips............................................45
   Limits of the Game........................................46
   How Sensors Work..........................................47
    Examples................................................47
    Footnotes...............................................48

