Moonshine

this is apparently still WIP as the issue is reported here: currently upon painting a contact, all Link16 information is immediately lost

yes, corrected

I like the idea, however not that useful for people not using Voice Attack (like me). lets stay on topic and not drift off further into Fix etc. this one is about the OA position being below ground despite setting positive altitude numbers in DED.

never tried a NAV Fix (ICP button 8 ) with a offset aimpoint, could try to select the relevant steerpoint, try a fix and instead of looking at the steerpoint diamond, youd look at the offset aimpoint triangle. then again, for that triangle to exist in your HUD, you need to be in AG CCRP, LADD or DTOS, i doubt you can do a NAV FIX in AG master mode. would have to test but i dont think thats possible. since a NAV fix corrects every steerpoint, not just the selected one, you can just use one that is not obscured by clouds or whatever. some brain needs to go into mission planning to ideally place all steerpoints on some sort of landmark, so you can choose any of em to perform a fix. alternatively perform the fix using the AG radar. edit: based off of this post in the viper minu update thread you have to be in NAV master mode for a FIX. https://forum.dcs.world/topic/209147-viper-mini-updates/?do=findComment&comment=4992813 Offset aimpoints can be used in combination with VIP or VRP, indicating Pull Down Point (OA 1) and Aim off Distance (OA 2). this provides visual aid with additional symbology to fly a pop up. As for VIP and VRP, with both you can use OAs as well, only difference is that in VRP, all points are in relation to the TGT steerpoint, in VIP all locations (even the target) are based off a known position (steerpoint not on the target but rather a significant landmark or whatever makes sense -> VIP) and from there the bearing and range to the target is related.

it did work at some point prior to last christmas, since then its broken. no, wags video showing the OA and how he designates it with the TGP is not correct. has nothing to do with GPS or no GPS, the OA will drift alongside the steerpoint they are related to in case of INS drift and can only be corrected doing a NAV FIX. however yes, if you have a target steerpoint and someone tells you (or you know, have a map and a ruler, do it yourself) that the exact location of whatever you try to hit is at a specific bearing at a specific range and altitude from your steerpoint, you can then plug this in via the DEST page so you dont have to get completely new coordinates (for example, JTAC giving you coordinates for one target, then only bearing and range from that point to the next target) another use case is for pre-planned Pop-Up attacks where your OA indicators act as a visual aid to fly the pop up profile, where as you could use OA1 as an indicator for the Apex of your profile and OA2 as your aim-off distance (where you place your FPM). this allows to fly the exact dive angle for optimal weapon delivery.

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