0.2.8.0_rc4: Release process and bugs
0.2.8.0_rc4: Release process and bugs
Another RC is needed, the additional checks to the parser demand it.
Pending stuff:
Really final final artwork. Joda's wall and the floor need a bit of tweaking on popular demand.
Another resource move. DTD's may go to AATeam/*.dtd. A version bump is required anyway.
Was anything forgotten that is important to the release? Last chance to speak up.
Probably not for 0.2.8.0 because it was brought up too late and is just too unimportant: any change to the map filepath scheme.
I'll handle the dtd if there are no well founded objections in this thread, Philippe has the final word on the artwork as before.
Pending stuff:
Really final final artwork. Joda's wall and the floor need a bit of tweaking on popular demand.
Another resource move. DTD's may go to AATeam/*.dtd. A version bump is required anyway.
Was anything forgotten that is important to the release? Last chance to speak up.
Probably not for 0.2.8.0 because it was brought up too late and is just too unimportant: any change to the map filepath scheme.
I'll handle the dtd if there are no well founded objections in this thread, Philippe has the final word on the artwork as before.
- Lucifer
- Project Developer
- Posts: 8645
- Joined: Sun Aug 15, 2004 3:32 pm
- Location: Republic of Texas
- Contact:
Minor annoyance that I'd really like fixed. When the server goes to sleep, then later when it wakes up because a player joined, everytime.cfg doesn't get loaded. Or at least, it didn't used to.
Here's why it matters. I dreamed up another use case for the map rotator I'm screwing with, and there's one situation it can't handle. Well, among the many it can't handle, that is.
Take the fortress server for the use case. Ideally, for single player play, it would just be a standard deathmatch against AI's. When a player joins, ideally (arguably) you want it to be sumo. You might want that for up to 4 players, in fact.
So, when the server goes to sleep, the map rotator would write one more everytime.cfg file, one that sets up a generic single player deathmatch. When the server wakes up because a player joined, it would load this new everytime.cfg and set up a simple deathmatch.
Then, it could keep track of players coming and going and do its best to match up a map with the number of players present. Sometimes you'll have 5-6 player sumo, sometimes you'll have regular fortress play with only 2-3 players, depending on when players quit. Otherwise, it would be fine. (That is, it would take a round to settle)
All of it adding up to a server that would be fun all the time, theoretically.
Here's why it matters. I dreamed up another use case for the map rotator I'm screwing with, and there's one situation it can't handle. Well, among the many it can't handle, that is.
Take the fortress server for the use case. Ideally, for single player play, it would just be a standard deathmatch against AI's. When a player joins, ideally (arguably) you want it to be sumo. You might want that for up to 4 players, in fact.
So, when the server goes to sleep, the map rotator would write one more everytime.cfg file, one that sets up a generic single player deathmatch. When the server wakes up because a player joined, it would load this new everytime.cfg and set up a simple deathmatch.
Then, it could keep track of players coming and going and do its best to match up a map with the number of players present. Sometimes you'll have 5-6 player sumo, sometimes you'll have regular fortress play with only 2-3 players, depending on when players quit. Otherwise, it would be fine. (That is, it would take a round to settle)
All of it adding up to a server that would be fun all the time, theoretically.
I'm not sure this is a bug. and if it is a bug I'm not sure if it's a rc3 bug or a fortress bug.
Whenever I join a game in fortress it shows me the last player to leave the game as if they left the same time I came in. Sometimes I've seen the player in another server before I've even joined. I haven't payed attention to whether or not this happens in other servers.
If it's not a bug, why is it happening?
Whenever I join a game in fortress it shows me the last player to leave the game as if they left the same time I came in. Sometimes I've seen the player in another server before I've even joined. I haven't payed attention to whether or not this happens in other servers.
If it's not a bug, why is it happening?
This post does not come with any form of Warranty or Return Policy.
If you're unhappy with this post, please feel free to suck it up and move on.
If you're unhappy with this post, please feel free to suck it up and move on.
- Lucifer
- Project Developer
- Posts: 8645
- Joined: Sun Aug 15, 2004 3:32 pm
- Location: Republic of Texas
- Contact:
General roundup. It's possible that some of this stuff is in the b0_2_8_0 branch and I'm just running the wrong branch.
In the log, there's no round end message. There's the Overall Winner, but no round end message.
The extra settings used for sumo don't appear to be there. In fact, it doesn't look like I can even setup a sumo clone.
Edit: Nevermind. The settings take effect, they just don't show up when you do armagetronad-dedicated --doc .
Like I say, maybe I just built from the wrong branch for my server.
In the log, there's no round end message. There's the Overall Winner, but no round end message.
The extra settings used for sumo don't appear to be there. In fact, it doesn't look like I can even setup a sumo clone.
Edit: Nevermind. The settings take effect, they just don't show up when you do armagetronad-dedicated --doc .
Like I say, maybe I just built from the wrong branch for my server.
I can confirm the strange messages as well. They appear to come from the server, I'll investigate. Unless I find this to be the tip of a iceberg bug, it'll get lower priority.
Lucifer: The config items are transitional and undocumented and you don't get help on it.
Was there ever a round end message? Should we have one? We only got the "Winner" thing. There is a reliable NEW_ROUND message in ladderlog.txt, if that helps.
Lucifer: The config items are transitional and undocumented and you don't get help on it.
Was there ever a round end message? Should we have one? We only got the "Winner" thing. There is a reliable NEW_ROUND message in ladderlog.txt, if that helps.
- Lucifer
- Project Developer
- Posts: 8645
- Joined: Sun Aug 15, 2004 3:32 pm
- Location: Republic of Texas
- Contact:
I guess I can make a regex for the winner. The new round message in scorelog.txt isn't quite right because it shows at the start of the round. I might be able to work with it, but it would be hackish at best. It results in off-by-one errors. Previously I used the new match message from there (because that's how wrtl's script worked), and it meant the map was rotated on the second round of each match because everytime.cfg was written after the first round started.
You could use named pipes; make everytime.cfg such a named pipe and generate its content right when its needed.
I did some feasibility testing:
After <rm /var/everytime.cfg; mkfifo /var/everytime.cfg> had the desired result: every round, the current round count and date, really the date everytime.cfg was read, was printed on the client's console. This is more right-on-time than any "parse log as we go and modify the real everytime.cfg file at certain points" scheme can accomplish.
Of course, everytime.cfg must not be a fifo while the script is not running, or the server hangs.
I did some feasibility testing:
Code: Select all
#!/bin/bash
f=1
# create named pipe
rm -f everytime.cfg
mkfifo everytime.cfg
while true; do
echo "SAY ROUND $f ENDS AT $(date)" > everytime.cfg;
echo "Round $f ends"
f=$((f+1))
sleep 1 # important, without the server gets fed an infinite everytime.cfg every round and overflows
done
Of course, everytime.cfg must not be a fifo while the script is not running, or the server hangs.
- Lucifer
- Project Developer
- Posts: 8645
- Joined: Sun Aug 15, 2004 3:32 pm
- Location: Republic of Texas
- Contact:
Heh, I seem to recall trying to use everytime.cfg as a named pipe before for something else.
Um, you're right that it's more right-on-time than anything else, but right-on-time isn't the goal. More like "before it gets loaded, hopefully with enough advance time to generate a new one".
I think I've got an idea, anyway. I can either tail the scorelog, or just have a regex for the round winner. In any case, all that really amounts to is a round counter. I can use the match announcement to correct any off-by-one errors that crop up, and realistically, writing everytime.cfg during the round rather than in that space before the new round starts (and everytime.cfg gets loaded) is better because it leaves more time for the map rotator to do other work. It could, for example, generate the new everytime.cfg in a cache, and then when the appropriate announcement is made, copy it from the cache. Then it could generate at any time. It could further leave markers in the cache for stuff that can't be changed until the round/match is over because it actually needs to know who won and then change those on the fly.
Um, you're right that it's more right-on-time than anything else, but right-on-time isn't the goal. More like "before it gets loaded, hopefully with enough advance time to generate a new one".
I think I've got an idea, anyway. I can either tail the scorelog, or just have a regex for the round winner. In any case, all that really amounts to is a round counter. I can use the match announcement to correct any off-by-one errors that crop up, and realistically, writing everytime.cfg during the round rather than in that space before the new round starts (and everytime.cfg gets loaded) is better because it leaves more time for the map rotator to do other work. It could, for example, generate the new everytime.cfg in a cache, and then when the appropriate announcement is made, copy it from the cache. Then it could generate at any time. It could further leave markers in the cache for stuff that can't be changed until the round/match is over because it actually needs to know who won and then change those on the fly.
-
- Dr Z Level
- Posts: 2246
- Joined: Sun Mar 20, 2005 4:03 pm
- Location: IM: luke@dashjr.org
- Tank Program
- Forum & Project Admin, PhD
- Posts: 6711
- Joined: Thu Dec 18, 2003 7:03 pm
Was playing rc3 and got a reproducable recorded crash... Opened chat and acidently hit F1. Boom.
Code: Select all
Fatal signal: Segmentation Fault (SDL Parachute Deployed)
Internal Error:Internal error in void tHeapBase::Remove(tHeapElement*) in tools/tHeap.cpp:145 :
Element is not in this heap! (Note: this usually is a followup error when the system fails to recover from another error. When reporting, please also include whatever happened before this.)
Please send a Bug report!
Segmentation fault
You do not have the required permissions to view the files attached to this post.
Thanks. The recording doesn't crash for me. Could you do the same while running in debug mode in a debugger and send a backtrace? Probably the spot where I'll need local variables listed is eMenuItemChat::Event().
I already spotted a false return value in that function, but that probably is not the reason for the crash.
I already spotted a false return value in that function, but that probably is not the reason for the crash.