LastRifleRound

I was curious if the new update strategy would push back the stated 2020 release goals

Ok, not sure where to post this as this is an A10 track, but I ran the same mission with the A10, targeting a building using a waypoint as well as the TGP. Both lead to overshooting bombs in a dive every time. I tried lasing, TMS forward long then lasing again multiple times until drop, and also just once before launch. Same result every time. Something went wrong when the drag indexes were updated, and the bombing algos weren't updated or something else is afoot. Please, in response to this, if you don't follow my procedures, it's ok to say you were able to hit using a different set of processes, but please also explain what I did wrong if you thing I SHOULD have overshot. Otherwise, there could still be a bug, and what you have discovered is a workaround, not proof that there isn't a bug. A10_Dive_issue.trk

No, OB only I'm afraid. I'm pleased with the perceived changes, just not sure what happened. I kept my tests pretty constant. I'm getting great bombing results now. It's just if hotfixes are being applied (particularly with drag indexes) us beta people need to know for testing purposes.

Does DCS use an online hotfixing system? It seems the bomb dynamics have completely changed, though no patch has dropped. Dropping 4 mk83's at once is routinely causing the bombs to collide with one another in mid-air, sometimes almost immediately, blowing my own jet out of the sky. I've dropped 4 at a time hundreds of times and never had this issue. The times when the bombs don't collide with one another. I'm getting accurate hits both level and at dive angles less than 10 degrees at so far up to 14k. This is absolutely bizarre. I've taken to dropping two pairs with 50 foot spacing and that ameliorates the issue. Does DCS employ such a system? Is it possible the drag index fixes are passed on to the software at login, not requiring the download of an actual patch? I know many titles do this, but I didn't think DCS did. I honestly don't know what else could be different.

Agreed. High alt dive in AUTO is the only safe and accurate way to deliver dumb bombs if the target has any decent point defenses.

Avro, I can't believe I didn't think of using WPDSG before to eliminate it as a variable before. I have done so with the next series of tracks and came up with what I believe is going on. Reviewing your tracks, I noticed you were bombing a completely different target in a different area. Since you and I are essentially bombing on coordinates, I figured that probably didn't matter. I noticed, you were also bombing in completely different atmo. I know I've had issues in the Viggen with barometric pressure not being read right, and I thought it was a Viggen thing, but I thought, what if it's an API thing? I have tracks 1-3, bombing in below 0. I changed to release 4 bombs from 4 pylons simultaneously, to make it VERY obvious where the center of the WEZ is over multiple drops. You can see, the drops are consistently short. There is never a single bomb beyond the target, meaning it isn't dispersion. The next two tracks, I change to July and 22 degrees. Notice the WEZ has now shifted forward. Just like it does in the Viggen. The altitude exacerbates the effect, but is not the cause. The algorithm is not compensating for atmospheric pressure correctly. The longer the bombs are in the air, the more this problem can present itself. The colder it is, the shorter the drop. The warmer, up to some minimus, the more "normal" the drop. Tracks 4 and 5 I'm able to achieve similar results to Avro's tracks. Thoughts? wpdsg_1.trk wpdsg_2.trk wpdsg_3.trk wpdsg_4.trk wpdsg_5.trk

PTRK ensures the exact center of the building, parrallax-free, is designated (can be verified as you overfly the target). Using other modalities inserts aiming errors into the equation. Since aimpoint and the bombing algorithm are closely related, not controlling for one or the other will lead to inaccurate, non-repeatable tests.

I wasn't sure if laser ranging was implemented, so I always did it this way to remove it as a variable. I don't think it matters at all. Though I haven't seen an official response on my other post, I don't think laser ranging is actually implemented yet. I've attached a track showing the JDAM going for the actual aimpoint, which is behind the building. This is the spot you guys are actually bombing if you don't update with another designate closer in. hornet jdam issue.trk

The problem here is you're using AREA track, so you are not repeating the experiment and introducing additional variables. Namely, aimpoint differences. What you are actually doing here is designating a point behind the building (you are actually picking the building on the left instead of right, so it's also a different target), not the building itself, so your aimpoint is long. I can prove this. Do the same thing, except launch a JDAMS in TOO at this aimpoint. Your JDAMS will overshoot the target quite a bit. Track attached. I took control of your track about 40 sec before delivery, achieved PTRK, then updated designation by TDC depressing (without moving the cursor, of course) with 7 seconds to go. String falls short. bomb 11k aimpoint comped.trk

Ok I see what you guys are doing differently. This is what happens when the laser ranging either not being implemented or ranging "through" buildings collides with another bug. I can reproduce your results if I DO NOT update my designation with an additional TDC depress with 8 seconds to go. In all my runs, I always designate the target with 8 seconds to go because my JDAM testing has led me to conclude you are actually not designating the building, but the spot "through" it on the other side. Your aim points are all long, so your bombs fall more or less on target. To illustrate, 4 tracks. 7k "update" wherein I update the target position with 7 seconds to release, and "no update" where I don't do this. "update" hits, "no update" is consistently long. 12k "update" falls consistently short (original bug report) and 12k "no update" falls more or less on target. I have tested many more altitudes and bomb spacing with a similar continuum of results. I've derived two conclustions: 1. The further from the target you TDC depress, the longer your aimpoint is from target center 2. The higher your altitude, the shorter the bombs fall from said aimpoint. I believe this is why "AUTO bombing broken" reports abound on the regular forum but with wildly different results. To consistently test your results, you MUST make sure you TDC depress at the same distance and altitude each time to ensure your aim point is the same each time. My aim point theory is in another bug post and is tested with JDAMs, so that is supported by evidence as well. Trust me, there's something up here with AUTO. hornet_auto_issue_7k_no_update.trk hornet_auto_issue_7k_update.trk hornet_auto_issue_12k_no_update.trk hornet_auto_issue_12k_update.trk

