Maverick87Shaka

This is a good approach, and it's also a really common best practice to do, not only for DCS server I make a quick and dirty test right now with ngnix used as reverse proxy, and it works, here the steps: Open on DCS game server firewall a TCP port to be used by reverse proxy ( in my test 9087, listen directive ). Configure ngnix to reverse proxy incoming request to the webgui_port specified in the autoexec.cfg file of the server ( in my test 9087 => 8087 ) Here the basic ngnix.conf file: #user nobody; worker_processes 2; error_log logs/error.log debug; pid logs/nginx.pid; events { worker_connections 1024; } http { include mime.types; index index.html index.htm index.php; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] $status ' '"$request" $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log logs/access.log main; sendfile on; tcp_nopush on; server_names_hash_bucket_size 128; # this seems to be required for some vhosts server { # simple reverse-proxy listen 9087; access_log logs/reverse-proxy.access.log main; # pass requests for dynamic content location / { proxy_buffering off; proxy_pass http://127.0.0.1:8087; } } } Copy the WebGUI folder and edit app.js to point at reverse proxy address and port Since the ngnix server is also a web server, instead of copy webgui folder and use it locally, you can also try to directly host the webgui folder with ngnix, so basically from a user prospective, they just need to connect to a given URL without worrying about grab the webgui folder and other stuff, they can also ignore all the port configuration, because basically you can change one time, and it will be immediately apply for all the DCS server admin/moderator. Let me say, since ngnix is already running, this last option can be a definitely good idea, protecting the url with password, ip whitelist etc.

Not sure when was introduced but it looks like is not going to respond anymore from anything that is not localhost. in this scenario the only option that comes to my mind is a reverse proxy to masquerade request as localhost to the gameserver. Not a straightforward solution I know, but it should works, let me know if you want try in this way, I can try to prepare something

Not sure how Liberation software works, but maybe is required an updated on Liberation to get it work with DCS 2.8 version. Just try to reinstall to see if during installation there are some action on scripts that was deleted by the update.

Wrong statement. DCS servers takes a lot of RAM, mostly depending on which map is running at the moment, and the complexity of the mission that your running. Server instance fire up at least a 5GB of RAM on "empty" mission over Caucasus, and up to 14GB for "medium complex" mission over the Syria. Persian Gulf sits in the middle.

If you're talking about this exclamation mark, it's something that was introduced before 2.8 It's related to the free trial program, it means that on server with exclamation mark, people with only free trial account on their own account, can join this server. Most of the server doesn't have this feature enabled to avoid "trolling" people. Fly Safe

Yes DCS need both TCP and UDP, so add two different rules, one for TCP and the other for UDP.

Non mi è molto chiara la domanda, ma se intendi avere una qualità diversa su schermo a livello proprio di "settaggi" diverso da quello che usi per il visore, la risposta è no, perchè il tuo pc dovrebbe generare due immagini diverse, quindi ancora più peso per il tuo pc

Unfortunately not, there isn't a "default" system to make server restart, so basically every server admin implements its own reboot/restart method, and they are really a tons of way to do that, since we also make some activity on persistence files, random weather and other stuff.... I guess it's not really an easy task and also it's now almost impossible to make a standard method that works for every server. To avoid this problem for example, I normally use fixed reboot every 6 hours at given time schedule ( trying to make during dinner/lunch etc... ) so players can know exactly when the server will reboot.

if they are 2400Mhz should be not set as XMP OC profile since they can reach it with standard SPD memory negotiation. To test if memory are in good condition, generally I'll suggest to try HyperPI first since it can be used from windows, and than for a full test the classic MemTest86.

Looking at your DCS.log looks like you've started several multiplayer session, ended up loading a recorded .trk file, I guess trying to recreate the problem..it's not exactly the same since the log is not really clean, but should be fine. Before the IC error there's no warning about reaching/exceeding maximum memory available, so I guess IC it's more related to a stability of your system. At what speed are you running your memory? I suggest to disable from BIOS any OC, especially the OC on memory like XMP to set the memory frequency. Try to start the system ad default 2133/2400Mhz for DDR4 and make again all the test to see if it help to solve your problem with integrity check. Regards, Shaka

Attach also your DCS.log generated after the session where you get kicked for integrity check, it could be also a problem with your memory RAM (not enough or some error on it)

If you still have the autoexec.cfg with the following line: net.download_speed = 262144 net.upload_speed = 262144 that's why you're limited to 2mbps ( 262144 B/sec ≃ 2Mbps ), I strongly suggest to remove it. By default DCS doesn't limit transfer speed and try to use all the bandwidth available to transfer .miz file to the client when joining. Following you've an example of how fast a client is getting a large .miz file (37Mb) from the server in a quick test that I've prepared on my environment. It doesn't look like a DCS problem, maybe it's related to your specific network setup ( firewall / traffic sniffer etc ) or hardware ( really slow HD where mission is stored? ) on server. But first of all, remove that line from autoexec.cfg Full video of the test:

