ftp.ee.pdx.edu/2014.02.ftp.ee.pdx.edu.tar/ftp.ee.pdx.edu/pub/frp/Archives/658

Internet Message Format | 1994-10-04 | 33KB

Path: usenet.ee.pdx.edu!cs.uoregon.edu!sisters.cs.uoregon.edu!sgiblab!swrinde!news.dell.com!tadpole.com!uunet!not-for-mail
From: [e-mail] (james vassilakos)
Newsgroups: rec.games.frp.archives
Subject: REFERENCE: ST-PBeM: Insert #2 (Tech Notes)
Followup-To: rec.games.frp.misc
Date: 30 Sep 1994 14:59:24 -0400
Organization: UUNET Technologies Inc, Falls Church, VA, USA
Lines: 549
Sender: [e-mail]
Approved: [e-mail]
Message-ID: <36hn6c$[e-mail]>
NNTP-Posting-Host: rodan.uu.net


*******************************************************************************
                           Star Trek: Play by E-Mail
                              The Forbidden Years
                               Campaign Write-up
===============================================================================
                                   Insert #2
                                Technical Notes
===============================================================================
              Copyright 1994 Jim Vassilakos / All Rights Reserved
*******************************************************************************

Like most campaigns I've run, the players in the ST-PBeM argued about anything
they could get their paws on. However, since the game genre was science fiction
in general, and Star Trek in particular, most of these "discussions" tended to
boil down to the nitty-gritty technical details. Luckily, a number of sources
already existed upon which I could base my rulings as GM.

FASA's RPG was one of them. However, to my increasing dismay, I found that the
FASA rules tended to skip over a good deal of technical detail. The game
designers no doubt realized that the scientific intricacies often quoted by
Data, Scotty, Geordi, and Spock usually amounted to little more than techno-
babble. In short, the goal of make-sense and consistency was downplayed in
favor of the greater goal... of telling a story.

While this may work great for a script, where characters conveniently forget to
use that interesting solution proposed by Wesley only two weeks ago, it doesn't
work so well in an RPG where the players refuse to make such oversights. In an
RPG, players are encouraged to come up with inventive solutions to problems,
and doomed in the GM who pops the same quiz twice.

Luckily, my source material was not limited to FASA alone. Strangely enough,
two of the artists working for Paramount, Sternbach and Okuda, wrote a
technical manual which attempted to codify the techno-babble which had been
gushing forth during the 2nd Generation series. It was a more valiant attempt
than that made by Franz Joseph some fifteen years earlier. However, between the
original series and the 2nd Generation, there had emerged such a morass of
conflicting material, such a level of confusion, that the manual put out by
Paramount didn't quite fill in all the holes. And it couldn't have without both
cutting off previous stories from the technical "realities" and cutting off
numerous future possibilities.

Hence, in many areas, they simply erected a virtual curtain of seemingly useful
trivia. And in a way, it was useful. It provided inspiration, both for me as a
GM in handing down various decision, and for me as a writer, since I like to
toss in techno-babble just as much as the next person. Only in this instance,
at least the techno-babble had some foundation.

What follows are the technical notes I kept during the exercise of the game,
just so that I'd remember what the previous decisions had been. For those of
you who plan to GM a campaign set in the Star Trek genre, hopefully these notes
will be of some interest to you. But beware that I deviated from that which is
"generally accepted" to a *large degree* in some areas, usually for the purpose
of increasing the make-sense of the game. Certainly, none of these rulings
should be considered as a final word on the topic, and like any rude GM, I
reserve the right to flip-flop on these decisions whenever the mood suits me.
Perhaps it is useful to illustrate the message with a quote. In the words of
Sternbach and Okuda, "Star Trek is about people; the technology is merely part
of their environment." So it is, I hope, with this PBeM.


Transporters
-------------------------------------------------------------------------------

Back in Turn #7, I gave some technical notes for Transporters. Those are
expanded as follows:

