Fastbreak

I would like to put a question to ED regarding the performance of the new AH-64 module (optimum use of hardware). Should this question have been answered before, please skip it. According to ED's newsletters (...) a part of the team permanently works on Vulkan/DX12/MultiCore as well as they have already rebuilt large parts of the core coding. The end of this project is not announced, but ED is pushing to wrap the new core up. Thus I assume new modules, which are developed when Vulkan/DX12/MultiCore meet the horizon, already to allow for the new DCS core and for economizing on their future development time. So, does the the code of the new Ah-64 module incorporates compatibilty with Vulkan/DX12/MultiCore (by quick reconfiguration of prepared code)? Thank you for your answer.

L140 Laser warning receiver. L-140 Otklik ESM Type: ESM Altitude Max: 0 m Range Max: 11.1 km Altitude Min: 0 m Range Max: 11.1 km Range Min: 0 km Generation: Early 2000s Sensors / EW: - L-140 Otklik - ESM, LWR, Laser Warning Receiver, Max range: 11.1 km

A day or two? Same thoughts on my side - with a day or two in international sales & marketing.

OK, it seems as if among the one-eyed is the blind king. Happy flying!

What kind of "eye candy in the cockpit" do you talk about? As far as I know the external model gets a graphic overhaul and BS3 receives a small weapon and defense functionality update, to which I look forward, too. Nonetheless, the more important question that I still ask myself is, wheter ED will finally bug-fix (...) the existing KA-50. Neither ED has written any single word about bug-fixing up to now, but only about development (that does not necessarily implicate bug-fixing), nor they do have bug-fixed any basic shortcomings (...) of BS2 for the last 2 years. It's a kind of magic

Ok, I see. I do not need 300 fps to have fun with a simulation, either, but I do expect more than an ancient graphics engine that does not use the latest technology. Of course, at the very beginning there should be a definition which minimum fps rate is rated performant as fun is a very subjective perception. From my perspective 60 fps { mimum level | regular frame times | @ 1080p*/2K/4K resolution | high graphics settings | 2D } should be specified. From a business point of view I understand that the old engine is used as long as possible, but in 2022 with modern APIs, new hardware features, e.g. real-time ray-tracing GPUs, time is ripe for a necessary change to guarantee a 60 fps minimum limit. *1080p in my opinion is useless nowadays because you cannot read cockpit instruments properly Of course, many people ignore fps while they fly, because everything feels smooth most of the time. My experience on the contrary is different. Fluctuating and low fps do not amuse me, rather they spoil the party for me when I pilot in e.g combat zones with input delyays or stutter due to missile launch. You perceive it differently than I do - granted, but I am struggling to comprehend how you have come to the conclusion that you get "accerptable performance". Every other aspect of DCS such as graphics, AI, weather, weapon systems etc. pp, of course, does contribute to a realistic and immersive overall picture. Nevertheless, all those factors will lose their magic if precise flying is limited by frame rates which are too low or extremely fluctuate and therefore cause input delays while piloting. Especially FPS and frame times are essential when you are flying a helicopter that is an instable aircraft, and much more important when you fly near to the ground or objects like trees or buildings. And with regard to the very expensive high-end HOTAS that most of the DCS enthusiasts call their own specified frame rates also seem a promising approach. I would really like to see a categorisation with specified fps minimum limits according to monitor resolution, graphics card, CPU and highest ingame graphics settings (default), 2D use and VR combination. A specification is the most legitimate way to give customers the necessary information to buy ED products without disappointment and upgrade they hardware at optimal cost-performance ratio. It would involve a lot of work for ED, but it could be a reaonable decision long-term, in particular if customers should be bound to change their habitual buying behaviour due to hardware prices that have been raising without end in sight. Anyway, it is your prerogative to regard things as fine the way they are as long as you feel entertained and have fun with DCS.

+1

I drive an old British Mini Cooper in racing green with a white roof. What I do get is acceptable performance and a pretty car. I'm certainly not worried.

Everybody who is willing to accept buying the best (and most expensive) available hardware for DCS, should also be willing to demand the best possible (and at the soonest) software optimisation for this hardware from ED. Those, who focus on the hardware side only, do not incentivise ED to introduce Vulcan or DX12 API with the highest priority and fastest development results. Vulcan 1.0 API has been available since 2016. Nearly six years have passed to renew and finish a new core for DCS, that has already had an ancient graphics engine in those days and earlier. If the majority of DCS enthusiasts who are probably not "sitting on gold mines" balance DCS's outdated graphics engine again and again by means of new hardware purchases, their approach will lead to both burning money and wasting performance, it will produce opportunity cost. Minimising opportunity cost is a sign of economic rationality. To be a purchaser, or not to be a purchaser, that is the question - at least to which degree or at what price. Keeping an eye on the financial developments outside our near and dear Digital Combat World, I am quite sure this question will soon catch up with ED, too.

