# 1.2.0

I noticed the problem with casting the energy drop to an `int`, but I figured that if an enemy was firing power 1s at a distance of around two hundred pixels, we would be able to get a score of 80+%, even with RM.

@Nz.jdc
This method saves two bytes over the conditional method (just enough to fit `setAdjustGunForRobotTurn(true)`). I don't think it is functionally different from a conditional check. If it is, I probably did something wrong.

Off Topic: I don't understand how your new Adept movement works. What's the point of `moveMode ^= 1`? Wouldn't that just return `moveMode` unchanged?

18:15, 4 June 2013

The old neophyte movement changed moveMode from 1 to -1 and back on every bullet hit. Then used direction *= moveMode to flip between orbit mode and oscillate mode whenever we get hit.

The new adept movement keeps that, but combines it with a yatagan style onDeath lookup table. However note that in adept onDeath uses moveMode += 2. ^ is the XOR operator, so on every bullet hit we toggle the low bit. This allows it to combine pure orbit, switch on death to pure oscillate. Do that a few times as yatagan does, then after several deaths it will go back to toggling between orbit and oscillate on every hit.

23:36, 4 June 2013

D'oh! I thought that carets were exponentiation operators. Your movement makes much more sense to me now that I realize they are inequality checks.

03:04, 5 June 2013

Sorry for being all pedantic about it, but I just wanted to make sure you understood that XOR isn't an inequality check.

if you have two numbers say:

a=1000101;

b=1011110;

then c=a^b; sets each bit of c to 1 iff that bit in a is one or that bit in b is 1 but not both. Otherwise the bit is set to 0. So c==0011011 is true.

Again. Sorry for being pedantic but I wanted to make sure that this was clear.

AW (talk)18:02, 6 June 2013

Thanks.

19:26, 6 June 2013

I ran some tests, and it looks like we'd only get a score in the sixties. I'm not worried though, because I don't know of a single bot in the rumble that would fire bullets less than power 1.0 at close range, except in the endgame. And even if there was one, it would likely have a HOT gun, which would be dodged by orbit movement anyway.

17:15, 10 June 2013

Well, let's see how it does! =)

20:17, 12 June 2013

Hmm, apparently not quite as good as 119. The scores may not have quite stabilised yet, but it has dropped down to second with 78.06 APS, about -1.2 IIRC :(

On the plus side I briefly get to retake the lead :)

Not to worry though, I have the superlatively evil (nasty, unpleasant, dishonourable, cheating or the insult of your choice) version 1.2 of PralDeGuerre under development. Now if only it performs up to the statistical predictions...

23:07, 12 June 2013

By the way, how much space is that move change saving? I think Sheldor said 2 bytes.
An alternative that might perform better (can't say for sure, you would have to benchmark it) would be to use the old move, but change the "... - (1.1 - 1e-8) ) <= 1)" to "... - 1) <= 2)".
This is slightly less accurate as the energy detect is .001..3.999 rather than .001..3.001, but it could work better.
You would also need to update the rand chance to be "4 / 0.6*Math.sqrt(..." rather than "3.0/(0.6*Math.sqrt(.." to account for the wider window.

23:25, 12 June 2013

The drop in score is due to two problems with the table. I just fixed both of them.

Yep, this method of enemy fire detection is two bytes smaller than the previous. The other `char` based check you just posted would be (going by memory here) only one byte smaller than the original, which would be one byte bigger than my new method.

00:56, 13 June 2013

It may be compiler dependent, I am just using standard jdk 1.6, but every time I have sized that it has been 2 bytes different.
1 is dconst_1, size 1 byte.
Any other double constant (except zero and possibly stuff that can be cast from an int constant) is
ldc2_w, indexbyte1, indexbyte2, size 3 bytes.

As to which is functionally superior I am not sure, I haven't done extensive benchmarking on that variant of Yatagan movement as those extra 2 bytes were not enough for me to add anything else, so I didn't use/test it much.

02:00, 13 June 2013

In Jikes that also saves 2 bytes. I think this would be a interesting one to try out after 1.2.1 stabilises.

05:08, 13 June 2013

Ah well, I had a few hours at the top, but it was not to last.
It has only had 1000 battles, but this version looks to have lost half a point from 1.1.9.

06:36, 13 June 2013

You do not have permission to edit this page, for the following reasons:

• The action you have requested is limited to users in the group: Users.

It looks like putting the oscillate first was the issue, 1.2.2 is tied with 1.1.7. I wonder if the `setAdjustGunForRobotTurn(true);` would be better replaced by `setAdjustRadarForGunTurn(true);` to cut down on the radar lock issues?

13:49, 13 June 2013

Version 1.2.2 isn't tied with 1.17, it's an all-around improvement. See a comparison here.

Infinity radar is fundamentally inaccurate. An adjustment wouldn't be worth the codesize.

16:54, 13 June 2013

Yeah, but even infinity lock will slip ~5x less if we change to setAdjustRadarForGunTurn instead. Seriously, it slips a lot, watch it in some battles.

18:44, 13 June 2013

I suppose we could try it.

19:03, 13 June 2013

That seems to have made quite a large difference. I suppose I should not be surprised about a pattern matcher not liking gaps in its pattern. @#\$!&* pattern guns, they are rather strong. I'm not sure even my cheaty dev version will have much margin over 1.2.3. I had better get back to the tuning. Or start praying for inspiration from saint Michael.

02:50, 14 June 2013