User talk:Khanguy

WallHugging

I need help fixing my wallhugging code. Everytime I reverse direction or when getHeadingRadians() nears 3pi/2 or pi/2 It seizes up(it won't move). I'm stick and can use any of the help I can use. Here is the code:

static double direction;	//1 for clockwise or -1 for counterclockwise
.
.
.
//in the onscannedmethod
wallHugging(); //Dunno why I did this, but it works!
.
.
.
//whenever I want to change direction
direction = -direction; // reverse direction when hit
.
.
.
// this is the absolute heading I want to move in to go clockwise or
// counterclockwise around my enemy if I want to move closer to them,
// I would use less of an offset from absBearing (I'll go right toward
// them if I move at absBearing)
public void wallHugging(){
//Pez's wall smoothing code with adaptation
double goalDirection = getHeadingRadians() + Math.PI/2 + direction*Math.PI/2; // I want it to go straight
Rectangle2D fieldRect = new Rectangle2D.Double(18, 18, getBattleFieldWidth()-36,
 getBattleFieldHeight()-36);
while (!fieldRect.contains(getX()+Math.sin(goalDirection)*160, getY()+
        Math.cos(goalDirection)*160)){
	goalDirection += direction*.1;	//turn a little toward enemy and try again
}
double turn =   robocode.util.Utils.normalRelativeAngle(goalDirection-getHeadingRadians());
if (Math.abs(turn) > Math.PI/2) {
	turn = Utils.normalRelativeAngle(turn + Math.PI);
	setBack(100);
} else {
	setAhead(100);
}
setTurnRightRadians(turn);
}

Skipping Turns?

Question: what makes bots skip turns and how do you fix it? --Khanguy 00:12, 15 May 2011 (UTC)

A bot is allowed a certain amount of time each tick for processing. The actual time limit is relative to the CPU and stored in robocode.properties (CPU constant, in nanoseconds). If you take longer than that, you are forced to skip the next tick - or possibly multiple ticks, depending on how far you went over the limit. If you take a very long time, Robocode will stop your bot for the rest of the round (I think?).

So fixing it means keeping the amount of CPU time your bot uses under that limit. The limit on your computer should be very close to the same on all computers because of the CPU constant, but there could be some variance with different JDKs and CPU architectures. In general, a few skipped turns (say 1 every 200 ticks) is not a huge deal, but obviously you want to avoid them as much as possible. --Voidious 00:20, 15 May 2011 (UTC)

what about skipping some 300 ticks consecutively? My nanobot that I working on was skipping a lot of turns nearly every round. --Khanguy 01:21, 15 May 2011 (UTC)

Do you use pattern matcher? Nano-size pattern matcher usually can have at most 45 pattern depth, otherwise it usually can't match fast enough. --Nat Pavasant 01:24, 15 May 2011 (UTC)

actually no, just a reduced linear gun with a nano sized wall hugging movement(its based on wall smoothing). --Khanguy 20:09, 15 May 2011 (UTC)

If you have a version of robocode between version 1.7 and 1.7.2.1, and are running with "-Ddebug=true", then this bug could be what you're hitting. Otherwise, I'd guess it's something in your bot. Add some timing code in your bot to report how long different sections of code take? --Rednaxela 22:03, 15 May 2011 (UTC)

I think I fixed it. The problem here was not an old version of robocode (I run version 1.7.3.0b) but with my class file. I tried to name my robot by only changing the classname. What I did not rename was the .java file. After fixing this I found that my bot stopped skipping turns. I'm now at a loss on how this mistake made me skip so many turns. --Khanguy 23:42, 15 May 2011 (UTC)

A Million and One Questions

I'm learning about the different targeting/movement systems out there, and despite all the research I'm doing I'm left with a ton of questions and I dont have much time to answer them. So, if anyone would take the time to answer my questions it would be greatly appreciated.

1. in segmentation, does the order of segments really matter? in other words, does putting distance before velocity make a difference than if velocity was the first segment in the array?
2. what is the best anti-pattern matching movement out there?
3. can "velocity surfing", as introduced by Savant VS, be as effective as guessfactors when implemented with waves?
4. is pattern matching the best "general" targeting method against wave surfing?
5. is genetic programming or ANN more successful in robocode?

I suppose that these are the most important ones. I'll have more questions up when these get answered. --Khanguy 12:17, 2 August 2011 (UTC)

In reply:

1. No. Put them in any order you want, they are just locations in memory.
2. Simonton's LifelongObsession has a dedicated anti-pattern matching. However, I've tinkered with this myself and it tends to have a detrimental effect on surfing against other targeting mechanisms. If you want to improve your surfing against pattern matching try adding time-based segments, such as distance-last-10, time-since-deceleration and time-since-direction-change.
3. Not sure, there hasn't been an extremely competitive implementation yet so I'd hazard a guess at 'no'. Feel free to give it a try though... I'd love to be proven wrong and there to be another element of robocode that we don't know about yet =)
4. If you go by the scores on the anti-surfer challenge page, then Neural Networks or a virtual gun system made up of several types of guns.
5. ANN definitely, although genetic algorithms can be useful for tuning parameters in code. The main problems with genetic programming (IMO) is that it can take thousands and thousands of generations to achieve a reasonably competitive bot, and you need to run against the entire testbed for each individual in each generation, making the amount of processing power required prohibitive.

