Moonshine

Yes, my tracks here are with the absolute latest Open Beta version.

its funny, in two separate patches it was listed as "fixed" however it was never really fixed. would be time for a hotfix

this bug has still not been fixed, despite the changelog, see new track attached with latest OB. edit: added second track, less clicky, showing same issue. very disappointing Offset-Aimpoint-location_bug.trk Offset-Aimpoint-location_bug2.trk

Maverick needs to be in PRE mode, master arm on ARM or SIM and since you are still on the ground, Ground Jettison switch needs to be on

it has been like this since Viper release. if it would really be such a big underlying issue, the viper bug section would be going nuts about this. the fact you seem to be the first to complain puts the relevancy of this "bug" compared to other bugs regarding radar, weapon systems, sensors etc. in perspective. dont go around now playing the victim and calling everyone "toxic" just because you didnt get the reaction you were expecting.

Might want to come down from your high horse a bit and look at it from a broader perspective. Either way, good luck with that report

There is no „incorrect“ default setting as youd have these switches put in the correct position if you have done a proper cold start. Since youre skipping all this and starting in the air, RWR is on. Now one can split hairs whether it should be on or off to begin with, however with the „minimum approach“ i mentioned, some assumptions had to be made. Now these dont seem to be to your liking, still does not make it a bug. While i agree the Cat 1 or Cat 3 could be simply solved depending on wing tanks equipped or not for example, still doesnt make it a bug.

I believe you did not understand anything i was just saying. Go to options, MISC and check for the checkbox „Synchronize Cockpit Controls with HOTAS Controls at Mission start“ because in all my hours in the viper i have never had any issue in air starts you seem to encounter. maybe also check your mods if you use any. also keep in mind, cockpit setup, switch position etc is highly dependent on the mission, situation and pilot, so having different "standard" ones for each possible variation of mission, loadout etc is just unreasonable. because what might be right for you, might not be right for me. ED going for the minimum needed here seems the right approach.

1. Landing lights to ON is correct as on takeoff, landing light should be used, the switch stays in the ON position until landed and switched to off or taxi upon leaving the runway. This is also affected by the option mentioned down below. 2. Radio on left console is OFF as its just the backup radio, during normal flight with 2 working radios, backup isnt mandatory for the others: there is a section under "MISC" in the options that syncs cockpit controls with HOTAS controls upon mission start. so if you have your HMCS set to off, it will be off (mine is always on for example as i rarely turn the brightness knob to 0) same goes with the XMIT buttons for the jammer and all controls mentioned by you (Master arm etc), mine are off by default at airstart, as i have the assigned hotas controls in the OFF position.

update: added a second SA-15 on the intended target location just to see what happens. funny enough: in RUK, HARM targets correct SA-15 HARM_RUK_2.trk in PB and EOM, HARM still kills the "wrong" SA-15 HARM_PB_2.trk HARM_EOM_2.trk This is especially weird since RUK out of all the POS modes has the largest "search footprint" yet is the only mode where the correct target is engaged

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