0.2.8 (beta 3 tagged)
No, I don't mind. As for settings: It would be cool if you could set DEDICATED_FPS to 50 to keep it donw, the effect on gameplay would be minimal (everyone gains about 7 ms of ping), but the recording size would go down, as well as the risk of the recording not playing back because of floating point trouble. RECORDING_DEBUGLEVEL is almost irrelevant, leave it at 0.
I'll also try to run a real server overnight, while connecting to it and playing a bit.
I'll also try to run a real server overnight, while connecting to it and playing a bit.
- Tank Program
- Forum & Project Admin, PhD
- Posts: 6711
- Joined: Thu Dec 18, 2003 7:03 pm
Got that recording finally, took a lot longer with the lower dedicated fps... Uncompressed it weighs in at 47MB... But 5.4M compressed. http://electricpotential.net/temp/overn ... ec.tar.bz2
Thanks a lot! Downloading now...
Edit: This was done with beta2, right?
Edit2: Right. At least it plays back fine with it. Thanks!
This seems to be the same strange infinite trying-to-connect-to-master-server bug Lucifer mentioned in passing. I'll have a closer look at it tonight; it only plays back with optimizing enabled and still takes several minutes to get to the failure point.
Edit: This was done with beta2, right?
Edit2: Right. At least it plays back fine with it. Thanks!
This seems to be the same strange infinite trying-to-connect-to-master-server bug Lucifer mentioned in passing. I'll have a closer look at it tonight; it only plays back with optimizing enabled and still takes several minutes to get to the failure point.
OT, but why did you tar a single file?Tank Program wrote:Got that recording finally, took a lot longer with the lower dedicated fps... Uncompressed it weighs in at 47MB... But 5.4M compressed. http://electricpotential.net/temp/overn ... ec.tar.bz2
- Lucifer
- Project Developer
- Posts: 8640
- Joined: Sun Aug 15, 2004 3:32 pm
- Location: Republic of Texas
- Contact:
Heh, I don't know why he did it, but I usually do it because that way I don't have to remember the command line arguments for gzip, which are different than tar. Since I don't like to fill my head with useless crap, I've just learned tar -czvf and tar -xzvf, and that j instead of f for bzip2 files. Oh yeah, and gunzip <file> on the rare occasion when I need to unzip a gzip file from the commandline.
- Tank Program
- Forum & Project Admin, PhD
- Posts: 6711
- Joined: Thu Dec 18, 2003 7:03 pm
No, I don't! A search for "nullify" and derivatives in the forum does not turn up anything. I remember this one bug where an explosion would wipe out a whole long player wall segment. I remember the rip bug that could make such an effect possible. So, how is it done?TiTnAsS wrote:He nullified his own wall..old bug remember?
Edit: Just discovered Joda's post on the previous page. I'll have a look at it.
Tank's and Lucifer's infinite loop bug was indeed already fixed in CVS, that's why I could not reproduce it Phew. I wonder whether Lucifer has psychic abilities or if I'm suffering memory loss.
The seemingly random IP addresses and ports appearing in Tanks log were uninitialized variables; in debug mode, an assertion would have stopped the program.
Edit2: Here was the SF bug entry for it:
http://sourceforge.net/tracker/index.ph ... tid=657948
- Tank Program
- Forum & Project Admin, PhD
- Posts: 6711
- Joined: Thu Dec 18, 2003 7:03 pm
So it is indeed fixed? Grand .z-man wrote:Tank's and Lucifer's infinite loop bug was indeed already fixed in CVS, that's why I could not reproduce it Phew. I wonder whether Lucifer has psychic abilities or if I'm suffering memory loss.
The seemingly random IP addresses and ports appearing in Tanks log were uninitialized variables; in debug mode, an assertion would have stopped the program.
Edit2: Here was the SF bug entry for it:
http://sourceforge.net/tracker/index.ph ... tid=657948
Allright, I've done some analysis with the blank screen recording Joda.bot submitted. I found the corresponding recording on the server side (Hint: it's easier when you scream "BUG"). There is a bit of uncertainty because I don't know with what exact sources the server was running back then (something that gets logged only when someone yells "BUG"), but the facts fit together nicely. Or, not so nicely, depending on your viewpoint.
(Here comes the technical part you can skip until the READ ON line)
The last effect of this error is that on the client, after a while, no sync messages for the timer arrive any more; the client then thinks it's between rounds all the time and does not render.
The server does not send the timer syncs after a while. Two of the previous syncs got lost and are still in the resend queue, so it gave up generating new messages. The server tries periodically to resend the two previous syncs but does not get an answer from the client. Eventually, the client would have timed out, but Joda.bot was faster The messages really get send, and to the right address. By coincidence and construction, the UDP packets of all the attempts have all exactly the same length and content.
On the client, NONE of the resend attempts even arrives. I checked that at at the lowest possible level, with grep and the raw recording.
READ ON:
So, in essence, we have 20 identically shaped UDP packets, data length 258 bytes, sent over the course of 30 seconds or so. None of them arrived at their destination.
Question to the network experts: Can this be a glitch in a network filter between client and server? Something like a very broken firewall? Our network behaves oddly here (at least the connection to my PC), the web feels very sluggish at times.
Would it perhaps make sense to randomize the resend attempts a bit, so the packets don't look all alike?
(Here comes the technical part you can skip until the READ ON line)
The last effect of this error is that on the client, after a while, no sync messages for the timer arrive any more; the client then thinks it's between rounds all the time and does not render.
The server does not send the timer syncs after a while. Two of the previous syncs got lost and are still in the resend queue, so it gave up generating new messages. The server tries periodically to resend the two previous syncs but does not get an answer from the client. Eventually, the client would have timed out, but Joda.bot was faster The messages really get send, and to the right address. By coincidence and construction, the UDP packets of all the attempts have all exactly the same length and content.
On the client, NONE of the resend attempts even arrives. I checked that at at the lowest possible level, with grep and the raw recording.
READ ON:
So, in essence, we have 20 identically shaped UDP packets, data length 258 bytes, sent over the course of 30 seconds or so. None of them arrived at their destination.
Question to the network experts: Can this be a glitch in a network filter between client and server? Something like a very broken firewall? Our network behaves oddly here (at least the connection to my PC), the web feels very sluggish at times.
Would it perhaps make sense to randomize the resend attempts a bit, so the packets don't look all alike?
-
- Dr Z Level
- Posts: 2246
- Joined: Sun Mar 20, 2005 4:03 pm
- Location: IM: luke@dashjr.org
Quite simple:Lucifer wrote:Heh, I don't know why he did it, but I usually do it because that way I don't have to remember the command line arguments for gzip, which are different than tar.
Code: Select all
gzip file
gzip -d file
I hope you mean 'tar xjvpf' and 'z' instead of 'j' for gzLucifer wrote:Since I don't like to fill my head with useless crap, I've just learned tar -czvf and tar -xzvf, and that j instead of f for bzip2 files.
See, you already know a way to un-gzip. The reverse process doesn't require any optionsLucifer wrote:Oh yeah, and gunzip <file> on the rare occasion when I need to unzip a gzip file from the commandline.
@z-man: Sorry, I did not write back early... I was quite busy ...
Before you get completly puzzled about this problem... please let me recheck this bug before you continue. I replaced my network adapter as it was completly gone. (The pc wouldn't even boot anymore, except if the adapter was removed...)
Wait stop , the recording was from Mac OS X ... but there might have been a broken network adapter on the same network (@home).
I'll just make test using Windows now...
On Linux I should be able to use the latest beta from cvs.
EDIT: It took me about 30min to get to the buggy spot on Tank's Test Server as Z-Mans was not online... got a 14min Recording with BUG messages.
gn8
PS: I guess I'd rather generate a new recording with the Z-Mans stress-test settings which seem to work faster
Before you get completly puzzled about this problem... please let me recheck this bug before you continue. I replaced my network adapter as it was completly gone. (The pc wouldn't even boot anymore, except if the adapter was removed...)
Wait stop , the recording was from Mac OS X ... but there might have been a broken network adapter on the same network (@home).
I'll just make test using Windows now...
On Linux I should be able to use the latest beta from cvs.
EDIT: It took me about 30min to get to the buggy spot on Tank's Test Server as Z-Mans was not online... got a 14min Recording with BUG messages.
gn8
PS: I guess I'd rather generate a new recording with the Z-Mans stress-test settings which seem to work faster
Last edited by joda.bot on Wed Oct 19, 2005 1:11 am, edited 1 time in total.