View source for Talk:ExclusionNano
- [View source↑]
- [History↑]
Contents
Thread title | Replies | Last modified |
---|---|---|
A Few Suggestions | 3 | 01:45, 29 April 2013 |
I was looking through the code of version 1.2, and I noticed some things you might want to fix in the next version. Here they are:
- I don't think the code in onBulletHit is doing what you think it's doing.
- The
while
loop in the radar code is unnecessary. Also, Double.POSITIVE_INFINITY is a byte cheaper than 1 / 0.
- Infinity Radar is sloppy enough even with setAdjustRadarForGunTurn. If I were you, I would get rid of that and replace it with setAdjustGunForRobotTurn.
- The
Math.min
call in your Energy Management code isn't really necessary.
- Finally, you can assign a new value to
d0
inline in your aiming code to save a byte.
That is some very good codesize saving advice. This nano was based off a relatively poor performing robot in the first place.
The onBulletHit
being wrong is possible, it was just getEnergy last time. However that looked like an error to me, since it was suppose to be detecting enemy energy drops, and I wanted to remove the possibility of
With my compiler, 1/0.0 has the same byte size as Double.POSITIVE_INFINITY.
As for the d0, note my comment "since I use this twice in the following, I am not sure which one is called first, if I figure it out I can shave another byte off". I assume its the most deeply nested one, but I could be wrong.
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page.
Return to Thread:Talk:ExclusionNano/A Few Suggestions/reply (2).
BulletHitEvent.getEnergy()
gets the enemy energy AFTER the bullet hits and its energy drops. So I shouldn't need to adjust by the bullet power. Sure I might miss a bullet fire, but at the time I was low on codesize.
But after all the reductions I can actually fit that in.