View source for User talk:Wompi

What Is Funnelweb Your New Project? Link:https://github.com/Wompi/robocode-bots/tree/Funnelweb/wompi

Hi mate, no not really a new project. I just play around with some stuff - mostly bouncing from one idea to another. It became some sort of a morning ritual to put on the computer and write some Robocode code just for funnies and also read the wiki to stay informed whats new.

Have fun... wompi

How Does Funnelweb work Why was it made

Hi mates. I'm quite new to the 'skipped turn' behavior and would appreciate a little heads up.

I just put this on my robot:

public void onStatus(..)
{
    start = System.nanoTime();
}

public run()
{
     .....
     while(true)
     {
           .....
           System.out.format("[%d] %d \n",getTime(),System.nanoTime() - start);
           excecute();
     }
}

This is what i get and i'm not sure how to interpret it:

[203] 7260000 
[204] 4098000 
SYSTEM: TassieDevil* (1) skipped turn 205
SYSTEM: TassieDevil* (1) skipped turn 206
[205] 7443000 
SYSTEM: TassieDevil* (1) skipped turn 207
[206] 8137000 
SYSTEM: TassieDevil* (1) skipped turn 208
[207] 8656000 
[208] 7771000 
[209] 4019000 
SYSTEM: TassieDevil* (1) skipped turn 210
SYSTEM: TassieDevil* (1) skipped turn 211
[210] 7488000 

To me it looks like that the turn counter is not incremented on skipped turns and the next turn after the skipped gets the time++. Normally this would have no influence on my bot, but i send some stats to another team bot who needs to know when the stats are gathered. I don't believe that it works like this and i'm very sure i missing out some here. My thought was that if i skip a turn it shouldn't reach the printout line. Is there a way to get the time i can spend until i get a skipped turn?

thanks in advance and take care

I think I understand what's going on here. When you go over your time limit for a turn, you skip the next one or more turns. But this probably means that none of the events are fired or anything else when you call execute(), and the while loop still runs.

If you think about what code is actually executing from your bot, there's the main while loop, and whenever you call execute, Robocode processes the setXXX stuff you've called and fires all your events. There's no way really for Robocode to make your main while loop skip ahead a couple of iterations. But presumably, no events are being fired for that tick, and any "actions" you take in the while loop are not happening when you call execute().

Hmm, actually, you're right, I'm still confused. Maybe if you also print the time from onScannedRobot we could see more clearly what's going on? Eg, maybe after turn 209, it decides you skip 2 turns and prints about them, but the while loop still happens for those turns, but execute() does nothing for the next 2 calls to it.

Actually... I was pretty sure this lag in "getTime()" wasn't the case in the past. I suspect this may be a Robocode bug that explains the unusual observations you were reporting elsewhere Voidious...

I played around a little and now i am even more confused :). I changed my whole code and now it runs all mostly under 1 ms. But still 'skipped turns' from time to time but with awkward times.

The output is:

System.out.format("[%d] %d [%d][%d] %d\n", getTime(),System.nanoTime() - start,onScanEventTime,onScanBotTime,onScanTimeDiff);

[94] 233000 [94][94] 113000
[95] 159000 [95][95] 41000
[96] 19648000 [96][96] 19506000    <---- no skip at 19 ms 
[97] 230000 [97][97] 84000
[98] 367000 [98][98] 232000

[145] 911000 [145][145] 152000
[146] 183000 [0][0] 0                                   < --- no scan
[147] 283000 [147][147] 129000
SYSTEM: TassieDevil* (1) skipped turn 148
[148] 9762000 [148][148] 9543000       < ---- skip at 9 ms
[149] 149000 [0][0] 0
[150] 141000 [0][0] 0
[151] 200000 [0][0] 0
[152] 148000 [0][0] 0
[153] 148000 [0][0] 0
[154] 257000 [154][154] 105000
[155] 199000 [155][155] 97000

As you can see the times are always the same for onScannedRobot(...) and run(). My first thought about the run() .. while loop was like yours. The loop runs to execute every turn and print out the time spend but without the setXXX(...) stuff doing. My guess about this was then i can see at least the time that brought me the skipping turn. But as you can see the spend time for the skipped turns are still under 15ms (i guess this is the most time you can spend right?) .

