Apollo, inspired by the KIROV and SS-N-19 antiship missile?

Weird Harold wrote:

BobG wrote:I wasn't suggesting that the RDs act as anything more that additional sensors. They could provide a refined feed to one or more Apollos. Note that the data could either be transmitted via laser to the Apollo missiles, and given beam divergence for comm lasers, it would probably be visible to multiple Apollos. The feed it transmits back to the command ship would also pass through some of the Apollo nodes, assuming any of them were in a straight line to the launcher.

Wouldn't that require all of the Apollos to be using the same encryption or at least recognize the same encryption, which would theoretically leave them open to hacking?

The main objection to using RDs directly communicating with Apollo ACMs is the speed disparity. If you've got time to get RDs in position to be useful, you've got time to use the ship's computers to compile the data and program it into the ACMs before launch. If you really need real-time updates, it isn't likely an RD will have had time to get in position.

If it was a snap engagement you wouldn't have time to get a recon drone in possition. (Like having a force pop out of hyper within MDM range of you).

But most combat, even with MDMs starts out with the two forces beyond weapons range of each other. There's time while they close to effective combat range to advance recon drones to get a closer look at the enemy (and to push drones out to sweep the flanks and cover the rear to protect against surprises)


So in many engagements there are clouds of RDs hovering near the enemy formation. (Which we've already seen used to FTL info about the enemies ECM and anti-missile tactics back to the Mantie fleet) But when this tactic used by smaller ships that only cuts half the com lag out; the updated info still has to go back to missile in-flight at light-speed. Or it has to be loaded into the next salvo - where it will be as much as 3 to 9 minutes out of date by the time they reach laser head range.


There probably are problems with trying to get RDs to push their observation directly to Apollo Control Missiles; but having the RDs in place to get that intel often isn't one of them.

Annachie wrote:Come onRFC, one of the first rules of weapon design has to be countering whatever you design. Surely the Manties alteady have an FTL jammer that they can signal through waiting in the wings.

Um. To the best of my knowledge, nobody's come up with a really good counter for a 16"/50 gun . . . except to devise weapons which outrange it so much you don't have to come into its reach . . . .

Sometimes there simply isn't a "counter" for a weapon and you just have to go ahead and accept that because if you don't equip your ships with it, the other side darned well will, and then where will you be?

runsforcelery wrote:

Annachie wrote:Come onRFC, one of the first rules of weapon design has to be countering whatever you design. Surely the Manties alteady have an FTL jammer that they can signal through waiting in the wings.

Um. To the best of my knowledge, nobody's come up with a really good counter for a 16"/50 gun . . . except to devise weapons which outrange it so much you don't have to come into its reach . . . .

Sometimes there simply isn't a "counter" for a weapon and you just have to go ahead and accept that because if you don't equip your ships with it, the other side darned well will, and then where will you be?

Well, not really a counter, but the Montana class was designed with armor to stand up to its own guns, for a while.

And arguably in some tactical situations smoke generators and radar jammers could combine to be an effective counter (against their fire control at least).


But I take your broader point that sometimes effective counters don't exist, or lag behind the offensive technology. And people rarely (if ever) hold back a new weapon just because they're still trying to invent a counter for it.

Mk-16s kicked butt at Saltash without benefit of FTL control links because Abby Hearnes had hacked the computers of Adm Bing's captured BCs to access their files on ECM systems and she was using the trick she had developed at Monica to use the sensors and FTL comm on recon drones to get near real time data on ECM. This cut the control loop in half which was sufficient when the SLN BC's ECM was essentially a homing beacon for her missiles.

Eventually, someone in the SLN might grow up, grow a brain, and even grow a pair of testicles or ovaries (whichever is gender appropriate). At that point, reducing the FC control lag time by 1/64 rather than 1/2 would be really useful.

I concede that installing an Apollo grade AI on a recon drone might be an additional expense. However; the FTL comm already employed by recon drones and Apollo control missiles is probably more expensive. The Apollo AI also seems to be cheap enough to be used in a one shot disposable missile.

Unless you have enough recon drones to provide FTL comm for every cluster of 8 attack missiles, you need a recon drone with enough FTL bandwidth to control more missiles. Of course assuming that a Rolland needs 3 recon/control drones to control a double stack salvo of 24 and a Saggy C needs to have 10 recon drones to control a double stack salvo of 80 and a Nike needs somewhere around 19 recon drones to control a triple stack salvo of 150 missiles is not absurd.

JohnRoth wrote:

namelessfly wrote:
Now the next question, given the inability of recn drones to control missiles at Saltash, will the RMN develop a forward controller drone? Think of it as an upsized recon drone with an normal, 10,000 gee recon drone drive and endurance but with an Apollo Control Missile's battle
management computer, FTL comm, and light speed data links to control the missile salvo. You could then get near Apollo performance from Mk-16s.

I'm not sure you need all of that. If you're looking for a forward controller for Mark-16s, then all you really need is the FTL com plus the telemetry and control channels. The Mark-16's range is long, but it's still short enough that, with FTL communications, the fire control on the ships ought to be adequate. Putting a tactical AI in the drone would increase the size and expense, and at the same time limit it to controlling a small number of missiles in the salvo. It doesn't seem to me that the forward control AI is worth it.

The other issue is: why bother? The problem at Saltash wasn't a matter of controlling what the missiles were supposed to do: take out those battlecruisers. It was that they couldn't be aborted in time to let the battlecruisers surrender. That's partially a doctrine issue --- commodore whats-his-name didn't allow enough time between salvos for the opposing commander to surrender. If he had, they could probably have aborted the last two, and possibly three, waves.

Of course sub caliber sabot rounds combined with smooth bore barrel sleeves can push the range of a 16" gun out to about 200 kilometers. Active guidance would make them devastating.

A ram augmented rocket projectile for 16" guns could push the range out much further.

I seem to recall that the USN developed a single, 8" gun mount that could be fitted to some destroyers.

A similar, single 16" gun mount could fit on a 25,000 ton cruiser.

However; a 16" or even an 8" Verticle Gun System with ram augmented rocket projectile could fit on a DD or perhaps even a submarine (which would have to partially surface to fire).

I like the idea of an OHIO class sub being able to sneak in to launch about 1,000 such projectiles from may be 500 miles away then sneak away.

runsforcelery wrote:

Annachie wrote:Come onRFC, one of the first rules of weapon design has to be countering whatever you design. Surely the Manties alteady have an FTL jammer that they can signal through waiting in the wings.

Um. To the best of my knowledge, nobody's come up with a really good counter for a 16"/50 gun . . . except to devise weapons which outrange it so much you don't have to come into its reach . . . .

Sometimes there simply isn't a "counter" for a weapon and you just have to go ahead and accept that because if you don't equip your ships with it, the other side darned well will, and then where will you be?

I wrote:

I wasn't suggesting that the RDs act as anything more that additional sensors. They could provide a refined feed to one or more Apollos. Note that the data could either be transmitted via laser to the Apollo missiles, and given beam divergence for comm lasers, it would probably be visible to multiple Apollos. The feed it transmits back to the command ship would also pass through some of the Apollo nodes, assuming any of them were in a straight line to the launcher.

Weird Harold replied:

Wouldn't that require all of the Apollos to be using the same encryption or at least recognize the same encryption, which would theoretically leave them open to hacking?

No. We can handle that today. Load a different encryption key into each RD at launch, and load the list into each missile. You can generate a key that cannot be cracked in a hour or two, surely?

The main objection to using RDs directly communicating with Apollo ACMs is the speed disparity. If you've got time to get RDs in position to be useful, you've got time to use the ship's computers to compile the data and program it into the ACMs before launch. If you really need real-time updates, it isn't likely an RD will have had time to get in position.

Most (but not all) engagements begin with detection well beyond missile range. In almost all the recent engagements with the Sollies, the RDs have had plenty of time to get in place.

As for why you want more real-time info, recall in Saltash that the ships were 2 light-minutes downrange. If a Sollie ship changed it's ECM parameters, or manuevered and released a decoy, the inbound missiles would have to work through that by observation. The local RDs would have more accurate data which they could update in real time.

I thought I recalled a comment that the sensor take from an Apollo pod used as an "advanced scout" for a missile swarm was actually better than a single RD, but it wasn't where I expected it to be. I may have imagined that comment.

Regardless, the simulation Adm Gold Peak ran in Storm From The Shadows suggests that the sensors of eight missiles are as good as the sensors of one RD.

I have to disagree, both in terms of light-speed delay in data and in visibility. The simulation she ran was based on the assumption that RDs could not reach the target in time to be useful.

Now using a Hermes Buoy where the range is greater than the FTL comm of an ACM can handle makes sense -- if you happen to have one in the area. I'm not sure that developing a Hermes type drone or control missile would be worthwhile. I can't see missile combat routinely extending to ranges where it would be necessary. System defense systems would make use of stationary relays like the Hermes Buoy, but making a mobile hermes-clone for offensive work seems like a solution looking for a problem.

Again, my intent was not to have the RDs act as Hermes buoys. Look at the geometry. An RD is transmitting a data stream to it's launching ship, and the attack missiles are on that path (within a couple of degrees, anyway). We know that grav pulses are detectable along that path, because Terekov was concerned about it when he attacked the pair of ex-Peep ships. As long as the data streams are available to the missiles, why not make them available as tactical information on the targets? The only concern I have in that regard is whether the Apollo control missiles can handle that many simultaneous grav pulse data streams.

Even that can be handled by simultaneously streaming the data by laser to one of the Apollo missiles. With beam divergence a function of the inverse of the frequency, the (presumably UV) laser would probably be capable of transmitting to multiple missiles, who would dutifully share the data. As for Mk 16s, if they were in the cone of the laser comm, they could individually utilize the data.

Again, I'm not talking about command and control. I am talking about the RDs providing another, far more accurate, sensor input to the missiles. And one that improves in real-time as the missiles approach the target. Let the missiles make decisions, based on the more accurate data passed to them.

This would not provide the capability of a full-up Apollo system, because the loop includes SD fire control computers to refine the data and provide individual commands to each group of Apollo missiles. This would, however, provide a real-time sensor stream to each missile that could receive it.

If I wanted to include some sort of control component in the RDs, I would keep it very simple, because it is possible that only some of the missiles would receive it - although an Apollo strike would prove redundancy in that case. I could see transmitting a command like the preloaded "AQ37" subprogram used in Thimble, or possibly a command to abort. And yes, you would definitely have multiple levels of encryption on that capability.

-- Bob G

Annachie wrote:Come onRFC, one of the first rules of weapon design has to be countering whatever you design. Surely the Manties alteady have an FTL jammer that they can signal through waiting in the wings.

Ah... What counter to nuclear weapons have we had for the last 60-odd years? Other than MAD, and I don't think that is a counter.

-- Bob G

BobG wrote:No. We can handle that today. Load a different encryption key into each RD at launch, and load the list into each missile. You can generate a key that cannot be cracked in a hour or two, surely?

Every encryption key you upload to an ACM is using space that could be used for attack profiles.

They obviously do something along those lines so that any ship can use the take from any RD, but ships have a LOT more memory and computing capacity than ACMs

BobG wrote:I have to disagree, both in terms of light-speed delay in data and in visibility. The simulation she ran was based on the assumption that RDs could not reach the target in time to be useful.

Which is precisely the point; relying on circumstances and equipment that might not apply when the balloon goes up is not the wisest choice.

BobG wrote:Again, my intent was not to have the RDs act as Hermes buoys. Look at the geometry.

Again, you're looking to enhance capabilities within a limited tactical geometry. Anything outside of that specific geometry -- such as an RD on the fringes of the "RD Shell" would be useless. Within the limited geometry you assume, you could, marginally, enhance tactical data to the missiles -- with appropriate trade-offs to add necessary receivers/transmitters/computer programming without increasing size of RD or ACM.

BobG wrote:As long as the data streams are available to the missiles, why not make them available as tactical information on the targets? The only concern I have in that regard is whether the Apollo control missiles can handle that many simultaneous grav pulse data streams.

The ACMs probably don't have more than one Grav Pulse channel -- that's all they need to communicate with the controlling ship and they're close enough to cross-talk with other ACMs via whisker lasers.

BobG wrote:Weird Harold Wrote
...but making a mobile hermes-clone for offensive work seems like a solution looking for a problem.


Again, my intent was not to have the RDs act as Hermes buoys.

I realize that wasn't your intent. "A mobile Hermes Clone" was my suggestion of a better use of technology -- if the range/accuracy of Apollo absolutely has to be extended; which IMHO, it doesn't.

Creating an ACM for ACMs that can relay FTL fire control and tactical information to multiple ACMs would double (at least) effective Apollo ranges. Since it wouldn't need to talk to individual attack missiles it would not add a great deal of complexity to make it able to talk to RDs if any are in position to help.

That would still be a case of creating a solution to a problem that won't come up very often. How much magazine space do you allocate to communications extenders you aren't going to need more than once a career?

As Michelle noted during that long range simulation, they haven't even started to crack all of the possibilities of Apollo; and that is without extending the range or shortening the C3I loop.

Weird Harold wrote:Every encryption key you upload to an ACM is using space that could be used for attack profiles.

You can fit a lot of 256 bit AES keys in a couple of exabytes of memory. And brute forcing a 256 bit AES key would generate a couple of megatons worth of heat and take too long even if you assume absurd increases in computer speed.

kzt wrote:

Weird Harold wrote:Every encryption key you upload to an ACM is using space that could be used for attack profiles.

You can fit a lot of 256 bit AES keys in a couple of exabytes of memory. And brute forcing a 256 bit AES key would generate a couple of megatons worth of heat and take too long even if you assume absurd increases in computer speed.

I didn't say it would take a LOT of space, just that encryption keys for drones would take space that could be used for other things. You young whippersnappers don't think in terms of efficient use of memory like us old 8-bit programmers.