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.nemostultae wrote:These two configuration settings do the same thing, right? WALLS_LENGTH and CYCLE_WALLS_LENGTH. That is a little confusing.
0.2.8_beta3: release process and bugs
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.
Check out my YouTube channel: https://youtube.com/@davefancella?si=H--oCK3k_dQ1laDN
Be the devil's own, Lucifer's my name.
- Iron Maiden
Be the devil's own, Lucifer's my name.
- Iron Maiden
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.
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.
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.

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

You do not have the required permissions to view the files attached to this post.
Check out my YouTube channel: https://youtube.com/@davefancella?si=H--oCK3k_dQ1laDN
Be the devil's own, Lucifer's my name.
- Iron Maiden
Be the devil's own, Lucifer's my name.
- Iron Maiden
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.
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.
Check out my YouTube channel: https://youtube.com/@davefancella?si=H--oCK3k_dQ1laDN
Be the devil's own, Lucifer's my name.
- Iron Maiden
Be the devil's own, Lucifer's my name.
- Iron Maiden
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.
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.
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 :nemostultae wrote: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.
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"
Matthias
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: 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.
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.

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.
Check out my YouTube channel: https://youtube.com/@davefancella?si=H--oCK3k_dQ1laDN
Be the devil's own, Lucifer's my name.
- Iron Maiden
Be the devil's own, Lucifer's my name.
- Iron Maiden
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.
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.
Check out my YouTube channel: https://youtube.com/@davefancella?si=H--oCK3k_dQ1laDN
Be the devil's own, Lucifer's my name.
- Iron Maiden
Be the devil's own, Lucifer's my name.
- Iron Maiden