Moonshine

thats funny, i dont share this feeling about force sensing. moved from a VKB stick over to RS FSSB and the feeling of the jet was instantly better (more responsive, "snappier", instantaneous reaction to input...). tanking too felt a lot better as the jet reacted better to very small inputs and immediately stopped when no input is made. on the VKB i always felt my inputs are a little "delayed" compared to what they are with the current joystick. there does seem to be some "deadzone" for joysticks that are not force sensing. this can be an issue when refuelling hope ED can implement something down the line in the special options that would allow the player to choose the type of stick used.. this however might mean creating a second flight model in order to not worsen the situation for the people that do have force sensing sticks and thats a lot of work.

not sure if what you are reporting is related to this: if not, please attach a track replay

yes but that means it is also not detected by a C2 instance, hence no ROE has been decided yet. but what we are talking about is a contact, that on DL is shown as red (my jet does not yet see it yet, C2 however does and has marked it hostile). now that contact, as soon as my jet ALSO detects it, currently changes back to "unknown" at the very moment my radar paints it - even though C2 still sees it - which means i can not be the only one painting that contact... the current implementation logic is wrong and needs to be fixed. in addition to that C2 has marked it as hostile already, there is no need to also have to correlate that track with my radar/NCTR to maintain the hostile classification.

Exactly my point. The inability to set burst altitude at all for normal parameter drops is a different bug

im looking forward to see the implementation down the road. of course i am dropping "outside of parameters" for a normal CCIP release but that is clearly not what i am trying to do. while yes the bombs missing is correct if the intention and bomb settings were used as you would for a normal CCIP release, it is not correct for what i tried to do and what i am reporting. but its splitting hairs at this point. fact is currently using Nose fuze for CBU-87 during a low level drop will result in a miss due to missing implementation of fuzing options. the reason i reported a bug is because it did work in the past and now suddenly it doesnt anymore.

Then i don’t understand why its „correct as is“ since clearly it isnt. the thing i am reporting is the fact that the bomblets impact long of the CCIP pipper, which in the past wasnt happening and the bomb was on target even when using Nose fuze only for a low level release so the canister instantly opens after clearing the jet

im not sure if i understand this correctly, are you changing the manual so it reflects the ingame state or are you changing the ingame state to reflect what is correctly stated in the manual?

Exactly. Hence the title is specifically chosen that way… just „fly higher than 1500ft“ will surely solve the problem, however Nose fuze option was made for exactly when the situation requires lower ingress altitudes than the preset burst altitude… oh well… from the manual, page 348;

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.