I was only interested in the first lines, #2 looks fine, my log shows several server lines and some using tcp protocol, but I don't think it's used, unless a client will connects. In #1, your tcp was tied to an actual IP address (instead of 127.0.0.1 which is the local host) so, it was probably using the network.
In any case, you said it looked better with #2 so, this seems to confirm, the real problem is lots of traffic over Simconnect, which is aggravated if running in TCP mode.
As a test, I had a look at the diagnostic with and without UT2, and I must say UT2 generates a *lot* of events, if you disable it, you'll see way less events scrolling down.
Yes, it's possible to enable a file log, but I don't think it could be much of use, if the issue is simply too much data sent over Simconnect, because of all the addons put together, there's not much that we can do, we are sort of trapped because:
- If we reduce the frequency of our commands, they'll probably get even less chances than now of being executed
- If we "play hardball" and increase the frequency of our commands, it will only worsen the traffic so, we *might* get the chance to control our own stuff properly, but we might affect *other* modules, just like UT2 is affecting us.
If you want to try with the log file, just uncomment ( remove the ; ) the last 3 lines of the Simconnect.ini example I've posted, and it will create a log file on your C:\ drive.
An interesting test would be:
- Running the sim for 2 minutes, with KDFW but without UT2, exit and check the log file size
- Running the sim again for 2 minutes, with KDFW + UT2, exit and check the log file size again
This might give an idea how much data UT2 is sending to Simconnect.
Have you tried playing with UT2 settings, to reduce the amount of airplane/data ?