I saw that the awards didn't include all the stats we would like to see and I didn't get a feel if Team Vortex was going to go beyound the awards system to produce stats. I was hoping they would do what OverloadUT just said.
Since they are working on awards and stats, I hope they will interact with us to get the UTStatsDB side up and running as soon as possible with a real good set of stats.
Again, I hope they post a list of what stats they are considering doing. Better to work with Team Vortex to help get it right, then to see a bunch of moan threads if some stats are missing when it rolls out.
Thanks Imaginos, OverloadUT, Robert, DavidM and others for working to get this going.
My chat with OLStats author, Overload
Moderators: Jay2k1, DavidM, The_One
Is this necessary? I don't think a sign other than F3 is needed to be honest. And what happens if someone is best att and passer? Will they have two colours?DavidM wrote: Additional Trails:
--------------
the f3 box shows the top 3 of each category. the first should have a trail at his feet.
These trails have 2 colors each, its fading from A to B, so I'll give 2 RGB values.
Best Defender should have a team color trail
Red=255,0,0 to 255,125,125
Blue=0,64,255 to 0,255,255
Best Attacker a yellow trail
255,155,0 to 255,255,0
Best Passer green
21,170,0 to 17,255,17
Keeper can get a purple trail
126,0,202 to 214,17,255
I was wondering if there is any forseable way to prevent people from stacking thier stats. If every play counts then we might see more beardy players popping into an empty room or with one other player to stack (cheat) the system into giving them better stats.
Perhaps you could enable stat tracking for league games or maybe make the stats count when the player count is over 4?
Perhaps you could enable stat tracking for league games or maybe make the stats count when the player count is over 4?
There's a thought.
The UTStats system that is on the BuD servers is not adapted for the Deathball output yet. One it is, there's already a method in place to prevent low player matches from counting in the scheme of things.
On top of that, the mixer/match gametype can be distinguished from the openplay pub gametype and stats for each can be kept seperate.
The UTStats system that is on the BuD servers is not adapted for the Deathball output yet. One it is, there's already a method in place to prevent low player matches from counting in the scheme of things.
On top of that, the mixer/match gametype can be distinguished from the openplay pub gametype and stats for each can be kept seperate.
Having seen the NADBL stats system, it seems obvious that further improvements in this area will reap rewards.
The kind of functions and plays that can seem to be recorded suggest that detailed anaylses can be produced as well as an accurate awards system.
however, i've been thinking of something that may help you come up with a way a deciding between a bad pass and a bad catch.
Note:
I've only considered lock-passes (autopasses) also,
Catch = either ball pickup or volley contact
Consider the passer, the receiver and an interceptor
Scenario 1.
Auto pass activates
The Receiver continues to move without adjusting speed or direction to catch the ball OR the receiver is impeded/makes contact with/boosted by an interceptor after the pass is made
The catch is made.
Result: Good Pass, Good Catch.
reasoning: a clean pass is easy enough to understand. i thought in the 'OR' option that maybe the passer should be penalised. but gave them the benefit of the doubt.
Scenario 2
Auto pass activates
The Receiver continues to move without adjusting speed or direction to catch the ball
The receiver is boosted/impeded/makes contact by an interceptor
The catch is not made by receiver
Result: Bad pass only, +1 for intercepter
Reasoning: I believe it's the passers responsibilty to ensure the 'line of sight' for the receiver is clear... bit unfair here as sometimes interceptors can boost in.. but balances with scenario 1, i'd say.
Scenario 3
Auto pass activates
The Receiver makes adjustments to speed or direction (excluding z-axis)
The catch is not made by the receiver nor is the ball intercepted in the time it should take to get to the receiver (<-tricky one)
Result: Bad catch only. Extra penalty if the receiver was blinking 'pass me the ball'
Reasoning: not the passers fault the receiver wasn't paying attention.
Scenario 4
autopass
ball intercepted or deflected on the way to the receiver.
result: bad pass, regardless of whether catch is made or not. Nil penalty if passer was killable in one hit. +1 to interceptor if the catch is not made
reasoning: if the catch is made then its luck. Only the passers fault tbh unless they were under pressure.
not sure how useful this would be though - its quite simplistic......
but i wrote it in response to:
The kind of functions and plays that can seem to be recorded suggest that detailed anaylses can be produced as well as an accurate awards system.
however, i've been thinking of something that may help you come up with a way a deciding between a bad pass and a bad catch.
Note:
I've only considered lock-passes (autopasses) also,
Catch = either ball pickup or volley contact
Consider the passer, the receiver and an interceptor
Scenario 1.
Auto pass activates
The Receiver continues to move without adjusting speed or direction to catch the ball OR the receiver is impeded/makes contact with/boosted by an interceptor after the pass is made
The catch is made.
Result: Good Pass, Good Catch.
reasoning: a clean pass is easy enough to understand. i thought in the 'OR' option that maybe the passer should be penalised. but gave them the benefit of the doubt.
Scenario 2
Auto pass activates
The Receiver continues to move without adjusting speed or direction to catch the ball
The receiver is boosted/impeded/makes contact by an interceptor
The catch is not made by receiver
Result: Bad pass only, +1 for intercepter
Reasoning: I believe it's the passers responsibilty to ensure the 'line of sight' for the receiver is clear... bit unfair here as sometimes interceptors can boost in.. but balances with scenario 1, i'd say.
Scenario 3
Auto pass activates
The Receiver makes adjustments to speed or direction (excluding z-axis)
The catch is not made by the receiver nor is the ball intercepted in the time it should take to get to the receiver (<-tricky one)
Result: Bad catch only. Extra penalty if the receiver was blinking 'pass me the ball'
Reasoning: not the passers fault the receiver wasn't paying attention.
Scenario 4
autopass
ball intercepted or deflected on the way to the receiver.
result: bad pass, regardless of whether catch is made or not. Nil penalty if passer was killable in one hit. +1 to interceptor if the catch is not made
reasoning: if the catch is made then its luck. Only the passers fault tbh unless they were under pressure.
not sure how useful this would be though - its quite simplistic......
but i wrote it in response to:is a distinction going to be made between bad passers and bad catchers? (if possible)
unfortunately not. if you got a good algorithm for a bad catch ........
That's a good point. I think a bad pass is considered to be one that was intercepted. I'm starting to look over the pont sysyem as I can in my off time and I'm starting to insert reporting lines that will remove the need to manually upload the client side stats.
I have a idea that I want to test tonight where I will attempt to run a modified serverside build of DB2.3 (most likely on BuD2) and record some teststats. UTStatsDB just entered a new beta release as well. I will definately have to modify that to accept and track the Defender/Attacker/Keeper/Passer scoring. If anyone good with PHP/MySQL wants in on this effort, step up please! I am learning everything as I go, so any experienced hands will certainly speed this project along.
I have a idea that I want to test tonight where I will attempt to run a modified serverside build of DB2.3 (most likely on BuD2) and record some teststats. UTStatsDB just entered a new beta release as well. I will definately have to modify that to accept and track the Defender/Attacker/Keeper/Passer scoring. If anyone good with PHP/MySQL wants in on this effort, step up please! I am learning everything as I go, so any experienced hands will certainly speed this project along.
well theres a couple of scenarios i've missed out, I'll consider posting it when i have more time and if someone thinks it would be useful. But the logic behind this seems sound enough - having re-read what i wrote.
Whether or not someone can/wants to use it is really the question. I don't think the passing stats would be meaningful unless the quality of catching was taken into account too.
Whether or not someone can/wants to use it is really the question. I don't think the passing stats would be meaningful unless the quality of catching was taken into account too.
Getting closer to submitting the changes to the 2.4 cvs. Here's a peek:
343 P 4 Saves
343 P 3 MissedGoals
345 P 4 BadPasses
345 P 3 ball_intercept
345 P 3 BadPasses
345 P 6 ball_intercept
346 P 6 GoodPasses
351 P 2 Saves
351 P 4 MissedGoals
357 P 2 GoodPasses
357 P 3 BadPasses
357 P 5 ball_intercept
357 P 5 GoodPasses
360 P 6 BadPasses
360 P 3 ball_intercept
362 P 3 MissedGoals
365 P 3 GoodPasses
366 P 2 GoodPasses
369 P 3 MissedGoals
373 P 3 Goals
373 P 4 FailedSaves
373 T 1 1.00 ball_tossed
373 S 3 0.00 ball_thrown_final
Still have some bugs to work out, but it's looking up.
343 P 4 Saves
343 P 3 MissedGoals
345 P 4 BadPasses
345 P 3 ball_intercept
345 P 3 BadPasses
345 P 6 ball_intercept
346 P 6 GoodPasses
351 P 2 Saves
351 P 4 MissedGoals
357 P 2 GoodPasses
357 P 3 BadPasses
357 P 5 ball_intercept
357 P 5 GoodPasses
360 P 6 BadPasses
360 P 3 ball_intercept
362 P 3 MissedGoals
365 P 3 GoodPasses
366 P 2 GoodPasses
369 P 3 MissedGoals
373 P 3 Goals
373 P 4 FailedSaves
373 T 1 1.00 ball_tossed
373 S 3 0.00 ball_thrown_final
Still have some bugs to work out, but it's looking up.
Can someone please explain to me what exactly should be shown in the matchstats in UTStatsDB for Deathball? Obviously we wouldn't be displaying frags. Also, I notice that the game description includes the version number. This should be changed to just "Deathball" in future versions so it doesn't try to create a new gametype entry every new revision (which would also cause it not to process correctly since the stats wouldn't know what specific gametype it is).
Also, I'd appreciate it if someone could send me as current a version as possible so I can use it to test with the stats.
By the way, hello, I'm the developer of UTStatsDB....
Also, I'd appreciate it if someone could send me as current a version as possible so I can use it to test with the stats.
By the way, hello, I'm the developer of UTStatsDB....