Re: FT: Question that may be really *old*...

Richard Bell wrote:

>>>In the pure beam case, the armor does not even delay the first
>>>threshold check (crunch the numbers, in the pure beam case, they
>>>all reach the first check at approximately the same time),
>>
>>Hm? If your simulator says this, there's either something strange
>>with it or you don't use re-rolls for beams - the latter would
>>explain quite a bit, of course. Lessee:
> 
>	      die roll
> screens    1	  2    3    4	 5    6
> none	      0    0	0    1	  1    2
> lvl-1 	0    0	  0    0    1	 2
> lvl-2        0    0	 0    0    1	1
> 
>To account for rerolls, we must multiply the average damage per die
>by the average number of rolls per die.  Which is 1 + 1/6*1 +
>1/6*1/6*1 + ..., and the result is 1.20.
>
>So the the test SDN with no screens requires twice as many hits as
>the lvl-2 SDN, but each die of beams inflicts twice as much
>damage . . . DOH! (I even remember coding this factoid and being
>amazed at how little the runs changed), the point two dice are not
>stopped by screens, 

Exactly :-) The average damage per beam die is:

No screen	2/3 + 0.2*2/3 = 4/5 ( = 0.8)
lvl-1		1/2 + 0.2*2/3 = 19/30 ( = 0.6333....)
lvl-2		1/3 + 0.2*2/3 = 14/30 ( = 0.4666....)

so the test SDN with no screens, strong hull and 20 pts of armour 
requires twice as many dmg pts to reach the 1st threshold as the one
with strong hull and lvl-2 screens, but each die only inflicts

(4/5)/(14/30) = 24/14 = 1.714... times as much damage, not 2x as much.

>so the lvl-2 screened ship has the first threshold, but the screened
>ship does not lose enough weapons to offset the damage bonus it
>inflicts on the armored ship. 

Spot on - for strong-hulled ships. But, as I outlined in the previous
post, quite often not if the hull is too weak.

>The other problem is that the screened ship probably still has at
least >one screen, so the armored has at most one turn of advantage for
>volume of fire.

The average time needed for 3 DCPs to repair a particular system is 2
turns, not 1 :-/ The average advantage in raw volume of fire (number of
dice thrown) remains with the armoured ship until either of
- all downed systems have been repaired, or
- the screened ship forces the armoured ship over the next threshold
before taking that threshold itself.

>What really skews things against the armored ship is that screens >can
be repaired, but not armor.

More or less true, but it depends both on the size of the ship and on
the
size of the battle. 

On the size of the ship, since cruisers and light capitals - up to
about BDN size or so - often don't have enough DCPs left when the
screens go down to repair all they'd need to repair. SDNs and bigger,
OTOH, tend to have enough DCPs to get a 50% repair probability on at
least one system even after the 3rd threshold, and on 2-3 systems after
the 1st threshold.

On the size of the battle, due to the varying amounts of firepower the
enemy can concentrate against the ship. In a large battle the enemy can
often throw many times the ship's own firepower at it, so the screens
should always have DCP priority (unless the enemy primary weapons
ignore screens, of course). In a single-ship duel, the damage points
saved by the repaired screen aren't always worth as much as the damage
points that could've been inflicted on the enemy by the weapon the same
DCPs could've repaired instead. Of course this depends on what weapon
it is, what the tactical situation is etc. and so on, so it isn't
really possible to give hard guidelines for this situation.

>The simulation evolved as I realized mistakes were made.  The first
>iteration was aweful, because I forgot to implement the armor (no
>surprise about the results). 

<chuckle> Been there, done that...

>The second iteration forgot to have any ship attempt to repair damage
>(the priorities were FC's if all were down and there are weapons,
>screens, p-torps, beams, and spare FC's). The third iteration properly
>handled rerolls. The fourth iteration added initiative coin tosses for
>each turn.  The fifth iteration added the p-torps and the armored ship
>finally stopped being an unqualified failure.

Some suggestions for the sixth iteration:	 :-)

- Go cost-for-cost, not mass-for-mass (unless your gaming group fights
equal-TMF battles rather than equal-points battles, but in that case
you'll have real problems with FB2). Armour is cheaper than screens, so
a mass-for-mass comparison automatically short-changes it.

- Vary the hull strengths. Armour and screen efficiencies depend on the
hull strengths in rather different ways, so knowing which is better for
one hull strength doesn't say much for another hull strength.

- Vary the engine sizes. Unless/until the simulator can take maneuvers
into account (which is rather difficult unless you make some very
specific assumptions) you'll only be able to compare ships with the
same thrust rating to one another, but the relation between the armour
and screen efficiencies as a function of the hull strength is different
for ships with different engine sizes.

- Compare ships with different amounts of passive defences and
different hulls strengths to one another, eg. to determine which hull
strengths are best for different engine sizes (it's not the same for
all thrust ratings), or to determine the hull/engine combinations for
which it isn't effective to carry *any* passive defences. (Some are
obvious of course - the ones that won't have any space left for weapons
if you put the passives in - but there are some others as well.)

