Multiple occasions where this option has been changed by users to e.g. server's IP, even though this is usually unnecessary because 0.0.0.0 already specifies to listen on all network interfaces - although this wasn't explained to the end user
Also enable /baninfo and /rankinfo (and theroetically any custom mod commands that choose to do so) to be used in MBs, without the additional restriction that moderation commands previously always required
Unfortunately, this also tended to results in the bots list being wiped/cleared when it was subsequently saved
This was caused by the JSON parser not properly handling numbers in exponential notation, that has been fixed now
Windows: It didn't divide by core count, so displayed value was typically 2x - 4x value in task manager
mono: Always returned 0.00%
.NET core: Not implemented on Linux and would throw PlatformNotSupportedException there
Now uses GetCurrentProcess().TotalProcessor instead to show CPU usage measured over last second, and also average since /sinfo was first run
Previously status message player count just counted number of non-hidden players. However it's possible for a player to be hidden, yet still be visible to guest ranked players - e.g. with /ohide
This happened due to two factors:
1) the standalone build would show a message box warning because it couldn't change the current/working directory
2) the gui schedules InitServerTask to run on the background thread. This in turn will eventually call Server.Start on the background thread, which in turn will call Logger.Log(..) which in turn calls back to Window.LogMessage
Note that the UI can only be updated from the main/UI thread. Normally this wouldn't cause any issues, because LogMessage checked whether 'InvokeRequired' returned true or not - if it did, then LogMessage scheduled the message to be logged later on the main/UI thread by using BeginInvoke.
However, it was rarely possible that due to thread scheduling, the call to LogMessage from the background thread would be run *before* the main window control handle had finished being created.
And unexpectedly, 'InvokeRequired' would return *false* if the main window handle hadn't been created yet - and hence the background thread would attempt to directly update UI controls with catastrophic consequences. Sometimes this worked, but other times it would cause the app to SIGABRT and crash in X11 somewhere, usually in X11Keyboard:XCreateFontSet
So to workaround this I made the following changes:
1) failing to set working/current directory doesn't show a warning message box popup anymore
2) LogMessage doesn't check 'InvokeRequired' anymore and just always calls BeginInvoke to schedule the message logging on the main/UI thread
So in the most of the rare cases when this issue even happened, it shouldn't occur anymore now. However, the underlying issue still isn't completely solved.. if you change the code to show a message box before the main window, you'll still rarely end up with the main window being a black box with X11
Although still documented on the wiki, I decided to simplify in-game help by removing it because
1) basically none of the current public command/plugin ecosystem uses visual basic
2) even when mono-complete is installed, you don't get a Visual Basic compiler (still need to install another package for it)
