Maverick87Shaka

Just tested on my client installation, with the current OB 2.8.0.32235.1 and it works as expected. You can try to run a server with a different working directory to see if there are some spurious settings that prevent the server load. DCS.exe --server --norender -w test_server where test_server it will be the name of new server folder under saved games. If it's still not working, make a full repair of the client and check the windows permission of the file itself.

Server can be installed anywhere, it should not be a problem. Just make sure you still have under C:\users\<username>\Saved Games\DCS.openbeta_server\Missions\ some valid .miz files if missions folder doesn't exist just create that, and put your file over there.

As result, JF-17 is no longer usable in any multiplayer server basically

Let me know if you need help, I can try to prepare a package with everything you need ( host + reverse proxy ) packed to run from ngnix. Put the zip on DCS server, run ngnix and you have everything Fly Safe

There are already a couple of method to know what is your callsign: If you have enabled on map at least with the own position visible,including fog of war, allies only etc, you can directly check from map: ( Chaos1-1 in the example ) Prepare the mission including in the group name the callsign ( is the method that we use as squadron for all our internal missions ) In this way the first slot will be always -1, second is -2, etc. Since in the mission editor you can't change the last digit, but it's automatically assigned and not editable, there is no way to make mistake. The first line of the group will be always the -1, second the -2 and so on. Last option, make a quick check with a fake radio call to a tanker or other AI unit, it will say in the transcription your callsign. The role selection UI is already full of information, I'm not sure I would like to have another column with an "obvious" information on it.

Simple ( but dirty ) way that comes to my mind for a quick workaround, could be read the dcs.log On second line you have all the arguments. its not 100% accurate since some people can mess the starting arguments, but it could be a starting point. === Log opened UTC 2022-11-01 13:00:50 2022-11-01 13:00:50.652 INFO APP (Main): Command line: DCS.exe --server --norender -w SyriaLiberation

You actuality need both, if you only use the webgui folder hosting you'll get the same error of trying to use webgui folder locally from any other computer. Reverse-proxy is required to make DCS believe the request comes from the same machine (127.0.0.1), otherwise it will not reply to the request. The method to host the webgui folder just give you more options to control who can actually use that url that you'll provide, you can track the log etc, gives you more options that simply provide a .zip file to your moderators/admins. Even just for any future change, without send over modified javascript again, you just take care of update webgui folder hosted by yourself, and you're ready to go!

Non conosco nel dettaglio tutte le su varianti, ma credo che sia solo la versione MB-339CD dotata di probe per effettuare il rifornimento in volo, non so se poteva essere "retrofittata" sugli A o PAN che abbiamo noi su DCS. Non mi pare che sia nei piani, quindi a questo punto non riporrei troppa speranza nel poter fare rifornimento con questo velivolo ( sarei lieto però di essere smentito con un CD in arrivo ahhaha ) null MB-339CD

Buongiorno piloti, Dopo ormai diversi mesi di non funzionamento del sito delle statistiche e info relative al server "conquest" del Persico, abbiamo deciso di investire tempo e sforzi per ripristinare questa parte del server DCS, perchè crediamo possa creare interesse nel giocatore avere un punto in cui "rivedere" i propri progressi. Con l'occasione, anziché limitarci a ripristinare solo quello avevamo costruito in passato, abbiamo colto l'occasione per fare un completo revamp del sistema. Ora è possibile vedere un overview di tutti i nostri server, entrare e vedere nel dettaglio il proprio posizionamento, e infine entrare sul proprio "logbook" e vedere i risultati personali. Stiamo ancora finendo di limare gli ultimi dettagli, ma crediamo che sia già arrivato a un buon livello, ed è per questo che abbiamo deciso di condividere con voi questa notizia! La pagina aggiornata la trovate QUI! Fly Safe!

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.