Linux Server (sort of)

[Nalgas]

So I kind of disappeared for a while, but...it's me again!

My old AI War group's interest in AVWW has finally picked up enough to the point that they're getting kind of antsy about 1.0 finally coming out at some point, particularly because it actually has multiplayer now, so I figured that was as good an excuse as any to set up a server and see what we could see.  We'll see about that part later, but the server part is an adventure in itself.  I am a firm believer that servers should not run Windows or be on my home connection, especially when I have a perfectly good one sitting mostly idle in a datacenter somewhere which is already running Linux.

For anyone playing along at home, it seems to work fine so far just zipping up the Windows install dir, chucking it up on there, and running it in the current stable version of Wine.  I also needed the Mesa OpenGL crap and Xvfb just so it would have somewhere to draw the useless status window that I can't see, but without it it won't even run, so...  The moral of the story is that it does run, even if it's a bit inconvenient.

I haven't tried playing with other people yet, so I'm not sure how performance is.  RAM use is just fine with no graphics to deal with or anything, but the CPU situation is not looking great.  (Speaking of which, I still do not understand how I'm not getting a solid 60fps in this game.  It made sense in the alpha before stuff was more optimized, but I have even faster hardware now than I did then, and I was dropping frames a few times in the tutorial of all places.)

So yeah, you can run the server completely headless on a remote Linux box with a bit of dicking around.  It is doable.  I'll have to get back on you on how well it actually works on the hardware I have (two cores of whatever hexacore offering AMD had last year, shared with someone else, and 2GB RAM; it's not otherwise doing anything terribly intensive most of the time, so most of that is available to it).

[Nalgas]

After fooling around for a little while with two of us, it seems to work fine.  One of my half-cores stays pretty much pegged at 100% the whole time, but that doesn't change whether no one's connected or both of us are doing stuff in different regions entirely, and it still runs well.  The lack of movement smoothing for enemies makes things kind of a mess, and the shadow bats cause a gigantic flood of error messages (but otherwise seem to work properly until I kill them...which is not a good time with them spazzing all over the place with jittery movement), but nothing seems horribly broken running it this way.

Edit: Oh, the other thing is I'm really not sure how in the world I'm going to handle updates.  That's going to be a giant pain.  I suppose for the time being just do it on my desktop and then copy the files manually, but there has to be a better way.

[Toll]

I don't know much (or anything) about server capabilities or Linux/Wine, but 100% sounds like a lot, given that the server runs at about 1-2% on my computer without anyone playing in it, and not too much higher when people are playing. That is, I suppose, 1-2% of the total capacity of my dualcore 3GHz processor, but it's still not a whole lot.

As for updates... Not sure how handy you are with code, but you might be able to toss something together with http://avww.s3.amazonaws.com/AVWWUpdatesList.xml? AFAIK, you can just unzip them to the game dir, and the update should be applied. I've been meaning to do something similar myself, but since I have access to the auto-updater in the "real" game, I haven't bothered with it much.

[Nalgas]

I don't know much (or anything) about server capabilities or Linux/Wine, but 100% sounds like a lot, given that the server runs at about 1-2% on my computer without anyone playing in it, and not too much higher when people are playing. That is, I suppose, 1-2% of the total capacity of my dualcore 3GHz processor, but it's still not a whole lot.

It's 100% of one virtual core, which is half a real core, but that's still more than it should be.  It doesn't seem to change at all based on actual usage, so I have a feeling it's something being stupid with all the virtualized crap going on attempting to emulate infinite loops as fast as possible...and display the output on a nonexistent screen using software rendering mode.  If anyone who uses Wine more often/less infrequently than I do has any bright ideas where to start poking at it, I'm up for suggestions.  I know some of you out there play have been playing AVWW and AI War through it for a while, only on proper hardware.

As for updates... Not sure how handy you are with code, but you might be able to toss something together with http://avww.s3.amazonaws.com/AVWWUpdatesList.xml? AFAIK, you can just unzip them to the game dir, and the update should be applied. I've been meaning to do something similar myself, but since I have access to the auto-updater in the "real" game, I haven't bothered with it much.

If all I have to do is grab those, pull the files out of them, and replace the existing ones, that's pretty trivial.  Should be easy enough to have it poll that for updates every now and then, grab them, kill the server, apply them, and restart it.  There's not really any way at the moment to broadcast a message to people who are playing that it's going to happen, but too bad for them.  They'll get over it.  Heh.

[keith.lamothe]

So I kind of disappeared for a while, but...it's me again!

And here I was thinking the amoebas got you!  Stay clear of that giant green one...

Thanks very much for sharing your linux server experiences, I've been wondering how that would do.  As far as the status window, in theory I could give you a command line option that would not try to load any graphics at all or show any gui at all, but I think that just the unity engine itself won't be satisfied without some kind of presentation layer that it recognizes.  Though apparently there is a -nographics command line that the unity player will recognize.  If you're feeling brave you might try that.

FYI, the status window won't remain useless; that's where things like "advertise this server", kick/ban, etc will go.

Very strange that it's burning up the cpu like that, as Toll says the server typically runs pretty light.

