View source for Talk:Robocode

The following 2 comments are from the "Robocode/Welcome" talk page, before moving it to "Robocode".

This article should be merged with Robocode Basics. --AaronR 23:19, 12 November 2007 (UTC)

• I agree, and thank you for doing the merge job. :-) I have just started putting stuff into this new Wiki, so I will continue extending the Robocode part of the Wiki with the old one provided here Robocode Online Help, but in a total updated version of course. My intension is that all the stuff I put in this new Wiki will contain all information about Robocode in the future, and then I will redirect the old web page to point on this new one, when it is finished. ;-) --FlemmingLarsen

The Wikipedia entry for Robocode

Somebody should update the http://en.wikipedia.org/wiki/Robocode page for Robocode some day. :-) --Flemming N. Larsen 23:31, 13 November 2007 (UTC)

1.7.1.2

I've been doing a bit of local testing, both with new and 'know problem' archaic bots (SandboxDT, SilverSurfer), and all the results seem to match 1.5.4. Also, it seems to run a LOT faster. I've been testing the rumble with UPLOAD=NOT and it also seems to match everything within what I would think is the margin of error. Can we have a consensus that 1.7.1.2 is safe for the rumble and challenges? --Skilgannon 19:15, 14 May 2009 (UTC)

I bet even 1.7.1.1 are ready for RoboRumble. I've been asked Darkcanuck about newer version and he said we should wait. One thing that change is survival score, 1.6.1.4 and earlier use 1st as survival score but 1.7.x use either survival or survival bonus score instead. » Nat | Talk » 23:32, 14 May 2009 (UTC)

Whoah, did the survival scoring really change? Man, I don't like that at all. I wouldn't support any scoring change being allowed into the RoboRumble. Where is there info about this?--Voidious 02:40, 15 May 2009 (UTC)

Indeed, the result doesn't change. (because it a percent) It just switch from 1st to survival bonus, which is the same for 1v1 battle (but not for melee rumble) Here are some result from my result file (1.7.1.1alpha)

roborumble,35,800x600,Nat_1711,1239165160631,SERVER
stelo.UnfoolableNano 1.0,2748,1475,900
robar.nano.BlackWidow 1.3,2685,1479,850
roborumble,35,800x600,Nat_1711,1239165163655,SERVER
robar.nano.BlackWidow 1.3,4848,2290,1750
sul.Pinkbot 1.1,640,640,0

The older version look like:

roborumble,35,800x600,Nat,1242355746718,SERVER
zyx.mega.YersiniaPestis 1.6.2.4,3746,1707,29
ak.Fermat 2.0,1529,1102,6
roborumble,35,800x600,Nat,1242355781553,SERVER
darkcanuck.Gaff 1.34,3559,1612,28
apv.AspidReloaded 0.6,2159,1638,7

Score in format total score, bullet damage, survival » Nat | Talk » 02:53, 15 May 2009 (UTC)

Ah, cool, thanks for that info. So it's just the representation that changed. I'll chill out now. =) --Voidious 03:08, 15 May 2009 (UTC)

He he, just found that 1.7.1.2 beta isn't ready yet, see http://robocode.svn.sourceforge.net/viewvc/robocode?view=rev&revision=2983 for more detail. Be should wait for final release before make it a rumble client. And, as I wrote this many times already, 1.7 is a LOT faster for sure. I've once run it with UPLOAD=NOT and I ran 60 battle/minute! » Nat | Talk » 23:41, 14 May 2009 (UTC)

Thanks for pointing out the scoring change, I didn't know about that. Do you know why it was done? I'd still consider this to be a bug, since it does change functionality without apparent cause. If we want the survival bonus it should be reported as a separate value.

1.7.1.1 wasn't ready because there were known bugs (e.g. melee rumble broken). Some of the movement gurus out might want to take a close look at 1.7.1.2 because the movement formulas were changed slightly to fix the quirks that Simonton had pointed out. Happily this new version does fix a problem with the rumble client that could cause mass removals and also adds smart battles for melee. --Darkcanuck 03:46, 15 May 2009 (UTC)

