Leaderboard

We really cant win, people demand news about stuff we give them news then they don't want news until its ready. There is no pleasing everyone, but we try. We will not give out dates until its closer, so we didnt. We wanted to share progress news so we did.

ASC: C-130J Check Six Media DCS: Top End Australia develop pics:

From Polychop Discord

I know there was a thread that was closed previously. That thread is half a year old and ANY fuselage damage results in complete fuel loss at the same rapid rate no matter where or how major/minor the damage is. You stated that fuel leaks are likely when the fuselage is damaged, fine. But, having EVERY hit, no matter how minor, to the fuselage cause catastrophic, rapid, leaking from all tanks, with no way to preserve any fuel, is ridiculous. Please give us an update on this or let us know we have to live with a single 7.62 to the left side of the intake being the same end result as a direct missile hit.

Thanks, some of us appreciate it. As a software engineer of almost (gosh !) 25y experience, I am sometimes critical of ED for certain things that I think should be done better (non-regression testing, for instance). However, in the case of going from single to multithread (even if multi=2 for a start) on an old code base, I am behind them 100%. Remember, people, you're *not* asking for *multithreading*, not quite. You are really asking for *more performance*. In particular in VR, where I don't expect much from MT. And for complex scenarios like MP, or smarter AI, or whatever will be required for a dynamic campaign, where the background computations can be taxing on the CPU. But know that thread-safety is incredibly hard to get right, especially when not designed in from the beginning, and it's quite easy to see either the ugliest, nastiest, bugs that computer-assisted mankind can produce. Or to overprotect (either by the "mutex sprinkle of death by crawling molasses" or the "death by copy-all no side-effect heaviness of misery") and see performance drop through the floor (worse than single-thread). In the latter case, you would get your multithreaded DCS but with unacceptable perf. In the former, you'd get epicly hard-to-reproduce bugs that would leave the userbase in arms and the devs baffled. They *need* to get this right, from the get-go. So, patience. Waiting is.

You can’t please everyone but I am sure many (like me) are very happy to get such updates. Moving into internal testing is a significant project milestone and well worth communicating IMHO.

Just to avoid any confusion about FPS. I Read something about the Main-Rotor is much too high poly Please keep in mind that that effect results in baking the High-Poly mesh on the Low Poly one. It may look like killing FPSs, but that's just a game on tricking the eyes. The Normal Maps are overriding the hard edges

DCS WORLD: KA-50 Black Shark 3 || IGLA Air to Air Missile In this DCS world video we will be taking a look at the Igla Air to Air missile for the KA-50 Black Shark 3 which is releasing soon!

A quite late as I've been quite busy but here it is. Let me know if I missed anything The Unbound System 2:19 Start of interview with Kickstarter founders of "The Unbound System" 4:24 Tell us about product, what is the company's name? What is the product's name and what does it do? 7:02 What other options are there? 8:26 What about weight? Are there any issues with heavier equipment? 12:49 So tell us a little bit about your kickstarter... F-15E 15:18 Interview start 15:39 What can you tell us Ron that is the latest and greatest with the F-15E, what's ground breaking on the F-15E that you want to tell the folks? 20:58 My question I wanted to ask since we have FC3 with F-15C, nothing from that was taken so you did everything from scratch right? 21:48 And speaking about the level of detail... 27:43 So you said this is the most complex aircraft that you have ever built or is that in DCS at the present time? 28:06 What would you say is the radar capabilities are the most complex 29:56 Do you ever see yourselves putting any DTC into the F-15E eventually? 30:46 There is a lot of workload for the WSO, is it going to be multicrew capable from the start? 33:55 I've seen a lot of your videos on Twitter and the M-2000C radar is amazing so I'm looking forward to the F-15E's radar 34:56 What do you hope this module will add to DCS, and what type of scenarios and environments do you see people operating this aircraft in? 38:28 Just to recap....and then we got 3 helicopters, 2 jets that are coming and the MiG-23 is that one of the jets that's coming? 44:09 Is there a big thing in the F-15E that won't be on early access?

