Wesjet

Encountered an issue after engaging a pair of MiGs in multiplayer where my radar was not working correctly. My elevation scan acted as if it was the azimuth, while the azimuth sweep acted like the bar scan. This was to the point that altering the degree of azimuth sweep would actually adjust the distance the elevation caret would travel, and adjusting the bar scan setting changed how far the vertical line representing the antenna position would sweep across. The track is very large, as it was a long flight and can be downloaded here: https://1drv.ms/u/s!Au6nuN4_FUp2grUuRcZmVBfkTj6eUw?e=5FR5vB Since I figure it may be difficult to work with such a large track, I recorded a section of it occurring while I changed the bar and azimuth settings - which has been uploaded to youtube (to appear below). I am not sure as to the condition to reproduce, as I did not notice it immediately. DCS 2.5.6.50979 Open Beta

Simple as the title, although through my testing this does not occur with all bridges - some smaller bridges don't cause the crash. Have a column of vehicles crossing the bridge and then hit it with something and knock it out. Game crashes almost immediately. Have done this in MP (track too long to upload) and reproduced in SP. Crash file uploaded via in-game upload tool but also included here for reference. Also to note, despite the column of vehicles being spawned on the road - if you look at the vehicles before they get underway you can see that they are not sitting in the lane properly and do not inherit the heading of the road that they are sitting on. dcs.log-20200426-210406.zip BlowTheBridge.miz

I can confirm that the autorudder system seems to still be taking effect with the settings disabled. While online on my server, it is interfering with the rudder during taxi. Auto-rudder and Takeoff Assistance are set to off. Trying the other WWII planes I own (Spitfire, 190A8, 190D9 & 109) the Mustang is the only one exhibiting this problem. I have also had a friend sign on and confirm he sees the same issue with his Mustang. Track included. You can see I make a right hand taxi turn - then my input is dampened suddenly. Allowing the aircraft to roll across the field, I am feet-off the rudder pedals. Throttle inputs result in rudder compensation. While braking the behavior continues. I am trying to not generate input myself, but you can see the inputs are quite large despite myself not adding much input. Edit #2: After further testing, this issue is not appearing in a SP test run using the same mission as running on the MP server. Edit #3: After additional testing with other servers, we have found the root cause of the issue. The mission designer had rudder assistance set to 100% and this setting carried through to the OPTIONS file inside the mission file. Editing the OPTIONS file to set [assistance] = 0 resolved the problem. Is it intended behavior for this setting to be saved to the mission and then apply within a MP session? I believe this should always be a user's choice. Thanks! Thorn Falaise ob255v0-20200422-215112.trk

Pikey, thanks for the info! I have asked my friend who designs the missions to check out the MOOSE version and see if we can try to log the group spawns. We try to cap missions with a 12 or 24 hour timeout, and then they automatically restart themselves via script. The server itself remains running and the total runtime of DCS.exe was measurable in months in some cases without incident. We have been fine with that method for all of the 2.5.5 branch. The mission we were running was a WWII mission with back and forth AI ground and aircraft spawns that fly towards the AO and engage but it was not running nearly long enough for there to have been that many - not even 12 hours.

We are seeing some of the same error messages: The above appears in pretty well every mission we run to a varying degree, and I am unable to tell if it is harmless in terms of the server operation, as it is apparent near the end of the log if the server crashed but other times the server keeps on running with many of these within a short time span but not consecutively. One of our WWII missions is having some performance issues that may be tied to the issues with the ground units and pathing, however it is seeing the following error messages pretty well spammed into the log growing to over 90,000 lines in relatively short time period. Our other missions don't seem to show this error message type: I cannot include the track file for the flight, as it is over 100MB for roughly 2 hours and 20 minutes of action. The partial server log is attached - up until I disconnected. dcs - Copy.zip

