Talk:Horizon/Version History

May be it is too late, but in 1.1.1, following updates:

• In the movement, GF arrays are now cached with each wave so that they don't have to be recalculated every tick. (Technically, this means that the bot doesn't consider data obtained since the wave was fired, but that shouldn't make much of a difference.)
• Changed the movement to use precise predicted max escape angles for GF -> bearing offset calculations, like the gun.

will make your movement worse.

The first one, I used to do that too, but says start of the match and you orbit the enemy at full speed (Musashi trick) and you get hit, if you update danger for every wave than it would surf the other way immediately, but if you cache the danger, then you will continue being hit for at least 2-3 time more.

The second one, well, I think you should look at oldwiki:MaxEscapeAngle for more information.--Nat Pavasant 02:44, 2 October 2009 (UTC)

As far as the first, it shouldn't be hard to adjust the code to expire the cache when new data becomes avaliable. About the second point: The wisdom I hear around the place is that 'precise predicted MEA' is good for targeting but bad for movement. Bad for movement because it makes your stats less consistant with how most enemy guns would see you. --Rednaxela 02:51, 2 October 2009 (UTC)

For the second change, if you read the updates after 1.1.1, you'll see that I immediately rolled back the precise predicted MEAs in the movement. As for the first change, I doubted that it would make much of a difference, but I didn't think of the Musashi trick problem. I'll look into recalculating the caches of the GF arrays when I log a hit / bullet hit bullet. I need to do some refactoring with the caching code, anyway. « AaronR « Talk « 07:08, 2 October 2009 (UTC)

That's why I said 'too late'. About the caching GF array, try look at DrussGT. He uses the 'surfStatsChange' global boolean which set to true every time he records new hit, and reset it to false every time he re-sums buffers. --Nat Pavasant 07:38, 2 October 2009 (UTC)

It's funny to me that the old wiki page referenced actually includes AaronR saying he tried and abandoned precise MEA in movement once before. =) --Voidious 14:08, 2 October 2009 (UTC)

Hey man, any reason to leave two versions of Horizon in the rumble (beyond a temporary basis)? You can always revert to a previous version if a new one falls short. Not a big deal, but I think the "one version" rule is a good one. (Actually, I also see four versions of PaulV3 and three Merkava's...) --Voidious 22:25, 9 October 2009 (UTC)

I'm going to stop the "two versions" thing as soon as I can match 1.1.1b's performance. Technically, I'm still just trying to unbreak the changes I made back in 1.1.1. I didn't expect it to take this long... « AaronR « Talk « 22:41, 9 October 2009 (UTC)

Ah, gotcha, my bad. Good luck - I've experienced much similar pain in the MeleeRumble in the last few months... so frustrating! --Voidious 22:47, 9 October 2009 (UTC)

Horizon 1.1.1b vs 1.1.2a

I'm trying to decide whether I've finally caught up to 1.1.1b and I can get on with new development. The current rankings show +/- 0.16 APS, 3.4 Glicko-2 after over 2000 battles. Statistical anomaly or actual performance difference? « AaronR « Talk « 07:22, 11 October 2009 (UTC)

I'd consider that right on the borderline. I have had a rerelease differ by 0.1% APS in the 1v1 rumble. My advice would be to post a rerelease of 1.1.1b - that's the best way to find out, I think. --Voidious 16:04, 11 October 2009 (UTC)

I was actually thinking the same thing before I posted my question. I already have a 1.1.1x version ready to post--it's just 1.1.1b with the properties file edited directly in the jar. « AaronR « Talk « 20:03, 11 October 2009 (UTC)

Clustering? Who needs it?

Answer is ABC --Nat Pavasant 12:48, 18 October 2009 (UTC)

And AaronR, apparently. I was sort of relying on this change to implement my flattener. The problem I have with my old clustering mechanism is that my buffer could return all non-hit recordings, which, if the flattener is off, would be weighted zero when summed into a GF array. I previously worked around this with the tick waves in the gun by multiplying their k-dimensional distance by a constant (forcing them to be nearest neighbors less), but that was just a hack and, as v1.1.3 demonstrated, less effective than weighting them less in the GF array calculation. How do other bots implement this? « AaronR « Talk « 21:36, 18 October 2009 (UTC)

In the gun, one of the dimensions I use is based on gun heat, so non-firing waves will always be further from the firing situation (gun heat = 0) and less likely to be used. In the movement, I have multiple sets of scans, each with its own kd-tree. For whichever sets are enabled (e.g., the flattener), I select the nearest neighbors "cluster" for that set, calculate the danger, and sum it into a total danger from all the different sets. --Voidious 21:49, 18 October 2009 (UTC)

Multiple trees, don't know why I didn't think of that. Thanks. « AaronR « Talk « 22:31, 18 October 2009 (UTC)