help with Ancients ship design
- Thread starter c_osborne
- Start date
far-trader
SOC-14 10K
Just a little clarification. You had me worried that T20 had goofed big on BGs there Sigg
As a side note I've often wondered just how much energy a BG absorbs each turn from background radiation. Around a Gas Giant? In the Inner Zone of a star? In the Habitable Zone? In the Outer Zone? In deep space? Anyone have some numbers?
But back to the clairity bit. In addition no weapon can fire out either.
In fact no energy can cross the barrier. The ship is blind and invisible. The only way to know it's there is by observing a lack of radiation when you know there should be some. Such as if the BG ship eclipses a signature and you notice the interruption.
The High Guard rules only impacted the ship's agility, with a 10% reduction per Flicker USP setting (rounding fractional agility down). But then HG combat wasn't really concerned with maneuvering. T20 seems to have missed or skipped this entirely. I can't recall if MT or some other rules did it and that's where I got it or if it was a HG house rule but I always figured it should also reduce the Maneuver thrust too by the same rate. And depending on the type of drive used it could pump some energy into the BG while doing so.
Also the whole "fog" issue was never properly addressed in my opinion. There should be some sensor/targeting and communications penalty for the BG ship being partially blind and invisible too. It should be harder to maintain weapon locks both ways when flickering. And it should be harder to maintain contact if conducting coordinated action.
I think for T20 a +5 to the DC per USP Flicker Rate (up to +50 to the DC for full on) for all sensor and communications checks (both ways) seems about right. It should also apply to visual spotting checks. There may be some slim chance of reading something even when full on, nothing is 100% efficient. But at +50 to the DC I think it's pretty much impossible
And then too HG required that before weapons addressed the BG they had to hit and penetrate defenses, without penalizing said defenses which never seemed right. Those defenses should suffer some reduction too. But T20 seems to have not addressed that either though it seems implied that to adjust the damage done you must have rolled a to hit and penetrated defenses. I think the effective USP of defenses should be reduced per the Flicker rate too.
Well, that was the HG rule (ship destroyed), second printing/edition anyway. First printing only said the drives "may" detonate and the BG drops leaving the ship exposed.
T20 handles it nicely (or starts to) by saying the ship takes damage equal to the total energy absorbed but then fails to give a way of converting EP to SI damage points. It should be related to the Weapon Efficiency table (p 157) rates but I haven't sat down to figure it out. It should also have noted that the Jump Drive (if that was the capacitor source) is completely destroyed.
Of course in MTU capacitors (that are so dangerous) have an ejection system. If an overload condition develops they blast out of the hull with the explosion directed away from the ship. So I don't have to worry about that whole problem.* You just don't have any capacitor banks left. If they were the Jump Drive capacitors your Jump Drive is disabled but easily repairable with the installation of a new capacitor bank.
* Until some clever desperate Captain realizes...
Which can be really bad if (since you're blind) you happen to run into something big and/or fast (relative). I mean really really bad.
As a side note I've often wondered just how much energy a BG absorbs each turn from background radiation. Around a Gas Giant? In the Inner Zone of a star? In the Habitable Zone? In the Outer Zone? In deep space? Anyone have some numbers?
But back to the clairity bit. In addition no weapon can fire out either.
In fact no energy can cross the barrier. The ship is blind and invisible. The only way to know it's there is by observing a lack of radiation when you know there should be some. Such as if the BG ship eclipses a signature and you notice the interruption.
...but at a reduced efficiency. At least one would imagine so. It is implied that this rate of flicker is not a cycle but random. If it were cyclic you'd be able to time your own energy output to bypass it, and a smart enemy might also soon note your cycle rate and do the same thing. I figure this is the nature of the globe and not something that can be controlled. At least not with current understanding. A controlled flicker BG would be almost as good as a White Globe.
The High Guard rules only impacted the ship's agility, with a 10% reduction per Flicker USP setting (rounding fractional agility down). But then HG combat wasn't really concerned with maneuvering. T20 seems to have missed or skipped this entirely. I can't recall if MT or some other rules did it and that's where I got it or if it was a HG house rule but I always figured it should also reduce the Maneuver thrust too by the same rate. And depending on the type of drive used it could pump some energy into the BG while doing so.
Also the whole "fog" issue was never properly addressed in my opinion. There should be some sensor/targeting and communications penalty for the BG ship being partially blind and invisible too. It should be harder to maintain weapon locks both ways when flickering. And it should be harder to maintain contact if conducting coordinated action.
I think for T20 a +5 to the DC per USP Flicker Rate (up to +50 to the DC for full on) for all sensor and communications checks (both ways) seems about right. It should also apply to visual spotting checks. There may be some slim chance of reading something even when full on, nothing is 100% efficient. But at +50 to the DC I think it's pretty much impossible
And then too HG required that before weapons addressed the BG they had to hit and penetrate defenses, without penalizing said defenses which never seemed right. Those defenses should suffer some reduction too. But T20 seems to have not addressed that either though it seems implied that to adjust the damage done you must have rolled a to hit and penetrated defenses. I think the effective USP of defenses should be reduced per the Flicker rate too.
T20 handles it nicely (or starts to) by saying the ship takes damage equal to the total energy absorbed but then fails to give a way of converting EP to SI damage points. It should be related to the Weapon Efficiency table (p 157) rates but I haven't sat down to figure it out. It should also have noted that the Jump Drive (if that was the capacitor source) is completely destroyed.
Of course in MTU capacitors (that are so dangerous) have an ejection system. If an overload condition develops they blast out of the hull with the explosion directed away from the ship. So I don't have to worry about that whole problem.* You just don't have any capacitor banks left. If they were the Jump Drive capacitors your Jump Drive is disabled but easily repairable with the installation of a new capacitor bank.
* Until some clever desperate Captain realizes...
mike wightman
SOC-14 10K
I was too lazy to go into all the details - so I just outlined the salient points.Originally posted by far-trader:
Just a little clarification. You had me worried that T20 had goofed big on BGs there Sigg
Don't forget that in HG the BG armour factor - 2 points of effective armour per flicker factor - is applied to enemy ships as well.
So your outgoing fire must also go into your capacitors
I think a more sensible way would be to reduce the effective number of batteries firing, representing syncronising firing with flickering (random to the outside observer but your computer controls the BG and your weapon batteries so surely this would be trivial).
You could represent sensor blindness by reducing the effective computer model by the flicker rate, but that's probably overkill, model 9 computer/sensor/firecontol systems can probably work pretty efficiently in their limited window.
Reduce computer model by 1 per 3 flicker factor?
far-trader
SOC-14 10K
I was too lazy to go into all the details - so I just outlined the salient points.</font>[/QUOTE]Quite. It just seemed odd to me that you mentioned incoming and not outgoing, and I had only skimmed the T20 rules so I might have missed it. And then I just got carried awayOriginally posted by Sigg Oddra:
</font><blockquote>quote:</font><hr />Originally posted by far-trader:
Just a little clarification. You had me worried that T20 had goofed big on BGs there Sigg
Nope, hadn't forgotten that, but it seems T20 skipped it.Originally posted by Sigg Oddra:
Don't forget that in HG the BG armour factor - 2 points of effective armour per flicker factor - is applied to enemy ships as well.
So your outgoing fire must also go into your capacitors
Both those ideas sound good too. Accepting that your computer does "actually" control the BG flicker rather than it being a mysterious recovered ancient tech that "works" in ways not clearly understood.
I was thinking maybe reducing the effective ranges of sensors and commo by one factor per flicker rate. So lower models are more subject to the interference while higher models are better able to fill in the gaps and punch out through sheer power. Hmm, power, I wonder if the higher computers should pump a flicker percent of the required EP in the capacitors too? But again I am running on and wandering off
mike wightman
SOC-14 10K
If the computer EP represent energy put into sensors then yes the energy should go into your black globe capacitors
Or again, you could match the sensor emissions to the flicker rate - which could lead to downgraded sensor performance just the same as if the energy is being absorbed.
Hmm...
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">computer effective computer model at flicker rate
model 0 1 2 3 4 5 6 7 8 9 10
number __________________________________
1 1 1 1 1 1 1 1 1 1 1 0
2 2 2 2 2 2 2 2 2 2 2 0
3 3 2 2 2 2 2 2 2 2 2 0
4 4 3 3 3 3 3 2 2 2 2 0
5 5 4 4 4 3 3 3 2 2 2 0
6 6 5 5 5 5 4 4 3 3 2 0
7 7 6 6 5 5 5 4 4 3 2 0
8 8 7 7 6 6 5 5 4 3 2 0
9 9 8 8 7 7 6 5 5 4 3 0</pre>[/QUOTE]These numbers were arrived at by reducing the computer EP by the flicker factor % and then determining the effective computer model from the EPs remaining (rounding down).
Or again, you could match the sensor emissions to the flicker rate - which could lead to downgraded sensor performance just the same as if the energy is being absorbed.
Hmm...
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">computer effective computer model at flicker rate
model 0 1 2 3 4 5 6 7 8 9 10
number __________________________________
1 1 1 1 1 1 1 1 1 1 1 0
2 2 2 2 2 2 2 2 2 2 2 0
3 3 2 2 2 2 2 2 2 2 2 0
4 4 3 3 3 3 3 2 2 2 2 0
5 5 4 4 4 3 3 3 2 2 2 0
6 6 5 5 5 5 4 4 3 3 2 0
7 7 6 6 5 5 5 4 4 3 2 0
8 8 7 7 6 6 5 5 4 3 2 0
9 9 8 8 7 7 6 5 5 4 3 0</pre>[/QUOTE]These numbers were arrived at by reducing the computer EP by the flicker factor % and then determining the effective computer model from the EPs remaining (rounding down).
far-trader
SOC-14 10K
Nice table Sigg
Icosahedron
SOC-14 1K
Maybe Model 2 should become Model 1 and Model 1 is just not complex enough to cope with flicker at all, and becomes zero?
Using this table, a Model 9 is progressively deteriorated by flicker rate, while a lowly Model 3 is barely affected, and is not affected at all by flicker rates above 1. Perhaps ALL computers should be degraded all the way to zero, so that small computers just cannot be used effectively with the higher-tech BGs.
Using this table, a Model 9 is progressively deteriorated by flicker rate, while a lowly Model 3 is barely affected, and is not affected at all by flicker rates above 1. Perhaps ALL computers should be degraded all the way to zero, so that small computers just cannot be used effectively with the higher-tech BGs.