Personally I’d be happy if ED decided to release it as a temporary third branch: Stable, Open Beta, and Open Beta (multicore).

Multithreading Development Report To date, DCS has performed most of the computational workload on a single thread (some audio components were moved to a separate thread). This was not a problem in most cases because the Graphics Processor Unit (GPU) did most of the work, and FPS was mostly limited by the performance of the GPU. As DCS evolved, GPUs have become much more powerful whilst the performance of a single CPU core remained practically unchanged. Instead, CPU manufacturers increased the number of cores rather than the clock speed of individual cores. As a consequence, DCS performance has become CPU-limited. In parallel, DCS World has become much more complex with increased reliance on CPU calculations that has exacerbated the problem. To improve efficiency of CPU resources usage, we have reworked the core of our engine. First, at the architectural level, it has been divided into two main threads: graphical and logical. This opens up new possibilities for further thread parallelization of calculations in both the logical and graphical parts of the engine independently. Second, to meet the requirements of scalable multithreading, and the needs of modern graphics APIs, the graphical engine part has been significantly enhanced. In addition, many subsystems have been updated, or written from scratch. Internal testing has begun, and we plan to release the updated DCS graphic engine (EDGE) next year. The initial release of Multithreading support will contain a fully reworked engine including preparation of the graphical frame and the separation of the graphical and logical parts onto two independent threads. It should also be noted that the most significant performance improvements will be regarding larger missions. This will be a welcomed change, especially in multiplayer where unit numbers are typically far higher. VR performance will also see a significant performance improvement in large missions. Stay tuned for upcoming releases. Source: https://www.digitalcombatsimulator.com/en/news/newsletters/2b4826e39c84423db49b8789fe2409f3/

Project 775 Ropucha Class by Currenthill Please DO NOT redistribute this mod without permission! Version 1.0.1 https://ln5.sync.com/dl/6d38d0890/ktiruc2w-i3djmvac-rrjsvciz-fwzcrq6y Installation 1. Extract in 'Saved Games\mods\tech' folder or use OvGME 2. Add the following files (from your old DCS 2.5x installation) to Saved Games\mods\tech\Project 775 Ropucha Class 1.0.1\Shapes - BDK_775_LOD0.EDM - BDK_775_LOD1.EDM - BDK_775_LOD2.EDM - BDK_775_LOD3.EDM 3. Add the following files (from your old DCS 2.5x installation) to Saved Games\mods\tech\Project 775 Ropucha Class 1.0.1\Textures - BDK_Back_basecolor.dds - BDK_Back_basecolor_RoughMet.dds - BDK_Back_Normal.dds - BDK_Centre_basecolor.dds - BDK_Centre_basecolor_RoughMet.dds - BDK_Centre_Normal.dds - BDK_Chains_basecolor.dds - BDK_Chains_basecolor_RiughMet.dds - BDK_Chains_Normal.dds - BDK_Damage.dds - BDK_Damage_map.dds - BDK_DmgInterior_Basecolor.dds - BDK_DmgInterior_Basecolor_Roughmet.dds - BDK_DmgInterior_Normal.dds - BDK_Front_basecolor.dds - BDK_Front_basecolor_RoughMet.dds - BDK_Front_Normal.dds - light_green.dds - light_red.dds - light_white.dds 4. Check the included Demo mission (in folder missions) to learn how to use the bow door! Developers - Currenthill Credits - ED for model and textures (not included in the mod) - Suntsag for original idea - Urbi for liveries and wake file Features - Ropucha Class landing ship based on EDs model and textures - 2 x AK-725 57 mm cannons with custom shells - Lights - Waving flag - Spinning propellers - Working damage model - Working bow door (land a helicopter on the ship and the door will open, see included mission for more information) - Realistic ship performance - Will go very close to shore for landing missions - Working FCR - Exhaust smoke - Rotating radars - Custom sounds - Custom MR-302 air/surface radar Known issues - AK-725 guns doesn't move visually (had to disable the movement since the ED model animations are backwards) - FCR won't turn correctly towards the target due to incorrect animations in the model) - The forward radar won't turn because of model issues - Ships won't fire antiship missiles since they classify this ship as a light armed ship, aircraft will fire antiship missiles towards it though Changelog 1.0.1 - Release version

