Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[KevinHoggard]

Hey all,

  Running 4.2.3, and making an escort mission, about 30 B-26’s at 10,000 feet. I place the aimpoint and the error is typically between 7296 and 7600 I don’t know if that number is in meters or what, but the drop isn’t even close. I move the aimpoint way past the target, and they overshoot it. Other escort missions with B-17 and B-24 work pretty good at 20,000 feet.

Any suggestions what to do?

[Vampire_pilot]

Aimpoint kind of never worked as an actual precision point, that's true. It never did in any instance ever since I started using this feature some decade or two ago.

It's funny you say they overshoot? in my experience, the drop will almost always fall short of the point. Anyway, I have just gone to test a drop each time and set the point just "off" enough to make the hit go where I want it. Saves me the trouble to overthink it and works quite well.

The most useful feature of this item is the fact that it creates a guaranteed level drop from any altitude, without any diving or stupid stunts of fighter bombers.

I have a theory that plane type, weapons features and AI experience levels plays into this weird mix and this was probably coded based on some 4.09 or 4.10 basis way back when. But as I said, I never saw this one really be "accurate".

[genXgamer]

I've only used the aimpoint function to replicate scattered Japanese bombing from high altitude (20,000 feet).
When more precise level bombing is needed use the conventional method.

[KevinHoggard]

Aimpoint kind of never worked as an actual precision point, that's true. It never did in any instance ever since I started using this feature some decade or two ago.

It's funny you say they overshoot? in my experience, the drop will almost always fall short of the point. Anyway, I have just gone to test a drop each time and set the point just "off" enough to make the hit go where I want it. Saves me the trouble to overthink it and works quite well.

The most useful feature of this item is the fact that it creates a guaranteed level drop from any altitude, without any diving or stupid stunts of fighter bombers.

Yes, when I overshot the target I moved the point to compensate for initial short, I moved it way beyond the target lol
I have a theory that plane type, weapons features and AI experience levels plays into this weird mix and this was probably coded based on some 4.09 or 4.10 basis way back when. But as I said, I never saw this one really be "accurate".

[KevinHoggard]

I've only used the aimpoint function to replicate scattered Japanese bombing from high altitude (20,000 feet).
When more precise level bombing is needed use the conventional method.

But when the conventional method is used, I have B-26’s making multiple passes to drop their bombs

[Vampire_pilot]

But when the conventional method is used, I have B-26’s making multiple passes to drop their bombs

Exactly. The B-26 (and IIRC some B-25 too) are fighterbombers at heart. Otherwise they would not be able to use the ground pound cannons. They only level drop above 3000m, IIRC.  So exactly for these kind of multi role planes, the forced level bomb of aimpont is great.  You just have to set the point up in a way to get the drop hit where you want it.

[Dimlee]

My experience and observations coincide with Vampire_pilot.
I also have chosen to test and move the point (or the target if possible) to achieve acceptable accuracy.

Some more:
- When I run the same mission several times without changing Aimpoint, I see that bomb drops are random, the bombs do not hit the same places.
- Some bomb raids can be more accurate than others. One group of bombers destroys a bridge from 3,000 m while another group can't hit a small town from 2,000 m - in the same mission.

[WxTech]

I just looked over the AimpointUnit class.

Some thoughts:
- A straight line distance threshold of a mere 10,000m will execute the code. If a plane is, say, at 7,000m AGL, for a line of sight distance of 10,000m the ground distance is roughly 7,000m as well, corresponding to a look-down angle of about 45 degrees. If the plane is way upstairs at 10km, the object is directly below before any action is taken. And if the plane is higher still, the threshold distance is exceeded and nothing happens here.

- A fixed line-of-sight threshold, resulting in a longer ground distance for aircraft lower altitudes, could mean that a direction-altering waypoint establishing setup of the drop should not be placed inside said ground distance. Meaning for safety at least 10km from the target. I suspect this because the plane's heading relative to the aimpoint object is taken into account upon crossing the distance threshold. If it subsequently changes due to a waypoint causing a turn, this might induce additional error. Now, this is after just a first look at the code, and be aware always that I'm a NARP^TM (Not A Real Programmer).

