Subj:	TRAVELLER digest 336
Date:	95-07-03 21:44:10 EDT
From:	traveller@mpgn.com
To:	traveller@mpgn.com

From:	traveller@mpgn.com
Sender:	traveller@mpgn.com
Reply-to:	traveller@mpgn.com
To:	traveller@mpgn.com (Multiple recipients of list)
			    TRAVELLER Digest 336

Topics covered in this issue include:

  1) Re: TRAVELLER digest 333
	by lhowie@dilbert.lrmi.com (Les Howie)
  2) Boy, am I dumb
	by lhowie@dilbert.lrmi.com (Les Howie)
  3) BR Optional Rules (longish)
	by merrick@Rt66.com (Merrick Burkhardt)
  4) Re: Why it's easier...
	by merrick@Rt66.com (Merrick Burkhardt)

----------------------------------------------------------------------

Date: Sun, 02 Jul 1995 23:05:26 -0300
From: lhowie@dilbert.lrmi.com (Les Howie)
To: traveller@MPGN.COM
Subject: Re: TRAVELLER digest 333
Message-ID: <9507030211.AA16578@lrmi.com>

"Brendan O'Donovan" <Brendan@odonovan.demon.co.uk> wrote:

>On a related point, why do starships need to have a constant armour value
all 
>over? If you can outmaneuver your opponent and keep him in your front arc,
then 
>why not make your frontal armour thicker? Given that most hull
configurations 
>are longer than they are wide, then the front arc will have a lower surface 
>area, and so require less material volume to make the armour thicker.
>

I would certainly consider such a design acceptable for BL play, since the
hull area hit by an attack is clearly determined.  FF&S (of I recall
correctly) also allows for the additional armouring of internal systems such
as engines, powerplant, etc.

Neither of these rules translates well into BR; designs with differentiated
armour could use a weighted average, but I can't see a clean way to
translate interior armour benefits.

> This 
>approach could also be useful for non-military designs. A trader operating
in 
>safe systems would only need Gmax x 10 armour on the front, back and one
side 
>(the side presented to the direction of travel when the ship turns over at 
>midpoint). 

I think that the resoning about minimum armour related to thrust has more to
do with structural strength then micometeors; otherwise the minimum armour
would be a function of maxmimum delta-V.
>
Les Howie
Senior Software Developer
Atlantic LRMI


------------------------------

Date: Sun, 02 Jul 1995 23:40:30 -0300
From: lhowie@dilbert.lrmi.com (Les Howie)
To: traveller@MPGN.COM
Subject: Boy, am I dumb
Message-ID: <9507030246.AA16818@lrmi.com>

Brendan wrote

> A trader operating in 
>safe systems would only need Gmax x 10 armour on the front, back and one
side 
>(the side presented to the direction of travel when the ship turns over at 
>midpoint). This could provide some weight and volume advantages. After all,
the 
>10 armour on some traders is as good as nothing against lasers and even
particle 
>accelerators already.
>

which just goes to show that he read the rules, and I should have before
shooting my mouth off.  Sorry (the fact that I like my explanation better is
completely irrelavent ).

Internal armour is listed on page 62 (part of section 7, Optional Systems)
Les Howie
Senior Software Developer
Atlantic LRMI


------------------------------

Date: Sun, 2 Jul 1995 23:45:27 -0600 (MDT)
From: merrick@Rt66.com (Merrick Burkhardt)
To: traveller@MPGN.COM (traveller)
Subject: BR Optional Rules (longish)
Message-ID: <9507030545.AA06791@Rt66.com>

Howdy, here is my latest "bash".  Before I lose some of you "I don't want his
house-rules" people, let me note that with the exception of some fixes I did
on
errors in the rules (where they are inconsistant with BL) all of these are
plug
and play optional rules that fix *within* the BR rules as they stand.

Rules changes (and fixes) for BR:
 
Task Difficulty Fix:
--------------------
All sensor, jammer, screen and fire tasks are 1 difficulty level harder.
This is a change in the *Base Difficulty Level*, this is not a DiffMod!
 
This reflects the fact that all the tasks considered _Average_ in BL,
mysteriously changed to _Easy_ in BR, even though the BR rules give a table
for converting TNE task Diff Levels to BR.
 
 
Overpowering DiffMod Fix (clarification):
-----------------------------------------
Overpowering -DMs may only be used to counteract +DMs (same as FC rating
rule)
 
Missile Damage Clarification:
-----------------------------
Det-Laser missiles do 1-6 damage points, regardless of success level.  
Optionally, allow 2 separate hits for outstanding success, but don't add them

together, it makes them way too nasty.
 
Additional Optional Rules:
==========================
(note that these rules are in addition to existing rules, and do not
supersede 
them except where noted)
 
