Search the Community

Dear ED, please take this in good faith and with an intent to problem solving. I'm a relatively new user, and there are issues with custom snap views: 1) Custom Snap Views get 1 sentence on page 49 of the DCS User Manual. Yes, there are YouTube videos. Some of them are even recent enough that some of the suggestions work. This is basic documentation. If it only exists in a feature list but isn't documented, it doesn't exist. (I'm aware that this fails certain Agile approaches, but this is a brief essay on the value of UX/UI in influencing LTV). Recommend striking the "feature" from page 49 of the manual until actual documentation is available. 2) "Cockpit Panel View Toggle" does not work, at least in reference to unofficial sources that show it working in years past. Is this a bug? Who knows? because its function is undocumented in the DCS User Manual and in the manuals for the aircraft I own. 3) Even if the functions for snap views worked empirically as shown in user-produced YouTube videos from 2-5 years ago, this alpha interface should be upgraded with an actual "Save Overlay." See, as one example among thousands, iRacing, which is far from exemplary, but "good enough." This is an hour of developer time (it doesn't have to be pretty). 3a) Is it worth an hour of developer time? That's not for me to estimate, as I don't have enough information. What I can estimate is the likelihood of user churn based on bad UX/UI experiences early in the customer journey. Here's the short version: as a new user, I find the lack of official documentation of snap-view saving a UX and UI disaster to the extent that I can't even assess if the system is bugged, bad, intentionally abandoned, or simply not accessible to new users without considerable time commitment. One might imagine that users purchase DCS products to learn about and fly various aircraft, not to spend hours trying to unpack underdeveloped and undocumented view settings. So, valued content producers at ED, you can Google "churn based on bad UX/UI experiences" and assess for yourselves if this matters at this point in your growth. Looking at your content expansion over the last few years, I think it does. Fewer hurdles to entry are better. The more of us in this together, the better. When you succeed, we all succeed. Thank you for reading.

The other day there was a "Cumulative update" to windows (23H2 i think) and i also recently updated my Nvidia drivers (551.52), but now when i try launch DCS, both normal & mt, the nvidia splash comes up, then the DCS 15 years splash comes up, and then the game just crashes. Ive attached the log file, from "savegames/dcs/logs", but as the game never actually launches, i dont know how helpful it is!! While in there i did notice a "dcs.log.old" file, should i perhaps delete that? i also attached the windows version im now running. Systems a 13700kf, 32gb ddr5, rtx 3090, nvme ssd dcs.log

When controlling the HUD Contrast with keybinds, increasing it turns on the HUD, and decreasing it turns off the HUD.

Started trying Su-33 carrier landing /takeoff today. Seems I've had 1 random explosion just taxiing and 2 random damage, one parked and one taxiing. Is this a known thing? Edit/add: Make that 3 random damage. One more just taxiing.

This bug is related to the bug with flanker DL, introduced with MT introduction. All airports disappear and even cycling through the selected airport does not help. Attached is the TRK-file demonstrating the issue in all NAV modes. @Flappie@BIGNEWY@BlackPixxel@PVNK@plasma1945 Bug-NAV-Server_1_Operation_Urban_Thunder_V7.4.5-20230520-225219.trk

Every time I play DCS I have to go into the control settings in the UI Layer tab and "Clear Category" for the HP Reverb controller. I use a button on the right VR controller for a control in the Hornet, and by default that same button is bound to VR Zoom, which I do not want. So, I clear the UI Layer category for the HP Reverb controller, and my Hornet keybind remains, and it works fine. The next time I launch DCS, the HP Reverb button is bound to VR Zoom again. So, I go in and clear the UI Layer category again. This has been happening for some number of months now, and it may affect more than the UI Layer controls. I only know the UI layer is affected for sure since that is where the unwanted VR Zoom control is. It is a minor issue, but I wanted to report it so that it is known. Thanks!

P-47 should have 3,400 rounds total, but currently the game only has 2,400 rounds (300 per gun). English manual pg. 46 states 425 rounds per gun with fire rate of 800-890 rpm which should have a firing time of 29-32 seconds, but current it fires for only ~22 seconds. This affects all three variants (D-30 early, D-30, D-40) although only the D-40 is used for the attached report. Attached files contain the following: P-47D-40 gun count 44 strafing.trk - track file of singleplayer mission on Caucasus Tacview-20230921-172412-DCS-P-47D-40 gun count 44 strafing.zip - Tacview file of said mission Screen_230921_172456.jpg - in-game debriefing dcs.log - per requirement for bug report Of note are items #2 and #3, with the Tacview showing exactly 2,400 rounds were fired while the image shows debriefing of firing stops after 22 seconds. Steps to reproduce (formality's sake): Create singleplayer mission with any P-47. In-air or ground start doesn't matter Fly to altitude to prevent ground safety Hold fire button until empty. Note down duration of firing P-47D-40 gun count 44 strafing.trk Tacview-20230921-172412-DCS-P-47D-40 gun count 44 strafing.zip.acmi dcs.log @razo+r made a post in the discussion thread of the game file, which shows the "count = 300," confirming that there is only 300 rounds per gun. Image reattached below, credits to razo+r

Trying out ILS Landings I found that the active runway logic for Mount Pleasant is a bit off. All Tracks where made with 100°/280° METEO wind direction -> runway 28 should be active in all cases since it´s also the ILS runway with 0kts Wind runway 28 is active. with wind from 1-5kts runway 10 is actice with wind greater 5kts runway 28 is active. should be not too hard to fix and also maybe fixes some taxiing problems ( ) so maybe threads can be merged. tracks attached mount_pleasant_runway28.trkmount_pleasant_runway10.trkmount_pleasant_runway28_0_wind.trk

MFD export effect before 2.8.3.37854.1 Open Beta update: After the update: My MonitorSetup: _ = function(p) return p; end; name = _('3440MFD+'); Description = '3440*1440' Viewports = { Center = { x = 0; y = 0; width = screen.width; height = screen.height; viewDx = 0; viewDy = 0; aspect = screen.aspect; } } LEFT_MFCD = { x = 790; y = 410; width = 620; height = 620; } RIGHT_MFCD = { x = 2030; y = 410; width = 620; height = 620; } --[[ CENTER_MFCD = { x = 1565; y = 100; width = 310; height = 310; } ]] JF17_LEFT_MFCD = { x = 350; y = 0; width = 620; height = 930; } JF17_CENTER_MFCD = { x = 2820; y = 0; width = 620; height = 930; } F14_TID = { x = 2030; y = 410; width = 620; height = 620; } GU_MAIN_VIEWPORT = Viewports.Center Previously I can see thru the MFDs on my screen and get a very clean view on the outside while don't have to lower my head and zoom in to see the MFDs, this can be a great help to enjoy flying and operating avionics at the same time, since you can choose a position you like to place the MFDs and read the information on them more confortably. Its for the same reason that some people buy a external screen and export MFD on it. building a monitor setup on the screen is just like building a cabin with many external screen at home, the only difference is one is virual and cheaper, the other is solid and obviously more costy. This should not be canceled just because of "simulation", it's player's freedom to display their MFDs wherever they like without obstucting the main view.

I wanted to do a bit of research with regards to the Curtiss Electric prop as modelled in the DCS P-47 modules in order to ascertain what is going on with the blade angle limits, and whether or not the behavior of the automatic governing vs. manual RPM adjustment was correct as we see it in the sim. As modelled currently, the governing range of the blades in the automatic mode reach their limit at 48 degrees coarse. Yet, by going into manual mode, you can further coarsen the blades to ~88 degrees -- what would be considered feathered. But this does not make sense for a single engine installation. I suspected that maybe the devs had erroneously modelled propeller limits for a multi-engine installation of the Curtiss electric prop and set out to understand how the limit switches (analogous to mechanical high and low pitch stops in a hydraulically actuated prop) function and how they should be configured in a P-47. For this I started out referencing the P-47 series Erection and Maintenance Instructions handbook (AN 01-65BC-2) 10 August 1944, revised 15 December 1947: As you can see, the depiction of the limit switches (mounted on the aft portion of the power unit, which also contains the electric motor) specifies three limit switches: Low angle, high angle, and feather angle. It is important to understand that all Curtiss electric prop installations have these switches as the props can be fitted to many types of aircraft. Indeed, some installations would be for multi-engine aircraft (eg. the B-26), where a separate feather limit would be needed. If one were to look at the wiring diagram for the control mechanism, and also if you read the user manuals for the Curtiss electric props, you can see and read that while the manual increase RPM switch uses the same circuit as the automatic governor, the manual decrease RPM switch makes use of a separate control circuit, one that doesn't pass through the high limit switch, but instead the feather limit switch (follow the yellow line): Indeed, in the generic Curtiss prop user manuals, it mentions that pilots can manually decrease the angle all the way to feather limits (albeit, at a slower rate than using the dedicated feather control on a multi-engine installation) if they use the manual RPM decrease control. One must remember that these manuals (you can check one out here for yourself) are made to encompass general usage of Curtiss props across several types of installations, and so are a bit ambiguous in specifying whether this feature works for a single-engine installation. If this was all there was to the story, the DCS modelling is correct as is. However, we also have this description of the limit mechanism: It mentions that the switches are tripped by cam segments mounted onto the ring gear. It turns out that how those cam segments are mounted, determines when exactly the switches will be tripped. How should they be mounted in our P-47? Which Curtiss electric prop models are installed on our P-47s? Here's what the Erection and Maintenance Handbook says: As you can see, we're already getting some hints about prop pitch ranges, but seeing as how we've got specific models listed and they all seem to be variations of the C542S-A series, let's take a look at that manual: There's a ton of information in here about installation, disassembly and description of components, but we're interested specifically in those cams: Here's the diagram, parts labeled 7-11 are the cams that determine when exactly our limit switches will trip. Notice at the bottom, we've got a note about blade angles?? Hey, we may be getting pretty close here. Let's have a look: Here, I've cross referenced all the specific model numbers listed in the P-47 Erection and Maintenance handbook, and you can see that for each of them, the High and Feather limits are exactly the same -- this means that a manual decrease of RPM should result in the same blade pitch governing range as the automatic mode. But why is our high/feather limit different than what we're seeing in game? To shed some light on this, here's a technical order from June of 1945: As you can see, at a certain point, blade angles were increased (the procedure involves moving those cams by 5 notches towards a higher coarse limit). There is still a discrepancy between this technical order and the curtiss prop manual, but I am assuming that is because the curtiss manual is 5 years more recent (1950). The one thing this does seem to prove, though, is that in all instances the curtiss electric prop installation on the P-47 had the same coarse pitch limits, whether governing in automatic mode, or set manually with the decrease RPM switch in fixed pitch mode. Also worth noting is that the increase limits in the technical order were done to help prevent engine overspeed in high-speed dives. Lastly, would like to reiterate the fact that, as others have mentioned multiple times on this forum, that the allowable engine overspeed limit in the P-47 pilot manuals is listed as 3060 RPM, probably owing to the fact that you WILL exceed the RPM redline in a dive at high speeds with any power applied: I believe getting the proper blade angle limits implemented would be a great first step on the road to really tightening up the P-47 module. Thanks for following along and I hope the devs really consider taking a second look at this.

Hi everyone, yesterday I was doing a MP mission with some friends and noticed that the FLAKs are not shooting at enemy air units. I got two tracks showing this behaviour either on UK flak or german one. I think this is a bug not reported earlier. thanks TRflak.trk UKflak.trk

Hello. I've tried using most weapons with the Viper, and so far they seem to work well enough. But with Cluster bombs CBU-87 and 97, i started noticing problems. #1 - Crash to desktop, if i tried selecting CCRP mode. Solved by removing some Mod Aircraft (no need to remove the excellent A-4 mod though). #2 - Creating a server and trying to play online, with the Viper carrying cluster bombs, after some minutes, during the game, even in just normal flight, without doing anything other than comms, i get huge freezes to the game, even having crash-to-desktop. (only 2 players in server; plays fine with other weapons). Also, when the bombs fragment/explode, i get a very noticable reduction in frames per second, but then goes away when their explosion ends. OTHER UNRELATED(?) BUGS: - VHF radio randomly doesn't work (my wingman can't hear me) for no apparent reason, playing online (server hosted by me). - Menu options and mission editor randomly have HUGE lag when selecting something. Really annoying !!! Sometimes causes crash-to-desktop. My System: DCS Open Beta: 2.9.2.49940 OS: Windows 10 22H2 Motherboard: MSI PRO B660M-A WIFI DDR4 CPU: Intel Core i7 127000 (LGA1700) RAM: Corsair Kit 32GB DDR4 3200MHz GPU: Asus GeForce GTX 1650 Super TUF 4GB Throttle: Thrustmaster Viper TQS Stick: CH Fighterstick USB Pedals: Thrustmaster T Flight Rudder I also use DCS-BIOS for a custom box i made

After update to 2.9 , I found that my H-6's YJ12 is in a wrong place and has a wrong model,but other missiles are all regular.The edm of YJ12 is also regular.Who can tell me how to solve this problem

In some situations, the Jester wheel A/G weapon selection information is wrong. It shows a weapon selected, but nothing is actually selected. This might only happen in hot/airstart? To reproduce: start the bombing training mission. Jester wheel shows bombs selected, but nothing will drop if you pickle. Only reselecting the ordnance fixes this. This also happens in the Reforger campaign. Possibly, punching tanks also deselects your bombs, but the Jester wheel does not reflect this. You need to reselect something manually.

PROBLEM: As subject describes. STEPS SO FAR: I've performed a cleanup and repair, per the instructions. I've uninstalled and reinstalled Normandy 2.0, and I've cleaned out the FXO and Metashaders2 directories. I've deleted all mods. I've also sent crash logs via the built-in tool each time it crashes. BACKGROUND: Each time I enter, DCS crashes to desktop when I get to the first menu to either select a seat or proceed to the mission. This doesn't happen with any other maps except Normandy 2.0, and it's happened from the beginning of Normandy 2.0. It's unflyable for me, except it occasionally allows me to run the Train Strafe instant action mission in the P47 over Normandy. This happens in both VR and nonVR. Here is the latest log file. Any ideas about the issue?...there are errors in the log, but I have no idea how to interpret them. UPDATE: I was able to do a private MP session with my flying buddy, and no CTD. We were flying P47s on Normandy 2.0, over the UK, cold start. If I were to host on my end, I get a CTD. Don't know if this helps. Thanks in advance. db dcs.log

After landing and taking the drag chute back to parking, when I shut the engines down, the drag chute falls off and the airplane begins turning to the right in place.

Hi all, after extended testing, we found out that AIM120 dont hit a thing that is near ground ( >200ft) , - while the target is not in perfect notch. The AMRAAM never hits the target ,but always near it ,on the ground. We tried that from 20-15-10-5 miles. We tried to TWS and STT (nothing changed) The shooter was always above the target 10k - 5k - 3k feet, and the target was trying to notch. (not always perfect notch) The miss was 100% - all 6 amraams hit the ground. The ground was FLAT. something is going on here - It looks like ground clutter affects significant the AIM120c. (Have not tried other missiles) Thanks.

This bridge on the North side of L'île Saint-Germain located at N48°49'27" E2°14'55" appears to be submerged in the water. On the North end, the bridge clips through the terrain. On both ends, the terrain has an odd looking trench. The smaller bridge on the south side of the island also has those trenches. Additionally, the bridge seen in game is a truss bridge, but Wikipedia has a historic photograph which does not include the steel superstructure. I may be mistaken about this - I'm not sure if this photo is the longer or shorter bridge.

This issue currently only exists on F18 and F16, and other aircraft (I tested F15, JF17, F5E, and M2000) do not have this issue. When the aircraft is initialized to "HOT in AIR", the throttle valve cannot be reduced to idle in the stick indicator. However, when the throttle inconsistent valve peripheral the stroke to 75%, the stick indicator shows that the force limit has been exceeded by about 20% and actual state of the aircraft enters the afterburner state based on the stick indicator. When the aircraft is in "HOT in ground", according to the display of the stick indicator, it can be lowered to the idle position (lower short horizontal line), but the AB position still exceeds (upper short horizontal line) At first, I thought it was a calibration issue with my device (currently WinWing F15EX), but I replaced the X56 and found the same problem. I tested other aircraft and found that the F16 also had the same problem, but F15, M2000, JF17, and F5E did not have this problem. In addition, although there is a deviation in the display of the lever indicator, the stroke display on the Controls Setting Page in the DCS settings menu is normal. So, I can currently confirm that there is a bug in F18 and F16, and I hope it can be resolved as soon as possible. In the AIR Start, When the external device is in idle and AB position: In the Ground Start, When the external device is in idle and AB position:

This issue currently only exists on F18 and F16, and other aircraft (I tested F15, JF17, F5E, and M2000) do not have this issue. When the aircraft is initialized to "HOT in AIR", the throttle valve cannot be reduced to idle in the stick indicator. However, when the throttle inconsistent valve peripheral the stroke to 75%, the stick indicator shows that the force limit has been exceeded by about 20% and actual state of the aircraft enters the afterburner state based on the stick indicator. When the aircraft is in "HOT in ground", according to the display of the stick indicator, it can be lowered to the idle position (lower short horizontal line), but the AB position still exceeds (upper short horizontal line) At first, I thought it was a calibration issue with my device (currently WinWing F15EX), but I replaced the X56 and found the same problem. I tested other aircraft and found that the F16 also had the same problem, but F15, M2000, JF17, and F5E did not have this problem. In addition, although there is a deviation in the display of the lever indicator, the stroke display on the Controls Setting Page in the DCS settings menu is normal. So, I can currently confirm that there is a bug in F18 and F16, and I hope it can be resolved as soon as possible. In the AIR Start, When the external device is in idle and AB position: In the Ground Start, When the external device is in idle and AB position:

Tried to enter offset to a particular waypoint, all the info gets entered normally (distance and elevation) except bearing. I replicated this issue many times on missions and instant action free flight. I wasn't able to enter bearing to an OAP any time I tested it. It stays at 00 degrees. Switching from True to Magnetic only adds the magnetic deviation difference in degrees, but still doesn't change the bearing that is inputted through the UFC. Offset Bearing Bug.trk

The Situation: I release the SLAM-ER in TOO with a Steerpoint designated as Target. Flight High, Fuze set, Time to Sensor is set to 10nm. Now i fire just one and it goes its way. 10nm - 20nm before target (60nm - 70nm down their way) in most attempts one SLAM turns Circles until its out of fuel. The second i fire with the same settings hits the target as intended. With Flight Medium both fail and circle until no fuel. Could someone may find a mistake i made or is this a bug. I´ll attach the mission and some Track files. Thanks in advance SLAMWeird0of2Take4.trk SLAMWeird1of2Take3.trk SLAMWeird1v2.trk SLAMWeird1v2Take2.trk SLAMWeirdTestMission.miz

Hello, it seems that there is a bug when setting up user waypoints via the map cursor while the map is in track-up -mode. In said mode the waypoint seems to get the correct coordinates as was shown in the cursor info-box, but then when I set the navigation to said point, the waypoint is far away from where I originally put it, even though when I check the coordinates from the user waypoint list all seems to be correct there. If you use the north-up -mode everything works just as intended. So it seems, that even though the NS itself show the proper coordinates, the actual position is copied from the screen as if it was north-up. Very confusing indeed! I found this flying in Caucasus. Haven't tested on other maps. Testing is simple: set the map to track-up, fly somewhere other than north and try to set up a user waypoint via the map (notice the coordinates!), set the direct-to function to the waypoint you just created and observe the result. Regards, MikeMikeJuliet

As in the title, flipping between F10 and F1 seems to have a % chance of starting long-lasting stutters and screen-tearing in VR. Usually happens after the 5th or 6th time looking at the map while on a mission. This is actually so bad that it immediately stops my gameplay, I cannot continue with it. See attached video. This bug never appeared before multithreading was introduced. https://cdn.discordapp.com/attachments/865742930064965662/1100018920297070692/20230424_200758.mp4 Oculus Quest 2 3070ti M.2 SSD for DCS 32GB memory X570 Gaming+ Ryzen 7 5800X3D

Doing the Su-25 T Mercury pod training mission, the screen looks bugged after turning the pod on. Screenshots of the view with just the Shkval, and with Mercury on. The Mercury has the top right flooded with something very bright, while the rest is dark. This stays constant as you maneuver the aircraft, or slew the pod. This is both in VR and normal.