Difference between revisions of "Talk:BasicGFSurfer"

From Robowiki
Jump to navigation Jump to search
(Bug in BasicGFSurfer?)
m (minor update to inquiry)
Line 64: Line 64:
 
</pre>
 
</pre>
 
-- [[GrubbmGait]]
 
-- [[GrubbmGait]]
 +
 +
== Surfing Bug or Misunderstanding? ==
  
 
When I was comparing performance between my own wave surfing drive and the one used by BasicGFSurfer, there were some interesting performance differences that made me take a closer look at the BasicGFSurfer drive.  I was a bit confused by the use of _surfDirections and _surfAbsBearings.  The code in question is in the onScannedRobot method and looks like this:
 
When I was comparing performance between my own wave surfing drive and the one used by BasicGFSurfer, there were some interesting performance differences that made me take a closer look at the BasicGFSurfer drive.  I was a bit confused by the use of _surfDirections and _surfAbsBearings.  The code in question is in the onScannedRobot method and looks like this:
Line 70: Line 72:
 
             ew.directAngle = ((Double)_surfAbsBearings.get(2)).doubleValue();
 
             ew.directAngle = ((Double)_surfAbsBearings.get(2)).doubleValue();
 
</pre>
 
</pre>
This means the enemy wave direction and directAngle are always pulled from the 3rd item in the list, but items are never taken out of the list (accept when list is cleared at beginning of round).  So if I'm reading it right, BasicGFSurfer is using invalid direction and directAngle values, which probably makes it move more randomly than surfing.  Shouldn't it be pulling the direction and directAngle from near the end of the list, and not the front? [[User:Skotty|Skotty]] 14:19, 25 June 2011 (UTC)
+
This means the enemy wave direction and directAngle are always pulled from the 3rd item in the list, but items are never taken out of the list (accept when list is cleared at beginning of round).  So if I'm reading it right, BasicGFSurfer is using invalid direction and directAngle values, which probably makes it move more randomly than surfing.  Shouldn't it be pulling the direction and directAngle from near the end of the list, and not the front (or it could remove the oldest item in the list when list size is over 3, since it doesn't use the older values anyway)? [[User:Skotty|Skotty]] 14:19, 25 June 2011 (UTC)

Revision as of 15:22, 25 June 2011

From old wiki

This bot is stronger than expected. -- GrubbmGait

Yeah, it's stronger than my Squirrel, which was SUPPOSED to take that code and improve it but all it did was make it worse :(. --Bayen

I don't think the tutorials are under the RWPCL, I fiugured the code was just to use and abuse for anything thats sports your fancy. (not that my bots aren't under the RWPCL anyway) -- Chase-san

PEZ put GFTargetingBot under the RWPCL, but I consider the WaveSurfing/Tutorial to be available to use however you want. -- Voidious

I lifted the RWPCL licensing now. The code is in the public domain. Of course I do believe very hard in OpenSource and would encourage anyone to use it anyway. -- PEZ

I put Squirrel's code in the jar, so that makes it open source, right? Anyway, I don't think anyone would really want to use my code, for two reasons. It's extremely messy, and Squirrel isn't that good. Oh well --Bayen

  • Yes, that makes it open source ;) -- Voidious

Hmm, when i run Plains against BasicGFSurfer, i sometimes get a

wiki.BasicGFSurfer 1.0: Exception: java.lang.ArrayIndexOutOfBoundsException: 5
java.lang.ArrayIndexOutOfBoundsException: 5
    at wiki.GFTWave.setSegmentations(BasicGFSurfer.java:386)
    at wiki.BasicGFSurfer.onScannedRobot(BasicGFSurfer.java:102)
    at robocode.peer.robot.EventManager.onScannedRobot(Unknown Source)
    at robocode.peer.robot.EventManager.processEvents(Unknown Source)
    at robocode.peer.RobotPeer.tick(Unknown Source)
    at robocode.peer.RobotPeer.turnRadar(Unknown Source)
    at robocode._AdvancedRadiansRobot.turnRadarRightRadians(Unknown Source)
    at wiki.BasicGFSurfer.run(BasicGFSurfer.java:51)
    at robocode.peer.RobotPeer.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)

Also, on two of the rounds, BasicGFSurfer is stopped.

----------------------
Round 3 initializing....
Let the games begin!
Round 3 cleaning up.
----------------------
Round 4 initializing....
Let the games begin!
wiki.BasicGFSurfer 1.0 has been stopped.  No score will be generated.
Round 4 cleaning up.
----------------------
Round 5 initializing....
Let the games begin!
wiki.BasicGFSurfer 1.0 has been stopped.  No score will be generated.
Round 5 cleaning up.
----------------------
Round 6 initializing....
Let the games begin!
Round 6 cleaning up.
----------------------
etc

--Starrynte

I can see why - it has MAX_DISTANCE set to 900, but technically the maximum distance should be 1000 - BOT_WIDTH (because it measures from center of the bot) on an 800x600 field (like a 3/4/5 right triangle). If you are as far away as possible, it will be a higher index than the stat buffer is initialized with. Really, the safest thing to do would be to calculate MAX_DISTANCE based on battlefield width and height. Hopefully, that stoppage thing is also related. I'll update the GFTargetingBot tutorial; somebody should release a BasicSurfer 1.1 =) -- Voidious

  • Maybe the introduction should be changed to read, "... the basic, buggy implementation of a WaveSurfer with GuessFactorTargeting ...". =P -- AaronR

Bugfixed version 1.01 available. Made a more robust fix than just increasing the distance, without any effect on distances < 900. MAX_DISTANCE remains 900.

int distanceIndex = Math.min(DISTANCE_INDEXES-1, (int)(distance / (MAX_DISTANCE / DISTANCE_INDEXES)));

-- GrubbmGait

Surfing Bug or Misunderstanding?

When I was comparing performance between my own wave surfing drive and the one used by BasicGFSurfer, there were some interesting performance differences that made me take a closer look at the BasicGFSurfer drive. I was a bit confused by the use of _surfDirections and _surfAbsBearings. The code in question is in the onScannedRobot method and looks like this:

            ew.direction = ((Integer)_surfDirections.get(2)).intValue();
            ew.directAngle = ((Double)_surfAbsBearings.get(2)).doubleValue();

This means the enemy wave direction and directAngle are always pulled from the 3rd item in the list, but items are never taken out of the list (accept when list is cleared at beginning of round). So if I'm reading it right, BasicGFSurfer is using invalid direction and directAngle values, which probably makes it move more randomly than surfing. Shouldn't it be pulling the direction and directAngle from near the end of the list, and not the front (or it could remove the oldest item in the list when list size is over 3, since it doesn't use the older values anyway)? Skotty 14:19, 25 June 2011 (UTC)