View source for Talk:Opposite

Any ideas for a targeting scheme with 132 bytes? (including how to select a target) --Starrynte 17:45, 12 September 2009 (UTC)

I'm not sure how much this will help, but this is the enemy selection I tend to use in codesize-restricted melee bots. I used linear targeting in this example:

package oog.nano.aorta;

import robocode.*;
import robocode.util.*;

public class Aorta extends AdvancedRobot {
	static double enemyDist;
	static String enemyName;
	public void run(){
		enemyDist=Double.POSITIVE_INFINITY;
		setTurnRadarRightRadians(Double.POSITIVE_INFINITY);
	}
	public void onScannedRobot(ScannedRobotEvent e){
		if(e.getDistance()<enemyDist||e.getName()==enemyName){
			enemyName=e.getName();
			enemyDist=e.getDistance();
			
			//This part greatly increases the accuracy of the targeting, but it isn't necessary.
			if(getGunHeat()<1){
				setTurnRadarLeftRadians(getRadarTurnRemainingRadians());
			}
			
			/*
			*You could replace these next two lines with any type of targeting and bullet power you like, 
			*I just used linear targeting as an example.
			*/
			setTurnGunRightRadians(Utils.normalRelativeAngle((e.getBearingRadians()+getHeadingRadians())-getGunHeadingRadians())+
					(e.getVelocity()*Math.sin(e.getHeadingRadians()-(e.getBearingRadians()+getHeadingRadians())))/14);
			setFire(2);
		}
	}
	public void onRobotDeath(RobotDeathEvent e){
		enemyDist=Double.POSITIVE_INFINITY;
	}
}

Note: I'm almost certain that this will fit into 132 bytes. If you need to put something else in, you could change it to head-on targeting or remove the line that locks on the radar before firing. Just remember that that line is pretty important for making the gun accurate--CrazyBassoonist 18:14, 12 September 2009 (UTC)

OK thanks, except should I do e.getName().equals(enemyName) as opposed to e.getName() == enemyName? --Starrynte 19:01, 12 September 2009 (UTC)

No problem. And using e.getName().equals(enemyName) would work, but costs three more codesize bytes--CrazyBassoonist 20:00, 12 September 2009 (UTC)

I wouldn't trust e.getName()==enemyName to work always without testing. Maybe it always uses the same object, and you end up with doing the right comparison with == in this particular case. Although I think it does work in this case, I'd test it thoroughly just to be sure. --zyx 01:23, 13 September 2009 (UTC)

I've tested it and it works every time I've seen for me, but please tell me if you find it is causing problems, as some of my robots use this target selection method--CrazyBassoonist 03:43, 13 September 2009 (UTC)

I think e.getName() always returns the same object... otherwise I'm guessing it would be pretty obvious that there's a bug in his code from the way it functions. If it weren't a nano and codesize-restricted, it'd be safer to use equals(), but I think in case case == is fine. --Spinnercat 18:15, 13 September 2009 (UTC)

I just did a ton of tests with it and found no problems. Congratulations on the score jump by the way:-). Is this all from switching to the distance-based enemy selection?--CrazyBassoonist 18:29, 13 September 2009 (UTC)

I think so...besides the change to bullet power 2.67 (though when I change that (including the bullet velocity) performance is worse). And I was using a distance-based target selection except it didn't store the name of the current target, just the distance, per Simonton's suggestion on the old wiki --Starrynte 20:58, 13 September 2009 (UTC)

Interesting, 2.67 seems awfully high to me. I've noticed huge gains after switching to something like 500/e.getDistance() in my robots, you might want to try that if you have space--CrazyBassoonist 22:16, 13 September 2009 (UTC)

Hmm, trying that at first appeared to be worse, but then when I checked the results (with my melee evaluator) they appeared to be better --Starrynte 01:12, 14 September 2009 (UTC)

I'm almost positive that e.getName() returns the same object during a round but not a match, which also makes the selection to forget his last target on the previous round even with a static attribute. I just meant that this kind of comparison is a need-to-be-tested assumption, but I agree it would be very easy to detect if it's not working. --zyx 19:36, 13 September 2009 (UTC)

Hi, very nice robot! I like its colors =) I've been thinking of a melee robot that uses stop and go and fluid movement, but I don't know how to implement fluid movement :/ Could I take a peek at your code just to see how it's done? Thanks!

Ok, thanks. I'll go look at the Anti-Gravity Tutorial and try to modify it for my needs =)