Fastbreak

You also believe in storks carrying babies and delivering them to parents, don't you?

There are a lot of information out here in the BS2 forum, but ED does not react to them in an appropriate way - in terms of content (newsletter, forum) or time (internal business organisation?). Consequently (critical) users both should economically act (instead of being cash-cows) and at the same time tell ED which modell charachteristics could be improved (within real-world parameters, no vodoo features...). Economic logic has it that if money starts to miss, ED themselves will begin to put questions to their users and will become more informative. If users just eat everything put on their plate, necessary (e.g. multi-core and Vulkan) or common development will literally take ages ...

My proposal: Study macroeconomics, at least the basics, and apply them to DCS - let your money talk to help ED in making the right decisions (nevertheless, the "decent amount of humor and good will" are an excellent idea! ).

... one year ???!!!

Information on BS3: - Patches (e.g. Shkval, AI, cockpit lighting & buttons etc. pp.) : not given - Deeper simulation of equipment (e.g. electronics, hydraulics) : not given - Needed reality improvements (e.g. rocket behaviour, sling rope transport) : not given - Old but absent features (pilot body) : minimum - Rough scheduling : not given - Reaction to (reasonable) questions : not given - Rewrite code (Multi-core and Vulkan) : not given No need (any more) of second thoughts due to scheduling and quality of BS3 ...

"I am a leaf on the wind. Watch how I soar!"

AI has been weighed, it has been measured, and it has been found wanting. In what world could it possibly convince me? An ED's Tale 2008-2022

This software has taught me one thing. Brilliance, pace TOM, is an unbelievably impressive expression in terms of DCS ...

Some information respectively a summary of progress are a problem, because of missing screenshots? This is your statement- seriously?

YES! By the way, the Ka-50 has had a pilot body from the beginning until its latest cockpit update (graphics) about 2.5 years ago, so a pilot body is definetively not a new feature or should be considered as a feature at all - it is a deliberate omission.

The brightness knob has not been working for 10 years or more. Never? I do not exactly remember any more... Manual 6-60 , figure 23. 23. “ЯРКОСТЬ” (Brightness) knob. Adjust panel backlighting brightness*. Increase brightness [RSHIFT + RCTRL + P] and decrease brightness [RSHIFT + RALT + P] *It relates to the PVI-800 panel only, not to the four autopilot buttons!

Distributing the thread's workload across multiple cores increases CPU performance. Vulkan can make use of all the available cores by redistributing the workload across a number of threads and scale the work without just generating more work. In order to be truly scalable, the Vulkan API spreads its workload across multiple threads with as close to zero overhead as possible. Vulkan does not scale multiple cores, because this is an explicit API after all, but Vulkan provides the tools and mechanisms needed in order to allow applications to scale as they want. Some of this can be achieved by simple design choices and yet more by providing objects that explicitly cater to multi-threading. I sincerely wonder why MultiCore and Vulkan shall be introduced in discrete way. Although two different APIs, as far as I understand MultiCore and Vulkan are mutually dependent to yield the best performance and efficiency result. I am eager to hear some more detailed explanation from ED - thank you.

Hi Frost, It's not exactly what you are talking about, but maybe you want to have a look at: DSMC for Digital Combat Simulator - the scenery persistence mod for DCS world 2.7 and above by chromium https://dsmcfordcs.wordpress.com/updates/ https://drive.google.com/file/d/111G8aIuTCrM-HegNLY-t2D3k1qbU27m6/view P.S.:

Mea culpa!

