Maverick87Shaka

Nah, If you hate long list, you can just create two rules and enable all your instance at once, nothing else. Since is not required/essential anymore to keep server offline while loading, it's totally safe to have just one rule to specify all the ports used from all different DCS instance. And you can simply create one for TCP and the second for UDP. that's all. It's really something above DCS, it's a common practices. If you have a windows server that act as a license server, or any other services, NEVER add programs to the firewall exception, manually specify port used instead. It's part of golden rules

You should stop using "allow program" rule in your firewall settings, and start use port rules manually adding ports and protocols that you need. nothing else.

From this page, if you click on Back to Port Forwarding, how it looks like the interface on that page? somewhere you should be able to add a new address or pick up fro ma drop down list your computer, and assign the custom rules "dcs tcp" that you have just created

yep, strange part is that you don't have the section to put destination address (internal ip like 192.168.1.2 etc..), that is normally required. Not sure u are in the correct section of your modem/router, can you make a screen of the menu also?

if in protocol dropdown menu you can only set TCP or UDP, you need to add two separate rules. So call one DCS TCP, and the other DCS UDP. Port range you have to set start and stop, so basically are the same, so default 10308-10308, and leave the same in translate to 10308 - 10308

What does it mean doesn't work?

Try to run a server with that mission, and check advanced option to enable: Allow to change Skins For the problem of the module, you have to set manually at zero the initial quantity available (default is set to 100)

It's already possible, if you move a bit the UI of the spawn slot, you have underneath the map (like the F10 map), you can interact with that and select directly the airfield from the map itself

@BIGNEWY we're trying to switch to dynamic spawn system our PvE servers featuring a persistence conquest, but actually we can't prevent people to join red coalition and pick up a red plane from the airfield not yet captured. So we should be able to have an option somewhere in the mission editor, to disable the Dynamic Spawn for a specific coalition, and leave it available just for the other. That is a must have feature for PvE server that want to use this feature in a "conquest environment" A possible workaround is to script all the warehouse to set 0 plane and resources if the airfield is of the "forbidden" coalition side, but since you can't change on the fly from unlimited to restricted and vice/versa it's a bit time consuming activity. A simple option on mission editor will be much appreciated

Based on my experience liberation tends to fill up the maps with units to create a lifelike battlefield, that is a great feature but tends to have lots of units (even if they are inactive) and, again, based on my experience, units/groups count in the .miz file has the most impact on server performance. In particular, ground moving unit. But I have no recent experience, just tested a bit at some point and then we move over for custom made mission. Regarding the e-core, if they are disable it should not be a problem since basically server is not yet a full "multithread" app (just the client with rendering is MT), so I believe it doesn't care if they are there or not. at least for the server, client may mess up something since maybe is expecting to find also the e-core based on your CPU model.

Su MSFS ci sono SDK e API molto più evolute, non è minimamente paragonabile al lavoro che è necessario fare (purtroppo) qui su DCS. fidati perchè @chromium in questo è forse una delle persone più esperte in questo con il suo DSMC! ( e nel mio piccolo pure io per l'integrazione dei device e del lavoro per mettere la persistenza sui server )

essendo una mod....il vero dubbio per me (che volo solo esclusivamente online) è come si comporta online con i vari integrity check etc......perchè il rischio è quello che da un momento all'altro magari non funziona manco più per i vari IC e non te ne fai più nulla.

Almeno c'è la magra consolazione di avere la certezza del il fix del radar dell'F15E

Not fully implemented mechanic, like simulation on signal strength/frequency and all the combination with pod and targeting radar or some more complicated stuff of electronic warfare, but definitely yes it's have impact even in MP match, like described by @razo+r

You can't use easily the local webgui from other machine, it will run just on the DCS Server host, according to the webgui port that you have to setup manually (and different for each instances of course) in the autoexec.cfg file. The process are explained in the document that you've attached here, with the following note: webgui_port=**** webgui_port=**** the *** will be replaced with the WebGUI port for the instance

it's normal, when you start the server your server "talk" to the ED master game server saying: "hello, I'm a DCS Server with this IP address and this port" The ED Master game server share this huge list of pairs IP/port to a DCS client when opening the multiplayer section. The client start to "interrogate" each IP/POrt to get server details and populate the Multiplayer GUI list. If your ip is changed in the meanwhile, the ED master server and clients are not aware of if it, and simply trying to interrogate the old one, founding nothing, and skipping to other in the list. You must restart your server when IP address change to have it on the multiplayer list. And in general for server performance, at least one full server restart per day is highly recommended even running simple mission.

I normally don't use the webgui to manage settings, just times to time to check on the fly connected people and change running mission on our mission server. But, I guess you can try to delete serverSettings.lua (backup renaming the file is better idea) and see if from the webgui it will be created automatically again according to the setting that you provide in the webgui. Can be a problem of file permission maybe But it's just an idea, not tested.

Sì sì, mi chiedevo appunto se lo avesse scritto su Discord Razbam col suo account per andarlo a ripescare. anche perchè nello screen purtroppo hanno omesso data e nome. L'unico "riferimento" che trovo è il post su hoggit/reddit, ma anche li manca il contesto della fonte

Questa cosa è davvero gravissima...se prima concedevo il beneficio del dubbio alle parti (ED e RB), onestamente ora mi pare che la ED abbia tutte le ragioni del mondo per essere un pochino di traverso con RB.... È davvero un peccato, perché alla fine siamo noi consumatori a rimetterci, e onestamente non mi sembra che la cosa possa a questo punto arrivare a una soluzione pacifica della questione. @nessuno0505 la fonte qual'è?

Trying to release a better build rather than been strict chained to a release date is a positive attitude in my opinion, the problem probably was the decision to scrap out the Chinook and just give one day of delay (from 3rd to 4th) to properly tune the build. Maybe at that time (on the original postpone announce) ED Should have taken more time? But it's ok. Take the necessary time to release a good build

Beh si erano venduti una data inserendo molte, molte cose dentro, e credo che col normale ciclo di testing interno, ci sia stato davvero troppo poco tempo per provarle e garantire un buon risultato. Togliere un modulo all'ultimo così viscerale per alcune funzionalità (il ch-47 e la logistica nel dettaglio) a mio avviso non è stata una grande mossa, o meglio, se il ch-47 non era pronto aveva senso svincolarlo dall'uscita della build, ma pretendere che tutto il resto venisse ri-testato in un giorno solo, (logistica inclusa) senza la presenza del ch-47, è stato davvero ottimistico. onestamente, anziché annunciare di rimandare dal 3 al 4 togliendo il CH-47, a quel punto mi sarei preso una settimana in più per sistemare per bene la build senza il Chinook. col senno del poi....facile parlare, me ne rendo conto, ma questo è.

Patch rimandata ancora, non uscirà oggi (4 Luglio) Questa volta non danno la nuova data....tocca aspettare Scusa @giullep abbiamo postato insieme

I've tested small rented virtual machine (VPS) just to host OpenVPN Server, the server behind NAT connect as client to the server, and the server is set to forward all inbound traffics (except the ovpn port) to that client. It works, not ideal condition but is technically doable. The problem was that I still have to pay for the VPS ( about 5$/month) and add unnecessary latency to all connected client, especially if our VNP/server is not in your same town/country. It was just for a test more than a production environment by the way, but it work

Normally I would suggest to add just the port (both TCP and UDP) as PORT firewall exception, rather than enable program, that based on my experience is less reliable. If you're sure your IP is public one, just check again that on your router,you've enabled the forward both TCP and UDP.