[Home]BeeWT

Robo Home | Changes | Preferences | AllPages

PEZ's Bee gun with data saving and loading.

The result of the discussion on the WikiTargeting page.

To take full advantage of BeeWT 1.1's data saving, clear the data file before running a long (100+) match.

BeeWT's 1.0 and 1.1 can be found at the Repository. 1.2 can be found at https://www.ginnezeek.nl/robocode/wiki.rrgc.BeeRRGC_WT1.2.jar because it's too big a file for the repository :-)

--Vic


My first tests suggest that it works. I ran lots of 35 round matches without data, and the same amount with saved data (data gathered in 100 round matches) and on average there was an increase in score of 2 to 3%. I am curious what it will do in the "real world" of the RR. But that means first BeeWT has to be equipped with data from all RR participants..... volunteers? ;-) --Vic

I can do it. Will take a day or two to do 100 rounds against each. -- PEZ

Hmmm. 100 rounds worth of data for all RR bots won't fit the 200K limit, would it? The files are 1k each.. -- PEZ

Well, as you should easily beat all the HOT bots (due to your movement) an ugly hack to use for testing would just be to manually populate a Vector with all the HOT bots (or enough to go beneath the 200 bots limit you have) and not save any data on these bots. Not good in the long run, but should work for testing purposes... --Brainfade

What CassiusClay does is to only save movement data on bots that are easily tricked. Maybe BeeWT could do something like it, but the opposite (like Brain suggests, only a bit less hard coded). Welcome back btw Brain! -- PEZ

Gah! After 60 bots I did something to the repository (maybe it was packaging a new CC) that made all the data files in BeeWT's data dir be reset to the ones shipped with the jar file... Well. Since it won't fit data for all particpants anyway, I'll wait with starting it all over again until we have figured out how to best use those 200k. -- PEZ

Are there already so many participants?? Maybe we should consider thinning out that population.... But anyway, there are now about 300 participants in 1-v-1. So that means the filesize has to shrink even further to about 667 bytes. That's a f@#$ing small filesize! As a quick fix I have decreased the number of SuperNodes saved to 200. I'm running RoboLeague right now to get the data files.

In the mean time we could try to find a solution for saving the data more efficiently. Currently, I'm using Mue's suggestion of saving in index-value pairs where the index gets 16 bits, the value gets 8 bits. I'm using DataOutputStream? and DataInputStream?, and of course the streams get (un)zipped, although I don't think zip does much to make these files smaller. The mentioned 16+8=24 bits are actually too much. As I suggested before on the WikiTargeting page 14+5=19 bits are enough.

So, does anyone know how to save/load an int in 14 or 5 bits? What in/outputstream should be used? etc..

Any other ideas to save SuperNodes in tiny files?

--Vic

Thinning out the RR population? No way! Doubling it, yes. Trippling it, yes. Shrinking it, no. =) Maybe if we place all files in the same zip-file things will get smaller. Zip will have a chance to shrink things when two bots have the same movement. And there'll not be that zip overhead on each file (not that i have a clue how big/small that overhead is). Normalizing all int data down to byte size might help to? -- PEZ

So how do you find the right data file in one Zipfile? The ZipInputStream? does not work in a random access manner afaik. I don't quite understand what you mean by normalizing int down to byte size. Maybe I already do that. I save the index using writeShort(int i), and the value using writeByte(int i). Is that what you mean? If so, that's still a total of 24 bytes, where we only need 19. --Vic

I'm not completely sure how to write multiple files in one zip file. I would think it's about getNextEntry() and such. I'm not sure what writeShort() and writeByte() does. I thought like maybe dividing all values by the ratio of sizeof_int / sizeof_byte before writing them. That should make all values fit in a byte (shouldn't it?). An index needs 5 bits doesn't it? Using some bit shifting tricks and such it should be possible to write out all indexes in a row. And then all values in a row. This is just random babbling. You might have thought about this and disregarded it long ago. =) -- PEZ

I think the functions (from DataOutputStream?) I use do something similar to what you say. Your other solution should work I think. It will be quite a lot of work though. I envision numerous new classes to be written :-) Maybe we should implement something like that when BeeWT 1.2 proves that this data saving thing works at all. --Vic


