Moonshine

Theory: in RUK, the HARM should have a search radius of 20nm around the selected steerpoint (according to the linked video below). this should ensure the HARM does not target something further out etc. according to the early access manual (page 397), EOM should require much more precise target location information than RUK (or PB) Now in my test, i placed 2 steerpoints. one on which i fire the HARM and the second one where the location of an actual SA-15 is.The goal here is, that the HARM will only attack a SA15 emitter around a specific steerpoint, not any other SA15 outside its 20nm search radius. Test: In this example I fire at a target steerpoint (kutaisi) with an SA-15 along my ingress axis, however outside of the 20nm search radius. expected result: HARM flies to Kutaisi, impacting on the steerpoint as it cant find any emitter there. observed result:HARM_RUK.trk HARM attacks SA-15 even though it is outside of the 20nm search radius around Kutaisi. this does not reflect what wags talks about here (first 2min): Test 2: after seeing that i was curious if the HARM in EOM does the same, even though the search radius around the selected steerpoint for the HARM should be even smaller than in RUK: expected result: HARM impacts steerpoint at Kutaisi observed result:HARM_EOM.trk HARM kills SA-15, 25nm short of intended steerpoint Test 3: Same setup this time using PB mode expected result: HARM impacts steerpoint at Kutaisi observed result: HARM_PB.trk Harm kills SA-15, 25nm short of intended steerpoint. Conclusion: in all of the POS modes, the HARM seems to target the first possible emitter of the selected emitter it can find, goes active too early and attacks "wrong" targets.

Is there any update on this topic@BIGNEWY? Seein the track has now been provided. This at times proves to be a big problem when trying to use DTT, upon bugging the first contact, the radar elevation changes and a the designation of the second contact (even when they literally fly in formation) is not achievable

in all honesty, a not working animation for a pod does seem rather minor compared to the amounts of serious bugs in the vipers systems...

Dont think so, as you can use the maverick image feed to refine the seeker. Only in Pre mode will the mav ever follow the tgp Edit: i stand corrected

yeah its a bit sad currently. for most sensors and functions, while they do work lets say 75%, often you need to rely on some weird workaround to get desired results, making the viper that by design would be highly optimized for pilot use, a very tedious plane in its current state in DCS. OA1 and OA2 are completely unuseable since 6 months now

not sure how the sensor logic should be. when maverick in VIS mode, HUD is SOI -> you can slew the TD box with the cursor slew, maverick will follow the TD box. pressing TMS UP will then ground stabilize the MAV at the TD box location, you can then slew the maverick around and refine its position (indicated by the circle you can slew around). you can either do that on the WPN page itself or directly in the HUD. pressing TMS UP again will attempt a lock. with the TGP, you can selw the TD box, however, maverick does not follow the TD box location. pressing TMS UP (entering point track) does not ground stabilize the MAV as they arent coupled like they would be in PB mode. when using the MAV page as SOI directly, not the hud or anything else, slewing around moves the TD box (visible in the HUD), however, pressing TMS UP does try to get a lock on something, not ground stabilizing the MAV. not sure if that is intended behavior or if the ground stabilizing part is skipped/missing.

it did work prior to the ominous christmas last minute update in 2022.. since then they are broken again

dont know why this is tagged as "missing trackfile" this issue is now sufficiently reported..

he did state that he switched the fuzing of the bomb to "nose" hence the fins (for the snakeye) or parachute (for 82Air) will not deploy and slow the bomb down... he isnt talking about tossing them in hi-drag settings

this. and also there is still this issue:

does work for me MGRS.trk

This is still the case. And nothing in the patchnotes. Its about time the viper gets some serious bugfixes. Long overdue.

been reported here, apparently "WIP".. hope to see some changes soon. current implementation makes 0 sense and does not reflect any manual either

another example. as you can see, i clearly step to the wingman (and no, missile is not pitbull off the rail), yet still both missiles track the same target. Aim-120_TGT_selection.trk

Need to enable ground jettison plus master arm sim or armed on ground

DTOS still gives you an ASL upon designating. also youd use CCRP until you can visually see the target, then switch to CCIP. Switching modes mostly happens on the final wire to the target (after the pull down and roll out) thats why OAs are so important. By stepping through the sighting option you get steering information to the offset aimpoints (thats how you fly a proper pop-up profile as per the manual). CCRP is for level flight, but not limited to it. toss profiles are far from level flight and CCRP is much more accurate than LADD

while i do think upside down bombing is rather questionable if not unreasonably dangerous, the ASL (azimuth steering line) should still not point in the opposite direction of where your steerpoint actually is, no matter the attitude of the aircraft. and as mentioned by VarZat, a pop up profile that requires some offset, some roll over and pull down to get on final attack heading will include this. if during that maneuver, the ASL misguides you, this can end very badly

just tested again, this time waiting for the initial toss cue to disappear so i dont drop at the edge of the envelope. while the effect is significantly less, its still present. CCRP_Rel_cue_jumping3.trk

@skywalker22 you can not use HTS and Harm HAS mode together. If you use HTS, you need the harm to be in a PB mode (any of them). Because: in HAS, the HARM seeker is your sensor. With the HTS and HARM in PB, your HTS is the sensor, not the HARM. dont mix those two up. If you use HAS, your HTS is useless to fire the weapon, no handoff will be made. while you surely can display the HTS (HAD) while having the Harm in HAS, it does not share information with the missile, so the HAD just a fancy display of emitters that you cant do anything with. edit: resolved

so, flew some bomb toss attacks, noticed that upon starting the pullup, the release cue on the ASL starts "jumping" up and down. is this supposed to happen or is this bugged? CCRP_Rel_cue_jumping2.trkCCRP_Rel_cue_jumping1.trk

appreciate this, thank you!

been reported, still an issue

Would have to see a track of how you employ it. Generally, pay attention to the keyhole during your maverick employment. Too far „off-bore“ and the missile wont be able to turn in time. Its not super maneuverable.

watched and reproduced. nice find. Test_2.trk