Sinclair_76

I think I have found a bug. When linking a zone A to a unit 1 via linkedUnit, if the unit 1 gets cloned in a zone (using the identical attribute). The zone A moves fine. But the moment you add useOffset or useHeading attributes the zone A stops moving with unit 1.

Could linkedUnit also be available for statics? This would diversify the options immensly.

Another thing I would like as a module is ELINT. In theaters like Iraq and Afghanistan, ELINT units were often able to provide grids of insurgent ICOM (walkie talkie) chatter. The way I see this in DML is a zone with attribute ICOM (placeholder), over a enemy unit. The value can represent the power of the transmission in watts, or chance of intercept, amount of transmission ins an hour etc. Furthermore a zone over a friendly ELINT asset, like an antenna or MQ-9 or RC-135 Rivet Joint. Work out line of sight and chance of intercept. If true a message could be sent (like in recce module).

No hair anyways. Solved it by adding the identical and wholeGroups attributes, both set to true, in the objective zone. Downfall is I can only have one group active at a time due to identical. Would nameScheme be able to overcome that? If so how? Could you provide an example?

I ran in to the following issue. For some randomization I clone a 'lead vehicle' somewhere random in a another zone. Linked to that 'lead' vehicle is another zone which through a sequencer, pulses 1-8 additional vehicle within 500' of the lead vehicle. Only thing that does not work is the zone following the 'lead' unit. Somehow I made this work in another mission but I can't reproduce it. Added the png's to show following zone attributes and the 'lead' vehicle attributes. Am I missing how linkedUnit works? PS the pulses set to 1-8 in the pulser attributes generates 4 pretty much al of the time. Does not appear very random.

The JDAM CEP is not bound to the sub-mode employed in the GBU. In a GPS denied environment only the INS will provide guidance and the CEP is 30m. If GPS is available the CEP is 5m (Boeing even claims 1.7m) source for 5m/30m CEP https://www.esd.whs.mil/Portals/54/Documents/FOID/Reading Room/Selected_Acquisition_Reports/FY_2018_SARS/19-F-1098_DOC_46_JDAM_SAR_Dec_2018.pdf https://www.af.mil/About-Us/Fact-Sheets/Display/Article/104572/joint-direct-attack-munition-gbu-313238/ source for 1.7m CEP https://www.boeing.com/content/dam/boeing/boeingdotcom/defense/weapons-weapons/images/jdam_product_card.pdf source for 3m (after JDAM PIP) https://www.esd.whs.mil/Portals/54/Documents/FOID/Reading Room/Selected_Acquisition_Reports/FY_2018_SARS/19-F-1098_DOC_46_JDAM_SAR_Dec_2018.pdf (p.15) The 13m CEP (with GPS) was an early figure before actual use data was available and the JDAM PIP. After actual usage the CEP dropped to 4.2m. After the JDAM PIP, CEP drops to 3m. The PIP probably consisted of the employment of better Kalman Filters or differential GPS/ GBAS. https://www.ausairpower.net/TE-JDAMPt1.html https://www.globalsecurity.org/military/systems/munitions/jdam-antijam.htm

Thanks! I figured it out. Any 'passthrough' menu option needs the radioMainMenu attribute.

Great update! Especially thrilled by the new radio menu. With one level of indirection, does that mean you can do F10 other / A-G / CAS / X1, X2, X3 (X1 through 3 being the different options (ITEM-A through ITEM-C) etc...) and not F10 other / A-G / SEAD / LR / SA2, SA5, SA10? or can you go as deep, with as many layers as you want?

It's because the JDAM GPS can't get a good/sustained fix below the wing. So before the release coordinates are transferred as a starting point. After release the JDAM needs 28 seconds before the error is identified. Then depending on the sub-mode it rejects the error or implements is as a bias.

I am getting this guardianangel pop up when a enemy SAM fires a missile. I've upgraded to the latest scripts.