Dear Malakhit, dear Dragon1-1, I am sorry, I should have been more specific with my comment. From a higher-level business point of view, a company's has to be flexible enough to accomodate the changes in the market any time. Its business modell has to forcefully grow and optimise its internal structures with the objective of consistently directing towards its customer needs - especially in fast-growing markets with a large number of customers. The permanent adjustment of bussines development to the market is regarded as standard nowadays. This is my understanding from education in economic science and my experience of many years in the international sales and marketing where I have also been directly involved in the perpetual challenges of hardware development processes (nanotechnology, EBL and IBL systems) and its complex control and application software. I have witnessed the hardships of our specialised developers and programmers in their daily endeavour to meet their deadlines that have been strongly influenced by the objectives of our business managers respectively our customers - oftentimes much to the chagrin of our executing experts. Nevertheless, our customers and their demands have made our business running (and my salary) and so we have had to stay agile. We have been rarely able to afford the luxury of delaying development, bug-fixing or disorganisation. From day-to-day, from month-to-month and from year-to-year the complexity of our activities has grown and due to our success it has been essential to grow our internal structures, i.e. human resources, expertise, organisational measures, to the same degree. Statements like "As long as it takes." are very starry-eyed, planning at an early stage, accurately timed processes and projects, has been extremely strenuous for every colleague, but it has not been an option, it has been a prerequisite to customised products, confiding customer relationship and sales revenue. I am also familar with incalculable factors that nonetheless of all optimising measures can come into being and lead into both unplaned situations and delays at customers' side at worst. With this background I daresay that I indeed am a customer with above-average patience who deems highest quality to be imperativ, too. I understand and agree your objections that it does not make sense at the moment to throw more staff at the new core engine to finish it, but I ask myself why ED takes so much time. Without insight into ED's internal organisation, and it ill behoves me to ask for it, I could only speculate about potential reasons (wine, women and song ?) why ED's work on Vulcan Vulkan/DX12/MultiCore apparently progresses slowly - despite of their long-standing experience. Once again, I am aware that ED's developers and programmers are not hired to wear themeselves out with their work to satisfy impatient fanboys, rather it is the management to know potential problems beforehand, to plan and to coordinate at the earliest to avoid problems at the best. After more than 13 years especially standing customers who do not only dabble in DCS should be able to benefit from significantly better organisation in form of punctual updates, bug-fixing, less promotion and more communication - transparent & informative, and EA periods that do not take several years - after all there are some users who past their prime... Me? No, never!

"This is the kind of project where you just have to leave the coders alone to do their thing." What would you say is an appropriate period of time for writing the new code? What would be your decisions as a responsible product manager to speed up this important and overdue development step? As long as customers are not economically driven I suspect ED will not find a sufficient solution for their pace (I explicitly do not talk about the coders). Nevertheless, I will keep my finger crossed.

"One of the things I notice is that George is always just glued looking straight forwards. Are there any active plans to have George look out the canopy or look down at the TEDAC? Especially as he is cueing weapons with the IHADDS?" This ought to be no question, but a given of a high level cockpit simulation! I also have noticed the annoyingly static helmet/body of Georgie Porgie at once, it's a kind of 1997 low level style. The cockpit unfortunately is an incomplete simulation till this day. The EA release without proper helmet/body movement would become very iffy - IMHO.

Latest newsletter - it's not exactly brilliant. Again no news on the KA-50 upgrade/bug-fixing, more important again no news on Vulkan/DX12/MultiCore(also relevant for KA-50). It is easier for a camel to go through the eye of a needle than for a brainy customer to enter the kingdom of ED's train of thoughts...

Okidoki

In-flight Single Engine Failure If one engine fails or there is an automatic engine shut down due to the free-turbine (FT) protection function of the electronic engine governor EEG in case of a FT over-speed, be aware of the following: Single engine failure indication: - Rotor RPM decreases and the «zebra» light (rotor speed less than 85%) illuminates - Noise of an engine shutting down - Uncontrollable descent of the helicopter - Ngg and EGT decrease for that failed engine - Engine inlet oil pressure drop (by the oil pressure gauge) - Ngg increase in still operating engine Actions to take: 1. Decrease collective pitch to avoid rotor RPM less than 85%. 2. Check the instruments to identify which engine has failed and close its cut-off and shut-off valves. 3. Set airspeed to 110 to 120 km/h and move the throttle control lever of the still operating engine up to FULL mode position to regain the rotor RPM. 4. Make sure there’s no fire aboard the helicopter. 5. Open the fuel cross-feed valve. 6. Make sure the remaining engine is operating normally and that the helicopter is able to maintain horizontal flight and maintain altitude. 7. Decide whether to do an emergency landing or to continue the flight. Manual 10 -47