Oh! I am wrong, it is actually survival, not survival bonus. But we still can't use current beta for the bug that fixed in r2983. It's is your server now, you don't want the new way so it is a bug. I've a patch now, see if you want. » Nat | Talk » 04:41, 15 May 2009 (UTC)

Robot Entry Sorting (in Robocode)

Regarding to this recent bug report I made, I want to ask you that, according to this issue (please refer to the comments on the report for detail, I don't want to repeat here), which solution do you prefer? Because I saw a lot of robots do like Diamond, and very few do like the current solution (like GrubbmGait's robots) --Nat Pavasant 13:15, 5 November 2009 (UTC)

Name	Keep	Change
Nat		X
Rednaxela	X

I'm afraid I have to be strongly in favor of 'keep', since I think versioning which keeps closer to what real numbers would sort to makes far more sense. I personally also think it's silly to use a designation scheme which restricts to 10 levels for any given level of versioning. I think more than 'very few' like the current solution, for a few examples see bots of: GrubbmGait, Skilgannon, Simonton, Wcsv, Mue, ABC, and myself. Also, many bots use versioning that ensures 'sane' ordering with either sorting (Shadow seems to), or simply don't have high enough versions to tell what the versioning scheme is. --Rednaxela 13:36, 5 November 2009 (UTC)

I personally prefer the current version, but feel that it does have a bug, in that if you append a letter to the end of a version name it messes the numerical section up. Eg it will sort in the following order:

1.1.1
1.1.10y
1.1.2
1.1.10

instead of

1.1.1
1.1.2
1.1.10
1.1.10y

As such, I don't support the change Nat proposed, but don't particularly support keeping it either, because I think there's a bug in it =) --Skilgannon 14:27, 5 November 2009 (UTC)

Ahhh, I didn't realize that about lettering. Agreed :) --Rednaxela 18:01, 5 November 2009 (UTC)

Oh, that's how the current sorting works? =) I don't really care much either way. And I actually agree that the other (Mue/Skilgannon) style makes more sense, I just haven't decided how/when to change over to it in my bots. --Voidious 15:54, 5 November 2009 (UTC)

Actually... There's no reason code couldn't sort any mentioned version styles all correctly. I'll write code for this in a moment...--Rednaxela 17:41, 5 November 2009 (UTC)

• Wait, nevermind, I was being braindead. But... there IS actually no conflict WHEN people using Voidious-style versioning keep the number of digits constant, which they (almost?) always seem to do. --Rednaxela 18:01, 5 November 2009 (UTC)

I definitely prefer the current alpha-numerical ordering. However, it should be like the last/2nd example given by Skilgannon, not the first one, which seems to be a bug. I already have a fix for this one. But I will wait will fixing it, till I know if we should keep the current sorting. --Fnl 22:39, 5 November 2009 (UTC)

Just updated and....

SYSTEM: chase.na.Seraphim uses static reference to a robot with the following field(s):
	chase.na.Extension.bot, which points to a robocode.AdvancedRobot
	chase.na.Extension.bot, which points to a robocode.AdvancedRobot
	chase.na.Extension.bot, which points to a robocode.AdvancedRobot
SYSTEM: Static references to robots can cause unwanted behaviour with the robot using these.
SYSTEM: Please change static robot references to non-static references and recompile the robot.

What a fun error, probably my fault, and it is easy to fix, but assuming I assign it every round, how is this bad? Aside from the game not being able to dispose of the robot easily due to the java equivalence of a dangling pointer. — Chase-san 22:10, 24 June 2010 (UTC)

Ever since some architecture changes, holding old instances caused more overhead than in old versions. If you assign it every round reliably it's probably not a problem in practice. The reason this warning was added was at least one or two robots who had old references hanging around in a problematic way were found. That answer your question? --Rednaxela 23:00, 24 June 2010 (UTC)

Jikes vs. ECJ

I know for a lot of the codesize restricted bots it was advantageous to compile with Jikes because it gave a slightly smaller codesize. Has anybody done any comparisons on the codesize of bots compiled ECJ vs. Jikes vs. Sun javac? I suspect Jikes still gives the smallest code... although I'd love for somebody to prove me wrong. I'm not on my usual computer or I'd be putting up some results myself =) --Skilgannon 00:03, 29 June 2010 (UTC)

