#FF.Pickup All-time Records added

[squeek.]

Originally Posted by beees

Why aren't you summing an estimated average*C into the numerator
Isn't the formula bavg= (values + approxavg*C)/(C+numval)?

Yeah, that's the next step. I thought it wouldn't matter since all I care about is the relative values of the Bayesian average (all due respect to the Bayesian people and their culture), not the Bayesian average itself (on Wikipedia it says: "In cases where the averages' relative values are the only result of importance, m can be replaced with zero."), but I'll fix the formula and see what happens.

[aleXtric]

Originally Posted by Bayesian man

White men have been using the name of our people for centuries in their mathematics without regard to the heritage, culture, or attainments of that which they steal from.

My Great-great-great Grandfather was one of the most respected men of our tribe in SouthEast Bayesia, he united the Ssengubar, Lutgeinkt, and Qw'sayloo clans in an effort to what led up to the last assualt of our race on the invading white man in the battle of Isandlwana.

That was the pinnacle of our battle with the white race and soon ended, because of succumbing in the later skirmishes to superior technology. The naming system your race often chooses to use is an unfortunate tactic in history, as the reason the Bayesians were defeated was the use of "white man's magic" or hence "his mathematic" of which the Bayesian forumulas were used in the artillery bombardments of 1882.

My people were honorable warriors, please respect them and their memory when using our name.

has to be nine

[beees]

Originally Posted by squeek.

Yeah, that's the next step. I thought it wouldn't matter since all I care about is the relative values of the Bayesian average (all due respect to the Bayesian people and their culture), not the Bayesian average itself (on Wikipedia it says: "In cases where the averages' relative values are the only result of importance, m can be replaced with zero."), but I'll fix the formula and see what happens.

Hmm, relatively speaking, I don't think it'll matter then. Simple analysis would dictate that each average would just have a constant factor added, which means the order is the same. That is, for A/f > B/f > C/f implies A/f+c/f > B/f+c/f > C/f+c/f. By the way, I don't understand how you can get 100%. It shouldn't even be possible if you're using bayes...

[squeek.]

Originally Posted by beees

Hmm, relatively speaking, I don't think it'll matter then. Simple analysis would dictate that each average would just have a constant factor added, which means the order is the same. That is, for A/f > B/f > C/f implies A/f+c/f > B/f+c/f > C/f+c/f. By the way, I don't understand how you can get 100%. It shouldn't even be possible if you're using bayes...

Yeah, you're right, it shouldn't matter much if at all. I might still do it because if I calculate the global averages I could also display them somewhere and they might be interesting on their own and to compare to individual records/personal bests.

I only use the Bayesian average for ordering; the real average is displayed. See Wicked_Clown's entry here: http://parser.ffpickup.com/v2/record...AM_0:1:4454243

[beees]

Instead of an arbitrary c, why not use a percentage of the total (ie. 1% of all players)?

[squeek.]

Originally Posted by beees

Instead of an arbitrary c, why not use a percentage of the total (ie. 1% of all players)?

I'm going to do it (as far as I know) totally correctly, and make the C for each record the global average of the "total" for that record. Like what I said in a previous post:

(global average of time played on offense * global average of scout as offensive class choice + sum of time played as scout) / (global average of time played on offense + total time played on offense)

so C = global average of the "total" and m = global average of the average being calculated.

I've not set it all up quite yet, but I've been testing to see the results, and, as an example, the Average Blue Pipe Kills values currently work out to: global average blue pipe kills (m): 5.3538 (calculated as total blue pipe kills / total rounds of demoman played) and global average of rounds of demoman played (C): 25.6489 (calculated as total rounds of demoman played / number of players)

[Lynus]

these stats are stupid, we want to see who has the best conc aim, the longest button hold on %map while %class, the amount of damage done as %class, the most airshots w/ rockets/grenades/pipes, the quickest cap on %map, the time spent in enemy respawns, most jumppads destroyed in yard on phantom, most kills while flag is in the yard, etc.

[KubeDawg]

quickest caps would be nice.

[ddm999]

Originally Posted by Lynus

these stats are stupid, we want to see who has the best conc aim, the longest button hold on %map while %class, the amount of damage done as %class, the most airshots w/ rockets/grenades/pipes, the quickest cap on %map, the time spent in enemy respawns, most jumppads destroyed in yard on phantom, most kills while flag is in the yard, etc.

And you've just described everything FF can't do until someone adds more LogLuaEvent()s to base_teamplay. :P

Stats for best conc aim means tracking every shot fired by a player while they are concussed, meaning logs become even more gibberish because every line is filled with stuff about missing conc shots / hitting conc shots.

Kills while flag is in yard can't be done because map makers never use the default location_yard trigger that comes with base_location because they can't be bothered to find what it's called.

Tracking the button isn't that easy either as most map makers don't use a LogLuaEvent() for when security goes down / up. Seem to remember a certain map doing this, so maybe it's in base_security, you know, the thing no-one really uses.