The other side is, i do really nothing special that could cause the system to skip turns, just a couple of minor loops and every turn it is almost the same stuff (just minor differences). Does the garbage collector need every than an now a little more time to remove dead objects? Because i make every new scan a new MessageObject for communication with the team mate.

And there you can see the skipped turn gets his scan event like every turn.

[64] 1224000 [64][64] 1074000
[65] 165000 [65][65] 46000
SYSTEM: TassieDevil* (2) skipped turn 66
[66] 207000 [66][66] 106000                          < --- reached the end of onScannedRobot(..) and set the vars
[67] 229000 [67][67] 45000

I'm still sure i missed something important but still can't see it :(

The last output of yours is the most direct evidence of a bug, imo - you "skipped a turn" but onScannedRobot was supposedly processed for that tick, the tick before, and the tick after. Either you didn't really skip that turn, or getTime() was wrong. As another data point, here's the info on a sort of similar bug I was hitting: User_talk:Voidious#weird_bug_I.27m_hitting_891.

If you enable replay recording, after the battle you can save the battle, and it outputs an XML file with all the data from that battle (like every tick, it's huge). Maybe you can also print out some info here to cross-check against the replay file?

Besides that, I think it's time to report a bug about this, and/or start digging through the code myself to figure out what's going on. =)

Btw, under the menus, you can "recalculate CPU constant" and it will tell you how much time each bot is allowed per turn on your system. Not sure how you're calculating elapsed time, but maybe it's not the same chunk of time being examined as Robocode.

Well, the turn time on my system is 5.6 ms. So most of the output is right. But the 19ms should skip 3 turns and the last output shouldn't skip the turn. I will give the XML record a try maybe i can find something there. As for the elapsed time, its just like the above code shows - start time at onStatus(..) and difference before the last step (excecute()).

I didn't even know onStatus existed. That runs before all other events on every tick? I could definitely clean up a couple things by using that...

Hmm this is the stripped output of the skipped turn:

Finally i got a skipped turn (288) and it works like we thought it must work. The whole turn got no events and even the loop got no turn, so no print out. On the other hand i think i found your bug. If you look at the table below you can see that the robot is advanced in his skipped turn and the next turn has the 15.98 distance difference. this should be 8 or less because of the skipped turn.

To me it looks right now there are three bugs

• skipped robots advance just like in a normal turn but they get no events
• skipped robots get events and advance just normal (so it is just a message with no consequences)
• robots get no skipped events at all even if they are way out of time

[285] 121000 0 [285][285] 49000  [270.78095:748.65046] - [1.41372]   //  ([x:y] - [heading])
[286] 130000 0 [286][286] 54000  [262.87944:747.39899] - [1.41372]
SYSTEM: TassieDevil* (1) skipped turn 287
[287] 16716000 16 [287][287] 16582000  [254.97794:746.14751] - [1.41372]
[289] 131000 0 [289][289] 55000  [239.28147:743.09643] - [1.34390]

turn	286	287	288	289
energy	160.07883925169597	160.07883925169597	160.07883925169597	157.07883925169597
x	262.8794433297025	254.9779366049414	247.07642988018029	239.28146936189842
y	747.3989879466453	746.1475122263234	744.8960365060016	743.0964280712507
bodyHeading	1.4137166941154065	1.4137166941154067	1.4137166941154067	1.3439035240356334
gunHeading	1.1884119094971828	1.161216370645719	1.161216370645719	1.135682848864048
radarHeading	1.7448331266273467	0.9322394243784347	0.5360878333247008	1.295952474940478
gunHeat	.09999999999999981	0.0	0.0	1.5
veocity	-8.0	-8.0	-8.0	-8.0
getX()	262.87944	254.97794	skipped	239.28147
getY()	747.39899	746.14751	skipped	743.09643
getHeadingRadians()	1.41372	[1.41372	skipped	1.34390
delta dist	...	8.0	should be skipped	15.98

Sorry i just edited my former post .. to save space.

Yep onStatus(..) is always the first event and holds every state of your robot.

The bug I hit was using the distance between locations from two ticks that had a getTime() difference of 1, so it shouldn't be an issue about moving during skipped turns. Anwyay, bots definitely should still move during skipped turns (or that could really break some physics), they just shouldn't be able to change their heading/velocity/distance remaining.

Thanks for doing all this debugging!

Ah good point. So the table shows almost how it should work. No bodyHeading and gunHeading change but still a radarHeading change. I will make some deeper tests, maybe i find something that brings some light on this.

Cool! So you think the original bug you hit was just "skipped turn message but didn't really skip turn"?

Also, if you called setTurnRight or setGunTurnRight and the command hasn't finished turning, I think those headings would still change on a skipped turn, as they would if you issued no new setXXX commands.

I think i got your bug figured out. Right now i'm to overtired to give you the numbers but i will do this tomorrow.

Basically what it does is the system skips some turns without a skip turn event, it just misses the turns out (happens very frequently). So it looks like this:

• 1 normal turn
• 2 lost turn without any data and no skip event
• 3 normal turn, you try to calculate the enemys x y but you get the wrong bearing from the system, your own values are ok
• 4 normal turn with delta time = 1, you calculate the enemys x y with the right values but if you calculate the distance to the last (wrong) x,y you get some distance that is way out of line

You can check this very easy if you just put the follow in onStatus(...)

if ((getTime() - lastTime) > 1)
{
    System.out.format("blabla...\n");
}
lastTime = getTime();

blabla should print out without a skipped turn event or console message.

Buahh 3:00am ... i have to sleep :) take care

Well this is what i got so far:

• robots get skipped turn events but actually never skip the turn (happens only by one turn skips)
• robots skip turns but get no skipped turn events
• after a skipped turn(s) the robot gets the wrong enemy bearing/distance and can not calculate the right x,y position of the enemy
  • it also happens that the robot gets 2 scan events in a 1vs1 match with time differences out of order
• minor - the skipped turn message shows the turn number of the last turn and not the actual skipped turn number
• faster client speed causes more skipped turn

To make it replicable i wrote a little BugBot_1.0 which can be downloaded and checked by yourself. The source is included along with some examples for the output of the above issue points. Just put two BugBots against each other and play with the client speed. You can also record the match (1 round is enough) and see what the XML files says about the issues (this is not really necessary the console output shows it quite good).

The bot generate all kind of the above points and can be used to find the robocode bug behind this. If you don't get some of the above output just increase the speed of the client and it should be happen. You can also increase the amount of skipped turns by raising the run variables.

Well i hope this helps a little and hopefully the code is sound.

take care

Wow, awesome! We should definitely file a bug report to Robocode for some of these - I'm sure BugBot will be really helpful in finding these bugs and testing the fixes. I'll check him out this evening too. Cheers!

Yep i did the bug report just now and hopefully Fnl can say something about this.

Thank you for the nice debugging Wompi! I was not aware of these issues. I especially like all the steps and details needed for seeing these issues. It's like a scientific approach. :-) This one will take me some time to fully understand, and I need to examine all the details and the BugBot_1.0 in detail. I also need to be sure that the BugBot is not really containing bugs. ;-) After that I will need to find the root of each issue and fix these. I don't expect this to be an easy task, so bear over with me if it takes some time to do. I will have my first priority to fix. :-)

