Moonshine

on stable version yes, on Open Beta not

this is true setting SSAA to 0x does fix this temporarily. can @BIGNEWY confirm this? i made two tracks (although i bet one would have been enought since it depends on user graphic settings anyways) Graphic settings used for NVG_Alignment_no_SSAA.trk Graphic settings used forNVG_Alignment_1.5x_SSAA.trk (the only difference is the SSAA)

works for me. a reminder: if you boresight your mavs at 9nm (you can compare that to zeroing a gun to a certain range), your mav crosshair and tgp crosshair will perfectly match at 9nm. now since the pod is offset horizontally (due to its position on the aircraft in relation to the position of the maverick), at a distance of 4nm to your target, your mav will be offset to the left (remember, you boresighted to 9nm). at a distance of lets say 15nm, your mav will be offset to the right as this is past the point of your boresight. maybe you heard of setting a convergence distance for wing mounted guns in WW2 aircraft. same principle applies. at close range your bullets wont get to the center of the crosshair, at long range your left wing guns will shoot too far to the right. only at the specified distance they will meet the desired impact point. reliable auto handoff with mav D was achieved at around 4-6nm to the target.

even the ED Viper manual (page 265) states how it is supposed to be, just the sim does not reflect this at its current state. further details are described in the M3

i have no problem with it being shown as white / yellow in case there is no AWACS that has already identified said contact, hence a second source is needed to correlate the information, but i have a massive issue if something has been positively identified by AWACS as bandit, shown red and the very instant my radar spots that contact it immediately turns into a white square hence losing all previously correlated information to said contact. that can not and should not be a thing, imagine the chaos that this creates in a crowded airspace. if that would be the case, why even have an AWACS since his information gets lost anyways as soon as your own ship paints anything. no other aircraft loses the DL info to a contact upon painting it with the own ship radar, putting the viper in a massive disadvantage in its current state and i fail to see why that would be a thing in real life for the viper but not for any other (western) AC with similar capabilities. and no i am not talking about "balance", this is a sim after all.

so, even with a C2 present, positively as hostile identified contacts still turn white upon being spotted with the own ship radar. how is that possible that a contact, identified by C2 as enemy (or friendly for that matter), shown red on DL suddenly loses all that info as soon as my radar sees him too? for reference, i turn the radar to silent midway through and as soon as the hits time out, it returns to red symbology... FCR_Color.trk

this. Burn through range is at around 25-28nm currently, so until then, it will show 99.9

as the title says: select TGP and enter point track Select MARK (icp7) Markpoint option TGP shows up on DED (when TGP SOI) create markpoint Cycle through the markpoint options (OFLY, FCR, HUD..) the TGP option never shows up again. TGP_Mark_Option_Missing.trk

despite the changelog listing things as fixed, the issue as described in this post, the triangle indicating the position of OA1 is showing up below ground, despite its altitude being set correctly. track attached Offset-Aimpoint-location_bug.trk Offset-Aimpoint-location_bug2.trk

lets assume everything is done correctly, i usually boresight the mavs mid air, using some house or structure as the object to boresight on. now, the first station i manage to boresight at around 10-11nm, all fine. switching to the second station and locking the same object up does not take a lot of time, yet when cruising with around 450kts you do cover some distance during that time, which means, the second station will be (perfectly) boresightet at around 8-9nm. so now you have two stations, both perfectly boresightet but to different ranges but it LOOKS like one is not accurate depending on how far out the target is you are trying to engage. nothing wrong with that. if that bothers you, change the object you boresight on so you can get the max range out of both stations. bottom line, no problem boresighting mavericks

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.