Talk:LittleBlackBook

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

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)

Wow, 1.58 has 7963 battles in mega... yep... clients sure working away at it when things were messed up before... :) --Rednaxela 03:55, 15 January 2010 (UTC)

Today was a huge update! Managed to redo and find roughly 20ish more bytes!!! Desired distance from enemy table became approach angle table for a big savings. Found 2 bytes in the averaging code. Came up with a new way to do bullet detection that costs only a couple more bytes than my simple one from before. Added Ramming ability. Overall, this bot will be weaker as the dodging stuff was so tightly coupled into the random movement, but next version will keep the massive increases against the simpler, linear aim bots while improving the general movement. This bot could very well reach top 5 in Micros. I have also decided that my string tables will not exceed 200k as per the Rumble rules to make it fair. Right the tables are sitting at 100kish and won't get much bigger until I add the Minis some day. I am now awaiting the results to see which bots are now broken and need another revisit :) --Miked0801 01:33, 16 January 2010 (UTC)

Tables, tables, tables. Fixed 30 or so bots thus far that I had weakened with the improved oscollation code. This put me above where I was at 1.59. I've got roughly 30 more bots to modify to get back to where 1.59 was against all bots. That's a good days work. Then, there's a revisit to change some bots from random movement back to oscollation for a nice boost. The new and improved energy detection code as made me weaker overall against PM bots. I'm working on a solution to this now. If I can find one, that's another 2APS overall or so and makes this a contender for the Micro crown. Then it would be on to the minis. Big talk though; gotta get there first! --Miked0801 19:15, 18 January 2010 (UTC)

Reviewed the movement code a bit because it still felt heavy and figured out a way to do near perfect stop-n-go movement. Good enough to fool Smog 90/10. It requires a bit of table wrangling to do though so I'll wait for version 1.70 or so to do it. I've still got lots of bots to tweak before I add yet another movement mode for maybe 5% of my opponents. Actually, stop-n-go overlaps most of my current oscollator bots so I'll have to review which helps more. I could use my extra few bytes to improve my gun instead by increasing the random range it uses for the index a bit more. Or again, look perpendicular velocity segmentation which is still a bit out of reach. Lots of choices here. Perhaps it's time for some heavy roboresearch... --Miked0801 19:27, 20 January 2010 (UTC)

Latest version I accidently bugged Fuatisha and lost 5aps on him. In addition, I removed the minor random added to the aim and lost .25 overall APS and gained back a bunch of bytes. Improved micros a ton though. Now, I'm sitting at 240 bytes and looking into its next improvement. It will cost 0 bytes to added near perfect stop'n'go, but I inherit another string table. That would give me another full overall APS though so I will probably do it. After that, it's time to look into improving aim with my extra bytes. I may finally be reaching the end of what I can do on movement alone. --Miked0801 16:32, 22 January 2010 (UTC)

Added perfect stop n go with this version at the cost of 8 bytes. This, plus some TLC with some aim tables, has moved me up roughly 1 full APS in the rankings. I'm now #4 in micros and may hit #3 when things stablize - with a bugged ntc.Knowledge entry that cost me 40ish points in that battle. I also seem to have comfortably hit 2k Glicko in Nanos! Party! I'm also a hairs breath away from 2K in both rankings which would be a first. I found a new, flatter movement curve and randomized my aim a bit more on generic bots for a good overall catagory bump. The same pattern can be used to help my scores against the top micros next time around. Hopefully, no reds on the micro screen sometime in my future. Still have 4 or 5 nanos I just have a very hard time beating. I'll keep working at it though. Fuatisha, you are an awesome bot. Next upload goal is 3rd in micros approaching 80 APS. We'll see if I can pull it off. --Miked0801 07:32, 27 January 2010 (UTC)

Looks like 3rd in Micros is achieved. Also, this build may give me a perfect PL score in Nanos. Fuatisha is the only question mark right now. I actually found a movement pattern that confuses some of the string PM guns and gained a nice chunk off the top bots in nano land. That means next updated will be mostly concentrating on Micros to see if I can approach 81% in the Micro rumble. That will be difficult, but doable. If I get there, then I am a micro crown contendor with my silly little nano. I also have a new home computer coming online this weekend. Hopefully reobocode is 64-bit Windows 7 compatible. Should be. If so, I will have roughly 10x the computing power I have right now for roboresearch and should be able to put together a first pass on mini-bots sometime next week. If it goes smoothly, I may just setup some scripts and add all the bots just to see if I'm top 100 overall or not yet. That would be a trick. Wow this bot has come far... --Miked0801 22:51, 28 January 2010 (UTC)