Apparently the JDAM has sub-modes that haven't been correctly modelled and ED is working on it (or considering it WIP at least). It has to do with the navigation inaccuracies recently introduced in the F-16. The JDAM sub-modes are called absolute and relative. As per "An Analysis of Target Location Error Generated by the Litening Pod as Integrated on the AV-8B Harrier II Pod as Integrated on the AV-8B Harrier II " p.7. The relative mode of the weapon is used when onboard the aircraft sensors are used to generate the target coordinates. In the relative mode, once the JDAM acquires a GPS signal after release from the aircraft, the weapon compares its GPS position to the JDAM INS position (previously aligned to the aircraft). Any difference is assumed to be an aircraft induced position error. The error is then applied as a correction factor (bias) to the coordinates (Figure 1-3). This bias is nearly zero when the weapon is aligned to a tightly coupled aircraft because both weapon and aircraft are using the same navigation source (GPS). However, if the sources are different (loosely coupled aircraft and tightly-coupled weapon) the bias allows the aircraft to designate a position relative to its own location without concern for aircraft INS induced errors [5]. This bias to the target coordinates will be in the same direction and magnitude as the aircraft handoff error. The application of a bias to the weapon did not change the position of the target but instead changed the reference frame to the aircraft-based (relative) reference frame from the earth-based (absolute) reference frame. In our version of DCS, the relative sub-mode of the GBU works. Regarding a pre-planned target, the target coordinates are considered absolute. In other words there is hardly or no error in the target coordinates as was certainly the case regarding a target of opportunity, where the aircraft position error carries over to the target location. If the same logic was applied when dropping a GBU on an absolute coordinate the bomb would (incorrectly) maintain the bias and miss the target. That is were absolute mode comes in. When a pre-planned (steerpoint) grid/location, without cursor slew, is transferred to the bomb it is considered absolute. In the absolute sub-mode when the GPS of the bomb comes online (28sec) it won't apply the here fore mentioned bias but will try steer to the given grid and hit the target. In our version of DCS, the absolute sub-mode of the GBU does not work. To overcome this discrepancy you would have to trick the system in relative sub-mode by applying cursor slew. The most effective way of doing this is slaving TGP to the steerpoint, slew over to the base of the target and TMS up to designate. All in all, I would rather have ED implementing a complete (relative and absolute) solution rather than what we have now but I applaud their commitment to realism. The fact that there are errors to deal with makes the F-16c feel alive and realistic. At the same time I get that the relative sub-mode is fairly easy to program compared to the absolute sub-mode.

And like the F-4E

Well done!

The -88C we have is indeed a SEAD weapon. The -88D and further have GPS and not only INS to guide the weapon when the radar is turned off. Technically an accurate waypoint increases your chances of a successful HARM (C) engagement even when the radar is off. It's just one less error to deal with. The -88C is a late cold war weapon (design) where SEAD was an important enabler of large COMAO's. Sure, DEAD is better, but prior GPS, DEAD required SEAD anyhow. With HARM's in the air, there is risk for the SAM operator. It adds friction to the OODA loop. This friction pretty much always compounds/snowballs in high stress circumstances, decreasing the chances of a successful SAM engagement.

CCRP delivery isn't a delivery mode for JDAM, so absolute or relative doesn't apply.

No not broken. Preplanned JDAM is less accurate at this moment. Using TGP to employ JDAM works perfectly fine for me, since it seems Relative Targeting Mode is modeled.

Good point. For BOC (bomb on coordinate)/ PP (preplanned) the JDAM employs absolute mode For BOT (bomb on target) / TOO, the JDAM uses relative targeting mode Basically in absolute mode, aircraft error is removed by JDAM GPS after 28 seconds and for relative targeting mode the error (or bias) is maintained. This document (p 7-8) perfectly describes the JDAM relative targeting mode (https://trace.tennessee.edu/cgi/viewcontent.cgi?referer=&httpsredir=1&article=6123&context=utk_gradthes) When using the preplanned data transfer method, in-flight data transfer method, or entering coordinates through cockpit data entry devices, JDAM will be released using the target coordinates in an earth-based reference frame (absolute mode). Furthermore... The relative mode of the weapon is used when onboard the aircraft sensors are used to generate the target coordinates. In the relative mode, once the JDAM acquires a GPS signal after release from the aircraft, the weapon compares its GPS position to the JDAM INS position (previously aligned to the aircraft). Any difference is assumed to be an aircraft induced position error. The error is then applied as a correction factor (bias) to the coordinates (Figure 1-3). Now with a quote from @Lord Vader Now I think I understand where ED is going. They have relative targeting mode modeled but not yet absolute mode. And that is what is probably (assumption/conjecture) is meant by And to overcome the fact that absolute mode is not modeled. If you have pre planned targets designate the with TGP to force the Relative Targeting Mode, because that is correctly modeled it seems. Now I also understand the logic behind the strict steerpoint grouping. To answer to @Swift.'s conundrum, could this be a solution? Steerpoint 1-20 are basically from the DTC and are preplanned or fatfingered/edited in the aicraft. They can be considered absolute. Steerpoint 21-25 are MGRS are fatfingered and are considered absolute. JTAC BOC for example. Steerpoint 26-30 are derivatives from AGR / TGP / JHMCS / HUD / Fly-Over and are considered relative at all times since the aircraft generated this coordinate. The moment you use steerpoint 1-25 with no delta(slew) applied it can be considered absolute. In that case JDAM can use the absolute mode. Once you introduce a delta(slew) with ie the TGP and update it (TMS up) the steerpoint with delta(slew) is considered relative since you're designating a target and JDAM should then use relative mode. Once you remove the delta(slew) with TMS down/CZ it is considered absolute again. Using JDAM on a markpoint is always relative and relative targeting mode is applied. Thanks @Swift. for pointing me in the right direction.

And if the bombrange trigger zone is 100m in radius. Does i.e. 95% quality mean 5m off center of the bombrange trigger zone?

I have a small request. Is it possible for the bombrange to show meters in stead of percentage? Would a clip distance of 100 translate % to meters directly? Or is is the size of the trigger zone? and I get this message when the gbu-38 hits the ground.

Fast takeaway. The second document provided pretty much all the info we need on page 28&37. There are four elements that contribute to JDAM system accuracy: 1) the JDAMs ystem components, including guidance hardware and software; 2) the delivery aircraft transfer alignment time hand-off accuracy, including location and velocities; 3) the GPS satellite error; and 4) the target location error (TLE) and the associated coordinate format. And... Once GPS-aiding is accomplished, the aircraft hand-off error is removed and is not a factor in system accuracy. Furthermore (page 37)... The handoff of high quality GPS information to the bomb, allows the JDAM to achieve full position and velocity acquisition within a maximum of 27 seconds and full GPS navigation within 28 seconds after release. This document states that after a gps handoff and roughly 28 seconds after release the aircraft error is not a factor anymore. Thank you @KlarSnow!

