Crazy Ideas

First, we initialize integer to 255 to save a byte. :)
Then, in the PM code we use (integer = integer >> 1), instead of (integer = integer - 1).

If I'm right (which I rarely am), this would be smaller, faster and smarter. How does it sound to you?

Sounds good. I did a geometric reduction of the key length in Toorkild as well, and it worked fine.

Hmm, for some reason, under Jikes, both of those changes add a byte of codesize. Any number above 127 takes an extra byte, and >> is one more byte than --

Were you using Jikes when you compiled Toorkild and got the weird savings from 255?

Yes, but I was using it for an array size, so that might have been something else happening.

So, if we do it just like Toorkild and use 64 as the initialization value, and use integer /= 2 instead of --integer, we should break even at 249 bytes, right?

Also, I think we should try using power-3 bullets, or at least go back to power 2.6667. I think 2.33333... is a little too soft for a bot with such an aggressive movement.

If the changes work, then go ahead and release version 1.0.4.

integer/=2 takes an extra byte from --integer, but if we switch our bullet power to 3 we have that byte to spare. I'll package it up and release.

Huh, for some reason it lost a lot against weak bots. Do you think this is because of the PM change, the bullet power change, or the movement change? I doubt it was because of the change to the random multiplier, because the RM shouldn't even be activated against weak bots.

I think the higher bullet power made it waste energy quicker, giving it an extra loss or two, which pushed a bunch of bots over into the random movement instead of orbit/oscillate.

One thing I noticed while watching battles was if it starts from very far away it does loops instead of settling for a nice orbital movement. I'm thinking of decreasing the turn amount caused by the distancing, especially as it isn't as sensitive to that now that the gun can handle any distance correctly.

Okay. Let's change the BP back to 2.33... and the constant in the distance controller from 2500 to 3000.

We also might try doing 3/orbit + 3/oscillate + 94/random instead of 2/orbit + 2/oscillate + 96/random.

One step at a time, I'd rather have less sacrificial rounds against top bots and lower the bullet power, although that gets us right back to where we were. I also want to see where the threshold is, so how about BP 2.666?

Sounds good.

I have another crazy idea that would allow us to get rid of the distance variable. The problem is, it would cost about ~2 bytes in other areas. Should I try it?

Of course, give it a go. I'll see how it compiles.

Sweet, that saves 3 bytes, down to 246. I'll package and upload in the morning when I'm a bit more awake =)

Ok, that doesn't work because the absoluteBearing has been fully initialised and doesn't just use the e.getBearingRadians() value, so it goes in circles. Oh well, I was hoping for some more codesize there!

Try it again with a pair of parentheses around e.bearing + heading. That should fully initialize absolute bearing. If it doesn't, then there must be something else going on.

What were you planning to do with the extra space?

Nope, the problem is in the distancing, see the change I made that fixes the behaviour.

I'm not sure what to do with the space, but I'm sure we can think of something. Perhaps better bullet power selection for rambots or something like that.

I think I figured out a way to get those bytes back--at a loss of targeting accuracy. We'll see if it's worth it.

I highly doubt you'd be able to fit anti-ram in 3-4 bytes. But, it seems that almost every time I say that, you prove me wrong. :)

Ooooh, that is ugly ugly ugly. But this is nano, the king of ugly, so it would only be fitting if the king was ugly too. I'm not sure what we'd gain from rambots would make up for this, but it's worth a try I guess.

I'm not really worried about rambots; Yatagan already does fine against them. Let's just enter this version as it is, and see if the performance loss is substantial.

I'm not sure why, but it stayed at 249 bytes.