hlfritz

well it does seem that some option methodology has changed (view changes in lua files in saved games folder, server nickname in server config file to name a couple - there are probably more), but there seems to be nothing in patch notes or otherwise that tells about it. also, it seems the update has overwritten some settings that were set in the game which probably should not happen (civilian traffic level is one we noticed in our group - we *think*), or at least a warning about what is being set and to what.

anyone know if the patch that was released a few hours ago fixes or helps with this issue?

anyone notice if a fix is in for stennis in missions causing the server to run amock?

our group tried a couple different missions. the high memory usage (up to all free memory on the server) started to climb after the 3rd person joined the server with a stennis present mission. this makes it unusable when carriers are in missions. we tried a mission with no carrier and all seems well. we can corroborate the carrier-in-mission issue.

you should probably go here and pile on: https://forums.eagle.ru/showthread.php?t=264018

yah - check here: https://forums.eagle.ru/showthread.php?t=263526

are you on the Steam or non-Steam version?

bonesvf103 is also on the Steam version.

TT, yes that is the same as I do, just on Debian instead of Ubuntu. Madfish is asking if anyone is running a hyperviser on bare metal, i.e. the hypervisor is the host OS.

yes, also agreed. it seems to be related to some security cert or other and maybe reinstalling will replace it, at other times it does not. i installed after that time period so perhaps mine is working as a new install as well. maybe there is something in the os certificate manager that could be sussed out. i see on my laptop where i tested the dedicate server i have two certificates (one 3rd party root and one intermediate) by thawte which correspond to the cert used when connected to digitalcombatsimulator.com (eagle.ru has a sepearate cert from the same thawte auhority). i also have a thawte timestamping cert. not sure if these are used for the remote control app at all, but all of their validity dates are current. this applet can be opened by typing certmgr.msc in the run window or at a command prompt. not sure if looking at these on the servers will help, but just an idea since some have mentioned a security type of issue.

I am running mine on a Debian host using KVM-qemu with virtualized win10 successfully. I cannot stress enough I had similar control problems until I properly forwarded UDP. Local control (loggged into the virtualized Windows OS via remote desktop) worked, but control through the ED account login/my servers portal did not work until I had UDP forwarded along with TCP. It would show up in my servers when logged in to my account, but control would fail (could not connect). Once I forwarded/allowed UDP as well it functioned just fine.

It does work, I have changed the name of my dedicated server. here are the contents of my dedicatedServer.lua file, which is in the scripts directory: net.set_name('RLG Server') local res = net.start_server(serverSettings) if res ~= 0 then log.write('Dedicated Server', log.DEBUG, 'Failed to start server with code: ', res) end The server itself shows up as RLG Server.

sounds like you might have some type of upnp enabled on the router. i usually find it is a good idea to turn that off and manage things manually. i usually turn off the firewall on my windows machine since it is always sitting behind my router/firewall, but that should not be necessary as long as you get the prompts to allow the application when it runs. usually a router will only allow ports to be forwarded to one system at a time as well. sorry i do not think i have any hints or suggestions.

i think i had the same thing happen to me and i had forgotten for forward/allow for udp on the server port (tcp i did).

just in case, as stated, not just ports but protocols as well. both tcp and udp need to be opened for 10308 (unless you change that port). also both on local machine and in firewall.

no worries.

you may have another firewall, not just on your PC. you may have a router with a firewall as well, or if it is doing NAT the ports and protocols need to be forwarded to the proper computer as well.

just in case - make sure tcp and udp are open in firewall for port 10308 in addition to port forwarding.

Be advised that the html error codes presented by a web server can be customized, even on a per web site (or even web page) basis. Not saying that is what has been done here, but it is possible. Most often custom error codes are added to the defaults, but sometimes the defaults are hijacked and reused for a custom error. Supposedly this is done to help debug when things go wrong. ;)

got it, thx! i will see if i can work up some general calculations and post back.

OK - what is range to target? do you mean it goes active at about 15km from target? thx.

Thx, but is that pitbull 15km from target, or pitbull 15km from launch?

uboats, how long for estimate or stopwatch? i.e. how long does one wait. that is a critical piece that I have not been able to dig up anywhere. I am willing to estimate, but I do not know what that time period is before pitbull. thx!

ensure you have BOTH TCP and UDP ports open in your firewall for the server port. The web control port only needs TCP, but the control app will not work if all ports/protocols are not open to the server.

it is all working for me, on two different machines with two different dcs accounts. both the local gui and the remote control via dcs world login. also for both release install and openbeta installs on each of the machines.