Huh? Didn't show my signature. --Fnl 22:05, 12 June 2012 (UTC)

Ah i missed your response. Yep take your time. I guess it is only fair to do some debug work because you probably have other things do do as well :).

Btw. thanks for taking care of the Robocode engine.

Take Care

This issue took a looong time to fix properly, i.e. without braking other stuff in Robocode and still fix all the observed issues. Sorry for that.

I have made an 1.8.1 Alpha 2 version of Robocode you can try out here: http://robocode.sourceforge.net/files/robocode-1.8.1.0-Alpha-2-setup.jar

Please check this version out and see if all issues regarding skipped turns have been solved properly. :-)

--Fnl 22:59, 22 February 2013 (UTC)

Sure thing, I will give it a try right away and give you a response as fast as I get some results. Thank you Fnl.

Hi mate.
That is an awesome fix you provided there. I tested all kind of stuff related to skipped turns and it works like a charm.

Things I tested so far:

no more hidden skipped turns (very nice)
no more wrong onScannedEvents(..) (I'm most excited :) well done)
right turn number for skipped turn events (nice to have :) )
disable bots if they skip more than 30 turns - just to check if it still works (and it does :))
also gone is the 'skipped turn message but no actually skipped turn' issue (just a minor issue but thanks for fixing this too)
it also looks like the influence of other bots is gone too. If I compare 'all nano' vs 'all general' melee battles, 
     I got no difference in average skipped turns anymore  

