darkman222

If you do a trackfile, try to do a short one with only the issue isolated. Airspawn for example.
Then dont use Mods. There is the eurofighter mod needed to be installed. 
I went through it fast forward and saw in the first engagement the TGP was NOT SOI. That could be the issue.
In the second engagement the Mavericks were set to Boresight aka BORE. They wont slave to the TGP in BORE. Switching to BORE happens when you accidentally press the cursor enable switch on the hotas, or when its bound with some other key you press together with it.
 
Make sure to stay in PRE mode all the time and that the TGP is SOI before you press TMS up on it.

... topic was moved from bugs to wish. Please make the wish come true ED 🙂

Yes the process is bothersome. Of course its the initial release. But quick and easy access to the DTC feature is needed. Otherwise people will soon abandon it continue 3rd party external software that has been around and used for quite some time now.
I made a mock up how that menu could look like in this thread:
 

Yes you are actually rocking the rudder pedals by rolling if you watch from the outside. This is an intruduced bug described here, and you cant do anything about it at the moment:
If you are fast and the wobbling is not present, its not your settings.

I am aware of that textures loaded from the SDD into RAM also can lead to stutters. ( 64 GB memory are ordered btw) But in my testing, you can see in fpsVR that my memory is way below the limit and no factor.
@BIGNEWY@Lord VaderI waited a few updates now for a final test and some conclusions here. My test is like it was from the first time I started testing: Approaching a Gazelle over the ocean. (see the video above how I do it, you can also download a track file of it) I could have used another aircraft to fly close to, but the Gazelle seems to have the biggest impact on CPU frame time and texture loading and unloading.
Here are my inital tests about in which version the issue has emerged. I used the DCS updater to revert to older versions. So its all with the same hardware and drivers. Tested on the same day. No change in hardware or drivers affect that test this way.
Note: In fpsVR see the graph for individual CPUs, that with 2.9 DCS seems to start using the CPUs more evenly than it used to in 2.8. More about it towards the end of my test.

This leads to another test how to improve that behavior. A lower texture size of course helps people that are affected by it, but as long as the texture slider is for all textures, including cockpit textures, it does not help in the long run as long as we dont get separate sliders for cockpit and exterior textures.

I still wanted to share my test up to this point as this might give some further insight, without being a solution though.
 
 
 
Here comes my most important test. I was trying a method mentioned by Jabbers in his testing running DCS with arguments: --affinityF (4 cores) to --affinityFFF (12 cores)
That did not help in my case. It made DCS run unstable. Possibly because it disables random cores. Then I used process lasso and clicked "disable hyperthreading". That also disabled the efficency cores. Note, this only works with process lasso. Disabling the hyperthreading cores and efficiency cores in the BIOS also leads to an unstable running DCS and even the entire PC runs unstable. The only way to do this is with process lasso.
 

Now DCS runs only on these cores ( note the efficiency cores are also disabled) :

Now here are the results. The stuttering because of textures loading and unloading into the cores / threads is completely gone.

I tried ( multiple times, but without success) the MT.lua @BIGNEWYposted in the thread he started called: "Intel hybrid CPU Getting stutter? Please try this in multithreading DCS" but it did not help. Not sure if it was rather to fix core parking issues. Also it took me this long to figure that solution out because disabling cores via BIOS is no stable solution.
 
Sorry for the long post. But I felt that I needed to share these results in detail, as I spent quite some time gathering them.
 
I included a ZIP file of my system specs, a dxdiag and a dcslog with "allcores" and with "8cores" in the file name. So you have a file that was created using all cores and a file that was created when DCS just used 8 cores. As requested, I included my GeForce settings too. But I dont thing they matter and they are just the plain default anyway.
 
Also a track file is attached. I am not really sure if you can reproduce it on your systems as this behavior is barely visible with the DCS fps graph when trying this in 2D. Running DCS on a high resolution VR headset is of course demanding for the hardware and clearly shows if something is not running smoothly. I am willing to help with further testing for ED, trying LUA files or whatever needed. For now this is a satisfying solution as long as nothing changes and I can keep the performance using this core affinity with process lasso.
 
dxdiag_dcs_log__geforce_settings_hardware_darkman222.zip
stutter8cores.trk

Use DTC for DCS instead.
In the F16 you can long press the WX button on the ICP that will start the upload to jet process.
https://github.com/the-paid-actor/dcs-dtc

You have to be in CCRP to make VRP or VIP work. I just took over your flight and simply switched to CCRP. Symbology is there. Everythings working fine.
null

Not really sure about the fuel flow as indication when AB starts. At least the nozzle does not move any more when going over the 75% percent which could be a sign that AB engages.
It seems like there is more signs that AB engages over 75% than that its not engaging.
Unless someone has better information, I assume that the 75% position is the correct AB position but the flame animation starts at 82%. Which cold be a bug or maybe it really is burning without a visible flame in that lower setting.

Afraid there isn't.
If you want more confort and save several waypoint sequences you can use https://github.com/the-paid-actor/dcs-dtc
It's not realistic to change the entire flight plan while airborne, but this software does a decent job

In the controls menu use the "search" function. For example search for "landing or gear" that brings up the gear only. Double click in the column under your desired controller (throttle gear knob) and push the button on the controller.
Or instead of "search" select "axis only" that brings up all the axis. Pitch, roll, bank. Double click it again in your controllers column and move the axis on your controller to both full extents. (Not sure about gear lever, if the F16 supports an axis)
And dont search for flaps. F16 has autoflaps 🙂
For a more in depth tutorial ask Mr. Wagner: (about minute 6 is what youre looking for)
 

To conclude my testing I have uploaded a short video.
Result: In MIZ pre GPS era INS drift is modelled. I will drift about 1100 ft per hour.
If you start up cold, ground aling, without entering coordinates, it will give perfect GPS alignment, which will start to drift over time too.
About the ground align without entering coordinates I am not sure, but the rest looks pretty realistic I would say.
 

You are out of range for guns for sure. I had done a similar post a year or maybe more ago.
The circle around the designated target unspins counterclockwise. I think at a distance of F 045 which is the 3 o clock position in the circle youre slowly getting in range for guns.
Put the bandit on the minus symbol (which is for him doing a max 9 G turn) and fire your gun. You'll see in Tacview that all your bullets will fall behind him. Even if you shot at the maximum plausible amout of lead ( 9G) at him.
 
Get closer to the bandit (in one of your screenshots), you'll see the pipper slowly creeping up from below the HUD.
In the F16, the pipper creeps up the HUD from infinity below through the 9G minus symbol and up to a position between the plus and the minus symbol in the funnel to meet the real G the bandit is currently pulling.
 
What you are expecting is the behavior from the F15 or F18. Where the pipper stays visible all the time in the HUD even if the bandit is out of range.
This is when you see people firing at the back of some other aircraft thats running away (on the dogfight, guns only servers). If you see it from the side view, you'll realize the bullets fall behind the target. But for the F15 or F18 pilot who is shooting, the pipper is on target, so they fire their gun.
I never got an answer why the pipper in the F16 behaves differently from the F15 or F18.