I can share your experience. This error exists, as far as I remember, for years and was discussed here before. Nowadays it is less likely that it happens (obeying the intervall rules of use for the laser*), but sometimes there is definetively a mess with it yet. Just a guess, maybe the activation of optional damages in the ME (Set Mission Options/Random System Failures) makes the laser by coincidence burn out too early? Or it might be quite a different bug ... * Laser rangefinder operation mode for one flight, series: 5 Each serie consists of 16 cycles of 10 seconds with 5 sec interval between the cycles. Interval between the series, min: 30 Manual 13-4

"Two Ka-50s were fitted with FLIR I’m guessing as a prototypes but it’s more realistic imho to give us the rare Ka-50N than an Igla which didn’t exist." I did not know that Iglas did not exist. Given this, I would also prefer the KA-50N prototype to be simulated. FLIR with fully, realistic working Vikhrs (+Shkval) as premise are a much better equipment for a helicopter mainly operating low-level to destroy ground targets than Vikhrs and Iglas without FLIR.

Hi 3WA! New feature vs bug-fix "THIS. I do want the Igla's because the shkval is so BAD at trying to lock aircraft, even helicopters against a clear blue sky." I agree, but I disagree your reson why. If the shkval is this bad, and it is because ED has botched it up, you should logically require bug-fixing first and foremost. Nonetheless, Vikhars should be very effectiv against air targets, too*. With Vikhrs (and Shkval) fully working against aircrafts some fast short-range air-to-air Iglas become a real benefit. Iglas therfore extend the air combat capabilities as far as a helicopter gets involved in an air fight at all. Bug-fixing should always have highest priority, in your argumentation, too, because broken functionality must not be replaced by new shiny features which again may produce shortcomings conducive to DCS's SCD (Safe Circle of Desaster)! * 9K121 Vikhar: Range 08-10 km, speed 1.8 Mach, warhead 8-12 kg tandem HEAT charge, armor penetration behind ERA etc. Igla-V (from 9K38 Igla): Rrange 5.2 km, speed 2.5 Mach, warhead 1.17 kg with 390 g HMX etc. Reality vs wishes "We NEED FLIR to have night capabilities. ED says they are making the Shark as it would be if it had been continued in development. It would have had FLIR. And most likely whatever EO system the Ka-52 is using." I disagree, yet I have to admit that I would love to use FLIR in KA-50. However, the KA-52 indeed is a different rotor wing, while very similar. Features that are not available in a real world aircraft do not belong in its realistic simulation per definition - a 'motley Doomsday device' better lends itself to some war game. In short, do not get your knickers in a twist and fly those (day) missions which the KA-50 is built for or switch to a different cockpit. The President S System in contrast is an optional equipment for various aircrafts in reality and therefore it can not be excluded from implementation (except Moscow mothballs it). Transparency Many open issue with the current KA-50 (2) require a detailed to-do list summed up from the forum. To avoid oversight ED ought to publish the(ir) to-do list in a newsletter (e.g. Newsletter Special - Upgrade to KA-50 3) where they tell us EXACTLY what items of KA-50 they will REMODEL, PATCH, and EXTEND* - BEFORE they start to rack their keyboards. Something by the way I consider a matter of course. The open to-do list does its bit to take the KA-50 3 to an overall development level that is par for the course after 13 years. * Especially with regard to Vulcan/DX12/Multithreading Bye

True beauty comes from within - of course, a splendid outward appearance is not to be scoffed at, either.

"The multi core Engine and Vulcan must come soon!..... The Weapon must fly smoothly, beautifully and with true intent of purpose." I agree. After all, I start thinking that ED might be struggling to cope with the demands of Vulkan/DX12/MultiCore in respect of the long time they take to implement - but this is just my guess with no offence intended.