0.2.8 (beta 3 tagged)
I've added a slight random variation in packet resending strategies. While I was at it, I added detection of and compensation for packet loss (by sending packets twice without waiting for them to get lost) and a preference to pack resent messages together with regular first time packets. This should increase the data variation, no two packets should be the same any more. Let's see if this fixes the timeouts. I've updated the fortress server to that codebase.
I just played it back using a build just compiled, and the bug is not reproduced. So it is fixed.z-man wrote:Thanks! Yes, the problem plays back fine on beta2 (meaning the bug is visible). I'll have a closer look at it tomorrow.
Update: It plays back fine in current CVS, too. The other fine, the one that says "bug fixed". Can anyone verify this? Please see nemo's link for bug report details.
I just got a recording of the "User 0 timed out" bug. Attached is the server recording + client recording.
Edit: http://sourceforge.net/tracker/index.ph ... tid=657948
Server was compiled today, so everything is recent.
Edit: http://sourceforge.net/tracker/index.ph ... tid=657948
Server was compiled today, so everything is recent.
- Attachments
-
- 2005-10-20_15-28_client.rec.bz2
- (99.36 KiB) Downloaded 89 times
-
- 2005-10-20_15-28_server.rec.bz2
- (58.7 KiB) Downloaded 115 times
Here is the /team code, right now it just messages your team, but I will add in messaging other teams (partially done, commented out that code).
- Attachments
-
- team.diff.bz2
- (1.53 KiB) Downloaded 89 times
Thanks. I'll have a look at it ASAP, probably tomorrow.
While we're talking about tomorrow: tomorrow was the planned date to tag beta3. However, there's a couple of bugs left; some are mysterious (so a beta may help resolve them, but I'm not putting my hopes up too high), but most require just a bunch of work. I'd say they don't hurt the beta: only one is new (the strange lag Lucifer mentioned), and that one is mysterious. Are there objections to just going ahead?
Philippe: now would be a good time to remove the <Resources> tag if you want to.
While we're talking about tomorrow: tomorrow was the planned date to tag beta3. However, there's a couple of bugs left; some are mysterious (so a beta may help resolve them, but I'm not putting my hopes up too high), but most require just a bunch of work. I'd say they don't hurt the beta: only one is new (the strange lag Lucifer mentioned), and that one is mysterious. Are there objections to just going ahead?
Philippe: now would be a good time to remove the <Resources> tag if you want to.
Since I could not properly wrap my head around my own problems, I did it now. Good work! One small bug, you checked for se_chatRelay.Supported( clientID ) twice, the first one should have been for se_chatHandlerClient.z-man wrote:Thanks. I'll have a look at it ASAP, probably tomorrow.
I'm getting the stong feeling that the special chat commands would be another area of heavy refactoring, but that can wait until we drop support for clients that only understand the old-style chat messages. It'll be easier then.
- Lucifer
- Project Developer
- Posts: 8640
- Joined: Sun Aug 15, 2004 3:32 pm
- Location: Republic of Texas
- Contact:
Um, didn't you "fix" the lag bug, and we're just waiting to test it? Or did I slip into another parallel universe and am now hopelessly far from my home universe?
As for beta3, sure. I'm fine with that. It would be nice if you'd, you know, throw in a few gratuitous lines of code just so I'll feel like work got done between me rebuilding my server with cvs code and the beta.....
(actually, I'd like to hurry up and build a Mandriva package for it and see if I can't get one of these other nice server admins running Mandriva to give it a run, beta3 should be pretty sturdy, right?)
As for beta3, sure. I'm fine with that. It would be nice if you'd, you know, throw in a few gratuitous lines of code just so I'll feel like work got done between me rebuilding my server with cvs code and the beta.....
(actually, I'd like to hurry up and build a Mandriva package for it and see if I can't get one of these other nice server admins running Mandriva to give it a run, beta3 should be pretty sturdy, right?)
Lucifer, I have it planned out when i'm going to switch to Mandriva.. After christmas when i get my new computer, i'm gonna install Mandriva on it in the beggining.. then i'd be happy to test your packages.. but we still got a couple months til then -_-.
EDIT: And what are resource tags? The 0.2.8_beta2 name?
EDIT: And what are resource tags? The 0.2.8_beta2 name?
Damn, it sure has been a while!
- philippeqc
- Long Poster - Project Developer - Sage
- Posts: 1526
- Joined: Mon Jul 12, 2004 8:55 am
- Location: Stockholm
- Contact:
<Resources> tag removed.
I realise we have 2 map-format-version in the map.
-one is the dtd file itself,
-one is the <Map version="???">. (not to be confused with the resource version, which tracks change in the details)
The purpose of map version was to say "this should be parsed according to rules defined at version x", but this gets implied of sort by the dtd.
We could require ppl to write the same version as the one defined in the dtd. It would seem pointless for a while, but should we make a change to the parser without changing the dtd, then the <Map version="x"> would be usefull to say according to which parser rule to operate. What do you think?
Another version question! Will they ever end?
-ph
I realise we have 2 map-format-version in the map.
-one is the dtd file itself,
-one is the <Map version="???">. (not to be confused with the resource version, which tracks change in the details)
The purpose of map version was to say "this should be parsed according to rules defined at version x", but this gets implied of sort by the dtd.
We could require ppl to write the same version as the one defined in the dtd. It would seem pointless for a while, but should we make a change to the parser without changing the dtd, then the <Map version="x"> would be usefull to say according to which parser rule to operate. What do you think?
Another version question! Will they ever end?
-ph
Canis meus id comedit.
Last I remember, all the conversation about it was:Lucifer wrote:Um, didn't you "fix" the lag bug, and we're just waiting to test it? Or did I slip into another parallel universe and am now hopelessly far from my home universe?
Lucifer: Strange lag!
Z-Man: Strange...(giving theory of what recent code change may be causing it)
So maybe now is a good time to ask further questions (I may have already asked them, but forgot):
Does the lag happen when connecting with a beta2 client or 0.2.7.1?
What is the exact nature of the lag? There are two variants I currently know of: at the beginning of a round, your turn commands are executed late, so if you turn right at the start, you lag slide badly (this is caused by the timer sync not working properly then, because ping estimates are grossly wrong). And, playing the Fortress yesterday, I had one HUGE lag spike (The lagometers filling half the screen) that threw the game off longer than it should have.
I want to make the fortress zones spin faster as they get conquered, what is already in CVS is nemo's team chat code, and (not of terrible interest to you) you can now force the teams to be named after colors, not players (and vice versa).Lucifer wrote:As for beta3, sure. I'm fine with that. It would be nice if you'd, you know, throw in a few gratuitous lines of code just so I'll feel like work got done between me rebuilding my server with cvs code and the beta.....
In the sense that it does not crash easily, certainly. The test server was running the past week under extremely heavy load without going down. There have been a few unspecific BUG cries, though.Lucifer wrote:(beta3 should be pretty sturdy, right?)
Small syntax change for team messages.
Code: Select all
foo --> Teammates: some message here
foo (Red Team) --> Blue Team: some message here // Not used yet
( foo --> Teammates ) some message here
( foo (Blue Team) --> Red Team ) some message
- Attachments
-
- team_message_syntax_change.diff.bz2
- (1006 Bytes) Downloaded 105 times