Homegrown Dedicated Server: DedCon 1.6.0_svn1038

Discuss your new mods and themes here

Moderator: Defcon moderators

User avatar
bert_the_turtle
level5
level5
Posts: 4795
Joined: Fri Oct 13, 2006 6:11 pm
Location: Cologne
Contact:

Postby bert_the_turtle » Sun Jun 10, 2007 2:25 pm

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.
User avatar
Smiling Buddha
level3
level3
Posts: 263
Joined: Fri Apr 20, 2007 7:35 pm
Location: Omnipresent Occupation: Supreme Buddha

Postby Smiling Buddha » Sun Jun 10, 2007 4:24 pm

bert_the_turtle wrote: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
level2
level2
Posts: 162
Joined: Thu Sep 28, 2006 9:25 pm
Location: Canada

Postby kentuckyfried » Mon Jun 11, 2007 4:02 am

Bert, he's the ONE!
User avatar
bert_the_turtle
level5
level5
Posts: 4795
Joined: Fri Oct 13, 2006 6:11 pm
Location: Cologne
Contact:

Postby bert_the_turtle » Mon Jun 11, 2007 10:25 pm

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.
User avatar
Ace Rimmer
level5
level5
Posts: 10803
Joined: Thu Dec 07, 2006 9:46 pm
Location: The Multiverse

Postby Ace Rimmer » Mon Jun 11, 2007 10:34 pm

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.
Smoke me a kipper, I'll be back for breakfast...
Sirthomasthegreat
level3
level3
Posts: 466
Joined: Fri Oct 13, 2006 12:18 am

Postby Sirthomasthegreat » Mon Jun 11, 2007 11:24 pm

Could you do one in a zip format instead of tar since I used to run linux but now am only on windows.
User avatar
bert_the_turtle
level5
level5
Posts: 4795
Joined: Fri Oct 13, 2006 6:11 pm
Location: Cologne
Contact:

Postby bert_the_turtle » Mon Jun 11, 2007 11:56 pm

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.
User avatar
Ace Rimmer
level5
level5
Posts: 10803
Joined: Thu Dec 07, 2006 9:46 pm
Location: The Multiverse

Postby Ace Rimmer » Tue Jun 12, 2007 12:04 am

Sure!
Smoke me a kipper, I'll be back for breakfast...
User avatar
Smiling Buddha
level3
level3
Posts: 263
Joined: Fri Apr 20, 2007 7:35 pm
Location: Omnipresent Occupation: Supreme Buddha

Postby Smiling Buddha » Tue Jun 12, 2007 12:45 am

bert_the_turtle wrote:/ping


What's this do?
User avatar
shinygerbil
level5
level5
Posts: 4667
Joined: Wed Dec 22, 2004 10:14 pm
Location: Out, finding my own food. Also, doing the shinyBonsai Manoeuvre(tm)
Contact:

Postby shinygerbil » Tue Jun 12, 2007 1:24 am

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
Here is my signature. Make of it what you will.
Image
User avatar
xander
level5
level5
Posts: 16869
Joined: Thu Oct 21, 2004 11:41 pm
Location: Highland, CA, USA
Contact:

Postby xander » Tue Jun 12, 2007 1:25 am

Smiling Buddha wrote:
bert_the_turtle wrote:/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
User avatar
Ace Rimmer
level5
level5
Posts: 10803
Joined: Thu Dec 07, 2006 9:46 pm
Location: The Multiverse

Postby Ace Rimmer » Tue Jun 12, 2007 2:02 am

bert_the_turtle wrote: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.

Image

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.
User avatar
xander
level5
level5
Posts: 16869
Joined: Thu Oct 21, 2004 11:41 pm
Location: Highland, CA, USA
Contact:

Postby xander » Tue Jun 12, 2007 2:06 am

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
User avatar
bert_the_turtle
level5
level5
Posts: 4795
Joined: Fri Oct 13, 2006 6:11 pm
Location: Cologne
Contact:

Postby bert_the_turtle » Tue Jun 12, 2007 7:35 am

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.

Ace Rimmer wrote: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.
User avatar
Ace Rimmer
level5
level5
Posts: 10803
Joined: Thu Dec 07, 2006 9:46 pm
Location: The Multiverse

Postby Ace Rimmer » Tue Jun 12, 2007 9:29 am

I figured that part might be intentional but wasn't sure.
Smoke me a kipper, I'll be back for breakfast...

Return to “Mod Projects”

Who is online

Users browsing this forum: No registered users and 1 guest