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?

Yeah, maybe I'll just do that for now, but I definitely want to fix any broken links on the participants lists too. On first pass I wanted to build the minimal set required for a superpack so I had it download everything individually.

Uh oh, I'm getting a StringIndexOutOfBounds exception. Did you do something to the PM string?

Ah, forgot to increase the minimum look-ahead distance for the PM, now that it isn't limited to 14 ticks of history. Fixed.

So is user1.user2.* the "new hotness" naming style for collaborative bots instead of wiki.* ? Or is it a subtle distinction between specific team-ups and totally wide-open bots? I kind of like the wiki package, though I also kind of thing it should be 'robowiki'. (I put RoboRunner in 'robowiki.runner' package.)

I think these kind of team-ups have been around for a while, eg there was usa.nano.Nemo which was in package usa because both creators were from the USA. I think wiki/robowiki package is great for stuff which is specifically released as public domain, like BasicSurfer, as well as test bots like DrussiousGT, and code/utils which is meant for people to use and hoist, but I see no problem with collaborative bots.

Can't remember if we were the first, but I know Chase and I used user1.user2.* for Scarlet. The thinking was a subtle distinction between specific team-ups and totally wide-open bots, but I'm kind of on the fence about "user1.user2.*" vs the wiki package. It really was a test bot like DrussiousGT, though the thinking was to leave it up there till either Chase or I surpassed Scarlet individually (though Scarlet has been removed despite that point not yet being reached due to some performance issues it had).

On the subject of the wiki package, now that you mention it, I'd say I would prefer "robowiki." over "wiki." for sure.

Rednaxela‎

Yeah, Scarlet was the one I remembered, but now I also recall GeomancyBS, which was "synapse.rsim". I think "usa" package was more because of the Robocode Olympics.

I wasn't passing judgement, just curious. :-) I can certainly see why user1.user2 makes sense as different than wiki package.