I have a quite large code base for skipped turns and I could detect something that looks suspicious. The output is from different battles - all full (10) melee.

This is the output if everything works fine ([x] skip xA - xB is the output within onStatus(), xA - lastStatusTime, xB - currentStatusTime):

SYSTEM: Numbat 2.1* skipped turn 6
[7] skip 5 - 7
SYSTEM: Bonus for killing cs.Grudge 1.0: 17
SYSTEM: Numbat 2.1* skipped turn 156
[157] skip 155 - 157
SYSTEM: Numbat 2.1* skipped turn 404
[405] skip 403 - 405
SYSTEM: Numbat 2.1* skipped turn 728
SYSTEM: Numbat 2.1* skipped turn 729
[730]  skip 727 - 730
SYSTEM: Bonus for killing simonton.nano.MeleeSeed 1.8: 4
SYSTEM: Bonus for killing kawigi.nano.Lib 1.0: 3
SYSTEM: wompi.Numbat 2.1* wins the round.

This is the output for some other battles and it looks like the system sends an StatusEvent even if the bot is dead.

Round 8 of 35
=========================
SYSTEM: Bonus for killing radnor.DoctorBob 1.42: 7
[1004] skip 973 - 1004    <------- last status event on 973 and current status event on 1004 
                                no skip events and I'm not having skipped 31 turns (average is 6 per battle) 
                                see following outputs for equally behavior on onDeath
                                I can't say if I died on 974 and the system just delayed the message, 
                                    or if something other happens  
[1004] DEAD    <-------- output from onDeath()
SYSTEM: wompi.Numbat 2.1* has died

Round 9 of 35
=========================
[244] skip 241 - 244
[0244] DEAD
SYSTEM: wompi.Numbat 2.1* has died

Round 25 of 35
=========================
SYSTEM: Bonus for killing cs.Grudge 1.0: 5
SYSTEM: Bonus for killing radnor.DoctorBob 1.42: 2
[661] skip 649 - 661
[0661] DEAD
SYSTEM: wompi.Numbat 2.1* has died

There is another one, but that should be discussed by the community, I guess. If a bot skips 30 turns within the victory turns he gets the 'no action message':

SYSTEM: wompi.BugBot* (2) wins the round.
SYSTEM: BugBot* (2) skipped turn 36
....
SYSTEM: BugBot* (2) skipped turn 83   <-------- way more than 30 turns
SYSTEM: BugBot* (2) has not performed any actions in a reasonable amount of time.
SYSTEM: No score will be generated.

So the bot gets disabled and (probably - not tested right now)) no score, even if he has won the game at this point. I don't know if this should be handled somehow or if it is a legal response to bots - would be great to get some opinions about this issue.

Anyway, great work and you can be sure all your work on the RoboCode engine is very much appreciated by all community members, I guess.

Take Care

Wow what an amazing fix. Hopefully these two other issues Wompi found can be ironed out as well.

Big thanks Fnl for sorting this out! And also to Wompi for testing it! I saw this yesterday and was wondering if I even remembered how the heck to test this, and was sad Wompi wasn't around, but I guess he is. :-)

You guys rock!

Great work! I'm curious, did this just affect the printing, getTime() and skipped turn notifications, or was Robocode actually doing the skipped turns inconsistently before?

@Skilgannon - Sorry I don't get the question. Is the question related to the two new issues or to the former issues? And who is it you asking :) me or Fnl? It is probably because I'm not a native english speaker but I can not realize what is meant, sorry for that.

@Voidious - thanks, I'm reading the wiki every day but have almost no time/clear mind over the week.

It was directed more at Fnl, but perhaps you can answer. I was wondering if the actual internals of Robocode were also behaving incorrectly, or if it only looked like it from the robot perspective.