Transporters are devices that can "beam" a person from one location to
another in a matter of seconds. There are three main varieties: personal
transporters, cargo transporters, and emergency transporters.

                                                Excalibur   Phobos
Type       Payload     Direction   Resolution   Cycle Time  Cycle Time
----------------------------------------------------------------------
Personnel  5 people    two-way     quantum      6 seconds   10 seconds
Emergency  22 people   one-way     quantum      6 seconds   10 seconds
Cargo      25000 kg    two-way     molecular    12 seconds  20 seconds

Cycle Time: Total time needed for ship-to-surface transport. Other types of
   transport exist, but this is a good benchmark.

Direction: Emergency transporters are special in the sense that they can only
   beam from ship-to-somewhere, while the other types of transporters can
   also beam from somewhere-to-ship.

Resolution: The difference between quantum and molecular resolution is that
   you need quantum resolution to successfully beam life-forms from one
   place to another.


Stats for the Excalibur's Personnel Transporters:

   Range: 40,000 km.
   T2P Cycle Time: 6 seconds. The minimum time it takes for
      beaming a person from ship to remote destination.
   T-Phase: 3.4 seconds.  The actual time spent in transport.
   Reset Time: 120 seconds.
   Pattern Buffer Integrity: 300 seconds.


Four modes of transport:

   Example: Tee-to-point / Beaming down
            From transporter room to remote destination.
      Sec 0.0 - 0.7: Lock on and scan person.
      Sec 0.7 - 1.2: Dematerialization of person into matter stream.
      Sec 1.2 - 1.5: Transmission of matter stream from transporter
                     pad to pattern buffer.
      Sec 1.5 - 1.6: Pattern integrity verifications. Bio-filter option.
      Sec 1.6 - 5.0: Transmit matter stream from pattern buffer through
                     emitter array down to planetary surface. (T-Phase)
      Sec 5.0 - 6.0: Rematerialization.
      Sec 6.0:       Release Annular Confinement Lock.

   Example: Point-to-tee / Beaming up
            From remote site to transporter room.
      Sec 0.0 - 0.1: Lock on person.
      Sec 0.1 - 0.8: Scan person.
      Sec 0.8 - 1.8: Dematerialization of person into matter stream.
      Sec 1.8 - 5.2: Transmit matter stream from initial location through
                     reception array and up to the pattern buffer. (T-Phase)
      Sec 5.2 - 5.3: Pattern integrity verifications. Bio-filter option.
      Sec 5.3 - 5.6: Transmit stream from pattern buffer to transporter pad.
      Sec 5.6 - 6.1: Rematerialization.
      Sec 6.1:       Release Annular Confinement Lock.

   Example: Point-to-point / Lift and Drop
            From one remote site to another.
      Sec 0.0 - 0.1: Lock on person.
      Sec 0.1 - 0.8: Scan person.
      Sec 0.8 - 1.8: Dematerialization of person into matter stream.
      Sec 1.8 - 5.2: Transmit matter stream from initial location through
                     reception array and up to the pattern buffer #1. (T-Phase)
      Sec 5.2 - 5.3: Pattern integrity verifications. Bio-filter option.
      Sec 5.3 - 5.4: Transmit stream from buffer #1 to buffer #2.
      Sec 5.4 - 5.5: More pattern integrity verifications. Bio-filter option.
      Sec 5.5 - 8.9: Transmit matter stream from pattern buffer through
                     emitter array down to destination. (T-Phase)
      Sec 8.9 - 9.9: Rematerialization.
      Sec 9.9:       Release Annular Confinement Lock.

   Example: Tee-to-tee / Shared Beaming
            From one transporter room to another transporter.
            Assumes shared T-Phase of 1.7 seconds (half normal T-Phase).
      Sec 0.0 - 0.7: Lock on and scan person.
      Sec 0.7 - 1.2: Dematerialization of person into matter stream.
      Sec 1.2 - 1.5: Transmission of matter stream from transporter
                     pad to pattern buffer.
      Sec 1.5 - 1.6: Pattern integrity verifications. Bio-filter option.
      Sec 1.6 - 3.3: Transmit matter stream from pattern buffer through
                     emitter array and through a transporter reception
                     array clear to another pattern buffer. (Shared T-Phase)
      Sec 3.3 - 3.4: More pattern integrity verifications. Bio-filter option.
      Sec 3.4 - 3.7: Transmit stream from pattern buffer to transporter pad.
      Sec 3.7 - 4.2: Rematerialization.
      Sec 4.2:       Release Annular Confinement Lock.

   Note that point-to-point transport requires the use of two separate pattern
      buffers as intermediate stations. Hence, you are in effect being beamed
      twice. There is more energy consumption, obviously, but even more
      important is the cool-down/reset phase. And worse still are the safety
      considerations. Your chances of being scrambled (though still very small)
      are essentially doubled via this method of transport.

   Note that beaming from one transporter to another also requires the use of
      two separate pattern buffers, but this mode of transport is preferred
      when feasible because of the outstanding degree of safety offered.

   Cool-down/Reset Phase: 120 seconds.
      Each pattern buffer must remain idle for two minutes after transport.
      Certain complex materials are broken-down during this cool-down phase,
      and a great deal of energy and fabrication-time must be spent putting
      them back into a usable form. Hence, there is the direct energy/time
      consumption of the transporting process itself, and then there is the
      indirect energy/time consumption of fabricating the cool-down materials
      which this post-transport phase consumes.

