Sauerbraten engine development

by Aardappel on 03/03/2004 05:18, 1571 messages, last message: 03/14/2008 18:53, 1351256 views, last view: 12/09/2021 04:10

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

   Board Index   

#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

#1532: ..

by absinth on 06/24/2006 18:13

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

what about always making the player connecting from localhost master? i don't like it when random people become master on my server and having to restart the server and connect VERY quickly is a PITA

reply to this message

#1533: Re: ..

by Passa on 06/24/2006 18:25, refers to #1532

there is an rcon style password system coming in the next version. makes that idea obsolete

reply to this message

#1534: Re: please :(

by xoltra on 06/24/2006 18:40, refers to #1529

Perhaps much of this was triggered by my recent posts. If so I want to point out that Sauerbraten is a great game that I enjoy playing. If I didn't feel that way I wouldn't bother to post anything.

I post posts here in hopes that it will be helpful. If I get the impression that all of my suggestions were things that were thought of, but not feasible (such as my SV_POS suggestion) then I'll stop.

As to modified servers - people making changes and then posting patches back (like I did for the MOTD patch) is just a decentralized way of trying out ideas. The developers can then see what's popular, and consider committing the patches.

I understand that people are often new to the game and that's why they don't know stuff. I didn't mean to make fun of them. I just meant to explain that there are cases where their lack of understanding interferes with other people playing as well as some possible suggestions to address it.

Thanks for explaining the map rotation bug in the cfg file. And I look forward to trying eihrul's change to mastermode.

reply to this message

#1535: Re: please :(

by Passa on 06/24/2006 18:46, refers to #1534

Dont be disheartened xoltra, this guy has just missed the point of open source, thats all.

reply to this message

#1536: ..

by makkE on 06/24/2006 19:14

Nope he didnīt really miss the point, imho he has a point as well. Still suggestions are fine, and as you can see they are being heard, when they make sense. Itīs just that suggestions tend to differ in sense.

Really appreciate the new rcon stuff and maxclients, a good decision. Current mastermode is a good idea, still allowing the server masters to have their ways of controlling it is just fair imho.

reply to this message

#1537: Re: please :(

by Quin on 06/25/2006 06:21, refers to #1534

IMHO quake2 was out of line. It seemed to me more of an accusatory than any point being made.

Open source is your way of taking something you've found useful, and determining what you'd like fixed, doing it yourself, then seeing if the original community would like your patches. If it weren't for this fundamental, the FOSS community would die.

I say kudos to you xoltra, you knew what you wanted and you offered your work back to us as a whole.

reply to this message

   Board Index