Download it from: https://robocoderepository.com/BotDetail.jsp?id=1548
Version 1.2 might be the final version. I suddenly found myself consdidering adding quite ridiculous things to this bot in order to get the highest PMC index. But I stop here and am satisfied with 1.2 getting 101.15% with PatternMatching only. I'm creating a new bot with this pattern matcher. It'll live on this page: Frankie.
| LeachPMC version___ | Bullet damage_ | Index |
| 1.1.2 | 18638 | 101.15% |
| 1.1.10 | 18638 | 100.96% |
| 1.1.9 | 18735 | 101.01% |
| 1.1.7 | 18180 | 100.01% |
| 1.1.6 | 18443 | 099.85% |
| 1.1.5 | 17978 | 099.30% |
| 1.1.4 | 18035 | 098.88% |
| 1.1.4 | 08938 | 069.24% |
| 1.1.3 | 08758 | N/A |
| 1.1.2 | 08350 | N/A |
| 1.1.1 | 08154 | N/A |
| 1.1 | 04500 | N/A |
| 1.0 | 01783 | N/A |
Your making real progress here PEZ! You won't be needing Albert's gun anymore ;-) Of course i was only joking about this before. Actually i think pattern matching like what we are doing for the challenge is of little use against the unpredictable movement of the top bots. But it sure is fun watching all those bullet dodgers and oscillators get bashed hard! -- Vic
Thanks! I'm not as sure as you are about these guns being useless against unpredictable movement. Well, true unpredictability maybe, but no robot has achieved that yet. There are quite a few pattern matchers in the top 30 of EternalRumble. -- PEZ
I tend to agree, also, alot of flatteners find their weakness not in a better stat gun, but against pattern matchers. I think his refusal to include any pm might be the biggest thing that'll bring down Paul Evans. -- Kuuran
That's interesting ... maybe there's a glimmer of hope for Ender yet :-) You guys have much more experience against the top bots so i had better take your word for it :-) --Vic
I assume you are not talking about the initial stage but about the true pattern movement stage, because the initial stage cannot be accurately predicted using pattern matching. Are you rounding off any data before putting it in the buffer? Especially (delta)heading needs good accuracy. It's also quite possible (as is the case with EnderPMC) that you have actually already perfected the Matcher part (you pattern searching seems ok) but have minute flaws in what you call the Projection part. This is very hard to debug (as i am finding out right now with EnderPMC). If you find the gunbearing using a predicted point then you could use RobocodeGLV014 to see if your bullet really exactly hits the point that you aimed for. If all else fails, hardcode hitting PatternBot in its initial movement stage and I'm sure you'll beat it with your current Index value (I wonder if our PMC king Rozu has done that...). You are right that PatternBot had no velocity values with decimals. Looking back PatternBot would have been even harder to beat if i had put in some strange velocity values. Actually there are a lot of things i could have done to make it harder to beat but this is challenging enough i'd say.....maybe in another challenge :-) -- Vic
Whoah! I can't believe LeachPMC 1.1.9 gets over 101% Index while not beating PatternBot! (did you run more than one match?) That probably means that if you get that initial damage going you'll end up with a huge index! Good work PEZ! -- Vic
=) Yes, but it was a close shave. And now I might have fixed it. (Or it is maybe just that I just need some luck to actually beat PatternBot). Out of ideas on how to attack the pre-pattern-phase though. Anyone has their ideas flowing? Kawigi? You seem completely unable to stop your flood of ideas (pun unintended). -- PEZ
I would also need to read and write zipped movement data I think. This is how I read and write today:
![[Home]](/images/RoboWiki.png)
private void saveMovie(String enemyName) {
try {
PrintStream out = new PrintStream(new RobocodeFileOutputStream(getDataFile(enemyName)));
for (int i = 0; i < Math.min(movieSize, PM_LENGTH / 3); i++) {
Frame frame = (Frame)movie.get(i);
out.println(frame.headingDelta);
out.println(frame.velocity);
}
out.flush();
out.close();
}
catch (Exception e) {
System.out.println("Error saving movie: " + e);
}
}
private void restoreMovie(String enemyName) {
try {
BufferedReader in = new BufferedReader(new
FileReader(getDataFile(enemyName)));
String line;
do {
line = in.readLine();
if (line != null) {
double headingDelta = Double.parseDouble(line);
line = in.readLine();
double velocity = Double.parseDouble(line);
record(headingDelta, velocity, 1);
}
} while (line != null);
in.close();
}
catch (Exception e) {
System.out.println("Error restoring movie: " + e);
}
}
I would like if I could use the same idiom (with println() and readLine()) because I .. well I like it! =) I can't seem to wrap my mind around Java's IO design. I have tried several ways to create a BufferedReader? from a Zip-stream, but utterly failed. I think I might have had working versions of the writing, but I'm not sure. -- PEZ
Streams and Readers don't like each other that much - use an InputStreamReader? or OutputStreamWriter? in between to maybe make it work. -- Kawigi
PEZ, i posted some clues on initial damage on this page earlier. Maybe you missed it. On the IO issue, yeah, i had the same problem. I eventually settled for a BufferedInputStream? and wrote my own version of readLine. -- Vic
Thanks Vic! Though now I am hoping that Kawigi will show me that it is possible with that InputStreamReader?. Please? About your initial phase handling, it obviously works great. But I want to solve it with PatternMatching and, if possible, in a way that is generally useful instead of tweaked against PatternBot. I'm testing an idea right now and will let you know what idea it is and if it works or not once I have the test results. -- PEZ
For the ZipInputStream?, you can just create the stream, initialize it (the whole nextEntry thingy), and then do something like:
BufferedReader in = new BufferedReader(new InputStreamReader(zipin));...and you should be all set. It might work better if you also do this when you write the file - initialize your ZipOutputStream?, and then use a PrintWriter? instead of a PrintStream?:
PrintWriter out = new PrintWriter(new OutputStreamWriter(zipout));...of course, you may find that writing with a stream and reading with a reader works fine (its writing with a writer and reading with a stream that might have issues, because streams weren't written with readers/writers in mind). -- Kawigi
Many thanks Kawigi! It works great! Now I can save the full "movie". The size dropped from 170k to 4k! =) The code now looks like so:
private void saveMovie(String enemyName) {
try {
ZipOutputStream zipout = new ZipOutputStream(new RobocodeFileOutputStream(getDataFile(enemyName + ".zip")));
zipout.putNextEntry(new ZipEntry(enemyName));
PrintWriter out = new PrintWriter(new OutputStreamWriter(zipout));
for (int i = 0; i < Math.min(movieSize, PM_LENGTH); i++) {
Frame frame = (Frame)movie.get(i);
out.println(frame.headingDelta);
out.println(frame.velocity);
out.println(frame.isInitialPhase ? "1" : "0");
}
out.flush();
out.close();
}
catch (Exception e) {
System.out.println("Error saving movie: " + e);
}
}
private void restoreMovie(String enemyName) {
try {
ZipInputStream zipin = new ZipInputStream(new FileInputStream(getDataFile(enemyName + ".zip")));
zipin.getNextEntry();
BufferedReader in = new BufferedReader(new InputStreamReader(zipin));
String line;
do {
line = in.readLine();
if (line != null) {
double headingDelta = Double.parseDouble(line);
line = in.readLine();
double velocity = Double.parseDouble(line);
line = in.readLine();
boolean initialFlag = (Integer.parseInt(line) == 1 ? true : false);
record(headingDelta, velocity, 1, initialFlag);
}
} while (line != null);
in.close();
}
catch (Exception e) {
System.out.println("Error restoring movie: " + e);
}
}
The alert reader also can see that I have kept the idea with including "initial phase" info in the movie. It seems to work a little better with it than without. -- PEZ
Thanks Kawigi! That will help clean up my code :-) I better remove my solution from this page since it is completely useless now. --Vic