You are a meanie...

Wise words! A happy new year to all of you! Digital Combat Simulation Street: Wanna Buy A 'P' Boosterdog? Boosterdog: [HUMMING] Fastbreak: Hey, bud. Boosterdog: Hey, who? Fastbreak: You. Boosteredog: Hey, me? Fastbreak: Yeah. Come here. Boosterdog: What? Fastbreak: Come here. Boosterdog: What? Fastbreak: Now, you look like an intelligent young man. Boosterdog: I do? Fastbreak: Yeah. Boosterdog: Oh, yeah. I do [LAUGHS] Fastbreak: You look like someone who would be interested in a bargain. Boosterdog: A bargain? Fastbreak: Yeah. Boosterdog: Why, sure. Why not. Are you a salesman? Fastbreak: Right. Boosterdog: Oh. What do you sell? Fastbreak: 'P' Boosterdog: 'P', like the letter 'P' Fastbreak: Sh! Boosterdog: Like the letter 'P'. Fastbreak: Right. Boosterdog: That's kind of a weird thing to be selling. Fastbreak: Listen, you take this 'P', here, see. It's very useful. You buy it, you hang it on the persective. Boosterdog: On the persective. Why-- Why should I buy a 'P' and hang it on the persective? Fastbreak: Next time you write about the way of looking at something-- Boosterdog: Yeah? Fastbreak: --you look at the 'P'. Boosterdog: Perspective has two 'P's! Fastbreak: Sh! Boosterdog: Perspective has two 'P's. Fastbreak: Right. Right. Please forbear with me and my above lines Boosterdog, but I could not miss this opportunity - love this Sesame Street scene too much ... all the best to you for 2022.

Good to hear & happy flying !

This is in the end a needless fighting of symptoms and it will only improve performance to a very small, not much noticeable extend. The solution is on ED's side ...

A small, temporary, hidden "on-site FARP" (resupply), would generally be more than a nice to have feature for all helicopters to broaden their field of activities in DCS. Enclosed I list some rough thoughts about those items which I would like to see implemented with regard to an "on-site FARP". "On-site FARP" in Mission Editor (ME) At first the "on-site FARP" should become a new object in the mission editor which mission builders can choose. The range of a convoy to an "on-site FARP" should be limited by its own fuel. The probability of how exactly the convoy is able to follow a set path, or if it has to make a detour, could be calculated due to different factors, see below. Some of them, such forest aisles, mug or boggy ground, does not need to be graphically implemented in DCS (yet). Mission builders could optionally overlay the 2D map with filters in the ME, e.g. in form of simplified mesh overlays, which gives them the information needed for mission/path planning. Convoy's way to "on-site FARP" (calculating probabilities) - traces: tracks off-road, forest aisles, dirty snow on ground, etc. - exact on-site position: dependant on various factors and can change in misssion over time # terrain (roads, off-roads, weather, season, hilly or mountainous ground, rivers, forests, villages, etc.) # season (weather with rain, sun, snow, wind, etc.) # forces (friendly, enemy, range, in air, on ground, etc.) # territory (friendly, neutral or enemy) - stoppage convoy (losses by enemy fire, technical failure, rough terrain, additional fuel consumption due to detour, etc.) Convoy at "on-site FARP" (graphics and sound) - landing grounds: grass, soil, mud, stone, forest floor, sand, etc. - camouflage: painted canvas, nets, branches, leaves, trunks, stones, snow, etc. - communication: pilot is informed on the exact posion by radio - support: refuellinging, reammunition, small reparations, pick up or set down rescued pilots, new mission orders, etc. - personnel: spruce technicians servicing the helicopter (and the pilot )

Seriously? You ask for an update before christmas without explicitly specifying the century and the year ?!

