TZeer

But I don't understand why they push unfinished FM changes to the live build, if it's a regression in overall FM quality. If the change improves the HOLD function, but the overall feeling and quality of the FM is worse. Then the FM change is not suitable to be pushed to live build. Quite simple really.

The insane part here as well is the premium they are charging for it...

Doesn't matter what cable they use. The problem is that there is no monitoring or any system in place to let you know if one wire starts to draw more current than the others. I think there are a few partner cards that have possibility to monitor if there is uneven distribution, but that's it. From the info and reports that have come so far it seems that it's so small safety margins that even doing everything correct will not guarantee you not getting hit by the problems. This was demonstrated by a guy where he plugged in the card 2 times with the same equipment, one where everything was within spec, and one where the the current in the wires where out of spec. Nothing physically changed in the setup. And with the small amount of 5090 cards that have even hit the market it's worrisome.

In general: 1: No, the cable is similar. The cable is nothing high-tech. Problem in the video is an extremely uneven distribution of power through the different wires. Some of the 3rd party cards has monitoring to check for these problems. But Nvidia founders card has not. But regardless, it's a <profanity>ty design and extremely poor QA from Nvidia's side. 2: It depends how much load there is on the GPU.

Seems the 5090 is even worse than the 4090 when it comes to potentially melting cables. 130-150 degrees celcius on the actual connection. Uneven powerdistribution through the cable. Does not look good.

I have seen the same behavior when flying low. Specially when flying helicopters. If I look straight ahead, it sometimes goes ok. But as soon as I turn my head and look into the trees my frames take a dump. It's not as noticeable on desert maps. But very easy to trigger it if flying low on the Caucasus maps over larger areas with trees. I also get it every time I fly low on Syria in clusters of vineyards. At a certain distance the frame time spikes.

I'm mostly a rotorhead, but I was surprised (in positive way) on the announcement for the F-35. No one is forcing anyone to buy or do anything with it. Servers can restrict the use of modules based on what kind of gameplay they want. This can be an interesting module to play with

To bad, I've had my eye on this for a while. Just been waiting on it to "mature". Guess I'll hold on to my money for a while longer...

I did some testing now, and it seems the CAS still give some input to the YAW while on the ground.

Do you have the latest version of DCS installed? I know it had that behaviour before. But should be greatly improved (fixed?) in the latest version.

Changed to the Huey to see if that helped. But still get the occasional drop in performance. It ssems to be correlated to bushes/trees/vineyards. When I get to close, the performance drops enough for my CPU to become a bottleneck. Get some distance or look the other way and the FPS goes back to 72 FPS...

I will upgrade to 9800X3D when they come into stock. But as it is now, everything is sold out until February in my country. Anyway, I upgraded my old 5800X to an AM5 platform and snagged a used 7900X CPU as a temporary solution. I use a Quest Pro, and I was surprised that my 7900X was the bottleneck when flying in somewhat isolated part on the Syria map in the Apache. I do use the Foveated Rendering, so I guess that might put an extra load on the CPU. But was hoping I could hold 72 FPS flying around in a sparsely populated area on the map. When using the 5800X I used Nevada mainly, due to how easy it was on the system getting 72FPS. My GPU is the 6900XT, and I have dialed in the settings so I'm getting up to around 90% utilization, before the CPU get bottle necked and cuts my FPS in half. I have 72 FPS while taking off and 90% of flight. I have already closed out all useless background apps. I have a optimized win 11 installation done with a custom ISO file made with winutil from christitus. https://christitus.com/winutil-install/ Any specific settings in DCS that heavily goes on the CPU that I can optimize? Or is it just wait until I get hold of an 9800X3D? Or keep flying on Nevada map?

Did some testing now, and I must say I'm very happy with the improvements. Feels much more controlled on the yaw. Very noticable while taxing. I have a Virpil pedal with a dampener-mod, and even with that setup the tail had a tendency to violently kick out when trying to do a turn while taxing. Now I'm able to do a much more controlled turn. I also noticed the constant oscillating behavior of the yaw is gone while flying straight. And the much more controlled behaviour of the helicopter when going into hover from forward flight. Before the change there was like a rug getting pulled out beneath you when getting below a certain speed, now it's actually somewhat predictable. Great work @Raptor9 and the rest of the team. Looking forward to the next improvements in the FM

Is the excessive sideways slip fixed as well?

Good news. Meta decided to do a full unit replacement

So, I got hit by this bug after I updated my VR set. I was way behind on the software, due to the previous bug where DCS did not work properly with Quest Pro and Quad Views. After this was fixed I updated my software and I was greeted by this bug a soon as I tried the VR set. I can use link via WIFI, but link refuses to work as it deactivates the USB-C port. Has anyone else had this bug? And have you been able to fix it somehow? I'm currently in touch with Meta Support, and have done everything from soft reset to factory reset, but no joy. Also on latest V69 software now. Message popped up as soon as I had set up my VR set and tried to link it to my computer. https://communityforums.atmeta.com/t5/Get-Help/Known-Issue-V65-V67-USB-C-Debris-Water-Warning/td-p/1196806