Hope this helps. --Skilgannon 14:10, 2 August 2011 (UTC)

On question 1, I have a slightly different answer:

1. in movement: No. Usually the attributes (velocity, distance etc) are in parallel. In targeting, as attributes are put in serie, it can make a difference in case you only regard segments with a minimum number of data. In my bot, I use unsegmented data if the appropriate segment of my first attribute does not have enough data. If it has enough data, I take this, 1-segment deep, data. If the subsegment of my second attribute within the segment of my first attribute has enough data, I'll take that data. The more data you get, the deeper the segmentation becomes. F.e. I have colleted 40 data, evenly distributed over 4 velocitysegments. In velocitysegment 0 the distribution over de distances is 0,2,8,0. If the opponent is in velsegment 0 and distsegment 1 (2 data) I will take all 10 data from velocitysegment only. If he is in distsegment 2 (8 data), I take the better fit data from velocitysegment plus distancesegment, ignoring the 2 data which were recorded at a different distance. As your data get build up, more and more finegrained segmentation will happen, making the gun (hopefully) more accurate. However, this is the situation for me, others have multiple segmentations (light and/or heavy) in parallel, choosing the most succesfull ones based on history. Short said: Choosing the most important attribute for the first segmentation can give a small advantage in the beginning to the middle of the battle, but to the end there will be no noticable difference anymore. --GrubbmGait 18:33, 2 August 2011 (UTC)

Thanks for your quick replies. As I said before, I have a ton of unanswered questions. Here are a few more pertaining to "learning" that constantly pops up on the wiki.

1. what is learning? I believe it to be machine learning in that a gun tries to learn the best firing angle possible in that situation. Am I right?

2. How do you measure the speed of learning?

3. How do you make a targeting method learn fast?

RSVP --Khanguy 19:15, 2 August 2011 (UTC)

1. Some of use ideas from machine learning, but I'd say we usually mean it in a more literal sense - guns that record data (in any form) and update their decision making process based on past observations of the enemy. This is in contrast to something like Circular Targeting, which is just a formula based on the current state of the enemy robot.
2. I'm not sure we do, at least not directly. Learning both quickly with little data and thoroughly into the later rounds are both important. You can always compare 1/5/35/500 round battles in a Targeting Challenge or WaveSim benchmark, though.
3. It kind of depends on your system. If you are using Visit Count Stats, for instance, you might have multiple stat buffers of varying complexities that you sum together, or you choose among them depending on how much data you've collected. When your buffer with 5 zillion segments still has no data in most situations, your unsegmented buffer is great! When you're in round 15 with 10,000 ticks worth of data, that unsegmented buffer is almost useless by comparison. In contrast, a system like Dynamic Clustering is somewhat immune to this issue, as it takes all data into account each time it makes a decision - Diamond's main gun uses (pretty much) the same calculation the entire battle.

--Voidious 20:00, 2 August 2011 (UTC)

Ok, I now have questions about Historical Velocity Recall:

