Err... *scratches head* there's not that much to tell, really. It wasn't meant to be a really serious bot, it's just Raiko 0.3's movement copy-pasted, with a random lead gun on top. I guess it really shows the value of the MusashiTrick in microbot competition, for one thing. :-) There are quite a few bytes left and some fluff as well (I think one method isn't even used?) So maybe I'll try squeezing a pattern matcher or average offset gun on top. -- Jamougha
That description fits Aristocles too =) (Well, there it's Tityus movement of course). An average offset gun consumes almost as much codsize room as a guess factor one. Though the former isn't very effective. -- PEZ
Err.. how? The smallest I've gotten a guess factor gun is about 250 or so bytes (just outside being put into a nano with movement). An average offset gun w/ rolling (if I correctly understand what you mean and off the top of my head) is
![[Home]](/images/RoboWiki.png)
final static int ROLLING_FACTOR = 100;
static double eLastBearing, avgBearingOffset;
public void onScannedRobot(ScannedRobotEvent e) {
avgBearingOffset = (avgBearingOffset * (ROLLING_FACTOR - 1) + (eAbsBearing - eLastBearing)) / ROLLING_FACTOR;
eLastBearing = eAbsBearing;
setTurnGunRight(eAbsBearing + avgBearingOffset - getGunHeading());
}
and without...
static double eLastBearing, avgBearingOffset;
public void onScannedRobot(ScannedRobotEvent e) {
avgBearingOffset /= getTime() / (getTime() - 1);
avgBearingOffset += (eAbsBearing - eLastBearing) / getTime();
eLastBearing = eAbsBearing;
setTurnGunRight(eAbsBearing + avgBearingOffset - getGunHeading());
}
-- Kuuran
That's the equivilent of a GF gun with waves being fired every tick, I think PEZ was refering to a GF gun with waves fired only when a bullet is fired, which would (I think) be much bigger. -- Tango
Interesting. But I wonder if this gun isn't even less effective than the original Gouldingi style one. I had in mind a gun using waves, just like Tango guessed. -- PEZ
Effectiveness I have no idea about... Firing only on fire turns... Oh, and I just made a small correction to the code above since it had a big mistake in it...
To take the average bearing offset between gunshots:
static int shots;
static double eLastBearing, avgBearingOffset;
public void onScannedRobot(ScannedRobotEvent e) {
if(getGunHeat() == 0)
{
avgBearingOffset /= (++shots) / (shots - 1);
avgBearingOffset += (eAbsBearing - eLastBearing) / shots;
eLastBearing = eAbsBearing;
}
setTurnGunRight(eAbsBearing + avgBearingOffset - getGunHeading());
}
and to simulate complete waves...
static int shots;
static double avgBearingOffset;
static double eBearing[] = new double[10000];
public void onScannedRobot(ScannedRobotEvent e) {
eBearing[(int)getTime()] = eAbsBearing;
if((getTime() - enemyDistance / bulletVelocity) % 15 == 0)
{
avgBearingOffset /= (++shots) / (shots - 1);
avgBearingOffset += (eAbsBearing - eBearing[(int)(getTime() - enemyDistance / bulletVelocity])) / shots;
}
setTurnGunRight(eAbsBearing + avgBearingOffset - getGunHeading());
}
Again, untested code, should work...
Maybe that should be % 16?
Oh, in other news, I'm now taking back what I said about stat gun sizes, I'm pretty sure I can easily make a nanostatist.
-- Kuuran
Now that would be pretty cool. :-) When I was trying to build a nanostatist I concluded that I couldn't, but that someone who was decent at codesize reduction probably could - maybe even without making the sittingDuck assumption. :-) Most nanos have horrible profiles, so it might even be competitive. -- Jamougha
Making that a GF gun wouldn't take too much space, would it? -- PEZ
Assuming you can get it to work reliably, it assumes alot, and I'm not entirely sure about the %15. -- Kuuran
An old, and utterly failed, version of BlackWidow tried to do waves somewhat like this. I think I might have abandonded it a bit too fast. It would be very interesting to see an expert code shrinker try make a nano GF gun. -- PEZ
I've tried before and never gotten it below ~300 bytes. -- Kawigi
That's about where my previous attempts were with movement, etc. I've had a few more ideas since then. If I can get the code above to work reliably then it's not even a challenge anymore. -- Kuuran
My previous attempts were probably with the old FunkyChicken movement (setAhead(Math.atan(e.getEnergy*5)*500); or something) -- Kawigi
You can just drop the whole % 15 condition and it's equivalent to firing a wave per turn, which is probably the way to go anyhow. You also need to change getTime so that it doesn't throw arrayIndexOutOfBounds? at the start of each battle... you can set an offset of enemyDistance/bulletVelocity on the first tick you see the opponent I guess. -- Jamougha
The advantage to only firing a wave at firetime is that you can get things like bullet velocity from the bullet returned. Also, code that might be worth looking at - Tobe's Calypso?. The last version I tested had a stack-overflow error or something, but I think he's fixed that. I think it uses a VB-like function for firing at the last correct bearing. -- Kawigi
So.. Segmenting on bullet power now as well, right? Interesting choice for a micro. Can you share the rationale behind it? And, it's not too surprising a for loop countin down is smaller than one counting up. Depending on the compiler and the host machine (the JVM in this case) you might be able to produce smaller code when the exit condition is that some value equals zero. -- PEZ
Sort-of, same as the last version. The idea is that I didn't have enough bytes to calculate the escape angle properly, so by keeping the bullet velocity the same in each distance segment, the escape angle will always be the same within that segment. Unfortunately I had to drop the cast-to-int which makes it work to save some bytes, so it's now a load of bunk and I might just remove it. :-) Doesn't seem to affect performance anyway. But it's really lateral velocity and distance segmentation, just like the 'old school' bots. -- Jamougha
Doesn't affect performance? How about 40 freaking points? In microrumble that is. And still some 15 points in the general class. Or did you feed it something else that accounts for the improvement? Casts doesn't cost bytes, do they? -- PEZ
Casting variables may well cost bytes - think of it as a movi2f sort of assembly command. Casts from long to int or something probably won't, though, because no conversion is necessary. Of course, sometimes doing operations on different data types is enough cheaper to justify additional casts. -- Kawigi
I have never observed a cast cost bytes. I will be more alert to that from now on. -- PEZ
Not only do they cost bytes, dependent on cast type, but they also cost bytes for each variable they operate on. (int)(someIntVariable?/someDoubleVariable?); is more expensive than someIntVariable?/(int)someDoubleVariable?; -- Kuuran
OK, I'm convinced. It might explain some of my failed shrinking efforts of lately. -- PEZ
Cool!
Fighting battle 0 ... jam.micro.RaikoMicro 1.3,cx.BlestPain 1.32 RESULT = jam.micro.RaikoMicro 1.3 wins 2740 to 2248Even with some luck it takes some micro to do that. -- PEZ
That is definitely nice. :-) But I think that was luck, in my tests it only beats BlestPain by a little. -- Jamougha
Beating BlestPain at all is an achievement! On another matter... How can you do without this:
//setAdjustGunForRobotTurn(true);
//setAdjustRadarForGunTurn(true);
? I would never have tried it even. -- PEZ
Yes, it hurts to loose the gun adjustment - adjusting radar isn't an issue, the radar from Tityus is rock-solid anyway. I just couldn't make another 4 bytes without sacrificing someting else, and the performance difference isn't that great. -- Jamougha
I never use the gun adjustment :p Actually I believe Muffin 0.6 beat or tied BlestPain in my testing ;) I doubt 0.6.1 does that anymore. -- Kuuran
Rock solid? Hardly. RaikoMicro's radar spins full turns quite often now. Not that it seems to impact its performance. But still. I will be quite reluctant to save those for bytes! =) -- PEZ
Hmm, well the performance was looking promising, but now it's back at just the same ranking... the improvement I saw doesn't seem to have carried over into the rumble. Maybe I should try bringing back that gun adjustment. :-) -- Jamougha
Don't be too quick on drawing conclusions. Aristocles 0.3.0 looked like it would place #18 in general rumble after 400+ rounds. The rating isn't at all stable below 500 rounds it seems. -- PEZ
You're right; in fact I remember Aristocles terrorizing Verti for a while. :-) I also forget how close the rankings are around 20th; a 10 point oscillation means a whole lot of places. -- Jamougha
At the moment (after 250 rounds) RaikoMicro is 10 points ahead of the mighty FloodMini in general rumble! And that's with a positive momentum. Here's hoping. -- PEZ
I know it's way too early to tell. But after 55 battles RM 1.39 is on #9 in general!!! Now I doubt I'll ever catch up. -- PEZ
After 200 it's one point above whee it was before. Ho hum. :-\ -- Jamougha
For god's sake you're in 7th!! Congratulations!! Now please please please stop developing before you reach the top 5 with a micro. Just think about us mere mortals for a second, we just don't need this kind of humiliation... :) --Brainfade
Thanks :-) I think a lot of improvements come about just because of the codesize constraints... it's better to be forced to tune a little code to perfection than to have a bot with lots of features but poor tuning. Paul seems to be the only person who can expand his bot continuously and still make every improvement perfectly calibrated. -- Jamougha
Looks promising! You have a completely different problem bot list from Aristocles. That's surprising and seems to tell a tale about possibilities. Nice details sheet in general rumble by the way! It sure doesn't look like a sheet from a micro. =) -- PEZ
It's amazing to see how close you are to RaikoMX with this bot! -- PEZ
Very impressive indeed, both RaikoMicro and Aristocles, the attack of the micro bots! :) -- ABC
Jamougha: The non-stoppable top-10-bot maker machine! Cool man! -- Axe
Thanks everyone, lol, I certainly didn't expect to get above Tityus, if only by a fraction of a point. :-) Think I'll give this one a rest now, Raiko hasn't had an update in a while. -- Jamougha
Well, in the minirumble you didn't do it with just a fraction of a point. That ranking table makes pretty crappy wallpaper at the moment. =) -- PEZ
I just thought it would be interesting to mention (in light of the start of this comments section) that I recently got waves entirely onScannedRobot working to 100% of the efficiency of real waves. I think I might refit Muffin with them, since right now, despite completely different code, it's being functionally identical to KostyaTszyu?. It's amazing what leaving Robocode for a while did, I'm looking at old problems and solving them in an hour. :P -- Kuuran
Lol, i just noticed RaikoMicro rhymes --Starrynte