SixMarbles

New info / ISSUE RESOLVED: During the slow load, the game loaded files at about 3 MB/sec average. I have moved the install from my RAID 0 array to a single SSD. Considering the prodigious number of files moved (34,610) and the amount of data (29 GB), the transfer went very fast. I averaged about 75 MB/sec with peaks over 240 and never falling below 35 MB/sec. This is not fast for a sequential read but it proves that the array is not faulty and its read performance is fine. Not a hardware problem. Now the missions load in around 20-30 seconds. This is how it used to be! This has told me that my install was highly fragmented. I am probably to blame as I kept using dcs_updater.exe to move the install from @openbeta to @release several times in the wake of the Viggen release. In between doing all of this, I downloaded a number of Steam games whose data likely filled the swiss cheese-like holes in my SSD array. It seems SSD TRIM operations/optimization were not being done by Windows 10. Whatever. issue resolved.

Same issue here. After the first load, I can connect and play with a ~20 second load. Using 2x Samsung 850 Pro in a RAID 0 array. Here is a notable bit of my log file: 00117.177 INFO EDTERRAINGRAPHICS3: force loading finished! 00117.177 INFO EDTERRAINGRAPHICS3: Force loading pipeline 'map'. Radius 6000.000000. Pos=-248650.875000,117.107254,625911.500000! 00117.208 INFO EDTERRAINGRAPHICS3: force loading finished! 00221.926 INFO NET: disconnected: 5 Server ping timeout 00226.768 INFO EDTERRAINGRAPHICS3: edtg::SH::initRenderItems() 00226.778 INFO EDTERRAINGRAPHICS3: edtg::CreateSurfaceRenderItem() Notice the extremely long delay from 117 seconds to 221. Is there a way to make the log file more verbose so we can identify the problem?

Unfortunately this phenomenon occurs with all SAS channels disabled as well. Translational lift is greatly undermodeled. Ground effect does not appear to be modeled at all. Rotor flapping appears to be modeled visually but does not appear to affect flight. Transverse flow/blowback is not modeled. Dissymetry of lift is not modeled except at extremely high speeds.

Yes, this is noticeable. From a hover, look down at your stick and you will notice movement of the in-game cyclic for a couple millimeters with exactly zero pitch/roll on the helicopter. I have tested this extensively with HOTAS warthog, so you may be sure there is no hardware deadzone. Also, when pitch, roll or yaw rate approach zero, the helicopter seems to 'lock' the current pitch, roll or yaw rate at zero. This is easily tested with pedals. I am using MFG crosswind. Once the correct antitorque is applied to completely neutralize your yaw rate, significant pedal movement is needed to "break out" of zero yaw. The same is true of pitch and roll.

Once again, I would like to stress that his server will not send UDP packets to the client on the correct port. Both TCP and UDP are specified in the port forwarding profile.

These options are not available in his router.

His setup is router + server only. There are no other hosts, and the server has one NIC with one IP.

c0ff, first of all thank you for helping us with this issue. However I don't think we've clearly explained the cause of the problem. We have both set up 'virtual server' or 'port forwarding/triggering' profiles correctly such that the internal and external ports coincide, but the issue persists. Please note that this issue seems to be specific to hosting DCS servers (I used to travel for a living, and successfully used my home PC as a gaming and FTP server which I accessed remotely from hotels and such using WOL. In addition, there were instances where I had to specifically remap external ports on my routers so that I could connect to my VNC server from within a comcast facility as they do not allow any traffic besides DNS and browser on port 80 or 8080). I shall try to make this short and sweet, and not include extraneous information... I'm not very good at that BTW When hosting a DCS server, I forward port 10308 (internal) to 10308 (external) using my host box's local IP as the target. I then launch the server. With this done, all seems in place. Unfortunately, my port is reported incorrectly as a 60k random port on the master server. So, when a remote client attempts to connect on that port, it fails. Of note: thanks to your master server update, this issue is no longer a problem. If, however, a remote client specifies to connect on port 10308, he is able to join the session successfully, albeit with one dire side effect: the session appears paused, his ping is reported as zero on the client list, and after 120 seconds he is disconnected from the session. After examining this issue with a packet analyzer, I have determined that the client's TCP packets ARE getting through successfully. This is why he can select an aircraft, participate in text chat, view an updated version of the player list, etc. until his 120 second timeout occurs. However, he cannot receive UDP packets from the server. This is why he cannot see other aircraft and the session appears paused. Here's where the game gets interesting: not all clients have this issue. Some clients are able to connect and fly without incident after specifying 10308 while others cannot receive UDP traffic from the server. Ooookay, hopefully that clarifies the issue a bit. Now the master server shows the correct port, but the UDP traffic (only) is still coming through on the random (60-64k) port. Thanks again for helping out, I hope this makes this easier. P.S. [sCoRPioN], thank you for your valuable insight.

I should point out that Graywo1f's gaming rig is in a different city than his server box. Furthermore, I have administrated his server's router directly and his NAT is configured specifically not to translate ports I.E. there is a separate entry for LAN (internal) and WAN (external) port, and he has them both configured to 10308.

Tentatively the issue appears to have been resolved. Tentatively! Still probing the issue with rigorous testing with the help of Graywo1f. c0ff, we may buy a plane ticket to Russia and find you, then give you a big sloppy kiss. No promises though, we are still determining what the deal is here.

Which intel media graphics accelerator do you have? Perhaps it's a problem with performance, or maybe you don't have sufficient VRAM. Try cranking down all graphics options to minimum to see if the problem persists. If so, try increasing shared video RAM in the BIOS. There should be no reason to go beyond 512MB of shared memory. Then again, You mentioned you're using Vista 64. Could be a driver issue. Good luck!

I have used wireshark pretty extensively to help diagnose this issue and I have determined that the problem resides within the master server's habit of mis-reporting your game server's port. This problem seems to be restricted to servers behind a router, but not all of them. In fact, I have observed this problem on my own PC behind three different routers (Buffalo, Linksys and Actiontec). Running a netstat command with filters for active ports reveals that the host still thinks it's on the port you determine when you set up the server (default 10308 ), and the initial heartbeat packet specifies the correct port in hex, yet when polling your session server from the master server, the wrong port is displayed. Furthermore, the port shown on the server list cycles periodically (only if no clients are connected), making server administration extremely tedious since the admin has to change the port forwarding profile every five minutes or so when noone is connected to the session. Interestingly, as long as there is at least one remote client connected to the session, the port remains the same. The ports shown on the master server list for servers exhibiting this problem typically vary randomly from around 60000 to 64000.

LOL! Gray you are a kick in the testes

Any new developments with this problem? So far we have determined that servers running from a fresh install do not experience this problem during the first session they host. The problem arises when the server is shut down. Subsequent sessions will produce the problem. We have also determined that only select users have this problem while hosting. The problem has been observed on varying rigs with varying internet connections. The problem is not isolated to people using routers (I have personally verified this), and no port forwarding profiles tried have yet helped. We have observed also that replacing the apparent port (60000-64000) with the correct port (10308 ) will allow clients to connect to a session, but not receive UDP packets from the server, only TCP. This will produce the circumstance where the client erroneously sees a paused server and later times out and disconnects.

I have analyzed some of the traffic from servers I can connect to successfully. These servers send both TCP and UDP packets in large amounts to connected clients, with the majority of traffic being UDP. Servers which show the incorrect port on the server browser do not send UDP packets of any kind to the clients that connect. This seems to be the cause of the 'pause' effect.