Have fun ;-)

>I chose strong hulls on the basis of what turned out to be a small
>sample size (my web connections were not terribly rich at first, nor
>did I have time to do a lot of surfing).  FB1 has a frequency of 50%
for >SDN's with strong hulls.

If you look at the population of FB ships of TMF 60 and up (ie., the
ones which are large enough not to suffer from the screens' minimum
Mass) instead of just the SDNs, FB1 has a frequency of just over 20%
for strong hulls while Average hulls are almost 75% ;-)

The small sample size was the very reason I started collecting FBx ship
designs from the web, BTW. It's still only a small sample considering
the huge number of copies FT2 (and, I suspect, FBs) sold, but at least
1245 ships and 65 designers (latest count - it grows constantly) is a
wider selection than 111 ships from a single designer 
:-)

Before someone asks where I found these designs: Some months back I
posted a list of web pages with FT ship designs, which (together with
Brian's ship registry at http://www.ftsr.org/) covers about 2/3 of my
design archive; that post should be in Jerry's archive somewhere.
Unfortunately I know that some of those pages have gone down
since then, but I haven't had time to update it :-(

Later,

Oerjan Ohlson
oerjan.ohlson@telia.com

"Life is like a sewer.
  What you get out of it, depends on what you put into it."
- Hen3ry
From - Wed Dec 13 16:39:21 2000
Return-Path: <owner-gzg-l@scotch.csua.berkeley.edu>
Received: from scotch.csua.berkeley.edu ([128.32.43.51])
	by lilac.propagation.net (8.8.5/8.8.5) with ESMTP id LAA20364;
	Wed, 13 Dec 2000 11:46:54 -0600
Received: from localhost (daemon@localhost)
	by scotch.csua.berkeley.edu (8.11.0/8.11.0) with SMTP id
eBDHfpA76671;
	Wed, 13 Dec 2000 09:41:51 -0800 (PST)
Received: by scotch.csua.berkeley.edu (bulk_mailer v1.12); Wed, 13 Dec
2000 09:41:49 -0800
Received: (from majordom@localhost)
	by scotch.csua.berkeley.edu (8.11.0/8.11.0) id eBDHfiU76606
	for gzg-l-outgoing; Wed, 13 Dec 2000 09:41:44 -0800 (PST)
Received: from soda.csua.berkeley.edu
(IDENT:rPlQv58jdnY7bT45dgRoR6hP1CNxyxBf@soda.CSUA.Berkeley.EDU
[128.32.43.52])
	by scotch.csua.berkeley.edu (8.11.0/8.11.0) with ESMTP id
eBDHfeP76588
	for <gzg-l@lists.CSUA.Berkeley.EDU>; Wed, 13 Dec 2000 09:41:40
-0800 (PST)
Received: from d1o960.telia.com (d1o960.telia.com [195.252.60.241])
	by soda.csua.berkeley.edu (8.11.0/8.11.1) with ESMTP id
eBDHfdf73907
	for <gzg-l@csua.berkeley.edu>; Wed, 13 Dec 2000 09:41:39 -0800
(PST)
	(envelope-from oerjan.ohlson@telia.com)
Received: from default (t2o960p74.telia.com [195.252.60.194])
	by d1o960.telia.com (8.8.8/8.8.8) with ESMTP id SAA04113
	for <gzg-l@csua.berkeley.edu>; Wed, 13 Dec 2000 18:41:36 +0100
(CET)
Message-Id: <200012131741.SAA04113@d1o960.telia.com>
From: "Oerjan Ohlson" <oerjan.ohlson@telia.com>
To: <gzg-l@csua.berkeley.edu>
Subject: Re: [FT, SG] Tell the world, I've updated the page
Date: Wed, 13 Dec 2000 18:42:03 +0100
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1157
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-gzg-l@lists.CSUA.Berkeley.EDU
Reply-To: gzg-l@csua.berkeley.edu
Delivered-To: gzg-l@csua.berkeley.edu
Status:   
X-Mozilla-Status: 0000
X-Mozilla-Status2: 00000000
X-UIDL: 39d245de0000087c

Bell, Brian K wrote:

>I'll play Oerjan for a moment (although I'm not worthy <s>)
> 
>Sydney Class Hvy Carrier:
>ADFC shown in SSD, but not listed in defenses or Sensor Suite.
>Without the SSD the ship has 2 mass unused.

Seems like Derek managed to update the page before I could check it <g>
But there are some other oddities:

Sydney CV: With the FB2 terminology hull integrity 39 is "Weak", not
"Fragile". I assume the FCS is for sensor purposes, since the ship has
no weapons which require FCS guidance?