About 50% complete with first pass at minibot tables. I have good movement types for them all, now am porting across aim. Then, I test against distances. Then, rebuild with best distance and test. Should take another 2-3 hours. I might get to that tonight. I will also probably pass the nano/micros back through a test pass again as well, now that I have enough CPU power to do a decent pass in a couple hours as opposed to a couple of days. Next release, I will skip to 1.70 because I'll have updated roughly 20% of the tables. I have no idea where I'll land against the minis, but not top 10. Initial testing is showing just how strong the top 5 bots in that division are. --Miked0801 18:55, 2 February 2010 (UTC)

Sigh - compiling with minibot data crashes the java compiler. My bot cannot get any bigger than micro with this technique. --Miked0801 05:47, 3 February 2010 (UTC)

Perhaps try a java bytecode disassembeler/assembler to hack the additional string length in? That might work to circumvent any compiler crashing unless it's a limitation inherent in the bytecode standard itself. --Rednaxela 06:09, 3 February 2010 (UTC)

Solved it! Too many character concats blowing up the compiler. How to fix? I just discovered how to put a unicode literal into a string "\u008f" becomes character 8f! This also has the added benefit of making many, many of my entries a much more readable single constant that I can static const final declare above. I will also be able to use a real IDE again as my current version crashes ecclipse and visual studio. Happy days for unicode literals! --Miked0801 16:20, 3 February 2010 (UTC)

Learned some Java things the last few days:

• \u000a, \u000c, and \u0022 (\r, \n, and "), when put into a string literal, are treated as a raw symbol meaning you have to \ them or use a seperate symbol.
• Non-aligned tables make for bugs that are very hard to find. Much debugging was needed to fix these bugs.
• RoboResearch on broken bots doesn't help much in terms of strength judging.
• The top minis are STRONG!

I have 1 more day of tweaking and then an update. --Miked0801 05:26, 6 February 2010 (UTC)

Chugging lots of numbers this weekend - ran roughly 100k battles over 2 days, testing ideal range from target from 100 to 380 units per opponent. The results of this tuning pass will appear as soon as I find 2 or so hours to comb through the results and adjust my range table. On average, I was getting a good 5-10% APS kick every 3rd robot or so, but I also know that with such a large update, I will accidently break a few bots as well. Still, when this pass is complete, I could be contending for micros overall. Minis - not sure where I'll land, but at least top 20. Fuatisha, I may finally have a marginal (52/48) solution for, but that's too small to count on. --Miked0801 19:00, 8 February 2010 (UTC)

BAH! 1.67 jar is partially corrupted so the source isn't available. Lame. It also has 10 or so bot bugs to fix. I'll get those taken care of tonight and get a new version reloaded. --Miked0801 18:16, 9 February 2010 (UTC)

Just uploaded a test for initial movement vs no dodge against 0.1 bullets and yes dodge up to 3.9 power change. Also may stick to walls slightly more. I know that this helps against ram bots, but am curious if it helps elsewhere. I've also fixed the mess that was 1.67. When adding that many entries, mistakes will be made. With 1.69, I finally got 10% ahead of the nearest nano, an achievement in itself. I think I found 1 more byte in the aim code if I want to redo 1/2 the aim values. The typecast to short can be dropped if I change my negative aim values to 2*Pi - values as I'm normalizing my gun anyway. I'll do that if the intial movement change turns out decent and I want the slightly better dodging code back. Then I do another comb through for 1 more byte. Always 1 more byte :) I'm now also thining about PhoneBook, a micro bot based on the lessons this bot has taught me. I won't abuse string literals like I have with this bot as I'll have enough room to handle things more elegantly (at first!). I'm also going to make another pass through Infinity and DustBunny, using my new tricks to save a ton of space. That may free up enough space for them to go on a new melee run. For fun, I've calculated what it would require to brute force the best possible bot with this technique and it would cost about (40^6 x 30 x 8 x 20 x 50 x 100) x numBots=800 x numSeasonsToGetGoodResult=10 or 7.86e20 battles run. Even at 1 battle per second, I don't think I have time to wait around for this result to appear. And this is with some culling already built in. Perhaps I'll check out JGAP or something for fun to see if a genetic algo comes up with better answers than what I've been doing. --Miked0801 22:59, 12 February 2010 (UTC)

Some rough calculation told me that even at 1000 battles/second, by the time the result appear, out sun will be White Dwarf for 2E10 year already ((7.86E20)/(86400*365*1000) - 5E9 approx. = 1.99E10, give or take leap year) --Nat Pavasant 04:48, 13 February 2010 (UTC)

Funny how taking out "code improvments" actually gained me between .25 and 1.0% APS in divisions. Now I'm sitting at 243 bytes with 6 bytes to spend on whatever. I also believe I may have figured out a cheap size way to get (averaged) lateral velocity segmentation in. If it works, I will be micro champion and will challenge for minis. Just need some time to see if it works - or I can go optimize some tables a bit to squeak out another 1.5% in micros and try to win that way. Either will work given some time. --Miked0801 08:16, 14 February 2010 (UTC)

I've coded in average lateral velocity / distance segmenting on my local copy at the cost of only 2 bytes. I'm not happy with my data gathering method though. With simpler bots like el33tGangstar <sp> or Infinity or even spinbot, I should be able to get a near 100% lock on rate with my gun and my test bot is currently not able to do this. I even added in a segment for acceleration/deceration/steady to see if perhaps that was the issue without luck thus far. Or am I being too perfect here? Amazingly enough, multiple segments isn't as easy as I thought it would be. Perhaps that's why there are so many different ways of doing this out there right now. If I can get my dataset cleaned up, I can test it against 10-20 bots and see how much of a difference it will make. It will fix my current weakness against multi-mode moving bots as well as make my data tables in general more efficient in space. I'll basically be trading 80% of my movement tables (which are mostly unused anyways) for additional aiming information which can be very useful. I can also explore segment size being controled via a more complex formula than e.distance() / CONSTANT to better pack my data into useful areas - with size cost being controlled. Perhaps something like a bell curve centered around 200ish distance. Perhaps even something like AmplitudeConstant * Math.sin(Math.min(e.getDistance * Constant, maxRange)). That costs around 27ish bytes so maybe I'll just stick with the original :) If I do get this to work, it means revisitng every stinking entry in the bot; AGAIN. Man that sucks --Miked0801 21:57, 16 February 2010 (UTC)

