PawlaczGMD

BTW, this issue is not unique to the P-47. A lot of old gyros drift so much that they are almost useless. Even the Ka-50 backup ADI drifts completely out of true within minutes and never recovers. I was under the impression that the gyro drift correction is not modelled at all TBH. Gyros should drift during maneuvers, but restore their true position in level(stable?) flight.

Sure - here I removed all deadzone from special options as well as hardware. A/P is not possible to engage in any mode. If I set some intermediate deadzone I can engage the A/P with some stick wiggling - but it's obnoxious to use. I have to just set a deadzone larger than I would like for control purposes to make A/P work. Similar function on the Hornet, just different details. Can you see the issue in the track? EDIT: I need to set about 2 degrees deadzone to reliably and comfortably use all A/P modes. f16 ap.trk

I have just done the training missions, and also experienced weird tpod behavior. Sometimes it jumps to some random place instead of being slaved to a STPT. I will try to get a track but something is going on here.

So after testing the F-16, I don't have any bugs related to cold start, but the AP just doesn't work right without a significant deadzone. It accepts tiny inputs from imperfect centering and floats all over the place, similar to the F-18.

We need a clown emoji.

yes, I also reported this. Not possible to drop LGBs reliably, and rockets also go weird sometimes.

Something that wasn't mentioned yet - you will definitely want a head tracking solution if you're serious. Unless you want to go with the VR route, which 1. can be a real pain to set up 2. is expensive 3. I'm not sure your laptop is powerful enough for VR. Then you should get head tracking like TrackIR or similar. It's essentially a clip you put on your head, and a camera tracks it to map your head movement to where your virtual pilot is looking. I think there is also tech that just tracks your head without the need for an IR clip, but I only ever used VR so I cannot say what is best specifically.

Thanks, yes, I agree. it is just frustrating, as I asked for this in 2 other threads, and ED didn't seem to see/acknowledge the problem. For me in the F-18: no deadzone: weird AP behavior, impossible to engage ACLS. Some deadzone: works fine, but I don't want an input deadzone.

It might be if some people have 0 hardware deadzones, and others don't so they don't see this. There might be an extra bug specific to F-16 on top of it. Regardless, I think it would be a great option to add breakout settings to all aircraft with this autopilot behavior, if not already implemented. For example, if I have no deadzone, it is impossible to engage ACLS on the F-18.

I think he means for M3 to open-source the existing module, which is not a reasonable request, as much as I'd like it updated.

Do you have a deadzone on hardware level? Most HOTAS will have it on by default, which might be forced. Some don't. I haven't checked the Viper yet, as I just got it, but it sounds like I have the same issue on the Hornet. People seem to not understand the problem because they have different hardware.

This is a problem on many jets, I know it bothers me a lot in the Hornet. What needs to be implemented is not an input deadzone, which is useless, as you can set it separately on your hardware. We need to have an input breakout setting, which is brilliantly implemented in the F-4 Phantom. What it does is sets a deadzone not for inputs, but for kicking you out of autopilot modes only. It is not a deadzone, but a limit to where the AP will ignore inputs when on, and disconnect when exceeded. This might be an issue only on some hardware where you don't have a hardware deadzone. I hate hardware deadzones and would like to have it at 0, but this messes with autopilot modes on many modules. PS, I think having "realistic" deadzones is a bit useless, as we have our unique HOTAS devices, and not the real plane stick connected to the real force transducers. And I don't know if the real jets have an input deadzone, but I definitely don't believe that tiny inputs would mess with the autopilot. You would think, but some jets don't filter tiny inputs, and it does mess with AP modes.

Here's a track showing loss of stabilization/tracking when passing a target, and sudden jumps/erratic behavior of slaved target mode. JF pod.trk

I managed to record a short track with the issues. I had a few instances of the pod jumping to a random location when switching targets/slewing. For the first target, I had to switch to radar and unlock to resolve the issue, but it was still present afterwards, and unlocking radar wasn't helping with it. I also had sudden jumps and loss of tracking when passing over the target with an LGB. Sometimes it jumps a little and I still hit, sometimes it jumps a lot. In a real mission, it usually jumped a lot more than the track, but it should demonstrate the issue in principle. I just also tried playing another campaign mission and it is absolutely impossible to drop LGBs, I lost tracking and missed by a 100m. Please take a look at the track. JF pod.trk