Didn't think I'd have time for this, but here's what happens with Waylander:

	Code	Class	Class
Nr	size	size	files	Location
--------------------------------------------------------------------
1	742	3945	1	jk.Waylander_0.3.7jikes.jar
2	753	4828	1	jk.Waylander_0.3.7ecj.jar
3	756	5057	1	jk.Waylander_0.3.7sun.jar

So better than the sun 1.6.0 jdk, but worse than jikes. I'll tinker with this... I'm sure this still has debugging info in it. --Skilgannon 00:22, 29 June 2010 (UTC)

Personally what I think would be most interesting would be seeing exactly where the different sizes of each come from, using a java disassembler. Anyway, I'm pretty sure one can only use jikes when compiling against an old robocode version though. --Rednaxela 01:40, 29 June 2010 (UTC)

I am pretty sure that some tricks to reduce codesize only works for Jikes. Many of my nanobots compile on Jikes and Ejc have the same codesize. --Nat Pavasant 12:45, 29 June 2010 (UTC)

I have waited as long as I could with replacing the Jikes compiler - especially due to Jikes ability to produce small code size. But unfortunately lots of users has made complaints in several years about Jikes giving strange compiling errors (I got one or two every week), and these users don't care about the code size. Hence, I suggest you still use Jikes for reducing the codesize. You can always set this up Jikes manually in Robocode, if you wish to - in fact any compiler you like. But I will only include one compiler into Robocode, and it has to be the best free "stand-alone" compiler, which I believe is currently ECJ. ECJ also provides much better compiler errors. :-) --Fnl 21:59, 29 June 2010 (UTC)

Bullet/Bullet intersection

Having written the one in roboflight, I now find it interesting that bullets intersect each other as lines in Robocode, meaning their collision chance even when fired directly at each other, is a bit low. Of course firing bullets to intercept bullets is also difficult. I wonder what the game would of been like if the bullet interception routine looked like this.

	/**
	 * Moving Circle test, reduced dimensionality version of the bullet/bullet intersection code in Roboflight.
	 * Tests two moving circles s1r1 s2r2, with directional vectors <s1x,s1y> and <s2x,s2y>, over a give time.
	 */
	public static final boolean testCircle(Point2D s1, double r1, Point2D s2, double r2,
			double s1x, double s1y, double s2x, double s2y, int time) {
		double rVx = s1x - s2x;
		double rVy = s1y - s2y;
		double a = rVx*rVx + rVy*rVy;
		double dx = s1.getX() - s2.getX();
		double dy = s1.getY() - s2.getY();
		double c = dx*dx+dy*dy;
		double rSum = r1 + r2;
		double rSumSqr = rSum * rSum;
		if(a > 0.0) {
			double b = dx*rVx+dy*rVy;
			if(b <= 0.0) {
				if(-time * a <= b)
					return a * c - b * b <= a * rSumSqr;
				return time * (time * a + 2.0 * b) + c <= rSumSqr;
			}
		}
		return c <= rSumSqr;
	}

— Chase-san 00:57, 29 June 2010 (UTC)

I think it would be much different, and using bullets to shield would be much more common. Note though, even with current line-based collisions, one author has had a great deal of success with it via an interesting technique (BulletCatcher), not sure if you've seen that one or not. --Rednaxela 01:52, 29 June 2010 (UTC)

When keeping AdvancedRobot instance in static field, robot will show warning:

Static references to robots can cause unwanted behaviour with the robot using these.

However I've been using this pattern (the way robocode can't detect, and I cannot avoid as well) since the first day I write robocode. However, robocode did not mention what's wrong with this pattern. Do anyone know what's the exact meaning of this warning?

I think the risk is that the static robot reference is not guaranteed to be valid after a given round, so if you don’t update the reference things may not work as expected.

Yes, that's also what I guess, and since I'm updating the reference every round, I guess it would not be a problem. However, since robocode did not say what unwanted behavior it is, I'm worrying about more problems: race condition (since each round you have a new thread), GC problem (no longer a problem since robocode cleans static field each battle) and more

Since you're updating it every round, why do you need it to be static?

