Search the Community

I will add a link to a video once it uploads. In this case 5 Ju-88's were hit during a mission and the crews bailed out. After that the abandoned planes do not loose either speed or altitude and continued to circle indefinitely. Tacview file also attached. Tacview-20250628-110307-DCS.zip.acmi

I was flying the Huey multicrew the other day when we noticed a few things that seemed to be bugs. I have attached a track file with them, I think most of what we noticed happened towards the end of the flight. 1. I was in the pilot's seat and the DG and Compass lined up. To my co-pilot, the compass and DG were about 100degrees different. When he changed to DG to line up with the compass, I saw them to be about 100degrees out. 2. We then went and did some sling loading. He was flying as copilot and I was monitoring. While moving barrels, to me I could see the hook doing orbits around the helo, and I could not see the rope. To him, everything looked fine. 3. We also did some mountain flying. We were up around 18,000' with no loss of consciousness, I don't know if this was an MP server setting or not. 4. At the end of the flight, after sling loading, the helicopter seemed to shut down for me in the pilot seat. I was pilot monitoring. For my co-pilot the helo seemed to be working without issue. For me it was completely stopped, rotor stopped, and I was flying around in god mode. This is my first bug report and post so please let me know if I have gone wrong anywhere, or left any info out. My track file is also 87Meg. Any idea how to get it below 50 so I can attach it?

