BUG cries on Bugfarm Fortress and Sumo

[Lucifer]

I'd like that option. Maybe a fractional number, like:

GAME_POINT 0.1 # needs 10% point difference to win

Then:

MAX_SCORE 150 # if the difference isn't reached when a team/player hits 150 points, declare a tie

[Z-Man]

Well, the true scientific way would be to make the required points distance proportional to the square root of the total points, because that's how the expected difference of two equally strong teams is supposed to fluctuate statistically.

To keep it simple to understand for the players, I'd stick to absolute differences. Make the required distance about what one team can maximally catch up in one round, just so nobody can complain "we'd have caught on the next round, stupid arbitrary match end". It doesn't matter that much how the difference scales for the end result, because match end scores can be expected to be on the same order of magnitute every time, the difference is a factor of 2.6 maximally on Fortress from additional kill points.

Yes on the score limit for ties.

[Lucifer]

How about a maximum point difference, too? Declare a winner when that's achieved? This might be a little more complex, but it seems like the game can determine each round what the total points available for each team are (each opposing player * 2 + 10), take that by the number of rounds left in the match, and if the point difference is equal or higher, declare a winner.

I think I mentioned it before. Of course, there are some benefits to not doing that, a lot of us fool around and do really crazy stuff when the winner's already clear and the other team can't catch up, and that's fun, too.

[Z-Man]

Unfortunately, it's not easy to figure out currently what the maximum score or score difference per round is. The relevant information is spread over gCycle, gGame and gWinZone for the scores and of course eTeam for team size. Yeah, bad design.

If we already had our fuction parser, we could make the required score difference a function of the current score and player count. I'd say we should wait for that (or scripting) to pop up and handle the fancier stuff that way later. Now, I'd like to stick to the basics. If the losing team wants to end the match quickly, they can all pretend to be AFK for the rest of the match. Oh, wait, that will kick them out of the game They can pretend to be almost AFK.

[DDMJ]

I don't know if you have gotten this bug before, but you probably have. Ever since the experimental change with the bikes having a width has started, every 7 rounds or so, the team colors flip-flop. The scores don't get affected but, it's weird because everyone switches teams. It doesn't say "...... switched from Team blue to Team gold" but it is clearly obvious. As I said though, the scores don't get affected. So, if the score was Team blue: 72 and Team gold: 34, after the switch it would be Team gold: 72 and Team blue: 34. It's weird. Does it have anything to do with a bug in the experimental test? It never happened before that. I'm just wondering becuase it gets quite annoying. Thanks.

[Z-Man]

It's linked to an unrelated change.

[DDMJ]

Is it fixable because it is rather annoying.

[Z-Man]

Of course It'll be fixed after the next restart. It happened every time a player left from both teams during a round and the team score ranking had changed.

[oO.k3nNy]

i had 2 situations today where i died at my tail? is that change removed? i BUG-cried the 2nd one, the other one was one match before i think

[omega]

polling- it wont let any of us do it. some1 has been tking us 10 rounds and he wont leave and we cant kick him. like 5 ppl have tried. It always says
'your not old enuff to vote'

[Z-Man]

Kenny: No, the tail thing should still be active. Have you installed 0.2.8.2? Because if you have, the tail shrinkage is known to your client and visible to you, and if you still aim 2.5 grid units ahead of its end and have already used some rubber, you're dead.

omega: whoops, got a logic condition the wrong way round. Again. I'll restart to fix this.

Code: Select all

[0] Player 1 core dumped Emlock for 2 points.
[0] User 10 timed out.
[10] Emlock left Team gold.
...
[2] Received login from <same IP as before> via socket *.*.*.*:4536.
[2] New user: 2
[2] Emlock plays for Team gold.
[2] Emlock: BUG

I take it this was a real timeout, Emlock wouldn't be killed by Player 1 if his client was still functional. What did it look like on the client side? Would we be lucky and there is a recording?

[oO.k3nNy]

Kenny: No, the tail thing should still be active. Have you installed 0.2.8.2? Because if you have, the tail shrinkage is known to your client and visible to you, and if you still aim 2.5 grid units ahead of its end and have already used some rubber, you're dead.

i ve got 0.2.8.2 installed yes.
actually i saw it working too alrdy. but this was a situation which i often use to change from outer to inner defender. i normally dont die at it (i had about 2 rubber min. left for sure). so why did i die now? could it be that the vehicle takes more rubber now at "driving-through-your-tail" ?

[Z-Man]

If you had 2 rubber left, you needed to hit your tail at one grid unit accuracy. That's 1/8th of the diameter of a hole. I can play the thing back if you want to know by how much you missed
Yes, the increased MINDISTANCE will make you use up more rubber when crossing your own tail, but it shouldn't kill you in situations you could survive previously.

[omega]

ty zman u the dude!

where can i get 0.2.8.2. On downloads gcc its 2.8.1.1.

can i have a link pls

[oO.k3nNy]

If you had 2 rubber left, you needed to hit your tail at one grid unit accuracy. That's 1/8th of the diameter of a hole. I can play the thing back if you want to know by how much you missed
Yes, the increased MINDISTANCE will make you use up more rubber when crossing your own tail, but it shouldn't kill you in situations you could survive previously.

hm strange thing, maybe i had a slight slide.

omega: http://sourceforge.net/project/showfile ... _id=110997