lemoen

Is it 5 entirely new missions? The first one seems the same (Find some missing ship between 4 nav points). Haven't flown it yet. Just curious.

Did you clear out your fxo and metashader folders, in Saved Games?

You've burnt out your laser. Switch it off between shots. It doesn't have an infinite lifespan.

Yeah, don't fly blindly into the Blue (enemy) zones. Look at your ABRIS to know when you're about to go fence in. Then stop and do a recce. Ask your wingman to do short then longer recon flights, he'll send targets via the datalink. Then start looking there for targets. Almost anything can and will kill you, especially watch out for ZSU-23-2, manpads and the tanks with their sniper missiles. When you get the 'Under Attack' warning its time to move, quickly. When you think everything is nice now, stop and look around. You're about to die. Keep looking for missiles coming your way, the KA50 doesn't have a missile launch warning or RWR, just the Laser Warning System.

You can start telling the software to run on a specific core but then you interfere with the OS scheduler and it will quickly become a whack-a-mole situation. If your application only has 1 thread, the OS can't make it run any faster on multiple cores than it would have run on a single core. The thread will be interrupted and resumed as the OS sees fit and it may end up on a different core when it resumes. This is normal. In general, interfering with this makes the system as a whole perform worse but it may or may not have a positive effect on DCS under specific circumstances. I think core 0 is used for Windows kernel stuff so letting the OS move DCS away from that one when it needs to probably results in better performance. You can test this by forcing DCS onto a single core with the affinity trick. You'll see it runs like absolute garbage because the audio thread interrupts the main thread a lot.

Georgian oil war so far seems to work perfectly. I'm 9 or so missions in. Great fun. Deployment was great in 1.5, will do that one next.

I used some rockets to get a bunch then I carefully gunned the rest of them. Wingman did a few too.

uhm, this only applies if you keep your stick in place. I'm guessing most people will use the center-trimmer option so that once you've trimmed, you let the stick go back to the center and you're back to where you started, curve wise. Your guide is fine for FFB sticks or ones like the VKB (with brake) which will stay put where you leave them.

The OS handles this. The programmer decides how many threads to spawn and what to do in them, the OS determines where to run them, whether on separate cores or not AND which cores at any given time. There's a scheduler in the OS that allows threads to run and it can interrupt them when it needs those cores to do other things (update the clock, redraw the screen, play an email alert etc). You can set an app's priority (task manager, process lasso etc), i.e. higher priority -> interrupt other stuff before this one or CPU affinity -> try your best to only use THESE CPUs (cores in our case but the OS see them as CPUs nonetheless)

The Mirage (and Viggen and Spitfire) also has different stick lengths for pitch and for roll, long stick in the pitch direction, short in the roll.

You need to go and look for the defenders, they're not necessarily at the FARP pads.

Were you close enough? The A10C can't lase further than about 10nm I think. Secondly, where the F5 and A10C on the same laser code? F5's must be set on the ground on the kneeboard before engine startup.

OK well if you feel confident about that I'll just leave it there. It makes little difference to my performance or anyone else's performance if you believe the loads will be distributed or not.

After all that here's the simple summary. Is it multi-core? Yes, it uses more than one. Does more than 2 cores gives better loading performance? Yes Does more than 2 cores give better framerates? No.

No. Not if it stays at 45fps. If it is capped at 45 fps it means there is some leftover time between frames pagadi, dude, no. Keep in mind that 2.5 still has a memory leak, hence the need to restart often. Also, switch off MSAA in VR. It runs a LOT better without it. I have a 1070 and use PD 1.2 and MSAA off. It works reasonably well. If you have a card with less memory you may need to stay at PD 1.0

I think the crashing has been fixed in both BF and DDCS. Some static units are still invisible though.

The menu and radio menus are hidden behind the NVG overlay. Expected behaviour is for them to be visible while using NVG.

+1 Should be an easy enough fix, just make the fov a bit smaller so we can peek underneath

Its fine you just need to switch off ASW so it doesn't try to interpolate the missing frames. Then 45 is A-OK.

His graph shows one core working hard and the rest not, which supports the single threaded hypothesis. You and bitmaster claim that rendering is happening in parallel so its up to you to prove it. I told you exactly how to do it. BitMaster copped out of the experiment so now its up to you to prove you are right.

Have you bound the axes at all? Enter mission, press esc, go to Adjust Controls, there's a button called 'Axis Assign' at the bottom. You're looking to bind the following things minimum to fly: Pitch, Roll, Thrust, Rudder

I remember having issues when I started. One thing to look out for is the throttle axis. It may be bound to more than your throttle, so no matter what you do, it goes back to zero and your plane will refuse to fly. Here's a tutorial for beginner:

You can set the Harrier's preset Comm1 and Comm2 freqs in the mission planner, set one of them to be the same as the Ship / Tanker / Airfield. OR Use easy comms.

See, this is where your assumption is wrong. If all the things that had to be done between frames could be done faster on multiple threads, then this would be true, but it isn't. Look up Ahmdal's Law, it gives you the maximum speedup for parallel calculations. Effectively, the speedup is limited by what percentage of the work can be done in parallel, and in DCS there's a lot of things that can not be done so. However, I don't dispute that a lot of things should be possible and currently is not. I would look at some of your other assumptions too, they are also in error. Parallel software is not quite as simple as you may think.

Twistking, BitMaster, since your machines shows this effect and some (like mine) doesn't, maybe you can do us a favour and do an experiment. Take a mission that shows all your cores working hard and fly around a bit in it, then save the track. Run a monitoring app like afterburner and save the graph (not a screenshot of FPS or usage, we need to see a time series for each of your cores) Now, change your CPU affinity for DCS such that there are 2 fewer cores and replay that same track and continue to do so until you're left with 2 cores only. Share all the graphs with us. You'll end up giving us graphs of 8 cores, 6 cores, 4 cores and 2 cores. So I guess the useful things to see would be Framerate, GPU usage, CPU1-8 usage. Allow the 2 core option to use any cores but core 0 as that's for windows and it will interfere and give bad results if DCS is forced onto it only. Null hypothesis: Higher framerate and higher GPU usage as you allow for more cores. Alternate Hypothesis: Negligible difference between 2, 4, 6 and 8 cores on GPU usage and framerate. How about it?