Hmm... I'm not sure we can do much with that unless you also print out getX(), getY(), and/or getHeadingRadians() from your while loop and/or onScannedRobot, so we can see what matches up and what doesn't. I'll also try reproduce this later when I have some time.

Hi mates. I'm playing with my new bot right now and it turned out he use quite a lot of memory. After a couple of rounds the client heap is full and things start to get very "strange". That leads me to the question: How much memory can a bot use? Is it restricted/shared in some way or can just one bot take all memory? It turned out that my test against Diamond and DrussGT leads to huge skipped turn counts on these bots but my bot is still fine (he just use memory like nothing in his current develop state to save on the cpu side).

Take Care

Memory isn't restricted per bot like CPU, so you can use all you want. But if your bot uses way more than its share, people's clients will crash only on battles with your bot and you'll get a lot of complaints. :-) I'd say your bot should be able to battle itself without ever causing OutOfMemory errors.

Do Diamond/DrussGT get the same amount of skipped turns if you pit them against each other, or themselves? I've definitely seen some cumulative CPU load effect on skipped turns - eg, Diamond is less likely to skip turns against Sample Bots than against DrussGT. Some amount of skipped turns is not a huge deal. How many are being skipped? Your high memory usage could lead to increased garbage collection, which I think would count against your bot's CPU time, but that (a bot using a lot of CPU) can also cause a few skipped turns for the other bot in my experience.

Hmm ... 1vs1 is no problem for my bot even against himself. But if it comes to melee it looks different ,because i have to hold combat data of 9 bots. Right now it uses almost 500 MB against a full melee field. But it is not finished yet and i guess i can bring it to 300 MB or less. I was a little surprised that not every bot can use the same memory share.

My test run is with DrussGT/Diamond/Me/ + usual sample bots. After a couple of rounds the memory was near 500 MB and the garbage collection worked very frequently. At this time both bots skipped turns like nothing. Diamond got disabled in 3 rounds and DrussGT had 150+ skipped turns. If i run both bots + samples without me, everything is fine (i have never seen both bots doing this and i use they quite often for tests). My bot got no skipped turn and showed no unusual behavior (beside the memory usage).

My guess is that the garbage collection counts against all bot times because it happens in background and is not related to one bot alone. If you have a bot that is near his cpu limit he will start to skip turns every time the garbage collection kicks in. My bot uses almost no cpu he just grabs the results from some HashMaps and so it got no skipped turns. Just a rough guess right now ... i'm a little sleepy right now and i will observe this a little in the future.

Hmm, that's a little scary that Diamond got disabled. =) Btw, DrussGT doesn't know anything about Melee so I wouldn't use it for Melee testing (maybe you meant Neuromancer?). I'm not really sure how much memory Diamond uses in Melee or if 10 Diamonds would run out of memory at 512 megs or not. He does push the CPU time a little by the end of the match with the amount of processing going on in the gun, though. Getting disabled early in the match would be very surprising to me indeed.

Of course you are right :) replace DrussGT with DemonicRage in the above posts. Like i said i'm very sleepy right now (it's 4:30am).

Hi mates. I'm playing right now with classifying the melee field and maybe we can share some thoughts. What i'm looking for, is to classify the whole field danger beside the single opponent danger. What i got so far is this little table:

It shows the max/min/avg turns when i died - related to the enemies left. The min/max/avg energy is the energy i had if i start to fight xx opponents. Count means how often i finished with x opponents left.

example: against top10 micro melee

enemies left	count	max turn	min turn	avg turn	max energy	min energy	avg energy
0	+10	+1276	+743	+937	+80.9	+2.9	+26.0
1	+6	+1252	+784	+983	+81.6	+6.9	+36.7
2	+6	+1052	+636	+739	+83.3	+9.2	+37.7
3	+2	+685	+638	+662	+96.9	+4.4	+50.5
4	+1	+434	+434	+434	+101.0	+15.6	+53.1
5	+2	+446	+324	+385	+103.3	+12.9	+55.4
6	+6	+386	+312	+350	+105.3	+0.0	+53.3
7	+1	+334	+334	+334	+110.2	+0.1	+60.4
8	+0	NaN	NaN	NaN	+107.7	+2.5	+73.0
9	+1	+222	+222	+222	NaN	NaN	NaN

