Jump to navigation Jump to search

I don't think a much longer match length so much predicts random movement as it does oscillators that don't use random numbers.

Anyway, I made those changes, and the bullet power one saves us a single byte. Not sure what to do with two bytes though...

Skilgannon (talk)08:47, 27 May 2013

I might have another byte for you. I have been doing some experimenting my my movement code and obviously also looking at yatagan since it is the best. One tweak I have tried (but not yet benchmarked or verified) that looks like it saves one byte is to not use infinity for direction. This then allows you to use direction rather than getVelocity() in the turning code, which should save a byte. Something like:

 private final static double VERY_BIG            = 1e+200;
private final static double CLOSE_FACTOR = VERY_BIG * 430;
turnRadarRightRadians(direction = VERY_BIG);
setTurnRightRadians(Math.cos((rd = e.getBearingRadians()) - (e.getDistance() - PREFERRED_RANGE) * (direction / CLOSE_FACTOR)));

This should work provided there is nothing weird in the robocode radar which will cause issues without the infinity.

Nz.jdc (talk)15:07, 27 May 2013

That's a very cool idea. The only thing I'd be concerned about is the radar, since it will subtract the amount it turns from the getRadarTurnRemainingRadians() and could eventually run out (although not really an issue if it is 1e200). Perhaps by reading in degrees and writing in radians for the infinity lock we could negate that, though. In fact, we could probably get away with a smaller value. I'll give it a spin when I get home.

Skilgannon (talk)15:24, 27 May 2013

Looks like it works ok. I was worried about depletion too, especially when I saw you use 48 (any reason for that number in particular?), then I actually thought about it and noted the rad/deg growth, so anything down to 2PI should be ok :)

Nz.jdc (talk)02:45, 29 May 2013

48 is the distance of a stop-and-go move, so my thoughts are that it will be big enough that on the enemy death it will avoid HOT, but won't go into walls.

Skilgannon (talk)09:19, 29 May 2013

Ah, clever. I keep forgetting that once an opponent dies you will stop getting scan events.
I also remember some comment about stopping on radar slips being a reason not to set it too small.

Does the recent ++integer and inversion of the matching actually work? It looks like it should always terminate the loop by setting matchPos = -1.

Nz.jdc (talk)13:10, 29 May 2013

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:Yatagan/Source/Improvements/reply (15).