0.2.8 (beta 3 tagged)

Website · Post by **Z-Man** » Sat Oct 15, 2005 12:52 pm

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.

Post by **dlh** » Sat Oct 15, 2005 11:12 pm

Phase bug, sorry no recording. Taken on Lucifer's server.

Website · Post by **Z-Man** » Sat Oct 15, 2005 11:23 pm

Ohhh, f3. Is that Your_mon's own wall he's going through to and fro a thousand times?
Don't worry, a clientside recording would not be of too much use here.

Post by **Tank Program** » Mon Oct 17, 2005 8:55 am

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

Website · Post by **Z-Man** » Mon Oct 17, 2005 8:57 am

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.

Post by **dlh** » Mon Oct 17, 2005 9:56 am

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

OT, but why did you tar a single file?

Post by **Lucifer** » Mon Oct 17, 2005 9:58 am

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.

Post by **Tank Program** » Mon Oct 17, 2005 4:53 pm

Yeah, I've got tars' options memorized... tar -jcvf, -jxvf, -zcvf, -zxvf... Much easier, as lucifer said, to memorize.

TiTnAsS · Post by **TiTnAsS** » Mon Oct 17, 2005 7:12 pm

z-man wrote:Ohhh, f3. Is that Your_mon's own wall he's going through to and fro a thousand times?
Don't worry, a clientside recording would not be of too much use here.

He nullified his own wall..old bug

remember?

Website · Post by **Z-Man** » Mon Oct 17, 2005 9:30 pm

TiTnAsS wrote:He nullified his own wall..old bug remember?

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?

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

Post by **Tank Program** » Mon Oct 17, 2005 9:54 pm

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

So it is indeed fixed? Grand

.

Website · Post by **Z-Man** » Tue Oct 18, 2005 3:29 pm

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?

Luke-Jr · Post by **Luke-Jr** » Tue Oct 18, 2005 7:11 pm

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.

Quite simple:

Code: Select all

gzip file
gzip -d file

Lucifer 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.

I hope you mean 'tar xjvpf' and 'z' instead of 'j' for gz

Lucifer wrote:Oh yeah, and gunzip <file> on the rare occasion when I need to unzip a gzip file from the commandline.

See, you already know a way to un-gzip. The reverse process doesn't require any options

joda.bot · Post by **joda.bot** » Wed Oct 19, 2005 12:42 am

@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

Post by **Lucifer** » Wed Oct 19, 2005 12:48 am

RIght, and then gzip takes the old file, gzips it, and then you don't have it anymore. So what's the command line option to tell it to save the old file?

(I guarantee it'll wind up being something "extra" for me to remember that I'd prefer to just have tar filter it for me)