You're missing the premise. Since going from max loiter or max range cruise to a max velocity at launch in the shortest possible time is key, acceleration beats top speed. The 1960s just called and they want their tactics back.

Спасибо за ответ! Будем ждать. Тем более уже подготовили множество ливрей для данной области

use RShift+\, after last MOD update we added base Radio System, set preset freq and custom one in Radio Panel

And a new one from this week on PC discord.

It is, in the next sentence: "To improve efficiency of CPU resources usage, we have reworked the core of our engine. First, at the architectural level, it has been divided into two main threads: graphical and logical. This opens up new possibilities for further thread parallelization of calculations in both the logical and graphical parts of the engine independently." Taken with the paragraph before the one you quoted from (in which E.D. make all the points you contain in your paragraph after the quote above) they have said: CPU manufacturers have focused on multi-core as an approach to performance improvement rather than single core clock speed / throughput. To date (with the exception of some audio) DCS has run as a single threaded process, and so could only use a single thread on a single core at any given time. Individual cores are not increasing in performance, so the only way to improve DCS performance is to pursue multi-thread parallelisation. As a first step the SIM has been split into 2 main threads. One dealing with 'logic' and the other with graphics. If there are 2 threads running in parallel, the game is multi-core capable. (actually, 1 for graphics, 1 for logic and 1 for audio means the game would be capable of using at least 3 cores) Having split the logical and graphical parts of the engine, E.D. are free to pursue further parallelisation of either one of, or both of, the 2 main processes - presumably depending on where they see the easiest performance wins coming from. There isn't really much news in the statement other than that the initial split will only be into two threads & that these will be logic and graphics. the change is already in internal testing.null 1 might seem disappointing to those that were hoping to see all 88 threads maxed out, but expecting everything all at once is a curse placed on our times, and this is a realistic first step. 2 is good positive news of progress ! As for the rest of the message -They've been saying they're working on multi-threading for a long time, it's more of an expectation setting message than anything else. I had some comments about shirt poosters, but I'll keep them to myself...

Great news . Suggestion:- another “next year” news item. ED seems to feel the need to throw out arbitrary news with arbitrary dates that are never met. Seems by now you’d stop doing this unless you like like the constant “2 weeks” banter as a mocking of how silly your dates are. We’ve all grown old of this. So how about you just wait until it’s done and then say “next patch we will introduce multicore” and not continue to make the same mistake over and over again. Just 2 cents from someone who spent $6000 this year to play your game :)

Да-да, мы знаем что VR это плохо. И пусть нам будет хуже.

Korea should absolutely 100% come to DCS before Vietnam.

I try to keep my work in as few places as possible, so that when I update, there aren't a lot of rogue links with old versions running around.

Here: https://drive.google.com/drive/folders/1NX9bHf1kYAFkEZqvoOQnt5LvrE_Tw0Fm?usp=share_link Now @currenthillhas made abundantly clear I'm not to host his mods so I won't. But deeply grateful for his fixes!

