Floyd1212

While tracking the target, move the TADS cross-hairs to a different position on the unit and press IAT Fwd again. It's the same procedure like you are adding a track to a new vehicle, but if you are already tracking that vehicle, it updates the position.

You are probably hearing "RPM Low". This happens when you are too aggressive on the collective, and pull too much pitch all at once. When you yank on the collective, the pitch of the main rotor blades change suddenly and there is a lot of resistance on the blades as they push through the air. This causes the rotor system to slow down and you get the "RPM Low" warning. The opposite will occur if you are flying along and all of a sudden drop the collective to the floor. The rotor system will have little resistance as they blades easily slice through the air and you will get "RPM High" warning. Bottom line: make gentle adjustments on the collective, especially when lifting off the ground to a hover.

If employing a real bug-tracking solution is off the table, perhaps using the "forum tracking" method more effectively could help? Create a sub-forum for bug reporting, and move the posts to another sub-forum when they have been accepted by the devs, then move them to another sub-forum when they have been resolved. This means there are shorter lists of posts in the reported and accepted forums for users to look through and understand what has already been reported and being worked on. Don't let just anyone post a bug report. You've got a nice readme pinned to the top of the forum, but apparently not very many people are reading it. Allow users to submit their reports for a moderator to approve before being posted. If it doesn't contain a comprehensive screenshot, a video, or a track file, don't accept the post. Ask the community to help confirm the bug by reproducing the bug with the included track file on their hardware before moving it on to the devs to look at. This is all just brainstorming for 5 minutes while I write this, but you get the idea. The bug reporting system in place right now is not working for the community, and probably not working very well for the devs, either. If nothing else, realize that you have community members that are taking the time to create concise bug reports with steps for reproducing the issue, and including the requested track files. At a minimum, come up with a reliable method for seeing them, downloading and viewing the track files, and processing the reports that are generated.

Going up against SAMs is one of my favorite things to do; much more exciting than plinking targets out at 8 km that don't even shoot back. For a particularly nasty SAM, LOAL is the way to go. You can use George in "No Weapon" mode to track the target from behind cover without lasing, launch your LOAL missile, then unmask and tell George to flip on the laser. Takes a little practice, but very rewarding when that Tunguska never even saw it coming. FCR is going to make this almost too easy...

https://forum.dcs.world/topic/312011-atgm-hit-destroyed-tail-but-anti-torque-rotor-still-active/

Today is your lucky day. Check the patch notes for the patch released 2 minutes ago...

As someone who makes large missions for my group of friends to fly, having the default to hidden on MFD, and the option to show the few units I may want to reveal would make a huge difference.

There are a couple things going on here... If you perform a "trim reset" while in forward flight, you can expect the nose to come up abruptly. You need to anticipate this and quickly move the controls to the previously trimmed location to counter this, or only use the trim reset function when the virtual controls are near their center already, i.e. when in a hover, and not in full forward flight. I posted a video in this thread on how to use Joystick Gremlin to avoid this problem when using Trim Reset. New-comers to the Apache might find it useful. I haven't heard of others experiencing the issue with the axis being ignored like you are describing. If you are using Central Position Trim Mode, is it possible you have some forward "drift" in your stick, and it is never registering as having been centered in the y-axis after applying the trim? You can try a slight deadzone to see if that does the trick. Your issue with the AT hold not working in a hover may also be because if drift in your joystick. The Attitude Hold is currently very "weak" compared to previous patches (like when Wags created that video), and it doesn't take much input from the controls to get the aircraft to override the hold and start to move out of position. Here is another recent thread that discusses that issue.

I do not have VR, so I have not tried myself, but I have read elsewhere that it does not work in VR.

The brightness of the exports has been an issue for a very long time, and is a problem with the core, not just the module. There are some threads about how to use ReShade to increase the gamma only on the exported areas, but you still have to crank the in-cockpit brightness to get anything workable on the external displays at night. lol, Apparently I already said that in the first page of this thread... Sorry.

Page 112 of said manual describes the FMC channels, and the UTIL page is where you can enable/disable each if you like.

There are two types of "misses"; both are annoying in their own way. Sometimes the laser is on the target the entire time, or at least for the last several seconds of guidance, but the missile still goes long/short, or falls behind a moving target. This is annoying because you feel that you (and George) have done everything correctly, but some mysterious glitch in the core engine is preventing the missile from hitting the target. Often times I will try a second shot, and the exact same miss occurs. This happens to me when I am in the CPG seat, too, so I don't fault George for these. Other times, George seems to wander off target and the missile ends up missing the target, but does hit where George happens to be lasing at the last moment. He seems to do better at close range, where the target is so big that when he drifts slightly the laser still stays on the target, and then further out around 7km where there is enough time for the aircraft to settle again after the launch, and George can get the laser back on target before impact. I'm sure we will see some improvements to both of these scenarios in the future.