[x4000]

As for updates... Not sure how handy you are with code, but you might be able to toss something together with http://avww.s3.amazonaws.com/AVWWUpdatesList.xml? AFAIK, you can just unzip them to the game dir, and the update should be applied. I've been meaning to do something similar myself, but since I have access to the auto-updater in the "real" game, I haven't bothered with it much.

If all I have to do is grab those, pull the files out of them, and replace the existing ones, that's pretty trivial.  Should be easy enough to have it poll that for updates every now and then, grab them, kill the server, apply them, and restart it.  There's not really any way at the moment to broadcast a message to people who are playing that it's going to happen, but too bad for them.  They'll get over it.  Heh.

Just to add: yes, that's all there is to those.  You look at whatever the current version of the game is, download any zip files you don't already have based on that, and then unzip them in sequence (overwriting each time) into the game folder.

[Mánagarmr]

I suppose for a pure CLI-type server, you'd have to create a Linux-compatible release, yes? Since it has to have the Windows API, you have to have Wine, and thus you have to have a GUI running. It would be kicking to have this running on my headless archlinux CLI server, but I don't see that happening

[x4000]

Right, that would involve creating a version of the game that doesn't use unity.  Aka, not going to happen in that fashion.  But having command-line parameters is feasible, and potentially even having some remote server admin through game clients on other machines, too.  We'll see.

[Toll]

Adding the ability to use stdin/stdout would make a world of difference, really. Being able to send commands to the server through stdin (chat messages, safe shutdown, etc) and sending information through stdout (players entering/leaving, chat messages, etc) would enable the programmers among us to make all kinds of nice things (such as an auto-updater that warns players that the server will shut down, and instead of killing the process, you'd be able to safely shut it down to minimise the risk of data corruption). It would also make it possible to create remote-controls for servers. Not sure how plausible that is using Unity though.

[x4000]

I'm not sure either, on that.  I don't think it's possible, but I could be wrong.

[Nalgas]

So I kind of disappeared for a while, but...it's me again!

And here I was thinking the amoebas got you!  Stay clear of that giant green one...

Oh great.  They come in green now?  I wonder what else I've missed...

Really my ADD meds and my seizure meds got in a fight.  I'm not sure who won, but I know I lost.  So did my laptop, when I managed to spill two glasses of water into it in the process.  Oops.

Thanks very much for sharing your linux server experiences, I've been wondering how that would do.  As far as the status window, in theory I could give you a command line option that would not try to load any graphics at all or show any gui at all, but I think that just the unity engine itself won't be satisfied without some kind of presentation layer that it recognizes.  Though apparently there is a -nographics command line that the unity player will recognize.  If you're feeling brave you might try that.

FYI, the status window won't remain useless; that's where things like "advertise this server", kick/ban, etc will go.

Very strange that it's burning up the cpu like that, as Toll says the server typically runs pretty light.

I tried throwing -nographics at it, and there was no change.  After trying it on my Windows desktop where I can actually see the results instead of monitoring side effecfs, I'm not surprised; it doesn't do anything.

And I don't mean that the window is necessarily useless for everyone, just that it's completely pointless in my situation, because it's just dumping it into nothingness where no one will ever see it, wasting a bunch of effort to translate D3D calls into OpenGL calls that have to be handled entirely in software just so it can display a bunch of nothing that no one can see.

Just to add: yes, that's all there is to those.  You look at whatever the current version of the game is, download any zip files you don't already have based on that, and then unzip them in sequence (overwriting each time) into the game folder.

What is the proper way to check the current installed version of the game?  If there's somewhere easy to read that from, and if there were some way to check if there are people connected to the server, even if it just wrote it to a file that it updated when it changes, auto-updating when no one's playing (and thus when it's guaranteed to not have chunks open for writing) should be simple enough.

I suppose for a pure CLI-type server, you'd have to create a Linux-compatible release, yes? Since it has to have the Windows API, you have to have Wine, and thus you have to have a GUI running. It would be kicking to have this running on my headless archlinux CLI server, but I don't see that happening

Well, if you look at how I did it, it is possible.  My server is headless.  It's a 2U colo box I share with a few friends.  If you don't mind installing and running a bunch of stuff on it that's completely unnecessary for everything else you do with your server, it will at least work.  Xvfb lets you basically have a non-GUI GUI without any graphics hardware or input devices or anything.  It just fakes it all for the sake of things that demand it.  As far as Wine and AVWW are concerned, they have an 800x600 screen to draw to, but it's really just a small chunk of RAM.  I'm not running anything else on top of that, just the bare minimum to trick them into thinking the hardware is there.  It gets a little annoyed when it starts up and can't properly configure the sound or input devices, but it gets over it.  Heh.

[x4000]

At the moment the version of the game is compiled into the game's DLL, and isn't found anywhere else.  However, we could write that to some file -- as well as the number of connected players whenever that changes, for that matter.  If you want to make a mantis issue with the things you'd need, we should be able to put those in sometime prior to 1.0 (knock on wood, and assuming they aren't too hefty -- the ones you just mentioned are not).