Difference between revisions of "Talk:LittleBlackBook"
(no problem.) |
|||
Line 32: | Line 32: | ||
: You should to remember the [[Code Size/Cheat sheet|Code Size/Cheat sheet]]. The most important part is the vars-on-register, which is discover by Simonton I think. » <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> » 11:02, 23 June 2009 (UTC) | : You should to remember the [[Code Size/Cheat sheet|Code Size/Cheat sheet]]. The most important part is the vars-on-register, which is discover by Simonton I think. » <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> » 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. --[[User:Miked0801|Miked0801]] 18:48, 23 June 2009 (UTC) | ||
== AceSurf == | == AceSurf == |
Revision as of 19:48, 23 June 2009
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)
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)