Figured I should add to this - I have a dedicated server that is having issues with ground unit paths going haywire, and it appears that my server has the horsepower to keep DCS responsive under most conditions but it can also fall into unresponsive until terminated. Included will be the multiplayer mission track, server and client log. The mission has only been updated to keep up with warehouse inventory adjustments from the recent patches, but otherwise would run 24/7/365 unless we decided to fly something else during the 2.5.5 OpenBeta branch. The columns of vehicles are spawned apart in time, but path issues leads them to jam up and get stuck. Attempting a fix by changing group formation from and back to column leads to vehicles flying/underground/driving diagonally - and hangs the server. Log_TrackPack.zip

I am not sure if this is related but it does seem to be. When I listed to music in iTunes in the background, certain combat actions such as guns firing cause my music to become explosively loud (painful with headphones on), and then it will return to normal. The exact triggers I am unsure of, but the mission I am most able to notice it is a WWII scenario and sometimes the orientation of the aircraft I am watching via F2 relative to the camera can make a difference so perhaps engine noises is one of them. This anomaly does not occur in any other game or application on my system - solely when playing DCS world.

Bignewy. As requested on Discord - here is the old log from my server that was encountering the same issues as shown in post #5 of this thread. I do not have any tracks that are short for this as sometimes the issue does not appear until 15 minutes to over an hour in to the mission. Over the course of this log I had loaded multiple missions, testing to see how they would run so it is quite long. dcs.log.old.zip

Ha - found those after I posted (originally just checked against anything posted since 2.5.6 dropped). Never had it before myself though. Steam file integrity check returned no issues. Next run today and textures are loading fine.

Some of the internal cockpit textures are missing in this patch including the rearview mirror bezel, left side arm rest, head rest cushion, and some structural components behind the pilot's seat. Seems to apply to all skins, screenshots attached. Edit: Log Attached dcs.log.txt

I think this might be the case, my cursor is not constrained to the DCS window as I would expect with a "dedicated" full-screen application, I can freely move to my second monitor and work in another program where as before I required using ALT+TAB first.

Hi, I am finding that my Steam installation of DCS which updated today to DCS 2.5.6.43559 is rejecting my login with the invalid username/password error. I know that my username and password are correct as I am able to use them to sign in to DCS standalone 2.5.6.43503 as well as digitalcombatsimulator.com without any issues. To be safe I also ran a Steam game file integrity check, with no results. Another user on the ED discord mentioned a friend having this issue as well and I have requested he add in to this report. Not sure if this is related to the other log-in report (https://forums.eagle.ru/showthread.php?t=263526) so I made a new thread.

Just to follow up on this. I was able to walk a friend through the issue I described and he got the same results in terms of the P-51D folder for MP and the P-51D-30-NA folder for SP. On another note, I saw you showed a screenshot for the Spitfire with a separate folder for the clipped wing variant. My system doesn’t have that, it’s using the same folder for both. The same friend I mentioned above’s system has both separate folders however.

BigNewy, follow up from Discord: I noticed that for me, DCS doesn’t differentiate controls between the -30 and -25 model, however it does use the “P-51D” folder for multiplayer and the “P-51D-30-NA” folder for singleplayer. I was wondering why after setting some new bindings online, they didn’t work in SP. I copied my files from the P-51D folder to the -30-NA folder and restarted DCS, and then my bindings came through in singleplayer for both the -25 and -30. The only thing not confirmed so far is if they also work for the -30 in multiplayer based on what I set in MP while in a -25. I have not checked the Spitfire controls for a similar issues between elliptical and clipped wing variants for the same type of issue.

Had a bit of a DCS break but I am able to get this again after some testing. Track to large to upload, see OneDrive link: https://1drv.ms/u/s!Au6nuN4_FUp2gqp7vP3PqKrWEHeHaQ It seems the ground attack portion may be incidental - cycling various radar modes including No Radar (IR seeker only + cage/uncage), LTWS, STT, ACM Boresight, HMD can cause the seeker to stop locking to varying degrees. This issue is very intermittent. In my track, fast forward until I climb into formation behind the F-15C @ ~24,000ft (after Mk82 release). At some points the seeker will growl but not fully lock one one or both missiles, and there is also a case where the seeker will chirp but not even achieve the growl stage. Towards the end I engage the HMD mode which seems to "restore" the seeker's ability to lock on. Track then finishes after I break off to the right.

This one appears to be back, I will work on a track for it as this occurred during a long MP flight with a large track file. I do have a video clip however. Same conditions: -Multiplayer -AIM9M -Prior A/G weapons use Issue: Right wingtip AIM-9M will not lock on to target, left wingtip AIM-9M is good. https://www.twitch.tv/videos/528741413

Grimes, 1) The UCID’s have only changed a few times per user. A couple times has been around when someone has gotten new hardware, but not always. I suspect major updates like 2.4 -> 2.5 might do it or internal updates to ED servers, but I am speculating as well. 2) I don’t think there are any issues, the running Windows profile is an administrator and other than what is related to that LUA file, repairs and updates work fine. I’ll look over it again though. Can you share the batch script by chance? Thanks!