The 13m CEP comes from the F-16.net site. It was one the earlier established CEP prior operation Allied Force. Later finetuning of the Kalman filter resulted in a 5m CEP. @Lord Vader It doesn't matter how you spin it, NATO documents provided (ATP 3.3.2.1 (NATO UNCLASS) 3.32 BOC and IAMS), clearly state that the only factors that determine the outcome of a JDAM release are the CEP and TLE. Nothing references to the launching platform or their location error. I stand by that with a functioning gps on the F-16 the JDAM CEP is 5m and that a location confidence of 30m or ,10m ,for that matter, don't influence the accuracy of a JDAM. The only reason I provided the F-16.net info is to fill in the gaps, not be used as a red herring.

The JDAM GPS kicks get it's first fix +/-10 sec after release. It then takes some time for the Kalman filter to wash out the launcher location error to get to the 5m CEP. Best open source I could find is F-16.net (see link below). The link is slightly dated, the Kalman filter has been improved to further reduce the 13m CEP to 5m CEP (2016 SAR document below). Sure the F-16 INS/GPS might develop a 30m error (which is a lot, the aircraft I used to work with had a position confidence of 15m) but the JDAM does not take the full error to the ground if employed correctly. To suggest that the F-16 error of 30m translates in a 30m (error)+5m (CEP) is just incorrect (see sources below and explanation above). In IAMS targeting TLE and CEP are considered, not the launcher location error. The JDAM is adverse weather and BOC (bomb on coordinate) capable. Especially with BOC the pilot only fat fingers in the coordinates and releases in optimum parameters. Hence that during CAS the only action required for correlation is the readback of the programmed coordinate in the system. In case of the F-16 you readback what you entered in the DED, not what you wrote down. To fiddle around with TGP to update the coordinates would invalidate that procedure (Aircrew will not modify coordinates once read back is complete). Sources: https://www.f-16.net/f-16_armament_article9.html https://apps.dtic.mil/sti/tr/pdf/AD1019464.pdf ATP 3.3.2.1 (NATO UNCLASS) / 3.9.1 BOC / 3.32 BOC and IAMS / 5.4.15.a BOC Correlation / H.5.g Correlation and Tholozor

The new navigation alignment for the F-16 is not accurate enough for pre planned GBU-38 delivery. Did a full INS alignment in open air according new procedures. Aligned GBU-38 on the ground. Verified target coordinates and corrected longitude (top coordinate on kneeboard). You can verify with miz file Once airborne delivered a GBU-38 on preplanned target. Target not destroyed. Although this trackfile is only on run I did many, none hit the target. Than proceeded for a TOO delivery. 1st TOO GBU-38 was fault on my side. 2nd TOO was a hit. You can crosscheck coordinates with kneeboard (lower coordinate). This means that in this configuration the F-16 can't deliver GBU-38 through bomb on coordinates CAS procedure. Or deliver a GBU-38 in a near peer environment with a low level toss. Personally I find it strange that the GBU-38 itself has a 5m CEP. But that F-16 is not capable of exploiting that degree of precision because it's INS/GPS isn't as accurate. TEST - NAV FULL ALIGN PP GBU38 delivery.trk Test - NAV-TGP.miz

I will. And I know how. But as far as I can tell preplanned JDAM targets are inaccurate.

So I've tested this. Mission setup 2 targets and my player aircraft. One steerpoint over first target. Double checked altitude. I did a full NAV line up with the aircraft on a platform, not in a bunker, using GPS according new procedures. All systems display a high accuracy in the DED. Made sure the GBU-38 did a full lineup (READY MSG) Once airborne the TGP slaved roughly 50 meters to the west. The GBU-38 falls roughly on that, 50m west of target, position. Update the tgt with an TMS up results in the 'normal' 5m CEP. And subsequent tgt kill. An air start resulted in a different issue. It seems like the target altitude is incorrect / too high. Before tgt the tgp is aiming too high and straight above the error seems almost 0. Funky stuff. I've some more testing to do so no replay just yet. But it's like 2 steps forward 3 steps back with the F-16.