Voy

I get what your saying, but it genuinely does not sound like the same person. I just booted into the Apache to make sure I'm not going crazy, I mean even the way things are emphasized are different. Also I just noticed the order of the voice messages in the last video is different in DCS. Here's a more clear example:

Hi all, I was wondering if anyone knows if the bitching betty voice in our Apache is authentic or fictional. I've came across a few videos of AH-64Ds and their version of betty doesn't even sound like the same person. Example: Just found it interesting, curious if anyone has any insight.

Ok, thanks guys.

Hello, I'm not sure if this has been reported already or not, but when playing multiplayer with a human CPG, our FCR pages are not synced, I cannot see what they are doing, what targets there are, etc. Also, on the TSD, the radar cone graphic is never facing the correct way, it's usually just off to one side despite actually looking forward. No mods, I ran slow repair, both me and my friend experience this issue. I have a video recording of the issue, but I'm not sure how tracks work with multicrew, is it just the same process as doing it in singleplayer?

I'm not sure what you mean... I think you might be confused what this thread is about.

ED added the Lamp test to the BIT in the last update, as well as more realistic BIT pages, one small step closer to feature complete.

Since OP never attached a track of the issue, I'll provide one and be as clear as possible of what the issue is. Issue: Symbols on the RWR's azimuth indicator do not change their position while the aircraft is maneuvering. In fact, aircraft heading is not taken into consideration when displaying emitter symbols. The only way emitter azimuth is updated is when the emitter scans the aircraft again with their radar. This means if the emitter has a slow scan rate, or is placed into the RWR's blind spot, the symbol will stop moving entirely until the emitter is re-detected. Expected Behavior: Symbol azimuth should update when aircraft heading is changed. See this thread explaining why this is a little more than just a hunch. Until the ED Team explicitly says that this behavior is correct, we'll continue to assume this is a bug due to how much of a huge oversight this would be in the real aircraft, given how it is a huge hit to situational awareness, and being able to properly defend against radar threats. F-16 RWR Symbols While Turning.trk

As far as I can remember, the symbols always acted as they do now, I made a post in wishlist about it a while ago. So I don't think it ever worked "normally". Regardless, I'm also of the opinion that emitter azimuth should update when aircraft heading is changed, not just when that emitter scans the aircraft again. Unfortunately, I don't think anyone will show up with publicly available documents saying so, it is more of a common sense thing.

Interesting, thanks for the info. Any idea for "IFF"?

Is that a real thing in the block 50 F-16?

Hi all, I was just wondering if anyone knows where the "Jammer" and "IFF" Betty callouts in the F-16 are actually used. It can be heard in the audio/lights BIT, but I've never heard them while flying. Or is this something that was leftover from older F-16 blocks, and not in our block 50.

Why was this marked as "pm evidence with references", is it correct as is?

Datalink targets on the radar & HSD always have their altitude displayed as 2 numbers, so if they are <= 9,000 feet, their altitude is prefixed with a 0. (i.e: "09") However, on the radar, if you bug/lock a target, their altitude is displayed as 1 number. (no preceding 0) But, that locked target's altitude is displayed as 2 numbers on the HSD. My guess that this inconsistentcy is a bug, but not sure which is correct. Additional note: In the track, the target is set to fly at 6,700 feet. The datalink shows the altitude at 6k, but the radar shows it at 7k. It appears the FCR and datalink round altitudes differently, this also might be a bug. F-16 altitude radar display.trk

I believe adding text outlines to the TGP text is on the roadmap, I assume this will also be true for the Maverick page.

Unknown emitters on the RWR always have the highest priority threat diamond on them even if other emitters are actively guiding a missile onto you. Additionally, unknown emitters seem to always be in the inner threat ring on the RWR regardless if they're locking/guiding anything. This might be the actual intended behavior, but I couldn't find anything in the user manual talking about this, so I'm assuming it's a bug. Attached track shows an SA-10 guiding a missile onto me, with a couple of Silkworm search radars (Which show up as Unknowns) nearby. F-16 RWR unknowns highest priority.trk