0.2.8_beta3: release process and bugs

[Z-Man]

These two configuration settings do the same thing, right? WALLS_LENGTH and CYCLE_WALLS_LENGTH. That is a little confusing.

No, CYCLE_WALLS_LENGTH is internal, marked as "don't touch". It's set to either WALLS_LENGTH or SP_WALLS_LENGTH by the game code depending on the current game mode, you should modify those. Quite a retarded way do go about it, but the only way to keep the logic on the server in the current configuration system. I always wanted to hide CYCLE_WALLS_LENGTH from the user's view completely, but forgot about it.

[Lucifer]

Are we still leaking memory? After playing the game for awhile, when I quit, I have to wait 5 minutes while my laptop unswaps all of Kwin, firefox, and friends.

[Z-Man]

The leak finding memory has not reported serious leaks to me for a long time, the last ones were sporadic forgotten teams, and that happened only on the server. However, the leak finder does not check external C libraries, and it only does one check at the end. So a system that uses more and more memory over time, but cleanly frees all of it at the end will not get reported. The network object management would be a candidate for such behavior, it keeps deleted objects around for some seconds and has one huge list that maps object IDs to objects.

Valgrind reports some leaks in libxml2, but they seem to be only caches, as the number of leaks does not increase with the time the client runs.

Best would be to use top or ps to look for the memory usage. It should not grow signifficantly beyond 20 Mb. I'm currently doing that.
Edit: Quite consistently, Res memory usage goes up by 1 Mb per round. It may be the textures; I'm turning them off now.
Edit2: Yep, definitely the textures. I'll look into it.

[Z-Man]

Fixed. I was not cleaning up GL's internal textures in the destructor (duh). A similar error happened with the display lists of the models, but only in fast forward mode. I'll commit it as soon as SF lets me.

[Lucifer]

Lag's crazy over on Fortress, and team chat stopped working! Here's a recording. Nemo said BUG and I left and came back after that for this recording. Nemo left while I was making this recording, so you should be able to pinpoint its time to the server's recording based on those two things.

Also: Did you manage to commit that fix, z-man? I'm going to update and see anyway, just thought I'd ask.

[Lucifer]

Two more bugs, no recordings, sorry.

1. Q brings up the ingame menu. If you unbind the camera key that's bound to q, then press q, it'll bring up the ingame menu. A pain because I want to bind an instant chat to it instead.

2. In local game, if you sit on the UI long enough, your cycle will slowly creep across the screen.

[Z-Man]

Yes, the texture leakfix is committed.

Also, your feature request from a while back, that the instant chat keys should insert their chat string if you're already in chat, is implemented. It only works for key bindings that don't generate a regular character, of course. (Sorry, nemo, I looked at your patch; I did not like that the user has to edit the configuration files.)
While I did that, I noticed I had to take extra care that you can't issue cycle turn commands from chat; they run through the same code path than the instant chat commands. I added a setting item for the server administrator to remove that prevention. Of course, once you turn while in chat, you lose the chatbot and the pyramid. Repeat: this needs to be unlocked by the server administrator for now.

I'll have a look at the recording and the other bugs later. I probably bound q to the menu for keyboards that don't have an escape key (silly) and the creeping seems to be caused by inaccuracies in the frame time averager.
Edit: The two new bugs were easy. The instant chat commands did not mark the SDL event as used, so the game code happily reused it, and the creeping was indeed caused by the frame time averager going inaccurate. Fixed both.

[Thias]

In gParser.cpp: somewhere in the middle of the file you have includes for gGame.h and tConfiguration.h. gGame.h needs to move to the top of the other *.h includes, otherwise compiling using gcc4.0 will fail as outlined here.

I can confirm this : Compilation of beta3 on Fedora Core 4 i386 fails on the above file. This one-liner patch fixes the build for me :

Code: Select all

--- armagetronad-0.2.8_beta3.orig/src/tron/gParser.cpp  2005-10-22 02:31:29.000000000 +0200
+++ armagetronad-0.2.8_beta3/src/tron/gParser.cpp       2005-11-14 13:42:41.000000000 +0100
@@ -6,6 +6,7 @@
 #include <string.h>
 #include <sys/types.h>

+#include "rSDL.h"
 #include "eCoord.h"
 #include "eGrid.h"
 #include "gWall.h"

Now off to test the PPC and x86_64 builds...

Matthias

[Thias]

Oh, another small bug I've caught : The desktop/armagetronad.desktop file contains the line "Type=Application" twice, and desktop-file-install chokes on it

Matthias

[Z-Man]

Thias: Thanks, the .desktop problem corrected. And Welcome!

Lucifer: Is there anything special about the recording? I saw two things, one is the team chat problem (fixed) the other is that everyone had a pretty high ping. This may have been a network problem outside of my influnece, remember the server is located at our institute. Normally, the network works fine and with low latency, but it's not exactly a professional server farm with guaranteed quality of service.

[Lucifer]

Heh, the recording mostly shows the team chat bug that was fixed already.

If you can match up the recording to the server with the lag thing, then it's probably useless to you. I'm now noticing some extra lag on other servers, so I'm not sure anymore that it's something specific to Fortress or my client.

[dlh]

I was playing on fortress and the two teams were Gold and Blue. The cycle in the screenshot is on Blue, but his trail is gold. Very sneaky...

[Fonkay]

That guys does that all the time. He's a real ass about it too. I've asked him to change it, but he refuses.

[Z-Man]

It has been taken care of
The color overflow bug, the only bug everybody liked so far, has been fixed. Only if BUG_COLOR_OVERFLOW is set to 1 (which is the default), it is still tolerated for players in one-person teams.
Edit: remember to tease him about it the next time you see him

[Lucifer]

On lag: it appears that we're getting pretty stable. I updated from the branch last night and now I'm getting the "syncing with server..." message, and there are much fewer hiccups, whether I previously attributed them to lag or not. Much more predictable play.

Another beta? This cvs code is pretty damn stable.

On chat: This is a longstanding bug that has been exacerbated by my instant chat keybinds and I kept forgetting about. When you're typing in a line of chat, and you hit the end of the line (maximum length), then it interprets new keypresses as regular keypresses. So I'd type a really long line, and then if I hit f because f was in the word, I would pop out of fullscreen. Well, now that I have instant chat bound to the left-hand side of my keyboard, chat fills up with it. So, with the new instant chat thing you've added (thanks, btw), my chat fills up with instant chats. What's weird about *that* is that I'm theoretically at maximum length for chat, but it's adding more characters from instant chats.

Is there any way we can increase the number of instant chats available? I'm not too concerned about it, if you just point me in the right direction I'll be happy to mod my client for it. I'm full up on instant chats for team play, so no room for fun chats, and no room for admin chats.

edit: More on chat. I seem to recall binding Return to 'say', and then I could only get out of chat by hitting escape. Or maybe I couldn't get out of chat, something like that. Weird.