1. Can Historical Velocity Recall make a decent stat gun?
2. Is it possible to use waves with HVR?
3. how can you increase the number of "bins" for HVR? 9 bins seems pretty set in stone to me.
4. on a related note: does increasing the number of bins in a GF gun increase its performance? My results really vary

--Khanguy 08:28, 4 August 2011 (UTC)

1. I doubt it. This works more like a average angle gun, which gives problems against bots with two 'peaks'. For instance, if a bot spent half its time at top speed, and 1/3 of its time still, this would shoot at GF-1, at the top speed location, and miss the actual location which would be somewhere in between the two.
2. I'm not sure why you would. Once you add waves this becomes exactly equivalent to a GF based gun, so rather use that as you can have the advantage of actually aiming at where they are going.
3. Just increase the 9 in the array to a bigger number, and the 9 in the loop to a bigger number. That simple.
4. I find it can help up to around 45. After that adding more bins makes the data too sparse, unless of course you are using some sort of technique to log data to every bin that would have hit the bot.

--Skilgannon 13:07, 4 August 2011 (UTC)

As a note about #4, I personally think that not "using some sort of technique to log data to every bin that would have hit the bot", or at least smoothing it, is kind of silly unless it's in a codesize restricted bot. So long as either of the two is done, there's never a disadvantage to more bins besides that it takes more memory. One could even take a bin-less approach entirely (In effect, infinite bins) and the resulting calculation would have the same result except slightly more precise, so long as you were using techniques that recorded to a range of bins or smoothed across them. --Rednaxela 13:31, 4 August 2011 (UTC)

Just as a sidenote: 'attribute' is the subject to segment on (f.e. distance), the 'segments' is how you chop the attribute in ranges (f.e. 0-400, 400-600, 600-infinite), and 'bins' or 'buckets' is the division of the maximum reacheable angle into pieces. --GrubbmGait 05:56, 5 August 2011 (UTC)

Ok, another question for your guys:

What is being done in the Robocode community to transition Robocode for use on mobile devices,tablets as well as phones? --Khanguy 02:26, 26 September 2011 (UTC)

I'm not aware of any efforts. What form do you see it taking? I wouldn't particularly want to write lots of code on a mobile device, and maxing the CPU for long periods of time (which is pretty common in my Robocode life) isn't particularly conducive to mobile processors or battery life. So I'm not really sure how well Robocode would fit with mobile devices. Also, iOS doesn't have Java. --Voidious 02:51, 26 September 2011 (UTC)

We shouldn't be limiting ourselves to simple running battles, there are many other ways we can introduce robocode to mobile devices. An app that takes updates from the RoboWiki should suffice as a good start. From there we can look into trying to code-on-the-go -- essentially making the robocode program + IDE work on mobile devices so that we would be able to view,edit,and test code on the mobile device. This ought to work on devices running Android and I'm pretty sure that there is an iOS version of a JVM. --Khanguy 03:49, 26 September 2011 (UTC)

Problem with Eclipse

I was working on my bot and decided to test the my tweaks. I found that my bot wasn't on the robot list. I then double checked my classpath to my project files, and it was correct. I then went to my project files, and found that it only contained my .java file. For some reason, Eclipse wont build my bot! I tried to build it again, but it failed again. I then proceeded to restart eclipse and robocode manager. That didnt work either. PlZ HELP!!! --Khanguy 19:06, 3 August 2011 (UTC)

Does it run in robocode? If so then it gets built (unless you have an old copy in there that you are using by mistake). Eclipse by default separates projects into a source and binary folder, so check for a bin folder in the project folder.. — Chase-san 19:15, 3 August 2011 (UTC)

No, it doesn't run in robocode, that's how i discovered the problem in the first place. The all of my eclipse binary files are missing, and my bot(s) won't build. It was fine before( all of my bots were there and I had no problem in coding them or even building them). --Khanguy 07:28, 4 August 2011 (UTC)

I think I fixed it :). After spending considerable time on this problem, I found that eclipse was having trouble with one of my test bots' classes. There were multiple copies of the GFTUTILS class, one being a seperate class,, and another being a subclass. I deleted the the external class, and found that eclipse was building my bots again. what a relief.--Khanguy 08:04, 4 August 2011 (UTC)