Not sure if this is something in my Windows 2016 or Azure security or what, but I see these messages when the app goes to grab the mods. It does succeed, but thought I would share.
Yup, it’s in the FAQ section, it’s a SteamCMD bug.
Regarding the ports, I did not configure anything either: I have SteamCMD embedded inside the Tool itself, so even if you did not have internet at all, it should still manage at least to save this SteamCMD.exe to disk.
That being said, the first thing SteamCMD does is to auto-update, so maybe that part failed because of some random firewall or security issue. Who knows
For people having problem with the Game Server complaining about the Direct X or Visual Studio 2015 runtimes not being installed, please check the FAQ, I added a section with a download link to the UE4PrereqSetup_x64 installer.
Aditional Checkboxes possible?
In certein circumstances a sub menü with more Server settings…
check and Edit the Settings.ini is sometimes confusing
Things are possible, but in order to make my life easier, it would be nice to provide me with the actual exact parameters (which ini file, name of the section, name of the parameter, and usually expected values), I don’t know all the settings, and the less I have to poke the dev team or search for what the parameters are, the better
Both should be in the serversetting.ini file if I remember my settings right =)
I’ve been using the (signed) version 1.0.15 for some time and it seems to work great for me so far. I think sometimes after changing and saving other settings (like the restart time or the fact that it does restart to begin with), It forgets the “On Startup Execute” setting and I’m pretty sure it reverted back to the original time when I moved the restart to a later time too.
But truth to be told, I haven’t tried recreating the circumstances and today I double checked and the restart time change I made, definitely stuck the first time around. I’ll keep an eye on it and report if I can get a better grip on when and how it happens.
One thing I noticed while researching another issue with lagspikes related to people logging in when large mods are enabled (posted here) is that the launcher seems to make reading accesses to the disk at about 120 MB/s rates in regular intervals. Those same reading accesses are gone when I turn off the launcher:
This hasn’t caused any issues, but I still thought it’s noteworthy.
I do have one more suggestion though. With the recent addition of Japan as serverregion, the tool may have to be updated to recognize the region number code in the ini file. As far as I can tell they are
0 = Europe
1 = North America
2 = Asia
3 = Australia
4 = South America
? = Japan (I assume it’s 5?)
One interesting observation I made when looking into this is that even though the field for the Server Region is greyed out and inactive, it does change when I edit the serversettings.ini directly and change the region code there. The GUI update also seems to coincide with the above mentioned disk accesses.
In any case I want to once again thank you for giving us this tool and especially for being so receptive for feature requests and available for questions. I’ve already made good use of the automatic execution of scripts and have one read the database and send the information to a google sheet which the generates some interesting statistics about our server:
It’s pretty much the same code for all the settings, at first glance I don’t see what could cause that.
If you can come up with a repro case, that would help
An easy way to catch these is to use the resource monitor (Task Manager -> Performance -> Open Resource Monitor (at the bottom of the window)), select the application you are interested in, then look at the list of Disk Access it performs.
Basically the Launcher is doing two things that trigger file access:
- Each time one of the three ini files (engine, game, server settings) is touched, I reload it to get the latest parameters (to limit conflicts or corruption)
- I regularly load the part of the server logfile I’m missing so it can be shown in the output
So basically, if mods start to spam to log a lot, the launcher is going to load from disk as well.
Good point, definitely need to add japan.
As long as the suggestions remains in the domain of “benefit most of the people” and don’t take too long to implement, it makes sense to at least try to do them.
That makes sense. it’s probably the logfile that uses most of the actual bandwith since it’s usually around 120ish MB after 24h of running the server.
Confirmed that it is indeed 5 that’s considered Japan.
Should not matter, normally I only seek to the end of the file to only load the part that is missing.
I guess there’s a bug
Regarding Japan, if I’ve time I’ll try to get a new version with that added, and possibly the BattlEye and VAC checks, just not sure where to put that… as somebody said, the UI is starting to get crowded
I’m using the graph of the Process Explorer that gives me slightly more information than the regular resource monitor which, oddly enough, doesn’t show any disc access by the launcher at all.
Here’s a screenshot with tooltip of the actual spike:
and the size of the logfile:
So it kind of fits, but I’ll check again once the server has restarted and created a new, smaller logfile.
In any case, since the reading doesn’t seem to block or slow down any other process on the machine to a measurable degree, this is not really something that should bother you a lot.
I don’t know, maybe it’s time for a submenu “Other server settings” or some such. But once again, those are luxury problems as far as I’m concerned.
So I checked the magnitude of those spikes right after the restart and it still fits the theory that they’re largely dependent on the size of the current logfile:
Ok, could you please try the Dedicated Server Launcher 1.0.16 ?
- Added Japan to the server region list of valid values
- Fixed a problem with the log file loadings which ended up loading the entire log instead of just the updated portion
- Added checkboxes for BattlEye and Valve Anti Cheat settings
Considering the time I spent on it, don’t expect a lot of testing on my part, so no guarantee that it all worked, but it should at least not work worse than before (except if I really fumbled on the log file loading optimization)
Regarding the UI, I’ve just moved stuff around to shoe-horn the BattlEye and VAC checkboxes…
Hopefully it will all work, the executable has been signed, so if your anti-virus whine again, not much I can do, except having the version sent again to the anti-virus company as “false positive”.
Have a good weekend
Cool thanks Toolguy!
Also I have one small question, when I originally ran the server launcher I forgot to set my region code to North America, I change it but now the “Save Changes” button is grayed out. Is there something I’m missing?
Are all the lights green? Or do you have a red light for Server Name and Admin Password?
The Save Changes button is disabled when there are some very wrong values.
Testing it right now. Initial results look promising. I’m still having trouble with the automatic execution of the script. Weirdly I can’t reproduce them on my local machine. One thing that’s different is how the launcher writes into the serversettings.ini. While they look fine on my local machine, the dedicated server keeps making a mess by inserting tens of blank lines and then adding more blank lines with a [ServerSettings] tag over them before finally adding the actual settings lines below and those each have their own [ServerSettings] tag too. Here’s are two screenshots illustrating the issue:
Since my local server doesn’t suffer from the same issues I’m wondering whether it could be an issue with taking over the configuration from older versions could be causing it. When I manually removed them (with launcher and server not running!) it just readded them again after the next server restart.
I answered that question a few eons ago (guess I should copy that in the FAQ now):
So basically, just press Save, and when the server starts you will have a clean ini file again.
I was not given a lot of free time to work on the tool, so I had to take some violent shortcuts here and there
Regarding why the script don’t run, maybe check the DedicatedServerLauncher logs in the Logs subfolder?
Sadly I can’t just shutdown and restart it at will so my options to test this are somewhat limited, but I don’t think it did/does that on the remote server either. That is to say when I restarted the server and checked the ini it looked like that.
So if I understand you correctly then the ini should always look good right after a restart and it only clutters up if I change settings whole it runs?
Nothing suspicious shows up. Just the server being started and then another one that it’s running.
About 2 to 5 seconds after the server starts running, it re-saves everything after flushing out what it did not like (like invalid parameters, or obsolete stuff)
LOL! and now I know. Thank You! I had set it originally, but I had issues early on and must’ve missed those two things the final time through.
Alright, I think I know why it looked like the scripts were not executed. The batch file was indeed executed correctly but the commands within it weren’t and the shell closed so quickly that I didn’t catch it opening at all. Would it be possible to log the output of the scripts that are executed at the start somewhere? Assuming there is a logable shell output at least.
The reason for the commands not being executed were that while I gave the full path to the batch file that contains all the other script calls, I didn’t give the paths to the scripts themselves within the batch file. I assumed the working directory, from the perspective of the batch file (and for the scripts called within), would be the same as the batch files itself… and apparently it was in some cases because it has worked most of the times but not so in others.
I’m unsure what decides which directory the scripts are run from but since I don’t want to change all paths to be absolutes, I’ll try changing to the right one within the batch file instead now.
Other than that, I can now definitely confirm that your fix for not loading the whole logfile at every change has worked!