example: against sample bots

enemies left	count	max turn	min turn	avg turn	max energy	min energy	avg energy
0	+100	+3131	+680	+1227	+219.0	+11.1	+139.5
1	+0	NaN	NaN	NaN	+220.6	+41.0	+145.3
2	+0	NaN	NaN	NaN	+217.9	+56.9	+141.7
3	+0	NaN	NaN	NaN	+199.0	+64.0	+139.8
4	+0	NaN	NaN	NaN	+184.7	+64.0	+136.9
5	+0	NaN	NaN	NaN	+180.7	+61.3	+131.3
6	+0	NaN	NaN	NaN	+167.6	+54.8	+126.5
7	+0	NaN	NaN	NaN	+164.1	+59.3	+122.2
8	+0	NaN	NaN	NaN	+159.4	+68.3	+115.7

I'm not sure how fast this values correlate to the current field danger, but i guess it is a good start. As you can see against the samples i could increase my damage and the movement could also be more aggressive because the field is weak. My opinion about the turn information is, you can see if you use the right weapon for the round state. Again - against the samples it looks i have some problems to hit (huge max turn, high diff between min and average) and should use another gun. Against the micros it shows an energy gap between 2-3 opponents left (so i should possible change the movement at this state).

My thought is, if i read this informations while battling and change my tactics on them it could be rewarding. What do you think and maybe there are some other data that should be collected to classify the field danger.

Take Care

I don't have time for a more comprehensive post right now, but with regards to the huge max time for the sample bots, I'd guess that has more to do with them not hitting eachother well rather than an issue with your robot. I mean, many of the sample bots don't even fire very often at all.

Hi. Has somebody an idear how to make this smaller. I need the max bearing difference between all enemys. My gut feeling says it should be easier, but i can't see it.

	private void calcBearingDiff()
	{
		if (myScans.isEmpty()) return;
		
		Comparator<ATarget> compi = new Comparator<ATarget>() 
		{
			@Override
			public int compare(ATarget a, ATarget b) 
			{
				double eAbsBearA = a.getBearing() + myRobot.getHeadingRadians();
				double eAbsBearB = b.getBearing() + myRobot.getHeadingRadians();
				return Double.compare(eAbsBearA, eAbsBearB);
			}
		};
		ArrayList<ATarget> enemys = new ArrayList<ATarget>(myScans.values());
		Collections.sort(enemys, compi);
		
		enemys.add(enemys.get(0));
		
		ATarget last = null;
		for (ATarget target : enemys) 
		{
			if (last != null) 
			{
				double eAbsBearingA = last.getBearing() + myRobot.getHeadingRadians();
				double eAbsBearingB = target.getBearing() + myRobot.getHeadingRadians();
				double diff = Utils.normalRelativeAngle(eAbsBearingA - eAbsBearingB);	

	                        // .... sort out the max
			}
			last = target;
		}
	}

Ah .. i'm looking for a different approach to the problem and not to make the code smaler.

Could make ATarget comparable

Thanks Chase. ATarget is a comparable but for other stuff. What i was looking for was something around another data structur. The above code snippet is way to much code for my taste. I thougth about to register the next ATarget on every ATarget and then simple ask the difference but it didn't work very well because i had to reorder the references to much. I'm looking for something that can handle ... update ATarget ... sort out the closest (bearing) ATarget ... and give the difference back ... I think i have to find a appropriate List/Tree structure for this.

Hmmm... what are you trying to use this for? I don't think I quite understood the question. Are you trying to get the biggest angle between any two in consecutive radial order? Or the one which is the closest to 180 degrees from it?

Area Picture

Maybe this picture can explain what i need. As you can see the white lines are the absBearing to every enemy and the transparent white area is the area from the two enemys who have the widest bearing to each other. I need this for my radar and my movement.
And yes i need the biggest angle between two in radial order (i guess :)). Nevermind the blue and green lines they are for something else.

I'm not sure, that i correctly understood your question and that its algorithm is completely correct, but idea must work, i think