A couple of questions: 1) Is common for player ID numbers to change? Every now and then one of our admins finds they cannot access the admin menu and has to be re-registered. Checking the admin list file, they will subsequently have two entries with different ID codes. 2) In regards to updating when a new patch comes out I am having to first run a repair which replaces missionscripting.lua with the default version before updating otherwise the DCS updater will not update and skip to launching the server. Is this normal behavior? Thanks!

Follow up on my previous post, with the net.use_ipv6 = false code in the autoexec the server as expected does not respond to it's IPv6 address but also it not listed in the server browser from the LAN. I had a friend verify that it is still listed from the WAN side. Is there any solution for that? Not a critical issue, I can still connect manually. Just a matter of convenience. Thanks!

We’re running it on Hollo Pointe North presently and have had successful tests between myself (LAN) and a friend (WAN). Quality is quite good, hopefully they (optionally) “ruin” it with radio effect like SRS allows in the future. :thumbup:

Rik, Useful information for future reference, thank you. We are using standard 10308 and 10309 - I saw the note about alternate ports but didn’t want to put clients through having to make a configuration change. Can you make sure that when IPv6 support is ready, it’s in the changelog? I’ll remove the autoexec line at that time and give it a test! c0ff, Thank you for this option - I have restarted my server with it, and the log now states listening on IPv4 with no mentions of dual-stack or IPv6. I’ll have to test later but I am fairly confident based on the logs that it will work.

Thanks Rik, I updated to the newest Open Beta earlier this morning on the server. Haven’t had a chance to test client yet, but the server logs don’t look any different, the entry about dual stack and listen on ipv6 are still there.

