From Robowiki
Jump to navigation Jump to search


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 than static 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)
HashMap<String, String> enemyGF; enemyGF.get(e.getName().split(" ")[0]); =) » Nat | Talk » 14:03, 15 June 2009 (UTC)
Um, wow. That does work: e.getName().split(" ")[0]. I rediscovered it myself and you had it here the whole time. I feel very stupid. Thanks for the advice! --Miked0801 06:13, 23 June 2009 (UTC)
No problem at all. =) » Nat | Talk » 11:05, 23 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)
That doesn't call fit, really. :P » Nat | Talk » 14:53, 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)

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)


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 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)