The Patter Buffer: This holds the matter stream in a high resolution matrix.
      The "image" can be held for about 300 seconds (5 minutes) before serious
      degradation occurs. Images can be transferred to a back-up buffer at the
      150 second mark with no detectable degradation, hence extending the hold-
      period by 150 seconds. Images can also be rotated (actually, the image
      isn't rotated so much as the buffer pointers). Hence, the direction of
      facing upon rematerialization can be modified. A person can even be
      turned upside-down (or turned inside-out if you want to get particularly
      nasty). Also, images can be consulted while in the buffer to determine
      the general nature/species of the organism being transported. Of course,
      if a check is done on an unknown species, the computer may well spit out
      nonsense.

The Bio-filter: If there is reason to believe that people being beamed from one
      place to another are carrying harmful bacterial/viruses, the bio-filter
      may be used to screen *known* viruses out of the person's buffer image
      before the rematerialization process. However, this is not a good option
      to use for medical treatment, as if the disease is beyond the stage of
      initial inception, the bio-filter will overload and "crash" causing
      serious image-degradation. I.e., you'll end up scrambled. Generally
      speaking, scanning and screening out an unwelcome pest can take anywhere
      from a few seconds to over a minute. Hence, the ability to hold people
      in-buffer is very important.

The Re-Mat Hazard-Window: Each transport-example has a rematerialization phase.
      The tee-to-tee and the point-to-tee have no hazard window on this phase.
      If the beam is attacked, the matter stream is shunted straight back to
      the pattern buffer. However, in tee-to-point and point-to-point
      transport, there is a very definite hazard-window. It occurs right at the
      end of the rematerialization phase, when the option-to-cancel has
      transpired. For roughly half a second, the transportee is in serious
      danger. If anything ruptures the annular confinement beam (ACB), the
      transportee will be scrambled. As a minor consolation, any matter that
      enters the beam will also probably be scrambled.

The De-Mat Hazard-Window: At the beginning of any transport, it is possible
     that the annular confinement beam could be ruptured during the
     dematerialization phase in various ways. This is a hazard-window that you
     simply can't avoid. If the beam is ruptured, there's no pattern buffer to
     fall back to. However, because of the fact that the transporter scans an
     individual before dematerialization, it's possible for it to "fill in the
     gaps" if the beam is breached. This is particularly feasible the further
     along into dematerialization the individual has gone, so that a person who
     is, say, 75% dematerialized may actually make it through just fine.

The Annular Confinement Beam: The strength of the ACB varies from one
      transporter to another. In general, medium strength ACBs are of
      sufficient strength to push aside the pressure of standard atmospheres
      and deflect blunt thrown or flying object. Fast moving objects, however,
      such as bullets or device-driven projectiles will often penetrate these
      beams. Even particularly fast birds with strong beaks have been known to
      cause serious problems. Shooting lava will also be hazardous, but things
      such as minor standstorms can be deflected. Lighting or phaser/disruptor
      fire will generally always penetrate such beams. Aboard the Excalibur,
      the annular confinement beams are fairly strong, and in tests, they have
      deflected hurled weapons and even the force of fairly strong sandstorms.
      However, they won't deflect bullets or energy weapons. The annular
      confinement beam will appear before an individual re-materializes,
      pushing aside whatever is in the way (air, water, grass, insects, dust,
      sand, etc). If it bumps into something that it can't push, the process is
      aborted before re-materialization commences.

Limitations:
   (1) Shields: Transport cannot occur when deflector shields are up.
        There are a few exceptions to this restriction, however.
       (a) Flicker: Shields can be made to flicker at some ratio of on-to-off
            so that people can beam through the shields. At a 50% flicker rate,
            the T-phase would be twice as long, and the ship would only be
            half-protected by its shields.
       (b) Flicker-points: Many of the older starships have an imperfect power
            cycle on their shields. That is, they already have a flicker rate
            established which they can't get rid of. Usually, the rate is small
            (1-3%). And very often it is undetectable by scans. However, if you
            know how to find this flicker-point, you can use it to beam into
            another starship. Note that this is often dangerous. If you're
            wrong about the flicker-point, you can easily get yourself
            scrambled. Further, if the rate is only 2%, it will stretch your
            T-Phase by fifty-times. That is, it'll stretch the total cycle time
            from 6 seconds to around 173 seconds. This is one of those rare
            situations where it helps to have a really high-quality pattern
            buffer.
   (2) Warp: Transport cannot occur at warp velocities unless both the original
        location and the point-of-destination are travelling at identical warp
        velocities. Sudden deviation from such a state could result in the
        scrambled-eggs syndrome. :-(
   (3) Replication: Since the matter-stream is never in two places at once,
        replication is impossible. A *very* fast computer would be needed to
        scan, copy, and hold the information of a quantum resolution matrix
        during the short time that an image can be held in buffer. Further,
        every time an image is transferred from one buffer to another, there is
        a "shift" in the pattern, not a degradation, per se, but a subtle
        shift, so that even if you could line up a thousand buffers (hence
        holding the image in virtual stasis for up to 41 hours), you still
        wouldn't be able to replicate any but the simplest of organisms.
   (4) Antimatter: Because of the way in which the pattern buffer holds the
        matter stream, any antimatter which exists beside normal matter will be
        able to interact inside the buffer, hence probably destroying the ship.
        So even if a jar has antimatter contained within magnetic fields or
        whatever, beaming that jar is not a good idea. You can reverse the
        phase transition matrix and beam out the antimatter from the inside of
        the jar, hence transfering it to another jar, but beaming the whole jar
        at once is a recipe for destruction.


Forcefields
-------------------------------------------------------------------------------

Forcefields can have four separate characteristics:

1) Resistance against weapons (i.e. phasers, disruptors, et al).
2) Resistance against transporter carrier waves (T-suppression).
3) Resistance against communications (comm-suppression).
4) Resistance against sensor scans (sensor-suppression).