Just sharing a small project to imitate a "force sensing" joystick for the F16 without going all the way with a Realsimulator FSSB. Was finding that with a standard VKB Gladiator and "normal" joystick curves (either linier or exponential) it was difficult to find a setting that worked for the Viper. F18 and A10 felt fine, but the software imitation of the F16's force sensing stick just didn't work for me. Nothing impossible mind you, it just felt "off" and there was no way I could ever get close to an AAR connection. So after a bit of measuring and CAD work to make the stl, a 3D collar was printed in TPU to fit between the bottom of the grip and the top of the base. The idea being that by printing in TPU (a flexible filament) with a low infill percentage it would both limit X and Y throws as well as act as a force to move against. The print was done with 15% infill, which has worked out to be just about right for me. It provides sufficient resistance while being able to deform to accommodate joystick movement. Total throw is now about 10cm X and Y, with resistance increasing linearly from center. Between the collar and the base is some thin foam material to help reduce the "stiction" of the TPU on the base body. Flying the F16 is now very nice. The limited movement and increasing resistance as the joystick moves from center makes it much nicer to fly - at least for me. To the extent that within 10 minutes of using it I could get an AAR connect for the first time. Now I just need to stay there long enough to fill up! The X and Y curves are done in Joystick Gremlin and there's still some tweaking to do, but quite happy with the result. And while it's much better than before, I don't expect it's anywhere near as good as a FSSB. I've started dropping hints to the wife that maybe I should get a Realsimulator FSSB for my 60th next year VKB Collar.stl

