ShuRugal

This is the real key to getting good at BVR combat. It's slow, and very painful, but after over a year of spending 5-10 hours a week flying (READ: dying) on 104th, I can reliably clean up just about anywhere else, unless I find myself going head to head with a practiced (human) squadron.

So, if we can get 100k supporters for DCS: Slope Soaring Physics, we cant get this off the ground? :p EDIT: I just had a complete out-of-the-box epiphany with regards to offloading support for AI PFM.... What if a separate application, dedicated to giving AI the ability to control PFM, were developed, and have it literally operate as a multiplayer client, only connected to localhost instead of an online server? Would that even work?

Off the top of my head? reduction/elimination of cluster-munition framekills, higher cap on the number and intelligence of AI units, more dynamic weather effects, simulation of airflow/turbulence around other aircraft, buildings, and mountains. If we dedicate one virtual core to each of those things, (AI, Munitions, Weather, Atmospheric fluid dynamics) that leaves your average I5/7 Quad four more threads to handle I/O, Sound, and whatever else is required. As far as cost/benefit goes... I'd pay to have weather and airflow around obstacles dynamically simulated...

when fighting against AI, don't use your jammer. Jammer forces AI to launch at close range, which puts you further inside their kill zone.

AI cheats. Much less than it used to (used to be able to see through it's own plane at you) but it will still instantly spot any missile launched wit a line of sight on the cockpit..

true, but i would be interested in a technical description of why the same general precepts do not apply.

So, the problem is not that there would be no performance gain, it's that ED can't afford the man-hours to re-write the engine from the ground up, which is essentially what would need to happen? in commo, we solve this problem by feeding in a snyc bit at predetermined intervals. For a less data-heavy solution (the cores don't need to share full details on their individual threads, just the end results of each step) have each thread output a timestamped progress log to an area where any thread may read it on demand. This way, even if you have one thread hung for a few cycles waiting on the most recent output from another, you don't have the entire app hung, which is what happens when a subprocess of a single-threaded application skips a beat. well, sure, if all you do is split it down the middle and say "okay, core 1, you execute all the evens lines, core 2, all the odd lines, go!" you have that problem. But that's not even remotely what I am asking. Except that there already exists a running mode where all the physics calculations are handled in parallel: multiplayer. The type of multithreading I am suggesting would operate almost exactly like a multiplayer match; Instead of each client controlling a single player aircraft and his projectiles, each client would be responsible for one type of entity. But, as KH already pointed out, that would most likely require a ground-floor rewrite of the engine.

I remember several recent statements from ED that it had been determined that multicore-optimization would not provide a significant increase in performance. I was wondering, what are the technical reasons for this? Granted, I am no expert on distributed computing, but it seems logical to me that taking major functions which tend to hog CPU time (looking at you, AI and projectile computations) and breaking them off onto separate cores would be massively beneficial. In my head, I visualize how this would work best as a client-server architecture (think network computing, but without the network): One core process would handle input/output, track and report positions of individual assets, and be responsible for determining the result of interactions between those assets. This thread could also handle simulation of the player aircraft. A second thread would do nothing but manage AI decisions and movement, and would report the results (positions) to the core process. A third thread would do nothing but determine the movement of projectiles (spawned by report from core or AI thread) and would report results to the core thread. We already have audio on it's own thread, so this would fill the fourth core of a typical quad-core processor. Now, perhaps I just have such a poor knowledge of how multithreaded computing works that I am missing something critical here, but i don't see what that is. Could someone give me a technical explanation as to why the above solution would NOT result in improved engine response versus having all of those function run linearly, as is currently the case?

what is basically happening here is that the SU-27 FCS allows you to put the plane into AoAs that guarantee extreme departure. The aircraft is particularly sensitive to negative G pushovers. Unfortunately, the aircraft is very stable once it achieves the inverted position, thanks to how tail-heavy it is. What those threads really boil down to is that the new flight model requires the Flanker to be flown with a gentle hand, and positive Gs.

Yes, the KOM will kill APCs and whatnot. You can even kill a tank if you get a couple to hit the same one. But if you want to kill armor, equip S-13. More precision, longer range, much greater damage.

have you tried setting overcast? Your first image looks about like what i see with my unaided eyes on a nice clear night once i've been outside for about 30 minutes to get fully dark-adapted.

The problem with Teamspeak is that no one uses it outside of squadrons. For those of us who prefer to fly pick-up-group style (I don't have the free time to reliably fly with a squad), lack of in-game voice communication support is a crippler.

I would be interested to see how ARH missiles currently perform in comparison.

the guys talking about shooting AIM-120 and AIM-7, and give their units in feet and nautical miles are Eagle drivers. the guys using metric units and talking about R-27s, R-73s, and jamming pods are Flanker drivers.

Settings and specs attached. DxDiag.txt

Looking at your screenshots, it appears you are in the area of Gudauta/Sukhumi? Do you have this low FPS problem elsewhere? I have noticed since 1.5 that in the Sukhumi area, my framerate also falls off the bottom end of the scale.

Since upgrading to 1.5, I have observed repeatedly that I suffer a massive loss of framerate in the coastal area around Sukhumi. Everywhere else on the map, I experience 45-60 FPS at low altitude, and 60+ at or above 8km. However, in the vicinity of Sukhumi, especially below 3km altitude, my framerate drops as low as 15 FPS. Anyone else seeing this?

This, really, is the problem everyone is complaining about: It's not that R-27s have stopped working, it's that they have been reduced to Vietnam-era performance levels by the dramatic reduction in seeker performance. The Su-27 is NOT a Vietnam-era fighter, it HAS look-down shoot-down capability. The R-27 family is NOT a family of 5-mile missiles (that would be the R-3). The problem, as near as I can tell, is that the missile's effective range has become limited to how far it will fly before the engine rolls the dice on chaff/ground-clutter... Once chaff and/or notching has been a factor for more than a few seconds, the missile goes stupid. This behavior is forcing players to launch at shorter ranges to try and deny the target time to react in a way that abuses the current seeker modeling. It's no surprise to anyone that the missile is performing brilliantly inside 5 miles... at that range, you're already inside the R-73 envelope.

To give a direct answer to the OP's question: I'd rather have the extra 2 R-73s. Radar and ECM modeling in the sim are currently so simplistic that it really doesn't make a difference. ECM burn-through occurs between 30 and 50 km, which is too far away to be useful in transitioning to the merge. All ECM in DCS does is make you easier to spot and force Russian radars out of TWS.

TWS2 does not (or at least, should not) produce multiple hard-locks.

In that case, it sounds like the earlier suggestion of the AI rapidly switching locks. Do you have any tracks or ACMI files? In Tacview you can see what the selected aircraft has locked as target.

"Locked" means that the radar set has a good return signal and is automatically tracking the strongest part of that signal. Older radar sets relied on various forms of feedback-loops, based on things like signal polarization and phase-angle. "lockbreakers" disrupt this function by sending out a signal on the same frequency that is out of phase or cross-polarized, which causes the radar dish to move away from center of signal instead of towards it. Newer radars are smarter, and use computer processing to build an "image" from returns, and track accordingly. Doppler radars are even more robust in this regard, because they use more types of signal data to compile their image. Chaff works by virtue of the fact that while it is sufficiently close enough to the target, the radar sees it as part of the target's RCS. Until the chaff diverges enough for the radar to see two separate targets, it has no way to discriminate. The missile goes dumb because the current radar simulation is extremely simplified. The Su-27 actually will continue to emit, even if the radar loses the target completely in the ground notch, provided you remembered to turn on EOS and get the "EORL" lock display. In this case, even though the radar has lost your bandit in ground clutter, the EOS keeps the radar slaved on target, and keeps illuminating the target so that it can re-acquire as soon as the notch is exited.

To an extent, but the thing with any radio transmitter is that there is no such thing as a "tight" beam. The center of the beam, where the signal is strong enough to paint a target with, may only be a few degrees wide, but the radar energy will be detectable from basically anywhere in front of the dish when within the range that a missile will fly.

It's a couple things adding up. SARH missiles are currently having a plethora of problems tracking the target. The biggest issue at the moment is that the DnD-Style "Roll to check chaff resiliency" mechanic current makes it possible to evade an R-27R/ER at any range just by spamming chaff. This is unrealistic for a couple reasons: 1) Fighter radars and missiles are designed with a certain measure of chaff-resistance, mainly by building a track of the target and ignoring deceleration rates that are impossible for a plane to perform (chaff tends to stop dead in the air within a second or two). In the specific case of the R-27, the missile's mid-course guidance comes via m-link (one-way datalink) from the parent aircraft. The Su-27 generates the updates for this link based on its track of the bandit. 2) Since chaff stops moving so quickly, at close ranges and/or flanking aspects, there will quickly become enough angular separation between the parent aircraft that the chaff is either no longer illumated, or moves out of the missile's FoV. This, again, is also somewhere that chaff-rejection programming should tell the missile to ignore the chaff, because a fighter can't go from 1200 km/hr to 10 km/hr in under three seconds without turning into a grease stain. 3) the Su-27 is equipped with an EOS targeting system to supplement the radar. in STT mode, the EOS can also track the target based on IR signature. Even a rudimentary tracking program should be able to recognize the difference between a fighter with both radar and IR signature, and a cold bundle of chaff (or the other way around, in the event of flare launch). This would allow the Su-27 radar to be kept on target based on IR sensor returns, further improving chaff-resistance at close range. If DCS was correctly simulating these effects, then a defending pilot would be required to not only spam chaff, but to maneuver himself into a relative position that allows him to negate the chaff-resistant features of his opponent's aircraft (IE: make high-G turns to disrupt track building, chose a hard hot or cold aspect to place his aircraft in-line with his chaff bundle, etc). The attacking pilot would then need to maneuver his own bird to try and regain a favourable position/radar picture. This problem is the kissing-cousin of another missile tracking problem that has been plaguing the R-27 for ages, and that is ground-clutter susceptibility. At one point, a few patches ago, it was so bad that I had an AI Su-25 "dodge" my missile simply by "notching" against the sky. No chaff, no maneuvers, just turned 90 degrees and kept flying straight. Unloaded my entire payload, and finally killed him with guns.

I'd do two things: 1) check your axis bindings, make sure nothing except throttle is bound to thrust 2) run repair utility.