It's been a while and I have been doing various experiments. I've now got my helper bot generating a profile based on acceleration, avg angular velocity, distance, and fire power. I've also calculated the math such that I have a very good idea if a particular GF bin or sets of bins actually hit the target or not. From that, I can compare the various fire power bins to get a points per tic calculation to determine what firepower is most effective at what range calculation. So, I now have a system to automate firepower at distance selection. Just that alone put into the current LBB framework would probably grab a full aps and perhaps more. But, I'll be adding an additional module to the test bot to iterate over the various movement profiles I've created. If it can alternate best movement check, best gun check, and iterate back and forth until both values agree, I've now automated most of the table creation process. Once that works, then I can use this new process to generate a set of tables for angular velocity vs distance vs firepower tables and perhaps even acceleration if I can find the code space. This of course is time consuming. Ambitious, but if successful, I'll have a very, very nice bot upgrade and a low labor path to adding all bots regardless of codesize catagory. I envision a time where adding a new bot is just a matter of running my test bot against it a few thousand times until the numbers stabilze. If I place the movement checks into an external xml or whatever table, then I have a way of adding new movement types at will without recompiling. A fully automated LBB table system. This of course could be used as a spring board for larger, more complex bots in the future. --Miked0801 18:07, 22 February 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)

Fuatisha

Well, it's nice to see that my nano is giving you so much trouble! Would you happen to have any idea why LBB seems to be having more trouble with it than other adaptive movement nanos? Of course, I wouldn't just be trying to figure out the best things to tweak in it......--CrazyBassoonist 03:34, 14 February 2010 (UTC)

It's a number of things:

• It really doesn't have a weakness in its good at any distance I can exploit. Moebius had a weakness at 260.
• It's movement is adaptive - my gun is not. Plus it has a Very flat movement profile.
• It's gun is just really, really good.
• The opening stop/go movement has a signifigantly different GF profile than its later movements meaning I have to give up hit percentage later to get it out of its opening gambit.

Basically, it is a better overall fighting bot than NeophytePattern and Moebius, but does worse against weaker bots. If you were to tune anything, tune agaist the masses and you'll probably get #2 (and help me!) :) --Miked0801 05:27, 14 February 2010 (UTC)

2013-07-09 tables updated by nz.jdc and re-released as mld.jdc.nano.LittleBlackBook Michael if you ever return to the game and update LBB then please delete this one, it is just an interim update to remind people of true evil that is LBB :)

It was fun while it lasted...

Very cool that you managed to pull this off, nice work!

Wow - thank you for that! It's awesome that you were able to figure out what the heck those tables were about. I came here expecting to see LBB towards the middle and was pleasantly surprised. :)

Went and downloaded latest client and found it is not supported by rumble. Will try an earlier one when I get a chance. Confirmed that NZ did indeed figure out very well indeed how LBB works. I've found my old test harness and it all still works. Now to find the 2 hour block required to get a couple of bots added. BTW, if anyone is a student of Digipen, I now teach a class there in addition to my current job so come look me up. --Miked0801 (talk) 16:29, 1 September 2014 (UTC)