Carrier Flak

[Furball]

I suggested a solution to the puffy ack problem in the other threads, in my opinion i think it could me made more realistic with some coding changes.

Rather than the current instantaneous puffy ack exploding in a virtual box fixed to the aircraft, there should be a time variable so that the 'box' location is based on the aircraft's course and speed 'x' amount of time ago.

'x' amount of time should be the variable changed by the distance from CV.  For example, if i am 5k from the CV, the virtual box will appear in a point in space where my aircraft was headed 5 seconds ago, 3k = 3 seconds and so on.  If i have changed course during that time the ack will be innaccurate.

If i continue straight and level at a constant speed, the 'box' should not only be on target, but i think it should get progressively smaller around the aircraft the longer it remains straight, level and constant speed, irrelevant of distance - simulating correction by the CV gunners.

In my opinion this will make it more realistic, without overcomplicating the current system by modelling each individual gun trajectory.

[moot]

Yep, that's the same thing I've been suggesting.

[SlapShot]

As I read it ...

As you fly into flak range ...

1) you are surrounded by a "flak box" and you are always in the "middle" of that "flak box" ... no matter what maneuvers you do.

2) the code randomly fires flak inside the "flak box"

3) the size of the "flak box" increases and decreases in size using ...

3a) distance from the "flak source"

3b) speed

3c) maneuvering

Once you enter the "range" your "flak box" is created and a randomizer throws flak shells into the confines of the "flak box".  The variables (3a - 3c) will adjust the size of the "flak box". As the "flak box" gets the smaller the chances of getting hit increase.

BUT ... no matter what the size of the "flak box", if the randomizer throws a shell into the box (especially in the middle) close to your plane, you will get some sort of damage and/or death.

Also, I read in another thread as to why the flak continues to fire at you even when behind mountains.

Tracking the trajectory from the gun(s) to the target in the "flak box" and determining if there are any "objects" in the way would be ... these are HT's words ... "expensive".

[moot]

Yes.. So it's basicaly that you'll be in the ships' flak bullseye (of varying densities) regardless of whether you could have completely dodged it in reality.

[SlapShot]

I suggested a solution to the puffy ack problem in the other threads, in my opinion i think it could me made more realistic with some coding changes.

Rather than the current instantaneous puffy ack exploding in a virtual box fixed to the aircraft, there should be a time variable so that the 'box' location is based on the aircraft's course and speed 'x' amount of time ago.

'x' amount of time should be the variable changed by the distance from CV.  For example, if i am 5k from the CV, the virtual box will appear in a point in space where my aircraft was headed 5 seconds ago, 3k = 3 seconds and so on.  If i have changed course during that time the ack will be innaccurate.

If i continue straight and level at a constant speed, the 'box' should not only be on target, but i think it should get progressively smaller around the aircraft the longer it remains straight, level and constant speed, irrelevant of distance - simulating correction by the CV gunners.

In my opinion this will make it more realistic, without overcomplicating the current system by modelling each individual gun trajectory.

So you are saying that the code should sample for x amount of seconds to determine direction, speed, and altitude to establish a box in front of you to lay the shells into ?

[Furball]

I have never heard an explanation why if you have just arrived near to the CV, you can get fairly close before puffy ack starts shooting at you.  

When you go to fly away, the puffy ack continues to shoot at you much further out than when it started firing at you.  If you go out of range and return again, still the ack shoots at you further away than you were earlier and not getting shot at.

This doesn't make sense to me.  The gunners should be concentrating on inbound targets which are more likely carrying nasty stuff to drop on the boat, so if anything it should be opposite.

Or is this all just my imagination?

[Furball]

So you are saying that the code should sample for x amount of seconds to determine direction, speed, and altitude to establish a box in front of you to lay the shells into ?

x = me

O = puffy

here i am flying along: -

x

In 5 seconds i will be here based on my current course/speed: -

__________________x

Puffy ack calculates this while i am here: -

x

And puts the puffy ack: -

__________________O

5 seconds after the original calculation.

But i have since turned: -

__________________O
_________x

[moot]

So you are saying that the code should sample for x amount of seconds to determine direction, speed, and altitude to establish a box in front of you to lay the shells into ?

Like it would in reality, yep.  It sounds like it's HTC's gameplay decision to not allow for that, though.  Way out at 8k, at least a few planes in the game could probably completely sidestep the widest possible wall of flak a 6-ship TG (like we have) could throw at them.

Furball, that's analogous to a TG not IDing you as enemy before a certain distance.  And then not needing to let you close enough for such an ID again before it starts firing if you get back in range.  I don't know if there's a simple/cheap enough way to code for targeting biased on inbound bandits, though.