This does sound useful. I typically use the SAT map as it shows the most detail, but I would switch to the DIG map if these features were displayed.

If you would like to make a video to drop some knowledge bomb on all of us, go right ahead. I think the official stance from ED is that this is currently an over-exaggerated behavior that will be toned down as the FM is refined.

It's called "Save Cockpit Angles"

Wags also has the official ED playlist on YouTube https://www.youtube.com/playlist?list=PLer9oF4AanvF7CTss44TU4aDOxb5A9Jic (Not sure why a dinosaur video comes up as part of that playlist, but the other 32 videos are helpful.)

Was there a waypoint predefined in the ME for that aircraft? Did you accidentally add a point on the TSD yourself?

Do you have any friendly units at your bullseye location? There will be a lot of Control Measures pre-populated in the TSD for your friendly units when the mission starts.

In the Apache, besides at startup and shutdown, there is not much need to adjust the throttles. You set them to FLY and away you go. I think a lot of people, myself included before I bought a collective, map one of the throttles on the HOTAS to the collective axis, and the unused one just comes along for the ride. I use mouse and keyboard during startup/shutdown to manipulate the throttles in the cockpit.

I would second (third?) the recommendation of replacing the Warthog base with something with cams and springs, and re-use the Warthog grip. I personally like a lighter spring and a smooth cam, but any of the quality bases are better than the Warthog base for fine control around the centered position. The Warthog throttle can work fine for the collective, though I recommend the mod to replace the cursor nub with a better analog stick. There has been some good feedback in another thread for the Flight1 Falcon S1 pedals, which seem to be a pretty good bang for the buck. When flying in the front seat, an Xbox controller will give you most of the controls you need to manage the TEDAC and sensors, at least until the FCR is added.

It isn't that the SCAS doesn't have enough authority to counter the small amount of drift on your stick, it just isn't doing it. I just flew another test thinking I would try removing my curves and even try the FFB mode to see if I could reproduce the results you were seeing, but even without any changes to my axis settings, if I move my stick so that the white diamond moves off of the red X by a similar amount to what your track shows, I start drifting off and it doesn't hold position. Interestingly, if I slowly add some pedal I can get all the way to the edge of the light gray SAS authority box before it finally breaks free and can't keep the heading. It seems like with the current way ATT Hold is working, it is super strong in the yaw channel to maintain the heading, but super weak in the pitch and roll channels, and it doesn't take much movement of the cyclic to get it to drift. This is probably a change in the FM from before, when you weren't having an issue.

Yeah, I could see how the settings I am using wouldn't be compatible with a FFB setup. Regardless, it appears the drift when you take your hand off the stick is what is causing the issue. In the past, the hold modes were rock steady, but as they have made changes to the flight model it has changed. Hopefully they will get things dialed in and it won't be so sensitive.

I played back the track and saw what you were experiencing. I then took control of the track and was able to get it to settle into a stable hover with ATT hold. In your post above you state that you have no curves, deadzone, or saturation. I think your issues are a combination of your hardware, and your current trim and axis settings. Or more specifically, not having a curve or deadzone on your axis for your given hardware, which looks like it wants to drift a bit. After you trim for the final time before engaging ATT Hold, I can see your inputs on the cyclic jump slightly (as a result of the Instant Trim) and then when you release your stick the white diamond does not stay centered on the red X, but instead drifts forward on the first attempt, and forward/right slightly on the second attempt. I think without any deadzone, or curve, this tiny bit of input is enough to cause the aircraft to drift. I fly with an extension on my stick, a curve of 15, saturation of 90% and a deadzone of 2. I also fly with Center Trim mode. When I trim for the final time, then enable ATT hold, there is no jump of the inputs, and with the deadzone and curve on the axis, when I take my hands off the stick, there is no deviation between the red X and the white diamond, so I am not influencing the aircraft at all. I would definitely play with a curve and especially apply a deadzone for your stick axis. And maybe check the calibration of the stick to make sure it is as centered as it can be. If you can't get rid of the drift in the hardware, a curve will help reduce the amount of influence the input has on the aircraft, and a bit of deadzone would eliminate it completely.

Not sure if you are exaggerating here, or if it literally isn't doing anything for you. When I get into a stable hover and trim the aircraft with less than 3 knots maintained ground speed, then enable ATT Hold, the helo will maintain that position and heading while I adjust the collective to come up over the trees, etc. When I launch a missile, the aircraft will buck slightly, but will recover and maintain position.