Moonshine

Dont forget to turn on the master arm to either „arm“ or „simulate“…

@BIGNEWYnot again, all needed evidence is here, there are also links to other threads that include trackfiles related to the JDAM accuracy error, the TGP inaccuracies etc.

same topic as raised here. I did two different tests with no particular issues. Feel free to use the tracks attached and use them for your tests. If the targets are within reasonable distance to each-other i did not see any issue bugging them. the only time this could get difficult is when one is significantly lower/higher than the other and exceeds radar scan limits. on a different note, at times (with awacs / DL present), designating any contact is only possible after the DL updated the contacts location despite what your radar sees as „bricks“. That could lead to issues designating anything and was raised in a different topic. will reference it once i found the post edit: found the post Maybe @BIGNEWY can look at this with the DL issue in mind

To get back to the subject; any chance @BIGNEWYcould check the supplied tracks regarding the JSOWs?

Yup, sad state of the viper currently.

bump

pm sent

will send PM

did a short test A/A mode, only Aim 120s (2x C, 4x B) -> switches automatically A-A_Mode_MRM_auto_switch.trk DGFT mode 2x C, 4x B-> switches automatically DGFT-Mode_MRM_auto_switch.trk DGFT mode all MSL types equipped -> 2x C, 2x B, 1x 9m, 1x 9x -> after firing the first 120s it switches to an aim-9, shooting this would make the jet switch to the second aim-9 automatically, not the other 2 Aim120s, those only come up if manually selected afterwards. -> question here is: should it instead switch to the next MRM type missile before going to the aim-9 or not? And shouldnt it select the remaining 120s as the only missiles left after all aim-9 have been used instead of just displaying 0 aim-9?DGFT-Mode_all_MSL-types.trk Per default when aim-9 are equipped, DGFT always selects aim-9. manually selecting aim-120c results to a switch to aim-9 once all aim-120c are used, aim-120b still on the jet. when shooting the first two 120C, the jet switches back to aim-9. MSL step long press lets you step through the weapons until you reach the other aim-120(b). shooting those however then also makes the jet change back to the already used 120C (0 120C) and does not automatically go for aim-9. this is wrongly implemented as the jet should skip depleted or otherwise not ready weapons DGFT-Mode_all_MSL-types-2.trk now since the last scenario sounds confusing; step by step: Loadout contains -> 2x 120C, 2x 120B, 1x 9m, 1x 9x 1. enter DGFT -> aim 9 is default 2. MSL step long press to get to 120C 3. Shoot all 120C -> jet automatically selects aim-9 4. MSL step long to get to the 120B 5. shoot all 120B -> jet changes back to 120C (??? why, they are already gone) -> this is wrongly implemented as the jet should skip depleted or otherwise not ready weapons according to the manual. 6. Manually step through (MSL Step long) to get to Aim-9m 7. Shoot aim 9M 8. Jet switches automatically to remaining 9x 9. use aim-9x 10. congrats youre down to guns

first track: i did it with 25kts crosswind, BA 1500ft. still way off. and 25kts is labelled as "strong breeze". should not be a problem for that bomb. bomblets drift way south of the target, with the most northern bomblet still not on target. interestingly; following the bombs flight path, she glides straight to the steerpoint, then going nose down for the final phase and only then trying to adjust for wind (large flight path correction in the final phase of flight). is that as it should be or should the bomb correct its flight path way earlier, reducing the need of significant last second adjustments? as of now it looks like she cant reach the desired offset point before reaching the defined BA, resulting in a miss Second Track: yes, lowering BA does help (set it to 1000ft), still only 1-2 bomblets actually fall withing the target point. youd have to set it so low you wont get any spread anymore, so why bring a cluster bomb in the first place. CBU-105_25kts_xwind.trk CBU-105_25kts_xwind_BA1000.trk

Yes its broken again

we are patient. just for perspective, the OP posted this in april last year...

Sinclair is right. WCMD are not actually correcting for wind. Did the same thing, not using the TGP to designate the target point, rather just used pre planned ones out of the ME. Add some wind and the bomblets go everywhere but not on target. @NineLine i think we have more than just the TGP inaccuracy issue at hand here. Currently the cbu-105 behave like the cbu-97, not correcting for wind

did some test to start with, Awacs has a contact, identified as bandit -> red on hsd, only outline as my radar does not see him yet. as soon as my radar has contact, Color changes to white, shape changes to filled square -> weird. DL isnt lost then i turn my radar completely off to lose the track -> turns red again as bandit on DL however, turning the radar on and bugging the contact gives me a red triangle even on FCR, yet a white circle outline indicating a bugged contact.. shouldnt the circle that indicates a bugged contact be the same color as the DL? white for unknown, yellow for ambiguous, red for enemy and green for friendly? upon firing at the contact and cranking, contact turns white again. cant explain that. then trying to lock the friendly AWACS -> HSD shows green circle, FCR shows white square. this symbology thing is reeeeally off, especially since not even friendlies show up as such on the FCR, making this a very dangerous endeavour. FCR_Color.trk

This.

circle is friendly, square is unknown and triangle is enemy. and to underline this for easier recognition there is the color. green for friendly, white for unknown and red for enemy. so if it is identified, red should always be a triangle. i think it was just worded wrong in OPs post

bump

dont have a track for OPs issue, for my comment, there is this: https://forum.dcs.world/topic/299714-fcr-color-after-lock/#comment-4957988

the whole FCR DL symbology is a little off. for example: how can a track that shows Red on DL (and is also detected by my radar) turn to white (unknown) from the second i bug it? do i magically lose all DL info on said contact?

interesting approach to a WCMD (wind corrected munitions dispenser) if thats the case

i think so too. while it is harder to detect on cluster bombs since their bomblet-footprint is so large and somewhat random that it is hard to tell if it did hit the correct spot or fell short (or otherwise missed). even more so if 2 bombs are dropped like @NineLine did in his test

the current inaccuracy of the TGP might not help with it. same as other GPS guided weapons (like the GBU38) dont hit within their parameters, i dont believe its the weapons fault but more the TGPs lack of accuracy. post for reference: TGP CZ issue (results in shifting Coordinates everytime CZ is pressed) -> https://forum.dcs.world/topic/315078-cz-function-issues/#comment-5132696 JDAM inaccuracy (most likely due to the inaccurate coordinates received from the TGP, making bombs miss beyond their 5m CEP) -> https://forum.dcs.world/topic/317925-jdam-still-inaccurate-beyond-the-5m-cep/#comment-5144779

any chance you could post that public document you mentioned @BIGNEWY? id love to have a look at it.

this by the way has already been part of a discussion and raised by other people, including track replays: then there is this: „The navigation system is initialized by transfer alignment from the aircraft that provides position and velocity vectors from the aircraft systems.“ source https://www.af.mil/About-Us/Fact-Sheets/Display/Article/104572/joint-direct-attack-munition-gbu-313238/ so that leaves us with this: when the INS data is transferred from the jet to the bomb, why would the currently selected master mode make a diffence in the speed at which this is done?

what makes us think is wrong? the fact that upon pressing "power on" to start aligning the JDAM should not make ANY difference at all which master mode, which other MFD pages or whatever is selected that would affect the duration of the alignment process. when starting the alignment of the JDAM while in AG mode and then swichting master mode back to nav for example completely stops (or slows down the alignment process) until the next time you get back to AG mode and check the SMS page, then it picks up where it "left off" when switching from AG to NAV. this can not be correct