ED made spotting work on Pimax devices and this causes you to boycott DCS because it must be a conspiracy/cash grab? What is your hardware/res here? 1: barely visible at 2.5 nm, looks legit 2: I see nothing 3: clearly visible above you, no spotting dot rendered at this close distance This looks perfectly fine to me.

Sorry for all the people that are suffering now, but after even more testing, my review on Pimax Crystal is positive. I can finally see stuff in BFM, especially WWII setting. It was hopeless on the previous patch. I do get your frustration - I need to increase resolution to 125% for the dots to not be really huge. I definitely understand why people on different devices are complaining. I agree with ED that the best and easiest way to solve this is to implement device-specific settings. And hopefully some more advanced system altogether when the state is fixed to be acceptable for everyone.

all disabled

I'm not convinced that's all that it is. I also see a big difference in tracer brightness in the central foveated area between 0.75 PD, 1.0 PD, and 1.25 PD. These are all high resolutions that shouldn't suffer from such effects. I think the brightness of these effects might just be too low at high res. Edit: This is for Pimax Crystal, so high res device.

Quick feedback about the virtual pilot mission (3): - in the 3v3, the allied flight is trying to climb too aggressively, they climb while stalled out, and begin combat basically in a stall. Maybe start us a bit higher? - in the fight against the F-5, please consider giving it extra weight. The F-5 AI flight model is extra broken, it has crazy unrealistic performance, and is basically harder to kill than the F-18. I guess that's not intended. I killed him on the first try so I'm not just crying here. -in both close fights, it looks like the enemy begins behind me? Is this intended? I think the standard is to begin a guns fight with a head-on merge.

I do not have any mods now. I wanted to post a track, but so far I only encountered these issues in the paid MAD campaign. I just started learning the JF-17. I have a track file from it but it is quite long. Would you need to have the MAD campaign to be able to replay it? If the track would still be helpful, let me know, and I can upload it on an external website. Otherwise, I will upload a shorter track when I manage to create such a situation again, but when I made a quick test airstart mission, I did not have these severe issues, so it is not 100% consistent. I will keep trying when this issue arises, so far I have just started to learn the Thunder, so I don't have much experience to go on.

Increase QV foveated res to 120-125% if your hardware allows, it makes the dots smaller, and about right. I would say slightly too big but acceptable. It would be useful to test the dot size with respect to using quad views or not, without upscaling the central foveated region. I might try that. Because my QV was not working due to the DCS update for 1 day, I can definitely say that the dots at 100% PD no QV were definitely too large, but with QV at 120% PD they are just slightly too large.

I've tried that, it does not resolve my issue with slaved waypoint being offset from where the pod is lasing/ jumping after TDC press.

There is a pretty huge brightness difference of light effects between low and high res regions when using QuadViews. Low resolution- bright lights. High resolution- dim lights. This creates a very notable boundary between the regions, which is otherwise not noticeable. It ruins visuals at night. Additionally, this applies to tracer fire very strongly, so in high res, I basically cannot see tracers (including my own), but if I lower the resolution, they become easily visible. My guess is that this is an issue with how DCS renders lights, and not QV directly. To test, just spawn above a city with many lights at night, like Abu Dhabi, etc. and see how lighting changes between the foveated region.

I've also experienced this, pod will lose point track when flying over a target (not masked), and suddenly jump to a location quite far away. This often results in a near-miss from LGBs. Also please look at this, might be related:

I've tried it again, and I think the radar trick fixed some of the issues, but I think it's still bugged or something. I made a quick test mission, and I had to use the radar unlock to be able to slave to waypoints other than 1, but other than that it worked fine. However I reflew the campaign mission, and here the radar unlock was not resolving my issue. I think I've narrowed it down, and completed the mission, but the way pod tracking works is extremely frustrating and unreliable. If you slave to a waypoint, it seems that the pod is looking at the waypoint, but actually locking some random point 50-100m away. If I press TDC lock, it will try to jump there. If that point is close enough to the target, I can manually reslew to the target, and lock it in area or point, and then it works fine. But if I can't get a point lock, I am not sure if the pod is lasing the target or some random point nearby. Playing with the radar didn't fix it for me. This is very frustrating for fast and reliable target engagement. A few times, I fired a rocket, and it was being guided to random empty space because I didn't follow this process. Additionally, the pod is frequently losing track when flying over the target, and will suddenly jump to some point 50-100m away with no input, which can cause misses with LGB. Not sure if this is related to the main issue described here. So far I was only able to reproduce it in the MAD campaign mission, and the track is very long and over the file limit. If someone wants it anyway, let me know.