In general (that is, under normal conditions, using standard equipment and
standard operating procedures)...

1) Weapons resistance can be either uni-directional or bi-directional.

2) Transporter resistance is always bi-directional and is a standard feature of
   almost all forcefields. The scientific rationale is that the fields emit a
   large quantity of "static" which interferes with carrier waves. This static
   is emitted for several meters on even small forcefields. Hence, it is
   difficult to build in a "hole" through which carrier waves may pass.

3/4) Comm-suppression and sensor-suppression go hand in hand. In general, they
   are not standard features of a forcefield, but where you have one, you
   almost certainly have the other.


Warp
-------------------------------------------------------------------------------

Warp is re-defined to equal the number of light-years travelled in a day (a
very terra-centric measurement to be sure, but that makes it easier to
remember). Ship's have a certain range according to how much antimatter they're
carrying and how fast they're going. The faster you go, the more A/M you use
per unit of distance, and the function is exponential, so it's important to go
slow if the price of fuel is any consideration. Most engines are optimized in
the design-stage for performing most efficiently at a particular velocity,
called the "standard cruise". For the Phobos, that's warp 3.

Here's how the details work:

Each ship is accorded a "range" statistic expressed in years at warp 1. This is
how many light years the vessel can travel at warp 1 before running out of
antimatter. The range for the Phobos is 6 years. Hence, it can travel for 6
years at warp 1, covering a distance of some 2190 light years. But that's an
awful long time to be travelling in space, and most ship's tend to like to go
faster. However, every time you double your velocity, you divide your range by
8. To think of it another way, the Phobos has 2190 units of fuel, and uses one
every time it travels for a day at warp 1. If it travels at warp 2, it uses
2^3=8 per day. Warp 3? That's 3^3=27 per day (though it gets a 10% efficiency
discount for warp 3 since that is its "standard cruise").

