Newtonian Aurora

[chrislocke2000]

By five seconds, it is now 300m from its projected non-acceleration point. It could also decelerate instead and be 300m behind where it would be without acceleration.

Whilst I know you are not dealing with facing it strikes me that any ship that wants to decelerate instead is going to need to spend some time flipping over and realiging itself before actually starting to decelerate. I'm not sure how fast one could expect a ship to flip over but it would feel right to me that, when dealing with relatively close combat - say 10 light seconds or less, then a target ships only real option is to change levels of acceleration or cease to accelerate. Similarly it would be constrained over the level of movement it could achieve on different axis of movement as well. This would therefore reduce the number of locations you would possibly need to shoot at.

[Steve Walmsley (OP)]

I just realised the targeting is more complex than I thought because the railgun projectile will have the momentum of the firing ship as well as its own velocity, which complicates the calculations. Time to learn some new maths I think

Steve

[LoSboccacc]

given the combination of ship speed and projectile speeds and enemy speeds, fire control will have an hard time to find firing solutions and the correct angle of lead to shoot at.

[bean]

Yes, the math is somewhat complicated.  However, its in my spreadsheet, and I'll post a copy later.

[Yonder]

1) Player specifies the parameters for the firing control using three checkboxes: Allow for possible Accel, Allow for possible decel, Allow for course change.
2) Aurora calculates the area in square meters, or line in meters if no course change is specified, or dot if no checkbox is checked, covered by that firing solution, and selects a random point within it (or along it).
3) The exact coordinates of that point are recorded, down to 0.1 meters.
4) Based on the speed of the projectile, the exact time of arrival (within 0.0001 seconds) at that point is recorded.
5) At the moment in time the projectile reaches the specified point, the location of the ship is checked to see if the location of the shot lies within the area of the ship.
6) Because the exact point in time will be partway through a sub-pulse and resolution of this will take place after movement, the location of the ship at the exact point in time will be calculated based on its heading and speed during the sub-pulse.

This means that a shot could actually miss even if the bearing would mean the shot would hit the target ship a fraction of a second later. However, because we are using an area rather than a volume, you have a higher chance to hit than you should have which compensates for this possibility. I haven't tested (or even coded) this yet but this is looking the most likely at the moment, unless someone comes up with a reason this won't work, which is entirely possible . This avoids tracking individual projectiles on the map but also excludes the chance of hitting something else. I could also check any other nearby ships to see if they are in the target location instead, although this is extremely unlikely and may not be worth it.

That sounds like a great way to calculate Meson hits, because them doing damage at a single point without passing through the space before or after that point seems to be how you've fluffed their ability to bypass armor, but for slugs, particle beams, lasers, etc, I would try to go for a compromise between that and modelling their trajectory for the entire journey. Maybe find their exact position half a second before expected impact, and half a second after target impact, and modelling them fully along that line.

Actually, instead of modelling a constant time before and after the impact point, you'd probably want to model the necessary time based on flight time of the projectile and the acceleration of the target, to eliminate the possibility of a ship simply accelerating towards their enemy with the knowledge that their bullets would all blink in behind them as long as he moved fast enough. If you just said "half a second on either side of impact time" that would work close in, but for really long range shots the enemy may be able to move in before the "projectile existence point".

Obviously that's more of an issue with a railgun than it is with a laser.

Their are two cases that I could still see as possible hangups with even the longer period of projectile modelling:
The possibility of putting up clouds of flak to, for example, shoot down missiles that you don't know are their but might be. This could fixed simply enough if "shrapnel clouds"--unlike projectiles--are modeled throughout the entirety of their trajectory (or at least until they disperse past a critical threshold.
The last one is the possibility of trying to destroy kinetic projectiles before they hit you, which may be important considering how much damage they can do. Other kinetic projectiles and beams would probably be useless for this because of targeting, but low yield missiles may not be.

If you see his muzzle flashes and know how fast his bullets are (which you may or may not) then you know the general place he is going to be shooting at to hit you. That means you also know about where his bullets will be along their entire path. Which means you could put some nuclear explosions along that path to try to vaporize those projectiles.

