Test servers moving to my home server
Moderator: Z-Man
Test servers moving to my home server
Several things happened nearly at once.
1. Last week, I had a really unpleasant experience on Bugfarm Fortress. I was coaching a new player, he already had learned to grind at start and not to kill teammates. Nevertheless, despite my request, he was kickvoted. I don't want to start banning players because that's work and awkward and leads to hate mail I have to dispose of, I can't set a remote admin password for moderators and I can't be there 24/7 (not even close) to moderate it myself.
2. Yesterday, my servers were shut down by one of the usual admin activities, and I can't bring them up until the admin gives me back the partition the servers live on.
3. My bandwidth upgrade was activated today, so now I can host a server for more than 4 people at home, provided the server's CPU is up to it. I'll experiment a bit more with compiler settings, the problem is that I want to be able to debug recordings, so the server essentially has to run debuggable code, which means unoptimized code, which is deadly for C++ performance. Perhaps inlining stuff suffices.
On top of all that, running private game servers on the university's infrastructure is stealing and it felt wrong from day one.
So prepare for one or two new Bugfarm servers to pop up, and the old ones to stay down. The bandwidth is enough for 16 players a 4 KByte/s, which seems to be just enough for cycle_delay .1 gameplay most of the time. I don't know yet whether I'll make a new fortress server, there are really enough clones out there by now. I could do config rotation or switching configs by player count; make it sumo until eight players are there and switch back to sumo when the player count drops below four or six. Maybe I'll just keep the deathmatch server. I'm mainly concerned with core gameplay bugs right now, so whatever it is I'm going to do, it'll probably be pretty constant over time so you can know what to expect. Whenever I'm not doing one of my evil experiments, of course.
Anyway, one change will be possible: I can now allow remote admins. It's my own machine, nothing fundamentally important is on it, the server is running as a safe user without write access anywhere. So, in case the new stuff gets popular again (probably not until new crazy shit is implemented and tested there, like CTF zones, flying saucers and lasers), we can have moderators that keep the atmosphere friendly.
Z-Man's Tournament Server, running on my work PC as well, will be down most of the time, too. I'll bring it up during tournament time (provided I get informed) and try to administer it then. That's still theft, but only a little bit.
1. Last week, I had a really unpleasant experience on Bugfarm Fortress. I was coaching a new player, he already had learned to grind at start and not to kill teammates. Nevertheless, despite my request, he was kickvoted. I don't want to start banning players because that's work and awkward and leads to hate mail I have to dispose of, I can't set a remote admin password for moderators and I can't be there 24/7 (not even close) to moderate it myself.
2. Yesterday, my servers were shut down by one of the usual admin activities, and I can't bring them up until the admin gives me back the partition the servers live on.
3. My bandwidth upgrade was activated today, so now I can host a server for more than 4 people at home, provided the server's CPU is up to it. I'll experiment a bit more with compiler settings, the problem is that I want to be able to debug recordings, so the server essentially has to run debuggable code, which means unoptimized code, which is deadly for C++ performance. Perhaps inlining stuff suffices.
On top of all that, running private game servers on the university's infrastructure is stealing and it felt wrong from day one.
So prepare for one or two new Bugfarm servers to pop up, and the old ones to stay down. The bandwidth is enough for 16 players a 4 KByte/s, which seems to be just enough for cycle_delay .1 gameplay most of the time. I don't know yet whether I'll make a new fortress server, there are really enough clones out there by now. I could do config rotation or switching configs by player count; make it sumo until eight players are there and switch back to sumo when the player count drops below four or six. Maybe I'll just keep the deathmatch server. I'm mainly concerned with core gameplay bugs right now, so whatever it is I'm going to do, it'll probably be pretty constant over time so you can know what to expect. Whenever I'm not doing one of my evil experiments, of course.
Anyway, one change will be possible: I can now allow remote admins. It's my own machine, nothing fundamentally important is on it, the server is running as a safe user without write access anywhere. So, in case the new stuff gets popular again (probably not until new crazy shit is implemented and tested there, like CTF zones, flying saucers and lasers), we can have moderators that keep the atmosphere friendly.
Z-Man's Tournament Server, running on my work PC as well, will be down most of the time, too. I'll bring it up during tournament time (provided I get informed) and try to administer it then. That's still theft, but only a little bit.
Here's what I've come up with:
A Sumo/Fortress hybrid server. There are not many things that are more depressing than a fortress server with three players on, so this one starts off in sumo mode (I don't know why the AI isn't behaving as on old sumo, it's only going straight, I'll investigate this). When six or more players are online, it switches to fortress mode. When less then four players (which is what I consider the minimum fun fortress setup) are there, it goes back to sumo. Note the hysteresis here, the server won't switch while four or five players are there. This should avoid excessive switching.
Sumo mode should work like on old bugfarm. Fortress mode has two modifications; you join a team again immediately, and the spawn formation is widened. The goal here is to take away importance of the startup, which, after all, is only ten seconds of a round that lasts several minutes, and causes an unjustifyable amout of pain for new players. I'll play with that a bit, so expect change.
My deathmatch server is down until I find a way to limit the sum of the player counts on both servers.
The remote admim password is the same as for the deathmatch servers; I posted that a while ago in the developers only section. You can switch between sumo and fortress mode with "include sumo.cfg" resp. "include fortress.cfg". The switching script won't override that for a while.
The server is named "Bugfarm Fortress Training" resp. "Bugfarm Fortress Training (Sumo Mode)".
Please tell me when you have evidence that the network settings are too permissive and the server can't handle the load that gets put onto it.
A Sumo/Fortress hybrid server. There are not many things that are more depressing than a fortress server with three players on, so this one starts off in sumo mode (I don't know why the AI isn't behaving as on old sumo, it's only going straight, I'll investigate this). When six or more players are online, it switches to fortress mode. When less then four players (which is what I consider the minimum fun fortress setup) are there, it goes back to sumo. Note the hysteresis here, the server won't switch while four or five players are there. This should avoid excessive switching.
Sumo mode should work like on old bugfarm. Fortress mode has two modifications; you join a team again immediately, and the spawn formation is widened. The goal here is to take away importance of the startup, which, after all, is only ten seconds of a round that lasts several minutes, and causes an unjustifyable amout of pain for new players. I'll play with that a bit, so expect change.
My deathmatch server is down until I find a way to limit the sum of the player counts on both servers.
The remote admim password is the same as for the deathmatch servers; I posted that a while ago in the developers only section. You can switch between sumo and fortress mode with "include sumo.cfg" resp. "include fortress.cfg". The switching script won't override that for a while.
The server is named "Bugfarm Fortress Training" resp. "Bugfarm Fortress Training (Sumo Mode)".
Please tell me when you have evidence that the network settings are too permissive and the server can't handle the load that gets put onto it.
- Tank Program
- Forum & Project Admin, PhD
- Posts: 6711
- Joined: Thu Dec 18, 2003 7:03 pm
Pentium MMX 266 Mhz
Tuning the compiler only turned out to give a 20% performance increase, but gives rise to the risk that recordings can't be played back properly. So I set out to do some profiling and optimizing and found something to do The network code was eating up far too much. It's called too often and does redundant work. I fixed that. The server is down now, because there was one undesired side effect, everywhere a living cycle was at the end of the last round, a nice explosion blossom was the next round (exploding only later). I'll get into this and another clientside bug (during chat/console input, no syncing takes place) tomorrow. It is advisable not to update from the 0.2.8 branch until then.
Tuning the compiler only turned out to give a 20% performance increase, but gives rise to the risk that recordings can't be played back properly. So I set out to do some profiling and optimizing and found something to do The network code was eating up far too much. It's called too often and does redundant work. I fixed that. The server is down now, because there was one undesired side effect, everywhere a living cycle was at the end of the last round, a nice explosion blossom was the next round (exploding only later). I'll get into this and another clientside bug (during chat/console input, no syncing takes place) tomorrow. It is advisable not to update from the 0.2.8 branch until then.
- Tank Program
- Forum & Project Admin, PhD
- Posts: 6711
- Joined: Thu Dec 18, 2003 7:03 pm
Too much time & money. But boy, what a use for a mechanical engineering degree...Jonathan wrote:Tank reminds me of something.
Gaa, the explosions are a clientside bug, at least, they're created client side. I've seen one of them before the current changes, but didn't mind too much. I think I mostly worked around them on the server (increasing GAME_TIMEOUT should help), but I'll have to give it another try on the client side. It's the same thing that causes the explosion sound at the end of a round in 0.3.0.
New twist: since single player mode in sumo was never all that exciting either, the server now starts in the good old last man standing game mode with three AIs. To make it a bit sumo-like, the arena is shrunklandish, and the spawn points are more off-center than usual. Of course, sumo starts as soon as the AIs are sent out.
Oh, well, not really as soon as. There's an unfortunate delay involved in counting the players and switching configurations. So be prepared to wait one or two extra rounds before any switch takes place.
Oh, well, not really as soon as. There's an unfortunate delay involved in counting the players and switching configurations. So be prepared to wait one or two extra rounds before any switch takes place.