Hence, Warp 1 = 365c   -->  2190 days
       Warp 2 = 730c   -->  274 days
       Warp 3 = 1095c  -->  90 days (standard cruise)
       Warp 4 = 1460c  -->  34 days
       Warp 5 = 1825c  -->  17.5 days
       Warp 6 = 2190c  -->  10.1 days (max cruise)
       Warp 7 = 2555c  -->  6.4 days
       Warp 8 = 2920c  -->  4.3 days (emergency speed)

Note that the engines are only designed to maintain emergency speed for twelve
hours (double that for warp 7), after which the ship must exit warp space and
run maintenance procedures for 24 hours. Running at anything above max-cruise
on a regular basis will result in excessive engine wear and extra time in
spacedock. Also note that engaging in battle tends to expend lots of
antimatter, which brings your range down accordingly.


Internal Sensors
-------------------------------------------------------------------------------

Even on the Excalibur, the computer does not normally keep track of where
people are, per se. It does keep track of where their locator badge is. All
guests on board are supposed to have a locator badge as well as the crew, which
is "supposed" to be worn continuously. On some ships where security is
particularly high, subdermal locator pins are injected into all individuals who
come on board. On the Excalibur, such a rule hasn't been made because internal
scanners and the computers are such that they immediately notice people who
have forgotten their badges. In such a case, a synthesized voice from the
nearest speaker usually reminds the person fairly quickly.

Note, however, that while the ship can "see" an unbadged personage, it usually
doesn't know who they are, and it usually won't attempt to find out unless
asked to. The programs on person identification are pretty weak, providing
statistics on race and other easily identifiable information. Work is currently
being done to enable the internal scanners and onboard computer to work
together as a sort of big-brother, able to identify individuals quickly, hence
doing away with the need for locator badges. However, such developments are
still a little ways off from general production.

The Excalibur's computer can "ping" badges to find their location. It doesn't
generally keep track of the location on a regular basis, however, unless
specifically asked to. Hence, there are no logs of where people have been. The
computer doesn't just generate this sort of information, assuming that it
*might* come in handy. It assumes that if you want the information, you'll
write a program to gather the information (which is exactly what Tsandzia did
at one point in the game). Note that while it does not take an excessive amount
of CPU to ping badges, it is hard to disguise such "network" activity,
particularly if a person is doing it on a regular basis, and sooner or later,
somebody in the sysadmin group will notice it and wonder what's going on. Pings
aren't illegal, of course, but continual pings might be considered an invasion
of privacy. After all, how would you feel if somebody was watching *your* every
move (and logging it). Only direct supervisors or the chief of security can get
away with that, and then, only with good reason. Call me a liberal commie
mutant cyborg, but that's my version of Star Fleet for ya. Of course, movements
into and out of specific key areas are logged as a general matter of security.
For instance, access to the bridge, auxiliary control, the armory, and other
key areas are closely watched.

