Code mods

Huge thanks.

Using a hard-coded distance in the pattern reconstruction was the main accuracy issue. Now that that's fixed, I think the 5 bytes required for the setAdjust would be better spent on Miked0801's char based energy monitoring.

I've decided to make this bot separate from Epeeist; and release it under the package sheldor.jk.nano. Any ideas for the new name?

char based energy monitoring? What advantages does it offer?

For names, how about Cutlass or Yatagan?

Ah, I see, using the unsigned property to wrap negative numbers so you don't need an extra comparison! Smart! Ok, that is in, total codesize 247 =) I just need your input on a name, and we're ready to go! Although, I think the whether-to-reverse decision could be improved by using a bigger divisor and different values in chanceOfReversing.

How's "Sting" for a name? It's small, blue, and extremely painful. :) If that's already taken, the Kukri is another great small sword/large knife. But, if you don't like either of them, go ahead with "Yatagan;" I like the sound of it.

How's this for a description?
<botname> v1.0.0 by Sheldor and Skilgannon. 03/20/2013
<Short description of namesake>
Codesize: 247 Bytes without any colors.

You're probably right that using different reverse probabilities would help against certain bots, but that sounds like a lot of hand-tuning, so let's save that for the next version.

Once you've packaged it, go ahead and add it to the literumble, and then post the source code on the wiki, under <botname>/Source.

Think I'll go with Yatagan, I'll package when I get home. Although I found a bug in the one optimization I did, so I'm going to have to find something else to shrink, it is at 251.

I might've found something to shrink. Here it is:

Change the chancesOfReversing to 30, 15, and 0; and then, change this line from:

direction *= (chancesOfReversing.charAt(deathCount) - (2 * Math.random()));

to:

direction *= (chancesOfReversing.charAt(deathCount) / integer - Math.random());

I didn't compile, so I don't know if it will work.

That will be integer division, so won't give fractional results. I'll find something though.

One byte down, one to go!

I made a little breakthrough, and now have 4 more bytes to play with. So, is it worth changing the bullet power to 3 if I can add back setAdjustGunForRobotTurn() ? Or is there something else I should go for? I need bullet velocities to be in integers, so bullet powers of 2, 2.333333, 2.666666 or 3 are the options. I don't have much experience for making these kind of judgement calls in nanoland =)

Awesome!!!

Power 3's are fine, especially since the distancing is so aggressive. Though, if you're not worried about rambots, 2.667 might be a better general purpose bullet power.

Getting the setAdjustGunForRobotTurn(true); back is low-priority, but if you can fit it, go ahead. On my compiler, setAdjustGunForRobotTurn(true); costs 5 bytes, not 4. If it doesn't fit, we can save a byte by switching the constant in the energy monitoring code from 1.09 to 1, though it would be slightly less accurate. I forgot to mention that earlier. Oops.

Turns out that version also had a bug, but it is up now, bullet power 2.66666 and 247 bytes, just need to wait for results. I also noticed that the LiteRumble hasn't properly stabilised the nanorumble, so we'll need to wait for that to happen too. I re-enabled priority battles for all of the rumbles (it was off for the nanos, micros and minis), it seems that my 'it will give them all battles' theory didn't mesh with a lossy 'eventually correct' implementation.

FYI I have a client running, but it lacks a bunch of bots with broken URLs on the participants list. One of us should take a pass at fixing those sometime. I'll see about it in the next couple days if nobody else does.

Can't you just dump the contents of the latest zip from Rednaxela's site?