[LoSboccacc]

on a slug based space warfare, deflection chaffs would be of extreme importance. it require far less energy to deflect a projectile just enough than to resist it or to destroy it.

a wedged slug, smaller and of similar speed, could intercept the enemy shoot halfway. it has to deviate it of just some deciradian, after all.

[Yonder]

on a slug based space warfare, deflection chaffs would be of extreme importance. it require far less energy to deflect a projectile just enough than to resist it or to destroy it.

a wedged slug, smaller and of similar speed, could intercept the enemy shoot halfway. it has to deviate it of just some deciradian, after all.

Yeah, but that only works if you either have very, very dense chaff clouds (and if you are able to put up that much projectile mass on the defense, why can't your opponent due so on offense?) or you have to actually be able to see these little 1kg slugs coming, aim at them, and shoot at them, and I'm assuming that's impractical at most velocities slug could be coming at.

Now that first criticism works for my proposed idea as well, do you really have the ability to spend a nuclear missile for every  salvo your enemy fires at you, if the answer is yes, is that really the most efficient use of your nuclear missiles? On the other hand, you may not have enough to stop every salvo, but if you can determine which salvos are the ones that have the highest chance to hit you, that may be enough. If you spend 5 nuclear missiles to live three minutes longer and fire another 35 missiles at your opponent than that was a good use of your resources.

Still, I have no idea whether it's a plausible scenario, it was just the only scenario I could think of which would be ruined by "teleporting bullets", so I thought I'd bring it up for discussion.

[Antagonist]

I support trying to find a closed form instead of simulated way of detecting slug hits.  Tracking individual slugs would be adding yet another performance hit on an already loaded combat engine.

One possibility though might be a kind of binary search... aka calculate the vector of your shot.  Let time pass till it hits the half-way mark, recalculate time of impact and where in the new area of the ship the vector will strike.  Let time pass till a subpulse around halfway of flightime, repeat till the time increments is 5 secs or less, then perform final calculation.  If at any step the projectile is well far enough out of the hit area, toss it and mark it a miss, even if the miss is actually only reported later, but no need for further tracking.

This kind of comprimise might allow higher accuracy in simulation compared to the suggested endpoint calculation, without adding TOO much overhead... (handful of subpulses are calculated versus position update every subpulse).  Of course, the ideal would still be a calculate-once form as Steve suggests, but it should be tested.

As for detecting the projectile... I find that unlikely with Aurora tech.  If its unguided it will emit no thermals, and even if it is guided thermals can't lock a targeting solution.  It has no EM to speak of and its mass and thus gravity distortion is negligible compared to even the smallest missiles.  It IS possible to detect the firing of a mass driver realistically, considering the huge amount of magnetic forces used to accelerate a slug, but I'm unsure whether such a detectable EM pulse is implemented. (Might be fun for a 'oh smeg' moment?  It will however destroy stealth for attacking ships)  Even if the shot launch was detected however, I'm unsure that enough resolution is possible to determine the exact vector of the slug, though it might provide an ETA (if the velocity of the slug is known, either prior engagements or a guess from the MJ of the shot.)  Such a warning could be useful for saving fuel with evasive maneuvers, since you can coast until under fire.  Then again, much less useful against lasers.  Your warning of a laser attack IS the laser striking your hull.

[Yonder]

Some type of huge shield is possible, although it would have to be truly gargantuan to resist very high speed projectiles or close-range nuclear detonations. Perhaps something planetary-based might be possible. I haven't given this area a lot of thought so far.

So I was thinking about this and I thought of two different types of shield to protect against kinetic (and possibly other?) defenses.

These were my goals for the defense:

• Provide some sort of defense that would protect slow things that can't dodge (planets, moons, shipyards) from instant and unstoppable death in a universe where an average ship (like the Daring) does enough damage on impact to match the explosion of every single one of the nuclear weapons currently on earth going off simultaneously. One thousand times...
• Not make such shields invulnerable (especially for shipyards, orbital habitats, or anything smaller).
• Have some sort of plausible-ish handwavium explanation, hopefully.

So what we want is something that protects against higher energy/velocity impacts more than those of smaller impacts. We want to make a planet relatively safe from genocide asteroid strikes, but not safe from a low-yield planetary bombardment. If this shield is knocked out by a low-yield planetary bombardment from orbit, and the planet is then genocided by an asteroid attack, that's ok. There was some sort of orbit battle that you lost, and the planet was destroyed, totally different from a small invisible object moving at relativistic speeds killing you out of nowhere.

And if a hidden foe is still sniping you from the outskirts of the solar system between the Uber shield taking the high energy hits, and your normal shield and armor of the PDCs taking the lower yield hits, hopefully you'll at least have time to look or the attacker, or evacuate, or something before the kill strike. Anything that feels a little more fair to the player.

Not only must it be more effective at blocking the higher energy strikes, but it should also take less damage from the higher energy strikes. It has to be handwaved as transmitting that energy somewhere else, if an asteroid causes the shield a million times more damage than a shell it's still the best weapon, and we are trying to de-incentivise those genocidal weapons.

Idea 1:
The best way to avoid taking damage from being hit by something is to not be hit by something. Now these things we're worried about can't dodge, and the faster the projectile is going the further out you need to be to deflect it... How about you just don't get hit by it. Instead of deflecting it spatially deflect it into hyperspace. It'll pop out of space when it hits your shield, and pop back into space on the other side of the shield.
Mechanics: The shield senses the warped spatial time of relativistic movement. Maybe it starts out at a 20% chance at warping things moving 1% of c (3000 km/s) and goes up from there, I don't know. The total energy each deflection takes is proportional to the amount of time the object needs to be warped times it's mass, ie the faster the object the less time it needs to be warped and the cheaper warping it is, but you can't just send a bunch of bb bullets either.
This shield could be an installation like the Planetary Observatories, one that is very expensive and takes a lot of personnel to run, so you can't just spam them on defensive outposts everywhere. Maybe they protect orbiting shipyards and orbital habitats, but not orbiting ships, or maybe there is also a (very very large, possibly less effective) component one so you can put it on Orbital Habitats, and you could add the same thing to shipyards somehow.
There could be some research lines for them "Warp Chance", "Warp Power per Second", "Recharge Speed", and "Capacitor Size per Facility" to increase the likelihood of blocking attacks and decrease the energy cost of doing so.

I need to do a little more math to vet whether my second idea may work.

[Yonder]

(if the velocity of the slug is known, either prior engagements or a guess from the MJ of the shot.)

That is probably how you'd have to estimate that, but keep in mind that you're only going to see the MJs (or a portion of them) that were wasted. The more efficient the enemy's railgun is the less MJ you'll see for an equivalent shot.

On the other hand, once (if?) you see a shot whizzing by or hitting a friend, if you can extrapolate from that the velocity and mass of the slug, you then have a very, very good idea of how efficient their railguns are.

[Yonder]

This is sort of a confusing idea, I hope that I explain it reasonably.

Idea 2: Another way to go would be some sort of shield that wasn't based on the kinetic energy of a strike, but merely its momentum. I'm not as sure about the mechanics of this one, but I like the idea because I think it would scale naturally in that you could apply the mechanics to ships or planets and it would naturally be less effective on ships.
If we require conservation of energy and momentum, but handwave everything else, then a kinetic round that hits your shield could be absorbed with a burst of energy and a shift in the momentum of the ship. Let’s ignore the energy for now, maybe it's expelled at 100% efficiency, maybe not. The momentum change would be applied to the ship over a short period of time (extended by research) to get the total acceleration. Maybe the device has a maximum acceleration tolerance, and anything that goes over that starts damaging the device or other parts of the ship. Maybe the device expels momentum up to its maximum acceleration (venting off the kinetic energy from the slowdown) but after that doesn’t affect the projectile’s speed anymore.

Lets take a look at the Daring impact again. We'll say it's empty after all the thrusting, so the mass is 6,873 tons and it's moving at 80,366 km/s. Lets look at two possible collision targets, the first is a large capital ship at 45k tons. The next is the moon, at 7.348E19 tons. That's a change in velocity of 12274k km/s for the capital ship, and 7.517E-9 m/s for the moon. If the device changes velocity smoothly over the course of a second that's also their acceleration. Obviously the capital ship is dead, which is what we want, and the Moon’s acceleration is a good ballpark number for the Earth Acceleration of an example acceleration that we want the device to be able to handle just fine.

Now lets do an example of something small that we want to hurt a ship, and see if it would still hurt the ship if it had this device (IE, would the acceleration be over that 8E-9 m/s^2 that we are saying didn't break the moon’s version.)
Let’s say a 1kg shell from the Daring hits our capital ship on its way in. The shell is also going 80,366 km/s. Change in velocity to the capital ship would be 1.79 m/s. A one second transition period gives a 1.79 m/s² acceleration, much much higher than the earlier acceleration to the moon, so that’s good. For a less ridiculous impact lets say that same projectile hits at only 40km/s, that leads to an acceleration of 8.89E-4 m/s². That’s still a lot higher than that the 8E-9 from earlier. Something in between those, 1E-7, 1E-6, is probably a good starting point for a closer look at how the mechanics of this would work..

Lastly for this method I would say that multiple hits at once should all add their accelerations together, and if the time interval gets large enough (say 10 seconds) then the earlier accelerations should still be counted against the device if later objects hit during the interval.

[LoSboccacc]

how about short range melting of slugs with lasers? this could reduce damage instead of negating.

also, heating only one part of the slug may very well change its trajectory, like how laser propulsion would work (ablation, see http://en.wikipedia.org/wiki/Laser_propulsion#Ablative_laser_propulsion).

by the way, current tanks defends from kinetic weapons by explosive strap on. Reactive armor may work as well in this context.

[UnLimiTeD]

Reactive Armor would be a way to decrease the force of the projectile by spreading the damage over a bigger patch of armor, but it's only a benefit if you can prevent the projectile from breaching into the inside, which will be pretty hard unless you also have shields and are not flying in the direction of the enemy.
Though Steve has repeatedly shown his discontent for different armor types by ignoring such suggestions^^.

[wedgebert]

Reactive armor tends to work by disrupting the shaped charge and subsequent cone of molten metal that makes up armor piercing weaponry these days.  Against a small hunk of iron, it's not going to have any noticable effect.

[sloanjh]

And the reason your math was off was because it looks like you were using the acceleration to calculate the velocity at each second, and assuming that velocity stayed constant over the entire second.

That is how it works in the game, which I thought I had mentioned somewhere in the thread but I probably haven't . I could change it to a constant accel, rather than accel before movement, but it makes things harder to model, especially for interceptions, and for players to visualise. Overall velocity increase is the same either way.

It's actually not that hard to model constant acceleration - you simply have to take the average of the initial and final V for each time step to give the average velocity for that time step.  So for your 20 m/s^2 (note the units: (m/s)/s ) example accelerating for 3 seconds, for the first time step the ship has V_i = 0, V_f = 20m/s for an average velocity of 10m/s * 1 second travel = 10m.  The second time step it's got V_i = 20m/s, V_f = 40m/s for an average velocity of 30m/s * 1 second = 30 additional meters or a total of 40 meters.  For the third step it's V_i=40m/2, V_f=60m/s, average = 50m/s* 1 second = 50m, total = 90m.  Note that this also works for the full 3 second interval: V_i=0, V_f=60m/s, average = 30m/s*3seconds = 90m., and is consistent with A*t^2/2.

For me, applying dV at the beginning of the timestep causes suspension of disbelief problems - if all the dV is really happening at the beginning, then you've got infinite acceleration going on.  Plus the formula for figuring things out for extended burns (spanning multiple time steps) becomes complicated and makes the distance traveled depend on the time step.  If you're thinking that most of a ship's time will be spend "coasting", plus making max accel a meaningful performance attribute of ships, then I would recommend calculating the burn time for a dV (t=dV/A) then subtracting the "distance lost accelerating" (= t*dV/2 = dV^2/(2A)) from the formula where all the dV is applied at zero time.

John