Of course, there are many crews in the fleet which do not yet use locator
badges. On older ships like the Phobos, combination or key access is still
common. The Phobos runs almost exclusively on combination access. Each crew
member is assigned an access code (a combination, in effect) and a separate
Security Access Rating (SAR) for each and every lock on the ship (if there are
a thousand locks, they get a thousand separate SARs). Furthermore, some SARs
are time-sensitive, so that a crew member's priority for a particular lock may
increase during a particular duty shift, though this is a somewhat rare
situation.

The basic idea behind the SAR is that a crewmember with a rating of "x" can
lock the portal to any or all crewmembers with a rating below "x" while those
at and above "x" will remain unaffected. The top command officers and the
security chief commonly have the highest access rating on all locks (override
access), intermediate access ratings being given to "lock owners" (the resident
of a particular cabin, or the work area of a particular crew member, i.e. owner
access). Low access ratings are given to everyone else (general crew access).
Hence, a crewmember can lock the door of his quarters, but the Captain or
Security Chief can still get in. The authority of their rating "overrides" the
wishes of the lock owner.

On the Excalibur, a similar systems is used, except that combinations are not
necessary. Locator badges are considered to be the keys. Floor panels
immediately in front of the doors detect whether or not somebody wants to get
inside. If they detect positive, and the door is considered to be unlocked for
the locator badge held by the person requesting access, then the door opens.
Key sections of the ship (secure areas) may also require a particular key
(usually a card of some sort), voice recognition, thumb-print scan, or
something else entirely. It's just too easy to steal locator badges to trust
them entirely.

Of course, all these precautions depend on the security staff implementing
them, and there are many ships in the fleet which while physically capable of
having a very tight security are generally run in a lazy fashion simply because
nothing ever happens anyway. The capital starships are the most secure vessels,
but they are the exception and not the rule. The older ships, most notably the
non-combat variety, are very insecure. Star Fleet is analyzing the problem, but
only time and increasing technology will likely to help the situation.


External Sensors
-------------------------------------------------------------------------------

There are three main types:

1. Long Range Sensors. Generally good to about four light years. You can pick
   up massive interstellar objects (stars) with this. Also, any ships in warp
   space will also register. From examining these warp emissions, you can (in
   much the same way a sonar tech derives the identities of submarines) figure
   out exactly what ship it is that you're looking at. These sensors are
   passive.

2. Medium Range Sensors. Generally good to about one subspace minute (or about
   2.3 light days). From here you can get a look at much smaller astronomical
   objects. Planets, moons, asteroids etc. You can identify some world
   characteristics (whether or not they are Class-M candidates, for example).
   You can also identify starships in much closer detail, mainly from analyzing
   the emissions of the ship's deflector grid, which it must use even when not
   in battle (at least while it is in motion) to keep from physically impacting
   with micro-asteroids. These consist of both passive and active suites.

3. Short Range Sensors. Generally good to several light seconds. They can pick
   up surface details of a planetary body and can tell what type of ship you're
   looking at by physically analyzing the shape and size of the vessel. One
   subset of short range sensors are immediate range sensors which include life
   detection and analysis. Short range sensors consist of both passive and
   active suites.

Tactical Sensors are a mixture of short and medium range ones. They enable the
weapons to "lock" on targets. They extend into the thousands of light seconds
(around 10000 c-secs on the Phobos). Phasers have reduced effectiveness outside
of this range. The Phobos P-torps only have a range of about 5000 c-secs.