CM3 vs CM2 The differences between these two throttles are largely cosmetic and fairly minor, with one major exception. a) Encoders E1 ad E2 have different dials. In my opinion, I much prefer the new dials. They are tapered and have a more positive feel when turning. b) Flaps axis has a dimpled top. Makes it slightly easier to move with the extra grip. c) Mode switch dial and switch are different. Maybe just a difference between individual examples, but the CM3 switch felt smoother and more positive. My CM2 mode switch has a slightly crunchy feel to it. d) Throttles are taller giving more sensitive throw. e) Improved throttle uncoupling switch. The CM2 uncoupling switch was awkward and stiff to use, and the CM3 version has greatly improved on this. I have read that some people are not so happy about how loose the CM3 uncoupler is, and I feel that it could have been given a bit more resistance, but I much prefer the way it is on the CM3. Very easy to couple/uncouple. I have also read that some people believe there is too much play and movement when the throttles are coupled. I don’t see any difference between the CM3 and CM2 in this respect. Anyway, when they are coupled, their outputs are linked, so it makes no difference. f) Button 22 has changed. Flat now rather than the previous indent. Cosmetic. g) Rotary dial on left throttle moulding has changed. Fairly cosmetic, but makes a bit of a difference in that the new indent makes it more obvious that there is a button press on the knob. I feel that both the left and right rotaries on the throttles feel more positive when being moved, but again, that could be down to individual samples. h)The biggest issue by a long way, is that Virpil, in their wisdom, have changed the button configuration on 2 of the 5-way hats, i.e. buttons 23-26 and 28-31. Now, I’m sure they had their reasons, but this means having to rebind all of these buttons in every DCS module and every other game. What a pain! General Comments a) The zoom slider axis on my first CM3, which I had to return to Virpil, had an issue in that for part of its travel, it scraped along the side of the casing making an annoying sound. The replacement throttle zoom axis makes a sound throughout its travel. Now, I think this might be deliberate from Virpil as what it does is make the movement slightly stiffer compared to the CM2. The advantage of this is that the slider stays in position better than the CM2 which always tended to return to its centre position too easily. I just wish this could have been done without the scraping feel. b) Detent screws. When I was experimenting with the different detents, I was aware that the supplied screws and allen key were not of the best quality, and might be prone to wearing. So, I bought some better quality screws – M3 x 12 A2 (as advised by Virpil) - online in advance of getting my replacement CM3, but when I tried to use them, I met resistance after about one turn, so I decided not to go any further and risk breaking the thread. I will consult with Virpil on that. Seems strange. UPDATE: Just tried the bought screws again and everything was OK, so must just have been a bad one in the batch. c) The packaging is appalling for an almost £500 (including taxes and delivery) item. Just a blank white cardboard box with the throttle inside a flimsy piece of bubble wrap. Nothing else – apart from a useless piece of cardboard – to protect the unit in transit. This has been the same for all the Virpil devices I have bought. Very poor, and really needs to be addressed in the future. d) On both the CM3s, there is a discrepancy between the throttle movements when uncoupled. By that I mean the percentage travel is different by a few percentage points when being moved together. UPDATE: I resolved this issue by adjusting the DZ Min and DZ Max for both throttles. Quite a complicated process to work out what is going on, especially as one of the axes is inverted, but in essence, you have to adjust each one to provide the correct and identical amount of travel between the detents. In my case, that is 4%-72%. I achieved that with a DZ Min of 1 for both left and right, and DZ Max of 4 for the left throttle and 1 for the right. e) The detent mechanism works really well, but it does require quite a physical effort to lift them into afterburner. I asked Virpil if this could be loosened a bit, but apparently not. Now, this isn’t a big issue, but it does make them quite hard to use if you have your throttle sitting on a desk - as opposed to being mounted – like me. This is because the throttle can move around a bit on the desk when lifting the levers over the detents. (I’ve got Virpil desk mounts on order!) Setting Up the Detents Various types of detent are supplied with the CM3, and after a lot of experimenting, I am currently using the Classic Plus set. This is mainly because I like having a notch on the idle/stop and a lift – as opposed to a push through - for the afterburner. UPDATE - after several days of use, I changed my mind and am now using the Classic set both front and back. I decided that there wasn't any real benefit of having a notch. There is more of a case for the idle position, but not really for the forward/AB one. Personal choice. Obviously, there are 2 aspects to the setup, the stop/idle detent and the afterburner detent. 1) Idle/stop Detent There have been various videos on this subject which tend to use the VPC software to map some of the throttle travel to 2 customised buttons to act as the throttles in an ‘off’ and ‘move to idle state’ in the axis panel. Now, as you only have 4 axis-to-button slots for the whole device, this seemed a little wasteful to me. Not everyone is aware that there are also pre-set ranges for axis-to-button which can be accessed by double clicking on the relevant axis in the axis panel. There you can see various ranges, 0%, 0-20%, etc. The only disadvantage of using this method is that you can’t choose which button the axis will output, but I don’t see that as a problem. (As an aside, I use this method on the flaps lever axis for the flaps stages on the Hornet. 3 axis to buttons for 0-20%, 40-60% and 80-100% for auto, half and full). I did a little initial experimentation with bindings in DCS, and decided that I didn’t think 2 buttons were required for the idle/stop detent. So, for both the throttle axes, I selected the pre-defined 0% and none of the custom slots. Then, I setup those 2 buttons in the buttons panel in the VPC software to give them a logical button number for Windows to recognise, physical 73 and 74 in the attached image. UPDATE: After locating my physical detent fully back on the throttle, I then defined the binding in DCS. For most modules, setting the 0% as either throttle/engine idle/stop or idle or stop works fine. In order to work out which binding works best, just go to a ‘Cold and Dark’ mission and try out various options. For example, the Hornet, Viper and F-5E work nicely with OFF/IDLE set to the 0% button. Others work well with it just set to OFF and moves OK into idle from OFF. However, this is down to different modules having different configurations. I have successfully configured 12-15 modules this way. (The only one that didn’t work was the A-10C. That requires a button for OFF and START. On that, I just used the defined physical buttons 127 and 128 as START and the 0% buttons as STOP. This is a little annoying, having to use 2 button slots just for one module, so you could just use the 0% button + modifier in DCS instead). UPDATE to A-10C: After discussion in another thread, there is now a way to solve the A-10C issue by inserting 2 lines of code into the files E:\Eagle Dynamics\DCS World OpenBeta\Mods\aircraft\A-10C_2\Input\A-10C_2\joystick\default.lua (and the equivalent for the A-10C). These lines are from the Warthog lua file and are examples of bindings that are available to the WH, but, rather bizarrely, not to other devices. The lines are: {down = iCommandLeftEngineStop , up = iCommandLeftEngineStart, name = _('Left Engine Throttle Set OFF') , category = _('Systems')}, {down = iCommandRightEngineStop, up = iCommandRightEngineStart, name = _('Right Engine Throttle Set OFF'), category = _('Systems')}, By inserting these lines into the default.lua files and binding the 'Left (and right) Engine Throttle Set OFF' to the 0% button, the A-10c works exactly the same as the others now, and I was able to remove the virtual buttons 128 and 127 from VPC software. IMPORTANT: If you want to use this technique, it is important that you set up the VPC software dead zones appropriately, otherwise it won’t work due to the sensitivity of the device. By default, I’m pretty sure Virpil have a dead zone of 4 on the ‘Axes lock function’. This must be set to 0. The values for DZ Min and DZ Max for each throttle axis need to be adjusted as well to achieve synced movement between them. See above in General Comments d). The final thing you have to do is to define throttle dead zones for each module within DCS to avoid having throttle thrust when stopped on the runway when just past the idle detent. With the throttle just sitting fully back past the detent, go to your axis settings for each module, and you will see a bit of movement in the throttle bar. What you need to do, is to set a dead zone in ‘Axis Tune’ so that white bar just disappears. In my case, I need a DZ of 4 in every module. (See attachment). 2) Afterburner Detent So, you’ve got your idle/stop working, now for the afterburner (AB). This is a little more fiddly than the idle/stop one as it requires fine tuning for each module. The first thing to do is to locate and secure your physical detent in the fully forward position. This allows maximum movement of the throttles. Then, you must – by trial and error – adjust the ‘X Saturation’ curve in DCS Axis Tune settings for each module so that the jet’s AB comes on just after you go over the forward detent. This means that for each module, you will be a max mil power at the detent, and kick into AB just after. Let’s look at the process. As an example, load up the Hornet Free Flight mission, put the plane into barometric hold, go to external view and rotate to the back so you can see what’s going on with the afterburners. Now, push the throttles up to the detent. The likelihood is that you won’t see the AB come on. Push the throttle just past the detent. You might now just see the AB start to come on, but not necessarily. What you have to do is adjust the ‘X Saturation’ curve in ‘Axis Tuning’, so that you don’t see any AB when in front of the detent, but you do see AB fully kicking in after the detent. In my case, the Hornet was 85% (see attachment), and although the process had to be repeated for each module with an AB, they were all similar values, and you only have to do it once! Aircraft Without Afterburners Not all planes have ABs, e.g. Spitfire, A-10C, etc., so you need to deal with them. Clearly, removing the detents, or just keeping them in place to reach 100% throttle say, is not ideal by any stretch of the imagination. So, what you must do, is adjust the curves to that the distance between the detents represents 100% travel. Then you just keep the throttle control movement between the detents. This is done by firstly adjusting the dead zone in the same way as in the idle/stop procedure to give you the 0% position, and secondly, use a similar procedure as above for the AB to fix the 100% position. To do this, put the throttle in the forward position just before the detent, then in DCS Axis Tune settings, adjust the ‘X Saturation’ until you see the white bar filling the box. (In my case, all modules were 72% X Saturation, this being the percentage travel of the throttles to the AB detent - as can be seen in the VPC software). Test it by moving the throttle fully forward and back to check that you are getting 0% to 100% between the detents. Although this method does give you a reduced physical travel, with the detents positioned as widely apart as possible and the extra height from the CM3 throttles, in practice, I feel it doesn’t make much difference. Then, you are all good to go!

