User talk:Starrynte

You're listed under U on the Bot Authors page for some reason. --Synapse 06:44, 3 September 2008 (UTC)

• ([[Category:Bot_Authors]] --> [[Category:Bot_Authors|Starrynte]]) Syntax for category listings ordered by a key other than the page title. -- Alexander (Nfwu) 10:08, 4 September 2008 (UTC)

Sometimes...sometimes I want to return to robocoding, which i haven't in possibly a year now...I quit partly because of school and partly because discussion was progressing towards a level I couldn't understand well...I do have some ideas though, and the nice thing about Robocode is that you play completely according to your schedule, so I am possibly returning. So my question now is, what advances in robocoding have occurred over the past year? --Starrynte 04:29, 11 September 2009 (UTC)

• Wow, last I remembered Robocode was 1.6 something, and now is already 1.7.1.4

Hey dude, welcome back. Two big non-robot things that have happened are that we're now using Darkcanuck's awesome new RoboRumble server, and we got the new wiki moved over to robowiki.net and a lot of nice stuff setup here. (There's still a copy of the old wiki on the new server at old.robowiki.net.) There's been a lot of melee activity in the last few months, that's been fun. Miked0801 came back and reclaimed both NanoBot titles. DrussGT is still on top in 1v1, now with a huge lead. There's been quite a lot of activity lately, as well, more than I've seen in a long time. There's plenty more to add, I'm sure, but those are the first things that come to mind, and I've got to get to bed. =) --Voidious 05:14, 11 September 2009 (UTC)

Two questions: 1) Robocode has been quite slow lately, any way to fix? (using 1.7.1.4 beta) For sure not a memory problem, unless 512M allocated to robocode isn't enough; not a cpu problem either. TPS/FPS is only around 5, when I set it to 30. (works fine when minimized though) 2) What are the 2 bars below the robot's name? --Starrynte 03:19, 14 September 2009 (UTC)

Under Options > Preferences > Rendering Options, you can change it to render for speed or quality or custom settings. If it's set to default, maybe give "Speed" a try? I think those bars represent energy, though I'm not sure what the various colors mean. --Voidious 03:31, 14 September 2009 (UTC)

It was already set to Speed. (though seems to be slightly better now, I didn't change anything. Maybe it was a slowbot) --Starrynte 03:55, 14 September 2009 (UTC)

The green/yellow/red bar represent energy: >50 = green; 20-50 = yellow; <20 = red (IIRC). Another blue bar is the 'score' it gains that round. Full bar means that you have the highest score in that rounds. The score bar can't tell you the real score since the length is the factor ratio against bot with the highest score.

About the slow, yes, I noticed that too. I think there are some problem with the graphics proxy, some of my robot that draw 1000+ shape as its debugging graphics, which used to work fine in 1.6.2/1.7.0.x/1.7.1.1, now throws BufferOverflowException in the graphics engine of Robocode. But perhaps this is Java bug? » Nat | Talk » 14:50, 14 September 2009 (UTC)

Another revival of interest has begun! So what has happened since...the beginning of the year? --Starrynte 04:21, 14 April 2010 (UTC)

Hope the return goes well! Since the beginning of this year? Well, I think the twitter feed gives a decent summary. Some Robocode beta releases, a couple tutorials on he wiki, some LBB development in the early part of the year, PEZ showing up, some new kd-tree happenings, and recently a little rash of activity from Skilgannon and Voidious. --Rednaxela 04:47, 14 April 2010 (UTC)

Yeah, that about sums it up. Welcome back. =) --Voidious 13:52, 14 April 2010 (UTC)

I'm finding it very difficult to come back, mainly because I'm having difficulty understanding my own robots (lol) which in turn is mainly because I haven't programmed anything for so long...it'll be at least a week before I can continue working on neural targeting...hopefully won't take too long :) --Starrynte 17:34, 17 April 2010 (UTC)

Random Questions

I have reproduced this numerous times already. Basically, when onScannedRobot is called my bot sets heading=(int)e.getHeading() . At the end of the onScannedRobot(), prevHeading=heading (for a pattern matcher). I put it in a battle with Walls. Most of the time, heading-prevHeading+10 is a normal amount. For some reason, every time Walls reaches the bottom left corner, the last two ticks of its turn say heading-prevHeading+10 is -339. --Starrynte 04:18, 16 September 2009 (UTC)

