User talk:Starrynte

From Robowiki
Revision as of 17:13, 18 October 2009 by Rednaxela (talk | contribs) (reply about "Dive Protection")
Jump to navigation Jump to search

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)

Debugging

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)

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)

You cannot post new threads to this discussion page because it has been protected from new threads, or you do not currently have permission to edit.

There are no threads on this page yet.