Sure would like to see another variant soon.

More or less but mostly everything can be calculated with just simple involving elementary study of rocket motors. Luckily there are plenty of motors sharing same diameter 380mm or 15’’ and having similar composite fuels so even visible differences forcing directions. All these three are in 380mm 5V27 of S-125 Neva (SA-3), R-33 and Kh-58…all in same diameter as AIM-54 5V27 is primarily for low and near to intermediate altitudes and nozzle is sized respectively Kh-58 is more for low intermediate and near to low altitudes This motor’s cross section is my creation but I stand for it very firmly And this is Mk47 Mod 0 with nozzle bell sized, obviously not optimized for sea level or intermediate altitudes but for up there altitudes just as R-33

Also the extent of the damage plays no part on the speed of the fuel loss. A rifle hit will result in the same speed of fuel loss as a 10mm cannon hit. This needs a rework.

I found this in imgui.ini: [Window][###FPS] Pos=0,10 Size=224,260 Collapsed=0 imgui.ini is in saved games\config I would use notepad++ to make changes.

BS3 is already in the Steam database. https://steamdb.info/app/2214600/

The new FPS counter in 2.8 revealed for us, that in the total frametime one of the largest chunk is "simulation". I wonder if the multithreading means that this "simulation" part will be completely detached from the rendering frametime, thus enabling higher framerates at start? Or the frames simply can't be rendered without the fresh simulation data no matter what? The current CPU + GPU hardware seems to be enough for pleasingly high framerates in 2D, the VR what seems extremely critical because of the need of high framerates combined with very high resolutions and dual displays. But for VR what is the most important part is to have virtually lag free very smooth movement for precise head tracking. Despite of the needed 90 fps this can be pretty much solved with asynchronous reprojection (ASW for Oculus or motion reprojection for WMR) at much lower framerates which would be perfect. The only problem are the visible artifacts of the reprojection. If those can be eliminated then even the current state of the sim would be very good for VR. But if the rendering and logic threads will be separated then this could yield high gains in the long run. The best description of the current situation is made by @SkateZilla in another topic here (I'm rather curious why not using such interesting details like this explanation in the newsletter by the way...):