Albatross CVE: Hull integrity 36 is "Average", not "Weak". The ship
only
uses 124 of its 126 Mass, due to Derek's design spreadsheet being
faulty. The Albatross's TMF is 126 so its thrust-4 engines are Mass
25.2 and its screens are Mass 6.3; they should be rounded down (to 25
and 6 respectively), but the spreadsheet rounds them *up* (to 26 and 7)
instead. IIRC (didn't have time to check very carefully) it also rounds
the FTL size up instead of to nearest, but for this ship those two give
the same result.

????-class missile cruiser: Tech specs says that it has a single
FCS, which is wrong. The SSD shows 2, which isn't.

Later,

Oerjan Ohlson
oerjan.ohlson@telia.com

"Life is like a sewer.
  What you get out of it, depends on what you put into it."
- Hen3ry
From - Wed Dec 13 16:39:21 2000
Return-Path: <owner-gzg-l@scotch.csua.berkeley.edu>
Received: from scotch.csua.berkeley.edu (scotch.CSUA.Berkeley.EDU
[128.32.43.51])
	by lilac.propagation.net (8.8.5/8.8.5) with ESMTP id LAA21772;
	Wed, 13 Dec 2000 11:54:59 -0600
Received: from localhost (daemon@localhost)
	by scotch.csua.berkeley.edu (8.11.0/8.11.0) with SMTP id
eBDHjQm76762;
	Wed, 13 Dec 2000 09:45:26 -0800 (PST)
Received: by scotch.csua.berkeley.edu (bulk_mailer v1.12); Wed, 13 Dec
2000 09:45:25 -0800
Received: (from majordom@localhost)
	by scotch.csua.berkeley.edu (8.11.0/8.11.0) id eBDHjOw76741
	for gzg-l-outgoing; Wed, 13 Dec 2000 09:45:24 -0800 (PST)
Received: from soda.csua.berkeley.edu
(IDENT:xznJ4ZKhe40BJnvsPETKpvoxqIG82qD+@soda.CSUA.Berkeley.EDU
[128.32.43.52])
	by scotch.csua.berkeley.edu (8.11.0/8.11.0) with ESMTP id
eBDHjMP76736
	for <gzg-l@lists.CSUA.Berkeley.EDU>; Wed, 13 Dec 2000 09:45:22
-0800 (PST)
Received: from mta6-rme.xtra.co.nz (mta6-rme.xtra.co.nz [203.96.92.19])
	by soda.csua.berkeley.edu (8.11.0/8.11.1) with ESMTP id
eBDHjLf74299
	for <gzg-l@CSUA.Berkeley.EDU>; Wed, 13 Dec 2000 09:45:22 -0800
(PST)
	(envelope-from Al.Bri@xtra.co.nz)
Received: from Al ([203.96.110.220]) by mta6-rme.xtra.co.nz with SMTP
	  id <20001213174515.RMKW1003258.mta6-rme.xtra.co.nz@Al>
	  for <gzg-l@CSUA.Berkeley.EDU>; Thu, 14 Dec 2000 06:45:15 +1300
Message-ID: <006f01c0652c$86cb2300$dc6e60cb@Bri>
From: "Andrew Martin" <Al.Bri@xtra.co.nz>
To: <gzg-l@csua.berkeley.edu>
References:
<417DEC289A05D4118408000102362E0A34D146@host-253.bitheads.com>
Subject: Re: [DS2] Aerospace Q
Date: Thu, 14 Dec 2000 06:45:46 +1300
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-gzg-l@lists.CSUA.Berkeley.EDU
Reply-To: gzg-l@csua.berkeley.edu
Delivered-To: gzg-l@csua.berkeley.edu
Status:   
X-Mozilla-Status: 0000
X-Mozilla-Status2: 00000000
X-UIDL: 39d245de0000087d

Thomas R. S. Barclay wrote:
> I was reading my DS2 and I thought I saw movement rates for VTOLs and
Aerospace craft. Yet I also thought I read that an Aerospace craft
operates
by making a pass over the board, defining its entry and exit points and
flight path, and then executing that. It seemed like movement rate was
thus
irrelevant (any plane should be able to make a pass in 15 mins...).

> What's up? Where'd I step off the path?

VTOLs (helicopters, Jetcopters, vehicles that go up and down) have a
movement rate and move like ground vehicles as well as up and down.
Aerospace craft (jets, deltas, etc) work as you describe.

> And on another note, anyone toyed with the idea of mounting LADs on
your
VTOLs? This would be like the "stinger" mounts on some modern choppers
to
provide limited A-A to ground support/ground attack VTOLs. Does this
make
sense?

Yes. Have a look at the Aerospace page in the DSII section on my site.
You'll see a lot of options there, including aerospace specific GMS and
such
like.

> And as to the comment about my proposed vehicle design by capacity
points... <which said I should just divide by 5 and round up - I assume
rather than use the chart provided>.... unless I screwed it up, that was
exactly the algorithm the chart attempted to ellucidate. <*grin*>

You might want to check out my fractional vehicle size rules, which
allow
for vehicles to be of any capacity, not just integral multiples of 5.

Andrew Martin
ICQ: 26227169 http://members.nbci.com/AndrewMartin/
-><-