Difference between revisions of "Talk:BasicGFSurfer"

From Robowiki
Jump to navigation Jump to search
m (→‎Surfing Bug or Misunderstanding?: remove extra newline)
 
Line 81: Line 81:
 
</pre>
 
</pre>
 
Passing the index 0 puts it at the front of the list instead. --[[User:Voidious|Voidious]] 14:37, 25 June 2011 (UTC)
 
Passing the index 0 puts it at the front of the list instead. --[[User:Voidious|Voidious]] 14:37, 25 June 2011 (UTC)
 +
 +
:Ah, I missed seeing that insert at front of the list.  Thanks.  [[User:Skotty|Skotty]] 14:46, 25 June 2011 (UTC)

Latest revision as of 15:46, 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)

The key point here is that it's inserting at the front of the list:

        _surfDirections.add(0,
            new Integer((lateralVelocity >= 0) ? 1 : -1));
        _surfAbsBearings.add(0, new Double(absBearing + Math.PI));

Passing the index 0 puts it at the front of the list instead. --Voidious 14:37, 25 June 2011 (UTC)

Ah, I missed seeing that insert at front of the list. Thanks. Skotty 14:46, 25 June 2011 (UTC)