View source for Talk:GresSuffurd/Version History

0.2.13

Great work! I'm curious to see what you changed - that's quite a huge jump at that rating. Just a tweak or two away from returning to the top 20. =) Congrats! --Voidious 21:59, 14 September 2009 (UTC)

Thanks, but I didn't change that much. Only the wallsegment calculation of the gun is done differently now, next to the very small imperfection in the fireangle to fool BulletCatcher. I used to calc that by extending the current direction of the enemy with 75/150 pixels. Now I assume the enemy orbits me at constant distance and I extend their path with Maximum Escape Angle. I did not expect 22 Glicko-points from that change. 0.2.13 should be compared against 0.2.11 btw, the imperfection of fireangle in 0.2.12 is to big and causes quite some difference in score against other bots besides BulletCatcher. --GrubbmGait 22:43, 14 September 2009 (UTC)

0.2.24

The addition of the second, decaying, gun brought less points than I expected. Although the four bots with the worst difference just seem to have 'unlucky' battles. When I improved the gungraphics, I found a bug that was present since the time I used a kind of Precise Intersection, October 2006. It turned out that the killing bullet was never processed in my gun.

A bigger problem is that my bullets are not always are where I expect them, they should be on the cyan line (gun 1) or on the orange line (gun 2, decayed), but sometimes the bullet is half a botwidth away from either line. I really have to look into that. I still have one improvement I want to make in the gun, next to cleaning up that messy Wave class, and then I will switch to movement, starting with some updated graphics. I really, really want to pass that 'Swedish block' in front of me, the gap to place 10 seems a bit to much for now. --GrubbmGait 10:44, 26 January 2011 (UTC)

Good luck with that Swedish block - you're so close! I still remember when I first found the rumble, thinking, "wow, German flag at #1, but Sweden has 2nd AND 3rd place!" =) Is half a bot width of error so bad? I check if my gun turn is within half a bot width. --Voidious 13:52, 26 January 2011 (UTC)

The sequence I work with is: Fire Gun - determine bulletpower - Calc Gunturn - endofturn. When calculating the gunturn on time T, i approximate the data on T+1, so on time T+1 the gun should be pointing exactly right. (and I check if gunturnremaining = 0). Maybe I have to check the rules in what order things happen when calling execute. It may be not so bad, but it struck me as not what I expected. --GrubbmGait 15:59, 26 January 2011 (UTC)

I'm pretty sure you have it right with regards to the order things happen when calling execute. I use that same gun sequence, and have tested it for precision of wave position and angles quite a bit. --Rednaxela 02:14, 28 January 2011 (UTC)

I think I found the problem. On T+1 I store the wave with the 'HOTAngle' of that tick. I should use the angle I approximated on time=T for T+1. The offset should be max 4 pixels, both bots braking, but on screen it seems a lot more. Oh well, at least I now have gungraphics that are not useless. --GrubbmGait 11:13, 28 January 2011 (UTC)

0.2.27

I finally know why my development for this version has such a poor performance. I am currently implementing a 'firing bin limitation' to simulate precise MEA in my gun. I implemented it with fixed bin-layout, meaning the first bin is located counterclockwise and the last bin clockwise. It performed ok, but sometimes I couldn't hit a simple full-speed orbital movement. So I got busy changing things without any clue, resulting in bullets fired 'mirrored' to the HOTangle, bullets always fired left, bullets always fired at extreme MEA etc etc. Finally, this morning the truth struck me. In my gun, I use relative bins and not fixed bins. I mean, relative first bin is in the opposite of enemies current direction, last bin is in the current direction of the enemy. So, this evening the fixed version will see the light and will start chasing Firebird. Note: that misalignment of real bullets and virtual guns still exists. --GrubbmGait 14:11, 23 February 2011 (UTC)

About that virtual guns not matching the real firing angle, I managed to get rid of it by marking the *previous* wave as the one with the bullet, and not the current one at the time of firing, because it was the previous wave that was used to aim the gun to its current angle. Don't know if you've accounted for this =) Good to hear that you've sorted that out with your 'brute force precise gunangle' implementation, I always love it when old school tech can be hacked to allow for modern improvements =) --Skilgannon 05:56, 24 February 2011 (UTC)

Ok, released it, although I'm not happy with the implementation. I had to use some tricks to be able to hit rambots ??!! I don't expect it to pass Firebird yet, but YersiniaPestis should be no threat anymore. --GrubbmGait 22:24, 28 February 2011 (UTC)

I'm curious, what do you refer to by "tricks to be able to hit rambots"? I've considered precise intersection to be particularly useful for close range targeting actually. In Polylunar, I had 'special' close-range targeting that used precise intersection do find angles that would hit no matter how the enemy moved, when such angles exist. --Rednaxela 00:19, 1 March 2011 (UTC)

Against rambots (read GrubbmThree) I sometimes got a range that did not even cover head-on, and head-on is always a possibility. So the trick is to always include head-on. At steep angles my calculation regularly hit the brakes instead of just turning left/right and I haven't figured out a reliable solution yet. --GrubbmGait 06:04, 1 March 2011 (UTC)

0.3.1

In my gun I mark any bullet-hit-bullets as non-bullet waves... this doesn't affect my gun really as I don't weight 'real' waves higher. However, one thing that I found which helped considerably against WaveSurfers was not counting bullet-hit-bullet waves in my virtual gun chooser. --Skilgannon 15:48, 7 May 2011 (UTC)

0.3.5

Finally installed RoboResearch, trying to find the cause of the disappointing performance of 0.3.3 and 0.3.4. I must say that I should have done this a bit sooner, say 4 years ago. Running challenges is so much easier than scrolling through html files and filling in excel sheets. Now I have to come up with an acceptable testbed, just the challenges and my previous version is not really representative. Let the attack on Hydra begin! --GrubbmGait 22:43, 1 July 2011 (UTC)

The complete refactoring (0.3.25 to 0.4.4) caused a 0.3 APS loss and a 0.3 Survival loss.
But using passive bullet shadows really paid off: 1.1 APS gain, 1.5% Survival gain, and a jump in PL from 29th to 11th place ! So now I have to find somewhere 0.2 APS to get to 11th place, as 1.1 APS to place 10 is a bit to much to chew on.

Finally, reached 11th place.
The whole passive bullet shadows plus some tweaks was enough to get there with the skin of my teeth.
But how the hell can I find another full 1 APS to get to 10th or even 6th place, any ideas ?

Yeah, it is a bigger difference than expected. Long time ago a distance of 540 was better, but since then my gun and movement have improved. I would have made top-10 only with this if not those other annoying bots (Firestarter, ScalarBot) entered top-10 before me ;-) Especially dragonbyte.Neutrino triggered the experiments with distance, a pesky bot with quite a good movement, firing 0.1 bullets till around 40 energy.

Congratulations from me too ;) I’ve never tried to experiment on distancing that much, since I couldn’t get any better score with prefered distance other than 500 ;) Nice to see that worked again ;)

Although my testbed says otherwise, I expect this version to be slightly better than 0.3.8. My testbed predicts a 0.5 APS loss . . ., but frankly I don't trust my testbed regarding rumble-score. I should increase the number of surfingbins, because 37 is to low and inaccurate for bulletshielding. My attempt to set the surfingbins to 73 (version 0.3.3 and 0.3.4) were not a success though. I probably have the optimum setting for 37 bins currently. Still aiming to pass Hydra.

Have you accounted for the increased value from adding more bins? And scaling the width of any smoothing you're doing?