Sauerbraten engine development

by Aardappel on 03/03/2004 05:18, 1571 messages, last message: 03/14/2008 18:53, 1700827 views, last view: 05/18/2024 21:30

This thread is for discussion of Sauerbraten coding issues / implementation ideas etc.

   Board Index   

#1512: ..

by virtualblackfox on 06/20/2006 13:20

Ok after some test kicking someone in capture make the server crash everytime it seem :D

reply to this message

#1513: another crash

by absinth on 06/20/2006 13:29

Thread 0 Crashed:
0 libSystem.B.dylib 0x900037a8 szone_malloc + 240
1 libSystem.B.dylib 0x90003380 malloc + 632
2 sauerbraten 0x0004099c enet_malloc + 32 (callbacks.c:36)
3 sauerbraten 0x000413b0 enet_packet_create + 64 (packet.c:30)
4 sauerbraten 0x00043ad8 enet_host_service + 2580 (protocol.c:431)
5 sauerbraten 0x00004d30 gets2c() + 624 (client.cpp:191)
6 sauerbraten 0x000718fc fpsclient::updateworld(vec&, int, int) + 5844 (fps.cpp:184)

reply to this message

#1514: Re: ..

by Passa on 06/20/2006 13:49, refers to #1512

Yeah its a bug with the current release. Server crashes, that is.

reply to this message

#1515: Re: Server crash

by xoltra on 06/21/2006 06:22, refers to #1505

I've had problems with the same IP address (cheating via modified weapons and using my nick). He's figured out a way to defeat /kick, but he's now permanently firewalled out of my server.

reply to this message

#1516: Re: Server crash

by Passa on 06/21/2006 06:29, refers to #1515

How did he defeat kick? I was under the impression he was a total n00b, I think he is using that downloadable hack.

What firewall did you use to block him? I can't find a way to block him using my Sygate firewall.

reply to this message

#1517: Re: Server crash

by xoltra on 06/22/2006 08:07, refers to #1516

I may be wrong about him defeating kick. Previously when I ran into him and I was master I thought kicking him by clientnum did nothing, but I may be confused. Or he may have been logged in with multiple clients. Or whatever.

Later I came across him again on another server and asked him how he defeated /kick. He said he hadn't, but he'd try. I don't see any obvious problems with the code (putting the client in a list of banned IPs and enet disconnecting it). So I wouldn't worry about it.

I don't know if he downloaded something, or he just figured it out by looking at the code. Adjusting weapon characteristics is pretty straightforward (no need to go into detail).

Since I'm running Linux I use iptables, which is the CLI interface to the firewall that comes with the OS. So, in my /etc/sysconfig/iptables I added
-A RH-Firewall-1-INPUT -j REJECT -s AA.BB.CC.DD --reject-with icmp-host-prohibited
just before the lines that allow the stuff into the Sauerbraten ports. Note that I hid his IP address since this forum may not like that.

I think you run the server in Australia and you also added a message of the day to your server. Maybe we can compare notes since I did the same to mine. You can find my patch at the bottom of my Sauerbraten page:
http://home.austin.rr.com/selliott4/sauerbraten

reply to this message

#1518: Re: Server crash

by xoltra on 06/22/2006 08:13, refers to #1517

As far as you know you did the MOTD thing first. Just wanted to clarify that it wasn't my idea.

reply to this message

#1519: Re: Server crash

by Passa on 06/22/2006 08:21, refers to #1517

Yup my server is run in Australia, obviously by it reprinting the message like 50 times everytime someone joins :P

Problem is that it prints it everytime someone joins, for each player, so if I have 10 people connected, and an 11th joins, it prints it 11 times.

Oh and on my MOTD, its actually one line of code. And that line of code wasn't even by me, it was by dbox, I just figured out where to put it. I aint a coder :P

eihrul: could you possibly add xoltra's new patch to the next release? I like the idea of it dumping the console output to a file. Plus it includes hostname details for each player. And the MOTD support looks solid. Nice stuff xoltra.

reply to this message

#1520: Re: Server crash

by xoltra on 06/22/2006 08:54, refers to #1518

I meant as far as *I* know. Ok, I think I've got it (finally).

reply to this message