I think this may be a known issue, as I see some users are also reporting similar problems. I have also submitted this topic at the discord channel (no answer for now). I'm using current DCS World Steam version, using a HTC Vive Pro 2 + Valve Index controllers. I have tried to check this issue in multiple modules (Su-25T, Black Shark 3, C101) without any results. I've reinstalled DCS and SteamVR to check out if there was any corruption issue, without solution. I tried some solutions provided by ChatGPT (remove fxo and metashaders2 folders, verifying files via Steam properties, etc) and nothing. ChatGPT log scanner detected that there was no controllers detection. I upload all the files recommended at the forum to try to solve the issue (I've upgraded my computer just to improve VR in DCS and this is dissapointing..) I hope you could solve it. dcs(1).log DxDiag.txt

The AN/AAQ-28 targeting pod mounted on the belly of the F-18 can be jettisoned in multiplayer games using an emergency release method, and the pod remains functional even after being jettisoned. I'm not sure if it's possible in single-player mode, but I've found that multiple people can reproduce it on multiplayer servers.

Hello BD, I'm currently on Mission 15, and I've encountered a few issues. When entering the AO and engaging in combat, there are instances where 3, possibly 4, transmissions overlap each other. Also, the mission instructs to call in the helicopter crew once the AO is deemed clear. I do this when I believe all enemies are eliminated. However, subsequent communications with Overlord then instruct to call for rescue, which I have already done by that point. There's a minor yet confusing aspect as well. During the coordination for the first two targets, AA and Manpad, it's mentioned that we should engage these targets and then contact Springfield. But the game requires contacting Springfield first. Additionally, after clearing the AO and reconfirming by directing my wingman to attack ground targets (to which I receive a negative response), and performing several low passes, the helicopter still gets shot down by a ground vehicle. I suspect this vehicle may have spawned in between these actions, or it somehow doesn't engage with me. In response, the helicopter starts taking fire, and I attempt a risky maneuver to locate the shooter, hoping it will target me instead. I suspect the attacker might be a BTR, which gives him the ungodly sniper powers that DCS creators have bestowed these types of vehicles It seems there are some irregularities with triggers and timing in this mission. I've attached the trackfile for reference Mission 15 CF.trk

I want to purchase the AV-8B but I can't find it anywhere in the DCS store although it shows up in the DCS main intro screen among the many other available icons, a/c modules, terrain etc. Clicking 'BUY' just takes me to the DCS store but with no listing or option anywhere to purchase. ?

When asking the Ground Crew to remove or to install ETC 501 bomb rack no weight is added in the rearm and refuel menu. In flight it seems to work fine and removing ETC 501 results in an increased airspeed of ~15kph.

The bombs mounted on the trollies scattered around airfields appear to be CBU-52s, which wouldn't have been around during WW2.

CH-47 mirror glows bright white when using high cockpit low cargo textures in NVG, this is in vr i don't know if its a thing for 2D i cant fly 2D so never do Is fine if you use high + high but i thought id try low for cargo as i don't really need that to be amazing as i hardly ever see in there my fix was just going back to high + high .buts its not really a fix but it works again for night flying

Hello, When using the GBU-24, in SL or PP, we have a min&max range. But, while the manual say : "Normally, the bomb can only be released when the aircraft is inside the LAR." (page 324) We cannot release the bomb before the release cue crosses the velocity vector. In image, that means that while we might think we could release the bomb any time in the red part, we can only release it in the yellow. Weapon release doesn't do anything in the blue part. We also tried a forced laze, and a loft. CLAR ORV ignored because, the manual doesn't say we need to use it to drop while in the CLAR. No track right now. Can do one if necessary.

The C on Boulder City when it appears on the communication menu or any radio text has a error where the C shows as a ? in a white background. I had noticed this before and ignored it, however since recently starting to use OpenKneeboard it is causing problems, as when that app reads the data from the game to show the radio log, it obviously gets passed that data, and as soon as I get a message from Boulder City the 3rd party apps crash, and their crash logs show they got unreadable data from the game. Took me a while to realise it only happens when I was taking off from Boulder. Just to clarify checks I did, I re-installed map and repaired game, but still the same, then got a friend to check and turns out his is the same so have given up trying to fix it now as its clearly a map bug.

Hi ED, very nice to see the Marias WWII map finally! Waited so long for it. However, I believe the Pagan Airstrip is a bit too short. See screenshots. If I assume historic map and ingame map are at the same scale (should be at least, although there is a slight offset it seems), the runway is at least 2300 ft rather than 1800 ft. If I use the roads as orientation, the airstip is even longer and slightly more shifted landward (I replicated the purple line). Is it possible the current airstip length has been salvaged from the original current-day Marianas map? There the airstrip has been truncated due to the volcanic eruption and lava flow in 1981 to be just above 1700 ft, which would match to the current ingame version. Also the ground texture and mesh look like that there are still remains from the eruption which has yet to take place. I believe the runway in 1944 must be longer, I have troubles in landing there in one piece.

It was only renamed to Hagatna (it's proper native name) in 1998. Alternatively, the towns could be assigned their japaneese names used during the occupation.

With SLAM-ER flight profile selected as LOW, the missile will cruise at about 5000ft if launched above 5000ft. If launched below 5000ft, the missile will fly at approximately 100ft. Tested with F/A-18C

after the marked offer to get a drink, this error occured. i could just click it away, but bug is a bug also the wingman gets stuck on the deck again. this time he was at least not blocking the deck and he just could not park.....

He is a very loyal CPG for sure but perhaps he should take a break with the rest of the crew? The back seat is empty, yet he stays, eternally waiting for his pilot to come back. My configuration: -IC Pass -No Mods -MT latest OB IC and game state verification screenshot. Early morning at the FOB in Afghanistan. This is an AI Mi-24 set to "take off from ground" but has the "uncontrolled" box checked because I am using it as a static. The pilot is probably asleep yet Petrovich insists on never leaving the helicopter. Steps to replicate: -Place AI Mi-24 unit -Set to "take off from ground" or "take off from ramp" -Check the "uncontrolled" box OR: -Place a static Mi-24 When viewed in the mission the pilot is gone but the Petrovich stays. An example of a configuration that produces this issue. This is an issue for people trying to use uncontrolled AI as statics. Using a static does not allow for tail number customization or loadout editing. Even if I were to use a static it would have the same problem. As a result it is currently not possible to have an empty Mi-24P in this game. Somewhat immersion breaking when you want to have other Mi-24s on the ramp when you start up.

The static L118 105mm light artillery gun has been added to the list of possible cargo (can be cargo) but when you want to sling it with the Mi-8 (both in hovering and on the ground) the gun seems to go into the ground and the Mi-8 is damaged or destroyed.

The F-16 Training/JDAM mission seems to be broken now. While doing the steps to configure weapon via the SMS page, trainer instructs pilot to press OSB 18 to switch fusing from AIR to Ground burst... pressing button does nothing. Though the weapon does actual ground burst when released. Further in the mission after attacking the target at steer point 3, once the JTAC call comes in and you begin to proceed to mission at SP 4, the training stays hung in active pause (JDAM assessment) while the voice over reads back the parameters for the SP 3 mission.

TL;DR: The DCS client/server terminates with a "Login session has expired" error popup only when reconnecting to the DCS master server after the connection had been lost for 30+ minutes. No error occurs, if the connection stays lost. This makes no sense and harms user-experience unnecessarily. The termination also occurs with the same error popup for a variety of other reasons. Technical Details The DCS client* must authenticate with the DCS master server (api.digitalcombatsimulator.com) when starting. As part of a successful authentication, the client will receive a temporary session ID from the master server. The client uses that session ID to periodically check with the master server every ~10 minutes. Clients and master server communicate via encrypted HTTP. The periodic session check is an HTTP POST request to which the master server normally responds with status code 200 (OK). *) Here and subsequently, "client" refers to a client of the master server. This includes the DCS dedicated server, which also performs authentication and periodic session checks with the master server. The master server session cache expires within ~30 minutes: If the master server has not received session checks from a client for ~30 minutes, it will forget the respective session ID. Afterwards, the master server will respond with HTTP status code 401 (Unauthorized) to any session check from a client with an expired session ID. This will be logged in dcs.log as: 0000-00-00 00:00:00.000 ERROR ASYNCNET (0): HTTP request dcs:checksession failed with error 28: Timeout was reached 0000-00-00 00:00:00.000 WARNING ASYNCNET (0): Session check failed: -28 0000-00-00 00:00:00.000 ERROR ASYNCNET (0): The session has expired (401). Exiting... The affected DCS client will not try to reauthenticate, but instead terminate with a "Login session has expired" error popup: This issue is likely not restricted to re-establishing connection with the master server and HTTP error 401. Other master server-side errors trigger the client-side termination, too. If the master server (or the reverse proxy it resides behind) temporarily responds with other error codes, e.g., 502 Bad Gateway, the client terminates itself, too. While I've not experienced this particular error code myself, it's been reported here. Apparently, this issue also occurs entirely out of the blue without any prior connection issues (i.e., no session check errors/warnings, cf. above) in dcs.log [1]. According to BIGNEWY, reasons may include simultaneous logins with the same account, local internet issues, or changing IP addresses [1, 2, 3, 4, 5]. However, I've not been able to reproduce this by repeatedly changing public IP address during a DCS session and local internet issues causing failure to connect to the master server would result in session check failed messages in dcs.log. So with the noteworthy exception of simultaneous use of a single account, I see no reason why this issue should occur. This might even be a bug in the master server. Who is Affected / Why to Fix This All players and servers: If the master server goes down and forgets all session IDs, all clients and servers will be forcibly terminated, too. This has happened on multiple occasions. Either scheduled or repeatedly unscheduled [1, 2, 3, 4]. This issue frustrates customers. With the master server being a single point of failure, this presents a possible attack surface. I'll refrain from elaborating on this further to not give random script kiddies any bad ideas. Players with a spotty internet connection (to the master server): Spotty internet connections are hard to debug and even harder to fix. Even if everything else works (e.g., playing DCS in multiplayer, streaming, downloads, etc.), an ISP's route to the single DCS master server may be sufficiently congested to affect the periodic session checks temporarily. Whereas DCS updates/downloads are handled via a globally distributed CDN, there's a only one master server that is located in Europe (ping/traceroute api.digitalcombatsimulator.com and cdn.digitalcombatsimulator.com for comparison). Players complaining about this in the forum are typically referred to customer service. A proper fix may pay for itself by less customer service tickets. I'd also expect far more players to be affected than there are reports on the forum [1, 2, 3, 4]. Casual single players or mission editors who want to suspend their computer mid-mission to resume another day: Suspending your computer for more than 30 minutes will also result in forced termination. With the DCS save feature not yet capable of resuming complex missions, this is a valid use case for casual DCS players. Workaround (@Affected Players) As the DCS client only terminates after reconnecting to the master server, the termination can be inhibited by preventing the reconnect. Do this at your own risk: Start DCS. Once in the main menu, the mission editor, or on a multiplayer server, inhibit further communication with the master server (api.digitalcombatsimulator.com), e.g., via firewall rules or by adding an invalid IP route with an administrator PowerShell: $api_addr = (Resolve-DnsName api.digitalcombatsimulator.com).Address route add $api_addr/32 0.0.0.0 Go about your day, suspend/resume your computer, or connect to multiplayer servers via IP address. The multiplayer server browser will no longer work. After closing DCS, remove the firewall rule or the invalid IP route: route delete $api_addr/32 0.0.0.0 How to Fix This (@ED) This issue could (and should) be addressed both at the client and the master server: The master server session ID cache should not expire prematurely. Using the 72 hours saved authentication grace period for expiring sessions seems reasonable. This fix should be relatively straightforward to implement as a stopgap measure. Improve client error messages. The session expiration presumably occurs for a variety of reasons, but the client always shows the same generic error popup message. To simplify debugging, the client popup message and dcs.log should include a human-readable explanation of the specific reason for the session expiration. This would require support from the master server, which must include this reason in its response (e.g., as the response body with a text/plain Content-Type; currently the 401 responses are text/html with an empty body). The client (and dedicated server) should always attempt to reauthenticate with the master server instead of just quitting immediately after a failed session check. Silently start the 72 hour saved authentication grace period once the connection to the master server is lost (or the master server experiences server-side errors, i.e., 500+) and only terminate the client if the master server hasn't been reached within that duration. Reset the grace period once the connection to the master server has been re-established. That should balance between user-experience (which ultimately pays ED salaries) and software piracy concerns. How to Reproduce Start DCS (in Online Mode), open the Mission Editor. Wait a minute. Disconnect DCS from the master server api.digitalcombatsimulator.com (185.195.197.20). Either by disconnecting from the Internet, by using a firewall rule for the aforementioned IP, or by setting a non-existing network route via a PowerShell with administrator privileges (alternatively, you can also just suspend your computer): $api_addr = (Resolve-DnsName api.digitalcombatsimulator.com).Address route add $api_addr/32 0.0.0.0 Keep DCS disconnect from the master server for 30+ minutes (less may suffice, too, but AFAICT it needs to miss more than just one session check). Re-enable the connection to the master server. If you used the route method, delete the invalid route: route delete $api_addr/32 0.0.0.0 Wait for DCS to quit within the next minute or so. Edit: Updated post, added workaround. Original post in below spoiler.

OK this subject is fun. FIRST OFF AS IMPLEMENTED our XM60 sight has the 50mil DIAMETER reticle HOWEVER A 50mil RADIUS reticle ALSO exists As does an 80mil DIAMETER reticle. all for the same sight. 3 Different reticles 1 sight Wild, right? Regardless. AS IMPLEMENTED Our sight is the 50 mil DIAMETER sight. As implemented, it IS correctly scaled. A 50m wide object at 1000m will fill the diameter of the 50mil diameter sight. Here is the proof, the C-17 has a wingspan of 53m There is nothing wrong with the reticle itself. The problem lies within the elevation knob. This thing. This knob is measured in mils. So if you increase or decrease it by 50 mils, the 50mil diameter sight should move so that the top is now where the bottom was, or vice versa The reticle should move by 50 mils if you change the knob by 50 mils, simple. HOWEVER. As you can see, to shift our 50mil diameter reticle by 50mils, we have to change the elevation by 95 mils. This is obviously incorrect. This isn't a matter of just changing the scale of the reticle either, as that doesn't fix the issue. The issue is that 5mils of elevation on the knob, does not equate to 5mils of rotation in the reflector sight. Changing the scale of the reticle won't fix that. This matters because the elevation table on the sight itself, this thing Asks you to adjust the elevation by mils. This means adjusting the elevation by 20 mils does not actually adjust the elevation by 20 mils, meaning your sight zeroing is incorrect for your chosen parameters. This needs a fix, either changing the scale depicted on the knob itself, or by changing the amount of elevation displacement so that it matches up to the number of mils on the elevation knob. I do not know which would be the correct option that would make it more like the real thing, however either option fixes the issue.

Good afternoon to all First of all thanks for all the help, if tried to search many topics but had no succes to find anything similar, thats why I bring the issue op. Im setting up a mission with infantry on top of defences, and when they get shot they disperse. This infantry is set to inmortal due to the fact I want them to survive waves of enemies until air support comes. I have atached 3 images with how everything is set up. The ai is inside the tower and the are set as Inmortal, Red state (so they are prone), and dispersal off but it dont work at all. The only way to to stop ai from moving is to disable AI via a trigger but then they dont fire and they are not inmortal. It happens in a lot of missions I have created its like AI inf ignore the Dispersal under fire off advance waypoint action. null Problemasenlafrontera.miz

Hey there everybody! After now hours of trying in the ME, I couldn`t figure out the failure. AI Huey takes off the Tarawa (LHA-1, Vanilla), does his route as ordered, and as soon as it enters the landing route, climbs up to max ceiling height over the ship and stays there! Anyone else had this bug....feature...whatever?

Hello, I was unsure if this was a feature but the ABRIS sometimes comes into the state where it is not usable anymore. This happens on different occasions, either pve missions or pvp servers with different amounts of ground units on the map. After asking some people on the official ED Discord, it seems to be something that is not a issue for everyone. Here is a video: I hope for a easy fix Thank you

As you can see, the shadows are flickering and the belt is inside the ejection seat. 3D issue. It only happens on the F-5E. Thank You!

Description: When engaging or observing medium-caliber anti-aircraft fire (estimated 20mm–80mm), the self-destruction of rounds in mid-air produces audio cues and shockwave effects, but no accompanying visual explosion or flak puff. This results in a jarring inconsistency during engagements, as you can hear and feel the detonation, but nothing visually manifests in the expected location. Steps to Reproduce: Spawn a mission with AAA units (e.g. ZU-23, Shilka, etc.) firing at aircraft. Observe the flak rounds as they reach their time-of-flight limits and detonate. Note that audio and sometimes screen shake are present, but no smoke/flak visual effect appears at the detonation point. Expected Behavior: A visible flak explosion (typically a small puff or fireball) should appear at the location of round self-destruction, consistent with the accompanying sound and shockwave cues. Kind regards, T-Bone