niru27

If it ain't broken, don't fix it. Why do you feel the need for constant, unnecessary updates?

The manual says: However in the jet: 1st press = Start timer 2nd press = freezes the timer DISPLAY, but the timer continues to run in the background 3rd press = unfreezes the timer DISPLAY, and shows the time elapsed since the 1st press F18_TIMER.trk

So there are no unguided penetrators to destroy C3 bunkers?

You can use this mission to reliably get CPU limited right at the (hot) start of the first mission, with a lot of activity. Was getting ~50fps with 12400 and went to 220+ with 9950x3D I always get GPU bound at the beginning of Raven One mission 2 "Riders on the Storm" But, with lower graphics, CPU gets additional headroom, and vice versa, so it is just a balancing act between CPU frame time and GPU frame time

Ah that might explain why the focus region has lower detail with the same QV settings compared to VD Godlike.

Using Intel Present Mon you can log GPU Busy, GPU Utilization % and total Frame Time. If Frame time > 13.89 and GPU Util > 100%, you're hitting GPU limits If Frame time > 13.89 and GPU Util < 95%, you're hitting CPU limits The problem in DCS is when there's a lot of units activity, it can spike CPU usage, so your frame time will go up. Perhaps we should tune settings to aim ~80% GPU usage so that we have headroom for sudden acitivities? -------- Have you tested how much CPU overhead QV adds? If you set peripheral to 1x and focus to 1x @ 0.01x0.01x, and compare that with QV disabled, that might tell us the minimum overhead required?

Same, VD seems to look sharper to me somehow, while Pico Connect seems to have higher dynamic range and better colours. Is Quad View working on Pico Connect for you? When activated, it seems the entire view is at the peripheral resolution, and the hi-res focus region isn't drawn

Your logic only applies to HDD. With SSD the data is never physically sequential since the controller has to do wear leveling, so it automatically moves the data to different parts of the flash memory. With HDD the data stays exactly where it was first saved, so the game files don't get "spread around" Further, the seek time for all sectors on a SSD is almost equal since there's no delay from a head having to physically move to the right place to read data, so it doesn't matter whether data is sequential or not. More importantly a human can't tell the difference between sequential and non sequential data reads.

Got a new PC. The script helped to transfer keybinds easily

Just run a slow repair on DCS, it will check all game files and redownload corrupt/missing files. This is the same as deleting + reinstalling DCS, except doesn't unnecessarily redownload everything. What makes a bigger difference is starting with a new Saved Games folder. Don't copy the old folder to the new PC. Start fresh. For keybinds you can use my script to automatically restore them on new PC:

Ah, good to know. One day I might rewrite the script to fetch the UUID from here instead of external DLL

Please follow the instructions on the Github What's the problem? Seems like your devices names got changed. Are current UUID's of connected devices always logged by DCS? In my script I have to use some DLLs to get that info

You can use my script to automagically restore from your backup:

I wrote a scipt to automate this:

One could set Mode 3 Squawk codes on the A10 for years now. While this does not affect the actual IFF outcome in DCS, it helps if you have someone on LotATC Recently while playing F18 Arctic Thunder campaign I realized I could set the M3 mode on Hornet as well So I'm thinking there are some valid, and some invalid codes, and that is what got modelled here

Been a while since I flew so can't say if you made any changes in the latest patch, but I just tested, and the pitching oscillation due to unstable G still occurs. HUD recording attached for reference First, watch the clip and just look at the Controls overlay to verify I'm holding a constant backstick pressure Then, rewatch the clip and just look at the G values. Playing in slo-mo will help You'll notice G oscillates up and down, first it maxes out at 7.8, unloads to 5.6, and then keeps going up and down repeatedly, before stabilizing at 6.5 7.8 > 5.6 > 7.0 > 6.1 > 6.5 The above unstable/constantly varying G is what is making the aircraft behave erratically. If this is considered normal, why aren't other jets doing the same? Just fly F18 and, say F16 and perform a Split-S back to back at the same altitude/speed, and you'll realize that this is just weird behaviour. 2025-03-21 18-22-29Ed-1080p-x264-22Q.mp4

Speed brake issue got fixed in today's patch, but this is still pending

Fixed in today's patch.

Done

Any news on this? It's been a ~year since the new FCS brought this issue which makes defending in BVR, say by performing a Split-S, almost impossible

This is the answer. If you had any AP mode active and did not disable it with a short press of the Paddle (yanking the stick doesn't work either), then when you drop flaps and try to trim, this happens.

Is the high altitude, high speed handling reported as well? When you yank the stick in those conditions, the FCS can't make up its mind on how many G's to allow, so there's a constant oscillation in pitch axis --------- Here's a TRK for the Topic Issue: Part 1 : Level flight with ATC and BALT engaged, and Speed Brake fully extended (WW F18 throttle, so the switch physically returns to the centre HOLD position) When I press the button aft (EXTEND), nothing happens as expected But when I release it, there's some pitch input from the FCS, which is wrong, since the board position hasn't changed at all Part 2 : I go into a left hand, level turn When I press the button aft (EXTEND), nothing happens - once again as expected But when I release it, there's some pitch input from the FCS, so the velocity vector leaves the artificial horizon line This issue is particularly problematic when doing Case 1. If you let go of the Extend button, the jet will want to depart from the level break F18 SPDBRK.trk

Just ditch the in game kneeboard which doesn't even remember the last position and size, and switch to OpenKneeboard. It is 100x better. You even get additional "categories" for things like AI radio transcripts

I did some testing and you are right, this is exactly what's happening. The pitch change is tied to the Speed Brake Extend button state instead of the actual "Speed Brakeextended state". After the board is fully extended, the FCLS waits until you let go off the EXTEND button to retrim the jet, instead of waiting for the board to close. So the net effect is you flight characteristic is a bit different depending on whether you're holding the Extend button or not.

Could it be the FCLS compensating for the pitch up caused by the speedbrake, by trimming down? The FCS page should tell you The new flight model is definitely wonky: too much ballooning when dropping flaps and nerfing of pitch control.