View source for Talk:Robocode

From Robowiki
Revision as of 05:47, 16 September 2009 by Starrynte (talk | contribs) (moved to Talk:User:Starrynte)

Talk:Robocode
Jump to navigation Jump to search

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)

Contents

Thread titleRepliesLast modified
Keeping AdvancedRobot instance in static field503:36, 21 August 2018
Will onRobotDeath event miss due to skipped turns? 1013:44, 6 January 2018
1.9.3.0 related bugs005:08, 31 December 2017
Robocode Wikipedia Article014:44, 2 October 2014
1.9.0.0021:12, 27 February 2014

Keeping AdvancedRobot instance in static field

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?

Xor (talk)10:45, 19 August 2018

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.

Enamel 32 (talk)15:32, 19 August 2018

You do not have permission to edit this page, for the following reasons:

  • The action you have requested is limited to users in the group: Users.
  • You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

You can view and copy the source of this page.

Return to Thread:Talk:Robocode/Keeping AdvancedRobot instance in static field/reply (2).

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

Skilgannon (talk)19:38, 20 August 2018

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

Enamel 32 (talk)21:41, 20 August 2018
 

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

Xor (talk)03:31, 21 August 2018
 
 
 
 

Will onRobotDeath event miss due to skipped turns?

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

Xor (talk)16:47, 29 December 2017
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.
Dsekercioglu (talk)18:17, 29 December 2017
 

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.

Beaming (talk)03:50, 30 December 2017

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.

Xor (talk)05:02, 30 December 2017
 

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?

Xor (talk)05:06, 30 December 2017

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.

Beaming (talk)05:34, 30 December 2017

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.

Xor (talk)06:06, 30 December 2017
 

Just found that even onDeath can be missed, via either calling execute before it's fired (via experiment result) or skipping turns (guess, but I'm pretty sure).

And when onDeath event is missed, SYSTEM: *** has dead will also be missed.

Xor (talk)09:23, 30 December 2017
 
 

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.

Dsekercioglu (talk)18:46, 30 December 2017

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

Skilgannon (talk)00:01, 31 December 2017
 
 

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.

Xor (talk)13:43, 6 January 2018
 

1.9.3.0 related bugs

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.
Xor (talk)06:15, 30 December 2017

Robocode Wikipedia Article

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.

Chase14:44, 2 October 2014

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...

Cb (talk)21:12, 27 February 2014