@JoeGreene: Yeah, I'd agree, that if you are running an headless server, you are probably doing something more than just helm/weap. However, Game master is still one of the least-likely used clients--unless a mission specifically makes use of the Game Master, then it would have no other function but to set your server parameters--so in that case, why not just make the Game master console the server?--my opinion is to find a better mechanism for setting the parameters.
@lucas99801: I also have run multiple clients on a single PC a lot--my friend and I are usually the only two that can get together for a game, so either I usually run the server on my laptop, or he runs it on his, along with the client for the selected consoles. That is not so much the issue--it's for finding a simplified way of setting game parameters when the server has no direct user interface with the normal Direct3D graphics. Kind of inconvenient, in my mind to have a special client set up somewhere just to set the parameters--but possibly the only solution if you don't have Direct3D on the server.
As I pointed out earlier, a trick to overcome, if no user interface is used, will be having to indicate when to start the game--if the game starts before all clients are ready, bad things could happen. But how would the server know everyone who is going to connect is connected and ready? And what should the server do when the game ends (currently stats are shown, and the user has the option of restarting or exiting)? Those are questions for Thom to work out, if he implements the headless server.
As timechick pointed out, though, all our ideas so far would require some kind of command access to the machine to start the Artemis server, whether it is remote desktop, physical access, SSH, VNC, etc. But there is yet another option: running the Artemis server as an installed Windows service, where it runs constantly (or at least as configured in the service). This would have the advantage of auto-restart if it crashed. It would require a bit of code refactoring on Thom's part to enable this, but it could be done. This design, however, would require that at least one of the clients would be able to configure parameters using Thom's proprietary Artemis protocol (SSH or VNC directly to the service does not really make sense in this case--the entire command structure and SSH/VNC protocol would need coded into Artemis--but coding to work with the existing Artemis protocol would require the least work--at least from Thom's perspective, but would mean he would also have to build the user interface to enable the configurating).