Homegrown Dedicated Server: DedCon 1.6.0_svn1038

[bert_the_turtle]

There already is a kick system, and repeated kicks during a single session now first push the player to spectator mode and then keep him out of the server completely. A permanent ban-list with IPs and authentication key IDs (they get logged in debug.txt by regular Defcon) would be possible, too. I don't think adding people to it automatically from kicks would be a good idea. Moderation should be escalation based:
Defcon 5: politely ask the offending player to stop whatever is bugging you.
Defcon 4: politely ask again.
Defcon 3: tell the player that you have admin powers and that you can remove him if he keeps bugging. Formulate it as a threat if you want.
Defcon 2: kick the player. If he comes back for a vengeance, kick him again. And again.
Defcon 1: if you get to Defcon 2 with the same player repeatedly, ban him.
And of course, if possible, don't use your admin powers while you are actively playing. I've violated this rule myself, but probably will add a way to transfer admin powers to a selectedspectator for a single game and use that in the future.

A separate log file containing the kicks could be useful, that would make it easier to find repeated offenders and get to the data you need for the ban.

By the way, kicks during the game apparently were explicitly planned at one point by IV. When you kick someone from a DedCon server, the clients properly display "Bla kicked" where normally "Bla dropped" or "Bla disconnected" would be displayed.

[Smiling Buddha]

There already is a kick system, and repeated kicks during a single session now first push the player to spectator mode and then keep him out of the server completely. A permanent ban-list with IPs and authentication key IDs (they get logged in debug.txt by regular Defcon) would be possible, too. I don't think adding people to it automatically from kicks would be a good idea. Moderation should be escalation based:
Defcon 5: politely ask the offending player to stop whatever is bugging you.
Defcon 4: politely ask again.
Defcon 3: tell the player that you have admin powers and that you can remove him if he keeps bugging. Formulate it as a threat if you want.
Defcon 2: kick the player. If he comes back for a vengeance, kick him again. And again.
Defcon 1: if you get to Defcon 2 with the same player repeatedly, ban him.
And of course, if possible, don't use your admin powers while you are actively playing. I've violated this rule myself, but probably will add a way to transfer admin powers to a selectedspectator for a single game and use that in the future.

A separate log file containing the kicks could be useful, that would make it easier to find repeated offenders and get to the data you need for the ban.

By the way, kicks during the game apparently were explicitly planned at one point by IV. When you kick someone from a DedCon server, the clients properly display "Bla kicked" where normally "Bla dropped" or "Bla disconnected" would be displayed.

Excellent!

Can't wait.

[kentuckyfried]

Bert, he's the ONE!

[bert_the_turtle]

Test release 0.2 is online, changes since 0.1:
- Rejoining implemented
- NAT piercing implemented (please test, it never worked for me even with regular Defcon)
- Filtered out chat from connecting players
- Performance improvements with joining spectators
- Kick system improved, it now creates bans for the session
- Config file scripting: you can wait for events or just for some time
before executing the next command
- Added version compatibility interval
- Code is now Windows and Mac-compatible
- Many bugfixes, of course

Test release 0.3 is online, too Changes:
- added /help
- added /ignore and /unignore
- made /ping available for everyone, it's now sent secretly
- Compatibility with 1.0-1.3 resp. 1.4
- Fixed problems with stray messages from clients that are not logged in
- Players can no longer kick players
- Added /op and /deop commands

Yep, turns out the chat history does not enter the desync detection checksum. So, it's possible to selectively send chat messages to only those clients that want them.

[Ace Rimmer]

I'm not sure if this is helpful an any way, but Friday I tried to join a couple of games that were in progress and at times the "connecting" would simply stop, not move, wait a little while then keep going. This is odd for me as I either go forward or backwards when joining other games, it's never "stopped" mid connection then continued.

If not, just ignore me.

[Sirthomasthegreat]

Could you do one in a zip format instead of tar since I used to run linux but now am only on windows.

[bert_the_turtle]

Ace: thanks, that may be a hint that something with my chosen sending strategy is not completely right; I noticed already that at times, flow of new data just stops. Could you watch the network monitor (tools->network data) the next time? If during the initial syncing, the rectangles all go dark, the server is not sending data fast enough. If the client send rate is much lower than the client receive rate over longer times, then the server is sending data twice.

Sirthomas: I could put the linux distribution in a zip file, but that wouldn't help you all that much.

[Ace Rimmer]

Sure!

[Smiling Buddha]

/ping

What's this do?

[shinygerbil]

according to the readme:

/ping: Gives you a list of the connected clients, player names and pings, useful for /kickid

where /kickid kicks a player by ID#, in case they try changing nicks to avoid being kicked

[xander]

/ping

What's this do?

It basically pings all of the players, and tells you how long it takes for packets to get to them.

xander

[Ace Rimmer]

Ace: thanks, that may be a hint that something with my chosen sending strategy is not completely right; I noticed already that at times, flow of new data just stops. Could you watch the network monitor (tools->network data) the next time? If during the initial syncing, the rectangles all go dark, the server is not sending data fast enough. If the client send rate is much lower than the client receive rate over longer times, then the server is sending data twice.

I just tried it and (still connecting in fact) it didn't stop this time, but I noted there were "gaps" which I've never seen happen. I even managed to get a screen shot on the first try! It was (is) changing pretty quickly from normal 1-5, sometimes full, to 2-4 gaps and the rest green.



Also I've noticed that it takes extra long to "receive" the game but less than 10 seconds to "sync" whereas a normal game will take about even time with both, or just slightly less with the sync.

[xander]

client 1 (Peace and Love) : hi Ace
client 18 (Ace Rimmer) : hey
client 18 (Ace Rimmer) : xander bot the real xander?

Ace, you just joined a game that I am hosting. Unfortunately, my client version of Defcon pinged out. So I am not actually in the game, but I am monitoring it. Say "hi" to P&L for me. Also, you could always join us on IRC.

xander

[bert_the_turtle]

Thanks, Ace. I may have been misinterpreting the packet acknowledgement data the client sends back; it always sends two SeqIDs (the running number of each packet the server sends). The first one pretty certainly is the last packet the client was able to process, I'm only using that at the moment, so until your client is ready to process a packet (which takes time, it has to go through the queue of the 300 bright green dots you only see the first 10 of), I don't notice if it got lost. The other one, I though, was the last one the client knew about. I'll make some experiments, it may be the last SeqID received without gaps before it, or just a random SeqID of a received packet. Edit: it is the SeqID of the last packet received without gaps.

Also I've noticed that it takes extra long to "receive" the game but less than 10 seconds to "sync" whereas a normal game will take about even time with both, or just slightly less with the sync.

That's intentional. My server only sends data as fast as your client can process it, the client's queue of unprocessed packets is kept around 300 packets. The regular Defcon server sends data as fast as possible, so when your client has all the data, it has a long queue of packets to process left. The time it takes for sending is the "receive" time, the "sync" time is where the received packets are processed. If I get rid of the gap problems, the total time should be the same for both approaches, but mine takes less peak bandwidth and doesn't waste it when people decide to abort.

[Ace Rimmer]

I figured that part might be intentional but wasn't sure.