http://www.wwiiaircraftperformance.org/fw190/Fw_190_A-8_15-3-44.pdf No date when the modification was widely available. Only "In Kürze" / Soon dating march 1944.

Интересно. а почему всегда "в личку написал"? Что мешает объявить цену сразу? Вот эти "в личку написал", по опыту общения в соцсетях, в 146% случаев или мошенники, или "я у мамы бизнесмен с индивидуальным подходом к клиенту". Я, я ничего не говорю про автора темы ни в коем случае, я просто интересуюсь почему нельзя цену указать для всех?

@Volk.@Flappie I'll have a look at it today. A few weeks ago I was able to reproduce it.

Please note that the issue is due to an incorrect installation of the upgrade released by Nightstorm for the main mod by GrinnelliDesigns. You were not supposed to replace folders, but go into each folder and already in these folders replace and supplement file by file. The reason for the lack of necessary files in the Shapes folder is precisely the replacement of the folder, and not the files inside it.

+100

Pm me Its not hard and also future note to remember these guys have nothing to do with mod support in liberation

That's how I feel about it as well: it's a step in the right direction (probably a larger one than I realise), but it feels like this is just the first step in a process that won't be properly completed for a while - as in: it will be a while after 2023 before we see meaningful gains... That's what I read in-between the lines anyway...

That just isn't true at all. My 24GB of ram are usually full (close to). Also, enterprise cards? I wish. Would save me 10's of thousands at work. The 3090 is pretty well saturated in MSFS. It just so happens that its not the bottleneck with DCS in VR. 3090 over 3080 in MSFS yields 20-25% gains. (enterprise perspective... a six year old p6000 will outperform a 3090 in certain business applications)

Aloha, Here is a drivable version of the LaFayette frigate (inspired by the Civilian Assets Pack - Navy v2.0 mod from Eight Ball) with a drivable artillery piece (inspired by the Admiral Kasatonov mod from Admiral 89). la_fayette.lua

