Talk:Wave Suffering

I think it would help if we in this article listed many of the causes of wave surfing. That is to say the small details that usually hold up an implementation of wave surfing. Listing the usual problems will serve as a useful checklist for future wave surfers if nothing else. Considering I have never gotten past 'wave suffering' I am far from the idea author for this article. — Chase-san 11:23, 26 July 2010 (UTC)

Hi, I have a problem that I discovered while trying to perfect my wave surfing, though it may be unrelated. Basically, I am getting impossible values for the enemy position and it seems to be caused by some inaccuracy in my absolute bearings, which appear to be off by up to 20 degrees. What makes this even wierder, is that I calculate this value twice (once for my gun, and once for the wave surfing) and they are both identical, so I should't be accidentally changing them. As if that wasn't odd enough, I tested this morning and didn't notice this bug (the waves are painted with the centers at incorrect points, so I think I would have noticed this). Any ideas on what could be causing this? (I am perfectly willing to give the source code, but it is very long and the bot isn't quite ready for the rumble yet so I haven't uploaded it anywhere.)--AW 02:46, 30 March 2011 (UTC)

I'm not sure, that i correct understand you, but try launch wave not from current enemy position, but from previous enemy position. It's works for me. But in my model i at first update enemy state (process all events) and then launch waves etc --Jdev 06:09, 30 March 2011 (UTC)

In my code I have a function:
Point2D.Double doProjectPos( Point2D.Double startpos, double head, double dist){
return new Point2D.Double( startpos.x + (dist * Math.sin( head)), startpos.y + (dist * Math.cos( head)));
}
To get the position of enemy, I feed it mypos, (robot.getHeadingRadians() + e.getBearingRadians()) and e.getDistance(). I know it sounds a bit silly, but do you have your own position correct? Maybe there is somewhere a Math.toDegrees missing (or too much) if you are still working with Degrees. Print stuff to the console and step through the tics manually, so you could check the values you're using. Good luck with the bughunt. --GrubbmGait 07:18, 30 March 2011 (UTC)

Thanks, I am not sure that my position is correct, but this is a huge error (I have gotten the enemy's positions as (-40, some Y coordinate) )so I think I would notice. I have a screenshot of the error in abs bearing that I could upload to the wiki if I knew how.--AW 14:34, 30 March 2011 (UTC)

You can upload images with the "Upload file" link in the "toolbox" on the left side of the wiki. It seems to me if you draw the enemy location, your own location, and the line for the abs bearing, you should be able to see where it's going wrong. How do you calculate abs bearing? Nothing comes to mind as an obvious mistake you might make with these values, but it probably is something silly... --Voidious 14:43, 30 March 2011 (UTC)

Thanks, here is the link Media:WaveSuffering.jpg . I am sure I calculate the AbsBearing correctly, because one of the calculations is from the wave surfing tutorial and the other is, well, correct (getHeadingRadians() + e.getBearingRadians()). As for it being a silly mistake, no question there, "silly mistakes" is my middle name. And one more thing, in the picture, the top line is (nearly, off by one pixel) horizontal, the middle line is an absBearing of about 100 degrees, and the lowest line is about 130 degrees.--AW 15:09, 30 March 2011 (UTC)

So the bottom line appears to correctly point to the enemy bot. What are the other two supposed to be pointing to? Wave sources? If so, do they start off pointing to the wrong spot, or start off correct (touching the enemy bot) and then move off the battlefield? --Voidious 17:49, 30 March 2011 (UTC)

The lines were not actually drawn by the robot, they were drawn by me in a photo editing program with the top two lines drawn to measure the angle and compare. I started having the robot draw a line to the enemy and it works most of the time, but more importantly I turned the view scan arcs back on and realized that I am missing some scans. However, I was using the infinity lock given in the wave surfing tutorial and, though the gun is slow I never catch skipped turns. I added a call to adjustRadarForRobotTurn() and the positions appear to be correct now , but not the missed scans or the wave painting. PS. (though all reported positions are on the battle field, some are reported as erroneous because they are not contained in the "_fieldRect" rectangle. why is this set to 18, 18, 764, 564 in the wave surfing tutorial?) Thanks again--AW 18:38, 30 March 2011 (UTC)

Well, that is because on default field size, a robot's center can never be outside those coordinates. The robot is 36 units in width and 36 units in height, so it can never get closer than half that to the wall. --Rednaxela 21:11, 30 March 2011 (UTC)

Are you sure? 800 - 18 = 782 not 764. I get coordinates of about 781 sometimes.--AW 21:31, 30 March 2011 (UTC)

Alright I found the bug, I was calling execute() and this, for unknown reasons (I will go check the API now) made the wave distances one tick late. Thanks for all the help. (I am still wondering about the _fieldRect though) --AW 21:54, 30 March 2011 (UTC)

It sounds to me like you're calling a second function that that has an implicit execute() in it, such as "turnRadarRight", and hence calling execute twice per main loop. If the problem wasn't that then your bot would do *nothing* after you removed execute(), so... I'm quite sure that's the problem. _fieldRect is correct. 764 is the rectangle width, not the maximum value. That's what the constructor expects. --Rednaxela 22:40, 30 March 2011 (UTC)

Ah, thanks. Though it is not quite as ready as I would like, I have released GreatWolf. (I wanted to do it on my birthday.) -- AW 22:51, 30 March 2011 (UTC)

Happy birthday then :) --Rednaxela 23:25, 30 March 2011 (UTC)