#1521: Re: Server crash

by xoltra on 06/22/2006 09:06, refers to #1519

Thanks for the positive feedback on my patch. It could use some work to make it more consistent with the other sauer code. The MOTD stuff could be more object oriented (I just did everything there). And I dunno if its reentrant enough with the static vars.

Also, I just added the timestamp to a few of the lines a I added. There should probably be a logging API that prepends a timestamp to every line.

I'm just redirecting the output of the server with 2>& | tee -a log_file. It might be nice if the server just wrote to a log file by default.

If nothing else this line:
setvbuf(stdout, (char *)NULL, _IOLBF, 0);
would be great to have in CVS. It just makes the output of the server line buffered so it can be redirected to a file. It should not be very demanding at all (a line every now and then).

reply to this message

#1522: Re: Server crash

by rpointon on 06/22/2006 09:51, refers to #1521

Classic unix - redirect via (or fork within) a psuedo-terminal and then you wont need to change the server source. Google for 'pty program'...

reply to this message

#1523: Re: Server crash

by xoltra on 06/22/2006 16:02, refers to #1522

That is true. stdout is line buffered when writing to a terminal and block buffered when writing to an ordinary file. But adding the one line I suggested should easier, and a pretty safe change.

reply to this message

#1524: Making SV_POS updates more scalable

by xoltra on 06/23/2006 08:45

Unless I'm misunderstanding the code the position of clients update each other with their current position by:
1) The client sending an SV_POS event with, among other things, the XYZ coordinates of the client at most 30 times per second.
2) The server echoing the packet to each client.
The total bandwidth required is roughly proportional to the square of the number of clients. I believe SV_POS messages make up a majority of the bandwidth during normal game play.

Have you considered determining which clients are visible to which other clients and only sending SV_POS to clients if it makes a visible change for that client? This may not be too hard to do because you probably already have logic that each time a frame is rendered determines whether each client is occluded (not visible). Perhaps each client could send a bitmask of the clients visible to it based on the occlusion calculations to the server. The bitmask would be only be sent each time of the bits change (another client becomes visible or not). One way of implementing this would be to have a global boolean that would indicate if any the occlude status of any dynent has changed since the last frame. When the frame is rendered if any of the dynents iterated through changed in occlude status the boolean would be set, and the bitmast would be sent to the server.

The server would would consider bitmask each time a SV_POS was received so that it would only be multicast to the clients that could see the change.

reply to this message

#1525: Re: Making SV_POS updates more scalable

by Aardappel_ on 06/23/2006 10:13, refers to #1524

yup thats a well known technique. Thing is, we have very small games sofar, and the problem with visibility testing is popping (if someone has 200msec lag, you'd ideally have to take into acount if both you and he can move with 200msec such that you become visible. That's an estimate at best).

reply to this message

#1526: ..

by Pxtl on 06/23/2006 13:53

So does anybody have hints on getting Sauer to compile in the Visual Studio free edition? I'm still getting missing symbols from the Windows SDK. What version of Windows SDK to use?

reply to this message

#1527: Re: Making SV_POS updates more scalable

by xoltra on 06/24/2006 07:10, refers to #1525

Thanks for explaining that. I'm glad it has been considered. It's probably stuff you've been over.

That being said, maybe a variation of the idea would work. Maybe there could be a maximum update rate for clients that aren't visible, possibly 10 per second. That way instead "popping" clients would just have rough, jerky motion when coming into view when there was lag.

Maybe the original idea could be applied only to clients that have a relatively low ping since the concern in that the server's list of who can see what is out -of-date by an amount no greater than the ping to that client.

And finally, a slightly different, but related idea, is adjusting the SV_POS update rate when the server gets lagged out. Maybe instead of using enet's bandwidth control, which I guess queues the packet and introduces lag, the rate of SV_POS updates could be reduced.

reply to this message

#1528: Players' lack of technical understanding

by xoltra on 06/24/2006 08:35

Having played quite a bit and having run a logging server for a few days its become even clearer to me that Sauerbraten would be benefit if players understood it better. For example, my server seems to get a bit lagy with more than 4-5 players. In spite of my adding a MOTD message explaining that the master should us /mastermode 0 and /mastermode 3 to regulate the number of players. In spite of that I'm lucky if one master in a day correctly uses /mastermode, and pings sometime reach the 1000s due to too many people. Admittedly my MOTD is easy to miss, but you'd think some people would see it and tell others what to do.