Sounds like just a normalization issue: getHeading() goes up to 360 before looping back around to zero. robocode.util.Utils.normalAbsoluteAngle(d) will normalize from 0 to 2 pi, and normalRelativeAngle from -pi to +pi (which is probably what you want). That's radians, though, so you'd have to convert back and forth, or write your own versions for degrees. --Voidious 04:27, 16 September 2009 (UTC)

Yes, that appears to be the problem, thank you! --Starrynte 04:48, 16 September 2009 (UTC)

Any simple ideas (for a nano) on how to have better center avoidance (for melee)? --Starrynte 05:52, 28 September 2010 (UTC), another return to Robocode, for an unknown period of time

Wave Surfing Questions

1. I don't understand why you use the absolute bearing from two ticks ago. From what I could tell, an enemy fires the tick its energy drop, which is also the tick you detect it, so shouldn't you use the absolute bearing from one tick ago?
2. To compensate for the edges or not?

--Starrynte 05:11, 17 October 2009 (UTC)

I don't quite understand the second question, but as number 1 goes. He fired one tick ago, you are right, but he aimed at you two (or even more if he waits the gun to align) ticks ago. Something like this.

• Tick 0, enemy calculates an angle to aim (high chance of it being a GF anyway). Sets his gun to turn to that angle.
• Tick 1, enemy's gun is now, ideally, aiming at his desired angle. Sets his gun to fire.
• Tick 2, you detect enemy's energy drop. You know he fired from his last position, but aimed at you at least two ticks ago.

Hope it helps. --zyx 05:43, 17 October 2009 (UTC)

Also not sure what you mean by the second question, but to elaborate on Zyx's explaination:

• Tick 0, enemy calculates an angle to aim (high chance of it being a GF anyway). Sets his gun to turn to that angle.
• Tick 0-to-1 transition, Robocode engine runs. Moves the enemy and turns the enemy's gun.
• Tick 1, enemy's gun is now, ideally, aiming at his desired angle. Sets his gun to fire.
• Tick 1-to-2 transition, Robocode engine runs. Moves the enemy and fires.
• Tick 2, you detect enemy's energy drop. You know he fired the position after the 1-to-2 transition, but aimed at you during tick 0 (using locations generated in the tick -1 to 0 transition) or earlier.

I personally find it sometimes helps to conceptualize it to also consider the transitions. Maybe I'm weird though --Rednaxela 06:29, 17 October 2009 (UTC)

We should have this posted on the page. It is almost exactly the same I asked before. To Red, you are not weird, it helps me too. To make it exactly what most do:

• Tick -2: Enemy aim his gun and call setFire();
• Transition: Gun is hot so it can't fire. Gun turned.
• Tick -1: Enemy aim again and call setFire();
• Transition: Gun is cool now. Robocode execute firing *before* gun turning. Enemy's energy drops.
• Tick 0: Energy drop detected.

Don't know if it help, though. --Nat Pavasant 12:02, 17 October 2009 (UTC)

OK, I understand it now - when aiming, the enemy is always using the absolute bearing from the previous tick. Anyways, my second question was whether the fact that GF 1 and -1 have fewer neighbors affected surfing at all, and whether you should compensate for that. --Starrynte 15:43, 17 October 2009 (UTC)

• Also a third question - you only log a hit in the surfing stats when you are actually hit by a bullet, correct? --Starrynte 15:52, 17 October 2009 (UTC)

I don't think anything is needed to compensate for edges like that. As far as when to log hits, normally you log when you're actually hit, many bots also log BulletHitBullet events since they also reveal where the opponant aimed. If you're making a flattener, the flattener will log every wave whether it hit or not. --Rednaxela 16:22, 17 October 2009 (UTC)

Aahh, finally I understand what a flattener is used for. But hey, I'm only a newcomer ;P --GrubbmGait 18:11, 17 October 2009 (UTC)

=D I don't believe you. --Nat Pavasant 12:43, 18 October 2009 (UTC)

