ZaltysZ

Do you have some "irregular" software running? Maybe a debugger? Or some invasive system scanner/monitor?

What have you used for downloading? Maybe a browser? Browsers are notorious for corrupting large downloads. Use download manager (something like http://www.freedownloadmanager.org/ or similar).

Affinity trick does not work on XP64.

Don't turn cockpit lightning on via wall panel. If that switch is in off position, switch on cyclic will work.

Don't forget that pedals are also effected by trimmer. Maybe you are holding unintentional "heavy" feet while pressing trim button.

Temp directory of DCS tends to grow quickly, especially with Tacview export script. My DCS folder has reached 7GB in 2 weeks. :doh:

Maybe this will help Devs: when C disappears, switch to sight mode (from auto track), switch laser to off, then to standby, press AUTO LOCK, correct range will be measured with count down of 1-2s, after that no more range measurement will be possible (unless laser is switched off/on again).

As GGTharos said, downloadable version does not install Starforce drivers. If you can't even boot from CD/DVD, then the problem is in hardware. Maybe overheat damage. What exactly happens when you try to boot from CD? Yes, I know it doesn't boot, but does it shows some errors?

No matter how. It is not game related. Sometimes it is possible to see that computer thinks they are pressed half way by looking at Pedals Control Panel. Sometimes it even happens just after startup of PC. I have observed it in DCS, IL2 (real hazard for tail draggers), FSX. It is known problem of these pedals.

Saitek Pedals have erratic behavior: frequently axis of toe brake show middle position while they are not pressed at all. It is hardware or driver issue. Pushing them a little and releasing corrects axis readings. Owners of them should develop a habit, to push and release brakes before landing.

It really depends on: 1)Number of threads (one thread can only be executed on one CPU). 2)Level of parallelism (if threads depend on each other, they won't be executed at the same time). 3)Calculation load (lots of threads with small calculations kills performance). Usage of threads gives performance overhead too. It appears because CPU time is also required for thread synchronization and management. Sometimes threads eat more resources for synchronization than their calculations. For example: there is a program which does 3 calculations: a=1+2; b+1+2; c=a+b. Multithreaded version will probably be slower than single threaded one, because thread initialization and synchronization will take more time than those little calculations. Well, I don't know exactly how much DCS can be executed in parallel, however it seems that not much. I guess that affinity trick is more related to Vista's implementation of DirectX than to multithreaded code of DCS, because the trick does not work on XP. Back to your question: I don't think that 4 or 8 cores will be of no help, however I think the performance increase will be lesser going from 2 cores to 4, than going from 1 to 2. You need to test that yourself or ask someone to do that.

The problem is not splitting, but parallel execution. It is easy to split, however most threads won't be executed at the same time because of dependencies between them. I suppose in good flight simulator, physics should be affected by weather. It is a dependency: aircraft movement is effected by weather (i.e.: wind). To calculate that movement, wind must be calculated before it. (you can't use numbers in equations, while they are still unknown - it is simple). It means that FM thread will wait data from weather thread - parallelism breaks. Currently dcs.exe runs with 10 threads in total. It is multithreaded as most programs, however it doesn't mean that it can paralelly run on 10 CPUs. There is some solutions (workarounds) for parallelism problem. It is possible to "lag" something (like using wind data from previous frame) or calculate things in advance, however such things might give strange side effects, increase calculations and even decrease performance (yes, it happens). What I am saying is that parallel execution in such programs as simulators is very hard thing to accomplish (much harder than most people think).

Mission with result equal or greater than 50% is considered as successful. By chasing that car, you may get higher score.

Rhino4, you forgot to include phrase: "Get a life!" :megalol:

What technology? SMP? Do you think it is possible to calculate everything in parallel? To gain performance increase from multithreading, calculations performed in each thread must be independent. If they are not, one thread will be waiting for results from some other thread and there will be no pararell execution. How much things in simulation can be independent from each other?

Ah... :) Launch 4-6 Vikhrs at building and it will fall. The civil car will begin its journey from ruins into the city to the left (looking from ingress point). Second salvo of CABs will be launched over the city for you to see and kill that car. Forget Vikhrs, engage the car with C8 or cannon while CAB's are still lighting the area. If you are too slow, it will escape in the dark. No need to kill everything around the house. Do only what are you supposed to do. :)

Destroy the house and after that chase and kill the car, which is trying to escape through the city. That is all.

Youtubish HD = low quality wide screen format. ;)

If rotors are slowed enough during a flight and there is power outage, AP (and maybe INU) will experience kinda of reset and will have to be aligned again before usage. So if you got blank TV screen recently, you should not engage auto hover for some minutes or at least should be prepared for blinking AP lights.

I think, stand off engagement range depends on skill assigned to AI of aircraft.

Check rotor rpm (left panel). If rotors rotate to slowly, generators will not produce enough power, required for systems.

Tearing with vsync on mostly happens when display is using forced refresh rate which isn't supported. People untick "Hide modes which this monitor doesn't support" and choose something to high. Although windows and video card thinks/uses that refresh rate, display silently uses its factory default rate and tearing occurs.

Comment to discussion of AlphaOneSix and Geier, regarding throttle: There is much more possible position of throttle than there have been named in manual. I personally have assigned it to axis and frequently use "unnamed" positions. I have not crashed or broken anything yet with such usage; as I like to watch blade rpm, variometer and temperatures. Maybe landing on IDLE is bad idea as you may not get chance to correct mistakes. :D However, landing or flying or hovering with something between AUTO and IDLE is quite easy, especially after sortie, when your weight is low. Why it might be beneficial to lower throttle (not to IDLE)? With lower power helicopter reacts much less and more slowly, so it might look more smooth and make landing a bit easier. Of course, recover will be much harder, if need arises.

Maybe a screensaver :D

Pay attention to wind; try landing against it, its direction is given by tower. Avoid fast vertical descents (over 3m/s), because greater sink rates may put your aircraft in vortex ring state. Safe vertical descent is slow and boring, instead descend in spirals around your landing location and enter hover only near ground and near landing point. Be prepared for ground effect - lift increases much near the ground (few meters). Smartly counter that with collective. Be warned, ground effect might effect only part of rotor and can create assimetric lift if altitude varies under rotor (for example: on the edge of helipad, near some slope and etc.). You may try to decrease throttle (PgUp/PgDwn) to one position above the idle. This will make Ka-50 to react less and be handled more smoothly. However, better practice to land on AUTO positon. Don't forget to flare (rising nose just a little) before touching ground.