Ease of access, probably. I was doing the same before my big inversion of control refactoring.

because I’m simply making everything under a static variable, just like lazy singleton. The field itself is not static at all, but the field containing the field is static and has to be static. Diamond uses this style as well afak However the problem of static reference should happen to this style as well, since two approaches are fundamentally equivalent

onRobotDeath is crucial when dealing with multiple enemies. If this event were able to lost, it will be hard to guess that information back.

If I understood correctly skipped turns happen when the bots passes the time limit. I think, after this event no actions are made(setAhead( ), setFire( etc.) and no events are called after it. I am 99 percent sure that if you call onRobotDeath first no skipped turns will harm it.

Even if it stopped everything you did by not updating the robot, static variables wouldn't change.

I think all events (except the skip turn event) are lost when robocode punishes for long CPU use. I have no source confirmation for it. But I quite sure that event of enemy death can be lost. I recall adding a special check of enemy not being scanned for something like 10 tics to put it into the dead enemy category because, because I was occasionally missing the death event during the run. I also think you might even miss your own death event. I have a code which suppose to print some stats at such event, and I see that sometimes the output is not produced.

Yes, that's true. I did a quick experiment and found that onRobotDeath event do lost when experiencing heavy skipped turns.

So just add if (Math.random() < 0.7) { return; } in onRobotDeath and see whether your bot totally breaks.

Anyway, I see some alive bot not getting scanned for 10+ ticks (when you skip turns, that could be easy to happen), are you handling this case correctly?

It should no be a problem if a "robot" reappear on scan, it is added back to the alive pool.

Hm, I could not find the code which is in charge of it. I vividly remember programming it several years ago. This might explain some quirks which I saw in melee, when my bot fires into a dead bot last seen location. I.e. if I miss robot death event, I still count enemy alive for quite a bit and keep firing at the "gost" till some timer expires.

well, firing at some "ghost" when missing onRobotDeath is unavoidable. Anyway we could set different timer for radar & gun. e.g. for radar, choose 8k ticks, where k is large enough to avoid marking alive bots as dead. And for guns, use a small k, e.g. 1, to avoid shooting at targets that we don't have new information.

I actually meant, if you call onDeath first and do not skip any turns in it it won't be lost. I am pretty sure that there can't be any skipped turns in onDeath.

It is still possible that you miss the turn the onDeath is created for by skipping from a previous turn.

Even onRobotDeath event got missed, it takes at most 8 ticks (assuming radar not affected by gun/body) to recover that event

— just check if everyone else got scanned after getOthers() drops, if so, simply mark it as dead.

While we are still not officially switching to 1.9.3.0, I found some new bugs introduced in 1.9.3.0 (comparing to 1.9.2.6).

My system: macOS 10.12 My robocode version: 1.9.3.0

UI bug:

• current robot score shown in right sidebar (the blue line) is incorrect
• radar scan arc is not shown correctly when it doesn't turn sometimes (it should be shown as a line, but is actually shown as it were a few ticks ago, when the radar was still turning).

Game logic related bug:

• when execute() is called before onDeath() is fired, this event will be missed and "SYSTEM: *** has dead" message will never be shown.

As FNL pointed out a good 7 years ago, we should rewrite the wikipedia article about robocode. Currently it is a very poorly designed and messy article. If anyone feels the same way, I suggest we set a few ground rules in regard to it.

First we should avoid mentioning specific authors or robots unless they are historically relevant. Having a ranking of the "best bots" is a terrible idea, since the article goes so long between being updated. We should especially try and avoid mentioning certain authors of certain techniques. Wikipedia readers likely don't care who made the first painting robot or who came up with wave surfing. At least as one offs.

We can of course include these in a history of robot design and techniques. But only so long as it is part of an actual article and not one liners of "Shadow (made by ABC) introduced wave surfing to the game." No one likely cares, especially since no one knows what the heck "wave surfing" even is. So such a thing needs to be explained in detail as part of the history if it is added at all.

Unfortunately I only know what has happened in Robocode since around mid 2006, so I can't easily write the early history.

Does anybody else have problems packaging a robot in 1.9.0.0? When I try to do it, it creates a .jar which only contains a manifest file but nothing else...