Moonshine

Yeah same here. Very annoying.

that is true, and if its modelled in DCS as well then there is still something wrong with it as if it would use electro-optical tracker i should not get a launch warning either, similar to the HQ-7 and Rapier

as the title says: fly towards SA-8 -> you get lock and launch warning. defend the first missiles (usually 2). turn back into the SA-8 -> you will get missile launch warning but no lock-on warning prior to that. out of the encyclopedia the SA-8 is semi-active radar homing. if i understand that correctly, that should always give lock before launch warnings on RWR track attached. RWR_no-follow-up-lock-warning.trk

plane does roll right when a TGP is equipped as the TGP is on the right cheekstation. you can balance it out somewhat by also adding a HTS to the left cheekstation but its still not equal, so you will have to trim a little to the left. however it doesnt roll right when your jet has balanced loadouts (mostly when not having any pods at all) best way to try it out is a no wind mission (to avoid crosswind) and clean loadout. if the jet still rolls, then surely its not the planes fault

Furiz is right, i too moved from a vkb gunfighter mk3 (i have full linear axis settings, no deadzones whatsoever) to a realsimulator base and stick. I was by the impression that my vkb was very good yet as soon as i started using the RS setup i immediately noticed just how much better (less sluggish, no more delay caused by artificial deadzones) the force sensing stick is. now to not stray too far off of the topic here, i believe it does make a difference for aerial refuelling as due to the described „deadzone“ or „input delay“, you are always „chasing“ the proper position on the tanker and are always reactive instead of proactive, which might make the difference in staying connected or causing an unwanted disconnect due to overcorrection.

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