I could use the -u switch to set the upload rate, but I'm not sure what the best value is. And I hoped people could figure it dynamically given that the bandwidth available may very.

Sometimes when the map does not advance (why did that go away?) people will play it over and over again. Although using /mastermode >= 1 to force maps is questionable it seems to me a reasonable time to do so is between games to change to another map if a majority of the players are either unable (don't know how) or unwilling to vote.

Other confusion includes coop mode where most players don't seem to understand /sendmap and /getmap (which admittedly rumor has it is going to be replaced with some sort of checksum scheme). The new players play with the original map and the old players play with modified map. Much of the time the modified map is wiped out by someone turning the grid size all the way up and deleting most of the cubes.

And then there are inappropriate modes/map combinations. When people do vote they vote for single player maps an amazing fraction of the time. It's not too uncommon to see people blowing each other away over and over again at the single playerstart, which gets old pretty fast.

I don't know if there are any easy answers to this. Maybe there could be additional warning, prompts or instructions. Maybe some text along the lines of "You are now the master! Here are your responsibilities ...". When the map does not have a next map and then the end of the game is reached perhaps the master could be prompted with "Would you like to pick a new map now? Use the menu or ..."
Each mode requires a minimum number of various entity types. Capture mode requires bases. Ffa mode requires (just about) ammo. All multi-player mode require more than one playerstart. When that requirement is not met a warning could be displayed.

Maybe entering coop mode could include mini-tutorial on using /sendmap and /getmap, including the benefit of having a designated map keeper who has the definitive copy (master seems like a natural fit since he can force reverts). The map keeper would periodically /savemap good maps to disk so that bad edits could be reverted with (force) vote and /sendmap.

Anyway, you may be thinking about this stuff as it is, but I just wanted to relay how much confusion there is, and some possible ways of addressing it.

reply to this message

#1529: please :(

by quake2 on 06/24/2006 12:42

@ xoltra:
Btw Maprotation is done clientside, so if the picked person (by the server) doesn\\\'t have a \\\"correct\\\" release.
The last version HAD a bug
in a cfg.

@ everyone:
Why can\\\'t people just use this game as it is.
You always demand more features and haven\\\'t even understood the existing.
Why do now everyone sets up modified servers?
Why does everyone think he knows it better than the people who game us this great game?

Just take what is there have some fun and don\\\'t even think about being able to make it better.
You can\\\'t!

If people don\\\'t read the manual it\\\'s their problem. Not yours.
If they cheat it\\\'s not their problem. Not yours.
There is a function in this game for every problem.

This game was meant to be fun. But it seems most people don\\\'t understand this.
If you want a \\\"perfect\\\" game search somewhere else.
This game here is mostly played by people who just downloaded it. That\\\'s why they don\\\'t really understand (yet).

And please don\\\'t complain about the code. It worked for many years now.

There is no need to change it now only to get some smaller packets in a netgame.
For me it seems some people only spam the forum with \\\"new\\\" ideas because they hope to get their signature into the game.

It\\\'s not your game. Be glad you can use it. Be glad you can look into the source and learn something. Be glad you can set up a server and help the community.

Please read the manual. Read the developer nodes. Read the first posts on this forum and you will understand what this is all about.
Do this before you even think about makeing suggestions.

Take the game as it is or leave it.
Thank you.

reply to this message

#1530: Re: Making SV_POS updates more scalable

by guest57 on 06/24/2006 13:08, refers to #1527

When there are too many people then the lag increases - therefore people give up, and then the lag reduces.

Multiplayer seems to work fine up to at least 8 players, maybe 12 on a good server/connection - thats plenty fun, any more players and you'd get lost in the crowd...

reply to this message

#1531: Re: Players' lack of technical understanding

by eihrul on 06/24/2006 16:56, refers to #1528

I went the opposite direction by adding a -c (maxclients) option for the server.

As for mastermode, we've made it a bit trickier for random newbies to get master.

reply to this message

   Board Index