Aurora 4x
VB6 Aurora => Bureau of Ship Design => Topic started by: blue emu on November 06, 2011, 01:16:25 PM
-
I've recently started experimenting with Modular Ship Design: designing ships in seperate sections (or modules), with the pieces held together by Tractor Beams. It actually works!
Here's a low-tech AMM module intended to be towed behind any ship requiring anti-missile protection. It has rather thin Armor, but not very much will be needed since the module is only 2,500 tons and has no engines, so it is hard to detect and harder to target from typical missile ranges. It carries a res-1 sensor, two PD FCs, six size-1 PD missile tubes, a 166-missile magazine, enough life support for the minimal crew and enough engineering sections to repair the biggest component on-board (the active sensor). No engines or fuel... instead, it carries a Tractor Beam, to lock it onto the mission ship.
The mission ship does not need a Tractor Beam!
Parasite AMM class Module 2,500 tons 215 Crew 600 BP TCS 50 TH 0 EM 0
1 km/s Armour 2-16 Shields 0-0 Sensors 1/1/0/0 Damage Control Rating 2 PPV 6
Maint Life 4.11 Years MSP 300 AFR 25% IFR 0.3% 1YR 28 5YR 426 Max Repair 252 MSP
Magazine 166 Tractor Beam
Size 1 Missile Launcher 2000 (6) Missile Size 1 Rate of Fire 10
Missile PD Fire Control FC10-R1 (2) Range 10.1m km Resolution 1
Size 1 AAM 1-2.2-2003 (166) Speed: 39,300 km/s End: 0.9m Range: 2.2m km WH: 1 Size: 1 TH: 288 / 173 / 86
Active Search Sensor MR20-R1 (1) GPS 252 Range 20.2m km Resolution 1
Missile to hit chances are vs targets moving at 3000 km/s, 5000 km/s and 10,000 km/s
This design is classed as a Military Vessel for maintenance purposes
Towing this module slows down a 20,000-ton Beam Warship from 5,000-odd kps to 4,500-odd kps... a -10% loss of performance. Naturally, the module can be dropped after the mission ship has weathered the enemy's missile fire, or once it has pulled in close enough that the PD module can cover the rest of its approach-run.
Think of the possibilities! Civilian ships can tow weapons modules. Carriers can be towed hangars instead of ships. In long, marathon battles, Fuel and Missiles can be towed, with the supply module dropped when empty. Jump Drives can be towed to the entry point of a contested system, then dropped at the jump point. Your whole task force can be faster and more agile if they don't need to carry jump drives. Tow a Box Launcher module, fire it off, and dump it, to be recovered later!
Other advantages: Modular ships can be built in sections, using smaller slipways. You can have a potent navy earlier in the game. They are also cheaper, and much easier to upgrade. Developed a new sensor suite and new missile launchers? Instead of upgrading your battle-line, just upgrade the AMM and ASM modules, or build some new ones!.
Comments and suggestions?
-
A good idea (didn't girlinhat mention something like this?) Although I think it would be more feasible for space stations than ships.
-
That, sir, is awesome! I don't know why i haven't thought of this before!
I'll try immediately ;D.
-
A good idea (didn't girlinhat mention something like this?) Although I think it would be more feasible for space stations than ships.
I think there's an old thread on this subject still kicking around, but rather than find it and resurrect it... different forums feel differently about thread necromancy... I decided to start a new one.
Jump point defense is certainly one possibility.
I am particularly intrigued by the possibility of mating civilian engine/armor sections with military weapon sections.
-
Yes, it's quite genius I think. Just idea but: what about a mine module? Some you could deploy from a ship that would fire thousands of self guided munitions?
-
A mine module would work... perhaps we should make a list of suggested modules:
1 ) AMM PD module
2 ) Gauss PD Module
3 ) Laser PD module
4 ) Box Launcher ASM module
5 ) Hangar module
6 ) Supply module (esp. Missile Ammo)
7 ) AWACS (Battle Management) module
8 ) Jump Point Defense module
9 ) Zone Denial module (ie: minefield)
10 ) Jump Drive module
-
Troop transport,
Non-box ASM,
Meson PD,
Decoy / bait (cheap but AI-attracting sensors?),
Salvage (because I rarely put more than one salvage module on a salvager and that seems like a waste of engines to me),
Freight (modular freighter size for varying cargo sizes or plain forward listening post / mainteance factories),
Survey,
Constructor
-
In the past I've considered both a "mine module" and a towable hanger array in place of carriers. The former was more like a disposable JP defense station, and the latter was more like a mini-FAC base that could hop from system to system as needed. Unfortunately I never got around to making either, though I did develop the doctrine for the latter quite a bit.
-
I tried out a similar idea out a while back (http://aurora2.pentarch.org/index.php/topic,2459.0.html), though my starting point was modules and ships of roughly the same size. Eventually it got refined into something similar to what youre doing. The best part was that you could move modules around on commercial ships too.
I still wish there was a mechanism for internal modular construction (ala the 'mission packages' for the US Navys LCS).
Heres another module suggestion, particularly when facing fast nasties; Booster module; a lot of engines and fuel.
-
I brought this up rather recently in "advanced tactics" actually. My designs were primarily going to be an engine section and a mission section, but it's very possible to add mission elements to the engine. I'm particularly fond of the box launcher idea, and the warp drive has some real potential, especially as it acts like a tender and you can leave it on the "safe" side. Not to mention fuel canisters open a lot of options. Have enough fuel for in-system combat and leave the main tanker module out of danger, shave off some weight from your combat ships, every bit helps. I'm also interested in a "heavy weapons" module. Some mega lasers to add a stiff punch to your fleet. Not to mention, sensor modules have some very obvious use. No more big expensive sensor ships, just slap a thermal module onto a destroyer and let them go!
-
Holy Crap! I've just had an idea (EDIT: reading over the new posts just above mine, it seems that everybody has had the same idea):
After-burners!
Put the tractor beam on the mission ship (instead of on the module), and use a small ship that's nothing but engines, fuel and (possibly) armor... to increase the mission ship's speed. If we can get the after-burner down to 1000 tons, we can use a FAC engine (2x power). If we can get it down to 500 tons, we can use a FTR engine (10x power)!
EDIT:
Interesting... a 120-ton Fighter "After-burner" increased the speed of a 41,000-ton (!) warship by 69 kps. Not really a signifigant boost, of course... but that's with a 41,000-ton mission ship, more than 340 times more massive than the module. I'll try it again later with a better size-match.
EDIT again:
OK, this is more like it... a 350-ton FAC after-burner increased that same 41,000-ton mission ship's speed by over 220 kps. That's quite impressive, considering that the mission ship out-masses it by more than 100-to-1.
EDITEDITEDIT:
... and a self-contained 900-ton Afterburner II FAC (with tractor beam) can boost a 16,000-ton cruiser by more than 400 kps. I think we're onto something, folks!
-
An interesting behaviour is the ability to daisy chain tractor beams. A ship that has been tractor beamed can tractor beam another ship.
To me, the most vulnerable portion is that you allow the enemy to knock apart one module at a time. This makes shields nearly useless.
You also waste alot of mass on armour, which gets heavier-per-non-armour-ton as your ship gets smaller.
-
An interesting behaviour is the ability to daisy chain tractor beams. A ship that has been tractor beamed can tractor beam another ship.
Are you sure? I thought that particular exploit was patched out some time ago. I didn't even bother testing it.
To me, the most vulnerable portion is that you allow the enemy to knock apart one module at a time. This makes shields nearly useless.
You also waste alot of mass on armour, which gets heavier-per-non-armour-ton as your ship gets smaller.
On the other hand, small modules give a smaller radar signature (inverse square) so for a res-100 active sensor to detect my 900-ton afterburner (or for a res-100 FC to target it), the enemy needs to approach more than 25 times closer.
-
If you take a single ship, split it in half with engines and weapons, and add a tractor, you become significantly harder to detect and shoot and significantly cheaper to produce (smaller shipyards with more slipways).
-
Are you sure? I thought that particular exploit was patched out some time ago. I didn't even bother testing it.
On the other hand, small modules give a smaller radar signature (inverse square) so for a res-100 active sensor to detect my 900-ton afterburner (or for a res-100 FC to target it), the enemy needs to approach more than 25 times closer.
You can in 5.52. I am unsure if it works for 5.53
Small radar signature is a plus yes. Although you do have a certain minimum effective size and it's somewhere around 1-2ktons.
Which isn't quite small enough unless you blow alot of RP on stealth systems, which, to be fair, will suddenly become alot more useful.
-
I've been playing around with the "Modular Ship Design" idea, with emphasis on trying to come up with a practical after-burner to boost our mission ship speeds.
A 120-ton Afterburner Fighter can tow a 41,000-ton mission ship (!) and boost its speed by about 69 kps. Not particularly impressive... if you ignore the fact that it's towing a load more than 340 times more massive than itself. The Tractor Beam needs to be mounted on the mission ship, though. No room for it on the Fighter.
A 350-ton Afterburner FAC can tow that same 41,000-ton mission ship and boost its speed by over 220 kps. Now we're getting somewhere! The Tractor Beam still needs to be mounted on the mission ship, though.
A 900-ton Afterburner FAC equipped with its own Tractor Beam can tow a 16,000-ton Cruiser and boost its speed by more than 400 kps. Now this idea is really starting to look practical! The Cruiser can even have a landing bay to carry the Afterburner FAC, when it's not in use.
Designs available on request.
EDIT: Latest test results:
One of these:
Afterburner FAC II class Module 1000 tons 65 Crew 246.4 BP TCS 20 TH 115 EM 0
11500 km/s Armour 3-8 Shields 0-0 Sensors 1/1/0/0 Damage Control 1 PPV 0
Annual Failure Rate: 0% IFR: 0% Maintenance Capacity 38 MSP
Tractor Beam
GB Internal Confinement Fusion Drive E65 2017 (1) Power 230 Fuel Use 650% Armour 0 Exp 36%
Fuel Capacity 85,000 Litres Range 23.5 billion km (23 days at full power)
This design is classed as a military vessel for maintenance purposes
... can tow one of these:
Box Launcher class Module 1150 tons 16 Crew 196.3 BP TCS 23 TH 0 EM 0
1 km/s Armour 3-9 Shields 0-0 Sensors 1/1/0/0 Damage Control 1 PPV 18
Annual Failure Rate: 0% IFR: 0% Maintenance Capacity 11 MSP
Magazine 120
Size 6 Box Launcher (20) Missile Size 6 Hangar Reload 45 minutes MF Reload 7.5 hours
Missile Fire Control FC117-R100 (1) Range 117.6m km Resolution 100
This design is classed as a military vessel for maintenance purposes
... at 5,175 kps. Looks like a reasonable plan for colony defense... keep a bunch of Box Launcher modules in a hangar, and the Afterburner FAC tows one out to firing range, fires it off, tows it back and trades it for a full one. The empty Box Launcher modules re-load while the next attack mission is taking place.
-
Too bad we can't turn off engines on ships that are being towed.
Then a commercial tug could be used to tow combat ships around (with engines off) on patrol to save fuel. Then when crisis approaches, the combat ships drop the commercial engines and start their own for the combat. Commercial engines without payload go v.fast and simply escape.
-
Commercial engines plus a hangar big enough to carry the military ship? Engines are always off inside a hangar.
Admittedly, it's not a perfect solution... an empty hangar weighs just as much as a full one, for instance.
-
I've just tried to compare boosters with and without their own tractor beam. The only difference between both designs were the tractor beam and some crew quarters I had to add to the larger version. The 300 ton FAC brought a 20kt cruiser from ~4600 to 6410, while the 800 ton FAC only reached 6380. I'm not exactly sure what the math behind the tractoring is, but I'd guess the self-tractoring booster isn't as good as the tractored one - but I base this on my observation only. Regardless, their difference wasn't that large.
On a side note, while this is all high tech with the 300 ton FAC engine flying at 1/3c (for up to 50 hours), it managed to boost a 20kt cruiser by a good 2000 km/s. I think boosters will have only marginal impact unless you tune down your mission tonnages significiantly or have upper medium level technology and higher.
-
I'm not expecting miracles, of course... but I feel that this entire field of research could be worth investigating.
Fire-and-forget Box Launcher modules will probably have the greatest impact on short battles, while Missile Magazine modules might have a bigger impact on long battles. After-burners are just an interesting side-branch... to exploit the fact that FAC engines deliver ten times the power-to-weight ratio of normal military engines.
-
Modular design is nice for things you are not going to need much of, or for long range combat. If you want to put heavy beam weapons on a small module you will quickly run into a problem where they don't have enough armor to survive an equivelent hit on them, and you will be in range of matching weapons while they can see you. Missile combat does not have this problem as a small module (ie fac size) can still give you a few more weapons, or a bunch of box launchers without being particularily detectible. I have used the idea somewhat in the past, mostly to give extra point defense coverage for a fleet. A single 25 hull space module has enough room for 1 tractor, 4 size 1 launchers, 1 fire control (usually size 2 for some range) and about 4 hull spaces magazine which translates to around 60-70 missiles. By the time any missile attack is able to hit them, they have already fired off all of thier ammo. Thier biggest drawback is when jumping into a hostile system they take one or your ship slots. The result is you either leave them behind to get the most concentrated firepower, or you need a lot more jump engines.
Putting the jump engine on the module doesn't work all that well because you need the module to be the same size as the ships it is taking through the jump. Sensors modules look good, but I like to have really big passives (40-50 hull spaces or around 2,000-2,500 tons). This is a pretty big module and is going to have a large effect on the towing ships speed. For smaller passive sensors this would be a good way to get a size 6-8 passive for your small combat ships.
Where I found modules to be really helpfull was with resuply of front line combat ships. A commercial ship with lots of maintenance and a tractor beam could tow a fairly big module (50+ hull spaces) of magazines or fuel without being slowed down much at all. The module could then be dropped off near the front while the freighter emptied its engineering spaces into all the ships that had used theirs up and then it would go home to pick up more supplies. Meanwhile the combat related module could stay put and be available for the combat ships to resuply from.
Brian
-
Just had another brainstorm... an idea that is certainly worth testing:
What happens when one of the linked ship modules has Hyperdrive, and the other doesn't? Is it worth carrying a Tractor Beam equipped Hyperdrive-FAC in a Boat Bay inside your mission ship, to tow you around when you are outside the Hyper-limit?
FAC engines are 10x power, and Hyperdrive is 10x speed. That's a 100x multiplier over the usual towing boost... assuming that a Hyperdrive tow is even possible.
EDIT: 2x power (not 10x :-X ), 10x Speed = 20x in total
It seems to me that if this works at all, it should work very well indeed.
-
Oh wow that would be amazing. A size 20 FAC with a hyper engine, a tractor, and some marginal fuel. Small enough to fit in a single hangar and potentially provide, what... 20 engine's worth of thrust to your regular ship? FAC gets 2x speed, hyperdrive boosts that up to 20x. 20 engines for 21 hull space of hangar could be well worth it if you can even pretend to get the enemy outside of hyper limit. A sensor platform or maybe a single transponder ship could be used to lure enemy ships outside of hyper, where your ships suddenly get a huge speed boost and tear circles around the enemy.
-
I'm positive that this whole field of design philosophy is just loaded with clever new possibilities... we just need to think of them.
I'm teching up my Hyperdrive tech now, to get it compact enough to fit in a FAC. I'll be able to test it out in a few more game-years.
-
It works!
(http://i11.photobucket.com/albums/a155/blueemu/Hyperdrive.png)
That's a 1000-ton Hyperdrive FAC towing a 16,000-ton Heavy Cruiser at 55,470 kps!
You have to be really careful about just how you issue the orders, though, because you cannot issue "Enter Hyperdrive" orders to a fleet that contains non-Hyperdrive ships. That option doesn't appear on the orders menu. You need to first move the task group into position outside the Hyperlimit, then detach the Hyper-FAC into a seperate task group, then give it a series of queued orders: "Tractor specified ship", "Enter Hyperdrive", and "Move to..."
It does, however, work very well. Fifteen hours to Pluto.
Impressed yet? ;D
-
I'm thoroughly impressed. This might be a viable way to deliver certain ships to binary systems.
Also, what if you uncheck the little "intelligent order list" thing? There's an option that lets you display all the normally invalid commands that may allow you to hyperdrive.
-
I'm thoroughly impressed. This might be a viable way to deliver certain ships to binary systems.
Also, what if you uncheck the little "intelligent order list" thing? There's an option that lets you display all the normally invalid commands that may allow you to hyperdrive.
Didn't try that, but yes... it might work. I was trying to get the job done without any "fudging".
It should be pretty easy for you to replicate my test. I'm only up to Hyperdrive size x1.6, and that's already compact enough to build a Hyper-FAC with nothing but one Hyper-FAC engine, a tractor beam, and minimal crew accomodations and fuel. As my Hyper tech improves, I can increase the fuel load... although at five hours per billion km, it really doesn't need more than a few days endurance.
-
I dunno, I'd just put hyper engines on the destroyer.^^
Though, will the destroyer be able to fight while the FAC tows it around?
That would open whole new way of missile evasion.^^
As for the box launcher concept, get a few launchers of so you get to 1000 Tons without the bridge.
Thats 50 Tons of bridge after all.
A lot of space in the long run.
Nonetheless, for the same space you'd be able to get 8 fighters of 250 tons, probably still faster and all with a bunch of boxes, you'd need to do a test on what actually delivers more punch.
And wether it wouldn't be more useful to just use reduced size launchers with long ranged missiles.
-
In the past when I did the modular idea for offensive missile combat I ended up deciding that the 25% size launchers were a better idea than the box launchers. This is mostly because box launchers require either a planet with maintenance facilities, or a big enough hanger deck to reload the launchers. The 25% size launchers could however be reloaded in the field. Granted that you get about 60% more launchers when you go to the box style, if you need to shoot them again you can only do that after a going into a carrier, or being towed back home. With the carrier idea it works, but if you are doing this right you probably don't have many carriers with hanger bays available, while you do have a bunch of modules. This makes for a really long long reload time. The 25% size launchers however can have a small magazine with 1 reload internal and then your fleet just keeps sailing along while they reload. The reload times are probably fairly close in scale also. A launcher sized matched by the reload size takes 50 minutes to reload. A box launcher of size 6 takes 45 minutes while a size 4 box launcher takes 30 minutes. All of these are out of combat times, but lots shorter than most movements are going to be. Up to you what you want based on your overall strategy, this was just what worked for me.
Brian
-
I dunno, I'd just put hyper engines on the destroyer.^^
If you just want to hyper it, outsourcing this to a booster would always be profitable. This way you only have one engine with 1.6 times its size and cost, whereas a full sized warship would receive this penalty on its many engines. Even if you tech it down to 1.0x the size, it still doubles in cost for each engine.
I'd make it dependant on how hyper drives are technobabbled - I wouldn't be comfortable with exploiting this if all ships needed to be hyper capable to do this. However, this gives a good reason to actually put the tractor beam on the booster and not the mission module.
-
However, the FAC will burn 10x fuel, and you'll have to somehow bring it along.
The only way that could be useful is if the Destroyer can keep fighting while the FAC tugs it.
-
What happens when one of the linked ship modules has Hyperdrive, and the other doesn't? Is it worth carrying a Tractor Beam equipped Hyperdrive-FAC in a Boat Bay inside your mission ship, to tow you around when you are outside the Hyper-limit?
I very very very ( :) ) strongly suspect that Steve would/will declare this an exploit. His basic design philosophy is to mold the details of the game mechanics to avoid game imbalance. There are two levels of this idea:
1) Being able to fire while under hyperdrive tow: exploit fer sure (you can't fire in hyperspace).
2) Being able to take a hyperdrive tow at all: not sure about this one, I could see him allowing it for "real" tow situations.
One thing that has me very confused - you say you're getting a speed of 55K by having a 1 Kton FAC tow a 16 Kton cruiser. What's the speed of the FAC without the tow? if it's not 17x55K then this is a bug. What should be happening is that only the FAC's engines should be contributing to the hyperdrive speed, which means the speed with tow should be 1/17 the speed without tow. I suspect that Steve never thought of this situation and both sets of engines are contributing, even though only the FAC set is hyper capable.
John
-
Any ship that uses hyper drives can still fire its weapons - That's how it's (afaik) always been with aurora. I don't understand a hyper capable drive as somehow entering hyperspace or subspace, but just somehow overcharging it.
With tractor towing non-hyper ships I'd think the tractor needs to be stronger (=> speed reduction?) to keep up with the increased speed, but there's no ineratia with trans-newtonian engines in aurora, so ... dunno.
-
Hyperdrive in Aurora isn't the system-crossing subspace bubble you see in things like Star Trek. Rather, once you're outside the gravity well, then it becomes possible to take the safety off without having torsion rip your ship apart, and you can shift to a higher gear.
-
I dunno, I'd just put hyper engines on the destroyer.^^
I wouldn't.
Hyperdrive engines are bulky. At my current tech level, they are 1.6 times more bulky than regular military engines. For my 16,000-ton Heavy Cruiser, that would be an extra 2700 tons of displacement... which would mean carrying 2700 tons less weapons, fire control, ammo, armor, etc.
Plus, of course, even a pure Hyper-CA wouldn't move this fast. I'm getting the Cruiser's speed (5,175 kps), boosted by the FAC's tug (to 5,547 kps), then multiplied by ten for Hyperdrive (to 55,470 kps)... all at the cost of ONE Hyperdrive engine: the one on the FAC. The CA has only normal military engines.
I very very very ( :) ) strongly suspect that Steve would/will declare this an exploit.
... and Blue Emu breaks another game!
(HOI-2 was patched twice, and HOI-3 patched once, in order to patch out exploits that I had invented).
FAC without tow is 11,500 kps... 115,000 in Hyper. CA without tow is 5,175 kps. Together: 55,470 kps.
I'm getting CA (5,175 kps) tow-boosted by FAC (5,547 kps) in Hyperdrive (55,470 kps).
I suspect that Steve never thought of this situation
Steve lacks my twisted imagination.
We need a ROFL smiley.
In defense of my exploit, a little techno-babble:
Assume that Hyperdrive engines create a temporary rip or weakness in space-time, allowing the ship's engines to gain traction on an underlying layer of sub-space. A second ship, following immediately behind the first and "drafting" it, can use the same axis of weakness to follow the lead ship at hyperspeed. Since the path of weakness heals quite quickly, the second ship needs to stay tucked immediately behind the first one... best achieved by locking them together with a tractor beam.
I have... in effect... invented the "Hyperdrive Ram"... a small single-purpose ship module which leads a conventional warship and opens a Hyperspace route for it.
-
Yes, this one is an official exploit :)
I'll probably add some code to prevent ships being able to use hyperdrive while towing.
Steve
-
Yes, this one is an official exploit :)
I'll probably add some code to prevent ships being able to use hyperdrive while towing.
Steve
:'(
... I guess I'll have to enjoy it while it lasts, then.
-
Why is that?
I think it's absolutely fine.
You'd need a bit of code that only boosts those engines that actually have hyperdrive ;D
That'll also allow to mount different kinds of engines ;D
-
Why is that?
I think it's absolutely fine.
You'd need a bit of code that only boosts those engines that actually have hyperdrive ;D
That'll also allow to mount different kinds of engines ;D
Agreed - I think there's a valid need to be able to tow e.g. a SY to a binary companion. (OTOH if you (Steve) don't I'm not going to fight it too hard).
I think you can get away with two small bugfixes:
1) Only hyperdrive engines contribute to hyperdrive speed.
2) A ship under hyper-tow is considered in hyperdrive for the weapons firing checks.
3) Ummmm IIRC you're not supposed to be able to fire in hyperdrive. Are you sure this check is actually in? One of the preceding posts makes me wonder....
John (the exceedingly excellent counter)
-
Just a small update.
In my on-going game (now in its 28th year) I am currently designing a new line of warships, every one of which will have a tractor beam and a minimal Hangar Deck for carrying a utility Hyper-equipped FAC. This will enable every ship in the fleet to use modules.
I'll let you know how it works out.
I'm still considering a re-start with a Navy designed from scratch using the modular design philosophy.
-
I'm still considering a re-start with a Navy designed from scratch using the modular design philosophy.
If you do go for an all modular design just remember that you will have problems with major jump point assaults. Deep space or defending against a jump assault you should be fine, but in the assault the number of ships you can take through is really going to bite you as each module is a seperate ship.
Good luck and let us know how it goes.
Brian
-
A Hangar+Tractor is what, 1550 tons?
That'd be three more engines, I'd definitely just create Hyperengines on the actual vessel.
But yeh, let us know how it plays out.
-
A Hangar+Tractor is what, 1550 tons?
That'd be three more engines, I'd definitely just create Hyperengines on the actual vessel.
But yeh, let us know how it plays out.
Naturally the design philosophy has drawbacks... in any reasonably balanced game, every decision will offer both advantages and disadvantages.
Some of the advantages are:
1) The smaller shipyards required... half-size for two-module ships, one-third size for three-module ships, etc.
2) Fewer maintenance facilities required, and fewer workers to run them, leaving more population for other tasks.
3) Interchangeability... the ability to configure a battle fleet based on mission requirements.
4) Faster build times and faster refits based on smaller size; partial refits based on modularity.
Some of the disadvantages include:
1) The need to devote extra mass to Tractor Beams.
2) The surface-to-volume ratio which increases armor tonnage.
3) Shields only protect the carrying module.
-
IIRC, Steve changed the code some versions ago to disalow tractor chains. So no three (or more) module ships
-
IIRC, Steve changed the code some versions ago to disalow tractor chains. So no three (or more) module ships
That was what I thought, but one of the forum members posted a few days ago that he had tested it in v5.53 and it still worked.
I'll test it now...
-
Tested in v5.53:
(http://i11.photobucket.com/albums/a155/blueemu/FourMod.jpg)
... looks like it works fine. I'm getting a pretty good turn of speed out of that arrangement... 85,180 kps... considering that the two 1,000-ton FACs are pulling 51,000 tons of dead-weight (a 26,000-ton Command Cruiser and a 25,000-ton BattleCruiser, neither of which has any Hyperdrive engines).
Here's how it works:
A ship with a tractor beam can have only one link, active or passive. A ship without a tractor beam can have any number of passive links. So a multi-module ship requires at least one module with no tractor beam mounted on it... ie: three tractor beam-equipped modules and one "deadweight" module.
In the example above, BC King Henry IV and both Hyperdrive Modules are tractor-equipped. CC President Abraham Lincoln has no tractor beam equipment... so all of the modules must link directly to it.
-
In my test, it was possible to chain tugs together so I've no idea what you're talking about.
Tug A tractors Tug B
Tug B tractors Tug C
etc.
You have to do this in order. If you make Tug A tractor Tug B, nothing else can tractor Tug A. But Tug B is still a valid tractor target and can still tractor things.
-
Ah, yes... I might have done it in the wrong order.
Still... I've found a formula that ALWAYS works: just daisy-chain everything onto the module with no tractor equipment.
-
Steve's design intent is "no tractor chains". So if you're able to do it, it's a bug.
John
-
Steve's design intent is "no tractor chains". So if you're able to do it, it's a bug.
John
Spoilsport. :P
Why no tractor chains? In real life, multiple tugs sometimes work the same load. Is it just a play-balance provision?
There's a bigger bug that that, hidden in the same code. I can use a Hyper-capable tug to boost a load into Hyperdrive, then detach the tug and send it over to grab the next load... while the original load continues moving in Hyperdrive, despite having only normal (non-Hyper) engines.
Steve should hire me to find these exploits. ;D
-
Given that Steve wrote Aurore to provide a background for his story-writing, I don´t see a lot of harm done, if chain-tractoring stays in. If it suits your playing style, use it. If you think it is silly, don´t do it.
Yes, the AI won´t use it and so is at a disadvantage if you do, but lets face it, this would be one of the lesser problems, the AI faces vs. a player :)
-
What was it about chaining tractor beams that was causing gameplay problems and labelled it as an exploit?
It seems perfectly natural to me for a tug with a tractor beam to grab a cargo pod, which grabs a cargo pod, which grabs a cargo pod, as long as the whole train is moving at the correct speed.
Or if the tug has n tractor beams for it to just pull n cargo pods without tractor beams directly.
-
... Or if the tug has n tractor beams for it to just pull n cargo pods without tractor beams directly.
... or for two or more tugs to both work the same heavy load... as long as they are pulling it towards the same destination, and not fighting over it...
-
... or for two or more tugs to both work the same heavy load... as long as they are pulling it towards the same destination, and not fighting over it...
You can't have that. Anything that tractors something must be in the same task group. Leaving the task group breaks the tractor beam.
-
You can't have that. Anything that tractors something must be in the same task group. Leaving the task group breaks the tractor beam.
Curiously, if the only Hyper-capable ship leaves a task force, that does not cause the task force to drop out of hyperdrive.
Sounds like another bug.
-
So, to confirm, you can have an engine ship with no tractor beam. Then have a point-defense ship with tractor beam, and a sensor ship with tractor beam. Place them into 3 different task groups, and assign the PD and Sensor to tow the engine ship (assuming they're all at the same location) and you'll have a ship pulling defenses and sensors?
If you have one ship being towed and assign another to tow it, will that work, or does it need to use the "standing orders are never invalid" type workabout?
-
Any number of tractor-equipped modules can lock onto a non-tractor module, yes. They will all end up in one task group.
A tractor-equipped module loses its lock if another tractor-equipped module locks onto it, so if you wanted:
A => B => C => D (A locked onto B locked onto C locked onto D)
... then you need to establish A => B first, then B => C, then C => D. If instead you established C => D first, C would lose its lock on D as soon as it was tractored by B.
-
... then you need to establish A => B first, then B => C, then C => D. If instead you established C => D first, C would lose its lock on D as soon as it was tractored by B.
Might be different in latest version, but in my test, if you do C=>D first, C doesn't show up on B's list of targets for tractor.
-
I don't like the concept of tractor-chains, per se, simply because it doesn't seem like its supposed to work this way (especially with regard to hyperFACs). As evidence, note the required order for tractoring things to get the desired result. However, modular ships are intriguing, so perhaps steve would be willing to include a much more flexible system for modular ships (AND MODULAR STARBASES). Consider that you could build a series of Core ships with engines, and then hook 2 modules to it (incresed to 3 and 4 with a line item) and then individual modules would have research lines to expand their absolute size restrictions.
I find modular starbases quite compelling. Very large constructs are quite interesting from my sci fi perspective.
-
I would rather just have a "Starbase" or "(Space) Station" designation for the design screen.
-
Wouldn't designing in modular ships (as opposed to the sorta kludgy method being used) entirely go against the spirit of retooling?
I mean you have a clear advantage in several ways over a player who builds a single ship in retooling terms.
Though this thread is very amusing and interesting. A unique-NPR (ala swarm or precursor) who used the tractor-module method would be pretty cool.
//
I would think starbases would be best implemented in a similar scheme as orbital habitats. I imagine theres been a lot of discussion about starbases tho, heh.
-
Modular ships still require refitting, just not the whole ship at once. Instead of refitting an entire ship to get some new lasers, and dealing with the engines and such along with it, you can instead just refit the laser module. It'll need to be refit eventually, but it'll be easier to refit when you finally need to.
-
I mean you have a clear advantage in several ways over a player who builds a single ship in retooling terms.
You pay in other ways though.
Jump squadron size is one.
Armouring / shielding your engines doesn't work for your lasers/sensors.
-
Also, the need to allocate tonnage to Tractor Beams. A four-module ship requires three Tractor Beams. That's not cheap.
-
It also hurts your overall ship size in early game. If you're making 100HS modules, then 1/10th of that is being tossed into tractors. When it gets later game and ships get bigger, then 10HS used out of 500HS isn't such a big deal.
I'm currently attempting this, and setting my module-per-ship count to my jump limit. If my engine ship has a jump limit of 4, then it will equip 3 modules, and progressively rise as my jump tech rises.
-
My current home game is almost the ideal test-bed for modular design.
I started a Conventional-start game in 1948... simulating a "Roswell incident" start... and we are now about eleven years into the game. Obviously, my tech is still very primative (Nuclear Pulse, first generation missiles, etc), and already I've encountered a space-faring NPR only two jumps from Earth. I'll need a fleet immediately, to guard the Sol system, and my low tech and small shipyards make a modular design philosophy very attractive.
One point worth mentioning: at low tech, the modular strategy offers at least one advantage... my Jump Drives can be quite compact. At Jump Efficiency 3, a 15,000-ton ship would need a 100-HS jump engine, costing 25,000 RP. A ship composed of three tractor-linked 5,000-ton modules would need a 34-HS jump engine costing 2,890 RP, and two 10-HS Tractor Beams which I was going to research anyway (for Tugs)... a saving of 46 HS (2300 tons) which can be used for weapons, armor and magazine stowage instead.
The only other requirement is Squadron Size 3, which is only 2000 RP... and the smaller jump engine saves me 22,110 RP (2,890 instead of 25,000) in addition to the extra 2,300 tons of displacement.
-
I thought squadron size 3 was a base tech needed for jump drives. So there isn't any difference for research points except designing the drive.
-
Correct... you need Squadron Size 3 in order to design a Jump Drive at all.
So there's no down-side to taking the modular approach early in the game... it saves you many thousands of research points on designing the drive, and saves years of shipyard expansions. Plus, the modules can be refitted more quickly and cheaply than a whole ship. New engines? Just refit the drive module. Faster missile launchers? Just refit the weapons module. Improved jump techs? Just refit the jump module.
Another point is that you need only bring along the modules required by the mission. Going to fight an enemy within your own jump-gate network? Leave the jump drive module home, and take along a second weapon section instead, or a magazine module.
-
Also of note: If you use a ship with two ships with tractor beams and attach them to one ship, then the one ship doesn't lose as much speed. IE - My ship has 6k km/s speed. It's HS 100 and the mission modules are HS 100. I was transporting 8 mission modules to a new Mars hangar PDC, so I linked them all to the single drive section. The drive section moved at 3k km/s despite having 9x the weight. It appears that speed calculations are only done for what the ship is directly attached to. Multi-attached ships only count the first link made. You could take a 10kt cruiser, attach a 1t probe, and then attach 50 10kt cruisers on, but the probe is the "active link" and will only register as a 10,001 ton vessel for purposes of engines, and get high speed despite high total size.
I support module ships and think that tractor beams should be kept as they are, but I think that issues like engines being fixed would make it much less exploit-y
-
This has been known as an exploit for quite some time now, and Steve wanted to fix it by limiting Tractors to one/Ship, but appearently he hasn't done so yet.
He's probably more busy with NA, which I support fully.
-
I feel we should keep modular ship designs and keep tractoring as it is.
The speed and hyperspace calculations obviously need to be fixed, that's a bug, as well as maybe add a signature penalty to tractor ships. Two 2000 ton ships might be difficult to spot, but if you put them within throwing distance of each other they become a much larger sensor blip ( sqrt(2000+2000) perhaps?) as well as an EM signature for an online tractor. Both of those fixes will help with the unbalanced parts of modular tractoring, but leave it viable for other uses such as tractorable ammo, fuel and AMM modules, even if chained.
I would ALSO like to see an improvement in the upgradability of ships in the form of modules. If I have a Quad turret laser equiped ship and I want to upgrade to a Quad turret meson equiped ship and the cost comparison is not within 10% I think it was, then this upgrade becomes far more expensive than it should be. Same with upgrading engines. I propose one of two things... Either the ship upgrade needs to recognise part similarity to a certain detail (Quad turret 10cm laser with a better Quad turret 10cm laser is similiar, but a 20cm laser would be less similiar) and take into account the replacing and the replaced module tonnages when upgrading(giving back the replaced part), or allow us to explicitly design modules.
Any 500ton module can be replaced by any other 500ton or smaller module with a minimum of a refit, giving back the replaced module. If you design a module, it will take everything in that module and add 10% excess (reducable with research) and have that be the module tonnage. With this system you can replace mission components of ships as needed resulting in higher flexibility and the ability to far better upgrade your vessels as tech advances. This last suggestion is one I saw before on the forums somewhere, not sure where, so can't take credit for it.
A module ship will be less tonnage since it doesn't need tractor(depends on module size tho) and be protected with shields, need less armor. The tractor ship will be less protected, need excess modules like a tractor and possibly a hangar, will have an EM signature and need a lot more micro-management, but will be able to actually discard modules, either empty magazines or leaving a jump tender or weapons at a jump point. So both will have advantages, legitimizing modularity if that is your gameplay style. A dedicated non-modular ship of course will have advantages in tonnage and cost, if losing out on flexibility.
-
srt(2,000+2,000)=63.24 I think that formula would be rather lopsided...
There's definitely an argument for modular ships, although if it were going to be a new game dynamic then it should act as such. A "clamp" would be needed to affix the module, and the hosting ship would need clamps for each module. Being that they're mounted on the outside of the hull, they should take minimal tonnage and suffer no breakdowns. A core ship might have 4 clamps. You could then design a module as a special type of ship, requiring no engines but needing a clamp, perhaps gaining some boost to maintenance life or crew requirements, maybe they only work when clamped to a core ship. These modules would be designed like a ship, with armor levels, weapons, magazines, sensors, all of that, except they would function as part of the ship itself, so things like fuel and ammo would be shared amongst modules and core, and module weapons could be slaved to core firecons. Ideally these would not show up in sensors, marking only one ship of equivalent tonnage. Incoming fire would have a chance to hit different modules or core depending on the relative sizes. Detached modules (jettisoned fuel or mags) would register more as wrecks or lifepods, items to be scooped up or re-attached, but with no default orders to fire on stray modules. A ship with missile modules could go to any colony or task group and perform the "refit modules" command to quickly re-attach any missing modules that might be available, similar to the way ordinance is applied this would be done in the design screen and the order to refit would grab what was assigned to that class.
If it were done like that, then armor sections could prove extremely valuable, if your 5k ton cruiser was mounting a 10k ton armor covering and a 5k ton weapon rack, then half of incoming fire would get soaked by armor, though the first internal hit would strike the clamp and destroy the module entirely, but then your carrier could be hauling a dozen spare armor covers to make "repairs" easier by exchanging damaged sections for fresh ones. Similarly, magazines could be reloaded on carriers and ships could grab a fresh mag to run back into the fray with full ammo.
This would mainly require 1: the linking module, 2: sharing fire control, power production, fuel, etc across sections that may or may not be there - probably done easiest by simulating damaged sections. If a module is missing, then it counts all those parts as "damaged" in terms of productivity. IE - you're flying along and a missile blows up your module. You had a core with a sensor and engine, a module with a laser, and a module with a reactor. The missile destroys your reactor module. The ship still remembers that it should have a reactor as this is saved as design data, so it marks that as missing/destroyed and adjusts power levels accordingly.
Of course this is mainly late-night ranting, but many of the ideas sound simple enough. Just that Aurora isn't quite built for truly modular ships and it'd take a small overhaul of ship design and tracking to implement them.
-
That is one approach to take; namely that of 'external' modules clamped onto the ship.
The other alternative is something I brought up a while back, which is the concept of 'internal' modules. A real world example is the US Navy's Littoral Combat Ship (LCS) projects, which are able to change payload depending on mission type. Here the design would have a '1000t module bay' component added, with a size of say 1200t. This bay could then take any modules designed by the user which were that size. The modules would be designed as ships, with a special component added to flag them as such.
Not sure how armour would play into this, but it could either act as an 'internal htk' split between all components in the module, or just be restricted to 1.
Tech could improve module changing speed, wasted space, and total mass of ship that could be modularised. A high-tech ~5000t multi-mission destroyer might be nothing more than 1000t of core components like fuel storage, living quarters and the external armour, and then have space for 3 1000t modules and 2 500t modules, which could range from weapons packages, engines, support modules, etc, etc.
Modules would be built by planetary industry and not exist as 'ships', rather more like pre-fab PDCs. They could be shipped as cargo and fitted at locations with appropriate maintenance facilities. Theoretically a fleet support vessel with maintenance modules and cargo space could do it too....
-
Apologies, I meant sqrt(2000^2+2000^2) = 2828 tons, aka pythagoras formula randomly picked. On one hand it is two ships flying close together which should be easier to detect, but then again that thought can be applied to fleets and right now total fleet tonnage does not affect stealth.
The internal module suggestion is closest to what I was thinking, especially since it solves the issue of armor. There might be limitations to what you can add to a module however (should it be allowed to add an engine module?) but it won't be too limiting. Additionally perhaps specialized clamps for turrets, giving say a 55ton turret clamp that can have any 50 ton turret clamped to it at a less than normal clamp overhead. This should make turret upgrades easier.
As for external modules... they sound identical to what I would consider tractoring to look like, only much closer. (Not sure if ingame tractoring is star trek style energy beam or just simple attach a long wire and pull?) Such clamps might act exactly like tractor, just take less space and allow some transfer of power and crew, but act as a seperate ship in terms of combat damage, as well as requiring a colony to switch around. Not too big a fan of this, but if implemented I can imagine this would be how freighters work. Small incredibly powerful engine ships connected to large cargo bays it pulls around.
-
I would imagine the clamps I described to work quickly at colony or hangar, where external robots can line things up just perfect, but it'd be possible in open space to carefully maneuver and bump against a clamp. I mean if we can dock a shuttle to a station in orbit NOW I think it'd be very easy in a universe where inertia doesn't matter.
-
I put this in a thread in tactics, but I guess it belongs here rather more:
Consider a 100kT cargo hold, with virtually no other components. Effectively the space equivalent of a shipping container.
Of course, if you just attached this to a ship, you'd have a very slow ship that takes six weeks to load.
However, what if you make one single high-powered tug, and importantly, at least two cargo modules. While one hold is getting loaded, the other is being transported, and vice versa.
No waiting for loading, and you can move kilotons of cargo with ease. What's not to like?
-
Over the christmas travels, I've come around on Modular ship design. Modular design is to the 21st century what interchangable parts was to the industrial revolution. Weapons, aircraft, ships, factories, office buildings, warehouses, and scientific instrumentation is all benefiting from modular design. Wave of the future, baby.
-
Over the christmas travels, I've come around on Modular ship design. Modular design is to the 21st century what interchangable parts was to the industrial revolution. Weapons, aircraft, ships, factories, office buildings, warehouses, and scientific instrumentation is all benefiting from modular design. Wave of the future, baby.
That's right... they laughed at Galileo! They laughed at Einstein! They laughed at Bozo the Clown!
I'm just ahead of my time! :D
-
I've been trying out my Modular Ship Design in action against a technologically superior foe... the Precursors.
I'll post the results a bit later.
-
I put this in a thread in tactics, but I guess it belongs here rather more:
What is not to like is the horrendous micromanagement needed to do this.
-
I guess. Still, there are reasons you might use it. Perhaps, if your tug is jump-capable, you could use this to make annual mineral runs from distant systems.
-
What is not to like is the horrendous micromanagement needed to do this.
Modular ships do require some micro, yes. The same applies to modular warships. On the other hand... players who hate micro would probably hate Auroras anyway.
-
Its mostly the attach/detatch logistics that makes my brain explode.
I get annoyed by moving through menus to do housekeeping.
-
So I have given the matter some very boring math-thoughts, mainly because I fin it very interesting, but also because blue emu asked my opinion, and well that's just how my brain ticks. Anyway, the post became quite long, and possibly very unclear, I admit that. I will post it in several posts, in the hope that this does not violate the code of conduct on these forums. . .
This has been an interesting and inspiring read so far. I would like to put my tuppence worth and add a bit of an analytical point of view.
What I mean by analytical approach is to try an estimate the costs and benefits of propositions on quantitative grounds, rather than qualitative points. Lets start by thinking what the tractor beam (“TB”) can actually do. It allows to either splitting a big ship into smaller parts, which still share (between them) one important aspect: engine power, or too share this characteristic between two smaller ships. On the other hand several characteristics are not shared between the joint modules: Armour, damage control, crew quarters, bridges, fire controls, shields and CIWS. So the question is: Is creating two modules actually better than creating either i) two completely separate ships, or ii) one integrated ship?
Generally the modular designs offered here fall into broadly four categories:
• Modules that make use of special rules that apply differently for different mass ranges, thereby allowing ship components that would usually not be accessible for a bigger ship. E. g. strapping a FAC engine on a capital ship via a TB (Afterburner Module)
• Separating parts of the ships so they can be more readily upgraded / replaced.
• “Dead weight” modules, which includes components that contribute little on the tactical level - at least after the opening moves (Fuel, “Box Launcher”-Module. . . )
• And lastly, modules that foster the ability to adapt ships to specific profiles in different circumstances.
Some of these ideas might be more efficient than others, so lets try to get an estimate of their respective efficiency. On difficulty is that Aurora has a number of different “costs” in terms of which efficiency could be measured (wealth, population, minerals…) and its not obvious
1) Weight-Particular modules
a) The Afterburner: the afterburner concept aims to allow major ships access to fighter-engines or FAC-engines, which are much more powerful than an ordinary engine. Ordinarily they are not suitable for capital ships, as they are restricted to certain mass ranges, and only one of these engines can be mounted on a vessel (while a vessel can not mount more than one type of engine). If the engine is put in a different, appropriately small vessel (the afterburner module), these restrictions are not important and we have access to the more powerful engine. So far the idea.
In quantitative terms a FAC-Engine weighs the same 250t, as an ordinary engine, while having twice the power. However, in order to connect the module to the main ship we need a tractor beam with a mass of 500t. Therefore we can see that the minimum weight for the module is 750t (engine plus tractor). Note that this is the mass-equivalent of 3 ordinary engines. 3 ordinary engines provide 50% more power than one FAC-engine (while using less fuel). Similar arguments apply in terms of building points cost, at least until very high tech levels. It would therefore seem that the afterburner is not a very efficient use of hull space or building points.
For simplicity we have ignored armour here. For very heavily armoured ships it could be that the armour required to mount the engines internally is higher than the weight or cost of the tractor beam, if the afterburner itself is left unarmoured. Furthermore the capital required to build and operate the shipyard is slightly higher for the single integrated ship, compared to the attachable afterburner +slightly smaller ship. We will examine that effect later in more detail, but under ideal circumstances this could be about 4% more shipyard capital for a 16. 75kt cruiser, compared to a 16kt cruiser+1t afterburner.
b) The jump tender: The jump engines become more costly for larger ship sizes in terms of building points, size and importantly research points. So the “jump module” aims at using smaller ship sizes to reduce these cost.
However it should be kept in mind that jump-ships allow the transit of a certain number of vessels that are smaller or equal in weight to both the jumps-ship’s size and the maximum allowance of the engine. Since larger jump-engines are more expensive, and provide no extra benefit, they are generally matched to the size of the carrier ship. I. e. a 3000t ship carrying a jump engine that allows 3000t ships to transit. Jump engines weigh less than their maximum allowance, hence jump ships must be “padded out” to match the allowance of their jump-engine. In other words it is not sensible to tow only the jump engine. For instance a jump engine that allows 4000t ships to transit might have a mass of 1000t itself, but it towed it could only allow 1000t ships to transit. Given the abovementioned costs of large jump engines, this is quite wasteful.
Since jump ships need to be padded out with other stuff anyway, this can well be engines, fuel spaces and engineering sections, turning the “module” into a full blown ship in its own right. So modularity in regards to the jump-engine seems to return little benefit. Which leaves the issue of the ships that it is supposed to accompany, is there a benefit to building modular? Maybe there is, but not in connection to the specifics of a jump attack. Surely, smaller jump-engines are cheaper and more readily available, so it is more costly to use big ships to make a jump attack. But remember the second alternative to modules: simply building separate ships. Say the squadron-jump size is 3, i. e. the jump-ship can carry two vessels into the contested system. This could be one ship of two modules, or two separate ships. Generally there seems to be little situation-specific reason why one big “moduled” ship should be preferable to two smaller vessels.
-
2) Upgradability: Engines are effectively shared between tractored ships. Engine technology has a significant impact on their performance. Because speed is important, new-generation ships will often be faster than older ones, i. e. players mostly use newer engine designs to receive a boost in speed, rather than freeing up space for more weapon platforms/armour/etc. while retaining the old speed. The net effect is that older ships can not form a battle line with modern ships and have to be in separate group (unless one sacrifices many of the speed advantages of the modern ships). Therefore old engines are a serious drawback of old ships. Engines are also a big and expensive part of most ship designs, which often makes replacing old engines on old ships more expensive than building a new ship altogether.
At the same time most other things do age a bit better. A new-generation missile launcher might fire missile salvos more quickly, but that does not render the old launcher obsolete. It can still fire new model missiles, unless the size is increased. Fire controls and sensors do get better, but this is often used to save size, so that one is able to fit more things into a new ship. Given the old ship is already there, its old launchers etc. usually still provide a valuable addition to any fight – provided it could be used in the fight along with the newer ships. Many other things do not loose much or any effectiveness at all - engineer compartments, damage control, fuel space, crew quarters… It is thus somewhat wasteful to scrap these elements – if only they could be propelled to the speed of the newer ships.
So the obvious suggestion is to split ships into 2 modules: A “Propulsion-Module” containing engines, some engineering and fuels spaces plus crew quarters, and a “Superstructure-Module” (or however you want to call it) which contains the tractor beam, weapon stations, magazines, fire controls, sensors, etc. The superstructure-module could be retained, while the propulsion-module would be scrapped and replaced by a version using newer engines, when these become available.
The benefit is the ability to keep old ships operational at low costs. Let us assume players use a fixed proportion of their (mobile) capital combat ships’ hull space for engines, e. g. all ships are 25% engines (*1). Say we use a propulsion module of, say, 30% size (to account for fuel, crew, engineers), of a new ship. When modernizing, the old engines will yield some scrap value for the old engines (30% IIRC). Assuming the old engines had cost 20% less than the old ones, we gain the new engines for 1-0. 8*0. 3~75% percent of their actual cost. Approximating weight with costs, we can modernize a ship in this way for 75%*30%=23% of the cost of a new ship.
After some tedious calculations I would estimate, that the “superstructure” should likely be upgraded every two to three generations as well. Yet there is a rather large number of factors influencing this and actually I am not too sure I used a sensible estimate for each. Still lets assume that the superstructure is updated every three generations, rotating, such that at each time 1/3 of the superstructures are 1st generation, 2nd generation and 3rd generation respectively.
Thus what would happen is that when a new tech generation is researched: 1) all propulsion modules are scrapped and rebuild 2) 1/3 of the superstructures are scrapped and rebuild. The first costs 23% of a new ship, while the later costs 70% (superstructure size) * (1 – 0. 3*0. 8^3 (scrap value of the old superstructure)) *1/3 (number of refits) = 20%. So overall in order to keep this fleet at that level we would require 43% of the costs of building a the same number of new ships. Scrapping and rebuilding an integrate ship of this size would have cost 1-0. 3*0. 8=75% of the costs of an entirely new ship. Put differently, in the long run the modular design allows us to have 1. 7 times as much ships, as we would have if we would scrapped and rebuild our ships every “round” of technology.
However these ships would be different. On the one hand brand new ships would all be of the latest weapon technology, while only 1/3 of the modular ones have the latest weapons, with the other 2/3 being outdated to some degree. Lets assume that each level adds about 10% to the damage dealt on the enemy. Thus the next-to-latest superstructures would deal about 91% (=1/1. 1) of the damage of the latest tech, while the 2-generation-outdates ones would deal 83% (=1/1. 1^2) of the damage of the latest tech, Or on average they would deal 91% of the damage of an equivalent number of the latest ships.
Furthermore, the modular design has some overhead costs compared to an “integrated” design. Notably one of the modules need to carry a tractor beam (most likely the superstructure, so to avoid rebuilding it for every new generation); both of the modules likely need a bridge; in order to achieve the same level of protection more armour must be used; shields need to be duplicated. Ignoring shields, because they might not be present at all, we can determine how much “dead” weight the modularity adds:
-The tractor beam weighs 500t.
-The bridge adds another 50t.
-For the armor it is slightly more complicated. The weight needed for armour is proportional to the desired armor thickness and the “surface area” of a vessel, which are assumed to be spherical. The volume (and thus weight) of a sphere goes like V~r^3 (r=radius), while the surface are goes like A~r^2. So the surface area is proportional to A~s^(2/3) (where s is the size). Thus 2 small vessels of size 1 will have 26% more surface area than one vessel of size 2 (2*1^(2/3)-2^(2/3)=2^(1/3)=1. 26). For a 30% propulsion system- 70% superstructure split this would mean an increase in the increase in surface area is 24% compared to a big ship. If one wants to retain the same armour thickness for both modules in a modular design, then this means the weight of armour will increase by 24%. Yet it should be kept in mind that the increase in surface area is not purely a bad thing, as it also influences the probability of enemy shots hitting the same spot more than once. I haven’t yet found a nice way to quantify the value of a broader armour versus a deeper armour, but I feel the later is vastly more important, hence I will ignore that there is also a benefit here. Also it is conceivable that the two modules could be armoured differently, i. e. it could be recognized that the destruction of a superstructure module is more valuable to the enemy (because the superstructure could fight without the propulsion at reduced efficiency, but the propulsion itself can not fight at all). Therefore the superstructure should be armoured more than the engine, up to the point where the enemy is indifferent between targeting either. There is a difficulty in that heat-seeking missiles could target the engines more effectively, while radar-seeking or fire controlled missiles would be more easy to fire at the larger superstructure. We are going to ignore this benefit that the additional diversification brings, because on the other hand the two modules can not share their damage control teams or potential shields, so this might chancel somewhat.
The absolute effect for the last point (+24% in armour mass) depends on the armour that is being used in a ship, so as a totally unrepresentative example I took my 18kt Heavy Cruiser with 3 layers of composite armour, totalling around 11% of the ships mass - roughly 2kt. If I would split this into a 30%-70% modular design with the same 3 layers of armour on each, this would necessitate 24%*2,000t=500t more in weight. Together with the tractor beam we would have a total weight of 1000t that represents the “cost” for modularity. On a 18kt Cruiser this is of course quite significant. I could skim this weight of the ship by removing 4 of the 20 missile launchers, netting a drop in my broadside weight of 20% (just an approximation, ultimately it is unlikely that I would do this, the weight reduction would likely come from many sources, maybe 1-2 launchers, bits of this and that, until the marginal benefit of all component matches). For now let us assume that this nets a 20% reduction in the ability to deal damage on the enemy.
Now we can try to piece this information together. We compared two scenarios: 1) the benchmark scenario in which every generation ships were entirely scrapped and rebuild to the latest standard and 2) a modular design, where we separated engines and superstructures. In this scenario we replaced the engines in every generation, while only 1/3 of the superstructures were replaced every weapon generation, because weapons age better than engines do in Aurora. This allowed us to operate 1. 7 times as many ships than in scenario 1. The modular design ships were on average a bit older and thus could only deal 91% of the damage of a contemporaneous design. They could also carry 80% less main weapons as the tractor beams and lower armour efficiency took away space. In total they can thus only deal 73% (=0. 91*0. 8) as much damage.
Finally converting these numbers into a measure that captures the ability to win battles, lets call it “Battle Winning Ability”. Ships are both targets and shooters, so we will use the Lanchester laws(*3) and calculate BWA=N^2*Damage_dealt. The Standard (integrated) design has a BWA=1 (we normalized it this way), while the modular design has a BWA=1. 7^2*0. 73=2. 31.
In other words the modular design offers a more than twice as much higher ability to win battles.
This is derived under a large set of assumptions, maybe the most important being the ship size of 18kt. For ships of 3kt the 500t-tractor beam would present a much higher proportion of the ships weight and consequently reduce the amount of weapon space more significantly.
Still that is quite a result - Bravo, Blue Emu!
As a side issue: Modular design also reduces the capital and worker requirement for shipyards. Take a 10kt ship, which could either be built integrated, requiring a 10kt shipyard. It would be produced at a rate of 1 +0. 5*(10kt/5kt-1)=1. 5 the racial build-rate. It would thus take 10/1. 5=6. 7 generic time units. In comparison a 30%-70% modular design could be build using two shipyards, one of 7kt and one of 3kt. The 7k module would be built a speed of 1+0. 5(7/5-1)=1. 2, and take a time of 7/1. 2=5. 8 generic time units. The 3k module would be build at 0. 8 and take 3. 75 generic time units. Thus using 3 7k slipways and 2 3k slipways will generate 3 new module-ships every 5. 8 generic time units. In the same time 3 10k slipways could “only” create 2. 6 integrated ships. So modular design uses less shipyard capacity (27k of slip yards in total, instead of 30k) and still produces ships faster (3 instead of 2. 6 ships).
This also applies to the shipyard-level. To build ship+afterburner one needs two shipyards - one with size x (the size of the ship) and one at size 1000t -, while to build the bigger ship with 2 more engines, one would need a single shipyard of size (x+500t).
(*1): This might be a crude assumption, and would only constitute an optimal strategy if the marginal utility of speed is hyperbolic, or, equivalently, that the utility of speed follows a logarithmic function(*2). This is likely incorrect, but I have not been able to come up with a better approximation for the (marginal) utility of all factors yet.
(2*): This can be derived by realizing that a fleet should be built such that the marginal utility of all possible investments is equal, i. e. adding/subtracting 100t of armor (if possible) has the same use as adding/subtracting 100t of weapons, engineering compartments or any other possible (and used) ship component. If this was not the case then a better ship could be designed by adding one type of components at the expense of others. Let du/dh_e be the marginal utility with respect to engine hull space, du/dh_w be the marginal utility with respect to weapon platform hulls pace (the “d” means a derivate, so that da/db is the derivate of a with respect to b). Since all marginal utilities must be the same we know that du/dh_w = du/dh_e. We can also write du/dh_w = dv/dh_e * du/dv (i. e. use a chain rule), where v is the speed. This means we can rewrite the marginal utility with respect to engine hull space as the product of the marginal utility with respect to speed times the increase in speed that an increase in hull space offers. And now comes the trick: If we assume an increase in engine technology, the marginal utility of a missile launcher does not change, so du/dh_w is a constant. The marginal use of engine-space was equal to this constant before the new engine tech came around, and it must be equal to this constant afterwards, as otherwise we would use a different proportion of space for engines. Thus we know that the marginal utility of engine-space before and after the tech change is equal: du/dh_{e,before}= du/dh_{e,after}. Or, using the identity form above: dv/dh_{e,before} * du/dv_{before} = dv/dh_{e,after} * du/dv_{after}. A new engine tech means the speed gained for adding engines becomes larger, say by a factor x, so: dv/dh_{e,after}= x* dv/dh_{e,before}. Furthermore we know that the speed is proportional to the power of the engine. We can rearrange and find that du/dv must be proportional to 1/v – i. e. a hyperbolic function. Integrating this expression yields the claimed logarithmic utility of speed. We can thus turn the argument backwards, and interfere that if the utility of speed is not logarithmic, it is not an optimal strategy to devote a fixed amount of hull space to engines for different technology levels.
One caveat: There might well be synergy effects. For instance with beam ships the marginal utility of adding another beam weapon might well depend on the speed that this ship achieves, so the change in engine technology could have a cross-impact.
(*3): The Lanchester laws might not be entirely justified here. Not only is each ship a “shooter”, and a “target”, every ship is also a “defender” in the form of point-defence weapons, adding a third dimension. (I am making the simplifying assumption that every ship is a miniature of the fleet, which makes it more convenient to calculate. It does not matter though if separate ships are used as PD-providers or offensive-launchers, as long as they move together). Thus I would expect a larger exponent than “2”. This would increase the usefulness of the modular design.
-
Your analysis seems to be mostly correct. I would like to add that if you are using cloak strategies, modular design may require that you research minimum cloak size.
But the payoff will be good! Each module becomes that much "smaller" in an all-cloak fleet. At high tech, you might even hit missile-sized, while missile-signature battleships will likely never be possible.
-
Good analysis, Theo.
One point not addressed in your discussion of Afterburners is the Hyperdrive afterburner.
Hyperdrive engines offer 10x the speed (while operating outside a sun's gravity well), at a cost (varying by tech research) of between 2x and 1x the mass... and by testing I have found that even a single Hyperdrive engine is sufficient to gain that 10x multiplier for the entire towed assembly.
Check the speed, nearly 0.5c :
(http://i11.photobucket.com/albums/a155/blueemu/Eyeball.jpg)
The speed is so high that it looks like a mis-print! ;D
With normal monolithic designs, this "single Hyper engine sufficiency" property is no advantage, since a ship can mount only one type of engine anyway, so with a normal ship the choice is whether to use all normal engines (at 250 tons each) or all Hyperdrive engines (at perhaps 375 tons each).
A modular ship can use the lighter normal engines for its Main Drive module, and carry a FAC hangar (1050 tons dead-weight) holding a 1000-ton Hyperdrive-equipped FAC which can boost the entire towed assembly up to 10x the normal speed... only while operating outside a sun's gravity well, of course. If it is carrying more than (let's say...) 2500 tons of engines, this is a net gain in capability.
Regarding construction... another minor point is that you will be able to build four 10,000-ton modules much earlier in the game than a 40,000-ton ship; since it takes many years to expand the dockyard to that point.
-
Good analysis, Theo.
One point not addressed in your discussion of Afterburners is the Hyperdrive afterburner.
Hyperdrive engines offer 10x the speed (while operating outside a sun's gravity well), at a cost (varying by tech research) of between 2x and 1x the mass. . . and by testing I have found that even a single Hyperdrive engine is sufficient to gain that 10x multiplier for the entire towed assembly.
Check the speed, nearly 0. 5c :
(http://hxxp: i11. photobucket. com/albums/a155/blueemu/Eyeball. jpg)
The speed is so high that it looks like a mis-print! ;D
With normal monolithic designs, this "single Hyper engine sufficiency" property is no advantage, since a ship can mount only one type of engine anyway, so with a normal ship the choice is whether to use all normal engines (at 250 tons each) or all Hyperdrive engines (at perhaps 375 tons each).
A modular ship can use the lighter normal engines for its Main Drive module, and carry a FAC hangar (1050 tons dead-weight) holding a 1000-ton Hyperdrive-equipped FAC which can boost the entire towed assembly up to 10x the normal speed. . . only while operating outside a sun's gravity well, of course. If it is carrying more than (let's say. . . ) 2500 tons of engines, this is a net gain in capability.
Regarding construction. . . another minor point is that you will be able to build four 10,000-ton modules much earlier in the game than a 40,000-ton ship; since it takes many years to expand the dockyard to that point.
Glad you liked the analysis so far. Yes, I deliberately ignored the hyperdrive afterburner.
I would agree that within the frame work of the game as it is presented to us at the moment, this is unquestionably the optimal and cheapest way to achieve hyperdrive capacity (for medium to large spacecraft). I would disregard the hangar and just leave the hyperdrive module attached at all times. In "normal" mode the total weight would be the same (1000t FAC, instead of 1050t Hangar), and you gain one engine. (There is no drawback of using a hyperdrive engine in ordinary space, once you do carry it around, or am I wrong here?). Although the hyperdive burner would be more vulnerable if not stored inside the main hull. However I feel that Johan Steve will change the game to make this less viable. . .
On a side note to my above points: I have not discussed a third scenario, which I think might be somewhat optimal to the "all modular" approach and sits somewhat in the middle. Initially built integrated ships without any modularity. Then when the next generation of faster ships starts to come online, I will design "upgrade modules", which consists of a bunch of latest generation engines +tractor, which will get strapped onto the aging ship. These can be designed such that the old ship + "upgrade module" matches the speed of the latest generation ships.
The advantage over full separation of propulsion modules is that the old engines can be retained and supplemented by newer ones, rather than scrapped& rebuilt. Of course it is not quite as flexible and beautiful, and the ships will probably look pretty horrific with all the engines wielded onto the hull, but still it might give good results.
-
What about non-turreted beam weapons? those use the ship max speed as tracking speed, but if you mount them on a weapon platform atached to an engine platform, does it get the movement speed of both together as tracking speed, or keeps at 0 as that's the speed of the weapon module?
-
What about non-turreted beam weapons? those use the ship max speed as tracking speed, but if you mount them on a weapon platform atached to an engine platform, does it get the movement speed of both together as tracking speed, or keeps at 0 as that's the speed of the weapon module?
This is a good question, and ought to be tested.
Another good question is whether engineering-section requirements are linear with respect to ship size, or follow a higher power-law... does a 10,000-ton ship require twice as many engineering sections as a 5,000-ton ship to gain the same mean-time-to-failure, or more?
(There is no drawback of using a hyperdrive engine in ordinary space, once you do carry it around, or am I wrong here?).
FAC engines use 10x fuel. Of course, you don't need to use a FAC engine in that 1000-ton afterburner, but it does boost your hyperdrive speed.
-
I'm trying to maintain a fleet of modular ships, but I keep getting "ship XXX has detached from it's TG as her speed has gone down to 1km/s due to damage" for deadweight modules, everytime there is a maintenance failure.
Unless there is an option to deactivate this, I'm not going to keep on modular design due to this massive spam.
-
Odd. I've never had that happen.
What are your ship designs? Do you include one engine and one fule tank in each module? I do that so that I can regroup them if the engine module is taken out by enemy fire.
-
No, I have sitting duck weapon modules and engine modules to tow them around. Maybe I should stick always 1 engine to avoid that spam.
-
I've put engines on weapon modules and they still detaching with 1 engine, "XXX has reduced his speed to 557km/s due to damage, and detached from TG"
-
You could deactivate maintenance failures.
-
I have maintenance on, and I've never experienced this problem.
Granted, I'm not playing the most recent patch, and I don't spend a lot of time orbiting wourlds that have no maintenance facilities... it's either deep space or home base, for me.
-
Wild Speculation:
Do the self-dumping modules have engineer sections?
If failures can't be self repaired that might be triggering some speed-comparison check, even if there shouldn't be a check for tractor locked stuff.
-
Yes, they ahve engineer sections. I'll post later the design.
NAV Satie IIA class Cruiser 8,000 tons 871 Crew 1458. 4 BP TCS 160 TH 24 EM 540
625 km/s Armour 8-35 Shields 18-300 Sensors 1/1/0/0 Damage Control Rating 6 PPV 60
Maint Life 5. 66 Years MSP 684 AFR 85% IFR 1. 2% 1YR 36 5YR 541 Max Repair 100 MSP
Magazine 776
M4 Internal Confinement Fusion Drive (1) Power 100 Fuel Use 50% Signature 24 Armour 0 Exp 5%
Fuel Capacity 50,000 Litres Range 22. 5 billion km (416 days at full power)
Epsilon R300/15 Shields (6) Total Fuel Cost 90 Litres per day
Missile Launcher S6/ROF40 (10) Missile Size 6 Rate of Fire 40
Missile Fire Control FC58-R25 (2) Range 58. 8m km Resolution 25
Active Search Sensor MR55-R50 (1) GPS 2800 Range 55. 4m km Resolution 50
ECCM-2 (2) ECM 20
This design is classed as a Military Vessel for maintenance purposes