double minAbsBearing = Integer.MAX_VALUE;
double minRelBearing = Integer.MAX_VALUE;
double maxRelBearing = Integer.MIN_VALUE;

for (ATarget target : enemys) {
    double absBearing = ...; // me.angleTo(target) in my case
    double relBearing = Utils.normalRelativeAngle(absBearing);
    if (relBearing < minRelBearing) {
        minAbsBearing = absBearing;
        minRelBearing = relBearing;
    } 
    if (relBearing > maxRelBearing) {
        maxRelBearing = relBearing;
    }
}

double widestArea = maxRelBearing - minRelBearing;
double startAngle = minAbsBearing;
double endAngle = Utils.normalAbsoluteAngle(minAbsBearing + widestArea);

You nailed it mate. Thanks. Looks like i was totaly looking at the wrong direction. But at least my gut was right :). Man this is even smaller than i hoped for.

You are welcome, but this code would not work:) Now I have no time to describe why (writing on english is difficult for me), but try to test different cases and you will easy understand the problem.

I also thought there might be some issues at certain angles with the single loop approach.

I think you need to take a <math>n^2</math> approach, ie, a loop within a loop. Otherwise you need to use a sorting technique (with nlogn), then a single loop. Here is pseudocode:

initialise min_sum = Inf
For each bot, b:
    me_b = find the angle from me to b
    initialise min_rel = Inf, max_rel = -Inf.
    for each bot c, excluding b:
        me_c = find the angle from me to c
        rel = the relative angle between me_b and me_c
        if rel < min_rel, min_rel = rel. if rel > max_rel, max_rel = rel.
    sum = max_rel - min_rel
    if sum < min_sum, min_sum = sum, min_ang = me_b + min_rel, max_ang = me_b + max_rel.

The other approach would be to sort all the angles into radial order, then go through looking for the largest space between two angles, and then use the opposite part of the circle. So in pseudocode:

for each bot, b:
    me_b = angle from me to b
    angles[i++] = me_b

sort_ascending(angles)

max_rel = abs(relative_angle(angles[0] - angles[angles.length - 1]))
min_angle = angles[0]
max_angle = angles[angles.length-1]
max_index = 0
for(i = 1; i < angles.length; i++)
    rel = abs(relative_angles(angles[i-1] - angles[i]));
    if rel > max_rel
        max_rel = rel
        min_angle = angles[i]
        max_angle = angles[i-1]
        max_index = i

Yes Jdev you are right it does not work for all angles and i was aware of that. But it pushed me into another direction to think about it. If the bot stays almost ever on the edge or corner of the battlefield your code works very well i get some really impressive average visit counts with my radar.

Thanks Skilgannon your first approach looks interesting and i will give it a try. Haven't found the time for now. My first thougth to overcome the angle glitch was to throw in a signum() direction check and switch the angles if they don't fit. Don't know how to describe this and its again more of my gut feeling which tells me that this might work. I'm almost sure i did this once but lost it. The second one looks a little like my first try, not really sure about that to.

But anyway, thanks to both of you for bringing me out of my stubborn mind state.

Congratulations on a strong competitor to the micro melee field! It's certainly nice to see some activity there. Based on watching it in just a few battles, Wallaby seems to have an impressive melee gun. Good luck with your robots--CrazyBassoonist 14:21, 22 April 2012 (UTC)

Thanks mate. I'm a big fan of your robots and i hope i can give you a little challenge. It would be nice to see you coming back. If you look at the sources of wallaby you can see i used (stole) some stuff of your robots. And i deeply hope you are ok with this. Right now i'm working on a better movement and i think it can do well, its mainly a codesize problem. The gun has got also a little improvement and it should bring me a little closer to oog.melee.Capulet (hopefully :) ). Would be nice to have someone to discuss do/don't things for micro/nano melee.

Well if you want to talk about small bots or robocode in general, I'm open. I may not be coding actively right now(though we'll see if that continues...) but I do check the wiki frequently. As for using code from my bots, I'm perfectly okay with that in small amounts. However, I would encourage you to find your own ways of doing things; nothing I do is perfect(in fact it's usually the opposite) and most of my successes came from me trying out my own weird ideas instead of copying other bots. Once again, nice to see someone doing something exciting in one of my favorite fields:)