Difference between revisions of "Talk:LittleBlackBook"
Darkcanuck (talk | contribs) (→Bot Blog: fixed + some notes) |
|||
Line 81: | Line 81: | ||
::: "... fixed an issue on my local client"? Please don't edit results.txt or upload any old results! Best thing to do is delete all files in the roborumble/files and roborumble/temp folders and start fresh -- preferably with uploads disabled for the first run just to make sure. --[[User:Darkcanuck|Darkcanuck]] 21:27, 14 January 2010 (UTC) | ::: "... fixed an issue on my local client"? Please don't edit results.txt or upload any old results! Best thing to do is delete all files in the roborumble/files and roborumble/temp folders and start fresh -- preferably with uploads disabled for the first run just to make sure. --[[User:Darkcanuck|Darkcanuck]] 21:27, 14 January 2010 (UTC) | ||
+ | |||
+ | :::: Not what I did. I have 2 copies of Robo installed. I created 1.59 in version 1.6.1.4 and it was 256 bytes in size. oops. I then fixed the problem and recreated it in my other version of robocode, but stupidly called it the same thing. I then took this version and copied it to both builds. But, the codesize.txt never updated to the new, reduced size for the updated lbb. Therefore, it didn't record roughly 30ish nano battles. When i noticed this, I completely killed the cache, the local 1.59 file, and removed it from the codesize file so that it could recreate it. This worked, but those 30 or so nano battles were lost as has since confused the server quite a bit. Another side effect of this is that when you first run the client, it correctly runs version 1.59 of LBB, but further iterations always run the previous verion. Long story short, be careful about versioning of bots... --[[User:Miked0801|Miked0801]] 21:45, 14 January 2010 (UTC) | ||
:: This is weird... If you look at its roborumble details, 1.58 only has 3 battles: [http://darkcanuck.net/rumble/RatingsDetails?game=roborumble&name=mld.LittleBlackBook%201.58]. Only 2 for mini, but lots for micro and nano. Not sure how that would happen... The server tries to run all pairings for each version (after a certain point), even if it's retired, so maybe that's what's going on. If you delete 1.58 from your rumble dir, it won't run 1.58 any more. (But anyone that has 1.58 will until it has all pairings, if that's the reason.) --[[User:Voidious|Voidious]] 18:51, 14 January 2010 (UTC) | :: This is weird... If you look at its roborumble details, 1.58 only has 3 battles: [http://darkcanuck.net/rumble/RatingsDetails?game=roborumble&name=mld.LittleBlackBook%201.58]. Only 2 for mini, but lots for micro and nano. Not sure how that would happen... The server tries to run all pairings for each version (after a certain point), even if it's retired, so maybe that's what's going on. If you delete 1.58 from your rumble dir, it won't run 1.58 any more. (But anyone that has 1.58 will until it has all pairings, if that's the reason.) --[[User:Voidious|Voidious]] 18:51, 14 January 2010 (UTC) |
Revision as of 22:45, 14 January 2010
Congrats!
Congrats! It's nice to see some movement in the nano scene lately. I was pondering predefined data bots myself actually. I'm curious though, you say "Any perfect dodge stop and go will kill it", which seems odd to me. It should be quite trivial for a distance/lateral segmented GF gun to hit that I'd think... --Rednaxela 01:51, 15 June 2009 (UTC)
- Math.signum() off e.velocity screws up 0 velocity checks and I have no velocity averaging. I'll check other bots for inspiration though. Has to be TINY though
- What about...
static double foo = 1; foo = e.velocity + 0.01*foo; foo /= foo;
? Not sure if that would be small enough, and I haven't checked it's codesize, but I think it's smaller than any others ways to handle that which come to my mind. I think it's smaller thanstatic double foo = 1; foo = (e.velocity == 0) ? foo : Math.signum(e.velocity);
anyway, since conditionals and function calls are expensive if I remember right. I'd also suggest seeing if you can get rid of the need to normalize the value to 1/-1 all together, but that may not be possible in this case. --Rednaxela 04:15, 15 June 2009 (UTC)- Anything having to do with statics are expensive. Your above code is probably around 25 bytes or so. Math.signum(e.getVelocity()) is 6 or so. I can easily fix my problem by adding +1 to the e.getVelocity() check on the inside of the gun( for 2 bytes)... But! It will only hit perfect stop/go 50% of the time as it is setup to use the velocity to know how far to lead. Also, bots like FretNano who have good guns, but get stuck on walls randomly, would then be unhittable. I get 1 lead value per distance segment at the moment. I've got a few ideas on how to improve this, though it will double+ the size of my string table. I will adhere to the 200k max limit and with 1000 or so bots to profile, I have to be careful on size. --Miked0801 13:38, 15 June 2009 (UTC)
Hi! Awesome results! Now that I looked at the code, I think there is one little problem with the overall concept: every time a new robot or a new version of a robot appears, you have to update the stats in your bot. --HUNRobar 10:31, 15 June 2009 (UTC)
- And a decent problem it is. I'm going to review the string libraries today to see if I can find a "closest to this name" type function for my search. That'll at least handle versioning. The version in there right now is using default behavior against Pugio because my table is setup for 1.40. When all your other versions get cleared from the rumble, my rating will go up another .5 or so. --Miked0801 13:38, 15 June 2009 (UTC)
Nice! I may re-release Ocnirp 1.0 to screw your stats =) Updated Wikipedia page for you now. » Nat | Talk » 12:00, 15 June 2009 (UTC)
- Don't bother, I'm already using default values against that bot so it wouldn't make any difference so Nyaa Nyaa! :) --Miked0801 13:48, 15 June 2009 (UTC)
- Really? I don't think so. (default is 50-40-30-20-10-0, right?). Beside, I'm working on Nano adaptive movement (Mysterious is its fail attempt) =) » Nat | Talk » 14:03, 15 June 2009 (UTC)
- Ok, you win. There are quite a few bots taht got default cases though. For some reason I thought Ocnrip was one. And, yeah, nice string match there. I could fit that if, oh I don't know, I took out all my movement code ;) --Miked0801 14:20, 15 June 2009 (UTC)
- Really? I don't think so. (default is 50-40-30-20-10-0, right?). Beside, I'm working on Nano adaptive movement (Mysterious is its fail attempt) =) » Nat | Talk » 14:03, 15 June 2009 (UTC)
Thanks! Links and work email address removed. --Miked0801 15:27, 15 June 2009 (UTC)
- He he, the revision system still have it. =) » Nat | Talk » 15:32, 15 June 2009 (UTC)
- Yep - but at least basic spider bots won't pick it up and spam be about male enhancement products :) --Miked0801
Ok, new version in the wild. I expect this release to be better against stronger bots, but I also expect some startlingly poor results against a few bots. These I can tune back to either the old values or a combo of new and old. Stelo.MirrorNano being an example. My next release will beat this bot 90/10, but now LBB is losing 45/55. No panic :) --Miked0801 02:04, 18 June 2009 (UTC)
- Good result. My next update tomorrow is going to absolutely destroy the competition. This is going to be a 1900+ rating bot. --Miked0801 05:45, 18 June 2009 (UTC)
Bot Blog
Seems like a decent place for random ramblings. The averaging code is doing its job, it just needs some table number TLC. Alas, it also screwed with some other scores that will need attention. I also commited a cut and paste errored with nat's SNG 1.0b bot resulting in a 6% score. Lame. I may try taking the averaging back out and using firepower control instead. It'd probably help me more overall to fire at 3.0 firepower at range 80 or 120 and closer against everyone. The Micro scores have been decent thus far with their first autogeneration pass. 19th is a good starting point and I know I can get to 15th or even 10th with some work there. I'll drop the mini scores in Tuesday or so and for another overall ranking boost. I still believe I can get this bot to a 2k points score with over 80%APS in nanos with a few revisits to lagging numbers.
Wow, a good day. Found another 10 bytes by just re-arranging the stack vars. Used that space to try out variable move distances. Helps quite a bit against the weakest bots. Also fixed bugs with a few bots that came from typos. Finally, I fixed poorer results against rambots wehre I wasn't aiming right at range 40 and in. My scores are now approaching DrussGT's against the low-end bots. Using that bot's scores gives me a reasonable target to short for. I'm also going to experiment with variable firepower as well, though for some reason I keep pushing back on that - dunno. Next release tomorrow night. Shooting for APS of 78ish in nanos. That would put me close to my goal of a 2k score. Hopefully, my micro score will get me top 15 there as well. I'll start running Minis by end of week to see if I can get top 25 there and perhaps top 100 overall (aiming real high, I know.) --Miked0801 03:38, 23 June 2009 (UTC)
- You should to remember the Code Size/Cheat sheet. The most important part is the vars-on-register, which is discover by Simonton I think. » Nat | Talk » 11:02, 23 June 2009 (UTC)
- I just rearrange them all until I get the smallest result :)
Another good day, but I found a dumb bug I introduced to my table generation a few days ago which will require me to revisit all the nano values. Sigh. Good news though, found another 8 bytes or so by declaring the string table final (never changes so I should have done it ages ago) and by rearranging a few typecasts to make sure we got int on int math wherever possible. That means I now have both distance and firepower control in the table! It hurts by aim a touch from 80 pixels and in, but for 1 more free byte I could fix this. I'll keep looking. 8 more bytes and I get variable string matching, though if firepower or move control prove poor, I can always swap this in for the other. Because I have to do a table revisit, I'm pushing my release back one more day. Who'd have though a variable GF, variable firepower, variable move distance, variable turn control bot could be done through a silly string table. It's like the synthesis of all the best nanos in one place. Next release will have some bugs, but the one following will be absolutely epic. --Miked0801 18:48, 23 June 2009 (UTC)
Bleh. Had to work late a few nights. I'm just now getting all my initial micro/nano runs complete. Good news is that only Moebius is currently able to consistantly beat me now in nanos. I'm going to experiment with distance control next as many bots are optimized for certain ranges and I expect I will do well at varying ranges against many bots. If it works well, I'll trade something off to get it. We'll see about a tomorrow release, work allowing. --Miked0801 07:39, 25 June 2009 (UTC)
Played around with enemy distancing and found it helps (much) more than firepower control. But, my test cycle is too far along to scrap and start again so I'll go ahead with what I have. Besides, I believe I found a way to fit all 5 factors into this nano anyways - Fire Power, Chance to reverse direction, Min Distance to move, desired distance from enemy, and Guess Factors. It requires my tables to be created differently (again), but I'll go for that next version. This is why I haven't bothered with minis or megas yet - the tables flux dramatically with each version. It also means yet another multiplier when creating my tables. I'm already running 20+ versions per bot through roboresearch. Adding distance is another x4 or so. Yikes. Back to 1 good test run and cull, cull, cull so that I have time to balance what makes sense. At least my testing methods are improving so that this doesn't take too long. Just need 1 more set up data to finish up for the guess factors and then we'll put this bot back together again. --Miked0801 07:29, 26 June 2009 (UTC)
Ok, version is up and we gained nearly another 2% APS in nanos and even more in Micros. Nice. There's still a few bots that came out a bit half baked, even with all the care I put into the tables before releasing. I'll revisit those for one last version 1.5x release and then go onto version 1.6x with distance control. Still shooting for 80+% APS, a perfect PL score in nanos, and 2k in ratings. 72 Glicko's to go. --Miked0801 02:59, 27 June 2009 (UTC)
Hey, you've taken my micro's place in the microrumble! I really should do something right after I finished my flash game. ;) --HUNRobar 17:31, 27 June 2009 (UTC)
Dang it. Screwed up robar.nano.Scytodes 0.3's table, which costed me 50-60 battle points and .33 APS in the Nano Rumble (.15 in micro). Savant values are weaker too, but that can be attributed a little to random luck. Beyond that, a very good update. Solidly in 11th now in Micros and 1.5% APS from 80 in nanos. That's only 260 battle % points and 50 of those are from my above mistake. But, without distance control, I'm running out of big gains. I can probably push this bot to 80% APS and 2k Glicko without distance, but it will take a lot of work. I made a lot of gain my swapping appropriate bots to 2.0 fire power. Some of those I can switch back to get some ground I lost between 1.52 and 1.53. I did tie for the PL score this time and would have had it if not for Scytodes. Next version I'll get it right. I think I'll release a 1.54 just to try for 10th/9th in the micros without distance help. --Miked0801 03:46, 29 June 2009 (UTC)
Well fixed Scytodes and decided to alphabetize my list and lo and behold I had missed 4 other bots - all micros. Adding those gave a decent score increase for them as well and would probably challenge Jen for 10th. But, I went ahead and started the HUGE roboresearch database needed for my next release. We're talking around 1 Million battles to be run before all is ready. I'm guessing my computer running 24/7 will get through this info in around 3 days. Wow. The good news is that my previous run is compatible so I saved 150k battles or so. All this will put me over 80APS in Nanos and will put me well into top 10 in micros. I'll know for sure once I start seeing some comparison results against the micros. The top nanos appear to be weak against different ranges, but I'm not sure on Micros yet. I'll post tomorrow with some initial results. --Miked0801 21:30, 30 June 2009 (UTC)
Test run about 15% complete. I'm tuning back to breadth of the first run to speed it up so I can play before next week. --Miked0801 02:18, 2 July 2009 (UTC)
33% done and I'm not patient enough to wait for it to go much further so I put together the next version - and had another awesome idea on how to make it do more for less. I now have distance control and! - all other factors also are available based on distance as well. This means variable firewpower on distance. This means I can change my move mode out of oscillation at those distances where I run into head-on shots (around 280 or so). I can even change my desired distance based on distance meaning I can ping-pong between values to help with multi-mode movers and to throw off pattern bots. That plus partial string matches and I'm sitting at exactly 249. That's enough tech for my goals. Now it's time to do my last pass through the nano/micros and see just how much pwnage will be wrought. 85+ nano APS isn't out of reach.
Work, work work. My job is heating up to the point where things have been on hold for a bit. This will continue for a few more days - grr. --Miked0801 17:39, 8 July 2009 (UTC)
And even more work. I'm in crunch mode now and barely have time for breathing. I've still got my next bot upgrade ready, jsut need to find a couple uninterrupted hours to fix a few minor things. I'm still alive guys :) --Miked0801 20:44, 27 August 2009 (UTC)
Good to hear =) I'm also pretty snowed under, but it seems that when that happens Robocode becomes my outlet =) --Skilgannon 20:55, 27 August 2009 (UTC)
Project starting to wrap up - we'll see if life returns to normal soon... --Miked0801 16:30, 6 October 2009 (UTC)
Project's done! Vacation is started. Updates to follow :) --Miked0801 16:28, 6 December 2009 (UTC)
- Yay, welcome back! =) --Voidious 17:18, 6 December 2009 (UTC)
Ok, Nanos mostly refit. I want to find another 1.5% of APS then its back to micros. Mostly hand tuning at this point. --Miked0801 22:46, 17 December 2009 (UTC)
Actually changed a little base code with this version. I removed the adjustTurnForGun() call and replaced it with a bit of randomness added to the range index. This results in slightly more random ranges when firing. It makes it easier to hit multi-modes, bullet catchers, and wave surfers, but hurts my score against really, really weak bots and the best nanos a bit. Still, seems like a decent upgrade. Broke 2 nano bot solutions with this chagne that I can easily retrofit back to pwnage. I will also be able to make a further micro pass to get above Jen on my next update. I beginning to believe that this might get top 5ish in micro before I'm done. --Miked0801 00:07, 9 January 2010 (UTC)
FYI, this bot needs to be compiled with Sun's Java Compiler in order for it to remain byte size complient. Got bit with that today. Made a major pass through the tables using the top Mega bot's scores in comparison to mine for inspiration on who to fix. Found many, many bots that were improved 10% APS or more. This should be the version, barring bugs, that hits 80%APS or even 81% APS in nanos - and should also hit 2k Glicko. And there's still a bit (not much!) more tuning that can be done. There are countless ways of ordering my tables to get 1-5% individual APS tweaks that I probably need a seperate program to find. Overall, this has ben a wonderful experiment and mega contenders should take note. I'll continue to tune it a touch more, but I'm also going to investiage Lateral Velocity segmentation as well. If I get inspired, it may not cost too much :) --Miked0801 23:07, 13 January 2010 (UTC)
Results looking very nice so far, though not sure if it'll quite end up getting past 2k Glicko. What I find most impressive is how you fit so many movement modes alongside a GF gun, in a nano, that's an awful lot of movement modes for a nano, particularly with the distance-based selection of them! :) --Rednaxela 03:50, 14 January 2010 (UTC)
- Thank you! I'm a rather proud parent of this bot and all comments make me grin :) --Miked0801 15:49, 14 January 2010 (UTC)
BTW, the build system seems to be completely confused at the moment. Would it help if I released a 1.60 version to fix it? --Miked0801 15:49, 14 January 2010 (UTC)
- What do you mean by "build system"? --Voidious 16:24, 14 January 2010 (UTC)
- Was about to ask the same, nearly got edit conflict :) --Rednaxela 16:33, 14 January 2010 (UTC)
- At the moment, the rumble is only running LBB 1.58 (retired), not LBB 1.59. I believe it is because 1.59 lost roughly 30ish nano battles whilst retaining the micro and up battles before I fixed an issue on my local client. I could upload the missing nano battles and that may fix it, but I wanted permission to do so first as I would need to edit the results.txt file manully to add the missing numbers. --Miked0801 17:42, 14 January 2010 (UTC)
- "... fixed an issue on my local client"? Please don't edit results.txt or upload any old results! Best thing to do is delete all files in the roborumble/files and roborumble/temp folders and start fresh -- preferably with uploads disabled for the first run just to make sure. --Darkcanuck 21:27, 14 January 2010 (UTC)
- Not what I did. I have 2 copies of Robo installed. I created 1.59 in version 1.6.1.4 and it was 256 bytes in size. oops. I then fixed the problem and recreated it in my other version of robocode, but stupidly called it the same thing. I then took this version and copied it to both builds. But, the codesize.txt never updated to the new, reduced size for the updated lbb. Therefore, it didn't record roughly 30ish nano battles. When i noticed this, I completely killed the cache, the local 1.59 file, and removed it from the codesize file so that it could recreate it. This worked, but those 30 or so nano battles were lost as has since confused the server quite a bit. Another side effect of this is that when you first run the client, it correctly runs version 1.59 of LBB, but further iterations always run the previous verion. Long story short, be careful about versioning of bots... --Miked0801 21:45, 14 January 2010 (UTC)
- This is weird... If you look at its roborumble details, 1.58 only has 3 battles: [1]. Only 2 for mini, but lots for micro and nano. Not sure how that would happen... The server tries to run all pairings for each version (after a certain point), even if it's retired, so maybe that's what's going on. If you delete 1.58 from your rumble dir, it won't run 1.58 any more. (But anyone that has 1.58 will until it has all pairings, if that's the reason.) --Voidious 18:51, 14 January 2010 (UTC)
- Wow... this is very weird... the "Last Updated" times for LittleBlackBook 1.58 keep going
up in mega/mini (and different update times from mini/nano), but the battle count is only increasing in mini/nano! Something is broken on the server side I think.... because all clients with LBB 1.58 (like mine) are ONLY running LBB 1.58, but the Rumble isn't recording the mega/mini results so it looks like it'll go on forever... --Rednaxela 19:46, 14 January 2010 (UTC)
- It should be fixed now. Looks like a concurrent retirement/reactivation. My guess is one client saw no battles for 1.58 in the last 4 hours and started to retire it, first for the general rumble then the mini. But then another client uploaded new battles (either due to old results not yet uploaded or an old priority file) while the retirements were in progress leading to the corrupted states. I have a permanent fix in mind, but it will require a lot of testing which I have yet to find time for... --Darkcanuck 21:27, 14 January 2010 (UTC)
LBB Cheeze Factor
I added PEZ's LittleEvilBrother, because it also had a String based GF gun, I believe. There was some discussion about whether or not it was cheesy to load data for a bot not capable of saving data. Consensus at the time was that it was cheesy, but judging by how much better LittleBlackBook does, it seems like a pretty cool strategy that has a lot of room for experimentation. Plus there's been nothing new in nano-land for years! --Alcatraz 03:09, 26 June 2009 (UTC)
- I'd be of the opinion that it is cheesy, but don't object to keeping it around, at least till something particularly new happens in nano-land :) --Rednaxela 04:26, 26 June 2009 (UTC)
- It's extremely cheesy an exploitive of a loophole in the codesize tool. Yet, I'm having some real fun with it right now (and this game is supposed to be fun! :). I literally believe I can get this bot as a top 10 in the micro competition as a nano. That's something that hasn't been done since just after we decided on weight classes. Right now, I'm still crunching a rather exhasutive set of numbers for firepower and movement types. Once that's done, I'll grab the numbers and give it a test run to see where it stands. Good chance it will go in tonight. --Miked0801 05:15, 26 June 2009 (UTC)
- Well, I wouldn't call it "exploitive of a loophole in the codesize tool" exactly (unless someone makes a highly capable interpereter within nano size), since such preloading of data specific to certain bots is also cheesy for megabots. I think what's cheesey most fundumentally, is when a bot that looks up the enemy on a preloaded table based on bot names regardless of codesize. --Rednaxela 13:11, 26 June 2009 (UTC)
- I for one don't like this though, but it is acceptable for me. Unless, like Rednaxela, someone make a good enough nano-size compiler and fit DrussGT into nano. I'll not object, but I do think that when you fully tuned this robot to the top and have no more idea, you should retire this robot. » Nat | Talk » 13:30, 26 June 2009 (UTC)
- Of course I agree that preloading data is kinda cheesy, but I think everyone understands that LBB is of a different ilk than other NanoBots. It's cool seeing how far you can go with it. To be honest, I think even hand-tuned segmentations are similar to pre-loading: with a different rumble population, different tunings would surely work better. We all take the rumble population into account when we write our bots; pre-loading is just a more explicit way of doing so. --Voidious 14:10, 26 June 2009 (UTC)
- Yep, it's cool to see how far LBB can go indeed. It is true that we all build our bots in way that considers the rumble population, but I don't think pre-loading itself is the cheesy thing. For one thing, I wouldn't consider it cheesy at all, if a GF gun preloads with the average data of a bunch of rumble bots, until it's learned enough about the specific enemy (hint, hint). I think tying pre-loaded data to a specific bot name is where the 'cheese' begins, but more general pre-loaded data is simply prudant rather than cheesy. --Rednaxela 14:34, 26 June 2009 (UTC)
- Personally, I think the only issue here is that pre-loading is used to get around the size class limits. A bot that saves its own data is fine by me, whether it's general or specific -- the 200k limit restricts how much you can really store anyway. LBB is a novel concept, but it would be disappointing to see it inspire a new generation of string table nanos/micros/minis. Now if you could make a nano that generates its own string tables, that would be really cool. You still have a few bytes left, right? ;) --Darkcanuck 15:02, 26 June 2009 (UTC)
AceSurf
I noticed you make not of AceSurf being a problem. One possible solution (if you can fit it into the codesize) that would probably work well, would be having a special code in your data that says "Aim at the last GF it went to". I'm kind of thinking that would probably eat too much codesize... but I think that's probably the simplest thing that could be done with the likes of AceSurf, besides random targeting anyway. --Rednaxela 16:00, 20 June 2009 (UTC)
- I'm not too worried. This bot just hit the 1900 club - the first ever in nanoland to do this. This is with untuned tables for 1/2 the bots. I will take a closer look at ace.surf results though and possibly setup alternating guess factors at every 40 pixels. This has been the best way recently to smash wave bots as it is nearly the same as 2 different guess factors every few shots. Wow I proud of this bot. I might be able to get it to the 2000 club when all is said and done. It just needs another 1000 percentage basis points or so. Plus, right after this bot was released, I figured out a way to better hit stop'n'go's without reducing accuracy against simpler bots who just get stuck. Next release will be fun! --Miked0801 16:06, 20 June 2009 (UTC)
- IIRC, The club score is base on ELO, not Glicko-2. » Nat | Talk » 16:13, 20 June 2009 (UTC)
- then Toorkild isn't in the 2k club. I was pretty sure it was the Glicko. But, it all may be mute. I just realized how few battles it has run - only about 1 per bot. I'll therefore wait a bit before posting anything further on that :) --Miked0801 16:17, 20 June 2009 (UTC)
- We're in a weird position with the clubs because it was based on ELO on the old server. ELO on Darkcanuck's server is way lower than it was on the old server, and Glicko-2 is a bit higher -- at least in MegaBot and MiniBot 1v1. As a point of reference, before the old RR server hit a few months of non-stop upwards drift, Dookious was about 2130 and Komarious was about 2085 in mini (prolly a few points higher now). Nevertheless, it's still easy to compare your bot to the competition, arbitrary rating systems aside. =) --Voidious 16:26, 20 June 2009 (UTC)
- The new server originally matched the old one, but ELO has drifted steadily downwards in the past few months. Why, I don't know. In late 2008, Glicko2 and ELO were in the same range, but now they're quite different. Maybe it's all the recent activity, plus some long-standing bots were removed earlier this year too. In any case, ELO is a relative ranking system so it's the difference between the scores that matters, not the absolute values. But it does leave the ELO clubs in a funny position. --Darkcanuck 17:34, 20 June 2009 (UTC)
- IIRC, The club score is base on ELO, not Glicko-2. » Nat | Talk » 16:13, 20 June 2009 (UTC)