I've managed to cram data on all participants (and a few more) into WT's data directory. Unfortunately the repository does not accept BeeWT because its size is now too big. :-( It is available here: https://www.ginnezeek.nl/robocode/wiki.rrgc.BeeRRGC_WT1.2.jar

Version 1.2 does not save data for stability reasons. You'll have to use version 1.1 to create the data files.

--Vic

"Maybe ... when BeeWT 1.2 proves that this data saving thing works at all.". If 27 points doesn't prove it, then what does? =) Insaneley good work man! Expect a CC 1.9.9.00WT tonight. -- PEZ

Thanx! I didn't expect it to do THAT good with only 200 SuperNodes saved. I guess this definitely proves that SuperNodes exist. If you need any help porting the serializing code, just shout. I'm right here behind my computer (designing my new movement scheme actually). --Vic

I'm off to bed! We may have a new king tomorrow..... I'll leave my RR client running. --Vic

It's out now. I only copied the load() function from BeeWT and about 200 of the data files. -- PEZ

A disappointing result... there must be a bug in there. Or maybe you can't just use the same data files with a different movement: in a way, enemies react to your movement too. But I'm not sure about this. Any clues, PEZ? --Vic

That WT data wasn´t acquired with CCWT? If so, i think that Vic has a good point here... Most bots move reacting to the enemy´s moving, and not to enemy´s gun. Excepting, maybe (and that´s a great maybe), WaveSurfers that reacts mostly to enemy´s gun.... -- Axe

I think I know what it is. I use the latest Bee and loading data from an older version. I checked the segment widths and they were the same. Which means the data loads without comlains. But I also drew the conclusion that this meant I used the same segmentations. Which I don't. I have changed velocity segmentation in a way that I think can explain the whole difference between 2063 (which was what I hoped for) and 2047 points. What we need to do is either:

  1. Reset current Bee's velocity segmentation (which I'm a bit reluctant to do, since I do think my current one (which is Pulsar's improvement on my velocity segmentation theory) is better.
  2. Use the latest Bee in BeeWT. Which might be more work, but would be safer since I might have forgotten some othe small or big change...
Then when this is done, next step is SilverFist WT. Just imagine!

I can't believe that both of you Vic and Axe are starting that crap movement-influsences-targeting thingy on the first little setback! I don't buy that at all. Especieally not when the Raiko movement and Butterfly are so similar from a distancing / orbiting / WallSmoothing point of view.

-- PEZ

Well, your last phrase admits that u at least are considering that possibility, right? Taking a extreme (VERY EXTREME, i know!) case: imagine if the data acquired came from a rammer bot...
Anyway, i ain´t a WT expert (not even close, u know), but i´m not getting this: why don´t u use CCWT to acquire that data? -- Axe

Ummm, because I don't want to spend four weeks on figuring out how? =) -- PEZ

Ah. That changed segmentation is probably the bug. If you don't want to reset your current segmentation then, as Axe suggested, you should acquire the data with CCWT. Which is basically the same as your own second solution, because that will result in a new BeeWT. As I said earlier, I'm more than willing to help you with that. I am VERY curious where that would take CC, and also SilverfistWT?! Those bots will ROCK! --Vic

Actually the most interesting bot right now is SilverFist WT. That bot could use the BeeWT 1.2 gun and data as it is. And I won't have to maintain two branches of CC guns. =) Axe, check the BeeWT source and you'll see how to plug in that gun instead of the current Bee. It's pretty similar setup, just a little bit more entangled. -- PEZ

Quick question-if you were to use the serialize() method above that Vic posted how would you get the data from it AND put them in the correct segment? --Starrynte

Where is that serialize() method? ...in BeeWT? Anyway, you'd need to have the same exact data structure (same segments in the same array) as that version of Bee had, then taking Bee's code for loading the data should be pretty straightforward. You'd probably want to generate your own data unless you want to be stuck with Bee's segments. Dookious also has pretty clean code for saving / loading WikiTargeting data in its gun - that might be easier to use to build your own. I can give you more specific pointers on finding, using, and/or just understanding that code, if you'd like. =) Let me know. -- Voidious

Ah... The code on the WikiTargeting can't be read back in, unless I'm missing something. I think its only purpose was for diagnostics - to see how many nodes were being used and print some data about them. It also uses a very lengthy ASCII format that you don't need; in Dooki, I use 3 or 4 bytes (can't remember) for each record and write out in binary, while each ASCII character would be a whole byte. To read / write WikiTargeting data, you need to:

A good example of this is in dgun/MainGunHighBuffer.java in Dookious' source code, if you want to take a look. (Parts of it will greatly resemble that WikiTargeting method.)

-- Voidious


Robo Home | Changes | Preferences | AllPages
Edit text of this page | View other revisions
Last edited August 23, 2007 2:24 EST by Voidious (diff)
Search: