Voidious and PEZ, assembled by Bayen
BasicGFSurfer is the merge between two bots: PEZ's GFTargetingBot and Voidious' BasicSurfer. More info can be found there.
More info can also be found at Kawigi's GuessFactorTargeting Tutorial and on Voidious' WaveSurfing Tutorial.
Nothing, it is the basic, bugfree, implementation of a WaveSurfer with GuessFactorTargeting
https://www.freewebs.com/bayen/files/wiki.BasicGFSurfer_1.0.jar
https://home.versatel.nl/gheijenk/robocode/jarfiles/wiki.BasicGFSurfer_1.01.jar
It is ranked just in the top-50 with 1865 points
basic WaveSurfing
basic segmented GuessFactorTargeting
Not aware of melee
Between rounds anything usefull, between matches nothing.
Well, I think that is rather clear, isn't it.
This comes from the tutorials, so it is in the jar. Public domain. The authors all enjoy credits though.
Nothing. It fullfills its purpose as it is.
Nope.
Reread this page, it is mentioned at the top.
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
Hmm, when i run Plains against BasicGFSurfer, i sometimes get a
![[Home]](/images/RoboWiki.png)
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
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