USSR_Rik, It doesn't seem that the autoexec change of adding net.force_ipv4_lan = true worked, at least as hoped. I have disable_write_track = true as well, which is working - so I know the file is being read. In the Server browser I still see the link-local IPv6 address from the LAN, and it appears to connect with that unless I manually connect via IP like mentioned above. VOIP works with a manual connect via LAN IPv4 and does not with Link-Local IPv6, same as before. Excerpts from my DCS Log file, emphasis added, personal information redacted. Note, ports 10308 and 10309 are forwarded at the router. 2019-12-04 04:18:46.034 INFO NET: UPNP IGD detected. 2019-12-04 04:18:46.034 INFO NET: Internal LAN IP address: 192.168.1.127 2019-12-04 04:18:46.034 INFO NET: External WAN IP address: <public IPv4 address> 2019-12-04 04:18:46.076 INFO NET: TCP external <public IPv4 address>:8088 is redirected to internal 192.168.1.127:8088 2019-12-04 04:18:46.077 ERROR NET: AddPortMapping(10309, 10309, 192.168.1.127, TCP) failed with code 718 (ConflictInMappingEntry) 2019-12-04 04:18:46.082 ERROR NET: GetSpecificPortMappingEntry(10309, TCP) failed with code 714 (NoSuchEntryInArray) 2019-12-04 04:18:46.104 ERROR NET: AddPortMapping(10309, 10309, 192.168.1.127, TCP) failed with code 718 (ConflictInMappingEntry) 2019-12-04 04:18:46.109 ERROR NET: GetSpecificPortMappingEntry(10309, TCP) failed with code 714 (NoSuchEntryInArray) 2019-12-04 04:18:46.109 ERROR NET: UPNP failed to map WebRTC port 10309 2019-12-04 04:18:46.109 INFO NET: Registering HTTP control interface as <public IPv4 address>:8088 (port is forwarded by UPNP) 2019-12-04 04:18:46.680 INFO Dispatcher: //=== END OF INIT ======================================// 2019-12-04 04:18:46.681 INFO NET: server has started 2019-12-04 04:18:46.682 INFO NET: Using LEDBAT for UDP congestion control. 2019-12-04 04:18:46.683 ERROR NET: AddPortMapping(10308, 10308, 192.168.1.127, TCP) failed with code 718 (ConflictInMappingEntry) 2019-12-04 04:18:46.687 ERROR NET: GetSpecificPortMappingEntry(10308, TCP) failed with code 714 (NoSuchEntryInArray) 2019-12-04 04:18:46.709 ERROR NET: AddPortMapping(10308, 10308, 192.168.1.127, TCP) failed with code 718 (ConflictInMappingEntry) 2019-12-04 04:18:46.713 ERROR NET: GetSpecificPortMappingEntry(10308, TCP) failed with code 714 (NoSuchEntryInArray) 2019-12-04 04:18:46.713 ERROR NET: UPNP failed to map server port 10308 2019-12-04 04:18:46.714 ERROR NET: AddPortMapping(10309, 10309, 192.168.1.127, TCP) failed with code 718 (ConflictInMappingEntry) 2019-12-04 04:18:46.718 ERROR NET: GetSpecificPortMappingEntry(10309, TCP) failed with code 714 (NoSuchEntryInArray) 2019-12-04 04:18:46.739 ERROR NET: AddPortMapping(10309, 10309, 192.168.1.127, TCP) failed with code 718 (ConflictInMappingEntry) 2019-12-04 04:18:46.743 ERROR NET: GetSpecificPortMappingEntry(10309, TCP) failed with code 714 (NoSuchEntryInArray) 2019-12-04 04:18:46.743 ERROR NET: UPNP failed to map WebRTC port 10309 2019-12-04 04:18:46.743 INFO NET: Successfully set up Dual-Stack socket, using both IPv4 and IPv6 2019-12-04 04:18:46.744 INFO NET: Listen to IPv6 on port 10308 2019-12-04 04:18:46.744 INFO Dispatcher: loadMission C:\Users\<user>\Saved Games\DCS.openbeta_server\Missions\<mission file>" 2019-12-04 04:18:46.744 INFO WORLDGENERAL: loading mission from: "C:\Users\<user>\Saved Games\DCS.openbeta_server\Missions\<mission file>" 2019-12-04 04:18:47.306 INFO NET: Loading mission: "C:\Users\<user>\Saved Games\DCS.openbeta_server\Missions\<mission file>" 2019-12-04 04:18:47.307 INFO NET: Registering server as <public IPv4 address>:10308 (port is assumed to be open)

BigNewy & USSR_Rik, Thank you for the prompt response! I have added the line to my autoexec.cfg (I also have the line to disable tracks to save disk space from long MP sessions) and the server restarted successfully showing it bound to the IPv4 address for LAN. I will follow up after work when I can hopefully do a other round of testing. Cheers!

To follow up with my initial report, as it is related but not exactly the same issue. After the successful test above, I turned off the port forward for 10309 again to test with UPNP since we were able to verify that the VOIP would work. Relying on UPNP, we were unable to make a successful VOIP connection and encountered some client crashes. My friend connecting over the internet had one client crash on slot selection. Connecting myself encountered crashes with IPv4 or IPv6 LAN IPs (crash reports submitted). Re-enabling the port forward solved the issue for my friend, and using the IPv4 LAN IP myself brought back the successful VOIP connection. LAN IPv6, still failed as described above.