I'm not sure if they always use the bearing from two ticks ago, there are bots that predict their and your position for the next tick, maybe some of them use that bearing for aiming, and some use an older bearing if they wait for the gun to align. But the bearing of two ticks ago seems like the most accurate if you have to settle for one of them, and most bots will actually use that one. --zyx 19:43, 17 October 2009 (UTC)

Direct message to Starrynte. User:Nat/WaveSurfingQuestion may have answer to your future question if any.

No offence, but if I'm newcomer I won't understand what Rednaxela said. If you are newcomer you would want reason. I don't know if Starrynte wants, though, but here it is anyway.

You only log for bullet hit, yes, because you know exactly which angle they are firing, and avoid them. So it isn't exactly the same as a reversed GF gun. This is suppose to dodge simple gun like LT/CT/HOT and very basic GF. But when you faced advanced GF gun, you will need a flattener, which you will log for every wave passed. This way you are simulating enemy's GF gun.

As for second question, this is used to call 'edge smoothing' IIRC. I think just normal smoothing will do fine. just don't update anything when you reached the edge. But actually many advanced GF guns don't have bin smoothing at all. --Nat Pavasant 12:43, 18 October 2009 (UTC)

Question 4: Suppose that you're orbiting the enemy clockwise and wallsmoothing. While orbiting, suppose Dive Protection tells your bot to reverse. After reversing, will it go forwards (because Dive Protection needs one more pixel forward to kick in), and then start vibrating back and forth? If so, how would you prevent it? --Starrynte 15:29, 18 October 2009 (UTC)

I have no experience whatsoever with this, but one solution might be to use your Precise Prediction to figure out whether or not your Dive Protection will make you reverse, and then use that to figure out the best place to move to.--CrazyBassoonist 16:09, 18 October 2009 (UTC)

I'd say that "Dive Protection" is not implemented correctly if that is an issue. Instead of having "Dive Protection" that says "I'm too close, reverse please", have it so it adds danger to proposed destinations for the surfing. I'm a big believer in that explicit Dive Protection is unnecessary however, and that it is implicitly provided by taking botwidth into account in danger calculations. RougeDC for one, relies on botwidth being accounted for in danger, to avoid moving too close when wallsmoothing. --Rednaxela 16:13, 18 October 2009 (UTC)

Note that it's bot width relative to max escape angle that is what is taken into account, if that wasn't clear. I'd also add that if you aren't convinced that precise bot widths add any value =), or you are lazy, you can just factor in distances instead -- bot width / MEA scales linearly to 1 / distance. I personally agree that multiplying a risk factor into your Wave Surfing dangers like this is the most elegant form of distancing / dive protection. It's very fluid and needs no special cases.

But it's not the only way, and you should certainly try your own ideas and experiment if we haven't convinced you. =) It's worth mentioning that Phoenix and CassiusClay are both very successful bots that do it differently: IIRC, if a movement option would create too steep an attack angle (above a certain threshold), they ignore that movement option. Phoenix then also has "anti-being-cornered" code to deal with the special case where all his movement options would be too steep.

--Voidious 20:51, 18 October 2009 (UTC)

I reverse when my desired angle (from distancing) and my smoothed angle differ more than 90 degrees. Maybe not the best solution, but its only 1 codeline and therefor bugfree. To prevent vibrating though, let your current direction be slightly favoured over the other direction, say multiply danger by 0.95 or 0.9. That will prevent almost any vibrating you will encounter. --GrubbmGait 22:50, 18 October 2009 (UTC)

As far as I know, there is 3 main kinds of Dive Protection. One is using pixel-perfect bot-width as Rednaxela said. The second one which I know use by many old robot, is the 'Fear the wall' method. Like when your the difference between your perpendicular angle and wallsmoothed angle over some factor, reverse direction. Phoenix use 30 degrees IIRC. The third one, which I know use by many surfers today including Dookious, Diamond and DrussGT is by weighting the danger at the point by the distance. Like risk/Math.pow(distance, 4) in Komarious. Latest Dookious use 1.5 or 4 base on the situation (being too close or not) and DrussGT use 2 IIRAC. --Nat Pavasant 15:24, 19 October 2009 (UTC)