Rhayvn

When using dual AWACS, the AWACS keybinds only seem to work for the first AWACS on the comms list, no matter what comms channel you are actually on. Is there a way to change that so that the keybind will make the request on the actual selected channel and not to a specific AWACS? Voice Attack does this, so it's possible.

What you are not showing on your screenshots is DL tracks or threat rings with type numbers. Those are faint and the altitude/numbers difficult to read. The TGP isn't an issue because the adjustments on it have enough range to compensate for the different lighting conditions. 1.6 gamma is not exceedingly low. I have used 1.5 or 1.4 for the entirety of my DCS experience and never had an issue until 2.7 with the new cloud shadows during mid day times. We all have different visual preferences for eye comfort or spotting/reading small details. It changed in 2.7. The Hornet used to have an issue with MFDs in certain lighting conditions, it was changed to make them easier to read because we don't have options real world pilots do to mitigate lighting problems. As one of those real world pilots, with various aged avionics displays that I can easily read in all lighting conditions WITHOUT them being at maximum brightness, this simply isn't something that would persist in reality. Forcing an overall graphics change (Gamma) to fix one small aspect of visibility is a poor alternative when allowing a greater range to the brightness controls would do the trick.

This was somewhat reported in the weapons bug area for 2.7, it is happening very frequently. If the 120 launched from the wingtip needs to make any course correction on launch that is parallel the the plane of the wings, especially inwards, it will almost always at least damage, if not destroy, the wing it was launched from. I do not have the ability to post a track file right now, but this is happening so frequently, I am hoping others chime in.

The contrast is set to max as well. Does not seem to help. I am fairly surprised this isn't a more commonly reported problem. Every single one of our F-16 members has it. Especially the VR folks.

They are at maximum brightness. This only occurs with the new cloud settings and only mid day since the patch.

I have changed nothing since the 2.7 patch and had no issues at any time of day prior to this. Again, all of my group are having the same issues and we are a mix of hardware, VR/Track IR and settings. It's based entirely on time of day. I realize my gamma is low, but every other aspect of the sim looks great and this was the setting I found helps the most with visually finding other aircraft. I have to turn the gamma above 2 in order to read the MFD, which makes everything else in the game look overly bright and washed out. Settings: 7AM local time. MFD is easily readable. 1300 local time. MFD is barely readable. Gamma turned over 2. MFD is still a bit hard to read and the rest of the sim looks overly white and not crisp on detail.

With the new cloud shading, there are certain conditions and times of day (Especially mid day) where the MFDs are extremely dim even at max brightness. Our entire group is experiencing this issue (F-18 and F-14 screens as well). When starting in the early morning, you seem to have more brightness control on the MFDs and the issue doesn't wash them out as much. Gamma can be turned up to help, but that does seems a poor fix for something that appears to be directly tied to the new clouds and how they affect in cockpit shading. Is anyone else experiencing this?

It has been repeatedly said that it is NOT a TGP slew and designate issue, it is the HUD CCRP indications and SPI markers not being synced to the TGP that are the problem. This interferes with weapons employment. You keep coming in here and claiming the problem can't be reproduced when you are not even addressing the reported problem. You have received multiple examples of an extremely prevalent and easily reproduced problem and each time, you refuse to test the actual issue and just repeat that the TGP is working as intended. It's been two months now that the F-16 CCRP and now MAV PRE mode when designating targets with the TGP don't work so often that those methods can't be relied on AT ALL. So, one last time: IT'S NOT THE TGP.

Every time in MP. This has been happening for a while. There is no point in repairing as it will be bugged every time.

From what I can tell, they inverted the X and Y axis and left the Z axis. The selections in the controls still don't change anything.

This is still an issue. The performance is utterly random. You can CZ and SP and occasionally the CCRP line will follow the SP mode to the center of the HUD and then follow how you slew the pod. MOST of the time, the CCRP queues stay locked on the steerpoint and WILL NOT MOVE no matter how many times you CZ and then SP. Then, completely randomly, the CCRP line will unlock from the steerpoint and move to the center of the HUD again when you enter SP mode. It might then work 1 time and then break again. It might work for 2-3 minutes every time, then break again. I have flown in a straight line and pressed CZ and SP and nothing else and watched it work differently. Completely random. It's easy to reproduce the problem, but virtually impossible to correct it. The issue appears to be that the CCRP data is locked to the HUD target box. If you make the HUD SOI, the TGP will snap to where the HUD target box with any touch of the slew controls is every time. But, you can not get the reverse, where the HUD target box follow the TGP when the TGP is SOI. It is infuriating and means the TGP is STILL so unreliable as to be a terrible loadout choice since you can't predict when it will break and you can't reliably correct it. The most often fix seems to be change from CCRP to CCIP, then back to CCRP and try to press SP on the TGP. If you are VERY lucky, everything works right. With no telling when it will get disconnected again. It has been over a month since this bug was introduced. Have we even gotten a confirmation from ED that it is an issue? It's not just me either, every person in our group has the same issues in both single an multiplayer.

External view control changed in this patch. Marking the Invert Axis for Mouse X, Y and Z does not reverse the behavior as it used to. Camera Horizontal Camera Vertical Camera Zoom

It's inconsistent. Sometimes it works exactly as expected and you can move the hud cursor and the tgp moves with it. Other times, hud cursor doesn't move. Others, you can move both, but they aren't slaved. I did it over and over again with the exact same steps and got different behavior, seemingly at random. There should be some method to target within the hud fov, like the old boresight. The current SP, being fixed a specific distance, no matter the roll or pitch of the jet, is virtually useless unless you align your nose, set it, then slew the pod upwards. That's needlessly cumbersome compared to how the Lightening pod works on every other aircraft. Additionally, if you change the steerpoint, that location you just worked to find is GONE. Unless you WRITE down the coordinates shown on the tgp display and make a new steerpoint with them, there is no way to go back to that location again. Lat/Long on the display and TTI is nice and all, but the new pod, unless used on a nice fixed steerpoint against stationary targets, is absolute garbage compared to yesterday. That doesn't even touch the issues with adding in the visual changes without giving tuning capabilities to actually have things stand out from the surroundings. Horrible choices on implementation.

It's not just the altitude numbers on the FCR, it's also the elevation indicator and while it wasn't many tests, the tests done showed no indication that elevation or depression were happening. Targets outside the listed altitudes on the FCR marker were not detected no matter how the settings were manipulated.

So far: 1. HUD and HMD brightness is very low at max brightness. It's virtually impossible to see against light backgrounds. 2. Radar Antennae elevation controls do not work. Keyboard or bound. 3. New Steerpoints show HUD symbology and are usable by the autopilot. Preset steerpoints show no HUD symbology and are not steerable by the autopilot. 4. TGP designation vs CCRP target is ~100 yards offset. Point track on the TGP does not correspond to the actual ground targeted location for the CCRP cues. Possibly using the wrong altitude for the coordinates? The 16 is FAR more broken than it was two hours ago. But hey, we can manually add steerpoints!!