After one team wins a match, the winning team sometimes starts off with 10 points at the beginning of the new match. This happens twice in the recording.
Near the end of the recording, my camera (custom camera) goes totally berserk. It starts flipping back and forth. This has happened to me frequently on Fortress.
= Recording
== EST(-0500)
http://generalconsumption.org/armagetro ... 06.rec.bz2
Fortress Problems
Thanks, it plays back fine.
The scoring bug is probably caused by a global variable; it gets set by win events (also by the classic win zones) and later analyzed by the game logic. Pure evil, and here it goes wrong.
The first instance of the camera bug (around T=2080s) looks more like a "normal" cycle syncing problem, it seems your path got cut off a while earlier, but it took your client a while to figure that out. The server's network connection is not perfect, there can be lots of packet loss. I'm not sure about the second one one round later. I'll have a closer look at it in the debugger, or simply play more and see if it happens to me
I'll also have a look at why the teams sometimes get named after the leading player; this may be the specified behavior of the players' settings of team name wish taking effect, but it seems to be irritating some players.
To the general public:
It also seems that now, people got the habit of blaming bugs instead of lag when they die. The problem: going after each of these is at least one hour of work, more if you don't at least give some hint about what the bug actually was. That simply means I have hardly any time to look at even a tiny fraction of bug events, so I'll pick the ones I've got most information on first.
The scoring bug is probably caused by a global variable; it gets set by win events (also by the classic win zones) and later analyzed by the game logic. Pure evil, and here it goes wrong.
The first instance of the camera bug (around T=2080s) looks more like a "normal" cycle syncing problem, it seems your path got cut off a while earlier, but it took your client a while to figure that out. The server's network connection is not perfect, there can be lots of packet loss. I'm not sure about the second one one round later. I'll have a closer look at it in the debugger, or simply play more and see if it happens to me
I'll also have a look at why the teams sometimes get named after the leading player; this may be the specified behavior of the players' settings of team name wish taking effect, but it seems to be irritating some players.
To the general public:
It also seems that now, people got the habit of blaming bugs instead of lag when they die. The problem: going after each of these is at least one hour of work, more if you don't at least give some hint about what the bug actually was. That simply means I have hardly any time to look at even a tiny fraction of bug events, so I'll pick the ones I've got most information on first.
I think that if the round is won by staying in the zone, the player that accomplished that should be announced (in the console) and possibly given points for it (another config item).
So you could turn of getting points for kills, and instead just keep track of who conquers the fortress the most frequently.
So you could turn of getting points for kills, and instead just keep track of who conquers the fortress the most frequently.
Nemo: Then we'd also have to give players points for successfully defending the own base, and I would not know how to do that. Otherwise, people would not want to defend. Taking away the killing score could be a good idea, though. And announcing the conqueror, so the other team has a clue who to kill first in the next round.
TnA: Sure, But then the game rules have to get more complicated (what happens if team B conquers team C's zone?) and group dynamics change ("Everyone finish team D first!"). There are reasons why classic sports games always have two teams on the field.
What we probably really need is more servers; I guess that'll happen automatically once beta3 is out.
Tard: I blame it on the bad network for now. Quite comfortable, but there really is no other logical explanation in sight.
TnA: Sure, But then the game rules have to get more complicated (what happens if team B conquers team C's zone?) and group dynamics change ("Everyone finish team D first!"). There are reasons why classic sports games always have two teams on the field.
What we probably really need is more servers; I guess that'll happen automatically once beta3 is out.
Tard: I blame it on the bad network for now. Quite comfortable, but there really is no other logical explanation in sight.
-
philippeqc
- Long Poster - Project Developer - Sage
- Posts: 1526
- Joined: Mon Jul 12, 2004 8:55 am
- Location: Stockholm
- Contact:
A question about the behavior of Zone when it gets triggered (current implementation).
If many players of the same team are in the Zone as it gets won, do they /can they all receive the "individual" score for it?
Yes, I've also wondered if the following scoring configuration was possible:
- 3 point to team score for capturing the zone
- 1 point for every team member that where in the zone at the moment it was captured
- 0 point for killing a player
- 0 point for being last team alive
If many players of the same team are in the Zone as it gets won, do they /can they all receive the "individual" score for it?
Yes, I've also wondered if the following scoring configuration was possible:
- 3 point to team score for capturing the zone
- 1 point for every team member that where in the zone at the moment it was captured
- 0 point for killing a player
- 0 point for being last team alive
Canis meus id comedit.
They don't, and they can't (no configuration option available).
It would be possible, I'd need to install a state variable in the zone. Something I probably should be doing anyway, currently it's abusing the expansion speed as a kind of state indicator.
Well, I guess I can make the individual score a variable. On my server, it'll certainly stay at zero
It would be possible, I'd need to install a state variable in the zone. Something I probably should be doing anyway, currently it's abusing the expansion speed as a kind of state indicator.
Well, I guess I can make the individual score a variable. On my server, it'll certainly stay at zero
I remember seeing in the source a commented out block of code about getting points for pushing someone into the zone, and how it did not work out. So this would kinda be the opposite, points for keeping someone out it.z-man wrote:Nemo: Then we'd also have to give players points for successfully defending the own base, and I would not know how to do that. Otherwise, people would not want to defend. Taking away the killing score could be a good idea, though. And announcing the conqueror, so the other team has a clue who to kill first in the next round.
I do think there should be a few config items for Fortress mode, I would like to try something similar to ph's suggestions.
Last edited by dlh on Wed Oct 19, 2005 8:29 am, edited 1 time in total.
-
philippeqc
- Long Poster - Project Developer - Sage
- Posts: 1526
- Joined: Mon Jul 12, 2004 8:55 am
- Location: Stockholm
- Contact:
z-man: good comments about defense score and multi-team. I'll have to think more about it.
I posted a bit too soon, I forgot to mention it was a curiosity question, not a desire for you to fix anything.
I think I'll have to find some settings that do the following:
- a single player would need to spend a long continuous time in the zone (10-12 seconds) because of an agressive decay.
- 2 players in the zone would solve it in a continous 3-5 seconds.
- 1 player vs 1 defender would never solve it (without pushing the defender out)
- 2 agressor vs 2 defenders would solve it in a duration of about 7-9 seconds.
All times are assuming that the players involved stay in the zone for the continuous duration.
I'm hoping it would create a "must be 2 to win a Zone" atmosphere on a server using such settings. But I'mjust dreaming for the fun of it, so you can safely ingnore the harmless idiot that am ;)
-ph
I posted a bit too soon, I forgot to mention it was a curiosity question, not a desire for you to fix anything.
I think I'll have to find some settings that do the following:
- a single player would need to spend a long continuous time in the zone (10-12 seconds) because of an agressive decay.
- 2 players in the zone would solve it in a continous 3-5 seconds.
- 1 player vs 1 defender would never solve it (without pushing the defender out)
- 2 agressor vs 2 defenders would solve it in a duration of about 7-9 seconds.
All times are assuming that the players involved stay in the zone for the continuous duration.
I'm hoping it would create a "must be 2 to win a Zone" atmosphere on a server using such settings. But I'mjust dreaming for the fun of it, so you can safely ingnore the harmless idiot that am ;)
-ph
Canis meus id comedit.
I never ignore idiots
Ok, let's do the math of your requirements. We have some hard constraints:
I. It should be possible for one player to conquer the zone. That implies CONQUEST_RATE > CONQUEST_DECAY_RATE.
II. 1 vs 1 does not conquer. This implies CONQUEST_RATE <= CONQUEST_DECAY_RATE + DEFEND_RATE.
III. 2 vs 2 conquers. 2 * CONQUEST_RATE > CONQUEST_DECAY_RATE + 2 * DEFEND_RATE or CONQUEST_RATE > CONQUEST_DECAY_RATE/2 + DEFEND_RATE
To tackle the soft constraints, note that the overall conquest rate is
RATE(attackers, defenders) = attackers*CONQUEST_RATE - defenders*DEFEND_RATE - CONQUEST_DECAY_RATE, and the time it takes to conquer the zone (if RATE is positive) is 1/RATE. It's better to think in rates, you don't have to deal with the inverse and all equations are linear.
Soft constraints:
RATE(1,0) = 1/(10..12)
RATE(2,0) = 1/(3..5)
RATE(2,2) = 1/(7..9)
Well, we have three variables and three equations, that should give one unique solution. Not boring you with the details (some readers hate math), It's
DEFEND_RATE = ( RATE(2,0)-RATE(2,2) )/.5 or here, about .06
CONQUEST_RATE = RATE(2,0) - RATE(1,0) or here, about 0.16
CONQUEST_DECAY_RATE = RATE(2,0) - 2 * RATE(1,0) or here, about 0.07
Unfortunately, this violates hard constraint II (That's actually the only one we have to check, I and III are implicit in the soft constraints), you'll need to bend the values.
Translating constraint II to the input values, the rates, it reads
2 * RATE(1,0) + RATE(2,2) <= RATE(2,0).
Ok, let's do the math of your requirements. We have some hard constraints:
I. It should be possible for one player to conquer the zone. That implies CONQUEST_RATE > CONQUEST_DECAY_RATE.
II. 1 vs 1 does not conquer. This implies CONQUEST_RATE <= CONQUEST_DECAY_RATE + DEFEND_RATE.
III. 2 vs 2 conquers. 2 * CONQUEST_RATE > CONQUEST_DECAY_RATE + 2 * DEFEND_RATE or CONQUEST_RATE > CONQUEST_DECAY_RATE/2 + DEFEND_RATE
To tackle the soft constraints, note that the overall conquest rate is
RATE(attackers, defenders) = attackers*CONQUEST_RATE - defenders*DEFEND_RATE - CONQUEST_DECAY_RATE, and the time it takes to conquer the zone (if RATE is positive) is 1/RATE. It's better to think in rates, you don't have to deal with the inverse and all equations are linear.
Soft constraints:
RATE(1,0) = 1/(10..12)
RATE(2,0) = 1/(3..5)
RATE(2,2) = 1/(7..9)
Well, we have three variables and three equations, that should give one unique solution. Not boring you with the details (some readers hate math), It's
DEFEND_RATE = ( RATE(2,0)-RATE(2,2) )/.5 or here, about .06
CONQUEST_RATE = RATE(2,0) - RATE(1,0) or here, about 0.16
CONQUEST_DECAY_RATE = RATE(2,0) - 2 * RATE(1,0) or here, about 0.07
Unfortunately, this violates hard constraint II (That's actually the only one we have to check, I and III are implicit in the soft constraints), you'll need to bend the values.
Translating constraint II to the input values, the rates, it reads
2 * RATE(1,0) + RATE(2,2) <= RATE(2,0).
-
Sabarai
- The Former Man of Cheese
- Posts: 2383
- Joined: Sat Jun 19, 2004 9:00 pm
- Location: 52°09'30.24"N 5°18'48.17"
You can also try to make the zone smaller as soon as players get in it, that would make it harder to capture.
You can also make the winning team be in disadvantage, that they don't spawn in their zone, but that their zone is somewhere else, of course not closer to opposing team than themselves...
Just a few ideas
You can also make the winning team be in disadvantage, that they don't spawn in their zone, but that their zone is somewhere else, of course not closer to opposing team than themselves...
Just a few ideas
Nemo, about the pushing code: It's not mine, so I don;t know why it did not work as planned. I figure just using the lastEnemyInflunence information should have worked. Here, I imagine it would be very hard to detect a successful defense by keeping an enemy out of the zone; we could rate kills near the own fortress higher, that's about all I could imagine. Unfortunately, the current code structure makes things like that difficult to implement in a non-hacking way.
Sab: Another unfortunately: the zone's coordinates are determined by the map; so it would not be a viable option to move it around.
I'll think about the sizing; this may be a good way to visualize the conquest status, something that would be useful for low conquest rates. I was also pondering modifying the color, or perhaps the rotation frequency.
Sab: Another unfortunately: the zone's coordinates are determined by the map; so it would not be a viable option to move it around.
I'll think about the sizing; this may be a good way to visualize the conquest status, something that would be useful for low conquest rates. I was also pondering modifying the color, or perhaps the rotation frequency.
-
Tank Program
- Forum & Project Admin, PhD
- Posts: 6711
- Joined: Thu Dec 18, 2003 7:03 pm