It was a joy to test out nightvision again in the apache now. Thanks!

I think why this has come up as a discussion time and time again, has just been due to some information being "lost in translation". Raptor gave an answer some time ago that it was due to calculations for the radar elevation setting. Which is correct. At that time I didn't quite understand why the calculation of the elevation setting should have anything to do with losing ability to find targets with the radar if the TADS didn't have a LOS. Anyway, they had control, Raptor replied that it was known and being worked on. Could not ask for more But now Raptor just dropped a bit extra info in this short explanation: So if those two factors are intermingled in the code that determines when the radome sees a target, it makes perfect sense. I'm just taking a wild guess here, but I guess the height over terrain "value" that was used in the code, did not take into account that the radome was positioned higher than the actual airframe/reference point. Example: Altimeter in whatever airframe has 0 feet when wheels are on ground. But the Longbow Radar is actually roughly 16 feet above ground. If they have used a value that was already in the code from some other part in the coding, not uncommon in coding by the way. And not taken into account that the radome is X feet higher on the airframe compared to whatever value they might have used from some other place, it explains everything. - The issue is tied to the radar elevation calculation that Raptor mentioned earlier, and did so multiple times. So he is 100% correct in his earlier statements. - But it also explains why the radar lose lock when we lose TADS LOS. If the reference point used in the current code is roughly at the same height as the TADS on the chopper, it will lead to a loss of targetlock roughly at the same time as the TADS lose LOS. There are multiple places they can have gotten a height value to use in the code that would have given wrong calculations: - Altimeter - George AI coding for simulating LOS via TADS etc - " Zero" point on the airframe ( X, Y axis on the 3d model) @Raptor9 We as a community really appreciate the time and energy you sacrifice to help, guide and support this product. I can only guess how frustrating it can bee trying to educate some of us "sofa pilots", specifically when some of us are trying to tell you how the machine works, when you actually have hundreds of hours in the real thing.

Plenty of tracks in this thread Just out of curiosity, how do you, the beta testers, verify that the simulated radar beam originate from the actual dome, and not from a "lower" position on the helicopter model? Do you have access to some extra tools? Anyway, looking forward to the fix

I know how the forces behave. And I fully expect the forces do what you say. But this behavior with the SCAS/SAS is well documented and known by the SME's. The relative large change in rudder input needed over a short period when crossing the "threshold", can be explained by the excessive lateral push made by the tail rotor. This excessive push is also the reason the Apache has the exaggerated "crabbing" movement when flying in aerodynamic trim. When that issue is sorted, my guess is that the transition between forward flight and hover will become smoother. It might be something entirely different, but from what I have understood so far after flying and reading the documentation and what the SME's has written, everything is connected with everything in this flightmodel, and it's a complex piece of software to tune.

That's my experience as well. It's really smooth and nice when you get a little speed (except for the issues you mentioned), but below 30 knots it's "unstable". You hardly need to do anything on the YAW while flying, but when transitioning below 30 knots and in to hover, I feel a lot of the change on the pedals need to happen on a relatively small amount of change in forward airspeed. There is also still some input from the SCAS while on the ground. According to the manual/documentation, the SCAS input to the YAW channel should not happen until the "weight on wheel" switch indicates that the Apache is in the air. This leads to this unpredictable YAW when taxing. It's amplifying whatever inputs you give, making it very easy to "overshoot" when trying to turn while taxing. It was worse before, but you can still see the SCAS giving inputs while on the ground. BUT, the FM has improved over time. It has gotten more stable, breakout values on the YAW has improved, doesn't "fight" you as it did before. If they can just iron out those 3 last issues it will be really good.

It's great to fly... BUT, there is still some WIP in the flightmodel. Most annoying thing for me is the constant "unstable" yaw channel. Unless you hold the trim reset or activate the attitude hold in forward flight, the yaw can start chasing left/right. Sometimes it's hard to see, sometimes easy. But if you pay attention to the FPV while flying, one can see the FPV floating left/right while flying straight. Press the trim reset and it stops. Then after a while it can start doing it again, first small, then increasing over time, up until you can see the entire airframe is turning left/right. Apart from that, the airframe is really nice to fly. Once that issue is solved, the Apache will become even more stable.

Looking at the leaks so far it brings a complete new gameplay into the DCS World. M4 shooting from inside the chopper, live feed from drone etc.

This is gonna be buy on first day!

@SkYwAlK3R-_ Try this: Shadows: Flat only SSS: Off Visib Range: High Terrain Objects Shadows: Off Shadows can be taxing on your system. Im running an AMD 6900XT overclocked on an AMD 5800X, I have the above settings right now, on top of that I'm running foveated rendering on a pair of Quest Pro. WIth those settings I'm not always able to keep the framerate @ 72FPS even on Nevada.... All depends on how many units need to be rendered in the background.