This post was never intended to be about all the other what if modifications and I would like it to stay focused only on the boost. Nobody ever claimed EN would be some miracle fix all for the Anton. It would simply make it a little more aggressive with acceleration and top speed. The boost raises final horsepower the engine produced by 250 horsepower or nearly 15%. That is nothing to sneeze at in a WWII fighter. It is a significant amount of engine performance that the aircraft had historically. Us people who love the Anton simply want it to be represented as accurately as possible within the simulation and that includes this boost system which the plane was widely known to have even before our timeline in the game. In the end most of us who love the Anton just simply love it and would argue its effective how it is, it's simply just not accurate to what it was. I would also disagree with the ability to remove the boost unless you are planning on making missions that predate March of 1944. If that's the case by all means do as you will I have never been one to harp on timeline continuity being the most important factor of DCS WWII. However, there are lots of people that continuity does matter to, and most servers are running June, July, and August missions where you would probably have been hard pressed to find an Anton that didn't have the system. I believe the Devs have also stated that the Anton in DCS is meant to be a representation of what you would've encountered in June of 1944. By that logic the Anton should have the EN system, and it shouldn't be something that is an option as by the stated mission of the Devs that would be standard fare on an A8 of that time. Lastly, I never have claimed and as far as I know nobody (who has intelligently added to this thread) has claimed the EN system is a "magical solution to all [of our] A-8 problems". It is simply a system that historically existed on our favorite aircraft and one that should be included just to add to the accuracy of the simulation. I personally know I will never get to fly an Anton irl. DCS is the closest I will ever get and with each passing year less and less flying examples of any plane exist. As far as I know there are no surviving A8s with the original BMW801 engine left in flying condition. So, I personally want the history to be preserved in this digital format for myself and any others who want to fly this or any bird that they will probably never get the chance to touch irl. Is it really too much to ask that we keep our digital preservation as accurate to the historical artifact as possible especially when we fly this because we know we will never get to fly the real deal?

Yes, hence why the maxim of "everything is subject to change" is bandied about with such frequency in these circles. And a few have disappeared, but those what disappear usually have dozens of red flags or never get the sign off by ED to begin with. Plus, if they never come out? You didn't part with money for it. I mean, unless you pre-ordered the P-40F from VEAO. Sympathies if that is the case. But, I fail to see how that's relevant in regards to the F-4 Phantom by Heatblur. We're talking about a developer who has multiple releases. Delays happen, they honestly do. As I said, never believe in a release window unless it's pretty specific instead of something as vague as a year. Why they haven't made a statement about it, yet? I can't say. Probably because it'd just confirm what we already know, really. At any rate, I'd rather F-4E drop in 2023 than get another F-16 release debacle.

I love it when designers open up giving us insights to what lies ahead. Doing a quick search through these forums show early discussions about multi-threading back in 2005 just as dual-processor chips were hitting the streets. Commentors suggested then that it would require a complete re-write of the LOMAC code itself a development of the 1995 SU-27 Flanker product. That's 30 years of commitment to making and supporting an amazing product through all kinds of changing times, people etc. Kindest regards to all those people that have helped along the way! Fantastic news!

In the AH-64D section in here from October 28: Development can only happen so fast with a game as complex as DCS, when trying to simulate an aircraft as complex as the AH-64D. Not every update can include new features, screenshots, or previews; nor will every update will be interesting to every player. A lot of this is very tedious, grinding work by the devs to program, implement, and test (simply stating more lines of code have been added for this project will rarely be interesting). Additionally, existing functions that are already in the game must also be maintained and bug-fixed, some of which are relied upon by future features to work correctly. No news to share. This is quite a big task to implement. It will take time, and will take patience.

Hier im oberen Drittel wird es interessant

thanks a lot. Will try asap EDIT: that did it ! thank you !

Known and fixed internally