- variable d16 goes toward calculating the error.
  d16 = plane speed * sqrt(plane height above object * 0.2039)
  For a height difference of 5,000m and a line of sight distance of 10,000m, the ground distance is 8,660m.
  For a height difference of 5,000m and a plane speed of 100m/s, d16 = 3,190

  error = ground distance - d16
  For a ground distance of 8,660m and d16 = 3,190
  error = 8,660 - 3,190 = 5,470

All this suggests to me that a fixed line-of-sight threshold of 10,000m is not good. It makes the error comparatively larger when the plane is at lower altitudes. And it results in activation from too close when the plane is at a high altitude. My instinct is to set the line-of-sight threshold by taking into account the height difference; the smaller this height difference the smaller the activation threshold. I took such a course for another of the C&C effects which employed a line-of-sight threshold distance.

- Variable d5 is a head scratcher, seeming to me to be incorrectly constructed. But this variable is not actually used, and so caused no harm if indeed wrong.

I don't see where the randomizing comes into it toward the end of the algorithm.

The existing code, with my notes:

Code: [Select]

public class CandC$AimpointUnit extends CandCGeneric
{
public boolean danger()
{
if(!active)
return false;
Point3d point3d = new Point3d();
Vector3d vector3d = new Vector3d();
for(java.util.Map.Entry entry = Engine.name2Actor().nextEntry(null); entry != null; entry = Engine.name2Actor().nextEntry(entry))
{
pos.getAbs(point3d);
Actor actor = (Actor)entry.getValue();
if((actor instanceof TypeBomber) || (actor instanceof TypeStormovik) && actor.getArmy() == myArmy && actor.pos.getAbsPoint().distance(point3d) < 10000D)  //10,000m seems small!
{
boolean flag = ((Maneuver)((Aircraft)actor).FM).hasBombs();
double d = Main3D.cur3D().land2D.worldOfsX() + ((Tuple3d) (point3d)).x;  //d = aimpoint object x position on map
double d1 = Main3D.cur3D().land2D.worldOfsY() + ((Tuple3d) (point3d)).y;  //d1 = aimpoint object y position on map
double d2 = World.land().HQ(((Tuple3d) (point3d)).x, ((Tuple3d) (point3d)).y);  //d2 = ground height at aimpoint object
double d3 = Main3D.cur3D().land2D.worldOfsX() + actor.pos.getAbsPoint().x;  //d3 = plane x position on map
double d4 = Main3D.cur3D().land2D.worldOfsY() + actor.pos.getAbsPoint().y;  //d4 = plane y position on map
double d5 = Main3D.cur3D().land2D.worldOfsY() + actor.pos.getAbsPoint().z;  //??? should be worldOfsZ()??? Anyway, d5 is NOT used
double d6 = actor.getSpeed(vector3d);  //d6 = plane speed m/s
double d7 = ((Maneuver)((Aircraft)actor).FM).getAltitude();  //d7 = plane height ASL
double d8 = d - d3;  //d8 = obj x - plane x = delta x
double d9 = d1 - d4;  //d9 = obj y - plane y = delta y
float f = 57.32484F * (float)Math.atan2(d9, -d8);  //f = arctan(delta y / -delta x) = hdg angle to obj
double d10 = Math.floor((int)f) - 90D;  //correct hdg angle for map east
if(d10 < 0.0D)
d10 = 360D + d10;
double d11 = (double)(-actor.pos.getAbsOrient().getYaw()) + 90D;  //d11 = plane hdg, corrected for map east
if(d11 < 0.0D)
d11 += 360D;
double d12 = d3 - d;  //d12 = plane x - obj x = delta x
double d13 = d4 - d1;  //d13 = plane y - obj y = delta y
double d14 = Math.sqrt(d13 * d13 + d12 * d12);  //d14 = gnd dist between plane and obj
double d15 = d7 - World.land().HQ(((Tuple3d) (point3d)).x, ((Tuple3d) (point3d)).y);  //d15 = plane height above obj (could be d7 -d2)
if(d15 < 0.0D)
d15 = 0.0D;
double d16 = d6 * Math.sqrt(d15 * 0.20386999845504761D);  //d16 = speed * sqrt(AGL * 0.2039); e.g., 100 * sqrt(5,000 * 0.2039) = 100 * sqrt(1,019.5) = 100 * 31.9 = 3190
if(!marked && actor == World.getPlayerAircraft() && !flag)
{
error = (float)(d14 - d16);  //error = gnd dist - d16
marked = true;
HUD.logCenter("                                                                             Bombs Gone! Aimpoint Error: " + (int)error);
}
Random random = new Random();
int i = Mission.cur().sectFile().get("Mods", "AimpointError", 300);
randomInt = random.nextInt(i);
if(Mission.cur() != null && Mission.cur().sectFile().get("Mods", "AimpointNoMark", 0) == 1)
error = 0.0F;
if(Mission.cur() != null && Mission.cur().sectFile().get("Mods", "AimpointMode", 0) != 1)
d16 += (float)randomInt + error;
if(d14 <= d16)
((Pilot)((Aircraft)actor).FM).bombsOut = true;
}
}
return true;
}

private float error;
private boolean marked;
private int randomInt;
private int maxerror;
public boolean active;

public AimpointUnit()
{
error = 0.0F;
marked = false;
randomInt = 0;
maxerror = 300;
active = true;
Timer1 = Timer2 = 1.0F;
delay = 10F;
}
}


