-
Welcome to Smogon! Take a moment to read the Introduction to Smogon for a run-down on everything Smogon, and make sure you take some time to read the global rules.
-
Congrats to the winners of the 2023 Smog Awards!
(Un)Official Smogon University PO Stats -- August 2011
- Thread starter Antar
- Start date
- Status
Surprising, as I assumed usage stats would put much less stress on the server than battle logs (but then again, I've never looked into that plugin).
Who is in charge of the Smogon server ? I wouldn't mind modifying it to show whole teams, ratings or any other relevant information in the server logs (they wouldn't show up on the user side even if I wanted to), without any significant impact of performance.
This is going to come out kind of rude, but I'm not meaning to be--I'm just being blunt: have you actually downloaded and looked at the PO code? Are you really familiar enough with Qt that you feel comfortable rewriting the code?
If so, that would be AWESOME. Contact Blue Kirby--he's in charge of the server now.
[Edit: for Innocent Criminal or whoever else wants to help and has the programming knowhow, what we really want is for the server-side battle logs to contain, in addition to what they contain now, (1) player ratings and (2) full teams, with items, natures, EV spreads and movesets. That is the Holy Grail. With that information, we can do anything.]
...Wait. I don't know about you guys, but my PO server shows both teams in the log at the beginning of the battle (I guess it's version 1.0.24 ?__?). We could easily use that.
Considering we can't get the players' ratings at the moment of the battle, I'd say we should take every team into account, even the losing ones (forfeits and disconnects would skew the stats even more if we went with only the winning player's team). Besides, "lol PO rating sucks", so I'm not sure I'd like using it to determine the stats... unless we go with weighted ones...
Very interesting... by "My PO server" do you mean, as in you run your own PO server? Or do you mean your PO client?
lol sorry, I meant "my PO client". It's version 1.0.30, and it shows both teams at the beginning. As an example:
The only problem is this message I get whenever I log on Smogon Server:
So I guess the server's logs doesn't write down both teams. So, either we get the server updated so we can get at least full teams, or Innocent Criminal or somebody else do the whole work and we get every single piece of info on the server-side logs.
too bad.
No offense taken, but I already did much more than that and made this :
http://www.smogon.com/forums/showthread.php?t=3450212
http://www.smogon.com/forums/showthread.php?t=3450476
I put it on hold for several reasons, but it was fully functional and hosted hundreds of battles. I don't have much free time right now, but I've seen how battle logs work and tweaking them shouldn't take much time. I'll talk to Blue Kirby.
Lol just hosted a server and checked whether my idea would work or not...
Yeah, Innocent Criminal is the man we need.
We are super grateful for anyone who can offer programming help. I've tried to direct anyone who has offered their help to the necessary resources. Before this last week, we had almost no one who was willing to help, hence the dry-spell stats wise.
With regard to the usage stats plug-in: I believe the plug-in had to be installed during the course of the month in order to function. We didn't have the plug-in during August. Blue Kirby now has the plug-in and it is possible we will use it in the future.
With regard to the usage stats plug-in: I believe the plug-in had to be installed during the course of the month in order to function. We didn't have the plug-in during August. Blue Kirby now has the plug-in and it is possible we will use it in the future.
Standard Grass-types go down (Ferrothorn, Virizion, Shaymin)
Non-standard Grass-types go up (Tangrowth, Rotom-C, Abomasnow)
Make way for the new Grass-types!
Non-standard Grass-types go up (Tangrowth, Rotom-C, Abomasnow)
Make way for the new Grass-types!
Oh wow. That's amazing.
Sorry to call your programming skillz into question.
If Innocent Criminal can modify the log-generator to output all the relevant info to the battle log, it'll remove the necessity of having the plugin running. The battle logs will, in my opinion, be superior, since the raw data will all be there, and anyone with access will be able to do their own analyses and modifications. Still, it'll be nice to have the plugin auto-generate stats and those nifty webpages, since it'll involve NO human effort.
So when I saw these stats the first thing that popped into my mind was that the OU 3.4 cutoff point made the OU list itself shrink. Now I do realize that the actual OU list is determined quarterly, but even so the size of OU seemed noticeably smaller then it should. So I started to run some numbers, and I found some interesting things. In all of the previous generations the OU tier list was composed of approximately 10% of the amount of pokemon that were available. As such the size of OU each year increased proportionately to the amount of new pokemon released. So I decided to see what B/W OU would look like if that were the case. So I went and crunched some numbers and came up with a Cutoff % of 1.83.
With that cut off point it hits right at number 67 - Whimsicott. Which falls right into the ~10%ish range that all the other generations fall under.
So I am wondering, why is our cutoff point at 3.4%? Shouldn't the cutoff be closer to 2%? I am not saying that we should use 1.8 as the cutoff, but 3.4 seems really higher in a game where choices abound.
With that cut off point it hits right at number 67 - Whimsicott. Which falls right into the ~10%ish range that all the other generations fall under.
So I am wondering, why is our cutoff point at 3.4%? Shouldn't the cutoff be closer to 2%? I am not saying that we should use 1.8 as the cutoff, but 3.4 seems really higher in a game where choices abound.
This makes a lot of sense, actually. The amount of Pokemon and the cutoff should change at least semi-proportionately.
It should be the number associated with 1 out of 20 teams including that pokemon.
I say "should" because I've tried looking up where that number was derived from, and there really isn't any solid documentation on how that number was derived.
It's probably much better to, since we know how these current stats were derived, to calculate our own percentage that, taking into account how Antar collected that data, corresponds with 1 out of 20 teams having the pokemon.
soul_survivor
VGCPL Champion
wow i agree the OU tier should be bigger, have you seen the percent differences. from virizion to donphan is a .7% difference. To me thats pretty big difference from 44 to 52.
The only problem with changing the cutoff now would be that the lower tiers would change drastically, which might cause some problems for UU.
Stratos
Banned deucer.
Which doesn't make sense because if one in twenty teams uses the pokemon then it should have a usage of at the very least five percent, probably more due to there being two teams, but either way much higher than 3.4.
Tbqh, the method described there isn't necessarily the "1 out of 20" teams either.
Rather, the formula used, (1 - (0.5)^(1 / 20)), just means that Pokemon that are above the cutoff will, out of 20 random teams, have less than a 50% chance of not showing up at all.
In practice, for a pokemon exactly on the OU cutoff, a 3.41% cutoff means that if you battle exactly 20 random teams a day, and if you play for D days, you'll run into the pokemon on an average D/2 days.
However, that's not the same as the pokemon being in 1 out of 20 teams, and I'd argue that the current definition is LESS useful than the simplified 1/20 = 5%.
The main difference is that, a 5% cutoff means that if you play against T random teams, you'll run into the pokemon on an average T/20 of those teams.
That's a lot more direct and useful than the current definition, which only states that when you play against exactly 20, and only 20, teams, you have a 50% chance of running into the pokemon.
The current definition also doesn't differentiate between if you run into the pokemon 1 time or 20 times during that 20 match streak, so while it can tell you you'll run into the pokemon 50% of your exactly-20-match-long runs, it doesn't even tell you how many pokemon you'll run into on average during those.
I apologize if I didn't explain that well, but I think you know about probability well enough to get the gist of what I'm saying, and how a 5% (or 4% or 2.5% or w/e) cutoff would both be more meaningful and simpler than our current system.
- Status