Rhayvn

I would be happy to send the track file, but I can't get it below 9M and the limit here is 5. Is there somewhere else I can post it and give you the link?

I have been seeing, more and more frequently, that SAMs explode almost immediately after launch. This seems almost to be at random at mission start as sometimes, they work and other they have the issue. This is fairly game breaking as you can not predict when it will happen and makes any SAM related balance unpredictable. This error is present in the logs for each launch: ERROR SOUND: invalid host_params(MAIN_17098752/weapon): orientation They explode so quickly, tacview thinks they damage the launcher/launching ship:

Heya Folks, I am looking for a way (Moose/mist/ME) to enable a CV group to have two stations. By that, I mean the first station is WPs 1-6. WP 6 has a command to switch WP to WP 1. This works fine and the ship cycles through it's pattern. What I can not figure out, is if I also have a second route, with WPs 7-12, how to make the ship 1) go to WP 7 and 2) return to WP 7 when it hits WP 12. This is easy for a ground or air group, you just tie the go to waypoint command to a trigger and when that trigger is set, the group changes to it's new pattern. WP 6 can have the command to switch to WP 1 and WP 12 can have the command to switch to WP 7. Ship groups, however, can not do this. First off, they can only select a WP to go to from SP to 9. You can not use WPs 10+. Also, if you have the change WP command at more than one WP for the group, changing one, changes them all. No matter where the command is in the route, changing one to WP2, changes ALL of them to WP 2. That includes if you put them into the Triggered Actions section of the group. Changing the destination WP changes it everywhere. So, if anyone has advice on how to use Mist/Moose or other script to set a new WP for a ship group, please let me know. Thanks,

Hopefully an easy question. Once you create 10 TOO targets. The 11th is still #10 and I can't find a way to clear them or start over at #1. Can you just enter the number you want after you hit the TOO button? So, if I want it to be target 2, but when I hit TOO, 8 shows on the up front display, can I press 2 and override it? Have not had time to try that yet.

What altitude are you dropping them from? I am having issues with the bombs falling too fast when dropped around 20k feet. They seem to track ok until they exceed a speed around 500kts and then become erratic.

Is there no horn silence command? I looked for one, but hearing the horn on a long descent is beyond annoying.

Please allow us to fix it until/if you get around to it. It's well and good to say you need to fix it, but, the RAM air for example, was reported YEARS ago.

Eagle Dynamics\Custom\Mods\aircraft\F-16C\Cockpit\IndicationResources\Displays\MFD_stroke_font.svg Readability for the MFD font for those of us that have trouble reading the white text. Eagle Dynamics\Custom\Mods\aircraft\F-16C\Cockpit\Scripts.fonts.lua Eagle Dynamics\Custom\Mods\aircraft\F-16C\Cockpit\Materials.lua Eagle Dynamics\Custom\Mods\aircraft\F-16C\Cockpit\Scripts\Displays\Common\indicator\StrokesDefs.lua Readability for the HUD, similar to the MFD, for those that have a hard time reading the default. Eagle Dynamics\Custom\Mods\aircraft\P-51D\Cockpit\Scripts\clickabledata.lua Fix for the RAM air control. In the default aircraft, you can move the control, but it does nothing.

Another example to make it more clear. These two aircraft are flying in close formation. I locked one up, then dropped the lock. Notice the one I locked and dropped, is frozen at the point I dropped the lock. The other on is constantly updated by DL. My radar is actually painting both, but the original dropped track is frozen at that dropped location.

If you lock a single target, or a second one in DTT, and lose the lock, the track is frozen on both the FCR and HSD pages. The target at 06 has been dead for over 5 minutes. The one at 18 is 20+ miles from the shown location. This is with an AWACS airborne that was showing those tracks on the HSD before I locked them. If I find the brick and relock the original target, the track updates it's location, but I get no datalink indication of where it is after the lock is lost. None. It's fozen in the lost lock location on both the FCR and HSD. Another example: The target at 32 was locked by me and then dropped. It is actually about 5 miles in front of the target at 26 at the time of the screenshot. But, the datalink is only updating the one, of the pair, that I never locked up. At this point I can turn in and re-acquire the target that was at 32 and the track will update based on my own radar lock, but never again by datalink. The only way to clear this seems to be switching from RWS to TWS or vice versa. This also only seems to happen with the last two tracks locked. Locking a third, removes the ghost of the first. This makes using the radar in a datalink environment highly problematic as not only are you not getting the right information, you are being shown out of date information. This also shows the ghosts when not using datalink at all, but I could understand that scenario as long as they eventually aged out or had a button to clear.

Seems to cause crashing with todays patch. Specifically seems to happen on shot down aircraft impact with the ground.

A few issues: There is incorrect symbology on the FCR now. A non datalink symbol is overlayed on top of the datalink symbol. This only happens in RWS SAM mode. Not in the others. Antenna elevation is not adjusted automatically. If the track goes outside of your scan zone, it will drop soft lock. This may be intentional, but it was not like that previously and is not like that for TWS or STT. 120s fired at a SAM target do not loft. The otherwise perform normally, but definitely do not loft. The same target in the exact same parameters will have the 120 loft if fired in STT or TWS. Bottom line, only partially fixed.

A few issues: There is incorrect symbology on the FCR now. A non datalink symbol is overlayed on top of the datalink symbol. This only happens in RWS SAM mode. Not in the others. Antenna elevation is not adjusted automatically. If the track goes outside of your scan zone, it will drop soft lock. This may be intentional, but it was not like that previously and is not like that for TWS or STT. 120s fired at a SAM target do not loft. The otherwise perform normally, but definitely do not loft. The same target in the exact same parameters will have the 120 loft if fired in STT or TWS. Bottom line, only partially fixed.

Happens fairly often and seemingly completely at random. Either with HPTP or without.

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.