[Vampire_pilot]

About the 10K. Keep in mind what scenarios Aimpoint is supposed to be used with.

- low flying typeBombers (below 3000m), to force them to level drop all in one go, instead of skip-bombing one by one bomb. Above 3000m, a typeBomber will simply do a level bombing run per default (if no target object is set, which you should not do with a level bomber anyway, since that B-17 will pick at the target in single bomb drops)
But so, no need for aimpoint to be used here in the first place, if the typeBomber is above 3000m- Simply set an unspecific GAttack waypoint then.

- Fighterbombers and Divebombers to drop all bombs in one go in a low level attack, instead of dropping each bomb individually and then return for the next. Splash and out.  This is a low altitude operation. Above 3000m, the type Divebomber will do a dive bomb per default. The fighterbomber will do weird shit but why set a fighterbomber for attacks that high anyway. That's wrong waypoint design.

So the 10K+ altitude with a big level bomber is no scenario you would want to use aimpoint. It is not and never was intended as a "precision bombing device"!

[WxTech]

Here's a graph of error values by A/C speed and altitude (specifically, the height difference between the aimpoint object and plane.)

There are 4 rows of data points. Each row runs almost horizontally, and from top to bottom correspond to altitudes of 1000m, 4000m, 7000m and 9000m.

The X (horizontal) axis is plane speed in m/s, with results running from 50-200m/s, or roughly 100-400 kt.

The Y (vertical) axis is the error value in meters, the range running from -4km to +9km.

These calculations were run on the assumption of initiation at the fixed 10km line-of-sight threshold distance. The error values are worse at lower altitudes and at slower speeds. Roughly, at an altitude of only 1km the error is around 8km! At an altitude of 9km and a speed about 100m/s (200 kt) the error is essentially zero. This zero error makes sense due to the ground distance being a bit over 4km and the look-down angle being roughly 60 degrees; in other words, the plane is not far from the drop point already.

What would be the rationale for such a large error at low altitude? About the only 'reason' I can come up with is less certain navigation due to the reduced area of landscape being visible, as opposed to the improved bird's eye view from high upstairs. Countering that, from a statistical viewpoint, is the variability of cloud. From high altitudes more of the troposphere is below and so there is greater chance for obscuration by cloud.

[WxTech]

I overlooked the subsequent evolution of the situation as the plane approaches the aimpoint object!

The plane will drop its load only upon meeting the condition of the ground distance becoming less than the result of a calculation based on the A/C speed and height. This means the actual error will be nowhere near the extremes of the initial values in the graph above. Such a grotesque error could occur only if the reducing ground distance were not used to re-evaluate the threshold condition for the bomb drop.

I should look at a range of situations to see what kinds of errors the algorithm will produce...

[tomoose]

WxTech;
not sure I understood all of what you stated but could ASL be a factor? Totally independent of the Aimpoint object, I noticed that the actual target altitude (i.e. above sea level) will affect the bomb drop.
i.e. if you set your bombsight for 14,000ft and your target is at 1,000ft ASL then your bomb drop will be off by that height difference.  I tested this years ago and was surprised at how accurate my bomb drop could be if I accounted for the target ASL height.

Again, not sure this even applies to the discussion but tossing it in in case it helps.

cheers,
Tomoose