Moonshine

with nose fuze the BA doesnt matter, she just opens as soon as it gets clear of the jet..

tested the CBU-87 with nose fuze (so she opens instantly) however the bomblets all fall long in relation to the desired impact point in CCIP. CBU-87_NOSE_drop_long.trk

got it, thanks for your time!

can you explain why, when i manually select the WPN page and start moving the mav around, it isnt considered "slew" according to your statement and hence no missile LOS circle is displayed in the HUD?

First and foremost, I would like to address the point where you mention that "Slew mode" only becomes active when the TD box is designated. In fact, this is a contradiction. SLAVE means that the sensor, in this case, the MAV seeker line of sight, is forced to follow another sensor, in this case, it is the TGP or the TD box that is Sensor of Interest (SOI) and provides a System Point of Interest (SPI). in Short: Sensor management is based on a single line-of-sight concept where all sensors are slaved to a common aimpoint, referred to as the System Point-of-Interest (SPI). Therefore, we should use DMS aft to make the MAV seeker the SOI and then manually move the MAV-seeker-LOS. In this case, it is no longer in SLAVE because we detach the MAV-seeker-LOS from SLAVE by slewing it through movement. However, in one of the videos provided here, the Missile-LOS-Circle does not appear. Let's move on to point 2. Slave mode and slewing are not mutually exclusive. The MAV seeker LOS can be in a Slave mode to the TD box but must slew with every movement of the TD box to maintain this state. As mentioned before, SLAVE means that one sensor is bound to another and tries to follow it. In our case, the Maverick seeker LOS is in slave mode by using the HMCS, which is SOI and provides the TD-Box/SPI, and therefore tries to follow the TD-Box/SPI. However, for the MAV seeker LOS to follow, it must move, and movement essentially involves slewing. Therefore, every time the MAV seeker LOS moves, a LOS Circle should appear, and once it reaches the TD-box-LOS and stops slewing, the seeker-LOS-Circle should disappear, which does not happen in the provided example. In this example, with the help of the workaround (enter and leave dogfight mode), we can observe a part of the correct behavior. The movement with the head/HMCS is faster than the MAV seeker head can slew. By slewing alone, the seeker LOS Circle should appear. Only when it reaches the TD box LOS and stops slewing should the seeker LOS disappear, which doesn't happen in the example. LOS.webm An excerpt from the ED F16 manual (pages 400/402): These 2 examples clearly explain that even when the TGP is the SOI, the term "slewing" is used to describe the movement of the MAV LOS. Furthermore, there are publicly available documents that provide further evidence that equates MAV LOS movement with slewing. From the explanation in the documents, "seeker line-of-sight appears when the AGM-65 seeker is in Slew or Track," a LOS Circle should appear with every movement, which is equivalent to slewing. Finally, it should be noted that this logic supports the pilots, especially when using HMCS. They need to know when the MAV seeker LOS matches the TD box; otherwise, it can lead to input errors.

for sure, EOM or RUK would be the better option to use. thanks for clarification. what i dont get is the following: in this test i first set the PB for SD prior to do anything else then i flew a bit offset to not have the STP within PB footprint. as soon as i saw SD on HAD, i designated it. after designating it, i turned directly for the steerpoint/the emitter. for the whole duration of my flight there, the box never started flashing at all, despite the "new data" being the same as the "pre briefed" data. HARM-POS-PB_SA-11_7.trk bottom line, PB is just not the mode to use together with the HTS/HAD

yeah i dont think the DLZ is the issue. the issue seems to be the emitter being designated while still outside of the "footprint" (as in azimuth, not in terms of range) - mostly will occur when in a turn like he was. best seen in my latest edit, test number 6

HARM-POS-PB_SA-11_5.trk @Lord Vader i was able to reproduce it to some extent. in POS-PB, the "footprint" of the HARM is relatively narrow. by designating a emitter outside of said footprint and then turning towards it to get the emitter within the footprint, the SPI doesnt seem to update and hence the harm "box" in the hud never starts flashing, preventing a weapon release did it on both occasion using OPs track and taking control right form the beginning, first designating the launcher (11), no box was flashing until i undesignated the emitter on HAD and re-designated it, with the emitter now being within the HARM footprint. the exact same happens on the second HARM i launch at the SD Edit: used my own test and did exactly as described above, did reproduce the issue as described by OP HARM-POS-PB_SA-11_6.trk

i do see what you mean. despite master arm being on, the box symbology on the HUD never flashes (flashing would mean you are within release parameters) and hence the missile isnt firing despite wpn rel being pressed. you are however relatively close to the target yet given the HUD symbology and the DLZ, you are not yet min-ranging it, so HARM should fire.

tested it on my end with no issues at all. i tried it in various different ways of designating, immediately at the start as SD appears on HAD, only when it is PGM2, with pullback and without pullback, after stepping through the emitters first before firing etc... in all cases every HARM did fire even at the SD on first press of WPN release button and i didnt even fly the perfect pull up in degrees as the distance is so close. HARM-POS-PB_SA-11_3.trkHARM-POS-PB_SA-11_2.trkHARM-POS-PB_SA-11.trkHARM-POS-PB_SA-11_4.trk As vader suspects there might be something funky on your end of the install. maybe mods, maybe something else

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