At what point did you take control? What did you do differently from me? Which track did you do this to? What was your altitude? It would help if you saved your own track and posted it. We have several users claiming a repeatable issue with this. The lower the altitude, the less short the WEZ is.

Please watch the tracks. Issue is not dispersion. Everything is explained in OP and demonstrated in the tracks.

Yes. I'm using PTRK and making sure the reticle snaps to the target, then lasing while pressing tdc depress each time to ensure a consistent aim point.

Attached 5 tracks. In tracks 1-3, I am bombing the same target at an alt of roughly angels 12 with 4 mk83 with 100ft spacing. All passes, the entire string lands short. To eliminate wind as a factor, I recorded "no wind" to show the same behavior was still occurring. Then, I recorded "low alt" where I release much lower and string, though not hitting the target (100ft is too much for this target), it perfectly brackets the target as I would expect. Altitude has an effect on where the bombs land, long or short, irrespective of flight skills, designation point, and atmospheric conditions. This strongly suggests there is a bug in the bombing algo. I tested the aimpoints with GBU38's to confirm that it wasn't a designation point issue, and it isn't. It's definitely the bomb drop logic itself. This definitely needs to be corrected, as AUTO bombing with iron is really not a good idea in the Hornet right now unless you can go low alt ( < 5000ft for best results). To reiterate, and ward off the cavalcade of inevitable "I saw X pilot say AUTO isn't accurate" posts, the bombing method is PRECISE, but it is not ACCURATE, meaning the dispersion pattern is as expected, but the actual point the system thinks it's trying to drop on is wrong. Random dispersion issues from large WEZ would be circular in nature, whereas this issue is linear. hornet_auto_issue_1.trk hornet_auto_issue_2.trk hornet_auto_issue_3.trk hornet_auto_issue_nowind.trk hornet_auto_issue_lowalt.trk

bump

I know you'll see much more parrallax with OPR vs ATRK. OPR looks "through" objects to the other side, whereas ATRK "sticks" to the ground. Not sure about real life, but those are my observations in DCS. I will test PTRK on static objects without an aquiretrack to see if it behaves like OPR or ATRK.

I saw this before. However, why was this tagged can not reproduce and I was asked for another track if it's not released yet? There are 4 other posts in the main forum about this directly and indirectly. I think it would help if this is true that this post tag be updated to "later in EA"

Newy, realized that track wouldn't work because I hadn't updated to the latest OB. I have done so now and re-created the issue in more concise format. In track #1, I PTRK the boiler house and designate somewhere around 9-10nm out, making sure LTD/R is flashing when I do it using trigger. This bomb falls way long. As I overfly the target, I make another designation when directly over the target, extend, turn 180, drop on this new designation, shack. To eliminate direction of flight as a factor, track #2 shows an attack on the same target. I PTRK the target, and wait until directly over the target before designating, turn 180 and extend, then turn 180 to around the first attack heading. I drop when in zone. Shack again. Since the test is run with GBU38, and can be repeated over and over, I have to conclude either laser ranging isn't implemented or isn't functioning properly. EDIT: Disregard in my last post where I say designation point is updated on slew. This was one of the changes in the most recent 2 patches and I hadn't observed it yet. hornet_laser_issue_1.trk hornet_laser_issue_2.trk

We could all speculate forever, or someone could give us an official response. I really don't think it's working. Also, the range in the display is updated, but your designation (and therefore bombing solution) is not updated until you TDC depress.

If you have an active designation, it won't slew just like MAVF. Press undesignate then you can slew.

I think Wags was mistaken that the range was generated by the laser. But the tag says "Can't Reproduce", it would say "later in EA" if it's not supposed to be done yet. Just trying to get the official status.

I did

In Wags videos he says tdc depress should do it. I used the trigger after I saw that wasn't working. I'll make a more concise track in a bit.

Laser ranging is required for accurate GPS coords from the TPOD, else you are getting angle rates without contrast lock. In the track, I engage a a "Boiler House" object using PTRK, make sure the LTD/R is set to "Trigger", hold the trigger for lasing and TDC depress. I release a JDAM in TOO on this target to see the spot designated, and the bomb overshoots on both "boiler house" type objects. I know the laser is going "through" the targets, because I re-flew the mission, waited to designate until I was DIRECTLY over the boiler house, TDC depressed, then turned around 7nm out and shacked the target near dead center. Basically, the TPOD is designating like the A10 TGP without lasing, taking only pure slant from the aircraft to ground aimpoint regardless of intervening objects that the laser should be picking up.

Track attached. Towards the end two JDAMS released in TOO mode, buildings designated in point track (to ensure cursor centered and consistent) while firing the laser. Both bombs overshot their target, as if the laser is going "through" the building, similar to what you would expect when designating a target without using the laser at all. hornet_laser_issue.trk