Talk:GravityWave/Tests/Archive June182009

The fact that you're losing rounds makes me think that you have a bug which makes your bot freeze occasionally. What about putting a try/catch in all your event handlers and main method, and if there is an exception writing the details of where you are, the enemy is, how many waves there are in the air, the game time, etc. I modified DrussGT not to shoot, and here were the results for 500 rounds:

1st	jk.mega.DrussGT 1.3.8	18250 (97%)	13250	5000	0	0	0	0	500	0	0
2nd	mld.DustBunny 3.8	612 (3%)	0	0	612	0	0	0	0	500	0

This has very little to do with segmentation, and is mostly about getting every single last bug out of your surfing. It looks to me like you might need some Dive Protection, as you are getting a significant amount of ram damage. I'm not sure if you have any form of 'escape movement' for when the other bot is very close and there is an enemy wave in the air. What could be useful is taking a standard random-movement from a non-surfing bot and using that for when there are not waves to surf, or the enemy is very close. Hope this helps on your quest for 85+ (and I suspect higher) --Skilgannon 19:49, 14 June 2009 (UTC)

I've been having the same suspicion about there being bugs, and the segmentation not at all being the problem. I very very strongly suggest you change back to head-on targeting bot for tests like DustBunny 3.5, or (the 'classic') HawkOnFire, and with it's movement disabled at least at first. Against an unmoving head-on targeter, you should be able to take as few as one hit per 100 rounds, or even fewer. If a bot can't... then chances are it needs to work on the non-segmented basics more before worrying about segmentation details. --Rednaxela 21:53, 14 June 2009 (UTC)

Alright, I'll start working on non-moving targets. I think why my scores are so low is because I don't have any buffers for my arrays, so it's pulling a 0 danger until hit. I'll worry about that later, after I work on Dive Protection and the movement a bit. --Jacob Litewski 22:20, 14 June 2009 (UTC)

Oh, well in that case, one additional suggestion, would be to place a danger at GF 0 (aka, assume the enemy is head-on until data says otherwise), when where is no data in currently read segments. In fact, pretty much every surfer I know of does this when it reads no data, so I was assuming you aready had that. --Rednaxela 22:41, 14 June 2009 (UTC)

I don't think I do. GravityWave, currently, is just a modified BasicSurfer, and BasicSurfer does horrid verses HOT-type guns. When I get Time, I was going to look into Dookious and DrussGT and get ideas on how to fix my problems. --Jacob Litewski 00:33, 15 June 2009 (UTC)

Well yes, BasicSurfer wouldn't, but virtually every one in the top 50 rankings does I think. Also, your sudden score loss when DustBunny is stationary seems quite odd, and indicates to me your own movement is trying to move you into very very close range, and that DustBunny's attempts to move away actually worked in your favor since you aren't firing right now. That kind of thing gives me the impression that you should be watching your bot in action and looking for when it gets in close range or freezes or something. And again, I'd suggest moving to a head-on targeter like DustBunny 3.5 or HawkOnFire, because then, almost any time you see your bot get hit will warrent investigation and cannot be attiributed to anything except your bot taking a fairly blatently wrong action no matter what data it has. --Rednaxela 01:59, 15 June 2009 (UTC)

Yea, GravityWave does try to get close (within 200 pixels). I tried to weigh the Array with distance, no change. I also tried to pre-buffer the Array with this:

System.out.print("Creating HOT Buffer... ");
for(int x = 0; x < 13; x++) {
	for(int y = 0; y < BINS; y++) {
		_surfStats2[x][y] += ((12.0-(double)(x))/6.0) / (Math.pow(HALF - x, 2) + 1);
	}
}
System.out.println("Done.");

So the closer he got, the heavier the danger weighed, I believe. The only thing is, GravityWave is always within 200/300 pixels of the enemy. He's also really stupid and tries to squeeze between the robot and the wall... So I'm guessing that I need to add in some sort of something to fix it... i just don't know what's wrong. --Jacob Litewski 20:56, 15 June 2009 (UTC)

---

I found out why GravityWave is sucking so much. If it's wallsmoothing, it doesn't factor in where the enemy is at, and if the enemy is close to the wall, it'll turn into him. I'm going to try and reverse wallsmooth (aka, turn counter-clockwise) if GravityWave is Close to the enemy (within 300 pixels should do). Hopefully this works. --Jacob Litewski 16:56, 16 June 2009 (UTC)