Limited attacks by Spinal & Parallel (non-trainable) Weapons mounts:
--------------------------------------------------------------------
A ship, in addition to the Multiple Firing Batteries (MFB) Rule (pg.19), may 
only fire a number of spinal and other non-trainable *weapons* equal to its 
maneuver rating in gs, minus every gturn spent on evasion and maneuver
(tracking
does not count for this, see below).  Results less than 1, are treated as 1.
 
The exception being that it may always fire weapons up to the number allowed
in 
the MFB Rule at any *single* target.
 
The maximum weapons bearing Re:MFB Rule are *always* in effect.
 
Optional addition 1:  A ship/taskforce may expend gturns on _tracking_. For
each
tracking gturn, add 1 to the number of weapons that may attack.
 
Optional addition 2:  Ships may fire more than the allowed number of weapons,

but add +1 Diff Level (to *base* level) for each additional weapon.
 
 
 
Advanced Sensor Rules:
======================
It is assumed that the bogeys that are represented by taskforce counters
(real, or false) were detected before the beginning of a given scenario using
long-time
observations with the ships' passive sensor arrays (rules for this are more 
suitable for BL, than BR and are not discussed here).  All ships are assumed
to enter a scenario passive (unfolded) unless otherwise noted.
 
Variable short range:  
---------------------
All active sensors may operate at any short range (SR) below their maximum
for 
various tactical reasons.
 
	eg: A CA with A:16 sensors may choose to
	operate them at A:2 in an attempt to lock
	nearby missiles without broadcasting its
	capabilities to the enemy.
 
Advanced Passive Folding Arrays:  
--------------------------------
Because they are aperture synthesis arrays, passive sensors may be listed
with 
2 short ranges.  The first is the SR that the ship may use *without*
suffering 
folding array penalties, the second, in parentheses, is the SR for the
unfolded array.
 
	eg: A BB might be listed as P:6(8).  This ship
	could use P:6 without unfolding an array, or
	P:8 with its array unfolded.
 
Going Active:  
-------------
In addition to the -1 DM the target ship suffers from going active, the 
detecting player gets to calculate the base difficulty using the SR of the 
*target* ships active sensor if it is using its *passive* sensors for
detection.  
 
	eg: A CA in its detection phase decides to
	attempt detection of an active taskforce 60
	hexes away.  Its folded passive array (P:5(8))
	has a SR of 5, so it wouldn't normally be able
	to detect a target past 40 hexes.  Since the
	target is active, with a SR=16 detector, the
	detecting ship may attempt detection with a
	base difficulty equal to Long range (within 64
	hexes).  The base difficulty would therefore
	be 4 (using the diff level fix above), and all
	other DMs would be added/subtracted from this
	value.
 
 
Twice Extreme Range Locking:  
----------------------------
Locking is possible out to *twice* the extreme range of an *active* targets' 
active sensors.  The base difficulty level is Impossible +2 (7 in BR), and
must be reduced by DMs to 5 to even be attempted.
 
 
Advanced Surprise:
------------------
Any targets that are surprised (see BR, pg. 25) are unaware that other ships
are
present at all, and are therefore conserving gturns.  
 
Under combat conditions ships use microbursts from their maneuver system to 
slightly randomize their positions.  The range DMs on the Player Aid Card
assume
these micro-evasions---but surprised ships (or non-evading ships with limited

gturns) are *not* making these micro-evasions.  As a result, the range table 
needs to be altered for attacks on surprised ships as follows:
 
Surprised ships are attacked normally, but the range DM is +1 for every 10
hexes
range (instead of 3).  In addition, surprised targets may be engaged out to
the limits that FC and overpowering allow, simply add a difficulty level to
the base
level at each doubling of range (+1 for twice extreme, +2 for 4xextreme,
etc.), and use the +1DM/10 hexes range table.
 
Obviously, only size will make attempts possible past a weapon's extreme
range.
 
 
Kinetic Kill Missiles (KKMs):
=============================
 
KKMs are fully independent (FIM), or semi-independent (SIM) missiles that
rely 
on physical impact with the target to cause damage.  They function as
det-laser 
missiles, except in the final moments of their flight, where they maneuver to

intercept their targets, then explode to disperse a cloud of tiny BB-like
shot 
that damages the target.
 
Launching and Detecting:
------------------------
Same rules as BR page 13.  KKMs must be noted as such when launched.
 
Controlling Missiles:
---------------------
All KKMs are SIMs, or FIMs, and are controlled as such.  I'm working on a 
playable way to run FIMs---stay tuned.
 
Moving Missiles:
----------------
KKMs move in the same way as other missiles (BR, pg. 13) with one exception:
to 
intercept a target, they *must*, in addition to intercepting the target hex, 
have a number of unused gturns equal to the number the target spent on
evasion 
(regardless of success) this turn, *plus* any +DMs due to the success of
evasiontask.
 
	eg:  A ship spends 4 gturns on evasion, and
	draws a 1, giving it a +1 DM, any attacking
	missile must have 5 gturns remaining after hex
	intercept to attack the target ship.
 