Good morning from the rabbit hole, Boosterdog! Your system specs are quasi the same as mine (I use a gtx 1080ti), as well as you I exclusively fly helicopters. In the previous DCS version I was able to fly with a gtx 1080 in 4K, but the reaction to control input was a little bit sluggish, so that I set the resolution down to 2K. Then I changed to a gtx 1080ti and could fly in 4K without problems - the difference between both cards was evident. In DCS 2.7 I can't clear the 4K hurdle and need to set the resolution down to 2K again (...). I get about ~60 FPS in all instant flights in all DCS maps (simple flight without any mission objects) and in use of one monitor. To get to the point, you might think about a cheap interim solution selling your gtx 1080 and buying a gtx 1080ti. Of course, that would be a compromise, but unfortunatelly we neither know when ED will be changing to Vulkan/DX12 nor when the hardware prices are levelling out. I have just looked graphics cards prices up here in Germany. There are gtx 1080s offered for about 300 to 350+ Euros and there are gtx 1080tis offered for about 500 to 550+ Euros. As an aside, I was seriously surprised that I was able to sell my gtx 1080 within one day. See you tree top level

+1 'There's Plenty of Room at the Bottom' with regard to system simulation depth. Another wish of mine is a bug-fixing - before long, in and out, thorough and each item appropriately documented in the official BS2/BS3 manual.

What might have happened: You have not turned the APU off after starting the engines or you have had the APU running very long before take off, so that during flight the Rear Tank pumped dry before the Forward Tank. The APU also gets its fuel from the Rear Tank, which again feeds the right engine (Engine 2) with Cross-feed valve closed.

Well, I have an unenviable position. If I caused your philosophy of fun to totter, I would be awfully sorry.

Hot topic I personally would not buy a 308X graphics card for the following reasons: The very first reason not to buy any graphics card higher than 3070 is the positively obscene prices. While customers ("have to") pay through the nose for hardware, companies laugh up for their sleeves and laugh all the way to the bank. The second reason is that DCS still uses a vintage graphics engine, but to be fair, ED is working on Vulcan, new Graphics Renderer and Multithreading to modernise it - It might be worth to mention that ED has not announced any offical release date yet. As for the old engine, DCS 2.7 gives a lot of performance away with both high-end and less powerful hardware in 2D as well as 3D (VR) use. Third reason resulting from above: the cost-value ratio is simply bad. Rip-of prices for high-end hardware to compensate for suboptimal software seems to be the standard way to go today - unfortunatelly it is neither an economical one nor the smartest (with regard to future market prices). P.S.: Don't get me wrong, I do grant each of the users with a 3080 or better graphics card the fun with fast and fluid flying.

Have you made acquainted yourself with the KA-50 systems yet? If not, you should do first to understand how weapon, navigation and autopilot systems mesh and affect the flight control of the KA-50. Their handling might be counter-intuitive in the beginning. To your question: OPTIONS 1. Check in the OPIONS MENUE / MISC. if the "FORCE FEEDBACK" is "NOT TICKED" (You have no Force Feedback stick) 2. Check in the OPIONS MENUE / SPECIAL / KA-50 / if "TRIMMER MODE" is set to "DEFAULT" (You have a regular spring joystick or joystick without spring) 3. Check in the OPIONS MENUE / SPECIAL / KA-50 / if "RUDDER TRIMMER" is "NOT TICKED" (Trim button only operates the cyclic control, it does not trim the rudder) INFLIGHT 4. Turn on autopilot (all channels) Channels 1. Pitch dampener & Pitch hold. Enables pitch autopilot channel. -> ON 2. Bank dampener & Bank hold. Enables bank autopilot channel. -> ON 3. Lateral dampener & Heading/course hold. Enables lateral autopilot channel. -> ON 4. Turn on FLIGHT DIRECTOR (FD) In flight director mode Pitch hold, Bank hold and Heading /course hold are disabled, but all dampeners still working. NOW you can test trimming again and see, if it works all right, because the FD lets you control the angular position of the KA-50 NON-INTERACTING with autopilot respectively the navigation system. I'm quite sure you won't experience any problems testing the trimming this way. Flying with autopilots / navigation system is another story, but it is extremely well documented in great manuals in the internet or in utube videos. Happy flying!

So say I.

Marked in red "R-800 volume" above: It's the ADF panel. The volume control here is for both NDB audio signals code and self test tone.

Thank you, I think I am fine. Can you say you are, too?

In RL the R800L14 VHF/UHF volume knob is mounted on pilot's helmet. Due to its position it is not implemented in the KA-50 cockpit, what makes sense. Unfortunatelly there are not any keyboard-shortcuts for the R800L14 VHF/UHF to change its volume, what is hard to understand. The only way is to open the "menu" inflight ( "ESC/Option/Audio/helmet") to change the volume. I am not sure if this item is still reported, but I deem it a bug.