Also important in the intelligence gathering scheme is the ship's subspace
emitter coil, what it uses to send subspace messages. Different ships are
fitted with different types of emitter coils, and by analyzing the particular
details of a ship's signal, a communications officer can determine what type of
ship she or he is talking to.

As might be expected, all this intelligence gathering business is countered by
a variety of means. The crew of the Phobos considered three different ways to
disguise their sensor image.

1. Modulating the engine power emissions. Hence, a military vessel may opt to
   appear more "traderish" than "starfleetish". The downside is that both
   engine efficiency and maximum speed are reduced.

2. Re-configuring the deflector shield grid. Again, this impedes upon the
   ability of shields to protect the ship in battle (perhaps by as much as
   50%), but it also makes the true nature of the ship less obvious at medium
   range.

3. Installing field baffles around the subspace emitter coil. This decreases
   the range of subspace transmissions by about 50% (On an old bucket like the
   Phobos, from 35 light years to about 20, and 35 light years on subspace
   isn't a whole lot to start out with). Note that this also applies to omegaon
   (real-time) subspace transmissions, though this is largely a non-issue since
   omega waves only propagate about one light year before destabilizing and
   suffering a decay of coherence (and hence their applicability as a method of
   communication). This is the very reason for the omegaon-relay network which
   reaches across Federation space, but that's another issue entirely.

The time required for such modifications varies from ship to ship and from crew
to crew. The Phobos was at a disadvantage being both old and under-staffed.
Engine modulation was estimated at twelve hours, deflector re-configuration and
installation of field baffles being estimated at a measly two hours each by way
of comparison.

During the game, a question was raised as to the extent to which a ship could
appear to change overall tonnage. For instance, could a tug-boat appear like a
battleship and vice-versa? Or a torpedo for that matter?

First of all, it's important to remember that a ship only registers on long
range scans when it's at warp. How long do you think a photorp could do warp
speed? Not very.

Generally speaking, you can calculate a ship's tonnage by taking a look at it's
power output vs. how fast its going. There's a set relationship between these
three variables. When a crew modulates their engine output, however, they can
increase the amount of leakage. Increasing it by anything over a factor of 5-10
is gonna be dangerous, however, and the more they increase it, the more erratic
the power flow tends to get. Any observable fluctuation is a sign that either
the ship is really poorly maintained or it's trying to disguise itself.
Alternately, the crew can work harder at containing the leakage, generally
decreasing it anywhere between a factor of 2-5 depending on the design,
manpower, and equipment. Decreasing emissions also means decreasing engine
performance, however, generally by one warp level for each factor of
containment efficiency above one (so you could look like a ship one-third your
size, but it'd cost you 2 warp levels to implement).

There are devices (crosses between torps and shuttles) which can pull off a
short term warp-voyage and give off massive emissions, perhaps looking like a
starship 1000 times their actual mass, but you don't want to ride on one unless
you like death from radiation poisoning. Particularly robust shuttles, like
Hawkins' Dixie for example, can be modified to suit the task. However, a
standard shuttle probably wouldn't do the trick, because it's engines just
aren't tough enough for the task. It would end up blowing itself up after an
hour or so.

Despite the various failings of the concept, this final method was chosen by
the crew of the Phobos. In short, Vince wanted a decoy, and Hawkins didn't want
to sacrifice the Dixie to provide it. While I hate having to delve into such
complex rationalizations just to provide the characters with technical
dilemmas, I also don't like to let their players stomp all over me with the
various ill-defined technical possibilities inherent to the genre. In this
sense, there is a road to walk for the prospective gamemaster, too much
technical verbosity on the one side and too many opportunities for the players
to run amuck on the other.


                 _   /|       Jim Vassilakos
                 \`o_O'       [e-mail]
                   ( )        [e-mail]
                    U         Riverside, California

 -----------------------------------------------------------------------------
 This Star Trek PBeM is archived on ftp.cs.pdx.edu in pub/frp/stories/startrek
 -----------------------------------------------------------------------------