Defensive Fire at Missiles:
---------------------------
KKMs are defended against as in BR page 13-14 with the following exceptions:
 
1.  Target Declaration---No change.
2.  Fire Control Lock---Same as BR pg. 13, but with
    an additional -1DM.
3.  Beam Weapon Fire---Conducted normally, but KKMs
    may be attacked *twice* by each weapon (KKMs
    become obvious to targeting computers since det
    laser weapons fire at a great distance right
    after the last chance shots.  KKMs keep closing
    allowing another last-ditch attack.)
4.  Dampers have No Effect.
5.  Sandcasters function in the same way as BR pg.14.
 
Firing KKMs:
------------
Firing KKMs is done as per the rules on pg.s 14, and 18 (SIMs) of BR.  Due to

the diff level fix, as well as the more difficult nature of a <c fire control

solution, the base difficulty level is 3.
 
No whiteout counter is placed, and damage is equal to the Closing Velocity
(CV) 
divided by 2 (round all fractions *up*).
 
The shot has a high penetration, so armor is treated as it is for lasers.
 
 
 
===================================================
Designer's Notes:
===================================================
 
First things first.  The Difficulty Level fix had to be done.  It *must* have

been an oversight---otherwise any player character fleets would be at a Diff 
Level disadvantage vs. non-player fleets according to BR's rules.
 
The Overpowering thing is clear in BL, and unclear in BR, just thought I'd
make 
it clear.
 
The rationale for the limit on det-laser missile damage seems clear enough.
 
The idea that a limited number of non-trainable weapons can actually engage 
targets seems to make a lot of sense to me.  Since all such weapons must be 
pointed at a target by rotating the entire ship, it would greatly constrain 
maneuver if too many targets were fired at, or too many weapons were trained
on targets.
 
The variable SR active sensors, and advanced passive folding array rules are 
more of the common sense variety, I thought many people would assume them,
but 
wanted to add them for clarity.
 
The use of the active sensor long rang, and passive locks on active targets
out to twice extreme is the result of the fact that the detecting ship sees
more 
energy than it reflects back at the active source.  As a result, it should
see 
about the same energy the active ship sees at twice the range.
 
The advanced surprise makes sense of the range DM table as it pertains to 
non-evading targets, and frankly, it was also a rationale for not driving
around
with the AEMS lit up all the time.  It would also have interesting
implications if one was to assume missiles did not micro-evade (kinda closer
to the BL 
designers notes in Challenge, huh?).
 
Lastly, I threw in my BR rules for KKMs.  These guys are really nasty, but
make
sense from a reality point of view.  I made intercept hard for them, and made

them easy to detect, and easy to kill---so you'd have to launch a huge number
to
get hits on a big ship, but they would probably be a little cheaper to make,
and
they aren't nukes (sometimes an important factor).
 
Once again, let me know what you think!
					Merrick Burkhardt

------------------------------

Date: Mon, 3 Jul 1995 18:41:37 -0600 (MDT)
From: merrick@Rt66.com (Merrick Burkhardt)
To: traveller@MPGN.COM
Subject: Re: Why it's easier...
Message-ID: <9507040041.AA24584@Rt66.com>

I made a major flub. 
 
 
> This, combined with the fact that MFDs can reduce basic diff levels in BR,
not
> just +DMs, mean that targets are engaged farther out than they are in BL.

This isn't the case in the rules, MFDs only negate +DMs.  /fwap merrick

The other problem is real.

-Merrick


------------------------------

End of TRAVELLER Digest 336
***************************


----------------------- Headers --------------------------------
From traveller@mpgn.com Mon Jul  3 21:44:33 1995
Received: from Ambassador.MPGN.COM by emin04.mail.aol.com with ESMTP
	(1.37.109.11/16.2) id AA269242273; Mon, 3 Jul 1995 21:44:33 -0400
Return-Path: <traveller@mpgn.com>
Received: from  (localhost [127.0.0.1]) by Ambassador.MPGN.COM (8.6.9/8.6.9)
with SMTP id VAA04855; Mon, 3 Jul 1995 21:38:45 -0400
Date: Mon, 3 Jul 1995 21:38:45 -0400
Message-Id: <199507040138.VAA04855@Ambassador.MPGN.COM>
Errors-To: traveller-request@mpgn.com
Reply-To: traveller@mpgn.com
Originator: traveller@mpgn.com
Sender: traveller@mpgn.com
Precedence: bulk
From: traveller@mpgn.com
To: Multiple recipients of list <traveller@mpgn.com>
Subject: TRAVELLER digest 336
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Traveller Mailing List