And now that I think about it, there wouldn't be only a position extrapolation required..  There could have to be a collision calculation, since the shells are proximity fused.  Meaning that with a flak box as you and I have been suggesting, we wouldn't be hit in an evasive that'd cross  the path of the shells, since the code only extrapolates the flak box's location without "seeing" that we'd just flown through the shells' proximity radius.

[SlapShot]

Ok ... I can read that.

But, lobbing shells at airplanes back then was just using good old Kentucky windage and with that, not all gunners are going to be experts at leading the target.

So ... with that, you should be getting shells going off behind you and on the sides of you ... not just in front. If the AI gunners always lead you properly, and using your schema, it would be ridiculously easy to defeat the flak and never fly into the "flak box" in front of you.

I think that is why HT has the plane in the middle of the box ... no matter what direction it's going ... and with the "random" shots being thrown into the box, you get the explosions all around you ... not just in front of you.

I would think that the closer you get the smaller, the box should get (this is what currently happens), but the rate of random firing into the box should increase (not sure if that part is in the code) dramtically as you get closer to the target.

The increase of firing into the box should only be determined by how close you are getting to the target, and speed, and maneuvering should not have an effect on the rate of fire.

[Furball]

And now that I think about it, there wouldn't be only a position extrapolation required..  There could have to be a collision calculation, since the shells are proximity fused.  Meaning that with a flak box as you and I have been suggesting, we wouldn't be hit in an evasive that'd cross  the path of the shells, since the code only extrapolates the flak box's location without "seeing" that we'd just flown through the shells' proximity radius.

But the current system does not take into account proximity fuses - if they were, we would not be seeing the flak bursts of shells completely missing the target?

So ... with that, you should be getting shells going off behind you and on the sides of you ... not just in front. If the AI gunners always lead you properly, and using your schema, it would be ridiculously easy to defeat the flak and never fly into the "flak box" in front of you.

Not necessarily, at short range the time variable would mean that it would be impossible to escape from the box in time because the shells are spending 'less time in air' between the shot calculation and then exploding round the aircraft.  Would probably need some tweaking but i think it could work.

Not sure about the rate of fire thing, because the amount of guns is always the same, or did they use different guns with different ranges?

[SlapShot]

But the current system does not take into account proximity fuses - if they were, we would not be seeing the flak bursts of shells completely missing the target?


Not necessarily, at short range the time variable would mean that it would be impossible to escape from the box in time because the shells are spending 'less time in air' between the shot calculation and then exploding round the aircraft.  Would probably need some tweaking but i think it could work.

Not sure about the rate of fire thing, because the amount of guns is always the same, or did they use different guns with different ranges?

Wait ... didn't flak shells with proximity fuses also detonate at some altitude so that they didn't rain down unexploded ?

The rate of fire would only simulate a priority target ... I would think that as a plane got real close to a CV group, most guns would train themselves on that target.

[moot]

I would think that as a plane got real close to a CV group, most guns would train themselves on that target.

It doesn't always do that.

So ... with that, you should be getting shells going off behind you and on the sides of you ... not just in front. If the AI gunners always lead you properly, and using your schema, it would be ridiculously easy to defeat the flak and never fly into the "flak box" in front of you.

Well, it's not about easy or hard.  It's about it being realistic..  Does it get better than having a realisticaly behaving flak umbrella?  Does it have any downsides?

I think that is why HT has the plane in the middle of the box ... no matter what direction it's going ... and with the "random" shots being thrown into the box, you get the explosions all around you ... not just in front of you.

I'm not, and I don't think Furball is either, suggesting that the flak aim only ahead of the target.  We're saying the flak box as it is ought to be centered not on the plane, but on where the plane would have been X time after the 5" salvo were fired, based on its velocity at the time the salvo was fired.  Basicaly an extrapolation of its position substituting for the actual ballistics being modeled.  As I mentionned though, this would effectively ignore the proximity fuse since the plane could fly through the shells' trajectory and not trigger any of them.  Unless collision detection was calculated between the shells' and the target's trajectories, which is probably as likely to be too expensive.  Like the terrain collision calculations are, to tell the flak whether the target's occluded.

I would think that the closer you get the smaller, the box should get (this is what currently happens), but the rate of random firing into the box should increase (not sure if that part is in the code) dramtically as you get closer to the target.

The increase of firing into the box should only be determined by how close you are getting to the target, and speed, and maneuvering should not have an effect on the rate of fire.

You mean like a doppler sort of thing?

But the current system does not take into account proximity fuses - if they were, we would not be seeing the flak bursts of shells completely missing the target?

Well, they're prox fuses, so we can't be asking for a changes to the flak model that wouldn't behave like them.  That's what I mean   I'm not sure what you mean, but the flak bursts that miss are (I guess) simulating dispersion and human error..