Floyd1212

As you probably already anticipate this, the response there would be Early Access is not mandatory, and is there for those that want to get in early, with the expectation there will be issues along the way.

+1 I have yet to see ED acknowledge that they even understand the problem they have created with this "feature" in any of the threads discussing the issue. At one point BIGNEWY said the solution is for the mission designer to set the units to "Hidden on MFD", but this is broken, and does not work properly in all situations. Please ED, give us one of two solutions until you have a fully-featured DTC implemented. 1) Make it an option that can be enabled/disabled in the special settings, or 2) give us a command to use after startup to wipe all threats/targets from the database at once.

Thanks for the updated config. I gave it a whirl, and I'm seeing a lot of yaw adjustment is needed while ATT Hold is enabled. It feels like there is no SAS helping to hold the nose at the desired heading at all, like the "breakout" percentage is down at 0%. Is this what you are going for? (I'm using pedals without a spring, btw.) For the ALT Hold, I am getting the large vertical oscillations still. In 2a) are you saying that the ALT Hold is still bugged, even with this config?

This is new behavior with this patch. You used to be able to arm the chaff before lifting off. But if it is correct behavior, we will learn to live with it.

Yes, many are able to fly just fine and enjoy themselves. Have I had to learn to adapt to some of the quirks in the FM? Yes. Do I regret purchasing the module in the EA stage? Not at all. It may not be for everyone, though.

Yes, there are some redundant controls between the TEDAC grips and the flight controls. When controlling the TEDAC as CPG, the controls you need to worry about are on the LHG and RHG.

It's a little bit different than your two examples since those require you as the pilot to take a moment to press a button on your joystick, or to look down and use the mouse to press a button in the MPD (or if you have a screen in front of you, for you to reach your finger out and press a button). Think of it like opening and closing the canopy door; you can map that function to a button on your HOTAS, but it still takes a moment for it to execute in the game.

This appears to be fixed with today's patch. I looked at the PrestonAI_page_common.lua file that I normally have to modify after each release to get George working again, and I noticed this section of code got re-written. I didn't modify anything and fired it up, and George is working. Thanks ED!

Yeah, ALT Hold mode is not working properly for me. I activate ATT Hold and ALT Hold while at a stable hover at 50 feet, and the helo will gain and lose altitude in long oscillations to a point where I even bounced off the ground. I really want to give ED the benefit of the doubt here, and that someone did some test flights before releasing this patch, and that I am just doing something wrong. Any advice?

This is because you are using a splitter instead of discrete outputs. To render something different on each screen, it needs to be a dedicated output from your video card. Do you have other unused ports on your card? DVI, USB-C, HDMI-Mini, DisplayPort?

Does the shake occur after you bring the engines up to full throttle ("Fly"), or only before? I was messing around in the TSD for a bit after starting her up the other day, and got some periodic shake while sitting with the levers set to "Idle". Once I bring them up to "Fly" I don't experience the shake again.

You will find a lot of people use an XBox controller as your left-hand and right-hand grips on the TEDAC. You can see some recommendations for how to map those buttons to a controller like that in the Controller Questions and Bugs subforum. When I am in the front seat (which isn't often), I use the controller in my hands and then occasionally use my mouse to click in the cockpit. In conjunction with head tracking, I rarely need to put my hands on my cyclic or collective. I have a button on the controller to toggle between free-looking around the cockpit and out the window with my head-tracker, and to a snap-view of the TEDAC pretty much full-screen. With my wide monitor I get the TEDAC and both MFDs filling my screen. Things are going to get more complicated when IAT and FCR are implemented, but for now there are plenty of buttons.

I occasionally get artifacts as PLT when I am viewing the CPG TADS video on one of my exported displays, but it isn't really a "flickering" as much as a black object moving across the camera quickly. My CPG complains of similar issues while sitting in the front seat looking directly at the TEDAC, and he is not exporting any displays. I never get any flickering or other artifacts on my exported MPDs when looking at other screens.

Can anyone tell me what the default value for this parameter was?

It is likely that your HMD is the current Sight, and so it is therefore unavailable to be the Acquisition Source at the same time.

Glad to hear it!

It does fail IC, BTW. I flew with it for a bit, and it definitely tames the SAS for the collective channel. It would take some time to get used to it, though. Definitely has a different feel, which I noticed the most when coming in to a landing. I switched it back to normal so I could go fly with some buddies, but I might try it again. I didn't test the yaw tweak, or adjust the shake value. Thanks for sharing!

Very interesting. I will take a closer look at this... Any idea if this impacts IC for playing on some servers?

Why do you need laser-guided rockets when you have laser-guided missiles?

The code in your snip doesn't really match the code in my snip, so I'm not sure what you were using for your starting point before editing. Your code is referencing a variable control_pos_offset that you don't have defined anywhere (that I can see). In my code snip, that variable is defined locally on line 34, but I don't see that line in your snip. I haven't taken the time to fully understand all the math that is going on in this code, but my assumption was that it finds your "main viewport" and places the UI objects relative to the center of that screen; meaning it should work universally, regardless of your specific multi-display orientation. But I could be wrong. It just occurred to me, looking at that block of code, that none of it runs if it can't find viewport "GU_MAIN_VIEWPORT". Do you have this last line present in your CustomMonitor.lua file? Beyond that, I'm afraid I am out of ideas...

Try "AH-64D_BLK_II"

I guess it really depends on what your actual problem is. If the problem is that the George interface is not showing up in the corners of your primary display, this is the fix: And this is my PrestonAI_page_common.lua file, which is working for me: PrestonAI_page_common.lua

There are examples directly above in this thread. ED, can you mention this to the devs, again?

Thanks for the feedback. I did not add any friendly air patrols or attack helos that take off from friendly airfields. I can see how that might be helpful if you are playing it solo, though. I was mostly playing it with a small group of friends and we were often 2 Apaches and 1 Warthog. Maybe I will go back and add some additional AI help. Even if they aren't super effective, they also add the immersion, like you mentioned. I think the friendly CAP that you call in with the comms menu are getting distracted and drawn into dangerous territory. That being said, if you are just getting started, it is all dangerous territory. There is definitely some fine-tuning that could be done there, and I probably have them pushing too far the way they are setup right now, but I also think the smaller area has something to do with it. When they get shot down, I just call in another patrol. If I go back and make changes, I will be sure to post the new version here.

I can confirm this still happens to me as well.