Whenever you host a mission, every client need to re-download the whole .miz file on connect. there is no other way. It's how DCS works. The settings that you're trying to apply it's still working but you're actually limiting the max transfer speed. If you don't have good upload speed, just try to limit your mission file, avoiding use .png and prefer compressed jpg for briefing etc, remove audio and other unnecessary file ( i.e. knee-board image that can be placed on client side )

I don't believe it's a problem of IPv6, actually it's just optional and not mandatory for DCS. I'm also on IPv4 only connection and so far I don't have any issues joining servers or find them in the list. What you can try if you have some problem, it's fire up a VPN and see if the list changes a lot.

You forgot also: Multipurpose UFC: https://www.multipurpose-ufc.com/ it's not a 1:1 replica but can be interesting for people that flying more module. Cheers

I would suggest to test on other server if you have the same problem. In our squadron we can easily stay connected for more than 3 hours, changing slot and so on, and we don't have any issue ( my pc has "only" 64GB compared to your ) or at least not so much ram used. And we run a pretty complex mission with scripts etc.

Frame rate during loading is something that you don't have to worry about. Loading time for multiplayer, especially for a server that is not fresh rebooted, or where a "complex" mission is running, can be a problem, but normally not related to a performance issues on client computer. If you want try to improve your loading time and general experience, you can just upgrade your OS disk and where you've DCS installed to a fast SSD, an m2 nvme drive ( if you don't already have and your mainboard support it ) Since DCS release and years, even if one of our server keep running the same exact mission file ( just adding slot for new modules ), we've noticed a more longer loading time, most of the time spent in the "NET SIM POST START". I believe it's something related to the "initial synchronization", like placing the clouds in the right place taking into account the weather preset and time elapsed since mission start. Nut I don't have any evidence to this, it's just my "feeling" based on my multiplayer experience, where I play really often the same servers, but always seeing different loading time. For the overall performance after join, so the pure framerate, the number of active units and groups on the server are usually the most important things. On some multiplayer server the mission that is running can easily exceed a number of this unit that your client can handle, and so you start see some performance degradation. Currently there is also an annoying bug that left some "garbage" on server side, that can easily cause degradation of server performance, maybe you just get into server in a bad condition. I'm sure in the future situation will improve as DCS is in continuous development and ED is getting more and more effort in multiplayer experience, but it's something that can't happens in a matter of days.

Make sure your ISP is not providing you a connection trough CG-NAT, to host a server over internet you must have: public IP Address 10308 TCP and UDP port forwarding set up in your router, that point your internal LAN IP address of server machine 10308 TCP and UDP port open in firewall of your server All the clients must be on the same exact DCS version ( to be fair you need same version only when net protocol change, but to simplify the concept, make sure you are on the same exact version including all digit, i.e. 2.7.18.30348 )

As far as i know....no. Currently there isn't a keybinding to accept people on board.

You can actually grab the WebGui folder, copy to another computer in your local network. Edit the app.js in js folder and replace all the 127.0.0.1 url matching server url, and of course on server machine you need to allow traffic from the control port within the firewall. But personally, since it will be plain http traffic ( even if it's in your LAN only in theory ), i will not recommend this setup.

A quick test with the latest OB Dedicated server ( 2.7.18.30348 ) A simple script that spawn random unit, randomly in zone, every 1 minute Is running since 1d and 4h with 1700 and more unit spawn, and they still spawning correctly, none of them are damaged or dead. null

I'm making some test, but I can't replicate the problem. On my dedicated server units are spawning effectively according to the template. What exactly mean with "restarts" when the problem occurs? You have goal/trigger that reload the same mission without complete server restarts? This one?

This is really strange behavior, I'll try to make some test in the next days, but generally speaking to keep good performance, if you have a "running" mission with some AI stuff, it's not a good idea leave the server working for more than 8 hours. It's something really common with other server like Arma and so on to plan a restart to keep it "fresh" if an AI or spawn is involved. I manage three public instances, and all of them since they are complex mission restarts every 6 hours. The only instance that last 24 hours is a private PVP clients only arena, that we use times to time to practice dogfight against each other of the team. No AI involved, no spawn, no script at all, just a dozen of clients slot put one in front of the other. What comes to my mind, try to put a spawn and a message write in the log message every hours, and monitor what happens, looking in DCS.log if there are strange things. Iìll try to do the same and keep it running for 24/48 and see how it will act. It's happening just after a mission restart without closing the DCS dedicated server right?

Yes, you can use Notepad ( better if it's something like notepad++ that is free ) and check near the bottom of the file ( after DCS crash ) You can also attach your log file here and we'll take a look at Fly Safe.

Are sure about that? We've used several time ( basically all the time ) the clock to synchronize our mission, flying with more than 40 players with a specific Time On Target. Nothing goes wrong. I've personally attended also to a 70 players mission! It sounds more like a problem of what people set on their plane to show, GMT vs local time and difference between each aircraft and what by default displays. The time in multiplayer is synced, I can guarantee for that