Robowiki - User contributions [en]

Template:Robobot/Status

2009-10-08T03:52:46Z

Robobot: Robobot 0.1 : update last running time

<noinclude></noinclude>{| style="clear: right; width:270px; float:right; margin:0em 0em 0em 1em; border:1px solid #87CEEB; text-align:center; background-color:#FFFFFF;"
| style="background-color:#f0ffff; text-align:center;" colspan="2" |'''[[User:Robobot|Robobot]] Status'''
|-
| style="background-color:#FFFFFF; font-size: 40px; text-align:center; padding-top: 20px; padding-bottom: 5px;" | <div style="color:green">Healthy</div> Last run: Thursday, October 8, 2009 3:52:35 AM UTC
|}

Archived talk:Wiki Targeting 20090501

2009-10-08T03:52:45Z

Robobot: moved Wiki Targeting/Archived Talk 20090501 to Archived talk:Wiki Targeting 20090501: move to talkarchive

{{Navbox small
| title = Sub-pages
| parent = Wiki Targeting
| page1 = Dynamic Segmentation
| page2 = Code
| page3 = Archived Talk 20090501
}}
{{Talkarchive|Talk:Wiki Targeting}}

Way cool! I don't follow along all the rocket science stuff, but I like that you keep thinking big. =) I agree that a pre-trained gun like this would not be too impaired by the adaptive movers yet since they are not plenty. I wonder one thing though. What is it that makes a super-node? I understand that tghe figure 100 is a very, very raw estimate, but I still wonder where it comes from. A node with just one sample in it doesn't contriubute of course. With two samples there's at least a theoretical possibility, though only with 1/16 or so. I'm assuming here that with enough dimensions one previous sample is enough to make it useful. Maybe that's a wrong assumption? I think that the number of super-nodes will vary greatly depending on the enemy bot. Some simple movers might have very few. If we only save the data from the actual super nodes we might shrink the data size greatly. And this might also make the dynamic segmentation unecessary? (Not that I really have a clue what dynamic segmentation is about...) -- [[User:PEZ|PEZ]]

A node is a super-node when it produces successful predictions. How exactly it would be defined I don't know. The definition is only that is contributes significantly to the score. That means it's a combination of how predictable the enemy is in that particular node and the number of waves collected in that node. I am not a math wizard so the figure 100 is not based on anything fancy. It's an intuitive number with which I get the feeling that if there is a tendency in the enemies movement in that particular segment, I will find it. But as I said, it could be much lower: 50 or even 20. I would love a statistics wizard's view on this! You say 1 previous sample can be useful. My view here is that since it has only one sample, this node is obviously hardly ever visited by the enemy, so discard it for the sake of file reduction and run the risk that you miss one or two shots more when it unexpectedly does visit that segment. Of course the loss of these shots (in total estimated at 20%) will have to be compensated by the remaining super-nodes. These need to be at least 20% more accurate after 250+ matches than CC would gather in 35 matches. I think you are right that the number of super-nodes will depend on the quality of the enemy's movement. This could definitely work in our advantage when reducing filesize. A lot of assumptions I made are very, very raw. I am hoping that some people have investigated some of this stuff before and can fill in the right numbers. If not, we must find the right ones ourselves. Maybe in that case we can use CC or another top GF gun to find out some of this stuff. Shouldn't be too hard. About dynamic segmentation: I'm a sucker for that stuff. But if this can be done without DS I'm all for it. I can think of a couple of reasons why we *should* use it, but not using it would save a lot of file space. We should discuss that in some more depth. Thanx for thinking with me! --[[User:Vic Stewart|Vic]]

What I meant was that 1 previous sample is useful if that's what you have when you are to fire. If it was correct last time, chances are it's correct this time too, in'it? Of course if after a 250 round battle you have nodes with only one visit in them these nodes are pretty useless. But I think a super node should have a spiky distribution. This is more important than the number of samples in the node. (If it's 10000 samples with a flat profile, we're not any better of than without samples, are we?) Of course we'll need enough samples to tell that the spike is statistically significant. On the issue of dynamic segmentation. Can you name the main reasons you think it's needed? That would maybe help me understand what DS is and also make us able to see if DS can be substituted with one or several other techniques or not. -- [[User:PEZ|PEZ]]

I agree with you on the spiky nodes issue:
* We need spiky nodes. I think calculating the spikyness would not be too difficult:
** use a regular, Botwidth Aware, array and a pure visits array
** find the spike using the botwidth aware array
** find the corresponding bin in the pure visits array
** retrieve the number of visits in that bin
** retrieve and add its neighbours considering bot width
** calculate the percentage of retrieved visits against the total number of visits. That would give you a hit chance which would increase as spikyness increases.
* We need to be sure that we have enough samples to be sure this spike is statistically significant.
But, I do think there may be a category of supernodes that is visited very, very often, but is quite flat. Let's call these Nemesis Nodes :-) Even if the rate of scoring in these nodes is much lower than that of the spiky nodes it still contributes significantly to the score because it is visited so darn often. Of course these are the nodes that we hate :-) But we cannot discard them in my opinion.
This is also a good example where dynamic segmentation may be useful: DS may be able to split these Nemesis Nodes up into smaller nodes that may be more spiky. I don't think DS is needed per se, but at least it would be interesting :-) without DS the data files could probably be smaller.
Other reasons why DS may be useful:
* In stead of simply throwing non-supernodes away, like we discussed earlier, DS should be able to group these together in better populated nodes. This should increase the chance of finding a significant spike.
* Sometimes a segmentation axes may be useless against a specific enemy (or in combination with other segmentation axes values). That means that using this segmentation will not help find spikes in the enemy's profile. In fixed segmentation it will only lead to thin out the population of the nodes. Removing this axis would increase the population and a significant spike may be found earlier. DS would test if splitting up a node into two or more nodes would result in more spiky nodes. If not, no splitting should occur. --[[User:Vic Stewart|Vic]]

brainstorming on fixed segmentation and supernodes: suppose we simply use fixed segmentation like used in CC. We run 250+ matches and discard the non-supernodes. We save the supernodes in a file. Now our robot retrieves that file and fills part of the array (the supernodes only). That means most of the nhe n will be empty. If an empty node is visited we could
* fire head on... yuck..
* not fire at all (it is likely that within a few ticks a supernode is visited)... interesting..
* fire a wave and collect it later so this empty node has a value. Next time it's visited, use it for aiming... hmm.. dunno..
How would the saved file look like? How can we make sure the right supernodes will be loaded into the array in the correct spot? If we could solve this, then I think implementing such a gun would be much easier than I initially thought. --[[User:Vic Stewart|Vic]]

Version 1.9.6.13 of CC tried to hold fire when it didn't have a certain amount of visits in the node. I tried different limits, but using "roundNum * 3 + 3" seemed to only actually hold fire in the beginning of the first round. This indicates that most nodes in the CC guns actually are visited multiple times during even a short battle. From my tests and the RR results this variant of the gun didn't perform any better than without this feature (rather sligthly worse). Note that I didn't check for spikeyness, which might tell a different story all together. As for data format for a non-DS version. We could try simple write the array object like CC does with its surf data. Before writinig we could mark all non-super nodes by writing -1 in all the buckets of them. I think this would help zip shrink the file considerably. Another option would be to use a crib sheet like [[Swiffer]]'s. Again with -1 marking a non-super node. (And then filling all buckets with -1 upon reaiding the data.) -- [[User:PEZ|PEZ]]

Sounds like an interesting idea. The biggest advantage i see is that you can revert to only use information gathered from waves that are aligned to real bullets (since the lack of samples is no problem anymore). That should produce better results vs movements that react to bullet fire (except real adaptive movements of course). On the other hand the inability to adapt might be a problem. I dont know how many bots in the rumble use some kind of adaptive movement, but im sure its not only wave surfers (thinking of [[MusashiTrick]]...). So combining this gun with a learning one might be necessary; perhaps using WikiTargeting first and switch to the other gun if the hit ratio is lower than it was while recording the data?

I just looked up what [[CribSheet]] means. If i understood it correctly, it will produce one value for each node (so in case of CC's segmentation 12500 values, which would be too much). Perhaps it is better to build up this crip sheet array and store just the pairs of index (2 bytes) and corresponding best guess factor (1 byte) for super nodes. If less than one third of the nodes are super nodes this should consume less memory, shouldn't it? Of course using zip might change things..., i have no experience there. --[[User:Mue|Mue]]

Well, It's easy enough to write two nodes in one byte. Which would amount to 6225 bytes. Zip ratios of 90% ave been seen before so it would fit. At least it could be tried without too much effort. We could write two or three different implementations and just pick the most efficient one if there is a big difference, or the simplest one if the difference isn't too big. -- [[User:PEZ|PEZ]]

Two nodes in one byte? Can you explain how? If you are right about most nodes being visited above your limit then the entire assumption of the existance of supernodes is false. In that case this whole theory is false and it is back to the drawing board (oh wait...that's where we are now :-). I think we should find out more about the distribution of nodes in the array before we can progress. I have thought of a formula that returns a node's Contribution to the gun. It is simply VirtualHits (as I described above) * BulletDamage. I think we could modify CC slightly to save a file containing a node per line, including this Contribution number and the segmentation indices. With that file we can check if super nodes really exist, and if so, how much of those there are. This modified CC would only need one 'shadow' array with pure visits (I assume CC takes botwidth into account with the existing array) and a function that analyses the nodes and writes the results to a file at the end of the match. If I have some extra time the coming days I'll try to make this CCWT version, but you are also welcome to do it if you want and have the time. Your solution for saving the data could work. I forgot about the fact that a file will be zipped when using a zipstream. Another (more difficult) solution would be saving a bitstream with 1 bit to denote a supernode/non-supernote and 6, 7 or 8 bits describing the optimal GF (only in case of a supernode). If that can be zipped then I think we're as small as we can. --[[User:Vic Stewart|Vic]]

[[User:Mue|Mue]], yes, we could try firing only real bullet waves. In theory that should work, provided the number of matches we need does not spin out of control. We will need about 15 times more matches in this case. On the other side of the spectrum, I was thinking of sending multiple waves per tick, for different bullet power levels. That would give us an extra choice: use the bullet power which corresponding node has the highest contribution (VirtualHits * BulletDamage) to the gun's success..... Switching to an adaptive gun in case of adaptive movement should work, although I think that the gain here would not be very high. About crib sheets: I think even one third would be too much. Also 2 bytes extra info per supernode is as expensive as using dynamic segmentation as described somewhere above. [[User:PEZ|PEZ]]'s solution or my solution below would produce smaller files I think. I appreciate your input! Are you by any chance good at statistics? We could use some guru input in that field as well. --[[User:Vic Stewart|Vic]]

I was too quick saying you could write two nodes in one byte... That would limit us to using 16 bins and that's not really useful. Sending multiple waves per tick doesn't work for the purposes you want. Even if most bots are non-adapters, plenty of bots use the actual bullet power in their movement. As for the existance of super nodes. They might still exist if they are defined as "being used enough times to become accurate and being spikey". As for firing only "real" waves. I'm not sure it pays. But it can be tested. CC doesn't care about bot widths anywhere, though it has a method in its wave objects that returns the target bot width in factors. (This function is going to be deleted in the next version of CC though, since it's just dead meat.) I guess, in your parlance, this means CC is only using pure visits. I won't have the time to code much at all the coming days. The time I have I will spend try finding out why CC is the only surfer that does not shut out japs.Serenity... -- [[User:PEZ|PEZ]]

One more thing. While Bee might be the best TC gun by some margin, it's not the best RR gun. I think that this WikiTargeting thingy's biggest promise it that it could provide us with a tool to explore just what segmentations to do and how to optimize the results. -- [[User:PEZ|PEZ]]

Well, CC (or Bee) is the best GF gun in the RR, tied with [[Raiko]]'s gun. Plus it's open source and very clearly coded. That's why I picked it as an example. I hope we get to the stage that we build the tool you mention. That would indeed be interesting. But if we decide to stick to fixed segmentation the tool is not needed for this gun. It would be needed if we went with dynamic segmentation. Of course DS could be a separate thing to explore. Ok, I'll see if I can find the time to hack together a CCWT and analyse some data. --[[User:Vic Stewart|Vic]]

Just the results from trying to identify the super nodes will make a good tool if you find a good test bed and are ready to hand tune the segmentations. Maybe DS is a better path, but I'll keep the judgement of that until I've seen it working. =) Please base any [[CassiusClay/Bee]] WT bot on BeeRRGC rather than CC. That will allow direct comparison with the other RRGC bots. How about BeeWT? -- [[User:PEZ|PEZ]]

@[[User:Vic Stewart|Vic]]: No i'm not that good at statistics :-) --[[User:Mue|Mue]]

I haven't had the time yet to create BeeWT yet. I'm too busy with work right now, and next week I'll be off on a 3 week vacation. Until then a few [[Locke]] tweaks will be the only thing I can manage. --[[User:Vic Stewart|Vic]]

Maybe this could spark some discussion on the subject of /DynamicSegmentation --[[User:Vic Stewart|Vic]]

The first results of the BeeWT test are in: in a 35 round match against RaikoMX, BeeWT fired and collected 19885 waves, and distributed them amongst a total of ................. no more then 572 nodes!!!!!!!!!!! (out of a possible 12500). Of these nodes the sizes differ greatly, and I have counted 52 nodes with 100+ visits. I am now confident that supernodes DO exist. I'll post BeeWT on the repository right away, so you can verify my results are correct. Here's the piece of code responsible for saving the visits data:

<pre>
public static void serialize(File file)
{
try {

ZipOutputStream zipout = new ZipOutputStream(new RobocodeFileOutputStream(file));
zipout.putNextEntry(new ZipEntry("data.txt"));
PrintWriter out = new PrintWriter(zipout);

double totalVisits = 0;
int totalFilled = 0;
boolean check = true;
for(int a=0;a<BULLET_POWER_INDEXES;a++) {
for(int b=0;b<DISTANCE_INDEXES;b++) {
for(int c=0;c<VELOCITY_INDEXES;c++) {
for(int d=0;d<VELOCITY_INDEXES;d++) {
for(int e=0;e<TIMER_INDEXES;e++) {
for(int f=0;f<WALL_INDEXES;f++) {
double visits = 0;
double coverage = 0;
double value;
//count visits
for(int bucket=1; bucket<FACTORS; bucket++) {
value = factorsFull[a][b][c][d][e][f][bucket];
visits += value;
if (value > coverage) coverage = value;
}
if(visits > 0){
totalFilled++;
totalVisits += visits;
String line = (int)visits + " " + (int)coverage;
out.println(line);
}
}
}
}
}
}
}
out.flush();
zipout.closeEntry();
out.close();
System.out.println("total visits:" + totalVisits + ", used nodes:" + totalFilled + " (of 12500)");
}
catch (IOException e) {
System.out.println("Error writing file:" + e);
}
}
</pre>

No mistakes I hope, [[User:PEZ|PEZ]]?

--[[User:Vic Stewart|Vic]]

That looks correct. -- [[User:PEZ|PEZ]]

Wow! interesting ideas, [[User:Vic Stewart|Vic]]! First time reading this, and it sounds indeed interesting. Unfortunately i had only take an overview, i´ll read it with more calm later... -- [[User:Axe|Axe]]

I've analyzed the data some more. The big conclusion is:

'''95% of BeeWT's hits are done by only 450 supernodes!'''

I have defined hits as the number of visits in the most visited bucket of each node. In this case a total of 3361 visits are 'hits'. The 450 nodes with the highest 'hits' number have a summed total of 3211 hits. So if you discard the non-supernodes, you only discard 150 hits, or 5%.

Loading data from a file containing 450 supernodes would make Bee operate very strongly (as strong as 95% efficiency of a 35 rounds filled array) from the start of a new match. Making Bee perform even better is as simple as saving data after longer matches.

Now how do we serialize those supernodes? My suggestion would be: save each supernode as a index-value pair (as [[User:Mue|Mue]] suggested). Each node has an index 0-12499. This can be coded into 14 bits. A node contains 27 buckets, so the best bucket (most visited GF) can be encoded in 5 bits. 450 supernodes * (14+5 bits) = 8550 bits = 1069 bytes = 1.04 kB. Hopefully zipped this number can fall below 1 kB, meaning we can save data on all RR participants. I think this can be done, and I think this could make BeeWT the strongest gun yet.

Thoughts?

--[[User:Vic Stewart|Vic]]

----

I think it's fair to say the SuperNodes theory checks out. BeeWT, CassiusClayWT and SilverFistWT are all doing insanely well with prepopulated data files on all RR participants. Each data file contains only the 200 best SuperNodes and their best GuessFactor. Should we pursue this path even more and experiment with things like:
#cramming more data in a file
#identifying which enemies it actually performs worse against compared to not using saved data
#use longer matches when generating the data files
#(dis)allowing saving data on short matches (after you save a file, you're stuck with those SuperNodes+bestGF forever)

About WikiTargeting in general, is there interest to continue the discussion on this page? Now that the SuperNodes issue is "resolved" the discussion on how to get the most efficient segmentation can continue if anyone is interested.

--[[User:Vic Stewart|Vic]]

How many rounds did you use to populate BeeWT 1.2? -- [[User:PEZ|PEZ]]

An interesting (imho) observation to make is that [[Bee]]'s rationale for using the segmentations it does was formulated without SuperNodes in mind. I'm trying to strike a balance between high granularity and fast enough learning. But with SuperNodes data management we can try segmenting much harder. -- [[User:PEZ|PEZ]]

100 rounds. Segmenting harder does come with a price: for each SuperNode that you divide up (into more spiky nodes) you have to drop one existing SuperNode from the datafile. I agree it does become easier to experiment when you don't have to worry at all about fast learing. Wait a minute, you do have to worry when you have no data on the enemy. Then it becomes just regular (non WT) targeting. --[[User:Vic Stewart|Vic]]

That's not a problem. Just use the current buffers for targeting while you are collecting data in the SuperNode aware ones. -- [[User:PEZ|PEZ]]

Yes, if you simply keep those buffers separated then there's no problem. About harder segmentation: we could use an offline application to read all WT data files and generate an overview of which nodes are most visited overall. That would give us insight on what to split and what to lose. Anyone care to write it? It shouldn't be that hard, since the code of reading the files is already written. I have my hands full at the moment. --[[User:Vic Stewart|Vic]]

This discovery of SuperNodes has convinced me even more that dynamic segmentation is the way to go. One worry I had before was if I could manage saving data of enough tree nodes to compete with GF targeting. Now the'e've found that only 200-500 nodes do all of the work, it may even be possible to save segmentation data AND best GF's of that amount of tree nodes. --[[User:Vic Stewart|Vic]]

Somewhere I saw discussion about reducing the file size for WT. These are generally small zipped files, where the zip header is a big part of the size. However there is a quite simple solution:

bash-2.05b$ echo qwerty >qwerty
bash-2.05b$ zip qwerty.zip qwerty
adding: qwerty (stored 0%)
bash-2.05b$ gzip qwerty
bash-2.05b$ ls -l qwerty*
-rw-r--r-- 1 lrem users 34 Sep 27 19:45 qwerty.gz
-rw-r--r-- 1 lrem users 151 Sep 27 19:45 qwerty.zip

Any conclusions? :>
-[[lRem]]

Yeah. I agree. I wrote above that I thought putting all files in one archive would help reduce zip overhead. Your example there is pretty convincing. =) -- [[User:PEZ|PEZ]]

That't't all. I'm not quite sure how the files look (I'm to lazy to check it by myself :P), but I suspect that not zipping at all could even reduce the size. This statement could be even more true if you did the bit-shifting trick, which is in fact a very effective number compression ;) And this could be done in quite short code, at least I was able to do so in C++. -- [[lRem]]

I doubt the raw files would be smaller unzipped. We need to save an index into the soap of 12500 nodes and also what bin is the most visited. This for 200 nodes. Without bit shifting this means 2 bytes for the index and 1 byte for the bin number. 600 bytes. Well, that means the zipped files are aboutthe same size as the uncompressed ones. But with all enemies' data in the same archive this could probably be shrunk considerably. Bit shifting should be pretty simililar in C++ and Java since they share the operators for it. But lets not resort to that until we know how far we get with the single-archive change. -- [[User:PEZ|PEZ]]

The bit-optimised raw files _are_ smaller unzipped. I use them in Shadow's movement, the smallest ones grow to double the size when zipped. You don't have to shift bits though, just some multiplications and additions. Anyway, the single file solution is probably the best. -- [[User:ABC|ABC]]

Hehe. Bit shifting and additions can be very similar to multiplications and additions. In fact back in the days when CPU's didn't have multiplication operations you had to bit shift to achieve things like multiplication and division. Anyway, the single file solution is probably the best. =) -- [[User:PEZ|PEZ]]

If your multiplications/divisions are all by 2^x you'll just gain execution speed. Acceleration, for example, is normally defined by 0-3, you'll lose 1 bit by bit-shifting :). The single file solution is, otoh (and imho), harder to code, you'll have to include some time-stamp if you don't want it to crash after a lot of rumble updates. With a multiple file solution you can use the file creation date to delete the oldest file when there isn't enough room for a new one... -- [[User:ABC|ABC]]

Does anyone have any example code on how to pick the right data file from the zipfile when reading the data? Currently the solution to [[User:ABC|ABC]]'s problem is quite simple: don't save any data when there is no data file available. Besides the data quotum reason I did this for two other reasons: 1>having no data file could be by choice. (i.e. against adaptive movers) 2>datafiles on short matches are not very good anyway. --[[User:Vic Stewart|Vic]]

Isn't it as simple as calling getEntry(enemyName) on the zip file instance? Check this page: http://java.sun.com/j2se/1.4.2/docs/api/java/util/zip/ZipFile.html#getInputStream(java.util.zip.ZipEntry) -- [[User:PEZ|PEZ]]

You are right, a multiple entry zip file should be just as easy as a multiple file solution, but I don't know if the compression rate will be the best. I was thinking about a single entry zipped file where you would store a big structure with all the enemies data... -- [[User:ABC|ABC]]

Ah, I had only looked at ZipInputStream. Cramming a ZipFile inbetween should do the trick then. [[lRem]], thanx for your input! Could you provide a code example of how you would implement the bit-shifting trick? Pseudocode will do, but the real thing would also be appreciated :-) As far as I've considered it the main problem is the absence of a BitOutputStream class and its Input couterpart. So I'm curious how you have solved it "with little code" as you said it. --[[User:Vic Stewart|Vic]]

For example:
Assuming 10 bulletTime segments, 3 vel and 3 accel. To store the node coordinates in one byte you could do this:

byteVal = (byte)(bt + v * 10 + acc * 30);

(Note: in this case you waste some bits, since the max value is 139. For perfect bit usage you'd have to use only power-2 segmentation)

To convert it back to ints:

int acc = byteVal / 30; 
int v = (byteVal - acc * 30) / 10; 
int bt = byteVal - acc * 30 - v * 10; 

-- [[User:ABC|ABC]]

This is similar to building hashCode() keys with the exception that here you ''must'' build uniqe keys of course. Anyway, I think this might not be necessary. Why not try zipping several files in one first. If it's not small enough try writing all data to one single zip file (or gzip which might get smaller). If that's not small eneough we can consider resorting to custom compression schemes imho. -- [[User:PEZ|PEZ]]

Use gzip. It has very very low overhead... Even for data that can't be compressed the file size will only be 10 bytes larger than the raw data. In addition you get the file modification times which can be useful as ABC pointed out. I would only use ZIP for larger files, or files which you know will compress well. In those cases the ability to set the compression level for a ZipOutputStream might make up for the larger header. --[[User:David Alves|David Alves]]

[[David]], something weird happened with your last post. Some words in unrelated paragraphs where garbled. Look at your diff and you will see what I mean. Any clues to why this happened? --[[User:Vic Stewart|Vic]]

I've seen it before. Thought it was a one of those moron vandals that did it. But it was in a page that David posted actually. Strange thing anyway! -- [[User:PEZ|PEZ]]

I'm using wireless internet access... maybe it's messing things up? I've got a wall between me and the access point... --[[iDvad Alevs]] <-- kidding

---

I wrote a lot of words here, then thought it might be better to move them to a linked page [[PhaseSpaceRambling]] as it's somewhat off the main topic! -- [[Shrubbery]]

I'm thinking...couldn't you use [[Entropy]] to refine what segments to keep? You process all the bins as usual, sort them by the actual bins' [[Entropy]] and then only save the top 50 or so... [[User:Skilgannon|Skilgannon]]

There's still a lot of benefit to keeping the most visited ones instead - a bin visited once in a 35 round battle would probably have the highest possible entropy, but it's surely not as useful to keep as a bin that was visited 500 times but that has a lower entropy. It could be a good tie breaker to choose among bins with similar numbers of visits, though. -- [[User:Voidious|Voidious]]

Yeah, I'm thinking maybe just discarding if the entropy is above a certain level, or the hits are below a certain level. It doesn't help to keep a bin with a perfectly flat (with flat juice on top =) ) profile.

[[Category:Archived Talk]]

Wiki Targeting/Archived Talk 20090501

2009-10-08T03:52:45Z

Robobot: moved Wiki Targeting/Archived Talk 20090501 to Archived talk:Wiki Targeting 20090501: move to talkarchive

#REDIRECT [[Archived talk:Wiki Targeting 20090501]]

Archived talk:When To Fire 20071205

2009-10-08T03:52:43Z

Robobot: moved When To Fire/Archived Talk 20071205 to Archived talk:When To Fire 20071205: move to talkarchive

I do it like this:

* In the run() method I registrer an event I call <nowiki>GunIsAimedCondition</nowiki>
** In the test() method of this Condition I do:
*** <nowiki>return (getGunHeat() == 0 && getGunTurnRemaining() == 0 && (getEnergy() > 0.2 || enemyDistance < 250));</nowiki>
* in onScannedRobot() I aim the gun
* in onCustomEvent() I check for <nowiki>GunIsAimedCondition</nowiki> and when it's there I call <nowiki>setFireBullet</nowiki>

Check [[MakoHT/Code]] to see it "in action". But the problem with this is that my bots seem to fire more seldom than other hard-shooting bots. Does anyone have a better scheme?

-- [[User:PEZ|PEZ]]

getGunHeat() and getGunTurnRemaining() return double values. You may want to put "== 0.0" or "== 0d" instead of "== 0". Using "== 0" has caused problems for some robocoders in the past. Also, you may want to shoot even if the gun turn remaining is not equal to zero. If the gun turn remaining is very small relative to the calculated distance to target impact, you may want to fire. Otherwise, you may find your robot spends more time turning its gun and less time actually firing.

-- [[Ray Vermette]]

Thanks! I'll start using .0 everywhere in my code then. I have tried using <nowiki>Math.abs(getGunTurnRemaining() < 0.5)</nowiki> and such but it seems not to make a difference. I have even tried removing that part of the check entirely (which mean I fire whenever my gun is cool), but it doesn't seem to matter either... Surpisingly enough it doesn't matter for the hitrate either. Possibly because I check the gun heat and gun cooling rate before I aim the gun and that maybe makes the gun aimed well enough when the gun is cool.... WAIT! I don't think I do Math.abs() there. Maybe that's what causing the delay. I must check immediately. -- [[User:PEZ|PEZ]]

The "0" is actually automatically cast to a double in this case, so adding the ".0" isn't strictly necessary. It shouldn't be that causing the problem. In my bots, I extend the GunTurnCompleteCondition instead of redefining my own using "gunTurnRemaining == 0", but I seem to fire as often as possible. Perhaps you should check to make sure you are within the 250 minimum distance at all times?
-- [[User:Nano|nano]]

I was already using 0.0 in my code actually. I try to be consistant about that because Java's automatic casts has bit me hard before. Anyway, yes of course I should extend GunTurnCompleteCondition instead, haven't thought about that. Would it be too much to ask you to post your code for that extension? The 250 minimum distance you are referring to only is checked when my own energy is <= 0.2. Do you have statistics on how often you fire and how often the enemy fires? Maybe if you pick up Orca 0.3.3 when I have uploaded it (soon) you could check its statistics and compare to yours and see if you fire more often? -- [[User:PEZ|PEZ]]

Alright, I will check its statistics. Watch this space. -- [[User:Nano|nano]]

According to the Java language spec, "0" is suppose to be promoted to a double value, but "== 0" has caused problems before, and replacing it with "== 0.0" has fixed them. Don't ask me why. Search through the Alphaworks or RobocodeRepository forum archives for previous discussions on this topic. BTW, you should also avoid using "==" with float/double values -- also discussed and explained in the Alphaworks forum.

Getting back on topic, I agree: I don't think "0" versus "0.0" is causing Pez to shoot less often. You should fire if the gun turn remaining is close enough to zero that being a little off target won't matter. In other words, if the gun hasn't finished turning, and firing now would cause your robot to hit the outside edge of the target versus dead center, then fire! A hit is a hit.

You should only call one turn-ending method in your entire robot. By turn-ending, I mean execute(), fire(), fireBullet(), or one of the blocking methods inherited from the Robot class. If you are calling more than one turn-ending method in your robot, your robot may not be firing as often as it could.

-- [[Ray Vermette]]

I'm not cheking for "gun alignment" when firing, so all my bots fire as fast as possible. The underlying logic is like follows: If your aiming system is good against your opponent, the predicted bearings will be consistent and the gun will be (aloms) correctly pointed (so no need to check). If your aiming system is not good, then it won't be a problem is the gun is aligned or not. Unsurprisingly, all my bots perform better without this check. -- [[User:Albert|Albert]]

Thanks. I needed a reasonable explanation to why I did not notice any real hit rate difference in any of my bots when removing the gun alignment check. Both [[Mako]] which does quite good aiming and [[Orca]] which does rather lousy aiming. =) Though I still seem to fire significantly less often than MicroAspid. -- [[User:PEZ|PEZ]]

May be they are skipping turns? -- [[User:Albert|Albert]]

[[Mako]] skip turns? Nah!!! I think it must be the fastest bot in the top-30. [[Orca]] is a bit more CPU intensive, but it doesn't skip turns either. In the last 10k round battle I put it up in it skipped one (1!) turn. But, I think I now know what is causing this (perceived) problem. I did the simplest of tests (should have done that right away) to put up [[Mako]] against [[Orca]] and they both told me their enemy was fireing more often. =) I have been trusting the energy-drop test too much. I wrongly assumed that only a hit to the wall would result in a drop within the range 0.1 <=> 3.0. Now I realize that when I hit with really weak bullets this happens as well. Anyways, your suggestion and explanation made the code much more simple. Now I fire from the while (true) loop and it works excellently. Not giving me any more bullets in the air though, which is an interesting find, but simpler, so I'll stick with it. I think it might consume less bytes as well which means I now can fit in a thing in [[Gouldingi]] that I have not had room for before. A wiki, good advice from the experts and EmpiricResearch is a powerful combination. =) -- [[User:PEZ|PEZ]]

----

Timed Firing:

Most bots that I have seen usually shoot as fast as possible (shoot when gunheat is 0 and when gunturn is low enough). 
Are there any bots that time their actions and wait until it recognizes a certain situation before shooting? (for example, when target bot reverses direction, or when a bot is accelerating after a full stop).

-- [[User:Dummy|Dummy]], (I wish I had time to play with [[Robocode]]... :-( .)

I used to test a number of conditions before firing, e.g. if the gun was aligned, when i expected the opponent to reverse direction, if a match was found by the patternmatcher, but this resulted in far lower scores on bullet damage. Even when using different kind of aiming techniques, a randomly shot bullet is often equally effective. So i reverted to shooting as much as possible.

my 2 cts, [[User:Loki|Loki]]

Don't you just hate it when you type something click save, and it tells you someone else has already typed pretty much the same thing as you have?? bah: i'm gonna post it anyway:

I doubt it very much, as the problem then is that there may be certain enemies that don't trigger your condition (spinbot for example never reverses direction or accelerates) meaning that chances are you're going to lose. In development i have found that anytime you limit your rate of fire, although your survival can go up your bullet damage tends to go down, and so overall it isn't worth it. -- [[User:Brainfade|Brainfade]]

CrazyGuns (my first public bot) was doing it. It had a kind of rudimentary analyzer, and when it detected the enemy movement was oscillatory, it fired against it just when it was turning. It allowed CrazyGuns to hit oscillators when using linear aiming. Latter on, when I switched to pattern matching, I found no need to use this trick and stopped using it. -- [[User:Albert|Albert]]

----
One more thing... I'm probably doing it the wrong way, but always if I try to add some gun-alignement check before fire my gun loses performance quite much. Since you are one to pay attention to detail I guess you wait for your gun to be aligned with the guessed bearing before you fire? If so, you should try a version that does not do this. -- [[User:PEZ|PEZ]]

Yes, i do this... I already tried not to wait the alignment (in dev. tests), but it failed miserably... There goes some theories, facts & observations about this:
* GF guns have a low processing cost, so guns like [[CC]]´s can stay every-tick updated in the correct (or almost) shooting bearing.
* PM guns have a high processing cost (and [[SS]]´s gun have a VERY hight processing cost), so i only calculate the shooting bearing once per shooting. The rest of the time, the gun stays pointing at the targets position (like [[HOT]] guns).
* If i don´t wait the alignment, [[SS]] ends shooting like a [[HOT]]. In the other hand, if i wait the alignment, this cost me 1 tick of firing rate. So, my solution was to calculate the shooting bearing when the gun is ABOUT to be ready (cooling <= 0.1), so when it´s aligned (1 tick after the calculus most of the times) it´s ready to shoot.
* there is no sense to do this in GF guns, since it´s already aligned for shooting every tick. Waiting for alignment would only waste 1 tick, and make u lose firing rate.
Well, this is my opinions & theories, i would like a lot to know if u agree with them. ([[User:ABC|ABC]]´s thoughts about this would be VERY welcome too. His gun is a lot similar to mine´s and he probably have the same problems) -- [[User:Axe|Axe]]

The funny thing is that my finding holds for my (lousy) PM gun too. Even with the low TC500 score of [[Ali]]'s of 82 something. It's an improvement over LeachPMC's score of 80 something and the only major difference is that I removed the gun alignment check. Though I start my aiming 4 ticks before the gun is cool. Starting only 1 tick before I can see why it would hurt your aimin. As much as I would hate to see SS slower than it is, it might be worth another try from your side. And the rest of us can pray it will not turn out to make your gun better. =) -- [[User:PEZ|PEZ]]

Dunno if i understood it correctly... U start the calculus 4 ticks before, but calculate it only once or every tick till is cool (probably the last, right?)? Interesting, ill take a try... The problem is that [[SS]] would be THE SLOWER BOT EVER!!! -- [[User:Axe|Axe]]

@[[User:ABC|ABC]]: What do u think about this? -- [[User:Axe|Axe]]

I do exactly what you decribed, I only compute the firing angle one tick before firing (getGunHeat() - getGunCoolingRate <= 0). I would think that GF guns should also do it like that, if you shoot with the last tick's bearing you'll be slightly off, even if you compute it every tick. -- [[User:ABC|ABC]]

But [[User:PEZ|PEZ]]´s idea has also merits, i´ll take a try later in my gunnery experiments. My gun gets a lot slow in the last rounds, and maybe i´m losing firing rate computing only in gunHeat <= 0.1... But this scheme probably would make it real heavy in processing, and could affect my movement. Anyway, i´ll try it later. Thanks for the sugestion, [[User:PEZ|PEZ]]! -- [[User:Axe|Axe]]

ABC, do you also wait for the gun to align before you fire? -- [[User:PEZ|PEZ]]

(edit conflict) I don't understand how computing the firing angle in a turn when you will not be able to fire can help your hit rate. If you do it correctly it will only miss in very extreme cases when your gun is unable to turn enough in 1 tick. Because of those (rare) cases, I keep the gun slightly ahead of the HOT angle when the enemy is close and traveling at top speed. But this logic aplies to all gun types, if a GF gun computes a -1 guess factor in the previous tick and then says you should fire at +1 the gun won't be able to turn quick enough and you will miss by much more than if you had the gun aligned with the enemy. -- [[User:ABC|ABC]]

I get your message about not letting my gun compute and aim every tick. I'll try it immediately. But with waiting for alignment I mean something like this:
<pre>
double gunAlignmentDelta =
normalRelativeAngle(getGunHeadingRadians() - guessedEnemyBearing);
if (Math.abs(gunAlignmentDelta) < Math.atan2(HALF_BOT_WIDTH, enemyDistance)) {
setFire(bulletPower);
}
</pre>
-- [[User:PEZ|PEZ]]

Yes I check if the gun has finished turning (getGunTurnRemaining() == 0), but I don't think I need to, it's old redundant code. I remember making some tests that indicated it always turns enough in 1 tick. -- [[User:ABC|ABC]]

Waiting for alignment like that is wrong, imo. With that code you'll only fire when the previous tick's prediction is close to the current tick's one. That will miss a lot of opportunities to fire. -- [[User:ABC|ABC]]

Yup. So you don't do anything like that? You just trust the gun will have turned enough? -- [[User:PEZ|PEZ]]

What i meant is that if computing the shooting angle takes more than 1 round (if), i can be losing firing rate. Computing it earlier could correct this... -- [[User:Axe|Axe]]

Or maybe (if i understood [[User:ABC|ABC]]´s words), just calculating and setTurnGun(angle) in T-1 and firing at T (without the getGunTurnRemaining() == 0) could also improve firing rate... -- [[User:Axe|Axe]]

Yes. If I aimed the gun in the previous tick, I fire. -- [[User:ABC|ABC]]

Axe, you mean it could take more than 1 tick to compute your guess? I don't think that's the case with my gun... -- [[User:PEZ|PEZ]]

If you take more than 1 tick to compute your guess, you need to find a faster way... :) -- [[User:ABC|ABC]]

One more question. If I turn the gun and fire in the same tick. Isn't that the same as using the last ticks gunHeading to fire? -- [[User:PEZ|PEZ]]

(edit conflict!)Not yours for sure, [[User:PEZ|PEZ]], but maybe that is happening with me (MAYBE) in the last turns... The problem is that this probably depends a lot in the environment that it is running. I´ll never know for sure. -- [[User:Axe|Axe]]

iirc, my tests show me that: if u use setTurnGunRight(angle) and setFireBullet() in the same turn, the bullet will be fired, THEN the gun turns... (not 100% sure, i made this test a long time ago) -- [[User:Axe|Axe]]

OK. So then I have been doing that particular thing right all the time I guess. But trying to keep my gun [[HOT]] when it's hot and aim it 1 tick before it gets cold doesn't work for me. It dramatically lowers the guns performance. I must be doing it the wrong way I guess... [[User:ABC|ABC]], think you can describe in more detail the things you do around this and in what order and such? -- [[User:PEZ|PEZ]]

Sure:
<pre>
if (bot.getGunHeat() > bot.getGunCoolingRate() {
aiming = false;
bot.setTurnGunRight(BotUtils.normalizeBearing(HOTAngle - bot.getGunHeading()));
}
else {
if (aiming && bot.getGunTurnRemaining() == 0) {
b = bot.setFireBullet(bulletPower);
aiming = false;
}
else {
fireAngle = getFireAngle(enemies.target);
bot.setTurnGunRight(BotUtils.normalizeBearing(fireAngle - bot.getGunHeading()));
aiming = true;
}
}
</pre>
I simplified it for clarity. I also have a check to see if the enemy is disabled, I shoot .1 HOT in that case.

-- [[User:ABC|ABC]]

This is about what I tried... Strange. I'll try a carbon copy of your solution and see if it works then. -- [[User:PEZ|PEZ]]

Simpler:
<pre>
if(getGunHeat() / getGunCoolingRate() < 4){ //turns left until we can fire
goodAim();
} else {
headOnAim();
}
</pre>
--[[User:David Alves|David Alves]]

And that's what I had tried before this discussion. =) But your simpler solution doesn't show where you fire so it could still be different from my attempts. -- [[User:PEZ|PEZ]]

Just add this after the code I gave:
<pre>
if(getGunHeat()==0.0){
setFire(bulletPower);
}
</pre>

--[[User:David Alves|David Alves]]

The problem is that, since firing is the first thing the Robocode engine does, you'll be firing with a prediction 1 tick old. Also, you'll make 3 redundant predictions, and with a slow PM gun that will have a big impact in your bot's speed. -- [[User:ABC|ABC]]

With your code you could be firing with data more than just one tick old... It might take more than one tick for the gun to turn from HOT to the angle you want. But you're right about my solution not being practical for slow guns. Thanks for being nice to us and aiming your slow gun as infrequently as possible. :-) --[[User:David Alves|David Alves]]

*And with your code you could be firing with a completely different angle than you intended, it might take more than one tick for the gun to turn from the angle you predicted in the last tick to the current one... -- [[User:ABC|ABC]]

But yous solution, David, doesn't solve any problem really, does it? What's the difference between your suggestion and just:
<pre>
goodAim();
setFire(bulletPower);
</pre>
? -- [[User:PEZ|PEZ]]

I tried ABC's firing scheme described above with both a PM-gun and a GF-gun. Results against a 'real-life' bot (Ascendant 0.8.5) decreased with 10% in both cases. These results are also reflected by the lower rankings of Fenrir and MiniWodan in the RoboRumble. 
The results of the modified PM-gun against PatternBot increased with about the same amount (7%). I had expected this improvement with the PM-gun, as PM implies that the behaviour is deterministic and that you can 'predict' the next t movements of your opponent. Thus aiming your gun at time t-1 and firing the gun at time t should improve results. But this appearantly does not hold (for my gun) with 'real-life' opponents. Dou you have any ideas why? 
With a GF-gun you use a statistic approach. As i fire virtual waves every tick (therefore also when i do fire a real bullet) and provide the (virtual) wave with the angle towards the opponent at 'firing' time, i think this aiming at t-1 is not necessary as you fire in an optimal direction for your statistics which are biased because of the way they are build up. In other words, these statistics 'correct' themselves for the misalignment. Does this make any sense? --[[User:Loki|Loki]]

My statistics are collected in an ideal space. Which means there's no auto-correction to hope for from there. I too tested ABC's scheme. It resulted in a .4 point decrease in TC500 score. Could be within the margin of error of course. But at least I didn't keep it. My own scheme of every tick doing:
<pre>
goodAim();
setFire(bulletPower);
</pre>
is simpler and seems to work at least equally well, if not better. I guess it's time for ABC to question this assumption of his and see if he can get rid of that piece of complexity in his code.

-- [[User:PEZ|PEZ]]

I could never use a setup like that, not without becoming a true SlowBot. The significant result from Loki's tests is, for me, the increased hit rate against PatternBot, that is the best indicator of precision. Ascendant is a dodger, many time a slightly buggy gun can hit wavesurfers better than a bug-free implementation of the same gun. I agree that GF guns can compensate for the misalignement because of their statistical nature. -- [[User:ABC|ABC]]

Well, i would never suggest that you don't wait for the last tick before you compute. And I agree that it isn't wise testing a gun against a surfer unless it's an anti-surfer gun. But my results where from the TC. It's worth testing I would say. -- [[User:PEZ|PEZ]]

Sure, TC500 results are always a good test. But a .4 decrease is not significant. There are a lot of good random movers in the TC, a classic PM gun will always be inferior to a statistical gun there. Loki, did you try the modified GF gun against PatternBot? -- [[User:ABC|ABC]]
* no, not yet. I will try running this tonight. --[[User:Loki|Loki]]
* the results of the modified GF-gun are between 4 and 5% down (i ran both 5*100 rounds and averaged the results and 1*2000 rounds). Maybe the modified gun shoots less often. I will verify this by adding a counter and run this test again. --[[User:Loki|Loki]]

What I say is that if that extra code doesn't bring home more RR points or any other points then it's redundant. The .4 decrease is not significant, I know. A classic PM gun is inferior everywhere except in the PatternMatchingChallenge. LeachPMC is pixel perfect there but is useless in the RR@H. -- [[User:PEZ|PEZ]]

<blockquote>
In response to:
"But yous solution, David, doesn't solve any problem really, does it? What's the difference between your suggestion and just:
<pre>
goodAim();
setFire(bulletPower);
</pre>
?" -- [[User:PEZ|PEZ]]
</blockquote>
The reason that I have setFire separate is that I have other code that needs to run only when I fire a real bullet. If you don't have any code that needs to run when you fire a real bullet you could put setFire() inside the if(timeToFire < 4) block. --[[User:David Alves|David Alves]]

----

This page hasn't been updated in a long time... Based on a lot of these comments, I went a long time without waiting for my gun to be aligned before firing, thinking that others had found it to not really be worth the decreased firing rate. But I felt it was only right to mention here that my TC scores went up significantly ''and'' [[Dookious]] gained 5 points in the RoboRumble from waiting for the gun to be aligned. I'd definitely recommend at least trying it for yourself if you aren't doing this with your gun. -- [[User:Voidious|Voidious]]

It has long been Ugluk's policy to only fire when the gun is aimed at the previous round's firing solution or the target is close enough that it doesn't matter (in which case the shot is also full power). When I tried ensuring that the enemy still had the same speed and rate of heading change as the firing solution's data, it meant anyone throwing a slight randomness to the speed or heading would prevent Ugluk from firing at all, so I nixed it. -- Martin

I think it is important to control when you fire. Don't stop firing altogether when you are doing badly, just do it less often or with lower bulletpower. [[Uba]] reduces its firing rate if it is missing a lot, and it improved its battles a lot when I first implemented this. --[[Bayen]]

[[Category:Archived Talk]]

When To Fire/Archived Talk 20071205

2009-10-08T03:52:43Z

Robobot: moved When To Fire/Archived Talk 20071205 to Archived talk:When To Fire 20071205: move to talkarchive

#REDIRECT [[Archived talk:When To Fire 20071205]]

Archived talk:WeeksOnEnd 20090522

2009-10-08T03:52:41Z

Robobot: moved WeeksOnEnd/Archived Talk 20090522 to Archived talk:WeeksOnEnd 20090522: move to talkarchive

{{Navbox small
| title = WeeksOnEnd Sub-pages
| parent = WeeksOnEnd
| page1 = Version History
| page2 = Archived Talk 20090522
}}
{{Talkarchive|Talk:WeeksOnEnd}}

A new 1v1 MiniBot by [[User:Simonton|Simonton]] that was his ticket to [[The2000Club/Mini]]. Come on, share all your secrets with us! -- [[User:Voidious|Voidious]]

Oh, no, well, I mean, I couldn't. I'm just too shy. Ok, well, you talked me into it :).

----

Well, I now have 39 free bytes on this beast. Any ideas? It's not enough for what I really wanted to try, so who knows what would get me a few more points? A segment to wave surfing other than lateral velocity? A segment to the pattern matcher? I've been thinking of taking up a few bytes for a little different firepower choice. Whaddya think? -- [[User:Simonton|Simonton]]

Hey, how about some nify colors! :P --[[User:Chase-san|Chase-san]]

Can't there be something more productive? Oh, and, make that 44 bytes. -- [[User:Simonton|Simonton]]

I'd say segment on distance in the surfing, I segment on LateralVelocity and distance. I segmented on wall distance for a while, too, but it actually gained rating points (and saved bytes) to remove it. A little bullet power management is worth a few points, too, though I haven't managed to tweak more points out of it beyond my initial code for it. Not sure how you manage your distancing, but with [[Komarious]] I've found it pays big (like way more than I'd first think, intuitively) to move away from the enemy at all times. I've basically got 20 bytes free in [[Komarious]] if I remove the colors, but I just can't find anything worth using them for... -- [[User:Voidious|Voidious]]

I tried removing the distance segment in my surfing and it cost me a few points. Now you try adding a distance segment =) -- [[User:Voidious|Voidious]]

Ha! Easy for you to say. [[Komarious]] runs 1000 battles in just like a few hours. It takes me over 2 days! I know, I know. It's my own fault. -- [[User:Simonton|Simonton]]

I would say to improve on which ever one you think is more important: MovementOrTargeting --[[User:Starrynte|Starrynte]]

Yes, that would be the task :). I'm not really so concerned which I improve, as much as how to improve it! I was more hopeful for version 1.4. :( -- [[User:Simonton|Simonton]]

Ok, ok. So I didn't try putting in a distance segment yet. But start to think bigger, because I was de-codesize-ing, and now I have 117 bytes to play with. So, any great ideas with that in mind? -- [[User:Simonton|Simonton]]

You could try something like adding anti-PM stuff to your movement (Not sure how to do that myself), the MusashiTrick, or maybe more segments to your surfing? --[[User:Nfwu|Nfwu]]

Funny you should mention it ... I was experimenting with anti-PM just last night. Haven't decided if it's going to help yet. Or if I can squeeze down my computation time enough to make it fit every turn. I'm nervous about adding segments to surfing, though ... I want to keep it agile & adaptable ... Oh, and the MusashiTrick just happened to be built into the wave surfing. --[[User:Simonton|Simonton]]

A score of 2110.03 in the mini at 101 battles, Wow lets see if it stays! --[[User:Chase-san|Chase-san]]

I never trust ratings until the tank has faced every other bot - WeeksOnEnd 1.8 is actually behind 1.7 in a by-bot comparison. (I check the [http://rumble.fervir.com/rumble/RatingDetailsComparison?game=minirumble&name1=simonton.mini.WeeksOnEnd%201.8&name2=simonton.mini.WeeksOnEnd%201.7 Comparison page], paste it into Excel, and sum the diffs.) That's only ~90 pairings and not many battles, though, so we still need to wait and see. ;) -- [[User:Voidious|Voidious]]

Still impressive. --[[User:Chase-san|Chase-san]]

Thank you for the optimism, Chase. Voidious, we'll see if this race needs to continue soon enough. I just got done working on the rumble client. It now can run a focused competitor, so I'm going to set it to work on my home machine and go to bed. (Until now I was only running it on my machine at work. 2 is better than 1.) Sometime tomorrow you'll see a big jump in the battles fought for WeeksOnEnd, then we should have our answer. :) Good night. -- [[User:Simonton|Simonton]]

Well, my money's on you to win this race ;), and WeeksOnEnd itself is absolutely "impressive". I was just saying that an interim rating isn't really that meaningful - as of now, 1.7 is your most impressive release, IMO. If 1.7 had only the same pairings as 1.8 has right now, it would have a higher rating than 1.8 does now. -- [[User:Voidious|Voidious]]

I just realized something about WeeksOnEnd in the RoboRumble, though I'm not sure of any reasonable "solution" to it. By running all your battles on a single client, you may be at a disadvantage. Any bot that saves data does better if it runs multiple battles from the same client vs a given bot; since your bot doesn't save data (right?), it gets no advantage from multiple battles on the same client, but bots that save data are getting an extra advantage against it. For other bots (like Komarious), their battles are distributed across multiple clients, so the odds are less that any bot will get 2 battles against it on the same client.

Like I said, I'm not really sure how you can deal with this fairly - if you deleted your opponents' save data before each match, that would be kinda cheap, but they are definitely getting the most of their saved data in your current RR@Home client setup. There aren't nearly as many MiniBots that save data, luckily, so at least most of the effect is probably in the General rumble. But I just wanted to share the thought with ya.

-- [[User:Voidious|Voidious]]

On the other hand, if [[WeeksOnEnd]] is a relatively slow bot, it may be at an advantage to do all its battles on a client that probably has an increased cpu constant, where if it were distributed, some clients might let it skip more turns :-) In either case, maybe those 50 bytes can find a way to make [[WeeksOnEnd]]'s memory problems improve. -- [[User:Kawigi|Kawigi]]

Voidious: that is true. I never thought of that. Well - I should pay some price for bending the rules so much! :) Kawigi: unfortunetely it would take a lot more than 50 bytes to fix that. :(. Maybe when LifelongObsession comes out .... :/ -- [[User:Simonton|Simonton]]

Hey man, do you have your client reporting some results only for the mini rumble? I noticed that WeeksOnEnd 1.9 has far more battles in the mini rumble than in the general rumble, which seems theoretically impossible... Any idea what's up with that? -- [[User:Voidious|Voidious]]

Wow - that does seem theoretically impossible. I didn't notice that? I'll have to look at the mods I made to my client to run focused competitors offline. But what would cause the battles to be counted in the mini rumble but not in the general rumble? Must be because I replaced the "RUNONLY" property with the substring to match for focused competitors?? (In this case, "Week"). Can someone tell me? I wonder if any of the results I've been seeing in the mini/micro rumble are affected by this (for WeeklongObsession, too)? -- [[User:Simonton|Simonton]]

Codewise, I'm not sure exactly how it's possible, but I know that it uploads a result once for each rumble it's supposed to be in. If it's not uploading 2 results for each WeeksOnEnd battle (like "Uloading WeeksOnEnd vs soandso..."), it's only uploading them to 1 rumble. Not really that big a deal, but something to investigate for sure. -- [[User:Voidious|Voidious]]

----

Suggestion: if you add this to [[WeeksOnEnd]], does it stop "leaking"?

<pre>
public void onWin(WinEvent e){onEnd();}
public void onDeath(DeathEvent e){onEnd();}
public void onEnd()
{
if (getRoundNum() == getNumRounds()-1)
patterns = null;
}
</pre>

It seems to work for me. I ran a series of 100-round battles with [[Shiz]] (just because I know it uses almost no memory that it might leak itself), and it seems to not allow the memory usage to blow up. If you have 20 or so bytes to spare, perhaps using it for this might be worthwhile :-) (still, if it's a bug in Robocode, we should also investigate that). -- [[User:Kawigi|Kawigi]]

Wow, that's very interesting. I'll try it. But if that is the case, it should most definitly be considered a bug. But then, why wouldn't it have come up with any other other bots? Has no one else really ever developed a memory hog? I do have 20 bytes to spare, I *think*, but it would be at the expense of some execution speed-up code, and I think it would skip some turns. At any rate, WeeklongObsession *definitely* does not have 20 bytes to spare. I'm trying to find one byte to squeeze out of it anywhere so I can release the next version. -- [[User:Simonton|Simonton]]

Handling onBulletHitBullet made a big difference? I do it in Dookious, of course, but I find it really hard to believe it makes that much of a difference. I will look into it now, though. :) -- [[User:Voidious|Voidious]]

<nowiki>:)</nowiki> -- [[User:Simonton|Simonton]]

Sure enough, Kawigi, that completely takes care of the problem. Somewhere in robocode it is not setting something to null, then, apparently. It would be '''awesome''' if that got fixed and I could let you all run battles for me ;). But then, I guess it would take time for any new version to work its way into rumble clients ... -- [[User:Simonton|Simonton]]

[[Fnl]] has been very responsive about updating Robocode, so I bet he can figure it out. Maybe you should summarize the issue on the Robocode page so that he definitely is aware of it. My rumble clients iterate every 10 battles, so they check for new bots and download them every few minutes... Your bots would definitely process faster if we were all running them. Seems like I see 3-4 people total processing battles whenever I check that [http://thekandieman.com/nfwu/rr-uploads.php uploaders script] recently, and sometimes I'm running more than one client. -- [[User:Voidious|Voidious]]

I will do that. But even if FNL updates robocode, it wouldn't work unless everyone running the client updated. One person running an old version would out-of-memory and my score would suffer drastically. -- [[User:Simonton|Simonton]]

It is possible to let Robocode clean up the memory used by robots. But it is tricky. As far as I remember, the robot instances (objects) are created and destroyed for each battle. This way all memory used by a robot should automatically be cleaned up. But if a robot uses one or more static member fields, then this is a problem. The static variables are not set to null automatically it Java, and Robocode does not do this with a very good reason. Many robots uses static variables to maintain a structure or the alike from battle to battle. If I explicitly set the static member variables to null on all robots after each battle, then these structures will be lost, and Robocode would break compability with legacy robots. I you guys have a nice solution for it, when I will gladly implement it. :-) --[[Fnl]]

Ok, I need to learn the proper terminology. The issues isn't beteen each battle, then, but between each ... uh ... match? You know, like WeeksOnEnd could fight another robot, then 2 completely other bots could fight, then if WeeksOnEnd gets fight again, I'll have memory issues. -- [[User:Simonton|Simonton]]

I think the 'accepted' terms are: fighting until one bot is left over = round. A normal RR@Home battle consists of 35 rounds. For several challenges a battle consists of 500 rounds. The static member fields [[Fnl]] is mentioning are (should) only be used within one battle. If someone needs to keep things between battles, (s)he must write it to file. If someone wants to keep things between rounds (and every wavesurfer, GF-gun and PM-gun needs that), the data can be put in static variables. -- [[User:GrubbmGait|GrubbmGait]]

You could just clean up the thread after the battle is over (e.g. after all the rounds have run), that would remove the data used by the static variables, and it might be able to be done without massive rewiring, let me take a look through the cvs. --[[User:Chase-san|Chase-san]]

Okay, looking through the CVS, I stumbled upon this in the robocode.battle.Battle.java. On line 218, is the line while (!abortBattles && roundNum < numRounds), thus it runds this while the rounds are avialable. I traced through to the RobotThreadManager, which ahs a cleanup() method, which is alled if you are not to replay, in this method you could remove all the static data that the bot used. Thus no major rewiring required. ;) --[[User:Chase-san|Chase-san]]

[[Fnl]] - More fundamentally, the static variables in a robot should be released when the classloader the robot was loaded in is disposed, and the suspicion here is that something (either the robot's classloader or the robot's thread) is still hanging on to something it should be able to release. It may be getting held by something within Robocode, but if it's the thread that's just stopping but not being disposed, they might hold references to objects loaded by that classloader, and that means static members in that class loader stick around. These static members already can't be accessed by future instances of the robot (in different battles), because those robots will be loaded in new classloaders (so we're not talking about breaking any existing bots). -- [[User:Kawigi|Kawigi]]

Okay. So we all agree that Robocode should clean the static variables for a robot (peer) when a battle (not round!!) is ended (or started ;-). That should be too hard to implement. I have no problem figuring out how to do this. I just wanted your oppinions upon if Robocode should be allowed to clean the static variables, as Robocode has never done this previously. Hence, if some robots keeps data from round to round, and battle to battle, then I might break the compability of keeping data from battle to battle. But hey, they should "save" the data! ;-) --[[Fnl]]

I have made a fix where all the static fields on a robot that are not final or primitive are set to null so that the garbage collector is called on these fields. I have made an alpha version that can be downloaded [http://robocode.sourceforge.net/files/robocode-setup-1.2.5-Alpha.jar here]. I should like you to tryout this version to see if the problem disappears? --[[Fnl]]

Yes! That worked perfectly. I'll just have to remember not to set big data structures to final. That shouldn't be hard. So ... but that still seems strange. Is the class loader being held onto, like Kawigi mentioned? -- [[User:Simonton|Simonton]]
* Cool! I will then add it to the real 1.2.5 release (of course also the Beta). Robocode has it's own class loader for loading robots. I have full control over this. I don't use the class loader for the fix. I just clean the declared fields on the robots that are static and that are not primitives or final using trivial Java reflection, and this is done when the cleanup() method is called. --[[Fnl]]

I guess everyone has to update thier clients, that is considering that if 1.2.5 doesn't have any major bugs implimentation wise (this might actually might increase the preformance, but you know what I mean). --[[User:Chase-san|Chase-san]]
* Yes, unfortunately. I will try to minimize the risk of introducing new bugs. I had to change the robot states etc. for Robocode in order to support Replay. This introduced a few bugs, but also simplified the internal code for Robocode regarding states! ;-) --[[Fnl]]

Uhh ... everone running an alpha version for their clients doesn't sound like such a hot idea. Maybe it's best to wait at least a little while ... -- [[User:Simonton|Simonton]]
* Hehe.. yes, I am sure that Chase-san was meaning the real 1.2.5 version. :-) --[[Fnl]]

By the way, is 1.10.3c equivalent to your best version of WeeksOnEnd? Also, does it use the Rules class? -- [[User:Voidious|Voidious]]
* Um ... not real sure actually! I'm thinking yes and yes. It should actually be named 1.10.2c; I just got the numbering messed up. I know it has some unneeded memory management (now that the static variables are being cleaned up). Looks like my entries in [[The2000Club]] and [[The2100Club/Mini]] should be revoked. Must have been the version of Robocode I was using for my clients inflating the score back then. -- [[User:Simonton|Simonton]]
** Leaving you with only the measley title of MiniBot Champion, eh? =) I guess the time has come for me to use the Rules class and implement <nowiki>onBulletHitBullet</nowiki> in [[Komarious]]. I wish we could officially "require" a current client for the RoboRumble once we conclude the new versions are stable, because I really hate the Rules incompatibility and memory leak issues. Maybe after the RoboWikiRenovation we can update the RoboRumble code that way. -- [[User:Voidious|Voidious]]
** I would second that motion. Has there been any talk of when the renovation may actually happen? -- [[User:Simonton|Simonton]]

Any idea how much memory WeeksOnEnd uses? I keep getting OutOfMemoryErrors when my RRAH clients run it with the default of 256MB. I've set them to 1024 for now, hopefully that will solve the problem. --[[User:David Alves|David Alves]]
* Ooo, really? Ouch. I thought I had tweaked it to take only its fair share of 256M. Hmm ... let me run a test. Oh, ouch. 2 WeeksOnEnd in a 35 round battle brought memory usage to 378M. That's more than 256. Hmm ... I must have been planning on people running the rumble at 512M. Has the default always been 256? -- [[User:Simonton|Simonton]]
* I thought the default had changed from 256 to 512 a while back, but I see that it is 256 in 1.4.5's roborumble.sh and 512 in robocode.sh. (I always run with 512, for whatever that's worth.) -- [[User:Voidious|Voidious]]

* Yeah, same for the batch files. It's 512 in robocode.bat but only 256 in roborumble.bat --[[User:David Alves|David Alves]]

----

Congrats. =) -- [[User:Voidious|Voidious]]
* I have confidence that you can answer, should you choose. That race to 2100 still appears to be open ... -- [[User:Simonton|Simonton]]
* Any idea what happened? WeeksOnEnd 1.10.4 has dropped to 2081 in the mini rumble. -- [[User:Voidious|Voidious]]
* Nope, no idea. I'm just about to leave work ... though I don't even know how I might check it out once I get home. -- [[User:Simonton|Simonton]]

I see anti-PM was mentioned above, but does the latest WeeksOnEnd in the rumble use it? Because.... by adding a PM of a similar conceptual breed as WeeksOnEnd (Single-tick, match of acceleration and turning), my rumble score against WeeksOnEnd went down from about 74 to about 49 despite some good success such as my score against [[Chalk]] going up 11 points, up 6 against [[Phoenix]], and while there are a few drop, none as massive as the one against WeeksOnEnd. So... it is anti-PM I smell here or not? :) -- [[User:Rednaxela|Rednaxela]]

Nope, there's no room in a mini =) I notice that my score fluctuates a lot against WeeksOnEnd though, from 60s to high 40s. IIRC LifelongObsession has Anti-[[Che]] movement. -- [[User:Skilgannon|Skilgannon]]

Well, I would argue that it could be done in a mini, but it makes sense that this is just fluctuations. Just to check though, do you mean fluctuations between particular runs, or more fluctuations between versions of your bot? -- [[User:Rednaxela|Rednaxela]]

Against different versions of several of my bots, [[Toorkild]] 0.1 beat WeeksOnEnd but 0.1.1 loses, versions of DrussGT where almost nothing has changed go from losing @ 45% to winning @ 60%, that kind of thing. -- [[User:Skilgannon|Skilgannon]]

Hmm, interesting... i wonder what makes scores against WeeksOnEnd so finicky... -- [[User:Rednaxela|Rednaxela]]

WeeksOnEnd/Archived Talk 20090522

2009-10-08T03:52:41Z

Robobot: moved WeeksOnEnd/Archived Talk 20090522 to Archived talk:WeeksOnEnd 20090522: move to talkarchive

#REDIRECT [[Archived talk:WeeksOnEnd 20090522]]

Archived talk:WeeklongObsession 20071128

2009-10-08T03:52:36Z

Robobot: moved WeeklongObsession/Archived Talk 20071128 to Archived talk:WeeklongObsession 20071128: move to talkarchive

{{Navbox small
| title = WeeklongObsession Sub-pages
| parent = WeeklongObsession
| page1 = MC2K7
| page2 = Version History
| page3 = Archived Talk 20071128
}}
{{Talkarchive|Talk:WeeklongObsession}}

Why you didn't place the link to this bot in Participants List? Give us the link!!!... in Participants List -- [[DemetriX]]

Because I'm running it on a modified client. Calm down, I'm not padding my score :). My bot generates TONS of strings to perform its duties, and Java's String class keeps a HashMap of every unique String it has ever seen. So, after a couple matches, Java's HashMap becomes so large it runs the JVM out of memory. My client re-starts after every time it runs a match with WeeklongObsession in its name, so that there is a fresh JVM with a fresh, small HashMap. -- [[Simonton]]

By the way, great job with WeeklongObsession, you really rocketed to the top of the MicroBot and MiniBot tables with this little guy. =) -- [[Voidious]]

Thank you, sir :). -- [[Simonton]]

There is another disadvantage in running your bots exclusive in your client: If your client is not running, new (versions of) bots will not fight yours, so the PL-ranking is not complete for those and your bots. -- [[GrubbmGait]]

Yes, you are right. The plug got pulled on my client at work, and I only have dial-up at home. That's why it hasn't been running. I can try to fire it up again at home running offline - it should battle the new bots eventually. This is really turning into a pain. When is that bugfix for robocode going to make it into people's clients again? ... -- [[Simonton]]

I know an 'official' version is in the pipeline, so I am not complaining about that. It is just for information that the PL-ranking is not complete. And I hate that I am still not better than the best mini . . . -- [[GrubbmGait]]

Very strange.... WeeklongObsession is in the MicroRumble but not in the RoboRumble....maybe that tweaked client of yours is up to no good? -- [[Skilgannon]]
* That's the way it should be. The tweaked client is only running battles for the micro rumble, so I can get results a lot faster. The rumble is set up to only show the scores for the micro rumble if that's all you're running, since you wouldn't want to see WeeklongObsession's micro score as his general rumble score, too! (That would be a little inflated). -- [[Simonton]]
* Well, the RoboRumble scores would be calculated using the relative ratings in the RoboRumble instead of the MicroRumble, so they wouldn't necessarily be inflated. But they would be inflated or deflated depending on whether your bot was better or worse against MicroBots relative to MegaBots - or something. Anyway, we should be past this issue soon, that will be nice... -- [[Voidious]]
* Ah, RELATIVE ratings, right. --[[Simonton]]

Since I can't download WeeklongObsession to see this new movement of yours, do you mind sharing? It seemed to push your score up a few points. -- [[Skilgannon]]
* With the latest upload of results it does not seem to gain me any points, but I think it has potential. I'm thinking the StopNGo needs some work under the new system. Unfortunetly it takes a lot of codesize, so I'm not sure it's worth it. Anyway, the basic idea is to weight whether you flip orbit directions toward the line between the enemy and the center of the field. This has the general effect of moving you into a portion of the field where you can put more space between yourself and your enemy. -- [[Simonton]]

Those memory errors are odd, very odd. I'm not sure you are correct in saying the JVM keeps track of all strings it has seen, it wouldn't make since, but it easily tested ... let me check real quick *codes up a test program concat'ing Math.random(), sets heap size to 1meg* ... yeah, its not, didn't think so, that or my test program is borked, which is possible. But I think its some other issue. I might check into it. -- [[Ntroutman]] 2007-08-28
* Sorry, those are old comments. You are right, it is not because of the String class. It was because Robocode did not release the classloader for robots from previous battles. [[Fnl]] took care of the problem by running through all the static variables of each robot class and setting them to null (via reflection, I think). So as long as I don't set those variables to final, there is no problem with the latest versions of Robocode. -- [[Simonton]]
* Okay, I'm glad to hear that the problem is non-existent now. [[Ntroutman]] 2007-08-29

You could probably shed those bytes by taking the getGunTurn(<lots of args here>) and inlining it. And WeeklongObsession is seriously slow! Have you considered dividing the matchlength by 2 every time instead of subtracting 1? You could probably take out the match-only-when-gun-is-cold then, which would save you those bytes. -- [[Skilgannon]]
* The algorithm for matching is going to be a lot different in the next version. The getGunTurn was necessary because of the randomly placed return statements .... but actually it saves codesize :). -- [[Simonton]]
*Hmm... have you tried making all those variable non-private? I seem to remember something about modifiers increasing your codesize. -- [[Skilgannon]]
* "Private" does not change CodeSize. The "static" modifier will decrease your codesize. "static final" will decrease it even more, at least for primitives. The codesize doesn't come from declaring variables, it comes from using them - and "private" only dictates ''where'' you can use it. -- [[Simonton]]

Now that you're releasing into the general rumble, maybe you could mod your client to also upload results to all the other rumbles? I'll be getting priority battles for WeeklongObsession even after it has 2000 battles in the MicroRumble, because your client isn't uploading them to all the other rumbles. Thanks. -- [[Skilgannon]]
* Well, I'm really more interested in seeing micro results faster. I don't care much about the rest. So ... I could stop release to the general rumble again ... unless somebody else has a better idea. -- [[Simonton]]
* General rumble release is fine. I'm just wondering if you could somehow also upload your microrumble battles to the mini and general rumbles as well, so that the number of battles increases there, and it doesn't get priority battles even after it has 2000 in the micro. Whichever. ;-) -- [[Skilgannon]]
* Oh, well that's not my design. It's part of Roborumble that: if you're only running against micros, it only gets uploaded to micros. I've always been curious exactly how scoring works in the rumble, though. Does anyone know if it would affect the score to have a dis-proportionate # of battles from the micro league? -- [[Simonton]]
** Having 1 battle or 50 battles against a particular bot doesn't matter, it only makes the score against that bot more accurate. In Melee, it ''does'' affect things, because if your bot performs better / worse against MegaBots, it will also affect your score against MicroBots in those battles (since you're always fighting 9 bots at a time). In 1v1 it should make no difference at all how many times you fight the MicroBots (as long as you do face everyone in the end). -- [[Voidious]]
** Ok, sweet. It's been done. Starting now with [[GFMicro]] the results will be uploaded to all possible leagues.

I just thought up a reason that using latvel/advvel in your gun isn't as good as using 'absolute' matching: by using latVel you are assuming that you were staying still last time, when you took the recordings, because you are reconstructing a GF, which should assume that the wave center stays still. But because the center of the 'wave' you are recording from moves, you get inaccurate results. My explanation is kind of lacking, but basically it all boils down to latvel/advvel not being as accurate for reconstructing enemy movements. But only if you are moving, which is why the PMResearch didn't show any problems with it =) -- [[Skilgannon]]
* Changing from absolute to adv/lat velocity cost me 0 points and saved me 50 bytes with this bot. The rumble says it's about the same either way, at least at the micro level. But you are right, adv/lat velocity has a margin of error because you are moving. It apparently doesn't matter in the end though. I guess I should say that I tried it both ways in the rumble using single-tick matching, but not the standard style. -- [[Simonton]]

WeeklongObsession/Archived Talk 20071128

2009-10-08T03:52:36Z

Robobot: moved WeeklongObsession/Archived Talk 20071128 to Archived talk:WeeklongObsession 20071128: move to talkarchive

#REDIRECT [[Archived talk:WeeklongObsession 20071128]]

Waves/Archived Talk 20071130

2009-10-08T03:52:34Z

Robobot: moved Waves/Archived Talk 20071130 to Archived talk:Waves 20071130: move to talkarchive

#REDIRECT [[Archived talk:Waves 20071130]]

Archived talk:Waves 20071130

2009-10-08T03:52:34Z

Robobot: moved Waves/Archived Talk 20071130 to Archived talk:Waves 20071130: move to talkarchive

Since I have now realized I have been doing [[Wave]]s all the time for my bots I'll try to give an explanation. Think of Waves as something very like how the rings on the water extend from a stone you just dropped.

The followin graph shows what Wave's are. The green and red circles moves outwards from the bot firing the Wave: -- [[User:PEZ|PEZ]]

;[[Image:Waves small.png]]
A screenshot of Fractal drawing some waves using RobocodeGLV014. The green waves are its own bullets, and the red waves are the enemy bullets. When the green waves collide with the enemy, the angle difference between the center of the circle to the bullet and the center of the circle to the enemy is saved in the proper bin (see VirtualBullets), and the wave is removed. -- [[User:Vuen|Vuen]]

For an implementation, using Robocode custom events, check VirtualBullets/VirtualBulletsBot. -- [[User:PEZ|PEZ]]

See also EnemyWave. -- [[User:PEZ|PEZ]]
----
==== Original question / discussion section ====
[[Cigaret]] obviously uses [[Wave]] [[Targeting|aiming]]. Could someone with understanding about this explain what it is and how it is similar or different? -- [[User:PEZ|PEZ]]

You note the point of origin, and speed of the (virtual) bullet you're firing. You keep track of the travelled distance of the bullet, and when that distance exceeds or equals the distance between your enemy and your bullet's origin, you can calculate back what angle your gun should have had to hit your enemy. This should give the same results as if you're firing an infinite number of (virtual) bullets in every direction. 
I believe Iiley's bots are open source. Otherwise, HummingBird's Probe class should be similar (HummingBird doesn't use it for patternmatching, though). --[[User:Dummy|Dummy]]

Yes, the source is included in the jar. But I wanted it more in prose. Like your answer here. =) Marshmallow does this to feed one of it's guns. Though no pattern matching with it. What do you mean by that? -- [[User:PEZ|PEZ]]

If I remember correctly, Cigaret and BlackSwans uses his Waves in combination with patternmatching.... so that's why I made that comment ;-). -- [[User:Dummy|Dummy]]

Some of my pattern matchers do that but in the contrary way: first match a set of N patterns, then calculate the gun bearing that would hit in a similar way to the one explained by Dummy, then pick-up the most probable. -- [[User:Albert|Albert]]

Wave is similar to Dummy's Probe,it just contains some Pattern element(property) in it to do Pattern Analyse. -- [[User:Iiley|iiley]]

What kind of principle does Wave work on? Would you be willing to explain it? -- [[User:Kawigi|Kawigi]]

I will explain it...hope i can explain it clearly with my poor English.;] -- [[User:Iiley|iiley]]

If you have it explained on your webpage somewhere, or something, I may be able to get my friend or one of my brothers-in-law to try and translate it for you, too. Just post a link I guess. -- [[User:Kawigi|Kawigi]]

Does your friend can speak Chinese? however i'll have a try to explain it in English.;] -- [[User:Iiley|iiley]]

My friend lived in Taiwan for two years, and his wife is Taiwanese. Three of my Brothers in law (2 of which are Chinese-American) also spent 1 1/2 to 2 years living in Taiwan. I have one sister-in-law who is Taiwanese, and my mother-in-law is from Hong-Kong, and my Father-in-law will be living there with her for a few years soon. In other words, I'd say I have a few close acquaintances who speak Chinese. It just never occured to me to ask them until recently... -- [[User:Kawigi|Kawigi]]

haha~~however,i wroted it in english,hope you can read it ;]

In A pattern matching gun,when you find the pattern in history witch is the most similar to current one,then you must calculate where it will go with the patterns in history(you can read some open source code with this pattern matching way,eg:cx.micro.Spark).but to shoot a enemy,i only need the shoot bearing,so why not record the shoot bearing in patterns,when i find the best pattern,i read the shoot bearing,then aim to this bearing to shoot.this is what wave does:
assume a time(in fact every time if i can),I can fire a bullet,but I donot know which bearing will be right(be right to hit enemy),so I fire a wave,this wave's center position is my position when it be fired,the wave increase its radius V pixels tick by tick(V=the Bullet's velocity,can be 11 to 19.7),you can imagine that however the enemy move,one time in future the wave can hit him(because bot's velocity<=8 and bullet's velocity<=19.7,hitarea is 36,19.7+8=27.7<36).When it hit the enemy,i record the bearing from enemy to the wave's center,So i know at that time,if i need fire,i should fire this bearing.
When i find a best pattern matched node,i will get the wave fired at that time to do my shoot.
and... of course wave node include pattern element to do pattern analyse too.
-- [[User:Iiley|iiley]]

Thanks for the explanation, I have long wondered how it works. It sounds a bit like [[Orca]]'s gun even though Orca uses a NeuralNetwork for the pattern analysis. What data do you use for pattern matching? -- [[User:PEZ|PEZ]]

1 : enemy_velocity*Math.sin(enemy_heading-enemy_absBearing)

2 : enemy_distance_to_filedcenter

3 : enemy_distance_to_me

-- [[User:Iiley|iiley]]

----

;[[Image:Waves small.png]]

A screenshot of Fractal drawing some waves using RobocodeGLV014. The green waves are its own bullets, and the red waves are the enemy bullets. When the green waves collide with the enemy, the angle difference between the center of the circle to the bullet and the center of the circle to the enemy is saved in the proper bin (see VirtualBullets), and the wave is removed. -- [[User:Vuen|Vuen]]

[[Image:Statwaves.jpg]]

And here's Statistician. I depend heavily on RobocodeGLV014 output for debugging. It is very very useful when doing crazy trigonometry. I am currently using RobocodeGLV014 to debug Tax's movement:

[[Image:Taxdebug.jpg]]

-- [[User:Nano|nano]]

Is that like a blind man's stick Tax is holding out? I've been experimenting some with using something like that for close-to-a-wall movement. But since I have never got RobocodeGLV014 to run on my machine I've never been sure I have got it right. -- [[User:PEZ|PEZ]]

----

GARR! This is really bugging me. I have a question about this type of gun. How do you 'decay' old bearing data? In other words, how do you make new VB hits / wave hits worth more than old hits? I've been working on and off the past week and all night now with several different decay types; i've tried linear decay, geometric decay, smoothed geometric, factored bin adding, and every possible way to teak all of the above and more... The problem is, I can't seem to find a single enemy where any kind of decay type is better than simply no decay. I've got a few more concepts using a round-based data decay algorithm factoring time spent at distances, but it seems complicated for nothing; microbots can pull this off better than I can. For anybody who uses this type of targeting, do you decay your bin data? If so how? -- [[User:Vuen|Vuen]]

I just use [[RollingAverage]], but lately I have not used any decay at all. As you have also noticed, it's not worth it against most enemies. Segmentation is much more important. -- [[User:PEZ|PEZ]]

I'm curious, what significant bots out there use non-decaying stats? My own released bots don't have any kind of decay (including FloodMini, FloodHT 0.8, Fhqwhgads and FhqwhgadsMicro). It seems like the goal in using such stats is to counter robots that either adapt movement (like GlowBlowAPM or the recent DT) or use several movement modes (like SpareParts or PrairieWolf). If you're trying to decide how to do decay, those are the sorts of robots to test against. That's the justification for not using all the stats. I plan on eventually implementing an adaptive bot, but until I do, decaying stats is not what's going to tip you over the edge against my bots. -- [[User:Kawigi|Kawigi]]

----
My EnemyWaves line up perfectly, but my normal waves don't. If I sit still, they work fine, but as soon as I move, it throws everything off (SittingDuck gets spikes at GF1 and GF-1). Any ideas? -- [[User:Tango|Tango]]

Maybe you are assigning a reference to your robots location to the wave? Then it will move as you move and all bets are off. Make sure you store a copy of your location at the time of fire in the wave. -- [[User:PEZ|PEZ]]

Bingo! It things like this that show my complete lack of java knowledge... Thanks. -- [[User:Tango|Tango]]

----

I'm doing some code refactoring and was hoping for some help in naming one of my classes. I'll have a VCSWave subclass of Wave, which stores a double array of VisitCountStats, but what should I call the one that store a list of exact GuessFactors (for log based targeting or surfing)? -- [[User:Simonton|Simonton]]

How about RawDataWave? -- [[User:Skilgannon|Skilgannon]]

[[Category:Archived Talk]]

Archived talk:WaveSerpent 20090520

2009-10-08T03:52:33Z

Robobot: moved WaveSerpent/Archived Talk 20090520 to Archived talk:WaveSerpent 20090520: move to talkarchive

{{Navbox small
| title = WaveSerpent Sub-pages
| parent = WaveSerpent
| page1 = Version History
| page2 = RRGC
| page3 = DookiSerpent
| page4 = Archived Talk 20090520
}}
{{Talkarchive|Talk:WaveSerpent}}

Although capable of high wave surfing challenge scores, I can't seem to get WaveSerpent to get a score greater than 30 against [[FloodHT]]. If anyone is brave enough to look through my extremely messy and unexplained code and give advice, I'd appreciate it. -- [[User:Kev|Kev]]

This might not be the whole reason, but without looking at your code much at all (just a glance, and then setting isMC == 1), I can tell you that your distancing is probably a huge culprit in the [[MovementChallenge]]s. Watch CassiusClay or [[Dookious]], or probably anyone getting high scores there, and you'll see that they all stay pretty far away, while WaveSerpent pretty much just keeps whatever distance it is at currently. Staying close has pros and cons in a real battle, but against a learning gun in an MC situation, it's just a huge disadvantage. I'd try that first before worrying much about it. -- [[User:Voidious|Voidious]]

Oh, and you really think it won't get much higher than [[Puzzle]]? [http://rumble.fervir.com/rumble/RatingDetailsComparison?game=roborumble&name1=kc.WaveSerpent%200.1&name2=kc.Puzzle%202.23 Comparison sheet] =) Also, how old was [[User:Alcatraz|Alcatraz]] when he hit 2K? -- [[User:Voidious|Voidious]]

I too think distancing is important, but for different reasons. Yes, of course against any non-trivial gun you'll get hit less if you stay away, but you'll hit less yourself too so there's no real reason in real battles to stay far away. However, trying to control you distance and make it so you fight most of the battles from the same distance is good for learning purposes. Especially for a WaveSurfer. Your targeting will benefit from it too against the majority of bots.

I haven't checked your code but I am still dead sure that what keeps your bot from really high ratings is '''bugs'''. It always is. Try the movement challenge and something like this:
# Use unsegmented surfing stats and go for perfection against HeadOnTargeting
# Then check your unsegmented score against LinearTargeting and see if you can segment your surfing stats to improve it
# Only ''then'' focus on the other guns in the challenge.

-- [[User:PEZ|PEZ]]

@Voidious - 17. @Kev - I found the bin smoothing function in RaikoMX very important. I think that's a great bot to look at. And graphical debugging was also great. Good luck with WaveSerpent. -- [[User:Alcatraz|Alcatraz]]

Well, I didn't mean to optimize your distancing for the challenges - obviously, how it performs in real battles is all that matters. But since you were looking for the reason you couldn't get high scores against [[FloodHT]], I'd say the distancing is probably a strong reason. Since you can probably count on your gun being stronger than the majority of RoboRumble opponents, you will likely benefit from staying a bit on the "far away" side in real battles, too. But what [[User:PEZ|PEZ]] says is true - it's all about the flawless implementation with WaveSurfing. It's a lot easier to get decent scores in the CurveFlatteningChallenge and such than it is to hold [[Barracuda]] to ~50 points every time, at least in my experience. -- [[User:Voidious|Voidious]]

Whatever the case, nice work with [[WaveSerpent]]! You shot right into the 1900 club, and halfway past it to 2K. -- [[User:Voidious|Voidious]]

Thanks for the advice all, I really appreciate it. The next version of WaveSerpent has simple distance control and replaces bins and bin smoothing with an interesting [[AntiGravity]] style approach. I'm getting 99+ scores vs. WaveSurfingChallengeBotA now. I still haven't found any bugs in the wave surfing code, but my previous direction finding algorithm was horrible and got WaveSerpent occasionally stuck in corners, most likely the culprit of low [[MovementChallenge2K6|MovementChallenge]] scores. -- [[User:Kev|Kev]]

Mad bullet-dodging skill :):

{| border="1" style="border-collapse: collapse; color: black"
|1st: kc.WaveSerpent
|4071
|1750
|350
|1643
|328
|0
|0
|35
|0
|0
|
|-
|2nd: rz.HawkOnFire 0.1
|14
|0
|0
|14
|0
|0
|0
|0
|35
|0
|
|}

{| border="1" style="border-collapse: collapse; color: black"
|1st: kc.WaveSerpent
|5285
|1750
|350
|2639
|496
|2
|47
|35
|0
|0
|
|-
|2nd: radnor.DoctorBob 1.42
|56
|0
|0
|56
|0
|0
|0
|0
|35
|0
|
|}

-- [[User:Kev|Kev]]

Still hasn't faced everyone, but... 2062!!! Friggin' awesome work dude. I think it'd be officially 5th, since CC 2pi.08 got 2067. Rock on, congrats! -- [[User:Voidious|Voidious]]

Giant jump, looks you are flying! Now you are really ''dominating'' one-on-one. And as a sidenote: you are pushing RaikoMX, who was 2nd when I started with Robocode, to rank 18! -- [[User:GrubbmGait|GrubbmGait]]

Thanks!!! And there was I thinking it might go up 15 points :). Having precise, bug free, and [[KISS]] wave surfing really makes a difference. I found a lot of inaccuracies in WaveSerpent's old movement (the most embarrassing being it segmenting movement data on the other robot's wall ahead instead of its own). -- [[User:Kev|Kev]]

Very nice! --[[User:David Alves|David Alves]]

When i run WaveSerpent against CopyCat (MirrorMovement) it suddenly sits still. Is it supposed to do that, or is it just because CopyCat doesn't fire when it has low energy (and so WaveSerpent doesn't have to move)? --[[User:Starrynte|Starrynte]]

WaveSerpent is not in the MeleeRumble... --[[User:Starrynte|Starrynte]]

That's right, [[WaveSerpent]] currently isn't in the melee rumble, and the latest version isn't melee compatible. However, [[Logic]] uses almost the same melee gun and movement as [[WaveSerpent]], so it acts pretty much the same. I'm not to sure what caused it to stop against CopyCat. [[WaveSerpent]] automatically stops against bots on the later rounds if it hasn't been hit yet (to avoid the other bot getting a score of zero, which don't count for the rumble). So if you put [[WaveSerpent]] in a one round match it will stop automatically. Besides that, I can't think of anything that would make it stop. When there are no waves to surf, [[WaveSerpent]] tries to get into a good position by moving away from walls and the other bot. -- [[User:Kev|Kev]]

Looks like you've solidified that #4 position, congrats! (I know you had it before, but it was very very close.) Funny seeing everyone messing with BulletHitBullet events after [[User:Simonton|Simonton]] mentioned gaining points with it in WeeksOnEnd. =) -- [[User:Voidious|Voidious]]

Yeah, nice improvement. I think this issue was on almost everyones to-do list, but [[User:Simonton|Simonton]] triggered us to increase its importance. It is quite an easy gain on movement (9 points for me) -- [[User:GrubbmGait|GrubbmGait]]

Thanks! I had no idea bullet collisions were that common in battles, or that it would be so easy to implement learning from onBulletHitBullet (I only just figured out you can use getX() and getY() for bullets). -- [[User:Kev|Kev]]

I'm glad you're trying pattern matching in your VG array. Pattern matching is my favorite :). I'll be interested to see how it turns out. -- [[User:Simonton|Simonton]]

Pretty well! I see green scores against 2k bots such as [[Garm]], [[PhoenixOS]], [[X2]], [[GresSuffurd]], [[RaikoMX]], [[PulsarMax]], [[Lukious]], [[PowerHouse]], and [[Engineer]]. It looks like a good pattern matching works well at killing surfers and getting those PL wins. -- [[User:Kev|Kev]].

So do your a/b versions each just have a single gun, no VirtualGuns at all? If so, will that be the next step after finishing tests with each? -- [[User:Voidious|Voidious]]

* Umm, right, I can read... =) Doh! -- [[User:Voidious|Voidious]]

Hey [[User:Kev|Kev]], did you forgot to take the second WaveSerpent out of the rumble? I can't help but think [[User:Krabb|Krabb]] and [[User:GrubbmGait|GrubbmGait]] want that #20 spot ;) -- [[User:Voidious|Voidious]]

*Never mind, we'll get there either way :P --[[User:Krabb|Krabb]]

Are you aware of how much memory your bot uses? I had to push the heap space up to 512MB and java was taking 500 megs of it, and right now robocode sits around 30 megs by itself with sample bots. -- [[Ntroutman]] 2007-09-08
* Are you referring to WaveSerpent 1.3b31? I know some recent version of WS had a bug and was storing way too much data, but the current one doesn't seem to be a problem on my system. Two WaveSerpents against each other (on a fresh launch of Robocode) is staying steady at 241 megs total through 100 rounds. It does seem that restarting the battle sends it up over 400 megs, though, and I see similar with [[Dookious]], so that would suggest a leak in Robocode itself. Probably should be reported to [[Fnl]] after a little more investigating. Are you seeing something different than I am? If you launch Robocode and run WaveSerpent first thing, is it really 500 megs by itself? -- [[User:Voidious|Voidious]]
* I grabbed the bot from this page, the link you have up top. As for memory leaks in Robocode, thats become my area (unofficaly currently), I just noticed I for got to sign my comment above (I'm the Nathaniel Troutman who worked on 1.4.3) so I'll check into things some more. I'll also check them out with Dookious. And I'll look into the possible Restart issue. -- [[Ntroutman]] 2007-09-08

This is great! Everyone is jumping on the DynamicClustering wagon! I'm having fun. It makes me happy. I '''never''' liked [[VCS]]. Never. Not for one minute, not one bit. -- [[User:Simonton|Simonton]]

* To be honest, I've never figured out why [[VisitCountStats]] works as well as it does. Intuitively (to me at least), it seems like DynamicClustering ought to be far more effective than VCS. -- [[User:AaronR|AaronR]]
* I think it's pretty elegant ([[KISS]]) and quite easy to tune. It executes ''very'' fast without any fancy algorithms and it clearly performs as well as anything DC-based, so far. I like DynamicClustering, too (a lot!), and it seems very "pure", but I gotta stick up for VisitCountStats. =) -- [[User:Voidious|Voidious]]
* I think the problem with DynamicClustering is that you may want some attributes to be absolute (for instance acceleration), yet you could still have a scan that is 'close' in all the other dimensions, yet not close in that one dimension, be 'closer' than a scan that is only slightly out in all the other dimensions. This can be overcome by segmenting the buffers you store your DC scans in, but that seems like cheating to me. Still, all is fair in love and Robocode =). I think my DC gun is ready for action, so look out, [[User:Kev|Kev]]! -- [[User:Skilgannon|Skilgannon]]
* I have to say that the INelegance of [[VCS]] is exactly what I dislike. Hard-coding the dividing line between segments is totally uncool. Also - I suspect that finding scans that are ''close'', rather than hard matches, is one of [[DC]]'s strengths. I've seen discussions about binsmoothing across segments taking too much processor in VCS systems - but that's exactly what you get built into DC. If you want accelleration to be an "absolute" dividing line, you could always give it a crazy high weight. Then, you still get the benefit of using real data when that acceleration value has never been seen before, but as soon as there are some matching scans those will be used. If you want a few attributes to have hard dividing lines it may be a bit more difficult ... but then that's exactly the inellegance that has kept me from [[VCS]] all along. That, and the fact that everybody else was doing it ... -- [[User:Simonton|Simonton]]
* I knew you'd say that (re: "INelegance"). =) I agree somewhat, but I think they are each elegant in their own way. The main thing elegant about VisitCountStats to me is this: VCS / [[Segmentation]] is really simple compared to DynamicClustering, in my opinion, yet as of now, it is still the most powerful system. And it's ''fast'', too, even without fancy data structures. -- [[User:Voidious|Voidious]]
* I see DC as the samurai and VCS as guys with guns, VCS isn't hard to be okay with, but is diffacult as any to be the best with, where as DC requires a bit of technique to even stand up (ergo the fancy data structures), not to say VCS doesn't, but it requires far less. But then again I could be totally wrong. It just makes it weirder that VCS predates DC. --[[User:Chase-san|Chase-san]]
* Hey, I kinda like that, actually. DC seems so pure and there's an obvious elegance to it, but there's also an elegance (to me) about a very simple invention that is very powerful. -- [[User:Voidious|Voidious]]
* One thing that I think people tend to overlook is that in your most frequently visited segments in a VCS gun (e.g. speed 8, no accel, distance 450) you can have really massive amounts of data. So you may be deciding the best angle to shoot at based on several thousand previous pieces of data. Whereas with DC you're only looking at 35, 50, maybe 200 scans at most, so if the enemy's curve is pretty flat in that segment, VCS may be better at picking up minor differences. Probably only applies vs. a few of the best RandomMovers, but still... --[[User:David Alves|David Alves]]

So, if you have a DC gun now, then don't you qualify for the TopTenDCParty? =) --[[User:David Alves|David Alves]]
* I thought only ''fully'' DC bots got you in the door? I believe WaveSerpent still surfs [[VCS]]. -- [[User:Simonton|Simonton]]
* What he said! -- [[User:Voidious|Voidious]]
* Aw, I wanted to party =(. WaveSerpent's movement doesn't actually use VCS, but it doesn't really use DynamicClustering either. I think I'll start working on a DC movement soon though... -- [[User:Kev|Kev]]

Congrats on the rating jump, dude, really awesome! -- [[User:Voidious|Voidious]]

WaveSerpent/Archived Talk 20090520

2009-10-08T03:52:33Z

Robobot: moved WaveSerpent/Archived Talk 20090520 to Archived talk:WaveSerpent 20090520: move to talkarchive

#REDIRECT [[Archived talk:WaveSerpent 20090520]]

Archived talk:User:Voidious 20071111

2009-10-08T03:52:31Z

Robobot: moved User:Voidious/Archived Talk 20071111 to Archived talk:User:Voidious 20071111: move to talkarchive

Welcome to the robocode addiction! -- [[User:Pulsar|Pulsar]]

Man, you said it! It's good for my programming skills, though, so it's not as hard to rationalize as some of my previous addictions :) -- [[User:Voidious|Voidious]]

I couldn't find any page for "miscellaneous discussion", is there one? Anyway, I wanted to point out this contest: 
[http://www.joystiq.com/entry/1234000283066508/ Tank Wars competition seeks smart AI programmers]
 
It's an invite-only competition, EA Games looking for AI game programmers... You can still download the package if you want, but you can only enter the competition if you go to one of the 14 eligible universities. Man, I'd bet some of you top-notch Robocoders could own this thing. -- [[User:Voidious|Voidious]]

Wow, I go to one of the 14 eligible universities... but I don't know C++ and the competetion is over. Other than that, boy, I bet a quick guess factor gun implementation and some nice random movement would be useful. -- [[User:Alcatraz|Alcatraz]]

When will we see the new Dookius in the rumble? -- [[User:PEZ|PEZ]]

Probably tomorrow... I'd like to rush it out and see how it ranks, but I am thinking of taking a short break from Dookious after this version, so I want to polish it a little bit first. (Plus I've released 4 versions into the RR in the last week.) There are a lot of aspects of Robocode that I haven't really explored much, and I would really like to toy with some various ideas soon. I doubt I'll be able to stay away from Dookious for too long, though... -- [[User:Voidious|Voidious]]

Too bad. Just throw it out and while waiting for a rating on it tidy up and polish it some. I'm curious! -- [[User:PEZ|PEZ]]

Well, OK, if you say so ;) I'm heading home now, I'll post it within the next 30 mins or so. -- [[User:Voidious|Voidious]]

I posted version 0.69, since the next release was going to be 0.70. It skips a lot of turns when I have CPU constant set to 1, something I was going to work on before 0.70, but I have my RR client set to 100 now, anyway. (It didn't take much of a performance hit when set to 1, anyway.) -- [[User:Voidious|Voidious]]

Wow, the air really is thin up there! I thought 0.70 would crack 2,000, but it's looking like it won't. Maybe I'll release *one more* version before taking that break from Dookious... ;) -- [[User:Voidious|Voidious]]

A belated congratulations on 2000, by the way. [[User:Florent|Florent]] was the only person to break the barrier in 2005. You've kicked 2006 off to a great start! --[[User:Corbos|Corbos]]

Thanks! I was extremely excited about that. I was workin' on Dookious a *lot* for several weeks before that, and now I'm really enjoying taking a break from him to try some other stuff... -- [[User:Voidious|Voidious]]

I spent much of yesterday tinkering with my first team, and got it to a very basic functional state. What a pain in the neck! That might be the last chance I ever give to AntiGravityMovement - it's generally so simple that it seems like a promising idea, but I feel like I have zero control over my tanks when using it. I will probably try some MinimumRiskMovement and/or some MultiMode strategy ideas next. Pain in the neck or not, it seems like a lot of fun! -- [[User:Voidious|Voidious]]

My attempts went from '5 Ugluks' to '5 Ugluks that didn't shoot each other' to '5 rambots that focused on one target at a time determined by the most senior bot alive in a chain of command' but that was a colossal failure due to the friendly fire that ensued. I spent about two days working on it around Thanksgiving and a few weeks ago I removed the last of the related code. -- Martin

Hehe, sounds a bit like my development process so far. Of course, you have a working melee bot, so you probably have a much better grasp of strategies with that many tanks on the field. Right now I'm happy to get over 33% of total score against any of the teams rated around 1600. -- [[User:Voidious|Voidious]]

It helps a lot if you have any melee-experience, even if it is just about how to handle the radar. Note that radar only has a 1200 scanrange. Most teams just are 5 meleebots put together, which leaves the door open for some 'real' strategy. [[Troodon]] is a very simple and successfull melee and teambot and one of the few that makes use of droids, I lent its way of communication for GrubbmGroup. My tip is to start with a simple gun and concentrate on movement. And watch your battles, it gives much more info about what goes right and wrong than the results can tell. -- [[User:GrubbmGait|GrubbmGait]]

Whoah, I thought I was at the wrong site for a moment when I saw this headline: [http://www.joystiq.com/2006/03/03/cyanide-launches-loki-web-site/ Cyanide Launches Loki Web Site] ... =) -- [[User:Voidious|Voidious]]
* It's not my kind of game, but at least the name sounds good. --[[User:Loki|Loki]]

A no. 1 rating at 486 battles and a positive momentum: will Dookious be the new top-bot and Voidious the new king? Stay tuned!

Anyhow, congratulations with your steady improvement on this strong bot. And i noticed you also entered the melee arena! So we will have to fear your presence there as well... --[[User:Loki|Loki]]

Thanks, Loki! I'm quite pleased with the latest rating, and I'll enjoy my time at the #1 spot, but the [[History/KingsOfRR|official crown]] certainly still belongs to Ascendant, since I'm sure his best version would outrank Dookious by a good 10 points.

* hehe, you wrote "I'm quite pleased with the latest rating" but i bet you are walking around with a permanent ear-to-ear grin on your face!!! And its earned! (reading this it's almost as if the British flag in front of Dookious is better suited ;) ) --[[User:Loki|Loki]]
* Ha, that comment made me laugh =) I guess "pleased" might be a slight understatement ;) There's a margin of error on anything I post about before lunch... -- [[User:Voidious|Voidious]]

And it might be a while before it's worth fearing me in the melee arena. That fear is probably better placed upon [[User:Florent|Florent]] at the moment. But I'll keep working at it... =)

-- [[User:Voidious|Voidious]]

My sincere congratulations to you! Real 1st place at RoboRumble. I can only hope, that one day my bot will enter first ten at least. -- [[DemetriX]]

Wow. I turn my back for a second and you take the #1 space - a very sincere congratulations! I look forward to seeing what kind of hornets nest you stirred up there. Well done. --[[User:Corbos|Corbos]]

----

I started using [http://en.wikipedia.org/wiki/Darcs Darcs], a free revision control system that runs on Windows, this week. Spoiled by large amounts of disk space, sometimes I'll just make a copy of my whole [[Dookious]] code directory when I want to preserve something, but I do know just how "wrong" that is. I finally put in the effort to find a CVS-type system that I can use on Windows, and Darcs is working very well for me so far; it's definitely worth checking out if you're looking for one. I wouldn't mind hearing what other people use, if anything. (I'd guess some of the Unix-lovers use CVS, which I've used but have never setup myself.) -- [[User:Voidious|Voidious]]

* Gah, I had seen the [[VersionControl]] page, but just found the [[CVS]] page. Maybe I'll give that [http://www.tortoisecvs.org/ TortoiseCVS] a try... -- [[User:Voidious|Voidious]]
* I've been using Subversion happily for a little while, and there is a plugin for Eclipse which makes it so easy to commit new versions. -- [[User:Alcatraz|Alcatraz]]
* I have been using [http://www.march-hare.com/cvspro/ CVSNT] since I started [[X2]] along with CVS plugin for Eclipse. It saved me few times. -- [[User:Florent|Florent]]
* I use nothing :o Almost all my bots are using only one sourcefile. (and I also use [[User:Kawigi|Kawigi]]'s built-in editor) -- [[User:GrubbmGait|GrubbmGait]]

I e-mailed PEZ right when this started, about 1.5 hours ago, just so you guys know. I hope he shows up sometime soon, but if not, it seems very likely to me that he (or I, if he wants me to) could write a script to revert the vandalised pages, and I don't doubt he could come up with some way of filtering out the SPAM edits in the future. I wish I had the time to keep helping with the reversions, but I have a research paper to work on, unforuntately. :( -- [[User:Voidious|Voidious]]

Sorry for the rudeness but... HOLY FRICKIN CRAP! Whoever did this(and their bot) should be shot in the testicles! -- [[Xero]]

----

Well, I picked up a MacBook (white, 2 GHz) today, and I am loving it so far. I've only got 512 RAM right now, and I'm going to upgrade to 2 gigs on my own since Apple would charge $450 for that upgrade (sheesh!). I haven't collected hard numbers on how it compares to my AMD2000 Windows machine in Robocode speed just yet, but it seems to be noticeably a bit faster (as I would hope). Also, this machine is still completely usable even when running an intensive benchmark; and I was able to run 2 separate Robocode matches at the same time with seemingly no slowdown. I haven't found anything to let me manually assign a process to a specific core on a Mac, but if anyone knows how, feel free to let me know.

Of course, even if the speed of Robocode were just ''not worse'' than my AMD machine, I would still be very happy to be using Mac OS X instead of Windows =) So I am quite a happy camper right now. I hope you other Americans are having a good holiday weekend!

-- [[User:Voidious|Voidious]]

Have fun with the new machine. =)

Hey, I remember reading somewhere that you changed your RR@H client to fail quickly if the repository was unavailable. Could you send me the class files for that version? My contact information is on ContactInfo. --[[User:David Alves|David Alves]]

I sent you my version (which should be the same as [[User:Voidious|Voidious]]'). This version will never download a bot from the repository, if it is available or not. This means that I download a bot manually if necessary and put it in the 'robots' directory. -- [[User:GrubbmGait|GrubbmGait]]

Ah, beat me to it! :) Anyway, I posted my .class files for that version online, too: [http://www.dijitari.com/void/robocode/roborumble_norepository.zip roborumble_norepository.zip]. It's just replacing the part after the "if" in line 205 of netengine/BotsDownload.java with "return false", instead of formulating the robocoderepository.com URL based on the id number. -- [[User:Voidious|Voidious]]

----

Snipped that discussion over to [[TwinDuel/2v2CompetitionIdea]]. -- [[User:Voidious|Voidious]]

----

I'm taking a machine learning course at school this semester, and one of the books we are using for the class is available for free online, with the stipulation that you don't print it. (It's also sold as a "real" book by a publisher.) It assumes some familiarity with some high-ish level math, but I figure some of you might find it interesting: [http://www.inference.phy.cam.ac.uk/mackay/itila/ David MacKay: Information Theory, Inference, and Learning Algorithms] -- [[User:Voidious|Voidious]]

----

Thanks for running those TC battles; though, please don't feel obligated to make up for my laziness. ;) I'm running a few MC rounds to make up for it... - just hard to balance everything with robots, family, work, and my [http://handmodel.co.uk/ hand modeling career]. Cheers. --[[User:Corbos|Corbos]]

Don't worry, I feel no obligation =), I was just curious to see the scores on your latest release. It looks like [[Chalk]] is a strong contender for the most accurate DC gun out there - very impressive. And besides, it's always nice to flex my MacBook's Core Duo muscle during lectures ;) -- [[User:Voidious|Voidious]]

[[Shadow]]'s got nothing to fear for a while. I've noticed (regretfully) that most of my improvement is against the more simple bots. My PL scores remain wanting. Still, my robofire is refueled. I've got a couple more ideas before I go dormant. What's the class schedule like this semester? Don't you have a couple theater credits left so you could go easy on us for a while? --[[User:Corbos|Corbos]]

Well, only one specific class "required" for my degree (it's my last semester), so I get to take my other classes as pass/fail, which is nice. However, like the dork I am, one of those "electives" is a Senior / Grad level Machine Learning course. On the one hand, it might consume my time so that I have less for Robocode; but on the other hand, it's possible I'll learn something that will help in my Robocoding. =) We're soon looking at k-means clustering. -- [[User:Voidious|Voidious]]

Growing a little frustrated by my recent work on BrokenSword, I turn back to an ancient problem that I've never quite solved: hitting [[Shadow]]. =) -- [[User:Voidious|Voidious]]

----

By the way, have you finisced your NaNoWriMo? I enjoyed the beginning and would like to read the whole story! --[[User:Krabb|Krabb]]

Hey, I saw your comment, I appreciate that =) Unfortunately, with everything else I had going on in November, I failed miserably to finish my story again this year. But I was really enjoying it, so maybe I'll pick it up again even though I missed the Nanowrimo deadline. Thanks for checking it out, man ;) -- [[User:Voidious|Voidious]]

Well, it's about time I post the reason for my recent hiatus: I've spent the last month or so moving to / starting my new job. I should be at least a little more active again in the next week or two, but we'll just have to see what happens. There are still some more pressing concerns, like adding to my miniscule quantity of furniture. =)

I'm certainly still reading the wiki regularly. I know I missed the TwinDuel this past week (without notice, too, sorry), but I'll get it going again this week, for sure. Maybe I'll even find time to try and improve LuminariousDuo in time or work on that TargetingChallenge2K7 score.

-- [[User:Voidious|Voidious]]

Hey [[User:Voidious|Voidious]] i was wondering if you knew how to setup a robot project in xcode so that xcode will compile the bot and copy the class files back to the robots directory in Robocode after a build. Thanks!! -- [[Gorded]]

Sorry man, I really don't know. I haven't played with XCode all that much yet, though it's always on my list of things to do. I just use Eclipse for Robocode. -- [[User:Voidious|Voidious]]

Hey, who was that from rpi.edu that just edited / reverted the main page? That's only about an hour away from me and I know a couple people who go there. Just curious. =) If it's someone new and you'll be hanging around, feel free to make a page for yourself and your bots. -- [[User:Voidious|Voidious]]

[[Category:Archived Talk|Voidious]]

User:Voidious/Archived Talk 20071111

2009-10-08T03:52:31Z

Robobot: moved User:Voidious/Archived Talk 20071111 to Archived talk:User:Voidious 20071111: move to talkarchive

#REDIRECT [[Archived talk:User:Voidious 20071111]]

Archived talk:Virtual Guns 20071129

2009-10-08T03:52:29Z

Robobot: moved Virtual Guns/Archived Talk 20071129 to Archived talk:Virtual Guns 20071129: move to talkarchive

== From old wiki's Virtual Guns page ==

=== What is VirtualGuns? ===
VirtualGuns is a way to choose the best aiming method against a given enemy by keeping track of each methods' virtual hit rate (or some other measure). There are obvious advantages:

=== What are the advantages ===

* Enemies tend to move quite differently, VirtualGuns will make your robot adapt.
* In theory it's can be quite easy to implement.
** And can be implemented in very many ways. [[OrcaM/Code|OrcaMs]]' <nowiki>NNCandidate</nowiki> is one way. [[MakoHT/Code]] is another. [[Marshmallow]] was my first bot using VirtualGuns and the design is outlined below.
* You can let your bot explore quite different [[Targeting]] techniques, even quite simple ones, in the hope that it will find weaknesses against particular opponents.
** For example against some bots [[HeadOnTargeting]] is better than many other targeting implementations. (Against a truly flat movement it can be better to just guess head-on all the time than risking to guess differently and wrong too many times.)

=== Disadvantages ===
* The main disadvantage is that in practice it can be quite hard to implement.
* You risk messing up things so that the array performs worse than your best gun would do on its own.

=== How does it work? ===
[[Marshmallow]] was my first bot using VirtualGuns (ehh, it was my first bot, period). It uses the following strategy for this:
# Everytime the robot is ready to shoot it creates an array of virtual guns and aims each of them
# When firing it stores this virtual gun array in an event
# The event's test() method checks wether a particular virtual gun has either hit or missed (using [[Wave]]s).
## Statistics are updated for each gun which has either hit or missed
## When all guns are finished the event is deregistrered and the virtual gun array is disposed.
Note that there's no event handler for this event. I only use it to store the copy of the virtual guns array and to get Robocode to run the test each tick. Like VirtualBullets/VirtualBulletsBot does.
-- [[User:PEZ|PEZ]]

=== What bots are using this? ===
Please add relevant bots to this list.
* SandboxDT
* [[Duelist]] also uses "virtual guns", it used them to decide how fast it should adapt its aim, ranging from "fire using whichever virtual bullet hit last time" to "fire using the virtual bullet that has been most effective on average over all data vs. this bot". --[[User:David Alves|David Alves]]
* [[Mako]], [[MakoHT]]
* [[OrcaM]]
* [[GB]]
* [[SpareParts]] has a bunch of them, which help him proof himself against brutally simple robots (I made robots later that did much better against good robots and ranked higher, but couldn't beat Walls).
* [[Ascendant]]
* [[CassiusClay]] (as of this writing in a development version)
* [[Dookious]] presently uses two GuessFactor guns in a VG array. One has a higher depth on the [[RollingAverage]]s and uses non-firing waves, the other uses only "real" waves and has a much lower rolling depth (aimed at WaveSurfers / adaptive movements).
* All of [[Greywhind]]'s bots use VGuns so far - all simple targetings, Laser, GF, and PM are included in Constitution and Strength.
* [[GrubbmGrb]] has a VG array of simple targeters (HOT, CT, random, av velocity CT and orbital)
* [[Ugluk]] has been using multiple simple targeters since before 0.3.0 (first Roborumble entry). I wanted to be able to defeat all sample bots before I entered, and what works for Walls does not work for SpinBot. Ugluk varies as to how many guns he has, but it has been as high as eleven at once.
* [[Perpy]] uses four different guns, using virtual bullets to assess hitrate. Respectively, they are HOT, CT, a GF gun and a patternmatcher.
* [[Squirrel]] uses a pretty big virtual guns array, including 4 GF guns, 3 AntiSurfer GF guns, 1 CT gun, 1 LT gun, and 1 HOT gun.


----

One detail that I think makes sense is this: weight your VirtualGuns data (hits and misses) proportional to the difficulty of hitting the enemy in that situation. For instance, 12.5% vs 12% at distance of 500 is the same ratio as 25% vs 24% at a distance of 250, but if you have an even number of data from each distance, the latter has more effect on that calculation, while it should be the same. So far, I've been weighting my VirtualGuns data proportional to distance, but I'll be making it bullet time (slightly more accurate) and total reachable escape angle (which I already calculate precisely in [[Dookious]]). -- [[User:Voidious|Voidious]]

Sounds reasonable. Would it also be helpful to take into account the percent of maximum escape angle taken up by the bot at each distance? -- [[User:Simonton|Simonton]]

The above two factors are actually my attempt to calculate exactly what you said - the average hit rate for RandomTargeting in that situation = exactly proportional to bot width / total escape angle. That percentage is proportional to both bullet time and the total escape angle. Can you think of any other factors? I would definitely add them if I knew them, but I think those two paint the whole picture. -- [[User:Voidious|Voidious]]

If your escape angle calculation takes into account wallsmoothing, then I can't think of anything else. -- [[User:GrubbmGait|GrubbmGait]]

* Yep, [[Dookious]] uses precise escape angles that take walls into account. -- [[User:Voidious|Voidious]]
* Hmm, hey wait. Distance is a factor in both bullet time and total escape angle, so I may be counting that one more than I should. Maybe it should be just distance and total escape angle? I decided on bullet time instead of distance before adding in the total escape angle thing... -- [[User:Voidious|Voidious]]
* Yes, you are right. You're not going to get it exact, because to convert bot width to an angle requires knowing the angle at which the bullet would hit the bot (because the bot is a square) as well as the distance to the bot (which can vary depending on whether the bot advances or retreats, e.g. for wall smoothing), but you already knew that. Anyway (bot-width-angle / escape-angle) or (bot-width / escape-distance) do encompass the whole picture, they're just slippery variables to nail down. -- [[User:Simonton|Simonton]]

----

Has anyone tried VirtualGuns within VirtualGuns? I think this could be effective against surfers, because your anti-surfer VirtualGun could choose between pattern-matching, a small DC gun, a lightly segmented GF gun, etc, and your regular gun could be just one, big GF gun. You can choose between your array of anti-surfer guns (which are treated as one gun by the 'main' virtual gun system) and your main gun using gun stats that have a very high rolling depth, but between the anti-surfer guns with a low depth. Because surfers constantly evolve their movement, at different points their movement might be more susceptible to different types of guns. -- [[User:Skilgannon|Skilgannon]]
* I would imagine that a literal implementation of this would be ridiculously slow. However, an equivalent method would be to put all of the guns in a single array and modify the method used to choose between them to consider the anti-surfer guns as a collective group. Only if it picks the group would the choice function look at the individual anti-surfer guns. On the other hand, by itself it is probably really slow to have several pattern-matching guns and DC guns in a VG array, so it might not be practical either way. -- [[User:AaronR|AaronR]]
* I understand what you're saying, but I have to ask - when would this ever be preferable to just choosing the best of all your guns? Do you really want to penalize choosing your best AntiSurfer gun by grouping it with your worst AntiSurfer gun in terms of VG rating? Also, I think it's really hard not to lose performance as you add more guns to a VG; often, it's best to cut the weaker guns even if they are better sometimes, because your chooser will never be perfect. -- [[User:Voidious|Voidious]]

== From old wiki's Virtual Bullets page ==

{|
| [[Image:Virtual_bullets_sample.png|422px]]
| Screenshot of /VirtualBulletsSampleBot on Robocode 1.1.3, showing virtual bullets for the three included VirtualGuns in flight, and # of hits for each Gun. Note that "Really Bad Gun" is initialized with 1 hit, but the robot quickly learns to use better methods. --[[User:David Alves|David Alves]]
|}

For a simple implementation with debugging graphics, take a look at /VirtualBulletsSampleBot, by [[User:David Alves|David Alves]]

For an implementation using Robocode custom events check /VirtualBulletsBot, by [[User:PEZ|PEZ]]
----
The concept behind virtual bullets is simple. Since the enemy can't tell what angle our gun is pointing when we fire, their reaction is not based on our gun angle. Therefore we can create a "virtual bullet" for each gun offset that we could have had at the time we fired, and keep track of these virtual bullets to see if they would have hit our enemy if we had actually fired at that angle. We can now track the success rate of each firing angle and see how well it is working.

if (bullet hit)
raise success rate for aim method used to fire this bullet
else if (bullet missed)
lower success rate for aim method used to fire this bullet

For example:
DuelistMicro chooses the angle to fire at from -2/3 to +2/3 radians, where 0 is pointing directly at the target, negative is behind them (relative to the last direction they moved if they are stopped) and positive is in front of them. You could also use virtual bullets to track how successful linear, circular, and direct firing are vs. the current opponent. The beauty of virtual bullets is that you'll learn at the same rate no matter how many different aiming algorithms you use - just fire more virtual bullets. :-)

Virtual bullets are used by the following bots:
* SandboxDT
* DuelistMini
* [[Dalek]]
* [[Marshmallow]]
* DuelistMicro
* [[Duelist]]
* SandboxMini
* PrairieWolf
* DogmanSPE
* [[Andrew|R2d2]]
* GrubbmGrb

and many others.

Virtual bullets were invented independently by Paul Evans and Rod Hyde.

--[[User:David Alves|David Alves]]

Here is Paul Evans' definitive write-up: <s>[http://www.sandbox.dial.pipex.com/robocode/guessfactor.shtml Virtual Bullets]</s>

I don't think Paul Evans or Rod Hyde are the first ones to use VirtualBullets, though. Some older bots like LoneDragon use virtual bullets as well (see LoneDragon 's bot-description http://robocoderepository.com/BotDetail.jsp?id=330 ). I do believe it was Paul Evans' idea to fire multiple VirtualBullets at the same time. -- [[User:Dummy|Dummy]]

Robocoders were using BulletTracker classes long before Paul and Rod came up with VirtualBullets (See [http://www.geocities.com/evilsimon/RayBot/RayBot_Description.html RayBot], [http://members.rogers.com/theartofwar/#fire TheArtOfWar - How does it fire, How does it dodge bullets], [http://www-106.ibm.com/developerworks/library/j-tipbullet.html Secrets of the Robocode Masters: Tracking Bullets]). Same principle: plot the bullet path, see if it hits, and use the resulting data to improve aiming. Paul's [http://www.sandbox.dial.pipex.com/robocode/guessfactor.shtml breakthrough] was realizing that he didn't have to actually have to fire a real bullet in order to plot its path and he could fire several of these VirtualBullets at one time. -- [[Ray_Vermette]]

Paul's breakthrough was also in getting the damn things to work! FiringBD in its various incarnations used what I called "magic" bullets, but my implementation was much less successful. I had lots of different aiming types, most of which were variants of linear and circular firing which used a number of types of moving averages based on heading, velocity, etc. --[[Rod Hyde]]

----
Isn't that some robots use VirtualBullets for enemy bullets as well? I think I've seen it used with AntiGravityMovement. -- [[User:PEZ|PEZ]]

Yes. Fermat 1.6, which won the Robocode Rumble in the intermediate category, used this AntiGravityMovement with predicted enemy bullets as gravity points. That's why you'll never hit it if you fire using linear, circular, or direct targeting. :-) Fermat has since then been updated to version 2.0, which uses virtual bullets for its own targeting as well as using them for dodging. --[[User:David Alves|David Alves]]

Both [[Neptune]] and [[Pluto]] use VirtualBullets for bullet dodging, I call it [[ShrapnelDodging]]. They also use something similar to VirtualBullets for aiming, which I call [[LaserTargeting]]. --[[User:Tobe|tobe]]

I have a '''very''' hard time hitting [[Fermat]] with PatternTargeting as well. But [[Fermat]] 2.0 does not have the same problems hitting [[Marshmallow]]. VirtualBullets might not be such a bad idea. =) -- [[User:PEZ|PEZ]]

Don't underestimate Pattern matching - look how well Cigaret is doing... :-) --[[User:David Alves|David Alves]]
----
[[Marshmallow]] uses VirtualBullets inside its VirtualGuns. There's no opposite relation between PatternMatching and VirtualBullets. Marshmallow uses both. Some people think of VirtualBullets as being GuessFactorTargeting, but they are not the same. Marshmallow will be using GuessFactorTargeting as well soon. -- [[User:PEZ|PEZ]]
----

Hmph... I must be the only person online who doesn't like the idea of virtual bullets.

I'm not saying they won't work or they aren't succesfull; Paul and others have obviously proven quite the opposite. It's just that the concept always seemed so limiting and slow (BLARG I can't find my words tonight!). The idea behind virtual bullets is that you fire a virtual bullet at every x angle. The main problem seemed to me that this is such a low-resolution approach: for each x angle, you only get a collision on the closest multiple of the x angle. The problem with speed is you need to calculate a collision for each of those bullets once you've decided that at least one of them has collided.

A more analog approach always seemed more attractive to me; just remember your position, the direct angle to the enemy, and the power of your bullet whenever you fire a bullet. Calculate when the bullet has collided in the same way as VirtualBullets (using the current distance from the enemy to your position when the bullet was fired). When this happens, just find the angle between the logged angle to enemy at the time of firing and the current angle from your logged position to the enemy.

This algorithm would seem to accomplish the exact same task as VirtualBullets, but would be MUCH faster to calculate and with infinite resolution.

The whole '[[VirtualBullets]]' craze always seemed to remind me of all my math and physics and chemistry classes throughout highschool; everybody always seemed so eager to attack a solution by trial and error, or by writing possibilities or cases, or by doing each problem individually. Why? The power of taking a simple derivative or applying the quadratic formula was always unmatched, giving me a general solution beforehand of solving Question 4 a) through q) for example without even having to know the numbers. Solving each set of numbers for a question was simply a matter of punching the numbers into the calculator at the right places in the formula to simply jot the answer on the page. The power of simplifying with algebra to give me a general, algebraic, fully analog solution beforehand has always outweighed doing a) through q) individually, or solving whatever problem by trial and error, or using a bunch of cases and finding the closest one; such is the case in VirtualBullets. Why not just find the solution in real numbers?

-- [[User:Vuen|Vuen]]

Well, the way you describe it is exactly how I do VirtualBullets in all my bots. I know some people fire lots of VirtualBullets, but I think most such solutions are being replaced by [[Wave]]s. Which, by the way, are also used by my bots.

Call what you do what you want, to me it sounds like VirtualBullets. =) -- [[User:PEZ|PEZ]]

----

Since DT 1.71 I have removed virtual bullets in favor of waves primarily for performance reasons (an other reasons not relevent for this discussion) - it makes little difference to the published guess factor statistical approch - once the wave 'hits' the opponent I have to calculate the minimum and maximum guess factor that would have succeeded in hitting the enemy and from there I need to update the stats on all the guess factors from -1.0 to 1.0. (DT1.71 has 32 distinct guess factor 'bins' and more than one method of calculating guess factor - much more than previous DT's which is why I needed to loose virtual bullets in favor of waves.)

The statistical guess factor approch requires discreate bins of data (I looked in some prety deep math/stat resources to overcome this with no success). It does not matter to the approch whether you separate the hit/miss data with virtual bullets or later with the results from the wave.

At the time of writing my virtual bullet code I was aware I could do it with a more efficient wave method (not that it had been invented then) but with less than 24 hours to go before IBM's Robocode Rumble deadline I went for the easy to debug/check virtual bullet method.

Either method is good as the other for the statistical approch (but waves are more efficient), however, if you want a single accurate hit angle to the center of the enemy (as pattern matchers prefer) then waves does the job better.

-- [[User:Paul Evans|Paul Evans]]

Ah, cool. I had not heard of waves before this; turns out waves are exactly what I had described. Bah.

Are you sure there's not some mathematical way to build an actual curve with the data rather than a statistical array? I'm trying to think of a way to regress the data into a curve without losing resolution; the problem is that the data is additive, in that two points near eachother add together rather than emphasize the curve at that point. I wonder if analysizing the data and iterating through it would allow you to find the inflection points in the curve and use them as spline nodes to build a real curve from; this would theoretically generate a curve for you where the data is algebraic and you can pull any point off the spline in real numbers. The problem seems to be the slight additional processor power required, but a curve recalculation can be made to occur only at every few hundred ticks or at the end of every round for example. Finding inflection points would give you direct highs and lows for gun accuracy in real numbers, rather than high and low 'bins' in iterated multiples.

This seems like something I'd like to try; I've been rolling around a new gunning concept in my brain lately, and inflection points is a step forward in an early calculation that would need to have been done anyway for my new gun, so as soon as classes are over I'll see about building this.

-- [[User:Vuen|Vuen]]

I'm not 100% sure, but I'm fairly sure (but don't let me put you off). One of the problems is that it is not possible to know how many inflection points there are on a graph in advance, you can't therefore do a regression analysis because you don't know the 'polynomial order' of what you are looking for. Some graphs have 5 or 6 max/mins. I looked at using regression analysis as a 'compression' method for data storage, but in the end I developed a lossy system (like JPEG but without the discrete cosine stuff which I don't understand in sufficient detail to test/debug and which is optimised for visual requirments and not robocode requirements).

When I had fewer bins I experimented with calculating a parabolic maximum from the maximum bin and the two bins either side - it did not add much value and in the end I ditched the code in favor of more bins and better compression of the data.

To give you a start on your resarch the problem we have in a statistical gun is that we have many (or somtimes only a few) discrete points into which we want to convert into a smooth 'density' line/surface/blob... The statistitions often have this problem with data and they utilise a 'Density Estimator' method - look it up via Google and see what you think. (If there was "some mathematical way to build an actual curve with the data" I think the statistitions would have found it - and I would have found it on the web). In the end I used some of the concepts of Density Estimators in my post 1.71 Gun's.

Good luck --[[User:Paul Evans|Paul Evans]]

Phew. I always knew you were a rocket scientist and brain surgeon in one person Paul. =) -- [[User:PEZ|PEZ]]

Of course, even if what you're storing is discrete, the comment about efficiency (basically that it's more efficient to fire one wave bullet than 30 or 40 discrete virtual bullets) still holds - in fact you started doing that as well in 1.71, too, I believe (and probably used it for that Density Estimators stuff). -- [[User:Kawigi|Kawigi]]

Yes - when I said Post 1.71 I ment Post & including 1.71. -- [[User:Paul Evans|Paul Evans]]

Hmm; you're probably right. What angle multiple does SandboxDT use for its bin frequency? I figure using say a bin every 1 degree would allow for lots of room to work with, and would allow the bot to find the inflections it needs without needing an actual spline curve. The data can be compressed by finding the inflections and handles from the bins themselves and writing those rather than writing actual bin values, so compressing this much data should not be much of a problem. I've started building my new bot, and will begin with a bin system in one of it's pattern analysers as soon as I program it to shoot :). I will probably also begin building an applet alongside the bot to graph and verify the curves it finds, much like liley's SmogPainter, but integrated into it's webpage button. Anyway, back to my bot... :)

-- [[User:Vuen|Vuen]]

I use 32 bins (and 13 distance ranges) each bin has an angle dependent on the bullet speed and guess factor calculator. For a simple absolute angle guess factor calculator the bin angle would be 2.9 degrees with 3.0 bullets (2*asin(8/11)/32), 1.5 degrees for 0.1 bullets (2*asin(8/19.7)/32). at a distance of 500 - 2.9 degrees is eqivalent to 0.32 of the width of a bot - more than accurate enough. Also most good bots have fairly smooth curves one point is almost as good as it's neighbour, bots with sharp points aren't a problem.

-- [[User:Paul Evans|Paul Evans]]

Ha! [[User:Paul Evans|Paul Evans]] also came up with asin(8/bulletv)! (We've had discussions over what the maximum offset can be before). -- [[User:Kawigi|Kawigi]]

Hey, one thing - how does this density estimator stuff perform against robots with a highly irregular curve? (i.e. - if they somehow had a really high negative spike and a high positive spike) -- [[User:Kawigi|Kawigi]]

As with standard guess factor guns there is no problem - to get a sensible curve you have to tune somthing I think was called a "kernal wavelength" based on the number of data points you have and the distribution of those points - (this appears where alot of work goes into density estimators - too small a wavelenth and you get a graph with too many spikes, too large and you 'blend' out important information/peaks. Unfortunatly it appears that there is no easy way to calculate the optimum kernal wavelength (and also I did not see anything on the web as to how to add new data to existing desity estimates). But note my earlier comments - I only used some of the concepts of density estimators, they are computationally too intensive for robocode. -- [[User:Paul Evans|Paul Evans]]

Back when I was trying to build a Bayesian statistical gun I also experimented with the idea of kernel density estimators based on gaussian curves. Unfortunately, after running many sets of data with DT through an industrial-grade data mining ap they turned out to be basically useless, in addition to horrendously slow. (Nor did any other standard data mining technique work, btw. Since coming to robocode I am beginning to think that virtually everything ever written on the subject is bunk. :-\) - [[User:Jamougha|Jamougha]]

I was thinking that if you wanted to represent a curve by an arbitrary amount of points, wouldn't that be a perfect application for a self organizing map (SOM) neural net? Something like the "Growing Neural Gas" at http://www.sund.de/netze/applets/gng/full/GNG-U_0.html [[JHH]]

[[Category:Archived Talk]]

Virtual Guns/Archived Talk 20071129

2009-10-08T03:52:29Z

Robobot: moved Virtual Guns/Archived Talk 20071129 to Archived talk:Virtual Guns 20071129: move to talkarchive

#REDIRECT [[Archived talk:Virtual Guns 20071129]]

Archived talk:Virtual Guns 20060129

2009-10-08T03:52:27Z

Robobot: moved Virtual Guns/Archived Talk 20060129 to Archived talk:Virtual Guns 20060129: move to talkarchive

Sorry for just blindly moving all this. But it gets hard to see what is relevant after a while.... I'm trying to get more tidy VirtualGuns page. -- [[User:PEZ|PEZ]]

From the VirtualGuns page ... From the RoboRumble/RankingChat page...

It should be noted that the fix also mysteriously hindered Jekyl's performance against the Flood bots, which Jekyl has been a significant problem for for some time, before he was in the top 10. I may finally be passing up DT as "the bot that requires buggy aim to be hit" (FloodHT 0.7 had a really funny targeting bug in one of its guns that ended up getting selected against SandboxDT when it kicked in). -- [[User:Kawigi|Kawigi]]

I guess that's a big advantage of VirtualGuns. Right now I have a huge bug in GD's gun though, it is definately not worth keeping there. =) -- [[User:PEZ|PEZ]]

Yeah, VGs is the perfect solution. Have both the buggy gun and the fixed gun in the bot, and pick between them. That way you don't lose the illogical benifit, and you still get to improve against normal bots. -- [[User:Tango|Tango]]

Provided, of course, you have a working selection scheme. Which is not always trivial. At least not a fast learning one... -- [[User:PEZ|PEZ]]

...and you usually seem to do worse than having one gun or the other... -- [[User:Kawigi|Kawigi]]

Yeah, I know you often say that. I will prove you wrong some day. =) -- [[User:PEZ|PEZ]]
* And when you do, let me know how you did your gun selection :-p Fhqwhgads's is simple, I'll admit, but it still does worse than FloodMini and FloodMini only firing waves when he fires a bullet, and basically he just VG's the two. He does worse than both options against the majority of opponents, and scores in between them in the other cases. -- [[User:Kawigi|Kawigi]]

* [[User:PEZ|PEZ]] unless you somehow manage to be %100 accurate in your selection of guns, it stands to reason that you will select the wrong one at least some of the time. If this is the case, then it stands to reason that your VG Array can never, ever, be better than your best gun, but don't let me discourage you =^>. It is times like this that I wish I knew more details of a [[SandboxDT|certain]] gun. I am sure that what ever is being done here is somehow more clever than anything that I have ever though of (so far anyways). -- [[Sparafucil3|jim]]
** You have a flaw in your logic there. Picking the wrong gun some off the time does not imply that your VGs will be worse than the best gun on its own. It will certainly lose against some bots it would have won against otherwise, yes, but as long as it picks the right gun enough of the time when the non-best gun is better it will still be better than the best gun on its own. -- [[User:Tango|Tango]]
** I agree with [[User:Tango|Tango]] here. Fully. As you pointed out your buggy gun could prove the best against particular bots. It stands to reason that the VG array will perform better against most bots than your bug-free gun does. I think the preformance of the VG array depends some on what you store in it. I think [[Paul]] has carefully selected the contents of DT's array. Probably guns with distinctively different characteristics. Although probably not as different as those in [[Marshmallow]]'s array. I would like to store [[Musashi]]'s, FloodMini's and [[Lacrimas]]' guns in an array and see what happens. -- [[User:PEZ|PEZ]]
***I guess it depends on how we measure better. While you are picking the "right gun enough of the time", your are is still picking the "wrong gun" some of the time. This will degrade the accuracy of *all* your guns by some measure (I call this the THRASHING_CONSTANT =^>). By my reconning this means that no single gun can be more accurate *overall* than your best gun. I do conceed that there may be situations where you may have another gun, which even with it's degraded performance, performs better against a given target than your degraded best gun would. If you can chose this gun accurately enough, your performance aginst this bot will be improved. I do know that you will certainly perform worse against a vast majority of bots (assuming for a moment that your best gun is selected most often), as you will hit them less often with your now degraded performance. The question is where is the cross over? What degradation in your primary gun is acceptable for the uptick you receive in certain situations? All of my efforts have led me to believe that I won't find it, and believe me I have tried. I hope someone does and shares the information though :) -- [[Sparafucil3|jim]]
*** There's only one way to measure better; Higher hit rate (with equal bullet power). I don't see where you pick the wrong gun. If you fire with the gun with the best virtual stats for a given segment it will be the best gun you have. Only in the case where the two top rated guns have equal performance you will ever trash. And then you'll trash between two guns of equal performance and there's no harm done. -- [[User:PEZ|PEZ]]
**** Precisely. GuessFactorTargeting is in fact a type of virtual gun, you have lots of guns which all fire a certain amount ahead/behind the target, and you work out which one is best by comparing the hit rates, you can do the same thing with more vastly different guns, such as PM etc. It might be interesting to try a VG array in which each bin of the GF gun is on the same level as all the other guns. Probably wouldn't work, but it might be fun to try. -- [[User:Tango|Tango]]

I'm confused; how did we suddenly break into a giant embedded bulletted list rather than just normal posting? :) Hope nobody minds if I break the trend... Anyway, about VirtualGuns, you guys are forgetting the fact that all the guns in a VirtualGuns array usually have very different learning times. For equal learning time guns, considering them on the large-scale, they can be an advantage, but against a single enemy, as [[Sparafucil3|jim]] pointed out they can never perform better than your best gun. They can't help you out against a single enemy, and they are basically useless to test against the top few dozen bots. However, with varied learning times, while your highly-segmented GF gun will be rarely accurate until it has enough data, your slightly segmented GF gun will be able to produce quick results that at first will be better than the high segmented gun. However across the course of the battle, using rolled statistics the highly segmented gun will quickly kick in as soon as it has enough data to consistently produce better results than the slightly segmented gun. This is what SandboxDT uses IIRC, and not a selection of equal learning time guns. This is part of what AutomatedSegmentation tries to do, but analytically rather than statistically. Anyway in the past couple of days I came up with a much better way to weight the reliability of the axis, but it's exam time now and I don't really have time for Robocode. I'll be back on it sometime later; just give me a few weeks :).

-- [[User:Vuen|Vuen]]

The reason we went with bulleted lists is that the VG discussion was not the last topic on the page. This is a wiki, you can break any trend you like. =) I think you are pointing out the only real weakness with VG arrays. Learning time and descisions on when to start trusting this or that virtual statistic and when to reset the ratings and such. It is tricky. I don't agree that a VG array could never be better than your best gub against a particular opponent though. Consider opponents that uses different movement strategies in different segments (like [[Chameleon]] for instance). I think many bots do this by accident as well. -- [[User:PEZ|PEZ]]

vote: are virtual guns worth it with the the option to use a single guess factor gun instead? --andrew

|'''Name''' |'''Yes'''|'''No'''|'''Maybe'''
|[[User:David Alves|David Alves]] | | | X
|[[User:Jamougha|Jamougha]] | X | |
|[[User:Kawigi|Kawigi]] | | | X

Hope that helps. :-) --[[User:David Alves|David Alves]]

But only because of all the new AM bots which are so hard to hit with GF guns. -- [[User:Jamougha|Jamougha]]

I think that no one has successfully used VG's in the purest sense in an optimal way, although I wouldn't rule out someone doing it. Although I think that VG's as an implementation is too undependable relative to one solid gun, except in the case of very special-purpose guns. As far as using multiple general purpose algorithms for targeting in the same bot, I think that the only way you'll ever have it work as good as or better than your best general-purpose gun is to have them cooperate - the guns can't be completely independent of each other if they are to perform better overall than either of them (something like having a husband and wife hold a contest to see who can conceive first without the help of the other). -- [[User:Kawigi|Kawigi]]

I'd be pretty mad if my wife won. :-P --[[User:David Alves|David Alves]]

i bet your wife would be very confused if you won.--[[andrew]]

can someone help me with this virtual gun stuff. i have a seperate wave class for virtual gun waves. i fire a virtual gun wave whenever i fire a real bullet. when i make the wave, i make an array of doubles inside the wave object which holds the guessed angles. so when after the wave hits,i check to see if the hitting point was a guessed value,if it was, i update the stats accordingly for that gun. so:
<pre>
public class VGunWave extends Condition{
double vDistance;
double bulletPower;
double vBearing;
double vBearingDirection;
Point2D vGunLocation;
double[] vGuns=new double[3];//this holds the angles chosen at the moment the wave was fired by the different guns

public boolean test(){
if (( this.vDistance+= (20-3*this.bulletPower) ) > this.vGunLocation.distance(enemyLocation)){
try{
if (vGuns[0]<absoluteBearing(this.vGunLocation,enemyLocation)+.5&&vGuns[0]>absoluteBearing(this.vGunLocation,enemyLocation)-.5)
vGunStats[0]++;
if (vGuns[1]<absoluteBearing(this.vGunLocation,enemyLocation)+.5&&vGuns[1]>absoluteBearing(this.vGunLocation,enemyLocation)-.5)
vGunStats[1]++;
if (vGuns[2]<absoluteBearing(this.vGunLocation,enemyLocation)+.5&&vGuns[2]>absoluteBearing(this.vGunLocation,enemyLocation)-.5)
vGunStats[2]++;
}catch(Exception e){out.println("*");}
removeCustomEvent(this);
}
return false;
}
</pre>
but it's not working.what ami doing wrong?--[[andrew]]

Are you using degrees or radians here? If degrees then .5 is probably too small, if radians then it's definitely too large. You could try using

<pre> if(Math.abs(Utils.normalRelativeAngle(vGuns[1] - absoluteBearing(this.vGunLocation, enemyLocation))) < Math.atan(18/vGunLocation.distance(enemyLocation)) </pre>

or something like it; Math.atan(18/enemyDistance) should be half the angular width of the opponent. Or you could just add the difference, or the square of the difference, between the predicted angle and the actual angle for faster learning. -- [[User:Jamougha|Jamougha]]

i don't understand what you mean by adding the difference. should this work:
<pre>

public boolean test(){
if (( this.vDistance+= (20-3*this.bulletPower) ) > this.vGunLocation.distance(enemyLocation)){
try{
double angle=Utils.normalRelativeAngle(absoluteBearing(this.vGunLocation,enemyLocation)-getGunHeadingRadians());
if (vGuns[0]<Math.atan(18/enemyDistance)+angle&&vGuns[0]>angle-Math.atan(18/enemyDistance))
vGunStats[0]++;
if (vGuns[1]<Math.atan(18/enemyDistance)+angle&&vGuns[1]>angle-Math.atan(18/enemyDistance))
vGunStats[1]++;
if (vGuns[2]<Math.atan(18/enemyDistance)+angle&&vGuns[2]>angle-Math.atan(18/enemyDistance))
vGunStats[2]++;
}catch(Exception e){out.println("*");}
removeCustomEvent(this);
}
return false;
}</pre>--[[andrew]]

Different subject, but does anyone check to see if an enemy bot dodges a bullet or not, so it can decide to fire VBs every turn at myfirstrobot and fire VBs only when fireing a real bullet at SandboxDT? I'm looking for example code for my bot.

Interesting question. I think it is very difficult to judge. The only way I can think of is what my grapher bots do. They keep different stats for "virtual" and "real" waves. Given enough data one could see if there is much difference between the two sets. But it takes a lot of data. Maybe if you do this in an otherwise unsegmented buffer for it... -- [[User:PEZ|PEZ]]

----

A Question on the speed of VirtualGuns, I have been trying to get my VirtualGuns to process fast but they just make my bot skip way to many turns. Is there any tricks to make my VirtualGuns go faster? -- [[User:KID|KID]]

What types of guns are in your VG array? Also, how are you storing them? Having a bunch of complex guns or storing them inefficiently seem to be the most likely reasons that would cause your VGs to slow down. A bit more info on your implementation would be useful for troubleshooting. --[[User:Wcsv|wcsv]]

Also, choosing 'the gun to fire' only 2 or 3 ticks before you fire and only calculating the angle to shoot those last few ticks can help. The rest of the time you can leave your gun in HOT- or LT-position. -- [[User:GrubbmGait|GrubbmGait]]

One problem I have always seen with VirtualGuns is how do you accurately select the proper gun to use against a specific target? Try this: do a TCChallenge with your VG array but store hit percentages with all your guns. When the Challenge is over, find the best gun and do the TCChallenge again but always selecting this gun and see if the results vary. I have always contended that a VirtualGun array was never going to be any better than your best gun. The very fact that you cannot accurately select your guns 1005 of the time would degrade the performance of this gun even. The best VG system in the game was in SandBoxDT. Paul never gave alot of clues about it, but from the words he used to describe it, one could gather that it would more and more finely segment your movement history, but it was always a GuessFactor gun (with some exceptions and I think only at very close ranges where HOT or LinearTargeting was almost garunteed to hit). The nice thing about this was you could use coarse segmentation early in an engagement to speed learning and as the match progressed get more and more refined. No one ever figured it out. Best gun in the game right now is the one in Shadow and it is not a VG or even a GuessFactor gun. Emulate that and you will have done something. It also has the benefit of being deadly to WaveSurfers. -- [[User:Sparafucil3|jim]]

For each of my guns I find every possible shot within 50 ticks-to-impact and compare the expected time to target against the historical hit percentage at that range, and keep the best 'firing solution'. Then I compare all of the gun's optimal firing solutions's and hit percentages, and use the best one among them. That means from shot to shot I may be using a different gun because I am closer or farther. I store these hit percentages for each range of each gun against each target. It's a lot of buckets. I generally have about a 3% skipped turn rate, which is not terribly alarming. -- [[User:Pedersen|Martin Alan Pedersen]]

Well to explain the situation that I’m in, first I’ll give the rundown on the class that came into play:

EnemyData - has all the data for a given enemy.
VirtualGun - one per robot and then per targeting type.
VirtualBullet - the bullets that I fire from my VirtualGuns.
Targeting - the interface that all my targeting class implement.

So, in each of my EnemyData class, I have an array of VirtaulGuns. For the constucter for a VirtualGun, I pass it my robot (AdvancedRobot), an enemy robot (EnemyData), and a targeting type (Targeting). I also create a bullet watcher condition class inside of the VirtualGun class that runs through my ArrayList of VirtualBullets. So then every turn I call the “update” method by give it the fire power of the bullet I want to fire. Then I add that VirtualBullet that I created in the “update” method to the ArrayList, and when my BulletWatcher class sees that a bullet as hit or missed, it removes the VirtualBullet from the list and ups the FIRED int, and maybe the HIT int. So then to find the best VirtualGun for a give enemy (EnemyData), I run through its array of VirtualGuns, and find the one with the best hit rate. (I can send anyone the src for my bos if you want, just send me an e-mail)

So as you can read, that’s a lot processing time for each bot on the field. That makes my bot skip a lot of turns (it was up to 60% one time for four enemys with four guns each). ANY help would be nice to have. -- [[User:KID|KID]]

In addition to Grubb's comment about only aiming before you're about to fire, I'd say you might try only shooting a virtual bullet when you're *actually* firing, instead of every turn. It will greatly decrease the amount of virtual bullets you're firing, as well as increase accuracy against bots that detect when you fire as a sign that they should dodge. Another general thought would be that you could increase the amount of guns as the number of enemy tanks decreases - like just use general targeting methods (eg, into a cluster of enemies) when the field is full of bots, and enable more advanced, individual VirtualGuns when you're down to 3 or less enemies. -- [[User:Voidious|Voidious]]

Well, I have about 8 guns calculating every possible shot within 50 ticks every round, and I track stats for 'virtual' bullets as well as virtual bullets fired in the same round as an actual shot. I'm only calculating a firing solution for one enemy in any given round, so duels vs. melee doesn't affect processing time. I'll estimate 20 possible shots per round per each of 8 guns comes to 160 virtual bullets generated and tracked every round. And it works with 3% skip rate. I'm invested a lot of time into my design, and evidently it has paid off. I remove each virtual bullet once its distance travelled has exceeded the distance from its origin to the target's present location. -- [[User:Pedersen|Martin Alan Pedersen]]

With all of these systems, can you garuntee you will choose perfectly? I was never able to accomplish it and in practice I found that my best gun was the one thats in [[Jekyl]]. I refined it in BlackPearl and solidified it in DarkHallow. It performs well in the TC but seems more susceptible to WaveSurfers that I would have liked. When I ran emperical tests with [[Jekly]]'s original VirtualGun system against a simple bot like SpinBot, I could not accurately choose the PM gun. I also tested a VG system against the target bot from the PatternMatchChallenge. Despite scoring almost perfectly with the PM gun, I could not re-liable pick and used the PM gun with a VG system. This is why I ask: Can you choose 100% accurately and are you sure you are not degrading your performance? -- [[User:Sparafucil3|jim]]

Well, no and no. Fortunately I don't need 100% accuracy and performance only has to be 'good enough'. If you pit [[Ugluk]] against [[SnippetBot]] or pulsar.[[Nanis]] you will see Ugluk's guns will lock on to the movement behavior and nail them. Ugluk's stats against them tell the tale. Against Spinbot or Walls, or any other bot that has a really pronounced movement tendency, Ugluk is going to become aware of it quickly and lethally. That only goes for linear, circular, and tangental oscillation, which are all independently handled guns. (I just added a pattern matcher but it is really raw and not a preferred gun.) If you have a pattern matcher that outperforms all of the simpler guns, by all means use it. I do not.

There is also the work experience / employment catch-22 with guess-factor guns. Until you start taking real shots you don't have data for your guess factor guns to use. So.. you can use some default like aiming at 0 degrees or you can prime your guess factor gun with results triggered by your simpler guns / pattern matcher. -- [[User:Pedersen|Martin Alan Pedersen]]

[[Category:Archived Talk]]

Virtual Guns/Archived Talk 20060129

2009-10-08T03:52:27Z

Robobot: moved Virtual Guns/Archived Talk 20060129 to Archived talk:Virtual Guns 20060129: move to talkarchive

#REDIRECT [[Archived talk:Virtual Guns 20060129]]

Archived talk:User:Tango 20090519

2009-10-08T03:52:25Z

Robobot: moved User:Tango/Archived Talk 20090519 to Archived talk:User:Tango 20090519: move to talkarchive

{{Navbox small
| title = Tango Sub-pages
| parent = Tango
| page1 = Archived Talk 20090519
}}

{{Talkarchive|User talk:Tango}}

'''News Flash: I'll be uploading a new bot tomorrow, it's not brilliant, but its much better than all the others i've made. I've been testing it today, i just need to come up with a name and i'll upload it. It was just a test bot to see how bullet dodging worked (hence its working name: Dodger), but it turned out to be better than i expected once i added a simple gun.'''

Cool! I suggest you name it [[Cassius]] after Cassius Clay (later Muhammed Ali). He was an excellent dodger with a remarkably effective punch. He can also provide your bot with a punch line (unavoidable pun): "Dance like a butterfly! Sting like a bee!" What kind of simple gun are you using? -- [[User:PEZ|PEZ]]

In fact, now when I have started to think about it, Robocode OneOnOne battles and boxing have very much in common. It's all contained in a rectangular arena. It's about the perfect combination of dodging and hitting. It's about power management. It's either about knocking your opponent out or making points. We could go on. You have a deep name space to pick names from as well. And all these boxers have produced more than one tag line you can use as well. -- [[User:PEZ|PEZ]]

Yeah, like Mike Tyson- "I can eat your ear, because I'm supposed to be the champion." -- [[User:Kawigi|Kawigi]]

Nice idea, but i'm not really a boxing fan, so i'll come up with something else. Thanks! -- [[User:Tango|Tango]]

Ok, i've thought of a name, its not very good, but then the robots not very good so it fits nicely. ;-) The robot is now called: [[Recrimpo]]! For more details see that page. -- [[User:Tango|Tango]]
----
Hi! I'm a complete novice to Java and Robocode, i have made a very simple robot, TangosBotV1, which will beat most of the sample robots but little else. I'm planning to make a robot using VirtualBullets and AntiGravityMovement as soon as I have the knowledge to do it, this robot is [[Deltan]].
----
Considering very view coders are working on dedicated team robots, i have decided that i will. I think this will give me a chance to do well, because there are less unbeatable teams out there. (A team of 5 times SandboxDT is a daunting challenge though...) I don't have a name for my team yet, any ideas will be welcomed. It will be designed so i can change how many of each type of robot there are, and it will still work. It will be focused around a shared hash of all enemies, all the robots with radars will add to it. This gives a lot of scope for pattern matching, if only i knew how to do it...
----
Welcome to Robocode land and to this wiki! I hope this wiki will help you come up to speed quicly with your next generation bot. My spontaneous advice when I see your plans forms a new section on the [[Beginners]] page. -- [[User:PEZ|PEZ]]

Thanks! I've just started work on my new bot, [[Deltan]], so I'll might have a few questions to ask soon. What is the best place here for random questions? -- [[User:Tango|Tango]]

Anywhere. Most often you can use the search function to find a place where the question fits best. And if not use the front page or the [[Requests]] page. -- [[User:PEZ|PEZ]]
----
Were you planning on putting [[Recrimpo]] or any of your Haikus you posted into the [[RobocodeLittleLeague]]? -- [[User:Kawigi|Kawigi]]

Maybe... they will lose... umm... ok, here's what i'll do. I'll ignore recrimpo because it is a terrible bot, and i will post a competative haikubot (the ones i've posted so far have been attempts at copying other bots, rather than real attempts to win battles) either tonight or tommorrow. How does that sound? -- [[User:Tango|Tango]]

Sounds great. I figure tomorrow night will be the deadline for season 1. -- [[User:Kawigi|Kawigi]]
----
Ok, [[User:Tango|Tango]] i have an idea. Having seen the way [[User:PEZ|PEZ]] and [[User:Jamougha|Jamougha]] have urged each other on, I've decided that i need a little head-to-head competition. I propose some kind of 2nd place brit competition, something along the lines of the old PEZCrippaLeague. Every week we have a OneOnOne battle to see who's the winner. What do you say?? -- [[User:Brainfade|Brainfade]]

I'm on half term at the moment, so I should have time to fix whatever is wrong with my GF gun. If I can do that, then I might be able to challenge you. What place is your top bot in the rumble so far? Are you thinking megabots, or size restricted? My current bot is mega, but I am considering getting it down to mini if I can get it to work. -- [[User:Tango|Tango]]

Interesting. The PEZCrippaLeague really kept [[Crippa]] and me on our toes for a long while of our early Robocoding. Yes, find someone competetive around your own current level and start competing. That will surely accelerate your advancement. Another thing to remember is that Robocode competition below the top 2 bots are still rather simple. [[Raiko]] proves this. Bug frequency is a major parameter I think. And to get that I can very much recommen tests. Got a GuessFactorTargeting gun that performs sub 85% in the TargetingChallenge? It probably has a bug or you're not segmenting it very well. -- [[User:PEZ|PEZ]]

I don't have an entry at the moment, and i'm keen to get one sorted asap. I would much prefer Megabot's as i've never tried restricted codesize, and my code is really wooly. Besides, the bot i'm working on is way over a mini and it doesn't work yet. If you've got some time, work on your bot, and give me an answer when you've decided... --[[User:Brainfade|Brainfade]]

Well, I've found the problem with my bot, I just need to work out how to fix it (I've posted the problem on the GuessFactorTargetting/Tutorial if you want to offer any advice). It's a very simple bug, so I should have a working bot very soon, so I will take you up on your challenge. May the best bot win! -- [[User:Tango|Tango]]

Well, now you've got a working gun, i'd best put some graft in. I'm gonna need this week to put it together (I'm a notoriously slow worker) so shall we schedule teh first run for next week?? -- [[User:Brainfade|Brainfade]]

How about next Sunday, then I have the whole half-term to work on it (or should I be doing homework... nah)? I'm just running my new gun through the TargetingChallenge, so we'll see how well it works... -- [[User:Tango|Tango]]

79%.... according to PEZ that means there is something wrong... it could just be the segmentation (simple distance segmentation at the moment), or it could be annother bug... I'll put it together with some movement, and see how it fares in the RR@H. I guess it can't do much worse than the current version... -- [[User:Tango|Tango]]

That got to 148, but i've added data saving now, so hopefully it will go up more. -- [[User:Tango|Tango]]

79% with distance segmentation only sounds like it is working. -- [[User:PEZ|PEZ]]

That's what I thought. Once 2.51 has stablised, I'm going to start testing some segmentation. My first thing is going to be an aceleration/deceleration axis, i think. I'm not quite sure why, but i've got to start somewhere, and my gut feeling is that will be quite useful. -- [[User:Tango|Tango]]

Hey Tango, just curious, you've been here for a long time and you're very active, so why do you only have one bot?

Because I'm one of the worst coders known to man! I am working on a bot that seems to be working quite well. I might even release it this week. -- [[User:Tango|Tango]]

[[Category:Archived Talk]]

User:Tango/Archived Talk 20090519

2009-10-08T03:52:25Z

Robobot: moved User:Tango/Archived Talk 20090519 to Archived talk:User:Tango 20090519: move to talkarchive

#REDIRECT [[Archived talk:User:Tango 20090519]]

Archived talk:User:Pulsar 20050722

2009-10-08T03:52:23Z

Robobot: moved User:Pulsar/Archived Talk 20050722 to Archived talk:User:Pulsar 20050722: move to talkarchive

{{Navbox small
| title = Pulsar Sub-pages
| parent = Pulsar
| page1 = Archived Talk 20050722
}}
{{Talkarchive|User talk:Pulsar}}
!

What?

It wasn't me writing that exlamation mark. But whoever did probably meant it as a PromptingStatement. -- [[User:PEZ|PEZ]]

Hehe ok, I should start coding on my robot instead of writing something not many are interested in ;-)

Lots and lots of people are interested to know at least some about anyone making bots. Making top-20 bots doesn't make you less interesting =). -- [[User:PEZ|PEZ]]

Indeed. Counting [[User:PEZ|PEZ]], there are, at least, two people interested on what is "made of" that top 20 new bot :). The concept behind the wiki is (i think) the sharing of ideas and knowledge, and the bots pages are not only a good source to others getting inspiration/ideas from you, but also a place to receive feedback (post help requests, receive spontaneous comments, etc..). -- [[User:Axe|Axe]]

Well yes that I understand, but that is more for the PulsarMax page I guess? I only have one bot in the RoboRumble so this page wouldn't be very interesting for now. -- [[User:Pulsar|Pulsar]]

Now at least there's a page when one clicks your name in the [[Changes]] list. =) -- [[User:PEZ|PEZ]]

That's more like it. =) -- [[User:PEZ|PEZ]]
----
Although it's not really the right place to ask - what on earth is java reflection?? Everyone i ever asked looked at me as if it were a dirty word... --[[User:Brainfade|Brainfade]]

Reflection is a way to "look inside" java objects and classes. Check http://java.sun.com/j2se/1.3/docs/api/java/lang/reflect/package-summary.html for a somewhat dense introduction. Also look at [[User:Nano|nano]]'s StatGrapher, which is using it to do its magic. -- [[User:PEZ|PEZ]]

(edit conflict!) As far as i know, java reflection is something that allows the java code to "look inside" itself. Using this API, u can for example, list the names and parameters methods and attributes of a class (also execute methods using the Introspection). A little example that lists all the methods of the String class:
<pre>
import java.lang.reflect.*;
public class ReflectionTeste {
public static void main(String args[]) {
try {
Class c = Class.forName( "java.lang.String" );
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++) {
System.out.println( m[i].toString() );
}
} catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>
But i have no idea how Pulsar could use this in robocoding, it would be interesting to hear something about... -- [[User:Axe|Axe]]

I use it for the guess factor targeting so I can easily redefine them and create new ones. I guess a more advanced version would do more magic.
<pre>targetings[0] = new GuessFactorTargeting(new int[] {8, 1, 3, 3, 3, 1, 1, 1, 1, 5, 1, 2, Settings.TARGETING_GUESSFACTORS});</pre>
note the int array, that defines the dimensions of one of my guess factor targetings (1 means I don't use that segment, with reflection I could remove even those but that just makes it hard to know which index is which so I don't do it ... yet... ). So for now it's just for development purposes, if I come up with a new segment I just add a number ion the above example and implement the calculation of the index in one place, done. No need to change code here and there to use one more dimension etc. I'm not using this for wave surfing (maybe later). It has one drawback, I haven't implemented a way of easily saving all that data effeciently yet. Just serializing it all takes 100kb or so per enemy compressed!! -- [[User:Pulsar|Pulsar]]

In [[Robocode]] u have 200K of space for saving data. If you r thinkin about saving data, in that kind of environment, serialization is far to be acceptable (even with [[CompressedSerialization]] - take a look at that page!). As u know, serialization is an easy-use API for persistence stuff, the problem is that easy-use cost a price: size. So we are all back to the radio-shack age, 200K for 260+ enemies... The solution that is usually adopted is to save that data compressed (like in [[CompressedSerialization]]), and give up the data "precision". As an example, i use [[Paul]]´s rolling average formula to rate my WaveSurfing segmented GFs. That kind of formula is suposed to give to me a double with something between 0-1 in each bin, when saving, i use only one byte for each bin, by a simple conversion to byte within a range 0-100. Bellow is the code that i use (nicely cleaned :):
<pre>
public void save(String name) {
try {
GZIPOutputStream zipout = null;
DataOutputStream w = null;
zipout = AxeFiles.getGZipOutputStream(name
+ AxeFiles.GFS_FILE_EXTENSION);
w = new DataOutputStream(zipout);
System.out.println("saving numAllHits=" + numAllHits);
w.writeByte((byte) numAllHits);
for (int i = 0; i < GF_QT; i++) {
w.writeByte((byte) Math.round((allHits[i] * 100)));
}
for (int j = 0; j < DISTS; j++) {
for (int k = 0; k < VELS; k++) {
for (int l = 0; l < ACCS; l++) {
for (int m = 0; m < BULL_PWR; m++) {
w.writeByte((byte) numHits[j][k][l][m]);
for (int i = 0; i < GF_QT; i++) {
w.writeByte((byte) Math
.round((hits[j][k][l][m][i] * 100)));
}
}
}
}
}
w.flush();
zipout.finish();
w.close();
} catch (IOException e) {
AxeBot.getIt().out.println("IOException trying to write: " + e);
}
}

public void load(String name) {
DataInputStream r = null;
GZIPInputStream zipin = null;
try {
File f = AxeFiles.findFile(name + AxeFiles.GFS_FILE_EXTENSION);
zipin = new GZIPInputStream(new FileInputStream(f));
r = new DataInputStream(zipin); //new FileInputStream(f));
numAllHits = r.readUnsignedByte();
System.out.println("loading numAllHits=" + numAllHits);
for (int i = 0; i < GF_QT; i++) {
allHits[i] = r.readUnsignedByte() / 100D;
}
for (int j = 0; j < DISTS; j++) {
for (int k = 0; k < VELS; k++) {
for (int l = 0; l < ACCS; l++) {
for (int m = 0; m < BULL_PWR; m++) {
numHits[j][k][l][m] = r.readUnsignedByte();
for (int i = 0; i < GF_QT; i++) {
hits[j][k][l][m][i] = r.readUnsignedByte() / 100D;
}
}
}
}
}
} catch (Throwable e) {
AxeBot.getIt().out.println("IOException trying to read: " + e);
} finally {
try {
r.close();
zipin.close();
} catch (Throwable e2) {}
}
}
</pre>
That code was extracted from [[SilverSurfer]]´s code, it is open source i there is any method that u want to seek (but i warn u: it is a messy code:). 
This data saved (I use a segmentation of 3X5X3X1 and 97 bins = 4365 bins) compressed costs me ~400 bytes per enemy. -- [[User:Axe|Axe]]

I think that without some CribSheet thinking on Pulsar's GF structures it will never be able to store more than 10 or so enemies in the 200K limit. But fast learning techniques might gain more than data saving anyway.

I still don't quite understand how the Reflection above is applied though. Think you can post some more code snippets [[User:Pulsar|Pulsar]]?

-- [[User:PEZ|PEZ]]

Thanks axe! I'm in no way going to do serialization of course but it is the quickest way to start with data saving. :) At work we usually do sort of a poor mans serialization for example (not even using externalizable but instead predefining a number of identifiers and then saving bytes our selves, so we sort of still keep the object-oriented stuff but have a minimum of data transfer needs) when we send stuff over the air (satellite, GSM SM, GPRS etc). I'm currently not using any rolling averages, I did so in my last bot though, thinking of trying it again, if so the above seems very nice! If I'm not using rolling averages (which I probably should start doing again) I was thinking of representing each double as a byte, with sort of an exponential mapping range. Anyway, I am indeed of course going to save some sort of byte array (whatever it represents) byte by byte instead.

Well Pez you will be amazed what knowing a few things about your data can do for your data saving needs ;-) Hm ok guess that's what you mean by crib sheet actually. I was more thinking along the lines of a byte represents 256 different possibilities and we want to use them all in a smart way, doesn't have to map directly to a guessfactor stat for example, maybe even predefine profiles, (probably a bad idea), but predefining and/or mapping things is usually effective. Quick learning indeed seems like more fun/challening though so this data saving is not a priority for now! Dynamic segmentation, thinking of automating it somehow with a few parameters here and there and then plug it in with the GF targeting and wave surfing.

For short, thanks both for again putting ideas into my head, and yes indeed bytes not serialization is the way it will be done, with a cribsheet eventually, and hopefully something even smarter, sometime... Maybe at least have different amounts of information per enemy. Dynamic data segmentation will help quick learning though as Pez says and that will fun to work out! :)

I will try and explain it further and with examples this evening maybe Pez. I should work now! So many ideas, so little time :) -- [[User:Pulsar|Pulsar]]

Ok Java reflection and guessfactors. Let's say you decide on anumber of segmentations for you guessfactor targeting/movement and come up with the following:
<pre>double[][][][] factors = new double[DISTANCE][VELOCITY][ACC][WALLS][FACTORS];</pre>
All is well, you write your code, get it all to work etc. Then one day you decide you would like to experiment/add/remove some segmentations. Youimmediately face a problem if you are passing around the <code>factors</code> variable, storing per enemt etc etc you have to change your code it in quite a few places. For short you can't declare an array with at runtime decided number of dimensions (just the size of each dimension). Or even simplier if you have a compile-time decided number of dimension but want to change it you have to change all your source code referring to it. Java reflection let's you do that in an easy way though. I'm just using this for targeting right now and for experimenting around with them. To make it easier I have a set number of dimensions decided at compile time actually, makes it easier to handle all possible indexes for now. I just set the ones I don't want to use to 1. The other ones I can generally pick whatever I feel like (the index calulators I have for a segmentation can handle arbitrary number of indexes in general) But it makes it extremely easy to add segmentations because only the declaration of the guess factor targeting needs updating (and the calculation of the index of course). No a big issue for non-mega bots I guess, but PulsarMax weighs in at around 20 classes now and I try to separate things in to methods here and there and not duplicate code. Global variables are bad too :) I'll add a code example or two when I get home.
-- [[User:Pulsar|Pulsar]]

* Ah....I remember fondly the days of my coding ideals. No byte saving techniques. Crisp clear code. Everything commented. Yes I remember it like it was yesterday. Then I started to write [[MiniBot]]s. Now all of that is gone. Come to the dark side, Luke. Your anger makes you stronger. =^> -- [[User:Sparafucil3|jim]]

* You might consider looking at the FloodGrapher robot to see one way of using reflection and organized classes to have a variable-dimension stats array. -- [[User:Kawigi|Kawigi]]

** Bah and I who thought I was first in robocode to do that. :-) -- [[User:Pulsar|Pulsar]]
** Ah ok you use it to load configured classes (reflection to find the constructors). Anything during the fights? I was more thinking of doing it on the fly later on. What I'm doing right now could as well be done using a List with Lists as elements, but then I would need to convert back and forth between Objects and primitives all the time (until Java 1.5). I'll explore all this more when I have gotten to the pint when it is time for dynamic data segmentation of some sort. -- [[User:Pulsar|Pulsar]]
*** Well, an early version of FloodHT tried every possible combination of segmentations, too, and did so fairly efficiently, if I do say so... But this also led to an obscene number of VG's (especially since I had another 5 or 10 aside from that, for a total of almost 30). And it wasn't very good. I swapped it out when I made a version of FloodMini that was clearly better than it, and made the current version which is quite similar to FloodMini as far as functionality. -- [[User:Kawigi|Kawigi]]
****Although people have suggested otherwise, i can't see (other than the problem of choosing between them, and possibly excution speed) how having loads and loads of virtual guns could be a disadvantage, surely you just eventually you just end up using a gun, or a small selection of guns against a particular bot. Is it just that it hampers you over short battles, and that you cant save all your data?? if so you surely just save the data on either which guns are better, or just save the data on the best gun(s) --[[User:Brainfade|Brainfade]]
*****I think the problom is to always select the best gun ([[User:PEZ|PEZ]] correct me now If I'm wrong). It's not as easy as it seems. One can only emualte the gun not currently used with for example virtual waves. But an enemy that is adapting its movment depending on where it gets hit for example might screw up all those stats. Just one example. So basically you would have to run a couple of matches with each gun. I still think it can be of use though, especially against a big majority of the enemies. :)
****** Actually, while on paper it looks good, in practice it doesn't work even if your enemy isn't adapting its movement or even attempting to dodge your bullets. I think the problem is that the "best gun" you'll pick is always the one you should have picked before, not the one you should pick now (because you pick the gun based on past performance, and you can't pick it based on future performance). I experimented with a lot of virtual guns and with a few virtual guns, and the obvious result was that against any enemy, the results were not as good as they would be with the best gun. The less obvious result is that if I have several solid guns that aren't especially specialized (i.e. say two guessfactor guns or a GF gun and a PM or something) that the ''overall'' performance is less than ''either'' of the original guns, although the performance against certain bots for which one is clearly better than the other may be more in-between (not worse than the worse gun against that robot). So it could be argued that you can exchange performance for less specialization. -- [[User:Kawigi|Kawigi]]
 

----

Congratulations! A really nice picture that too. -- [[User:PEZ|PEZ]]

Thanks, a friend was playing around with the picture stuff, not me though, so the credits go to her, but still working on it :) -- [[User:Pulsar|Pulsar]]

Pulsar, do you remember the days that you signed your postings with something like "/Pulsar, who will someday enter a bot to one of the competitions and get badly beaten :) ". (see http://www.robocoderepository.com/jive/thread.jsp?forum=6&thread=487&start=15) You are no. 4 right now and beating us badly! --[[User:Loki|Loki]]

Hehe, I remember that indeed! Thanks for bringing a smile to my face! At least I started out by solving a problem :) I'm only no. 6 right now though I think, but got lots of things to do before giving up, "only" need some more spare time!! Anyone selling some? I barely have time to chat about robocode with [[User:PEZ|PEZ]]! Finding one of those things collectively known as [[SignificantOthers]] didn't help... ;-) --[[User:Pulsar|Pulsar]]
* i am glad i made your day :-) --[[User:Loki|Loki]]

PulsarMax ''does'' get badly beaten by all surfers though. =) -- [[User:PEZ|PEZ]]
* and by bots featuring a PM-gun (like eg. Fenrir). But those bots are a problem for all WaveSurfers... --[[User:Loki|Loki]]
* I disagree. If you sort a PM-bots details sheet you'll find that it will have surfers as its worst enemies. Don't confuse PBI with problem. -- [[User:PEZ|PEZ]]

[[User:PEZ|PEZ]] you always find something to say to motivate me... By the way, the wallseg stuff and some accidental smoothing in the gun, wasn't the problem, it helps, but not all the way. Bleh. But if this all was easy where would the fun be? --[[User:Pulsar|Pulsar]]

[[Category:Archived Talk]]

User:Pulsar/Archived Talk 20050722

2009-10-08T03:52:23Z

Robobot: moved User:Pulsar/Archived Talk 20050722 to Archived talk:User:Pulsar 20050722: move to talkarchive

#REDIRECT [[Archived talk:User:Pulsar 20050722]]

Archived talk:User:Nano 20090519

2009-10-08T03:52:21Z

Robobot: moved User:Nano/Archived Talk 20090519 to Archived talk:User:Nano 20090519: move to talkarchive

{{Navbox small
| title = Nano Sub-pages
| parent = Nano
| page1 = Archived Talk 20090519
}}
{{Talkarchive|User talk:Nano}}
It took a year before anyone corrected that spelling on the ReadMe page. I'd say that we now have taken the next step in wiki-land. =) -- [[User:PEZ|PEZ]]

Wall smoothing is heavily dependent on your implementation of movement. How to do it for an orbital movement that selects direction and angle of attack is completely different from a movement that selects points. One good example is in [[RandomMovementBot]]. The general principle is to translate your point of impact back inside the acceptable battlefield, head to it, translate the subsequent point of impact, and so forth until you're perpendicular to the wall. -- [[User:Kuuran|Kuuran]]

I suppose that that is the algorithm for WallSmoothing if using a go-to movement, however, most rotation is done per tick (in an attempt to stay perpendicular to the enemy), and in this case it becomes impossible to merely translate the point of impact. When I attempt something like this, I have problems with bouncing back and forth between two angles (the one inside the battlefield and the one perpendicular to the enemy). Has anyone had this problem and developed a good solution? -- [[User:Nano|nano]]

As I said, [[RandomMovementBot]] has something like this. But when you adjust to the new angle aiming at inside the battlefield you should still be headed for a wall collision, that's not actually gone until you've come parallel to the wall. Ensure that your normal movement code can't assert it's angle if there is wall collision impending and ensure that you're aiming for the legal portion of battlefield closest to the point of impact and you shouldn't be having this problem.

[[RandomMovementBot]] closes on the enemy if a wall collision is impending and moves away from the enemy at all other times to achieve the smoothing effect. It just sets an optimal distance and shrinks it until it's projected movement isn't leaving the battlefield. The turn to close to the distance from the enemy that's still inside the battlefield (basically the distance between the enemy and the wall) is also the turn required to just miss the wall, for obvious reasons. Either method should provide the results you're after.

-- [[User:Kuuran|Kuuran]]

"When you adjust to the new angle aiming at inside the battlefield you should still be headed for a wall collision." This just doesn't make sense, unless by "headed for a wall collision" you mean "aimed toward a wall", which is always, of course, true. If you translate some line projected in front of your bot to be inside the battlefield, it follows that that line is now inside the battlefield, and thus by definition, you are not headed for a wall collision. Thus the next tick will not use the correction as it should, and will instead rotate into the wall (to be more perpendicular to the enemy). This oscillation between the two angles is evident in all three of my attempts at real-time WallSmoothing (that is, not using goTo). It is obviously just a bug in my code (or perhaps a flaw in my approach), but I will look into this again in a few days. For tonight I am running the TC again with a new stat segmentation algorithm. My fingers are crossed. -- [[User:Nano|nano]]

There's nothing in RandomMovementBot's WallSmoothing approach that depends on a goTo() function. I just happen to use goTo() to give the right setAhead() and setTurn() commands, implementing BackAsFront while at it. RandomMovementBot uses an orbital movement approach that could do very well without the goTo() for driving around. What RandomMovementBot assumes is that its enemy is inside the battle field. A reasonable assumption, in'it? =) -- [[User:PEZ|PEZ]]

Obviously your approach is wrong. I don't see why you're so hung up on goTo(), as PEZ said, but anyway, if you translate your destination inside the battlefield all you're doing is wall avoidance. When you head for the point nearest the point of impact unless your angle of approach was extremely shallow you're still going to be heading for a wall collision, just at a slight delay, until you've finished the smoothing and are riding the wall. Prevent the perpendicular to your opponent angle from asserting itself while this is happening and project your movement before applying the select change in angle (after picking the angle before putting it into setTurnRightRadians() or whatever use that angle to project if you're going to have to smooth with it, and do so before it asserts itself). -- [[User:Kuuran|Kuuran]]

You could regard RandomMovementBot's way of doing WallSmoothing as a flexible "blind mans' stick" with a little wheel at the end. RMB is sticking out this stick in the direction it wants to move. When the stick hits the WALL_MARGIN it "folds" and "rolls" towards the enemy until it has room to extend to its full length. Then the bot moves there. Does this make sense? It is how I came up with the technique to begin with. -- [[User:PEZ|PEZ]]

Yes, that's the approach I am using (projecting a "stick" in front of my bot and translating it inside the battlefield). I will look at RandomMovementBot's code more closely and see how I can translate it to my code. Thanks much for the help! It sounds like this is much easier than my failures at coding it had led me to believe. -- [[User:Nano|nano]]

Just making sure it is clear; RMB does no translation of the destination point. It just iteratively moves the end of the stick closer and closer to the enemy until the stick end is inside the battle field (with some margin). I think this is much better than translation. Like Kuuran says, that's just WallAvoidance, not WallSmoothing. Check [[Tityus]] movement code for a way to control just how much smoothing you dare do. -- [[User:PEZ|PEZ]]

Yes, that is the idea I meant to communicate. My first attempt did do this "translation" by mathematically translating the point instead of iterating over closer and closer angles, but my current attempt follows the pattern you describe. Hopefully I can get this fixed by the end of tonight so that I can move on to more interesting things. :) -- [[User:Nano|nano]]

Thanks for the help again, and the firm bludgeoning! After reading Raiko and RandomMovementBot's wall-smoothing code I finally got mine to work. My problem? I had a bug in my getAngle function (to get the absolute bearing between two points), in that it did not return Robocode angles. That didn't matter for my stat gun, but it mattered everywhere else. Now Unnamed's movement is siiilky smooooth. I also implemented a neat bullet-power selection algorithm and my patented segment-balancing algorithm (which actually only helps my aim a very little bit, but it does help). Next step: some semblance of a good movement. I may try a little CoolMovement + adaptive movement, we'll see if I can get anything to work. -- [[User:Nano|nano]]

[[Category:Archived Talk]]

User:Nano/Archived Talk 20090519

2009-10-08T03:52:21Z

Robobot: moved User:Nano/Archived Talk 20090519 to Archived talk:User:Nano 20090519: move to talkarchive

#REDIRECT [[Archived talk:User:Nano 20090519]]

Archived talk:User:Kev 20090516

2009-10-08T03:52:19Z

Robobot: moved User:Kev/Archived Talk 20090516 to Archived talk:User:Kev 20090516: move to talkarchive

{{Navbox small
| title = Kev Sub-pages
| parent = Kev
| page1 = Archived Talk 20090516
}}
{{Talkarchive|User talk:Kev}}

Greetings, fellow washingtonian! Cheers from the land of Coupeville, on Whidbey Island. --[[AaronKrill]]

Welcome and congrats with the melee-ranking of Logic! It's quite an entry for a first robot. You can request a flag for your package over [[RoboRumble/CountryFlags | here]]. B.t.w. what does "ninth grade student" mean in terms of age? --[[User:Loki|Loki]]

Thanks! If I was addicted to robocode earlier, you should see me now! I acutally requested for a flag for the "kc" package when I submitted my robot. Sorry for being unclear about "grade", I'm really 15 years old. --[[User:Kev|Kev]]

I wish Robocode was around when I was in [[High School]], but that was in another century. --[[User:Pedersen|Martin Alan Pedersen]]

thanks for the explanation! I keep learning new things at this site, robocode related and not. --[[User:Loki|Loki]]

----

I have a problem with robocode causing robocode to freeze, making running long tests impossible:
* Robocode doesn't print any error messages. It just stops working.
* It only happens when robocode is minimized or running very fast.
* It crashes seemingly at random, but it happens more often with slow bots.
* When the screen is minimized and I maximize it, the whole screen is grey; there isn't even a frozen picture of the battle.
* This only seems to happen on my computer (I can run the same battles on school computers without any ill affect)
* I'm using robocode version 1.0.7.

Has this happened before? Do you have any suggestions? Your input would be greatly appreciated. -- [[User:Kev|Kev]]

That's very strange. Sorry, but I don't think i've seen that happen before. --[[User:Wcsv|wcsv]]

Does your computer have more than one CPU? -- Martin

It has only one CPU, but its duel core. If this helps, it is specifically a "pentium D processor 820 with duel core technology" (2.80 GHz, 800 FSB). -- [[User:Kev|Kev]]

Try this: Launch Robocode. Bring up Windows Task Manager (crtl+alt_del) and click on the Processes tab. Right-click 'cmd.exe' or 'java.exe' and see if it gives you the option 'Set Affinity...'. If it does, you've got 2 cpu's, and you need to set the Robocode related stuff to use only one. I set cmd and java to use cpu 0 for one, and I run another instance (from another drive) set to cpu 1. I have to set all 4 processes every time I set it up. There are ways around this, but I don't know them and don't want to invest further research into it. -- Martin .. Edit: Just to clarify, I'm describing how I set up the Roborumble .. I usually don't bother with it for the Robocode client since it is seldom a problem. -- Martin

That is indeed the case, robocode works no problem now. Thank you a whole lot!!! -- [[User:Kev|Kev]]

Another possibility is to use [[User:Kawigi|Kawigi]]'s version of v1.0.7, he solved the hyperthreading bug there. You can find the link and a description of the changes (also improved editor) on [[OpenSourceRobocode/Contributions]]. -- [[User:GrubbmGait|GrubbmGait]]

----

After PEZ blocked the recent vandalism attack, my computer, ID = 5989, can't edit pages (I'm sneaking on a school computer to post this). Could PEZ undo this please? -- [[User:Kev|Kev]]

Entirely sorry about that dude. I guess I must have blocked the wrong IP. Do you know what IP range you're using? -- [[User:PEZ|PEZ]]

No problem, the IP address is 24-19-160-72. -- [[User:Kev|Kev]]

I can't find that IP in the block list. Maybe it's one of the name blocks. What's your provider's name? -- [[User:PEZ|PEZ]]

Bizarre... I can edit pages now! Whatever the cause, there's no need to worry about it any more. -- [[User:Kev|Kev]]

I removed a block on comcast.net. Maybe that's your provider? -- [[User:PEZ|PEZ]]

It is, thanks PEZ! -- [[User:Kev|Kev]]

----

Is anyone interested in (yet another) challenge? I was thinking a melee movement challenge similar to the [[RRGunChallenge]] would be very interesting. Entrants would hook their movement to a melee gun (maybe [[Coriantumr]]'s or even [[HawkOnFire]]'s) and then enter it in the rumble. Melee movement is much harder to evaluate than one-on-one movement, so the challenge could be useful in making sure you movement is up to par. -- [[User:Kev|Kev]]

Sounds like a really good idea. I've wondered about doing this for 1v1, too, actually. I know HawkOnFire is just HOT, plus whatever logic for choosing a target and bullet power. Why don't you go ahead and get the page and everything setup? =) -- [[User:Voidious|Voidious]]

Indeed an interesting idea. I don't know if it is as transparant though as the RRGC, because the coupling between movement and gunnery in melee is a lot tighter (e.g. current enemy to target can also be of influence in movement). But there is only one way of finding out: starting the challenge! -- [[User:GrubbmGait|GrubbmGait]]

Done! See the rough version of the [[MRMovementChallenge]]. -- [[User:Kev|Kev]]

----

Hey Kev, you're from Washington? So am I. What city do you hail from? -- [[Krillr]]

I'm from Sammamish (right next to Issaquah, not far from Seattle). I actually visited Coupville a couple of weeks ago while camping at Whidbey. You have very nice island there :). -- [[User:Kev|Kev]]

Its not bad to visit, but unfortunately living here is an absolute bore. Especially when you're used to the up-beat life of Seattle. I moved here from Seattle 3 years ago. -- [[Krillr]]

----
Was is your intention to remove MaxRisk while adding [[Thorn]]? It still is the best rammer in the rumble. 
You are really starting to dominate bytheway: nr1 in nano, micro and TwinDuel, top-5 in mini and melee, and top-20 in OneOnOne. Maybe a sort of 'domination-ranking' (thanx for that name [[Martin_Alan_Pedersen|Martin]]) should be made, where all 10 results (4 OneOneOne, 4 Melee, TwinDuel, Teams) are listed and totally ranked. -- [[User:GrubbmGait|GrubbmGait]]

* Hmm, then would that person be [[History/KingsOfRR|King]]? I better get to work... =) -- [[User:Voidious|Voidious]]

Yep, I did mean to take [[MaxRisk]] out of the rumble. It's old and leaving it in is not really doing any bot favours :). I guess a 'domination-ranking' would be cool, but you're the only robocoder I can think of with entrants in all competitions [[User:GrubbmGait|GrubbmGait]]. I can't really see how the system would work... -- [[User:Kev|Kev]]

You're right, there are not much robocoders with entries in more than 5 classes, and besides, there is already something like TheBestBot. My idea was just to count the dominationpercentages (first meaning 100, last or no contribution meaning 0) and the one with the highest total would be the Dominator or Dictator. -- [[User:GrubbmGait|GrubbmGait]]

Two totally separate comments coming here... First, anybody with a NanoBot automatically has a bot in every division for this type of ranking, and if it was just an average of domination percentage, there really might be some surprises in who ranks highest. If somebody had no entry in a division, they could just get 0, and still have a chance at the highest overall domination. Doesn't [[User:Kawigi|Kawigi]] have at least one bot in every division, too?

Next comment: [[User:Kev|Kev]], what are you working on now? You've got the NanoBot and MicroBot thrones... You going for the MiniBot title? Getting WaveSerpent in the top 10 in 1v1, or top spot in melee? Or are you going to finally try to reclaim the TwinDuel title? (LuminariousDuo has been getting most of my attention lately...)

-- [[User:Voidious|Voidious]]

You're right, [[User:Kawigi|Kawigi]] has entrants in all devisions of the rumble too. I think he would be the clear winner of a domination-ranking contest, but it might still be interesting to look into. Right now, I'm developing a pretty cool [[PatternMatching]] gun with a lot of new ideas. It's already getting around 84 on the [[TargetingChallenge2K6/FastLearning]], and I haven't even started working with [[MultipleChoice]] yet. This might turn into a melee gun good enough to get [[WaveSerpent]] into contention for the top melee spot.

Besides that, I have tons of other things I wand to do, like try to get [[Vyper]] up to [[The2000Club/Mini]], re-writing [[WaveSerpent]]'s movement, and improving [[GeminiTeam]]... I just don't know what order I'll do it in :). -- [[User:Kev|Kev]]

Hey [[User:Kev|Kev]] i was just wondering how the plugin your making for Yoda's beta-testing stage is comming along or if you needed any infomation, my project is due on June 1st, so i need what ever you've made a bit before then, you dont have to get very advanced with
it, i mainly need feedback about the plugin-system. Thanks -- [[Gorded]]

Yay! Kev is back! You've missed some action on your hiatus, there, Kev. -- [[User:Simonton|Simonton]]

Hi Kev, welcome back :) Your new WaveSerpent is really slow and it consumes a lot of Memory! --[[User:Krabb|Krabb]]

Good to see ya back, Kev. =) -- [[User:Voidious|Voidious]]

Quick [[User:Simonton|Simonton]], we have to take the MicroRumble before he notices ;-). -- [[User:Skilgannon|Skilgannon]]
* Ok, let's do it. We won't tell a soul until it happens! --[[User:Simonton|Simonton]]

Thanks guys, it's great to be back! Good luck with your, erm, secret takeover [[User:Simonton|Simonton]] and [[User:Skilgannon|Skilgannon]] (although I'll try not to make it easy for you :). -- [[User:Kev|Kev]]

[[Category:Archived Talk|User:Kev/Archived Talk 20090516]]

User:Kev/Archived Talk 20090516

2009-10-08T03:52:19Z

Robobot: moved User:Kev/Archived Talk 20090516 to Archived talk:User:Kev 20090516: move to talkarchive

#REDIRECT [[Archived talk:User:Kev 20090516]]

Archived talk:User:Iiley 20090430

2009-10-08T03:52:17Z

Robobot: moved User:Iiley/Archived Talk 20090430 to Archived talk:User:Iiley 20090430: move to talkarchive

{{Talkarchive|User talk:Iiley}}

Hey, [[User:Iiley|iiley]] - I have a question for you. If I have a bot in test that seems to do real well (about even) against [[Cigaret]] and [[CigaretBH]], but gets beaten really hard by [[Smoke]], what could that mean? What is my weakness? -- [[User:Kawigi|Kawigi]]

Oh,[[Smoke]],a old bot of mine,current version of [[Cigaret]] have a fault in fact,you may have seen it did very hard to beat [[Shera]],but the old versions eg 1.10 can beat it easily,What the differences?I think i cannot tell why it when i have not improved it,Although if you watching the performance of Shera you will konw.[[Smoke]]'s movement is similar to old [[Cigaret]]'s,so...I think its the same reason to your bot.You can have a try to the old version of Cigaret.The Point I mean the movement,[[Smoke]]'s movement is similar to Old Cigaret's.But all i said is my problem,sorry,your problem,your bot's weakness(how to improve you bot to beat Both Cigaret and Smoke),I have no idea,But i think you have to improve you bot's movement.(maybe you can send you bot to me,let me have a look ;]) -- [[User:Iiley|iiley]]

I think it sounds like Kawigi needs to improve the gun. -- [[User:PEZ|PEZ]]
----
Hey iiley, you removed CigaretST, [[Ash]] and [[Yager]] from the RR@H. I can see why Yager would like a melee rumble, but the other two didn't exactly embarass themselves! Are you moving the test code from them into a new monster? -- [[User:PEZ|PEZ]]

Yes,I will release a new bot based on CigaretST,but it is not a monster,it cannot beat Neo and [[VertiLeach]],but it can beat DT in 1000 rounds in my testing~;],i learned some from Andrew's Neo,so i removed CigaretST,and i removed [[Ash]] because I think i need to removed some old and not very good bot. --[[User:Iiley|iiley]]

To me anything involving tobaco is monstrous. =) Good that you beat DT with it. Paul wanted the RoboRumble/PremierLeague to be some challenge to him. I can tell you how to beat VertiLeach as long as you don't tell anyone and don't use it in a mini. You know my e-mail address. =) -- [[User:PEZ|PEZ]]

I released it,named [[Lacrimas]],It seems that the rumbles use short rounds battles,it is not advantaged for [[Lacrimass]] it learn slowly.~;[ and... I send a email to you PEZ. -- [[User:Iiley|iiley]]

What? VertiLeach has a flaw? ;) Also, those bots are far from old and not very good; all 3 of them outranked [[Fractal]]... -- [[User:Vuen|Vuen]]

Just don't tell anyone. =) It's good some of us making lots of bots clean out some of them from time to time. A bot need to have a reason for existance to consume CPU power in the RR@H I think. I cleaned out quite a few of my bots a while ago. -- [[User:PEZ|PEZ]]

----

Hey iiley, do you mind if when I release the next version of [[Fractal]] I release alongside it a version with Fractal's gun and Cigaret's movement in the wiki package? I want a competitive comparison of it's new gun compared to some of the other bots out there, and I figure that a common movement (ala Griffon, Cigaret, Sedan) would be the best way to compare. Of course, these are all minibots, and Fractal is far from it... -- [[User:Vuen|Vuen]]

Just to make it crystal clear. Griffon does not share the movement with Cigaret and Sedan. I know you don't mean that, but someone reading it might misunderstand. Anyways, ask [[User:Sparafucil3|Jim]] too if you can borrow his movement, then you can compare your gun with Jekyl's and Griffon's. Good if iiley doesn't check up on the wiki in a while. -- [[User:PEZ|PEZ]]

OK,nice to see [[Fractal]]'s new gun.Sorry that i had not visit wiki page for days since i have not finish my project.Busy days these days.~;[ -- [[User:Iiley|iiley]]

----

[[User:Iiley|Iiley]] - I've noticed for some time here that [[SonAsh]] gets destroyed by [[AresHaiku]]. Any idea why that happens? Most of your waves should be hitting in the same place against it, and I'd expect that it moves fairly predictably, so I don't see how you'd miss it unless you had a bug in your aiming that made you fire head-on or something. -- [[User:Kawigi|Kawigi]]

[[SonAsh]] did not use waves,it use a symbol pattern matching.Maybe there is some bug or weakness,i will check it.Thanx [[User:Kawigi|Kawigi]] told me that,i didnot know it lost to [[AresHaiku]] as it is very predictable for PM. -- [[User:Iiley|iiley]]

That's what I figured. I also figured out that FunkyMusic had a bug that made it lose to AresHaiku, too, but then looked to see that FemtoAsh and SonAsh don't use enough of FunkyMusic's aiming code to have the same bug. Actually, I noticed that you were pattern-matching on heading and velocity (as opposed to heading change and velocity or lateral velocity). That's another thing that didn't occur to me. It might not be as strong as using heading change because it's less likely to get a good match, but it's a lot simpler to code. -- [[User:Kawigi|Kawigi]]

----
Nice to see you have Robocode plans again iiley! Wonderful painting. Did you paint it? Looking forward to meet [[Tide]]. -- [[User:PEZ|PEZ]]

Ha[[User:Voidious|Voidious]]Thank you,you paid attention to us so suddenly.~;] Yes,i painted it,But it is not for [[Tide]],if it is,i would paste it to the page of it.I think you mean Tide not Tibe. ~;] -- [[User:Iiley|iiley]]

I'm always looking for signs that you're back iiley. =) OK, so [[Tide]] then. Is it a tidal wave aimed to crush the surfers? -- [[User:PEZ|PEZ]]

Thank you, PEZ,i was planning to back robocoding for a long time,then now i come back,be very very excited.But dot worry,[[Tide]] is not strong enough,surfers are improved for a long time,it is adult and gentler and very strong,I lost too much about this.for the first, [[Tide]] will use the similar technic(Also similar to [[Lacrimas]]'s technic).I am testing the first robot of [[Tide]],maybe it can be upload tonight.~;] -- [[User:Iiley|iiley]]

If this bot started out as [[Lacrimas]] then it will not be long until it goes to the top. [[Lacrimas]] is one tough bot to beat. -- [[User:Sparafucil3|jim]]

[[Category:Archived Talk]]

User:Iiley/Archived Talk 20090430

2009-10-08T03:52:17Z

Robobot: moved User:Iiley/Archived Talk 20090430 to Archived talk:User:Iiley 20090430: move to talkarchive

#REDIRECT [[Archived talk:User:Iiley 20090430]]

Archived talk:User:Darkcanuck 2008-01-07

2009-10-08T03:52:15Z

Robobot: moved User:Darkcanuck/Archived Talk 2008-01-07 to Archived talk:User:Darkcanuck 2008-01-07: move to talkarchive

{{Talkarchive|User talk:Darkcanuck}}

Heya, welcome to the RoboWiki! Care to tell us a bit about yourself and/or your bots? Nice handle, by the way. I'm originally from Buffalo - that almost makes us neighbors, eh? =) Feel free to ask questions, I think it's generally a pretty open and helpful community. Cheers, -- [[User:Voidious|Voidious]]

Thanks for the welcome. I'll fill in this page with a bit more about me and create a page for [[Leon]] shortly. I do have a burning question though: I added Leon to the melee rumble yesterday and he appears to be doing very poorly. Almost as if he's throwing an immediate exception or being disabled by the robocode engine. I've done a lot of testing in my local client (using the packaged jar) and can't reproduce the problem. Anyone know what's going on or how I can debug a rumble-specific problem? -- [[User:Darkcanuck|Darkcanuck]]

Just wondering, is your bot compiled 1.5 compatible? That might be the problem. -- [[User:Skilgannon|Skilgannon]]

I had problems running RoboRumble (probably from incompatible bots) on my Mac under Java 1.5 so I actually run it using the SoyLatte BSD port of Java 1.6. But everything's compiled with the default 1.5 javac. Hmmm, I'm just testing a battle under using 1.5 and the skipped turn count is pretty bad - maybe the Rumble client is more sensitive to turn length? -- [[User:Darkcanuck|Darkcanuck]]

* For what it's worth, the rumble client uses the same Robocode engine and configuration, so it shouldn't be any more sensitive. You can run robocode.sh from your RoboRumble directory and run battles in that same space to check into issues like this. -- [[User:Voidious|Voidious]]

* I'm running meleerumble.sh from my robocode directory -- I only have one installation of version 1.5.1 and do all my testing with that. -- [[User:Darkcanuck|Darkcanuck]]

Yeah, that could be it. If your bot goes 5 seconds without calling execute(); it gets disabled. See if you can optimize any of your functions, particularly things that are in nested loops. As another trick, Math.sqrt(x) is faster than Math.pow(x,0.5), and x*x is MUCH faster than Math.pow(x,2). -- [[User:Skilgannon|Skilgannon]]

* Nice tip! My only Java experience is from robocode, so I didn't know about that. Should speed up my NN code, which is where Leon spends most of his time anyway. I may whip up a 1.01 version with this change, see if that helps. Do you know if Point2D.Double's distance() function has similar performance issues? -- [[User:Darkcanuck|Darkcanuck]]

* Well, it's always preferable to compare squared distances (ie. distanceSq() ). But beyond that it's just calling Math.sqrt(), AFAIK. The main place where it's important to increase speeds in in the nested loops. Caching results for distances that you use more than once is another good technique. Calling sqrt() isn't going to make your bot a SlowBot unless you are calling 500+ per turn. But my opinion of a SlowBot may not be everybody else's =) -- [[User:Skilgannon|Skilgannon]]

I will try running your bot in a melee battle when I get home and I'll let you know if I see any problems. I'm also on a Mac, using the default Java 1.5. I see that [[User:GrubbmGait|GrubbmGait]] is currently running his melee rumble client (we really should more prominently link this [http://thekandieman.com/nfwu/rr-uploads.php Who's Uploading Now] page), so maybe he'll see this and be able to test your bot on his system, too, as it seems likely those results are coming from him. -- [[User:Voidious|Voidious]]

* I ran a melee rumble client overnight a few days ago, so I think many of those battles are from me. Interestingly, there are a few cases where Leon won, just nowhere near enough to pull him out of the basement. -- [[User:Darkcanuck|Darkcanuck]]
* I started my client about 13:30 GMT on January 4th, and at seems that Darkcanuck gives no problems on my system. Maybe I can run some 'dedicated battles' to counteract on your about 8 bad battles. -- [[User:GrubbmGait|GrubbmGait]]
* Thanks, the last 300+ battle results are closer to my expectations. Which means its my rumble client causing the problem. I'll try a dedicated rumble install, see if that helps. -- [[User:Darkcanuck|Darkcanuck]]
** I checked and it is indeed your client. There are some more bad results for f.e. Fermat and Hatamoto. Please check if your meleerumble.sh has enough memory preserved (384 or more). -- [[User:GrubbmGait|GrubbmGait]]
** It indeed is strongly advised to have separate installs for the rumble and own development. On one install there must only run one thing at the time. If you have the power to run f.e. a one-on-one and a melee rumble at the same time, they should run in separate installs. -- [[User:GrubbmGait|GrubbmGait]]
** Ah, the RAM is a good point. I think the robocode.sh defaults to 512 and the roborumble.sh defaults to 256. That could definitely make the difference for a neural net bot, I'd think. By the way (if you didn't know already), feel free to post a new version once you're confident in your RR client posting good results. You may not have seen many new versions posted recently with the holidays and all, but it's definitely commonplace to release new versions frequently. Good luck! -- [[User:Voidious|Voidious]]
** I already had all of my scripts set to use 512M memory, so that's not the issue. Set up a fresh install of 1.5.1 and RoboRumble still dies under OS X. I'm hesitant to run any more sessions using SoyLatte if its creating bad results for other bots too. Leon 1.01 is out, sped up some NN code with Skilgannons' tips. -- [[User:Darkcanuck|Darkcanuck]]
*** I used 1.4.7 for meleerumble and upgraded today to 1.4.9 (on WinXP though). Maybe that version is more stable on OS X. -- [[User:GrubbmGait|GrubbmGait]]
*** I'm actually still using 1.4 for the RoboRumble. It seems anything past 1.4.4 or so throws some weird exceptions on my Mac (for the rumble, but not for Robocode). I haven't tried anything past like 1.4.9, I don't think. -- [[User:Voidious|Voidious]]
** Ok, so I've compiled Robocode 1.4(.0) and the rumble seems to work ok under OSX. Is there anything I should watch out for before uploading results? I don't mind corrupting Leon's results, but don't want to harm anyone else's. -- [[User:Darkcanuck|Darkcanuck]]

For what it's worth, I am also getting some minor skipped turn problems, dwarfed by a missed scan problem (turn passes without new info). I get about 2 of the former and a dozen or more of the latter every round, on average. I've recently done a major rework of my bot though, so I am inclined to suspect my code. I am using Java 6, compiling with 1.5 compliance, and using Robocode 1.5.1. I noticed a pretty precise value for the CPU constant in the config file. Is there a way to override that so nothing times out (for testing purposes)? -- Martin
*You can edit the file and fill in a larger value for it. The only drawback is that it will run slightly slower (when minimized). -- [[User:GrubbmGait|GrubbmGait]]
* I've tried doubling the cpu constant and it helped a bit with skipped turns during some of my debugging. I haven't noticed any missed scans, although I haven't been looking for them specifically. -- [[User:Darkcanuck|Darkcanuck]]
*The missed scans problem is a coding error, as I expected. Upping the cpu constant to 4 billion has removed the skipped turn issue for now. -- Martin

Did I mention that I'm happy to see [[Leon]] stabilize in 36th place? Just what I was hoping for, a top-40 result. -- [[User:Darkcanuck|Darkcanuck]]

[[Category:Archived Talk]]

User:Darkcanuck/Archived Talk 2008-01-07

2009-10-08T03:52:15Z

Robobot: moved User:Darkcanuck/Archived Talk 2008-01-07 to Archived talk:User:Darkcanuck 2008-01-07: move to talkarchive

#REDIRECT [[Archived talk:User:Darkcanuck 2008-01-07]]

Archived talk:User:Axe 20090511

2009-10-08T03:52:13Z

Robobot: moved User:Axe/Archived Talk 20090511 to Archived talk:User:Axe 20090511: move to talkarchive

{{Navbox small
| parent = Axe
| title = Axe Sub-pages
| page1 = Inspiration
| page2 = RoboLeague Analyser
| page3 = To-Do List
| page4 = Archived Talk 20090511
}}

{{Talkarchive|User talk:Axe}}

Bem-vindo ao wiki. :) -- [[User:ABC|ABC]]

Conforme ja havia lhe dito, obrigado. de uma olhada na To-Do list da pagina do [[Musashi]] :-)... -- [[User:Axe|Axe]]

All you know how seriously we take the Carnival here in Brazil, 5 days of holiday! And also all you know how Rio de Janeiro becomes in these days (a lot of turists - 2 million aprox.). So, I'm going to the mountains in that hell-like mean time. See u all soon, good carnival and give a rest to my bots please :)... Specially [[User:Rozu|Rozu]]'s [[Aleph]]. Obv, just kiddin', good carnival to you all that don't have that holiday! Quoting D'Gaule: "Brazil isn't a serious country" (at least he was 5-days right..) -- [[User:Axe|Axe]]

Happy Carnival, everybody ))))))))))).... -- [[User:Axe|Axe]]

I have a question to you RoboCoders: Is the real dimensions of a bot 40X40? Think that i've saw somewhere that it isn't really that. Does anybody knows something about it? -- [[User:Axe|Axe]]

Iirc, it's 36x36. -- [[User:ABC|ABC]]

That was what i thought have seen... But why the api returns 40 then? -- [[User:Axe|Axe]]

Does it? I think you might be the first one who have ever use the API call. =) -- [[User:PEZ|PEZ]]

Am I drunk? I'll check my code... Maybe is the carnival :-) Hic! -- [[User:Axe|Axe]]

Nope, i aint drunk (yet)... I use (probably since i've started robocoding): Math.max(this.getHeight(), this.getWidth());... The api javadoc says:
<pre>
--------------------------------------------------------------------------------
getHeight
public double getHeight()Returns the height of the robot

Returns:
the height of the robot
--------------------------------------------------------------------------------
getWidth
public double getWidth()Returns the width of the robot

Returns:
the width of the robot
--------------------------------------------------------------------------------
</pre>
And it returns 40X40... Any clues why? -- [[User:Axe|Axe]]

because that's the width and height of the bot maybe? The legendary 18 and 36 stuff we're doing is because Robocode actually subtracts 4 from both of those when doing collision detection, maybe as a sort of averaging between when they're facing diagonally and facing vertically or horizontally (?) -- [[User:Kawigi|Kawigi]]

The bot is a non-rotating square according to the developers IIRC, so where you're facing shouldn't make a difference. I can't believe that 40x40 is correct, my movement code should make me drive into walls constantly... [[User:Jamougha|Jamougha]]

My point is that a bot is a 40x40 rotating square according to the developers (ideally), but it's implemented as a 36x36 non-rotating square. -- [[User:Kawigi|Kawigi]]

Perhaps... I'm not sure what the difference is. :-) Anyhow, I just tested and a bot can approach to within 18.0001 pixels of the wall or so, so 36x36 is a good assumption. -- [[User:Jamougha|Jamougha]]

I had a gun that couldn't hit walls once because he would be within 17.999999999 pixels of the wall and it screwed it up. -- [[User:Kawigi|Kawigi]]

It's a non-rotating square? Are u sure? I mean, it isn't linked to the graphical representation? -- [[User:Axe|Axe]]

Interesting... it's really a 36X36, there is the code:
<pre>
public synchronized void updateBoundingBox()
{
boundingBox.setRect((x - (double)(width / 2)) + 2D,
(y - (double)(height / 2)) + 2D, width - 4, height - 4);
}
</pre>
Where width=height=40... Weird... -- [[User:Axe|Axe]]

Beware u all robocoderes... I´m preparing a disciple: Caeser. He promisses(?). Time will tell... -- [[User:Axe|Axe]]

I have a problem with all of your bots. Not a single one runs on my computer.Everytime when i try to run a battle with a robot i get this:<pre>SYSTEM: Could not load axeBots.SilverSurfer 1.01 : java.lang.UnsupportedClassVersionError: axeBots/SilverSurfer (Unsupported major.minor version 48.0)
java.lang.UnsupportedClassVersionError: axeBots/SilverSurfer (Unsupported major.minor version 48.0)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:486)
at robocode.security.RobocodeClassLoader.loadRobotClass(RobocodeClassLoader.java:187)
at robocode.battle.Battle.initialize(Battle.java:491)
at robocode.battle.Battle.run(Battle.java:139)
at java.lang.Thread.run(Thread.java:484)</pre>
I use Java 1.3 . Is this a possible reason for throwing this exception or what am i doing wrong. --[[User:Deathcon|deathcon]]

Thnx for reporting. Probably is the JRE version, [[User:ABC|ABC]] also gave me this warning. I'll try to fix it for 1.3 as soon as possible, the problem is that i'm around with some WaveSurfing problem... -- [[User:Axe|Axe]]

Just installed java 1.4 and no more problems. :D --[[User:Deathcon|deathcon]]

It's a good step i think. Many others bots have the same compatibility issue... I have to solve this to make it 1.3 compatible, but this kind of stuff always loose priority (it´s not that fun u know:). -- [[User:Axe|Axe]]

Dude, I do receive your e-mail letters. It must be you not receiving mine. -- [[User:PEZ|PEZ]]
* It was that spam killer... I don't know what is worst: the disease or the cure. -- [[User:Axe|Axe]]

Hey you all dudes! Just to remember that I remember u all, and hopefully u all remember me too... (remember-boring i know) I have some new ideas and thoughts that are screaming to go out, but i'm facing now an awfully long and hard time. But u all know too, after the storm the good times allways shine! "It can't rain alltimes..." (sic-to me) (or !hics! maybe? - definately it's written PORTO on the bottle, [[User:PEZ|PEZ]]! Actually on all of them:). God Bless U All, see u soon! -- [[User:Axe|Axe]]

Man, that doesn't sound good. Well, it sounds like it tastes good. Maybe it's with Ports as it is with Burboun, you need to break a few bottles before they really get to ya. =) Hope to see you back on the scene soon! -- [[User:PEZ|PEZ]]

Hope to see you back soon Axe, well as long as you keep from pushing us down in the rankings that is ;-) Same goes for you ABC! -- [[User:Pulsar|Pulsar]]

Too late for that... ;) -- [[User:ABC|ABC]]

Hey ya! Good to "see" u all! Hails from Brazil! 
Congrats for the 3rd place, [[User:ABC|ABC]]! Aiming the crown? 
U have work to do now, [[User:Pulsar|Pulsar]] ;). Answering your question, im not planning anything by now... Too much work, no time for fun now. But maybe ahead we will try something, i definately(?) miss robocoding...
Again, salutes to u all robocoders. Build the best, destroy the rest! -- [[User:Axe|Axe]]

I'm always aiming for the crown, who isn't? ;) Take your time to return, I had (almost) forgotten how tiring robocode can be, when you'r not coding you are thinking about what to try next. It's an obsession! -- [[User:ABC|ABC]]

Yeah u are right, indeed... It´s in the blood, isn´t? Or you do it deeply, or u better don´t do it at all. The night that [[User:Pulsar|Pulsar]] wrote me his post, i already noticed that u where(was?) doing updates. Tryied to post a response like that: "ABC seems back, if i where(?) u all, I´ll start to shake, I´´ll start to coff..". But i´ve got problems in my connection, and later was too late... Like the crowd use to shout here, in the Maracanã after a goal: "Haaaaá! Eu Já sabiaaaaaaá!". ;) Keep on pushing up the limits! For those about to robocode, we salute you!!! -- [[User:Axe|Axe]]

Btw, a question to u all robocoders: I was thinking in putting, in a temporary base, [[SilverFist]] back. Only to see where it would stand, and after that i´ll take it out. Anyone have a problem with that? [[User:PEZ|PEZ]] (where r u, man...)? -- [[User:Axe|Axe]]

I definitely have no problem with that! As a newcomer to Robocode, I've only read about this legendary monster, and I'd love to get to see it in action :) (From what I understand, PEZ is [http://www.halowiki.net playing Halo].) -- [[User:Voidious|Voidious]]

Naughty boy that [[User:PEZ|PEZ]], ain´t him? I´ll try to contact him anyway, let´s see if those old adresses that i have r still valid... 
Welcome to the battle, [[User:Voidious|Voidious]]! Very impressive that #32 for a first bot. Keep the good work, new quality blood is a bless. -- [[User:Axe|Axe]]

Yes, SilverFist is always welcome. We made an interesting experiment a while ago, AShadow (Shadow's movement + Ascendant's gun). I don't know if you saw it, but the result was AShadow > Ascendant. ;) -- [[User:ABC|ABC]]

Lots of Halo 2 for this guy, yes. And even more maintaing http://halowiki.net and my Halo 2 clan (http://clanofbobs.org/). Halo 2 is cool in many ways, but it is far from as friendly as the Robocode scene. I miss you guys! And I will probably now try to put some focus back on Robocode. How fun could it be for an [[Ascendant]] without something to ascend? =) -- [[User:PEZ|PEZ]]

HA! The old and good [[User:PEZ|PEZ]], now a.k.a. "Halo man"? :)
I´ll take a look at that Halo stuff, if it´s good for [[User:PEZ|PEZ]]... But my guts says that RC is invencible! Even i´m beeing more than a year far from the rc coding, I still sometimes catch myself wondering about angles, neural and statistic approachs for aiming & moving... 
But as i said, for the next weeks i´ll be just the Work-Axe-Holic, no time for fun-coding (althought i still squeeze some time for Beers, friends & women). Beeing a single again since dec-2005, it´s time for changing, the rock must roll, "O mundo gira, a Lusitana roda!" (i really dont think that this can be easily translated, perhaps ABC could). As PEZ, im trying new games too, Kenjutso & Kendo, and its sometimes amazing how life imitates the code... Sword fighting aint that different from robocoding at all!
Talk 2 much, i now. 2 much from me, i now 2. But as PEZ, I miss you guys 2! (2 much 2s? Or 2 much muches? :)) 
Well, ill try a taste of rc today, [[User:PEZ|PEZ]] agreed with my little [[SilverFist]] test, and since no one was against it... I´ll remove it when stable in rank, so it´s only a test. But i´m curious about how it will perform in this new environment. This is the old version, from 2004 september, i think. No updates at all. I think that it reached 2078. Lets see now. -- [[User:Axe|Axe]]

SilverFist ended afterall w/ 2045 pts., irc, it was 2078 more than a(n?) year ago. It was a King at his time, but now it ended in a draw with SilverSurfer at 5th... The competition is definately toughter... -- [[User:Axe|Axe]]

[[Category:Archived Talk]]

User:Axe/Archived Talk 20090511

2009-10-08T03:52:13Z

Robobot: moved User:Axe/Archived Talk 20090511 to Archived talk:User:Axe 20090511: move to talkarchive

#REDIRECT [[Archived talk:User:Axe 20090511]]

Archived talk:User:Awesomeness 20090504

2009-10-08T03:52:11Z

Robobot: moved User talk:Awesomeness/Archived Talk 20090504 to Archived talk:User:Awesomeness 20090504: move to talkarchive

{{Talkarchive|User_talk:Awesomeness}}

Okay, I need to make a list of bullets. I have made a bullet class and everything, but I need a special list that will let me access all of the bullets in a while/for loop and be able to add and remove them at any time and never mess up. If I did this in a normal array I could do a for loop and access using an increasing number, but I wouldn't know when to stop. In a while loop, if I used while(bulletsArray[x] != null) and then increment x, after I remove my first bullet that say, hit a wall, it will stop there. I need help!

:Thanks,
::[[User:Awesomeness|Awesomeness]] 14:02, 2 May 2009 (UTC)

I think this will do:
<pre>
ArrayList<Bullet> bullets = new ArrayList<Bullet>();
for (int i = 0; i < bullets.size(); i++) {
Bullet bullet = bullets.get(i);
if (bullet.needRemove()) {
// I think this will work
// bullets.remove(i--);
// but usually I do
bullets.remove(bullet);
i--;
}
}
</pre>
Here I assume that you use ArrayList to store you bullets and your bullet's classname is Bullet. If you use a plain array to keep the bullets, consider change to ArrayList. It is more flexible. » [[User:Nat|Nat]] | [[User_talk:Nat|Talk]] » 14:09, 2 May 2009 (UTC)

:Oh my gosh! You're right! ArrayList is way more flexible! I looked at the documentation; you don't even have to increment or decrement anything! The function remove() shifts the other elements to the left already! Thanks! [[User:Awesomeness|Awesomeness]] 14:14, 2 May 2009 (UTC)

:: Be sure don't use for-each style (<code>for(Bullet bullet : bullets)</code> or you will get ConcurentModificationException when you remove element (this is per java spec, but I still use the for-each style and didn't get this exception actually). And when you scroll through the array like one I mentioned, be sure you do i--, or you will just skip one element. » [[User:Nat|Nat]] | [[User_talk:Nat|Talk]] » 14:19, 2 May 2009 (UTC)

:: Oh, you're right. [[User:Awesomeness|Awesomeness]] 14:27, 2 May 2009 (UTC)

: One suggestion. Don't use <code>bullets.remove(bullet);</code>, use <code>bullets.remove(i);</code> instead because removing by index is far faster than removing by content. Well, with the size the list is in robocode it probably doesn't matter a ton, but removal of list by content, when you already have the index on hand, seems terribly wasteful to me. --[[User:Rednaxela|Rednaxela]] 14:45, 2 May 2009 (UTC)

: I changed that myself already. =D lol [[User:Awesomeness|Awesomeness]] 14:56, 2 May 2009 (UTC)

I've grown very fond of iterators for Lists, this would be my implementation:
<pre>
ArrayList<Bullet> bullets = new ArrayList<Bullet>();
Iterator<Bullet> i = bullets.iterator();
while (i.hasNext()) {
Bullet bullet = i.next();
if (bullet.needRemove()) {
i.remove();
}
}
</pre> --[[User:Skilgannon|Skilgannon]] 15:00, 2 May 2009 (UTC)
: Ahhh... I never knew that iterator has remove method so I always using ArrayLisy.get(i) to prevent ConcurentModificationException. Thanks you very much. » [[User:Nat|Nat]] | [[User_talk:Nat|Talk]] » 15:06, 2 May 2009 (UTC)

: Actually, I'm very fond of them myself, and what gives you the best [[wikipedia:Big O notation|asymptotic speed]] is using LinkedList with Iterator.remove(), because with that method is never needs to recopy parts of the list to shift them over. Note, 'best asymptotic speed', means that it's the fastest for very very large numbers of list elements, and that if the list is small ArrayList/iterator is faster. To find out what "small" is defined as, one would need to benchmark it, and it is somewhat dependant on the particular computer. Also ArrayList/index is ''slightly'' faster than ArrayList/iterator version in all cases because the ArrayList/iterator version incurs overhead for function calls but in effect does the same thing. --[[User:Rednaxela|Rednaxela]] 19:16, 2 May 2009 (UTC)
----

How do you find the x and y of a robot you've scanned? I see no <code>ScannedRobotEvent.getX()</code> or <code>getY()</code> method. [[User:Awesomeness|Awesomeness]] 15:19, 2 May 2009 (UTC)

Trig Trig Trig...
<pre>
double absBearing = e.getBearingRadians() + getHeadingRadians();
double x = getX() + Math.sin(absBearing) * e.getDistance();
double y = getY() + Math.cos(absBearing) * e.getDistance();
</pre>
That's all. » [[User:Nat|Nat]] | [[User_talk:Nat|Talk]] » 15:21, 2 May 2009 (UTC)

Here's a method I use in my utils class (I first saw it in a [[User:PEZ|PEZ]] bot):
<pre>
public static Point2D.Double project(Point2D.Double sourceLocation,
double angle, double length) {
return new Point2D.Double(sourceLocation.x + Math.sin(angle) * length,
sourceLocation.y + Math.cos(angle) * length);
}
// You'd pass it something like:
// myLocation = new Point2D.Double(getX(), getY());
// enemyLocation = MyUtils.project(myLocation, absBearing, e.getDistance());
</pre>
--[[User:Voidious|Voidious]] 16:15, 2 May 2009 (UTC)

Lastly, I need a way to "dodge" these simulated bullets and to figure out what angle the oppenent bot would be shooting from if it used linear targeting against me. I don't know how to do either of these. [[User:Awesomeness|Awesomeness]] 16:31, 2 May 2009 (UTC)

To dodge, use [[Anti-Gravity Movement]], to assume linear firing, use this code:
<pre>
angle = Utils.normalRelativeAngle(absBearing + Math.PI + Math.asin((Math.sin(e.getBearingRadians()) * getVelocity())/(20 - 3 * BULLET_POWER)));
</pre>
replace BULLET_POWER to which you get from energy drop. This prediction use non-iterative no-wall-stopping linear targeting. » [[User:Nat|Nat]] | [[User_talk:Nat|Talk]] » 16:35, 2 May 2009 (UTC)

:Thanks! This fits exactly what I was planning to do! [[User:Awesomeness|Awesomeness]] 16:44, 2 May 2009 (UTC)
:However anti-gravity confuses me greatly... [[User:Awesomeness|Awesomeness]] 17:11, 2 May 2009 (UTC)

UGH! I worked so hard on this and look what it does! Enable the debug graphics to see where it thinks the bullets are... Theres no point in working on antigrav movement until I fix this.
Program:
<pre>package awesomeness;
import robocode.*;
import robocode.util.*;
import java.util.Random;
import java.util.ArrayList;
import java.awt.*;

/**
* PwnBot - a robot by (your name here)
*/
public class PwnBot extends AdvancedRobot {

static StringBuffer pattern = new StringBuffer("" + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)-8 + (char)-7 + (char)-6 + (char)-5 + (char)-4 + (char)-3 + (char)-2 + (char)-1 + (char)1 + (char)2 + (char)3 + (char)4 + (char)5 + (char)6 + (char)7 + (char)8);

static double previousEnergy = 100d;
static double changeInEnergy;
//static double totalBulletDist;
//double[] bulletDists;

static int movementDirection = 50;
static long lastTime; //The last time known, used to track bullets

static Random generator = new Random(); //This makes random numbers
ArrayList<VirtualBullet> bullets = new ArrayList<VirtualBullet>();
static VirtualBullet newBullet, bullet;

public void run() {
lastTime = 0;
setAdjustGunForRobotTurn(true);
turnRadarRightRadians(Double.POSITIVE_INFINITY);
}

/**
* onScannedRobot: What to do when you see another robot
*/
public void onScannedRobot(ScannedRobotEvent e) {

//The absolute bearing, this is used a lot
double absoluteBearing = getHeadingRadians() + e.getBearingRadians(); ;

///////////////////////////////////////////////////////
////////////////////Movement Code//////////////////////

/////////////////////Bullet Code///////////////////////

//If there's a change in energy, it probably fired

if ((changeInEnergy = previousEnergy - (previousEnergy = e.getEnergy())) > 0d && changeInEnergy<=3.01) {

newBullet = new VirtualBullet(getX() + Math.sin(absoluteBearing) * e.getDistance(), getY() + Math.cos(absoluteBearing) * e.getDistance(), 20 - 3 * changeInEnergy, Utils.normalRelativeAngle(absoluteBearing + Math.PI + Math.asin((Math.sin(e.getBearingRadians()) * getVelocity())/(20 - 3 * changeInEnergy))));
newBullet.tick(1);
bullets.add(newBullet);

}

for (int i = 0; i < bullets.size(); i++) {
bullet = bullets.get(i);
bullet.tick(getTime() - lastTime);
bullets.set(i, bullet);

if (bullets.get(i).checkHitWall()) {
// I think this will work
// bullets.remove(i--);
// but usually I do
bullets.remove(i);
i--;
}

//bulletDists[i] = bullets.get(i).getDistance(getX(), getY());
//totalBulletDist += bullets.get(i).getDistance(getX(), getY());

}

///////////////////End Bullet Code/////////////////////

//Stay at almost right angles
//setTurnRightRadians(Math.cos(absoluteBearing+(-0.003*movementDirection)));

//setAhead(movementDirection);

////////////////////Movement Code//////////////////////
///////////////////////////////////////////////////////

///////////////////////////////////////////////////////
///////////////////////Gun Code////////////////////////

double absbearing;
absbearing = (e.getBearingRadians()-Math.PI/2)+1.57079633;
//rounding to be more accurate in projection!
pattern.insert(0, (char)(Math.round(Math.sin(e.getHeadingRadians() - (absbearing = absbearing + getHeadingRadians()))*e.getVelocity())));

int index=0, searchlength = 30;
//lol, if I ever make a haiku pattern-matcher, this will be in it:
while ((index = pattern.toString().indexOf(pattern.substring(0, searchlength--), 1)) < 0);

//searchlength will now become the index of the StringBuffer that I will project back to (back because my pattern
//is stored backward).
double power;
double dist;
searchlength = index - (int)((dist = e.getDistance())/(20-(power = Math.min(3, Math.min(getEnergy(), e.getEnergy())/4))*3));

//just add the offset to the bearing instead of making a new variable!
//The fact that this actually reconstructs future movement (like a normal pattern-matcher does) probably makes this
//just about the most accurate current nano pattern-matcher (except possibly Kakuru's, since it uses doubles instead of
//characters). The nice thing about it is that it correctly projects patterns even if I'm at a different distance than
//when I collected the pattern.
do
{
absbearing += Math.asin(((byte)pattern.charAt(index--))/dist);
}
while (index >= Math.max(0, searchlength));

setTurnGunRightRadians(robocode.util.Utils.normalRelativeAngle(absbearing - getGunHeadingRadians()));
setFire(power);

///////////////////////Gun Code////////////////////////
///////////////////////////////////////////////////////

///////////////////////////////////////////////////////
/////////////////////Radar Code////////////////////////

setTurnRadarLeftRadians(getRadarTurnRemainingRadians());

/////////////////////Radar Code////////////////////////
///////////////////////////////////////////////////////

lastTime = getTime();

}

public void onHitWall(HitWallEvent e) {
i();
}

public void i() {
movementDirection = -movementDirection;
}

// Paint a transparent square on top of the last scanned robot
public void onPaint(Graphics2D g) {
// Set the paint color to a red half transparent color
g.setColor(new Color(0xff, 0x00, 0x00, 0x80));

for (int i = 0; i < bullets.size(); i++) {
bullet = bullets.get(i);

g.drawLine( (int) bullet.getX(), (int) bullet.getY(), (int)getX(), (int)getY());

// Draw a filled square on top of the scanned robot that covers it
g.fillRect( (int) bullet.getX() - 5, (int) bullet.getY() - 5, 10, 10);

}
}

public class VirtualBullet { //A class to simulate bullets.

double x, y, speed, angle;

VirtualBullet(double startX, double startY, double velocity, double trajectory) {
x = startX;
y = startY;
speed = velocity;
angle = trajectory;
}

public void tick(long ticks) { //Moves the bullet the amount it would
while(ticks > 0) {
x += Math.sin(angle)*speed;
y += Math.cos(angle)*speed;
ticks --;
}
}

public double getX() {
return x;
}

public double getY() {
return y;
}

public double getDistance(double botX, double botY) {
return Math.sqrt(Math.pow(botX-x, 2)+Math.pow(botY-y, 2));
}

public boolean checkHitWall() {
if (x < 0 || y < 0 || x > getBattleFieldWidth() || y > getBattleFieldHeight()) {
return true;
}
return false;
}

}

}

</pre>

=( [[User:Awesomeness|Awesomeness]] 17:28, 2 May 2009 (UTC)

First, '''Robobocode trig is not same as your Math class trig'''. It should be:
<pre>

public void tick(long ticks) { //Moves the bullet the amount it would
while(ticks > 0) {
x += Math.sin(angle)*speed;
y += Math.cos(angle)*speed;
ticks --;
}
}
</pre>
And when you detect energy drop, '''bullet already move one tick!''', mean that you must advace bullet one tick when you add it. And, the absBearing you use in position calculation is not yet an absoluteBearing since it just e.getBearingRadians() because I use codesize trick. But if you are creating megabot, try remove all the codesize trick and make the code more readable. (or less ugly) Few suggestion:
* Check for energy change in onBulletHit, onHitByBullet too because the robot loss/gain energy when hitbybullet/bullethit.
* use more acculate radar lock, or you can't detect bullet acculately.
» [[User:Nat|Nat]] | [[User_talk:Nat|Talk]] » 02:27, 3 May 2009 (UTC)

:I have partially fixed it. It still fails miserably. I added a bit more debug graphics, which attempts to make a line from the bullet to PwnBot, but it doesn't work either. This confuses me... One end of the line should be touching my bot.
:: What you fixed? I fix to this code and it work correct as far as I can tell. I '''cannot''' be 100% accurate. I think just 80% is ''very'' good. This is my modified code:
<pre>
package awesomeness;
import robocode.*;
import robocode.util.*;
import java.util.Random;
import java.util.ArrayList;
import java.awt.*;

/**
* PwnBot - a robot by (your name here)
*/
public class PwnBot extends AdvancedRobot {

static StringBuffer pattern = new StringBuffer("" + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)0 + (char)-8 + (char)-7 + (char)-6 + (char)-5 + (char)-4 + (char)-3 + (char)-2 + (char)-1 + (char)1 + (char)2 + (char)3 + (char)4 + (char)5 + (char)6 + (char)7 + (char)8);

static double previousEnergy = 100d;
static double changeInEnergy;
//static double totalBulletDist;
//double[] bulletDists;

static int movementDirection = 50;
static long lastTime; //The last time known, used to track bullets

static Random generator = new Random(); //This makes random numbers
ArrayList<VirtualBullet> bullets = new ArrayList<VirtualBullet>();
static VirtualBullet newBullet, bullet;

public void run() {
lastTime = 0;
setAdjustGunForRobotTurn(true);
setAdjustRadarForGunTurn(true);
setAdjustRadarForRobotTurn(true);
while(true)
turnRadarRightRadians(Double.POSITIVE_INFINITY);
}

/**
* onScannedRobot: What to do when you see another robot
*/
public void onScannedRobot(ScannedRobotEvent e) {

//The absolute bearing, this is used a lot
double absoluteBearing = e.getBearingRadians() + getHeadingRadians();

///////////////////////////////////////////////////////
////////////////////Movement Code//////////////////////

/////////////////////Bullet Code///////////////////////

//If there's a change in energy, it probably fired

if ((changeInEnergy = previousEnergy - (previousEnergy = e.getEnergy())) > 0d && changeInEnergy<=3) {

newBullet = new VirtualBullet(getX() + Math.sin(absoluteBearing) * e.getDistance(), getY() + Math.cos(absoluteBearing) * e.getDistance(), 20 - 3 * changeInEnergy, Utils.normalRelativeAngle(absoluteBearing + Math.PI + Math.asin((Math.sin(e.getBearingRadians()) * getVelocity())/(20 - 3 * changeInEnergy))));
bullets.add(newBullet);

}

for (int i = 0; i < bullets.size(); i++) {
bullet = bullets.get(i);
bullet.tick(getTime() - lastTime);
bullets.set(i, bullet);

if (bullets.get(i).checkHitWall()) {
// I think this will work
// bullets.remove(i--);
// but usually I do
bullets.remove(i);
i--;
}

//bulletDists[i] = bullets.get(i).getDistance(getX(), getY());
//totalBulletDist += bullets.get(i).getDistance(getX(), getY());

}

///////////////////End Bullet Code/////////////////////

//Stay at almost right angles
setTurnRightRadians(Utils.normalRelativeAngle(absoluteBearing + Math.PI/2 - getHeadingRadians()));

setAhead(movementDirection);

if (Math.random() > 0.92) i();

////////////////////Movement Code//////////////////////
///////////////////////////////////////////////////////

///////////////////////////////////////////////////////
///////////////////////Gun Code////////////////////////

double absbearing;
absbearing = absoluteBearing;
//rounding to be more accurate in projection!
pattern.insert(0, (char)(Math.round(Math.sin(e.getHeadingRadians() - (absbearing))*e.getVelocity())));

int index=0, searchlength = 30;
//lol, if I ever make a haiku pattern-matcher, this will be in it:
while ((index = pattern.toString().indexOf(pattern.substring(0, searchlength--), 1)) < 0);

//searchlength will now become the index of the StringBuffer that I will project back to (back because my pattern
//is stored backward).
double power;
double dist;
searchlength = index - (int)((dist = e.getDistance())/(20-(power = Math.min(3, Math.min(getEnergy(), e.getEnergy())/4))*3));

//just add the offset to the bearing instead of making a new variable!
//The fact that this actually reconstructs future movement (like a normal pattern-matcher does) probably makes this
//just about the most accurate current nano pattern-matcher (except possibly Kakuru's, since it uses doubles instead of
//characters). The nice thing about it is that it correctly projects patterns even if I'm at a different distance than
//when I collected the pattern.
do
{
absbearing += Math.asin(((byte)pattern.charAt(index--))/dist);
}
while (index >= Math.max(0, searchlength));

setTurnGunRightRadians(robocode.util.Utils.normalRelativeAngle(absbearing - getGunHeadingRadians()));
setFire(power);

///////////////////////Gun Code////////////////////////
///////////////////////////////////////////////////////

///////////////////////////////////////////////////////
/////////////////////Radar Code////////////////////////

setTurnRadarRightRadians(2 * Utils.normalRelativeAngle(absoluteBearing - getRadarHeadingRadians()));

/////////////////////Radar Code////////////////////////
///////////////////////////////////////////////////////

lastTime = getTime();

}

public void onHitWall(HitWallEvent e) {
i();
}

public void i() {
movementDirection = -movementDirection;
}

// Paint a transparent square on top of the last scanned robot
public void onPaint(Graphics2D g) {
// Set the paint color to a red half transparent color
g.setColor(new Color(0xff, 0x00, 0x00, 0x80));

for (int i = 0; i < bullets.size(); i++) {
bullet = bullets.get(i);

// Draw a filled square on top of the scanned robot that covers it
g.fillRect( (int) bullet.getX() - 5, (int) bullet.getY() - 5, 10, 10);

}
}

public void onHitByBullet(HitByBulletEvent e) { previousEnergy += 3 * e.getBullet().getPower(); }
public void onBulletHit(BulletHitEvent e) { previousEnergy -= 4 * e.getBullet().getPower() + Math.max(0,2 * (e.getBullet().getPower() - 1)); }
public void onHitRobot(HitRobotEvent e) { previousEnergy -= 0.6; }

public class VirtualBullet { //A class to simulate bullets.

double x, y, speed, angle;

VirtualBullet(double startX, double startY, double velocity, double trajectory) {
x = startX;
y = startY;
speed = velocity;
angle = trajectory;
}

public void tick(long ticks) { //Moves the bullet the amount it would
while(ticks > 0) {
x += Math.sin(angle)*speed;
y += Math.cos(angle)*speed;
ticks --;
}
}

public double getX() {
return x;
}

public double getY() {
return y;
}

public double getDistance(double botX, double botY) {
return Math.sqrt(Math.pow(botX-x, 2)+Math.pow(botY-y, 2));
}

public boolean checkHitWall() {
if (x < 0 || y < 0 || x > getBattleFieldWidth() || y > getBattleFieldHeight()) {
return true;
}
return false;
}

}

}
</pre>
:: I bet it 90% accurate, but you may see it doesn't accurate because enemy cannot turn the gun to it aim position in time before it fire. » [[User:Nat|Nat]] | [[User_talk:Nat|Talk]] » 06:08, 3 May 2009 (UTC)

== THANK YOU ==

Thank you guys! All of you! Especially you, [[User:Nat|Nat]]! I've made the official working code, all I have to do now is make them anti-gravity points! You fixed almost everything, all I had to do was inverse the Y axis for some reason. I don't know enough trig to fix whatever formula's going wrong. But thank you! YAY!

--[[User:Awesomeness|Awesomeness]] 17:09, 3 May 2009 (UTC)

:I just was browsing on the wiki... =( My bullet dodging idea isn't original or new... It's just this thing called "ShrapnelDodging"... Aww... --[[User:Awesomeness|Awesomeness]] 17:23, 3 May 2009 (UTC)

:: Robocode's been out quite a while, so it's very difficult to find 100% original ideas. It's just the way it is, try not to let it get you down! =) Glad to hear you got your stuff working. --[[User:Voidious|Voidious]] 17:27, 3 May 2009 (UTC)

:::You're right. Besides, maybe I'll even change something. Until I'm in highschool, I'll never have a full understanding of trigonometry, so I'll probably need help with that. I might use this virtual bullet engine in my other bots. It's not huge, but it'll never fit into a nano bot and probably not into a micro. Currently, without any movement and including the graphical debugging, it's 691 bytes, and I'm sure it can be compressed.
--[[User:Awesomeness|Awesomeness]] 17:47, 3 May 2009 (UTC)

:::Actually, taking out the weak PM gun, the graphical debugging, and the weird movement I put in before I planned out the bullet sims and stuff I have now, (leaving only the basis of the bullet tracking itself) I get 409 bytes. Is that good, or is that way more than what other people have made?
::::Oh, I just checked the [[Robocode/Game_Physics|game physics]], and I found out that the Y axis is well... reversed. That's weird. I don't like that. Oh well. [[User:Awesomeness|Awesomeness]] 19:59, 3 May 2009 (UTC)
::::: But that make a life more easier! » [[User:Nat|Nat]] | [[User_talk:Nat|Talk]] » 23:45, 3 May 2009 (UTC)
::::: I can't say it makes life easier, but I let you know that if end up going down a world with lot's of geometry, being capable of using any coordinate system is important and Robocode's system is a good example and practice field for that. --[[User:Zyx|zyx]] 03:46, 4 May 2009 (UTC)
:::::: The atan2(x,y) seem reasonable to me more than atan2(y,x), at least for who that only know basic trig before starting robocode like me. » [[User:Nat|Nat]] | [[User_talk:Nat|Talk]] » 06:09, 4 May 2009 (UTC)

User talk:Awesomeness/Archived Talk 20090504

2009-10-08T03:52:11Z

Robobot: moved User talk:Awesomeness/Archived Talk 20090504 to Archived talk:User:Awesomeness 20090504: move to talkarchive

#REDIRECT [[Archived talk:User:Awesomeness 20090504]]

Archived talk:User:Awesomeness 20090502

2009-10-08T03:52:09Z

Robobot: moved User talk:Awesomeness/Archived Talk 20090502 to Archived talk:User:Awesomeness 20090502: move to talkarchive

{{Talkarchive|User_talk:Awesomeness}}

Note for you, Horizon Component System broke in 1.7. It cannot perform a radar lock so it can't dodge/fire effectively. Try robocode 1.6.0 or 1.6.1 and let see can you get score at this rate high? » [[User:Nat|Nat]] | [[User_talk:Nat|Talk]] » 02:28, 13 March 2009 (UTC)

Shoot, 1.6.1 doesn't work on my computer. Strange...[[User:Awesomeness|Awesomeness]] 02:52, 13 March 2009 (UTC)

Welcome to Robocode [[User:Awesomeness|Awesomeness]], good luck and have fun. Shout when in trouble. --[[User:Zyx|zyx]] 03:09, 13 March 2009 (UTC)

Welcome to the wiki indeed! About Horizon, maybe Horizon is fixed as of 1.7.1 Beta2? I haven't tested 1.7.1 Beta2 yet. And Nat, any reason you haven't made a bug report for it or is it the same bug as one already reported? --[[User:Rednaxela|Rednaxela]] 03:21, 13 March 2009 (UTC)
* I haven't download the 1.7beta2 yet. But, about bug report, I completely forget! Thanks for remind. I think there isn't ''anyone'' know this except me. » [[User:Nat|Nat]] | [[User_talk:Nat|Talk]] » 11:25, 13 March 2009 (UTC)

Um... I do have one problem. Whenever I try to use things such as GF targeting, Surfing, etc. The tutorials never use the methods properly or something. It gives a can't find symbol error for every custom method in the code. =/ -- [[User:Awesomeness|Awesomeness]]

Er, what method are you using to compile it? The tutorials are using methods just fine. --[[User:Rednaxela|Rednaxela]] 03:45, 13 March 2009 (UTC)

The compiler ALWAYS gives me errors unless I set it to "-classpath /Users/student/Documents/Robocode/libs/robocode.jar". Maybe that's cuz I use a mac. [[User:Awesomeness|Awesomeness]] 14:36, 13 March 2009 (UTC)

Er, you always need to include the classpath if you're compiling from the command line normally. It has nothing to do with using a mac. The only way to go without it is either by including it in the CLASSPATH environment variable, or using an IDE like Eclipse --[[User:Rednaxela|Rednaxela]] 17:16, 13 March 2009 (UTC)

I'm not using a terminal to compile, I'm just changing the compiler settings for the classpath. I really need GF or PM targeting for my bot! =( [[User:Awesomeness|Awesomeness]] 19:01, 13 March 2009 (UTC)

So what are you using? The editor/compiler built into Robocode? It should work straight out the box... --[[User:Skilgannon|Skilgannon]] 19:25, 13 March 2009 (UTC)

I use the Javac thingy, not Jikes. It doesn't matter which I use, I'm pretty sure, I seem to get the same output for them no matter which compiler I use. Same errors with the default classpath.

NEVERMIND!!! YEEEAAAHHH! I got GuessFactor targeting to work perfectly! And with my already good movement strategy, it's awesome! I'm so proud of myself because I thought up this movement concept myself, and I checked, no one else uses it! It's a truly original strategy! I think...

Umm... I just had a thought... If two robots battle each other and use static variables with the same name(s), will the robots mess up? --[[User:Awesomeness|Awesomeness]]

Nope, they won't. Robocode loads each robot with a seperate classloader, which makes it so individual robots in battle keep completely seperated static data. --[[User:Rednaxela|Rednaxela]] 02:23, 14 March 2009 (UTC)

Okay. Can someone take a look at my page, [[Fission]]? I need help making it into a jar.
----
For Elite: Have you try just 35 rounds? Many of nanobot's pattern matcher get stuck exactly after round 35... And I think I look correct, but
{| border="1"
| 22 || robar.nano.Assertive 0.3 || 62.58 || 70.73 || 1730.7
|}
22th is now Assertive. PlusarNano is at 29th. » [[User:Nat|Nat]] | [[User_talk:Nat|Talk]] » 09:46, 17 March 2009 (UTC)

Hmm... You're right. Either way, I easily beat the 29th bot so I'm happy =D

Hi, good luck for the rumble! If you have any questions about nanos, I'm a nano-freak. ;) Looking for strong nano-dodgers try the Neophyte series, Freddie, Mosquito series, AceSurf, Acero, RaikoNano. --[[User:Robar|HUNRobar]] 20:54, 18 March 2009 (UTC)

* I think the strong of Neophyte is not for movement, at least not a dodge, but it come from its distance control (180px) and good gun. That why PRAL and SRAL perform so good per LT. » [[User:Nat|Nat]] | [[User_talk:Nat|Talk]] » 03:29, 19 March 2009 (UTC)

== Trigonometry Question ==

Ok, this is kind of unrelated, but all you guys here are experts at trigonometry,and although I go to a VERY advanced school, I'm only 13, and I have a limited understanding. I am making a java application totally unrelated to Robocode. Say I have this scenario:

I've made a dot that moves around with the arrow keys, but I want another dot to follow it. I've made the first dot move according to the arrow keys, and I could make the follower dot's movement simple, but I want it to move DIRECTLY towards the arrow key mover dot. To do this I need two things:

-A method returning a double and taking parameters x, y, x2, and y2 giving the angle in radians between them in comparison to vertical. For example, if x and y are 0, 0 and x1 and y2 are 2, 2, then the angle you'd get is 2.35619449, or 135 degrees in radians.

-A way to get the change in x and y when given an angle. It returns x and y and takes a double called angle. For example, if the angle was 90 degrees, (in radians, though, of course) then it would return 1, 0, if it was 180 degrees, it'd return 0, 1, and if it was 270 degrees it'd be -1, 0.

Sorry if this is confusing... Someone help, please! --[[User:Awesomeness|Awesomeness]] (moved by --[[User:Zyx|zyx]] 01:24, 29 March 2009 (UTC))

* That first method is equal to Math.atan2(x2-x1,y1-y2). --[[User:Rednaxela|Rednaxela]] 01:27, 29 March 2009 (UTC)

* For the second method, your first value would be Math.sin(angle+Math.PI), and the second value would be Math.cos(angle+Math.PI). (Keep in mind that you can't return two values from one method unless putting them in an object/array or something) --[[User:Rednaxela|Rednaxela]] 01:31, 29 March 2009 (UTC)

(edit conflict)

* Although [[User:Rednaxela|Rednaxela]] already answered, I believe he's methods may be too Robocodish, as I think he still has the rotated Math we use here. But I may be wrong.

* First let me clarify. I think you have the 0,0 on the top left corner, am I right? That's the only reason I would understand your results for question1, and probably makes sense since you are using display coordinates.

* Being that the case, the first method is something like this
<pre>
double angle(double x, double y, double x2, double y2) {
double alpha = Math.atan2(-(y2 - y), x2 - x);
return Math.PI / 2 - alpha;
}
</pre>
:see that atan2(y, x) will give you the angle from origin (0,0) to (x, y). The minus sign in the y parameter is to account for the fact that 0,0 is on top left and not bottom left as in regular math. PI / 2 should be the vertical vector you mention, the may need some tweaking, but they are small if any.

* For the second method, I will give a hint and let you try work it out. The sine of an angle represents the y-axis, and the cosine is x-axis. Try working out them for your fits. Use a calculator to check the values, Windows calc can handle sin/cos of Degrees or radians, and most scientific calculators do as well.

Hope it helps. Ask again after some work ;-). --[[User:Zyx|zyx]] 01:47, 29 March 2009 (UTC)

[[User:Rednaxela|Rednaxela]] methods are not in Robocode coordinates, are actually in display coordinates, so probably are more direct to your needs. --[[User:Zyx|zyx]] 01:56, 29 March 2009 (UTC)

I believed [[User:Rednaxela|Rednaxela]] method are robocode's, not trigonometry standard. But robocode use the same coordinates system as same as java awt/swing component. Anyway, don't use [[User:Rednaxela|Rednaxela]] in your math class! In math class you should do [[User:Zyx|Zyx]]'s. Another thing, standard/java's 0 degrees would be at right but robocode use top, so beware when you write robots that you should switch sin <-> cos and atan2(z,x) to atan2(x,y).

One more thing, you said "I'm only 13, and I have a limited understanding." I don't know where do you learn (you say very advanced school, but I'm in advanced school, too), but I'm 13 too and understand a lot of trigonometry already (well, not all. I still have some problem, too.) yet I have not learn that in classroom (but learn from some other source, including robocode) Trigonomatry is not hard, as I and my friends taught another friend within 10 minutes and that include all basic sin/cos/tan and the inverse. » [[User:Nat|Nat]] | [[User_talk:Nat|Talk]] » 06:33, 29 March 2009 (UTC)

* Incorrect Nat, the methods I listed are ''not'' for robocode style angles/coordinates, they are for the style that [[User:Awesomeness|Awesomeness]] very specifically requested. It was quite specifically said that 0 degrees should be up, and 2, 2 should be 135 degrees. Which is neither robocode-style nor standard-trig-style, but is the style I set those methods up to use. --[[User:Rednaxela|Rednaxela]] 06:47, 29 March 2009 (UTC)

* Yes [[User:Nat|Nat]], I was confused at first too, but they are quite what asked for. The first method should give the same results as the one I posted, but his method takes care for the 0 being on top more directly than I did; and I don't think that matters in this case, but is faster than mine :-). --[[User:Zyx|zyx]] 10:51, 29 March 2009 (UTC)

** Well well, I know that Rednaxela method are what Awesomeness want, I just warn him not to use your method in his math class or in other place. Also, in old wiki, there is said somewhere that this style is robocode's, but I know that this is what Awesomeness want :-) » [[User:Nat|Nat]] | [[User_talk:Nat|Talk]] » 13:28, 29 March 2009 (UTC)

::* This style ''isn't'' quite robocode's. In robocode, 0 degrees is up AND 2,2 is 45 degrees not 135 degrees. Inverted y axis from robocode in other words --[[User:Rednaxela|Rednaxela]] 15:37, 29 March 2009 (UTC)

User talk:Awesomeness/Archived Talk 20090502

2009-10-08T03:52:09Z

Robobot: moved User talk:Awesomeness/Archived Talk 20090502 to Archived talk:User:Awesomeness 20090502: move to talkarchive

#REDIRECT [[Archived talk:User:Awesomeness 20090502]]

Archived talk:Twin Duel 20090807

2009-10-08T03:52:08Z

Robobot: moved Twin Duel/Archived Talk 20090807 to Archived talk:Twin Duel 20090807: move to talkarchive

{{Navbox small
| title = Twin Duel Sub-pages
| parent = Twin Duel
| page1 = Participants
| page2 = Results
| page3 = Strategy Guide
| page4 = Tourney Runner
| page5 = Origin Discussion
| page6 = Archived Talk 20090807
}}
{{Talkarchive|Talk:Twin Duel}}
Please sound off if you think you'll enter this Thursday, and in which division (AdvancedRobot or ExtendsRobot). It's not a commitment, I'd just like to get a feel for things. I plan to enter one team for sure, and possibly a second just for kicks, although I'm 99% sure one of my teams will be far superior to the other. Good luck dudes! -- [[Voidious]]

*I'll try to have an AdvancedRobot team ready for Thursday, but I can't guarantee anything for sure. --[[wcsv]]
**Well, I didn't have a decent team ready for the first week. Considering that I've never written a melee or team bot (or a bot under 2000 bytes for that matter), i'm not surprised. After writing duelists for so long, it's tough to get used to the idea that there's more than one other bot out there.--[[wcsv]]

*I'll have at least an AdvancedRobot team ready for Thursday. Hopefully a Robot team as well. --[[David Alves]]

*I have holidays! Two teams should be possible :) --[[Krabb]]

*My holidays are over :( I will try to have a team ready by Thursday, but cannot promise anything. --[[Loki]]

*I spent the night in a hotel, so I have a 'cheap' Twin ready (GruwelTwin). A really new Twin will come next week. -- [[GrubbmGait]]

*I'm in. Meet TwintelligenceOne and Two, weighing in at 1993 bytes (which could be compressed a lot if I tried...). How do you want me to send them, Voidious? For now, I'll try to put them on the Repository. -- [[Greywhind]]
** Just e-mail me the .jar, e-mail is on the [[ContactInfo]] page. I can and will just get 'em off the repository, if it's up, but it isn't always. -- [[Voidious]]

This is gonna be fun! As bot-master, I promise not to look at or test against anybody's team until the actual competition has taken place each week =) With the aid of the RoboRumble code, I think I'll have the battle automator stuff done tonight. -- [[Voidious]]

Alright, much thanks to [[Albert]] and his excellent RoboRumble code, I'm now able to simulate team battles for this competition. I also perused [[Mue]]'s runbattles.zip code, but Albert's turned out to be more useful, and I also knew it was team-aware. Just a little work left in organizing the code and we'll be ready to rock with this. -- [[Voidious]]

* Sweet, got that round robin automator totally done and ready to rock for Thursday. I'll just run the bracket tourney by hand, although I could and probably will automate that part, too, in the future. I'll share the code here sometime soon. -- [[Voidious]]

Just a note beforehand that I would like to make the finals a best of 3, unless somebody raises serious objections to that. So far I've got [[GrubbmGait]]'s entry, and I know that mine will be ready. I'll run everything when I get home from work tomorrow, and hopefully have final results posted tomorrow evening. Good luck everyone. -- [[Voidious]]

Just realized a potential problem with the ExtendsRobot division... TeamRobot extends AdvancedRobot, so the only way to have isTeammate() etc is to do it yourself by parsing getName(). =P --[[David Alves]]

* Ha, good point ;) Just removed it from the rule set at the top. Was gonna try and make one, too, but I guess I can just spend that time on my AdvancedRobot team now. =) -- [[Voidious]]

Is it ok to use java 1.5? Or are we saying that bots need to be 1.4 compatible? --[[David Alves]]

I'm running Java 1.5, so it's fine with me if you use it. -- [[Voidious]]

I've got one ready. And its going to kick the pants off y'all. Or something. Actually, it probably sucks. We'll see. -- [[Krillr]]

I don't get my team redy this week... it's more than just minimising slarti :) --[[Krabb]]

I failed to reach the deadline too :( I guess, because i understood the meaning of GMT! But what the @$#% is the meaning of UTS?

Quote Wikipedia:
"Coordinated Universal Time (UTC) is a high-precision atomic time standard which replaced Greenwich Mean Time on 1 January, 1972 as the basis for legal civil time all over the Earth. UTC has uniform seconds defined by International Atomic Time (TAI), with leap seconds announced at irregular intervals to compensate for the earth's slowing rotation, and other discrepancies. The leap seconds allow UTC to closely track Universal Time (UT), which is a time standard based on the earth's angular rotation, rather than a uniform passage of seconds.

Time zones around the world are expressed as positive or negative offsets from UTC. In this role, UTC is also referred to as Zulu time (Z)."

The problem with this definition is that it does not define 0 UTC...

While GMT ("Greenwich Mean Time") at least represented a geographical location that most people know ... end of growling... --[[Loki]]

Positive side of this new competition is that i discovered a huge bug in my team of Valkiries which prevented the exchange of information. I hope to use this info and finally implement a bugfree version of my new movement. --[[Loki]]

Well Voidious emailed me and said he's on his way home, so you still have a half hour or so. My (last minute) entry is at YinYang. Good luck guys! --[[David Alves]]

My real twin will be in next week, for now I just entered a team-aware Gruwel. (Shame on me, but at least there is some competition) -- [[GrubbmGait]]

Starting the round robin now ... I hope to have everything up tonight. Maybe I'll post some interim info, well see =) Good luck all! -- [[Voidious]]

I got the losses down to a 2-1 ratio vs GruwelTwins last night, and cut almost 400 bytes by converting to a VisitCountStats gun this morning. There is hope for next week, at least =) -- [[Voidious]]

I've finished an interesting team that beats all current entrants but [[KomariousTeam]]. However, I'll be on vacation for the next two weeks, so I won't be able to update it (or maybe even check on its score). Lets hope for good results when I get back... -- [[Kev]]

Wow, all but [[KomariousTeam]] is an interesting statistic. I guess I won't pull it =). Also, I am going to assume I should just re-enter a team if it isn't updated for the following week - somebody let me know if I should do otherwise. -- [[Voidious]]

Just a reminder, deadline is the same as last week, and I'll be running the competition when I get home from work tomorrow. Good luck everyone! -- [[Voidious]]

No new entry for me yet. The 2v1 strategy seems ok, but the 2v2, 1v1 and especially the 1v2 strategies are not want I want. Lets see if GruwelTwins can keep the nr 1 position for one more week. -- [[GrubbmGait]]

I wouldn't focus much on 1v2 strategy, but that's just my 2 cents. Unless you find that HolyGrail implementation of TwinDuel WaveSurfing that I've been looking for =) -- [[Voidious]]

* Hmm, ya know, disregard that comment. There's plenty of times that the 1v2 strategy can work out. But I do think it's the least important strategy to focus on... -- [[Voidious]]

* I know, but the overall feeling is not good yet. It is difficult to test strategies as I beat the first-week-participants easily and GruwelTwins does not care about what strategy it is fighting against. -- [[GrubbmGait]]

* Well, I promise you'll have something better to test against after this week... =) -- [[Voidious]]

Deadline for bots is Thursday at 5 pm EDT / 9 pm UTC / 2 pm PDT. You can just e-mail them to me (check [[ContactInfo]]). Good luck everyone! -- [[Voidious]]

I don't have a new entry ready for this week. =( --[[David Alves]]

Tourney's running, but I'm eating dinner, so I won't update wiki page for a little while. Thanks everyone for the entrants. Probably only 2 rounds of round robin this week, too, but we'll see. -- [[Voidious]]

Just a friendly reminder that the deadline is at 21:00 UTC today for this week's tourney. I'm not sure I'll have an update to my team, sadly, but we'll see if I can make some progress against GeminiTeam in the couple of hours I have left =) I'm planning to start things right at the deadline today, so please get me your updated entries before then! As before, I will assume a previous entry should stay in unless you let me know I should remove it. -- [[Voidious]]

* Hmm, only two new/updated bots this week? And one is mine. I'll give it at least an extra 15 minutes here... -- [[Voidious]]
* Well, I'm heading out to dinner, so I'll get the round robin started. Good luck all! -- [[Voidious]]

I added a rule, "no reading from or writing to files". Is that OK with everyone? [[GrubbmGait]] proposed this during our initial discussion, and nobody had a problem with it. It might be OK to change it to "no writing to files, and no pre-loaded data that is enemy specific". So you could still store patterns or whatever in there to cut code size, if you want. Thoughts? -- [[Voidious]]

Just an hour until the deadline for this week. Once again, I have not made much progress - I've been a little distracted by [[Phoenix]] climbing the rankings behind [[Dookious]] =) - but I am looking forward to returning my focus to the TwinDuel format soon. Good luck to everyone! -- [[Voidious]]

Alright, only new entries this week are from me and [[Loki]] - and mine are probably a decrease in performance. =) Good luck everyone! -- [[Voidious]]

No new or updated submissions yet for this week (8/31). I do hope to try some new stuff with my team in the next week or two, but I don't have anything new for this week, either. I'll change my entry from 0.90 to 0.89 of LuminariousDuo and still run it for this week, in any case. Next week, I would like to move the tournament to Wednesday or just cancel it altogether, since I have a family wedding and related activities later in the week. I'll only cancel it if there are still no new entries by then. Good luck all, though I'm pretty sure GeminiTeam will still take it home if nothing new comes in in the next 20 minutes =) -- [[Voidious]]
* sorry, i am not ready in time. I will have a new entry next week. --[[Loki]]

There were no new entries last week, and I was very busy with Real Life, so I didn't run a TwinDuel tourney. I am planning to for this week, though, despite the only new entrant being a small update to LuminariousDuo from myself. I hope you guys are still interested in doing this... I, too, am quite guilty of not working much on my team. Maybe I'll drop it to bi-weekly if interest doesn't pick up. -- [[Voidious]]

What about dropping the code limit? ;) --[[Krabb]]

Well, that would raise the level of competition to the point that it would be unexciting, for me. [[Shadow]] and [[Aleph]] would instantly dominate, probably to the point that they wouldn't be dethroned for months, if ever. Even now, adapting a good melee MiniBot is a pretty quick route to a competitive team... Which is not such a bad thing, as I think it's quite possible to overcome their head start with some teamwork and the extra 500 bytes. That's my feeling on it, anyway... sorry man. :-\ -- [[Voidious]]

I agree with [[Voidious]] that dropping the codesize limit would give a HUGE advantage to established mega team bots like Shadow; however I also must admit that the codesize limitation is really killing my interest in working on my team at the moment. There must be some sort of solution, what about factoring codesize into the scoring so that bots larger than 2000 bytes are handicapped proportionally to their codesize? --[[wcsv]]

The idea seemed interesting, but I wasn't going to design an entirely new bot to meet the code size restriction. Fortunately, there is already an "Extends TeamRobot" competition for megabots, and you can run it whenever you like. I've stripped out all of the team code from Ugluk since creating my three teams (one was discarded). It made additions and refactoring of the code more burdensome. Perhaps some day I'll make another team. -- Martin

I like wcsv's idea. How about the winner of a given round is determined by (score / (codesize + 500)), with no upper or lower limits on codesize? The reason for adding 500 is so that Walls isn't an instant champion. =P

Just to give a rough idea of how that formula plays out, here are some matches that would be ties.
<pre>
SomeNanobot (249 bytes) that scores 1000 (37.5%)
would tie with
SomeMicrobot (749 bytes) that scores 1668 (62.5%)

SomeMicrobot (749 bytes) that scores 1000 (38.5%)
would tie with
SomeMinibot (1499 bytes) that scores 1600 (61.5%)

SomeMinibot (1499 bytes) that scores 1000 (15.8%)
would tie with
Shadow 3.66d (31696 bytes) if Shadow scored 16106 (94.2%)

SomeMinibot (1499 bytes) that scores 1000 (14.3%)
would tie with
Aleph 0.34 (11498 bytes) if Aleph scored 6002 (85.7%)
</pre>

The number 500 would favor things around minibot size I think. That constant could be adjusted up or down if we wanted to favor larger or smaller bots. But essentially, there's no way for any large megabot (eg Shadow, Aleph) to win it.

--[[David Alves]]

So we'd just ditch the [[Survivalist]] aspect altogether? I must say, I do prefer the rules like they are. But I'm interested to hear what the other competitors (and would-be competitors) have to say about it. The truly fun part of all this is in trying a new style of competition and competing with you guys, so I'm certainly flexible =) However, it seems to me that the people that dislike making code size restricted bots would dislike this just as much. Is that not true? -- [[Voidious]]

I also think the tournament is good the way it is. Basing score on code size looks like it might help smaller code size bots even more. I'm pretty sure two [[DoctorBob]]'s would win fairly easily if the scoring is kept (score / (codesize + 500)). With a higher constant, it might work though. [[GeminiTeam]], which doesn't use [[MinimumRiskMovement]], proved that adapting melee bots might not be the best way to go anyway. -- [[Kev]]

Well, use (survival firsts) / (codesize + X) if you want to keep the survival element. As for DoctorBob winning, here's the results of GeminiTeam vs. DoctorBob in a 75 round match:
{| border="1" cellpadding="3" style="border-collapse: collapse; font-size: 85%; color: black"
| Team || Score || Codesize || Score / (codesize + 500) || Survival 1sts || Survival 1sts / (codesize + 500)
|-
| kc.twins.GeminiTeam || 40389 || 1833 || 17.312 || 70 || 30.004 (x1000)
|-
| radnor.DoctorBobDuo || 16277 || 238 || 22.055 || 5 || 6.7751 (x1000)
|}
So maybe the constant should be higher if we use Score / (Codesize + X). I think 500 is fine if we do survival firsts though. --[[David Alves]]

Not sure how I feel about mixing Survivalist scoring with the code size penalty ... A lot of lopsided battles happen in the TwinDuel in terms of rounds won, so I think the Survivalist scoring would favor larger code sizes a bit more than raw scoring. -- [[Voidious]]

Well I tried Shadow vs Gemini, and Shadow won with something like 45-30, which wasn't anywhere near enough to overcome its codesize penalty. For what that's worth. =) --[[David Alves]]

Getting ready to start this week's tourney, but going to give David a few more minutes to send his team, since he was taunting me with some impressive results earlier today... =) Good luck everyone! -- [[Voidious]]

Congrats David on this excellent result! That is the charm of such a tournament: You don't have to be the absolute best, as long as you beat the bots you are fighting. I already found out that being agressive is much more important than in [[Melee]] or even OneOnOne, but can't find the time to bugfix my new version of GrauwuarG. -- [[GrubbmGait]]

Question: are the best TwinDuel bots better melee bots, or are they more of modified 1v1 bots? How would they do in the rumble -- [[Alcatraz]]

We really don't know enough to say for sure. So far aggressive 1-v-1 bots seem to do the best, but Luminarious is a melee-style bot and the latest version is quite strong. --[[David Alves]]

There are also some interesting trade-offs. For instance, the first GeminiTeam, with an agressive 1v1 type style, trounced pretty much the whole field; but KomariousTeam, an adapted 1v1 bot team, made easy work of it, while many others had an easy time with KomariousTeam. I found it funny that GrubbmGait, with some solid background in melee, commented that the style is more like 1v1, while I, having spent 90% of my time in 1v1, find it to be more like melee ;) -- [[Voidious]]

Alright, I'm gonna get things underway for this week's tourney ... Good luck, everyone. -- [[Voidious]]

Holy cow, I am really out of it tonight. I completely forgot about the TwinDuel until just now. There are no new entries, anyway, but I'll go ahead and re-run last week for the heck of it. =) Good luck, all! -- [[Voidious]]

A bit late reaction because I missed your post above. The main reason I took Gruwel to make my first twin and not Griezel, was that I expected it to perform better. Most of the better meleebots have their movement tuned to not getting targeted. In the TwinDuel you have only one enemy, so you will always be targeted. As running away is not really possible, being agressive hopefully throws off your enemy's movement. Next to that the gun is much more important than in melee. The TwinDuel can still be played as OneOnOne, as long as you have a teaspoon full of team-awareness and a meleeradar. @[[Voidious]]: isn't it time to retire [[Codious]] and enter a tuned [[Luminarious]]?
As for GrauwuarG, I can't get it to do what I want, so I spent the little time I have on chasing [[Tigger]] -- [[GrubbmGait]]

Yeah, you have a whole lot of good points there. It's certainly a unique thing between 1v1 and melee. Probably the main reason it feels more "like melee" to me is because, for me, the key difference between 1v1 and melee is that you have perfect data available to you in 1v1, so you can act on basically pure statistics at all times. To not have perfect stats makes a ''huge'' difference in how you design a tank - instead of designing the best algorithm to deal with all your data, you have to come up with systems that deal well with a variety of situations without knowing everything about it first. And you're right, I should retire [[Codious]] and make a melee-aware [[Luminarious]], or maybe revamp [[Codious]] with [[Luminarious]] as a base... -- [[Voidious]]

Sorry for no [[TwinDuel]] this week, but I was a bit busy with various things and there were no new entries. If there's interest, I'll run a replacement tourney today or tomorrow. (And it could just be ''me'' that's interested. =)) -- [[Voidious]]

I don't plan on skipping the TwinDuel again this week, but if I don't have power by the time I get home from classes today (on campus now), I won't be running it until this weekend... -- [[Voidious]]

Just a note that I'll be running this week's TwinDuel shortly, once LuminariousDuo has been tweaked to beat everyone =) I kid, but I do have a nice update to it for this week. Good luck all! -- [[Voidious]]

Are there any other formats that some of you would be interested in using for a weekly or bi-weekly tournament? It's a relatively small amount of work for me to write the code to automate the whole thing, and I am generally willing to commit the CPU time needed for it. We could make it and the TwinDuel bi-weekly on alternating weeks if it were a strain on my time to run them both.

Is anyone interested? And what might be some fun and (at least somewhat) unique formats we could try? Or is everybody busy with the current RoboRumble@Home divisions and not interested in this kind of thing?

-- [[Voidious]]

* I would surely enter a MegaTwinDuel competition!
* A Mixed2on2 where bots from different Authors are playing together would be fun too! But no code restrictions please :) --[[Krabb]]

I would gladly run a MegaBot TwinDuel tourney, though I'd like to keep the current division around as is, too. If the teams ended up really slow, as MegaBots tend to sometimes, maybe we could decrease the # of rounds. We could also consider throwing the "mini" twins in the mega competition, or maybe only if the author expressed an interest in doing so.
* If we start a Mixed2on2 competition i would drop the MegaBot TwinDuel tourney, the first one sounds more interesting. --[[Krabb]]

The mixed 2 on 2 seems like a neat idea, too. Are you thinking like an author would write a single bot, and it would be randomly paired up with another bot in each match? That seems like a really interesting idea... Maybe we could develop a "base class" that does some information sharing that everyone would extend from? Then everyone would have access to at least some common team information, like where the teammate is, maybe who they're targeting, sharing scans, etc.

-- [[Voidious]]

Nice description :) I think we should keep the base class really elementary, the bot should react on the enemy's behavior and this should not be that easy! --[[Krabb]]

No updates from anyone, again, but I'll get this running in a few minutes. Had to take the MacBook in for repairs on the [http://www.macbookrandomshutdown.com Random Shutdown] issue - how's that for irony? =) Trusty Linux box is a bit slower, but should be no problem to run the TwinDuel from it this week. Good luck all! -- [[Voidious]]

I'm starting work on my TwinDuel robot, it will be called Inevitable, and will just be two of the same robot, I have some cool stuff planned. -- [[Chase-san]]

Okay, I'm in, I listed my bot as a wiki bot as its based off RaikoMicro (abiet a greatly modified one), my goal was to try to make two bots that worked together as best they could to bring down a single enemy then pick off the other. I'll add my team (if applicable) to the list.
The team is at http://jad.tfsnewworld.com/bots/wiki.twin.InevitableTeam_0.1.jar
-- [[Chase-san]]

I might be able to get some people at my school interested for next week. I'm giving a talk on Wednesday that will hopefully get some of them hooked. =) I'll do it in any case. --[[David Alves]]

@David: If it would help, we could have a "beginner's division" for the TwinDuel, or you could take my tourney running utility and run some yourself just for them.

Looks like [[Kev]] and I have both updated our teams to be title contenders this week. Out of fairness, I'm not testing against his new GeminiTeam before the tourney, so I'm excited to see which of us will come out on top, or if [[KomariousTeam]] will get lucky and make it 4 in a row =) Nice to see a new team this week, too, from [[Chase-san]]. Round robin will be starting at 5 pm Eastern, good luck dudes!

-- [[Voidious]]

An interesting observation: a team of 2x [[Shiz]], weighing 749 bytes, beats the current LuminariousDuo. That and 2x GlowingHawks were the original makeshift teams I tested against, but I haven't been lately. Lumi used to beat them both ... it's interesting that by far the best version yet of Luminarious in the TwinDuel now loses to Shiz. -- [[Voidious]]

No new entries this week, but I'll get the round robin going... Good luck everyone! -- [[Voidious]]

I am going out of town this week (Wednesday), so I'm not going to run a tourney this week. If somebody wants to run it, they are free to, just let me know and I'll forward any new entries to you. (You'd also want to grab the [http://www.dijitari.com/void/robocode/TwinDuelUtil_001.zip TwinDuel Utility] to automate the round robin.) Otherwise, with Thanksgiving next week, I'll just plan to run the next one on Tuesday, 11/13, and then resume the Thursday schedule the following week. -- [[Voidious]]

I am running the TwinDuel for this week right now. Sorry I forgot about that one last Tuesday, but no new entries anyway... Good luck all! -- [[Voidious]]

I decided to awaken things and add a pair of [[Shiz]]es to the mix. The real fun now is that they create a cycle in the who-beats-who graph :-) -- [[Kawigi]]

Awesome! =) I guess it's time to get back to work on LuminariousDuo 1.01... maybe for next week, too many finals to worry about right now. I'll get the round robin running around 5:00 pm EST. Good luck, all! -- [[Voidious]]

Welcome back [[Kawigi]]! I am glad you got interested in Robocode again. It's amazing what an (non-tweaked?) melee-expert twin can achieve against those one-on-one rip-offs. -- [[GrubbmGait]]

I think [[Shiz]]'s movement is a little bit weighted against head-on targeting, which is why it performs so well here. That and the very simple knowledge of the difference between avoiding the enemy and avoiding the teammate makes it coherent enough for almost any team setting (and it would probably do well in TwinMelee, if such a competition existed). Perhaps with [[Coriantumr]]'s gun, it would perform more consistently against other near-top teams. I'm not really sure that I'm "back" into Robocode, I have way too many hobbies currently as it is ;-) Just checking in on what you all are doing. The problem is that while I enjoy these little experimental leagues (and I'm not as attracted to the barrier of reentry I perceive in 1-on-1), I think I make them less fun for others (has anyone beaten [[Girl]] yet?). -- [[Kawigi]]

I don't think anyone's tried to write a serious ExtendsRobot bot since Girl. Welcome back! --[[David Alves]]

I wouldn't worry about making the TwinDuel less fun by whooping us =) For one, it's not overloaded with activity as it is... also, I, for one, would welcome the challenge! If anything, I think it would encourage more activity if you came along and rocked everyone in this competition. -- [[Voidious]]

Got things started for this week (12/14), but I'm also working on a project for school that's due at midnight, so the results might not be up until a bit later than normal. Good luck everyone! -- [[Voidious]]

I'll try to resume the regular schedule tomorrow - sorry about the 2 weeks with no tourney! (As if anyone noticed... :P) -- [[Voidious]]

Got the round robin going about 20 minutes ago. I'll have some result up in an hour or two. Good luck all! -- [[Voidious]]

Getting the round robin started for today (1/10), sorry for the late start... -- [[Voidious]]

Any [[TwinDuel]] today? I like winning :-) -- [[Kawigi]]

Yes, starting the Round Robin right now. Sorry I never got one going for last week, I kept putting it off and then never got around to it. Good luck all! -- [[Voidious]]

I just ran a battle vs a ShadowTeam (two shadows), and MarioBros. MarioBros bearly wins, but the Shadows gets the most Survival 1sts.
{| border="1" cellpadding="3" style="border-collapse: collapse; font-size: 85%; color: black"
|Rank
|Robot Name
|Total Score
|Survival
|Last Survivor Bonus
|Bullet Dmg
|Bonus
|Ram Dmg*2
|Bonus
|Survival 1sts
|Survival 2nds
|-
|1st
|Team: kawigi.twin.MarioBros
|22471
|9100
|1180
|10763
|1428
|0
|0
|34
|41
|-
|2nd
|Team: abc.ShadowTeam
|21246
|5900
|920
|12642
|1784
|0
|0
|41
|34
|}

I probably have the better TwinDuel movement by a bit, but he has the better duel movement/gun :-) -- [[Kawigi]]

For what it's worth, ShadowDUo absolutely crushes LuminariousDuo, usually like 71 - 4. Very impressive results for MarioBros (I got 46 - 29 when I ran it). -- [[Voidious]]

I am working on a new team and I have all the base logic done with only 1616 bytes to play with. Thier called Shade and Umbra. Be called the DarkTwins. I was gonna call them team ShadowSpawn, but thats probably too much of a name to live up to (and personally I think its rights belong to Abc). I will probably enter Shade (in modified form) into melee if I get around to it. --[[Chase-san]]

I considered entering Mario in 1-on-1 and melee as well, although I'd prefer if it was a MiniBot (which it isn't right now). -- [[Kawigi]]

By the way, differences in performance against [[Shadow]] may have to do with whatever your CPU constant was set to. [[MarioBros]] is a lot faster than [[Shadow]] :-) -- [[Kawigi]]

Meh, EclipseTwins; Penumbra and Umbra currently loses to TwinintelligenceTeam. 25 to 50, but then again its using FunkyChickens movement. They use a collective patternMatcher, each bot watches one of the enemies (unlike envitables which watch the same one), and then teams on one of them using data gained from the other(meaning no gaps in scan data!). Once I get some real movement into it, I expect them to alteast outrank my old InevitableTeam.

Getting the round robin going right now for today (2/1). No new entries, so MarioBros should demolish us all again, but I still intend to update LuminariousDuo eventually, I swear. :) -- [[Voidious]]

See, when I enter these smaller tournament-style things, I suck the updates out of everyone (j/k). -- [[Kawigi]]

I have but one thing to say to that: [http://www.dijitari.com/void/robocode/morbo_destroy.mp3 morbo_destroy.mp3] ... (I'm only a recent OS X convert, so forgive my lack of command of the audio apps. :P ''Edit: Good opportunity to find some good free apps - now it's an MP3.'') -- [[Voidious]]

Getting the round robin going for today (2/8) here. I did work on LuminariousDuo some early in the week and made some progress against MarioBros, but not enough to pose any real threat. Still, was good to work on it some and I am entering 1.01 this week. Best of luck, all! -- [[Voidious]]

Good to hear, awaiting the results :-) -- [[Kawigi]]

Man, I really gotta just write the bracket tourney into my TwinDuel util. Maybe for next week... ;) -- [[Voidious]]

No new entries this week. I'll be getting the round robin going shortly. -- [[Voidious]]

Just a heads up that I am going to have to delay the TwinDuel until Friday of this week due to some other engagements... -- [[Voidious]]

Oh come on, what else could you possibly have going on that would be so important? ;) -- [[Simonton]]

<nowiki>*cough*</nowiki> -- [[Kawigi]]

Getting the round robin started now. :) (Just got back from dinner.) One update this week from GrubbmGait. -- [[Voidious]]

Sorry for the delay (if anyone's paying attention) - gonna post round robin results and run bracket tourney momentarily. -- [[Voidious]]

Sweet, I've just finished getting the whole bracket tourney completely automated (the round robin already was). About half the coding time was spent doing the basic bracket tourney based on the round robin results; the other half was spent doing a non-ugly implementation of the "last round is best of 3" =) Anyway, it's done. The only thing not handled is if the best of 3 in the finals results in an overall tie, but I figure I don't mind running that manually if it ever actually happens. =)

What actual impact does this have on anything? Perhaps not much just yet, but: I'm less likely to delay / be late running the TwinDuel each week; I could easily run a much larger tourney over night if we had significantly more teams or added more rounds to the round robin; I save about 45 minutes each week of manually running battles =); and maybe somebody else will find the source useful for their own tourneys. I'll post the source soon.

-- [[Voidious]]

Good to hear! Now the next step is getting the results to be uploaded automatically :-) (that was one of the charms of the [[RobocodeLittleLeague]]) -- [[Kawigi]]

I'll get the tourney started in about 15-20 minutes as I'm leaving for dinner. New entries from GrubbmGait and myself. I'll still post the round robin results when they're available, even though it's all one automated tourney running now. =) -- [[Voidious]]

Sorry for being so late on this today, I'll run the tourney now. I probably won't be up late enough for it to finish, so I'll post the results in the morning. No new entries this week. Good luck all. -- [[Voidious]]

Getting the tourney started momentarily. Only update this week is from me, but I still haven't caught up with MarioBros =) Good luck all! -- [[Voidious]]

A little late, as usual, but I've got this week's TwinDuel going now... -- [[Voidious]]

See previous comment =) Starting it up now, results tonight or tomorrow... -- [[Voidious]]

A day late, but I'm running this week's TwinDuel now. Good luck all! -- [[Voidious]]

I am working on a bot that might make its way here, its on a anti-gravity base (the old style). --[[Chase-san]]

Sorry, I know I'm a terrible Tourney Master these days. I actually ran last week's tourney last week but never posted the results. I'll run this week's and post them both sometime this weekend, I promise. =) I'll try and get back on the regular schedule, too... -- [[Voidious]]

Ok, I'm really truly running this week's tourney now, and will post results tonight or tomorrow. I'll also make a rare "triple whammy" update and post the tourney results for the last 2 weeks =) Sorry for the lack of discipline, guys, I hope you all can forgive me. New entry from [[GrubbmGait]] is the only one for this week. Best of luck, all! -- [[Voidious]]

Running the TwinDuel overnight, will post the results tomorrow. Got an update from me this week, but still not enough to dethrone MarioBros. Good luck all! -- [[Voidious]]

So the TwinDuel has taken an extended hiatus, as maybe somebody noticed. Is anybody interested in me starting it up again? What about a non-Codesize restricted version? There was a lot of slow time throughout the TwinDuel, but other times it was a whole lot of fun (for me, anyway), especially in the beginning. I think this style of competition has a lot to offer over the grueling world of tweaking that is the RoboRumble sometimes. And/or what about a weekly or bi-weekly tourney with a new format for each event? -- [[Voidious]]
* TwinDuel has always been in the back of my mind, but lower on the list than climbing the other ranks. So, while I hope to participate in such an event at some point, it is in the future. -- [[Simonton]]
* A non-Codesize restricted version would be nice! This would be the perfect possibility to make Garm team capable! --[[Krabb]]
* Still have a GF-gun and a tweaked movement ready for GrauwuarG somewhere underneath a pile of dust. If I can find it, find the time and also some 30 bytes, it's ready to shake up those rusty top 5 Twins! -- [[GrubbmGait]]
* What about reviving the [[HatTourney]]? --[[Krabb]]

Ok, I'll start running this again this week. I'd like to just run it while I'm at work on Thursdays, so I'll make the deadline Wednesday nights at midnight (Eastern time). If there's interest (read: an entrant over 2000 bytes :-P) I'll start a MegaBot version, too, perhaps in alternating weeks. Should I include all the < 2000 entrants in the MegaBot class, as well? ...at least at first?

Also, I just re-read that [[HatTourney]] page and that sounds like it could be really interesting. The main barriers are developing some common API and writing automation code for creating teams on the fly. I think it'd be really fun, though, and you'd get a lot of cool matchups. The API could be very simple and still be useful.

-- [[Voidious]]

We had a discussion about [[HatTourney/MessageFormat|message formats]]. I'd be interested in participating in a Megabot Hat Tourney. Right now I'm swamped with other Java coding trying to revive a project that I worked on for three years when I was just learning Java. I am pretty embarassed by the coding style, though the thing was very complex and worked well. I am trying to remove the database calls from the JSP pages, for example. But I digress. 
I would have incorporated this more into Ugluk but I hit a snag with serializing messages for transmission and I think I just gave up after a while. If we could collaborate on a standard message format, perhaps with some additional "commands" to show intent (e.g. "shoot this target" and "radar sweep this target" to allow both opponents to be scanned while focusing fire on one), that would make the rest smooth sailing. - Martin
*Actually it looks like most if not all of the work has been done for the common message transmission, though I didn't really look closely at the code. -- Martin

Just a reminder that I'll be running a weekly TwinDuel again as of tomorrow. My money is still on [[MarioBros]] =), but maybe I'll take a break from the DC world to try and bang out some changes to LuminariousDuo. Also, I should clean up this page a bit. -- [[Voidious]]
* You could give them DC guns ... -- [[Simonton]]

If I recall correctly, Luminarious had DC guns initially, but Voidious switched to GF because DC took up too many bytes. --[[David Alves]]

Yep, they sure did. VisitCountStats was a lot smaller and the same (or better) performance, if I remember correctly. -- [[Voidious]]

----

Just a note that the TwinDuel is gonna be a bit delayed today. My MacBook has a messed up fan that sounds like a jet engine (and is going in for repair soon), so I didn't want to leave it running on there while I'm away from home. I'll run it (probably on another machine) when I get home today. -- [[Voidious]]

I had lots of JVM issues with getting Robocode running last night on my temp machine, but I managed to figure it out today. I'll get the TwinDuel running shortly. The only new entry this week is from me. Good luck all! -- [[Voidious]]

You can remove the bot I entered if you like, it is been soundly trounced. I might start looking into melee soon, as One on One just doesn't seem to be doing it for me. --[[Chase-san]]

I'll be getting the TwinDuel going shortly. New entries from me and GrubbmGait this week. Good luck, all! @Chase: I'd just as soon leave it in unless you want it out, it's nice to have some variety. -- [[Voidious]]

Mmkay, but as soon as I get my melee pathfinder done (its like anti-grav and min risk, but it maps out its path based on a weighted node map (yes neural in nature)), I might if it can be shurnk enough, enter it (assuming it does okay in melee). --[[Chase-san]]

Sorry, but I encountered a but in my TwinDuel tourney automator during the last run, so I need to fix it and rerun it. I think it must be a pretty obscure one, because I've never seen it before and it would be pretty obvious if it were happening regularly. Hopefully I'll have it fixed today or tomorrow. -- [[Voidious]]

So I fixed a bug in the TwinDuel bracket tourney. The net effect of the bug is it assumed the first bot listed (usually the higher seeded one) would get the higher score - as in score score, not survival - and show up first in the results table. Obviously a really bad assumption (and not one I actually ''made''). At least it's nice to note that I started automating the bracket tourney sometime after MarioBros came along, so I don't think I've affected the tourney winner with this too often (if ever). Anyway, it's fixed now! -- [[Voidious]]

TwinDuel for today (Nov. 8 2007) starting now, results posted in a bit... -- [[Voidious]]

I missed last week because of the holiday, but I have no excuse for this week - I'll get the TwinDuel running soon and post the results later tonight or tomorrow. Good luck dudes! -- [[Voidious]]

I need to make a new one of these, I have been putting some time into the movement lab, and some into the radar and team management area's. I think to test it all out I could dump it into a twin-duel bot (if it all fits). --[[Chase-san]]

Still no new entries - starting this week's TwinDuel now. Good luck dudes! -- [[Voidious]]

* NightAndDay '''will''' be ready for next week. All that's left to do is tune the minimum risk movement a bit and have some way to stop it from getting stuck at local minimums so easily, probably just weighting the one attribute higher. I've still got 500 bytes free, so I might even be able to change it to DynamicClustering. It's REALLY slow, though. Aiming only <code>if(getGunHeat()/0.1 <= MEA/(Math.PI/9 - Math.PI/18))</code> should fix that. -- [[Skilgannon]]
* Wouldn't pi / 9 - pi / 18 just be pi / 18? Anyway, definitely looking forward to seeing NightAndDay in action. =) --[[David Alves]]
* Yeah, it would, but it gets compiled to that anyways, and I think PI/9 - PI/18 makes it more readable (ie. max gun turn - max movement turn, which is minimum possible gun turn per tick). -- [[Skilgannon]]
** Just use a comment, as far as codesize is concerned thier free. --[[Chase-san]]

Firing up the TwinDuel for this week. There is a new entrant from [[Skilgannon]], [[NightAndDay]] - cool! Best of luck to all! -- [[Voidious]]

Sorry, got a bit sidetracked after work - TwinDuel for 1/3/08 starting now. Good luck all! -- [[Voidious]]

A day late, but I've got the TwinDuel for this week running at home. I'll post the results when I get home in a few hours (around 6:30 EST/GMT-5). Good luck, all! PS - I hope that Chase and Skilgannon's entries work ok with RoboRumble 1.1.3, because I didn't test them... doh. -- [[Voidious]]

Wow, some tourney runner I am, I completely forgot to run it this week. Did anyone notice? =) Anyway, I'll run it after work today. No reason to deny [[Kev]] his new win streak... -- [[Voidious]]

Hmm, one question I just thought of for this. Is it allowed that one robot be a droid? I don't see anything against it in the above rules but wonder if this might be 'against the spirit' or not ;) -- [[Rednaxela]]

Well, the rules don't mention it specifically, but I say go for it. =) There was some talk of droids in the [[TwinDuel/2v2CompetitionIdea|original discussion]] where we started up the TwinDuel, but it sounded like everyone was fine with them being allowed. -- [[Voidious]]

Okay, done! :) It will be interesting to see how LunarTwins fares considering it's guns just consist of one using CircularTargeting and the other using HeadOnTargeting... Anyways, could you add my entry of LunarTwins (The download url is on it's page) for next week's run? :) -- [[Rednaxela]]

Just in case you don't see it in the LunarTwins page, I just made a new release, WaveSuffering with RougeDC got on my nerves, so I took a break to improve the refreshingly non-adaptive LunarTwins ;) -- [[Rednaxela]]

I feel like Robocoding TwinDuel teams finally :) --[[Starrynte]]

I've got this week's TwinDuel running right now, so I'll post results this evening when I get home. Also, is this thing on? Haven't seen any updates in a couple days - I hope the wiki ain't broken! Guess I'm about to find out. =) -- [[Voidious]]

Yep, still working.... I've been so busy I haven't had time to do any work on bots. I'm still checking in regularly though. -- [[Skilgannon]]

Twin Duel/Archived Talk 20090807

2009-10-08T03:52:08Z

Robobot: moved Twin Duel/Archived Talk 20090807 to Archived talk:Twin Duel 20090807: move to talkarchive

#REDIRECT [[Archived talk:Twin Duel 20090807]]

Archived talk:Tityus 20090519

2009-10-08T03:52:05Z

Robobot: moved Tityus/Archived Talk 20090519 to Archived talk:Tityus 20090519: move to talkarchive

{{Navbox small
| title = Tityus Sub-pages
| parent = Tityus
| page1 = Version History
| page2 = Archived Talk 20040104
| page3 = Archived Talk 20090519
}}
{{Talkarchive|Talk:Tityus}}

*Applause* Ninth place! Damn that new movement is good. Beautifully simple, too. Well this definitely raises the bar for Raiko. ;-)

Thanks! Yeah, the movement is promising. It's actullay the same movement as 0.6.2 just differently tweaked. And the current version is far from perfectly tweaked. I'm applying alchemistry now to find the right formula. =) -- [[User:PEZ|PEZ]]

Amazing!! You've taken number 3, and it looks stable! Your graph is incredibly funny. :-) Congratulations! I think this heralds a new era in Robocode. Multimode is back, and back with a vengance. - [[User:Jamougha|Jamougha]]

Eek, I hadn't looked at the minibot rankings. 40 points above Verti?? :-D - [[User:Jamougha|Jamougha]]

Hey, I thought [[Swiffer]] was the return or the MultiMode era. =) But you are right. It took a really brilliant idea (of [[User:Axe|Axe]]'s) to really break the barrier. I think this shows that the ranking system is a bit funny. Yeah, a look at Tityus LRP graph really shows it. I might have a less funny looking graph if I do the trick Axe's way, instead of my home-brewed one where I sacrifice the first two rounds against bots that don't hesitate shooting full lead. This makes me lose valuable points against many good bots. I have 1851 points with 358 battles fought at the time of this writing. With a negative momentum, so it might be #5 or something for T this time. But next version should fight better for the #3 spot I hope. 40 points ahead of Verti? That probably will settle too. But I would like to have both #1 and #2 a while. Something to use for wall paper. =) -- [[User:PEZ|PEZ]]

Quoting [[User:Sparafucil3|jim]] again: "Hey!!! I was quoted. This might be a first." (That makes 2 quotes for [[User:Sparafucil3|jim]] X 1 quote for me :). I am very proud that i can pay back all of the great ideas that u all gave to me. I think that this is the spirit: "No Fear From The Sharing"!! Congrats!!! U surelly deserves be fighting for the crown! Watch out [[Paul]]!! -- [[User:Axe|Axe]]

Excuses, watch out [[User:Iiley|iiley]] too :)... -- [[User:Axe|Axe]]

I think that i have a good idea too for that decaying problem in [[MultiMode]], i have a large experience with multi gun thing. The problem is the switch in the best time, that is: the decaying... I will be sharing it at [[Musashi]]'s page shortley. -- [[User:Axe|Axe]]

What decaying problem? I must have missed something.

It seems T0.6.8 gets the same rating as did T0.6.7b. The graphs are pretty different. This is interesting. It seems my own implementation to tricking head-on guns was more accurate than [[User:Axe|Axe]]'s. But it came with a heavy price tag of giving two rounds away to the stronger bots. Since [[User:Axe|Axe]]'s function is so elegant and to-the-point and the end rating is the same I'll keep it. I don't like losing to the strong bots even if it makes me win bigger against the weak. -- [[User:PEZ|PEZ]]

Tityus 0.8.1 which is a blend of T0.6.3 movement, T0.6.5 gun and the MusashiTrick, rates in at 1854. And as I suspected it was the small (I thought) gun changes in T0.6.6 that was letting me down. It was also why the graphs looked so funny. Now the graph iswellbalanced and neat, and you can see the head-on targeters pretty easily. =) I often give, and seldom follow, the advice to not work with targeting and movement at the same time. Now, that advice is really worth something! -- [[User:PEZ|PEZ]]
----
I tried the shrinking tips [[User:Jamougha|Jamougha]] gave me on the VertiLeach page on this bot and it saved me 47 bytes. Maybe I should do something more to reach those 60-70 bytes? In any case, now I have 115 bytes free. Anyone has a suggestion on what I should do with them? -- [[User:PEZ|PEZ]]

Mmmm, let's see, you still have Point2D wGunLocation = new Point2D.Double(); in your wave class, and you don't need to initialise wGunLocation here. If you bring your shoot() method back into onScannedRobot you can make lastEnemyAbsoluteBearing local. Unfortunately your nice code structure makes it hard to do much more shrinking. :-) At least you found something to use up the bytes, heh. - [[User:Jamougha|Jamougha]]

Thanks. It's funny this shrinking voodoo. I removed the redundant initialization of wGunLocation and it didn't save a byte. The Wave class was still 69 bytes. Then I tried to compile it on a Windows PC with the bundled jikes compiler. The main class then shrinks 12 bytes and the Wave class grows to 73. But on the PC the Wave class shrinks to 57 if i remove the initialization. Which means compiling on the PC saves me in total 24 bytes. Together with some other canges and removing the DynamicGuessFactors again I now have 166 bytes free for the next version of Tityus. I am figuring on if Ishould use them for movement or targeting. I think I will choose the movement path. The bad thing is I will have to do the compiling on the PC... -- [[User:PEZ|PEZ]]

What happens if you mix and match the class compilation - compile some classes on pc - others on your normal system - and bring them back together when packaging. -- [[Paul]]

That should work. However, in this case both classes gets smaller on the PC. But I'll keep that in mind. I have seen that in same rare cases some classes get smaller on the Mac. Codesize limited coding is a pretty stupid thing to do anyway. I guess I must suit myself for getting bothers like this. =) -- [[User:PEZ|PEZ]]

OK. so I got this cool movement idea from [[User:Kawigi|Kawigi]] that I just must try. I think it might cost some 100 bytes in the first try. Will take a while to tune though. I wish I could use my speedy PC for this. It would cut down my test cycles from 40 minutes to 5. ... -- [[User:PEZ|PEZ]]

If you're talking about a [[CoolMovement]] idea, it shouldn't be worth much more than 30 or 40 bytes. Of course, I say that based on my experience with using in Flood bots which are already doing interesting things with enemy fire power. It does take some tweaking for it to work, though. -- [[User:Kawigi|Kawigi]]

Scchhhh! =) We'll see about codesize, my guess is this will cost me 100 bytes. I bet you, [[User:Dummy|Dummy]], [[User:Iiley|iiley]] and other codesize experts could obfuscate it down to 30 bytes. =) -- [[User:PEZ|PEZ]]

I don't remember how many assumptions I made about default settings either, though, for instance using .1 instead of getGunCoolingRate() and stuff. -- [[User:Kawigi|Kawigi]]

Well, I'm using the API call. That should be the only assumption you could do. The rest are fixed with this version of Robocode at least and doesn't have a corresponding API call anyway. -- [[User:PEZ|PEZ]]

----

Well, so my first try with CoolMovement didn't make the bot stronger. In fact it got a bit weaker and I think it's only the MusashiTrick that keeps its nose above the water. I won't give up on the first try though. It is hardly tuned at all and I know it's profile on sub 300 range is horrible. Besides [[Shadow]] seems to have problems with this movement. That's a reason in itself to keep it. =) It does cost me 100+ bytes as I suspected. But it might prove worth it if I manage to master the tuning. -- [[User:PEZ|PEZ]]

Nice scorpion. Did you make it? --[[User:David Alves|David Alves]]

No, I ripped it off of the web somewhere. I wish I could do graphics! -- [[User:PEZ|PEZ]]

Interesting update. :-) Found another bug in the gun. To get the correct guess factor it uses

<pre>Math.round(((((wave.wBearingDirection * Utils.normalRelativeAngle(
absoluteBearing(wave.wGunLocation, enemyLocation) - wave.wBearing)) /
maxEscapeAngle(wave.wBulletPower)) + 1) / 2) * wave.wAimFactors.length)))]++;
</pre>
but converting a guess factor to an angle uses

<pre>((mostVisited + 0.5) / AIM_FACTORS) * 2 - 1</pre>

which are not reversible functions. Works out it gives the wrong guess factor by one about half the time. Try subtracting .5 inside the Math.round function. Doesn't make much difference, but it's worth a percent or so on your accuracy. - [[User:Jamougha|Jamougha]]

The add 0.5 trick doesn't work for negative numbers, switch to real rounding around that statement if you can. -- [[User:Kuuran|Kuuran]]

I agree with [[User:Kuuran|Kuuran]] that rounding is better than adding 0.5 (and agree with both of you that they aren't equivalent). The reason I started rounding was because I was truncating ("rounding toward zero") to find the guessfactor but then firing straight at the guessfactor. This means I was basically always firing half a guess factor closer to head-on than the middle (and supposeable median) of the guessfactor. Not something significant, but something that may be worth 1% in the TC against the harder-to-hit bots. Side note - While my intuition tells me rounding is better, stuff like this is generally worth a TC run against one robot (I typically use DT 1.91 in passive mode for 500-1000 rounds) to see which is better. With a good test against fairly "pure" random movement (none of this crazy adaptive or self-charting stuff, a buggy gun is probably better there), the better is probably also more correct. On that note, I believe if you are using custom events for waves, you should add one to the firing time when you create the wave or always subtract one from the current time while processing it. Or it could be the other way around, but 500 rounds against movement-only DT will tell you. -- [[User:Kawigi|Kawigi]]

Thanks all of you. Long ago I used a different calculation (I think [[Griffon]] still uses that one), but I felt these were easier to read. It was [[FnH]] and [[User:Kuuran|Kuuran]] assisting me when I asked the question on [[PEZ/Question]]. Now, do I understad things correctly if my best bet is to do round(mostVisited) instead of adding 0.5 like I do above? I so wish I could run those 500 rounds against movement-DT 1.91. But the stupid bug in my PC (WinXP or Java or hardware or whatever it is) prevents that effectively. And it's painfully slow on my old laptop... But I'll have to do it I guess. =)

I had actually hoped this T should go a bit higher. [[Raiko]] style segmentation really helped a lot, but I need to dig up some more points. The only mini beating T now is BlackDestroyer it seems. Since T beats both [[Raiko]] and [[BlackPearl]] pretty good this should probably tell me something. But I don't see what it is! =) Also [[Musashi]] seems to be tough for this T. Watch this space to see what I do to counter that. -- [[User:PEZ|PEZ]]

I should have pointed out way back when on [[PEZ/Question]] that the 0.5 will create problems with negative numbers, but for some reason I didn't (maybe at the time I wasn't aware of this). Math.round() does actual rounding to the nearest, adding 0.5 does so for positive numbers, but adds 1 to negative numbers because, by default, java does truncation, which is always in the direction of 0. So 1.2 + 0.5 = 1.7 which truncates to 1, the proper rounding. If it were over 1.5 (1.6 for example) you'd have something like 1.6 + 0.5 = 2.1 which truncates to 2, the proper rounding. In negatives you get -1.2 + 0.5 = -0.7 which truncates to 0, so you can see the problem ;) Truncation is always towards 0, the addition in positives moves it away from 0 by the correct amount to round, but in negatives you're moving it even further towards 0 throwing your factors way off. Math.round() around the statement instead of the adding of 0.5 will solve that.

Err.. sorry it's late and I wasn't thinking, I initially posted that you want to round the whole mostVisited/AIM_FACTORS term, which is obviously wrong, that turns it into an on/off switch :p Something like ((double)mostVisited / AIM_FACTORS) * 2 - 1 gives you your exact guess factor from -1 to +1. You want to use that precise value to calculate the angle in this situation, there's no actual rounding required going this direction, is there? Aren't you just going to take this double value and multiply it by the full lead angle to get how far ahead/behind they're probable to be? -- [[User:Kuuran|Kuuran]]

I'm not sure the addition of 0.5 is a rounding thing. I think [[FnH]] meant to make the factor be offset half a factor. Something like what [[User:Kawigi|Kawigi]] is talking about a few lines up. This is totally confusing to me, my head doesn't cope well with things like this. So hit me hard with more discussion around it. I'm slow, but eventually I'll get it. =) -- [[User:PEZ|PEZ]]

Hrm, I'm going to take a look at the full code because it seems like I've misunderstood what's supposed to be doing what, and clearly that's not helping me make sense. -- [[User:Kuuran|Kuuran]]

Thanks! I appreciate. -- [[User:PEZ|PEZ]]

Wow, at the rate you're going you'll pass Shadow shortly. :-)

To see what I mean about the bug, try putting Tityus up against sitting duck. - [[User:Jamougha|Jamougha]]

(edit conflict)I looked it over and now I have a slightly different picture of what does what. As far as I can tell this isn't a bug, I think you're right. The gun shoots at guessFactor + 0.5 instead of directly at guessFactor on the principle that all the data in the guess factor is coming from values above the guess factor (ie: all the stuff in the third bin is coming from guess factors 3.0 to 3.9999...). This isn't true, however, because you're using Math.round() instead of a cast to int, so 3.7 or whatever else that rounds up will in fact be in bin 4. This makes each bin the median value of the guess factor, not the start value, and makes adding 0.5 to shoot at the median needless. Remove it entirely and run a few hundred rounds against DT or compare to a few of your existing TC percentages for that gun, bet you'll see a small aim improvement. -- [[User:Kuuran|Kuuran]]

Thanks! I never did like adding 0.5 without knowing why. =) -- [[User:PEZ|PEZ]]
----
Apparently RR@H hates you. I just watched smart battles run 30 battles of nothing but 0.9.2 vs Gouldingi and DogManSPE, both of which have negative PBIs ;p -- [[User:Kuuran|Kuuran]]

It shouldn't make any difference, if everything is working correctly. It would only change the ranking if T did worse than it did last time it fought them. -- [[User:Tango|Tango]]

What is smart battles anyway? I have seen that happen too at time that two bots really get to hammer out on each other. Doesn't make sense. -- [[User:PEZ|PEZ]]

Something tells me this update (0.9.3) was a huge mistake... -- [[User:PEZ|PEZ]]

Of the 0.9.x line it seems 0.9.0 and 0.9.2 were the best, depending on wether you're looking at overall scores or scores in mini. -- [[User:Kuuran|Kuuran]]

I'd say it's 0.9.1 in overall (1897 points) and 0.9.2 in mini (1907 points). But 0.9.2's edge over 0.9.1 in mini could be that I packed a few more mini-bot data files in the latter. -- [[User:PEZ|PEZ]]

I may've confused .0 and .1 there, sorry. The ones I was thinking of did have the best scores there, and yeah, in mini I remember it being very close, I guess we'll see a rollback to .1? Good luck with version 1.0.0 if that is what's next, hope to see some Raiko upsetting ;) -- [[User:Kuuran|Kuuran]]

I don't think we'll have a rollback of the code. I like how simple I got it now in 0.9.3. My hoping is that it was just me doing a bad tweak of it. 1.0.0 is where I'm heading yes. When it's able to bring home 1920 points in general roborumble I'll name it 1.0.0. Passing [[DT]] 2.41 with a mini would be so sweet! =) -- [[User:PEZ|PEZ]]

Now, a rollback of the code might be what I should do. I'll do two or three tests with this new system and if they don't work out I go back.

What should I do about the mirroring bots? I know stupid me gave [[User:Axe|Axe]] the advice to outmove and outgun the mirrorers. I wasn't aware then that my problem bot list does not only contain pattern matchers but also mirrorers. I can't fit an AntiMirror gun. Someone has another idea for strategy?
-- [[User:PEZ|PEZ]]

What about stop moving and fire(3) at you opponent if it is a real and pure mirrorer. --[[User:Deathcon|deathcon]]

If the mirror also does fire(3) I'm not all that well off am I? But something along these lines might work. Problem is it eats up quite a few bytes to check if I'm mirrored. -- [[User:PEZ|PEZ]]

Adding in a dedicated AM system is probably beyond the scope of a mini that wasn't designed with it in mind from the start. Best bet might be to tweak your gun segments so they're particularly strong against your movement, you know when and where your movement is liable to show weakness, adjust your gun to see those situations easily and you should be alright against anyone who wants to borrow it. Even just tweaking the granularity of segments to match how your movement changes would be a good idea. -- [[User:Kuuran|Kuuran]]

AntiMirror guns, although fairly simple in themselves, are very hard to implement into a bot, because the gun and the movement are usually separate. Maybe you could just make a new movement system that only kicks in when it detects mirroring, and just make it very predictable (by you, not the enemy) so you can work out where the enemy will be and shoot it. The difficulting is fitting an extra movement system into a minibot... good luck. -- [[User:Tango|Tango]]

Well, it doesn't fit in T I can tell ya! It already packs more features than most other minis. But I thank you all three for your suggestions. I think I can make something out of them. Kuuran's observation alerts the problem I create by using the same bot for graphing when tweaking it's movement. Of course I create the ultimate Dodge Tityus movement then. And of course I get into big problems with mirrorers. -- [[User:PEZ|PEZ]]

Indeed, the prevelance of personal grapher bots is my theory on why mirrors are suddenly a huge thorn in everyone's side. If I ever do get into larger bots where movement is paramount I'll probably grab a gun out of some top level OpenSource bot to plug into my grapher. Going the other way around, tweaking your gun on your movement, is probably a safer bet, as you'll do well against all the mirrors out there; where if you tweak your gun against some other bot you'll only be tweaked for that one bot, instead of multiple mirror bots. Since your movement is using the same strong, smooth, flat ideas as most of the top movements, a gun that hits it well should hit most top bots well anyway. -- [[User:Kuuran|Kuuran]]

One solution is to add a segment based on how long you are going to continue in the same direction. This helps against all cannibals, e.g. Verti, and helps slightly against other bots if done right; I've been playing with the idea of using it. Of course you would need to change the implementation of your movement to do this. - [[User:Jamougha|Jamougha]]

A couple versions of VertiLeech ago, I tried a segmentation based on the clock direction I was trying to go vs. the clock direction my opponent was going (either same direction or opposing directions). It was enough to make that version of FloodMini beat VertiLeech (although it may not be enough anymore). You could try something like that. Of course, it may be no better against a true mirrorer than some acceleration segmentation. -- [[User:Kawigi|Kawigi]]

About your 0.9.5 version problem: R u still using MusashiTrick? If u are it seems not to be working properly, see your ratings against [[Barracuda]] and [[Wesco]] for example... -- [[User:Axe|Axe]]

No, I'm not using it. But I thought I had replaced it with something that should work as well. Appearantly not. =) Thanks for letting me know! -- [[User:PEZ|PEZ]]
----
[[User:PEZ|PEZ]], could you explain formulas in the code below?
<pre>
double reverseFactor = 0.1 - Math.pow(enemyDistance * (enemyFirePower + 1.1), 0.82) / 7750;
if (enemyFirePower <= 2.3) {
reverseFactor = 0.107 - Math.pow(enemyDistance * (enemyFirePower + 2.1), 0.83) / 8000;
}
</pre>

--[[Ph]]

Nope! It's about flattening of course. Tityus is a RandomMovement type of bot which means it continously asks itself the same question. How probable should it be that I change orbiting direction this tick? The main two factors to consider is the distance we have to the enemy and the velocity by which its bullets are traveling against us. I wanted this porbability to fit a non-linear curve and then I used Excel to experiment with different formulas to achieve it. But then the curve isn't perfect of course. Because of walls mainly. So from there it was about experimenting with different coefficients. I actually breeded several hundred versions of T and let them fight a TestBed of bots to feel more comfortable that I had got it right. To look at a more scientific approach look at [[Raiko]]. It uses T's WallSmoothing technique and the same basic how-often-should-i-reverse question. But it's using a formula that surprisingly simple. And this with as good results as T gets. -- [[User:PEZ|PEZ]]

Tityus/Archived Talk 20090519

2009-10-08T03:52:05Z

Robobot: moved Tityus/Archived Talk 20090519 to Archived talk:Tityus 20090519: move to talkarchive

#REDIRECT [[Archived talk:Tityus 20090519]]

Archived talk:Tityus 20040104

2009-10-08T03:52:04Z

Robobot: moved Tityus/Archived Talk 20040104 to Archived talk:Tityus 20040104: move to talkarchive

{{Navbox small
| title = Tityus Sub-pages
| parent = Tityus
| page1 = Version History
| page2 = Archived Talk 20040104
| page3 = Archived Talk 20090519
}}
{{Talkarchive|Talk:Tityus}}

In the scanned robot event you have :
<pre>
setTurnGunRightRadians(Utils.normalRelativeAngle(
enemyAbsoluteBearing + maxEscapeAngle(bulletVelocity(enemyFirePower)) *
sign(deltaBearing) * mostVisitedFactor() - getGunHeadingRadians()));
</pre>
should that be bulletPower instead of enemyFirePower? Was wondering why it wouldn't beat DuelistMicro... :)

- Jamougha

Phew! Thanks for telling me. I often have problems against the small Duelists, but this bug might be giving it an unfair advantage. =) -- [[User:PEZ|PEZ]]

Now a new Tityus is out there. I added it to the RoboRumble@Home again now that it might have a chance to enter the top-30. I'm curious [[User:Jamougha|Jamougha]], how come you tested Tityus? It has been dormant for some while now.

[[User:Kawigi|Kawigi]], if you read this, please update Tityus before the next season of RobocodeLittleLeague. It might be version 0.5.1 or 0.5.2 then, if I find something to tweak. =) -- [[User:PEZ|PEZ]]

I've been coding away from home, and rather than re-write my old gun I decided to borrow one for the duration; Tityus' is almost identical to mine, though much more elegantly written. I was quite shocked when it did worse than head-on targeting :) but I fixed and changed a few things.
Congrats on the #8 re-entry, btw! - [[User:Jamougha|Jamougha]]

You are entirely welcome to borrow Tityus gun. Just remember it's [[RWPCL]] so you must show what you changed. =) Again thanks for helping it recover from that ugly bug. I was very, very frustrated when T started to fall down the rankings and I couldn't fix it. Seeing the company in the top-10 in mini #8 isn't too bad! -- [[User:PEZ|PEZ]]

Thanks, I may just keep using it and release the bot as open-source in a few days. Right now it barely beats 0.5.1 over a thousand rounds, and my movement is definitely not as good, so I figure you can get Tityus up a few more places yet. :-D - [[User:Jamougha|Jamougha]]

I'm sure [[Tityus]] gun can be improved. It's not exactly the best gun around. =) But I'm not sure [[Raiko]] beating T 0.5.1 over 1000 rounds really shows this. It depends on what you aim at. Tityus gun is opted for RoboRumble@Home short battles. Then your high segmentation might slow learning a bit. But it pays in long battles for sure. And even if T 0.5.1 movement is better than [[Raiko]]'s (which I am not sure it is) it might not be better against T's gun. None the less I will look at [[Raiko]]'s gun and see what I could consider to tweak in my gun. This is the beauty of open sourcing a bot. I would never have found that bug without your help and the gun will surely evolve faster with two or more people using it than with just me. I hereby promise never to close the source of any of my bots again. -- [[User:PEZ|PEZ]]

Yeah, open source is great. Saved me a good few days. ;-)
I've had problems with over-segmentation in shorter battles too. For over a week my best gun vs most bots was completely unsegmented! Now that you're firing a wave every round you have a lot more leeway, though. Segmenting on whether or not a bot was approaching the walls was a big breakthrough for [[Raiko]], do try it in Tityus. The other segment is a load of junk. :-)
Hmmm, the nicest thing would be to have oodles of segments and remove most of them depending on how much data is in the bucket. Unfortunately I don't think I can fit that into a mini, but maybe for [[Raiko]]'s eventual big brother. - [[User:Jamougha|Jamougha]]

[[FloodMini]] does that segmentation, but it's the first one I take out when I do guess-factor guns in Micros, not because it's not good (it helps against bots like Cigaret if I remember right, it was the segmentation that got me beating Cigaret, which was a couple versions ago of both bots), but because bots don't spend as much time in different segments there. -- [[User:Kawigi|Kawigi]]

That's an interesting observation. Maybe it's that different segmentation is needed? Like wall proximity and such. I'll try such a segmentation in [[Tityus]] once I have gotten the movement to work. Once you have a basic gun, movement is more important for your performance than targeting. -- [[User:PEZ|PEZ]]

A real basic gun may also leave you with glaring weaknesses, but a reasonably segmented guess-factor gun without any coding bugs usually doesn't generally have that problem. And adding a segment for whether or not the opponent was approaching the wall jumped FloodMini from 30th to 12th in the ER (in retrospect, I'm surprised it made such a distance - more than half-way to the top). -- [[User:Kawigi|Kawigi]]

For the record. With "basic gun" I meant a "reasonably segmented guess factor gun". I'm not one of those counting GF targeting as "advanced". It's simpler than most other techniques. -- [[User:PEZ|PEZ]]

[[User:Sparafucil3|Jim]], if you test BlackPearl .69 against T 0.6.2, remove T's data file on BP first. I accidently packaged it with a saved file from a 1000 round battle against that BP. It was my last test before releasing... Oh, yes, BP won that fight pretty comfortably. -- [[User:PEZ|PEZ]]

Tityus/Archived Talk 20040104

2009-10-08T03:52:04Z

Robobot: moved Tityus/Archived Talk 20040104 to Archived talk:Tityus 20040104: move to talkarchive

#REDIRECT [[Archived talk:Tityus 20040104]]

Archived talk:Thorn 20091005

2009-10-08T03:52:02Z

Robobot: moved Thorn/Archived Talk 20091005 to Archived talk:Thorn 20091005: move to talkarchive

{{talkarchive|Talk:Thorn}}

Hey, you did it! =) Top spot with a first version is way cool, great job. -- [[Voidious]]

Thanks! It's amazing how easy it was when I had two top-level bots to work off. -- [[Kev]]

Not sure how much of a fluke this was, but...
<pre>
Fighting battle 6 ... kc.micro.Thorn 1.2,pe.SandboxDT 3.02
RESULT = pe.SandboxDT 3.02 wins 2769 to 2763
</pre>
That is just incredible for a MicroBot! Keep it up, man...

-- [[Voidious]]

Unfortunately, it still lost quite a few points in the rumble. I'm suprised because 1.2's scores were way better than before in the movement challenge tests I was doing. I'll submit an expanded version of it's [[FlatMovement]] to the [[TargetingChallenge2K7]] since I think it is one of the hardest non-surfing bots to hit. -- [[Kev]]

Nevertheless, I'd say DT sacrifices some rating for PL prowess itself, and even the top MegaBots have a hard enough time with it. If that MC score vs Dookious is consistent (from [[TargetingChallenge2K7/Results]]), I'd definitely call this the hardest to hit non-surfing movement out there right now. -- [[Voidious]]

ThornHT is not using the exact movement code from Thorn; the distancing and wall avoidance are a tweaked a bit and the "random factor" is calculated a little more accurately. Nevertheless, Thorn 1.2TC was getting movement scores several points higher than 1.1. Too bad it didn't translate to the rumble. I also have a hunch that [[Raiko]] might have better random movement than Thorn, but I'm not sure about it. -- [[Kev]]

Oh you didn't. Don't make me come back there. -- [[Simonton]]

Will this be the first in [[The2000Club/Micro]] ?? -- [[GrubbmGait]]

That would be awesome, but it looks like it might fall about 10 points short. Still, given the rating distribution and other factors in the MicroRumble, I think its current rating is more impressive than 2000 in General, anyway... Great job, [[Kev]]. -- [[Voidious]]

Truly, this is a VERY nice improvement. -- [[Simonton]]

Yay! Thorn's only ~10 points off of 2000 in the micro rumble, and has probably snagged the number 1 PL spot too! But I think those last points might be hard to get. And congratulations to you [[GrubbmGait]] by the way, for your rapid ascent in the micro rumble. -- [[Kev]]

Hey Kev, you don't think that the reduced rankings could be due to the fact that the entire rumble has changed since 1.142 was released? Maybe you should re-release 1.142 as 1.145, just to check where you actually stand today. - [[Skilgannon]] <who is proud of his current number 1>

I'm not sure what you mean when you say "the entire rumble has changed since 1.142 was released," but I doubt its rating would change significantly from a re-release. And congrats on your number one spot by the way... it looks like I've been dethroned from #1 in micro as well as nano :P. -- [[Kev]]

Well, [[Simonton]] dropped by about 10 points when he re-released WeeklongObsession. I'm just going on what he said. And it just goes to show, in Micro/Nano, PatternMatching is the best option =). -- [[Skilgannon]]

Thorn/Archived Talk 20091005

2009-10-08T03:52:02Z

Robobot: moved Thorn/Archived Talk 20091005 to Archived talk:Thorn 20091005: move to talkarchive

#REDIRECT [[Archived talk:Thorn 20091005]]

Archived talk:Gladiator 20071113

2009-10-08T03:51:59Z

Robobot: moved Gladiator/Archived Talk 20071113 to Archived talk:Gladiator 20071113: move to talkarchive

Welcome to the wiki! I noticed you have thought about the setup of your bot, the code is quite readable. A few remarks about its performance:
* in OneOnOne you are not moving enough and most of the time facing your enemy. Maybe you should include a (small) antigravity force at your last position.
* it seems that the gun is only turned when you are ready to fire. This causes some 'wild' bullets. Turning your gun every tick, or when the gunheat is less than 0.3 or so, should improve its accuracy.
* shooting peas (power 0.1) is not very effective. Try taking the enemy's energy into account, but also try not to disable yourself.
* in melee, try not to get distracted by an accidental hit from the other side of the field. Most of the time the closest enemy is the most dangerous one.
Note that these are just some tips after briefly watching a few OneOnOne and melee-battles, I did not dig into the code. As your bot seems to be ment for melee, check out the MeleeStrategy page. It covers everything you need to know about melee. --[[User:GrubbmGait|GrubbmGait]]

Thanks for the welcome! I have noticed that in OneOnOne my bot faces my enemy way to much, I tryed what you said and it made a BIG differance. Thanks for the tip! Also, All the other tips I have added into my bot in some way or another. I have one question though, is it better to aim at the stronger bots that are close to you, or the bots that are weak and somewhat far away? --[[User:KID|KID]]

Assuming you are talking about melee then it is better to aim at the bot which you are most likely to hit. That way you get some return on the energy you invested into the shot. That is not always dependent on wether it is closest or not (although it often is). [[User:Kawigi|Kawigi]] will most likely offer that it is better to shoot at the enemy that is most dangerous to you. I am not sure, but "[[kawigi|my boy]] is wicked smart" when it comes to melee. -- [[User:Sparafucil3|jim]]

The movement of my current meleebots is coupled to the enemy I am targeting, so therefor I favour to target the closest one. As AntiGravityMovement is less coupled to the current enemy, it could be advantiguous to target someone further away, as he is less expecting it. --[[User:GrubbmGait|GrubbmGait]]

Right now I am using <code> (enemyEnergy / myEnergy) * enemyDistance </code> to find the "EnemyRiskFactor" (this is not in v.1), then I fire at the bot with the smallest EnemyRiskFactor. I don't know how effective this is but it seems to work well, especially if the enemy is disabled or nere being. --[[User:KID|KID]]

Well, [[User:Sparafucil3|Jim]] guessed quite well what sorts of things I'd say - when I started melee I assumed that the reason targeting the closest was good was because you were more likely to hit, so I tried targeting the one that I was most likely to hit. The reason this wasn't as effective was that (indeed) clearing out nearby bots is more important if you want to survive. So the reason to target one bot over another is the benefit to you (which comes from how likely you are to hit them) and the risk they pose to you (which comes from how likely they are to hit you). Shortest distance alone can strike a fine balance there, although I don't discourage using energy as a parameter.

[[User:KID|KID]] - why is the enemy risk factor proportional to distance? Do further-away enemies pose a greater risk? I'm not sure I follow. I think you should do something more like (enemyEnergy / myEnergy) * enemyDistance. Of course, your energy should be constant for comparison's purpose, so that might as well be enemyEnergy / enemyDistance. You modify that just slightly and it starts looking like the [[MeleeStrategy/UnderstandingHawkOnFire|risk function for HawkOnFire]].

Also, make yourself a page! -- [[User:Kawigi|Kawigi]]

I spent a while toying with alternates to 'if closer than present target by x' with no success. I attempted factoring in enemy energy and my hit percentage against them and my scores dropped. It's on the back burner again for now. -- [[Martin Alan Pedersen|Martin]]

----
I got my computer up and running again, but now [[Gladiator]] 6.6g looses every meleebattle. I use Java 1.5 and have tried robocode 1.0.6 and 1.0.7Kawigi. Before uploading more results I will try to find out if the problem is my configuration, but can anyone else run one meleebattle to rule out a problem in [[Gladiator]] itself? -- [[User:GrubbmGait|GrubbmGait]]

[[Gladiator]] crashes on my mashine as well in meele Battles:
<pre>
kid.Gladiator .6.6g: Exception: java.lang.NullPointerException
java.lang.NullPointerException
at kid.Data.MovementProfile.inEvent(MovementProfile.java:60)
at kid.Gladiator.onHitByBullet(Gladiator.java:197)
at robocode.peer.robot.EventManager.onHitByBullet(EventManager.java:582)
at robocode.peer.robot.EventManager.processEvents(EventManager.java:729)
at robocode.peer.RobotPeer.tick(RobotPeer.java:1043)
at robocode.AdvancedRobot.execute(AdvancedRobot.java:139)
at kid.Gladiator.run(Gladiator.java:106)
at robocode.peer.RobotPeer.run(RobotPeer.java:633)
at java.lang.Thread.run(Unknown Source)
</pre>

thanks for the heads up, i have seen this bug in OneOnOne, and was able to fix it there. just checked my code and makes sense that it would crash in Melee too. @[[User:GrubbmGait|GrubbmGait]] - it a bug in [[Gladiator]], so it's not your fault. i'll release a new version to fix the bug. -- [[User:KID|KID]]

Congratulations! It seems that you are the first to get into the melee top-5 since . . . well, since forever. -- [[User:GrubbmGait|GrubbmGait]]

Didn't notice! Wow... I was just planning on getting backk into contention for the top ten again. Wow... -- [[User:KID|KID]]

Still a lot of opponents to face, but I think it's safe to say nice jump with .6.7. Looks like almost 8% better per opponent so far - impressive! -- [[User:Voidious|Voidious]]

Thanks [[User:Voidious|Voidious]]! I did some work with the MC2K6 and got some better scores against the simple targeters then I had before and I think it paid off! (but I still can't get higher then a 95 against BotA, Grr...) I would appreciate it if someone would look though my code (hard, I know) and see where I can improve. -- [[User:KID|KID]]

Please don't take offense to this, but it's more a matter of fixing bugs than making improvements when trying to master surfing HeadOnTargeting. Try hard coding some danger at GF-0, make sure your prediction is working correctly, and you're clearing out old waves correctly (to surf the "correct" one at all times); if all of that is working, you should get 99+ against BotA, I reckon. Check out [[Komarious/Code]] if you want to see how simply she dodges GF-0 (hard-coded), and she gets over 99%. -- [[User:Voidious|Voidious]]

No offense taken [[User:Voidious|Voidious]], but my form of [[WaveSurfing]] is more [[WaveSurfing/TrueSurf|TrueSurf]] then anything else. So, [[User:ABC|ABC]], if [[Shadow]] really is doing [[WaveSurfing/TrueSurf|TrueSurf]] like I think it is, I could use some help on how to weigh the risk for forwards and backwards. There is another movement that I'm sort of working on that is like [[Komarious]], and it gets 98+ against BotA, but is not as good against [[PatternMatching|PM]] or [[GuessFactorTargeting|GF]] guns, yet. -- [[User:KID|KID]]

[[Category:Archived Talk|Talk:Gladiator/Archived Talk 20071113]]

Gladiator/Archived Talk 20071113

2009-10-08T03:51:59Z

Robobot: moved Gladiator/Archived Talk 20071113 to Archived talk:Gladiator 20071113: move to talkarchive

#REDIRECT [[Archived talk:Gladiator 20071113]]

Archived talk:SilverSurfer 20060602

2009-10-08T03:51:57Z

Robobot: moved SilverSurfer/Archived Talk 20060602 to Archived talk:SilverSurfer 20060602: move to talkarchive

{{Navbox small
| title = SilverSurfer Sub-pages
| parent = SilverSurfer
| page1 = Version History
| page2 = Wave Suffering
| page3 = Help Requests
| page4 = Archived Talk 20060602
}}
{{Talkarchive|Talk:SilverSurfer}}

This is the bot that i´ll use to test new ideas, [[David]] inspired me to do this with his [[JALT]]. 
Just like the original Silver Surfer, i´ll send him to seek the universe for anything that can feed me. Guess who is Galactus? -- [[Axe]]

I inspired you? *cough* [[David Alves/Inspiration|inspiration]] *cough* :-D --[[David Alves]]

You know, it's really not neccesary to pimp that page, let them come :P -- [[Kuuran]]

Yeah I'm a loser like that. :-P --[[David Alves]]

Kuuran is just waiting for someone to make him and inspiration page. -- [[Kawigi]]

I'm not really aware of anything I've inspired, so I'm not exactly holding my breath on that one... :p I talked about some stuff pretty similar to Nemo before it was released, I think that's about the extent you could go, and Nano is more than capable of coming up with Nemo without my inspiration ;) -- [[Kuuran]]

Although I needed to egg him on a bit to finish Nemo 2 ;-) -- [[Kawigi]]

What really did it was that lateral-velocity mirroring. Bloody brilliant at 10 bytes. And yes, I probably wouldn't have finished or released Nemo 2 without that chat session. ;) -- [[nano]]

btw: David, don´t u think that i had inspired u too? Afterall why did u took off from the battle your HeadOnTargeting bots? ;-) -- [[Axe]]

I have a question to u all robocoders: I am testing in version 1.01 pre-saved data, is this considered unfair? -- [[Axe]]

i think no, because many bots are using pre-saved data. we have to say clearly if it is allowed or not and then one could modify RR client to delete automaticaly bot.data directories, but till then it is and should be allowed imho. --[[deathcon]]

Hella yes! We have decided about that before you entered the game [[Axe]]. Pre saved data is considered a bit cheesy, but it's a valid strategy for sure. -- [[PEZ]]

Thnx. Let´s see if it works for me... -- [[Axe]]

That's one good looking details sheet! http://rumble.robowiki.net/servlet/RatingDetails?game=roborumble&name=axeBots.SilverSurfer%201.02 I think you have something really good in the coming there. You're strong against the strong and against the weak. -- [[PEZ]]

Hope so, but I think is too soon to say something, my tests with FloodGrapher wasn´t exactly perferct... -- [[Axe]]

Version 1.03 is another rotten version, argh! Seems that i´m becoming an expert on trashy versions... -- [[Axe]]

Hey! I'm that expert. You're just a novice in that game. =) -- [[PEZ]]

Just give me time, u are underestimating my trashing capacity, there goes one more... :))-- [[Axe]]

OK. So 1.06 proves you can at least try compete with me in trashing capacity. =) What's this new system about then? -- [[PEZ]]

I said you... It seems that everything that i try trashes it. I´m testing variations on what-criteria-do-i-use-to-choose-bad-gfs. This version has a good thing althought: It seems stronger against weaker (but a lot weaker against stronger). -- [[Axe]]

Interesting. I seem to be going in the opposite direction. Making P stronger against the strong and not strong enough against the mid range and weak. -- [[PEZ]]

My primary goal for now is to make my movement perfect against HeadOnTargeting bots... I think that the way to get things working in this kind of system (at least in the kind of system i imagine) pass throught beeing HeadOnTargeting bullet-proof. If i ain´t, something is very very wrong. 
Your system (as far as i know) works not surfing the current wave, but all the waves in air, is that right? That kind of system probably won´t let u to be 100% precise, but can give u some advantadge against strongest bots (only a feeling). 
The fact is that i have only one thing in mind that is 100% sure: we both have a lot of road to travel... -- [[Axe]]

Yeah, but I only weight in the "other" waves very little. I doubt it even matters. I don't know why ABC and Jamougha weights in the other waves, but for me it is mainly a (codesize) cheap way to choose the closest wave. I agree a system that works should be close to 100% against head-on. But maybe there's something in the fact that RaikoMX is almost 100% against FloodMini. At least in the long run. Food for thought. -- [[PEZ]]

BTW. Later [[Pugilist]]s are pretty good at taking care of head-on targeters. -- [[PEZ]]
* I know. 96.8% against HawkOnFire. That is very good indeed, but i´m talking here about perfection, RaikoMX & Shadow makes it 99.6%... This means being hit only in blue-moon situations. And there is nothing absurd to me that 99.6%, if things were working i should score something above 99%. Obviously they aren´t for me ;) -- [[Axe]]
[[Pugilistrz.HawkOnFire_0.1 96.8

P should get something like 99+ too if things worked. Since default for P is to move GF1 until it has data in a segment. Or, that's how I intended it. I think, in practice it does other things. =) But I think 99.6% against head-on, the way RMX is built is just an effect of carefully choosen default behaviour. It probably doesn't get a score like that against some other fixed-GF targeting methods. So achieving 100% against head-on is just pragmatism, not perfection. Perfection is to give FloodMini only 15 or so rounds out of 1000. -- [[PEZ]]

Yes, feeding in a little head-on data at the start helps a lot against head-on guns. I've been working a a little on countering linear targeters more effectively, but the whole idea needs a considerable amount of polish; linearly targeted bullets don't hit the same guess factor much when your velocity is zero.

[[rozu]] is really the master of beating head-on targeting, though I've no idea how the heck he manages to make it so precise. Myself, I've found that one of the biggest problems is movement strategy. You have to turn sometime, and if you weigh things up wrong then you'll get hit, one way or another; usually by getting stuck between the wall and a bullet stream. I've probably spent close to half my time just working on when to bounce.

That's what is so great about [[ABC]]'s method of weighting all of the waves, though. It lets you know when you're cutting things too fine with your wall smoothing. Helps quite a bit against simple guns. It also helps against pattern matchers; the danger against them is that you can get stuck always seeking the local minimum, and repeat your movement over and over until you get hit. Plus it helps you get out to the negative GFs. Real genius. -- [[Jamougha]]

Do any of you adaptive movement guys check to see if a bot is firing only at positive guess factors? Seems to me doing that and then avoiding those facotrs would make for a bot that could get 95%+ scores against an even greater range of bots. I think that's what [[Immortal]] might be doing, because it can really crush some non-headon bots like SandboxMiniMelee. -- [[Alcatraz]]

What I fail to understand is how such low weights can give any of the good effects you describe. Obviously you are right, but I can't intuitively accept it. Let's say you have 3 bins and smoothed values in the closest wave like 120, 250, 400. Weighted with / sqrt(distance) the next wave is something like 2, 2, 3 and next wave is 0.1, 0.1, 0.1. How can that have any effect at all?

I think I have spent 97% of my time with my (failed) wave surfing on dealing with wall bouncing and wall behaviour. The sad thing with Pugilist 1.3.1's relative success is that it creates a false flatness just because it happiliy bounces off of the wall very quickly. Against good wall segmentation it is a SittingDuck.

[[Alcatraz]], good information you share! I can use that I think... Though it is pretty hard to create a negative GF movement as it is. =) -- [[PEZ]]

-- [[PEZ]]

what's this wall bouncing i keep hearing about? i thought you guys all had wall smoothers. or do you just ocasionaly bounce when you get near a wall instead of smoothing it? --[[andrew]]

I certainly have never managed to create a movement with successful NoFearTheWalls. So yes, until you master smoothing and collecting and acting on data perfectly near walls you need to bounce. Choosing when to bounce can make huge, huge differences in the performance of your bot. -- [[PEZ]]

very interesting news PEZ. because r2d2 has just been wall smoothing with no bouncing at all. so the idea of wall bouncing is that 20% of the time or so that you are aproaching the wall, instead of smoothing, you reverse directions? --[[andrew]]

Cool. You can have many rating points hiding there! Yes, increasing the probability of bouncing is one way to go. That's what [[Aristocles]] do if I remember correctly. Bouncing if you have wallsmoothed your destination more than X% is another. That's what current Pugilist do. There are lots of variious ways to do it. Go ahead experiment some. -- [[PEZ]]

Hmm, how are calculating those figures? I'm using bullet travel time, so at the point a bullet has passed me the rest will be e.g. 16, 32, 48 ticks away. So the second bullet counts for ~70% of the first, and the third for ~60% of the first. It will become more extreme as a bullet comes closer, e.g. when the nearest bullet is 2 ticks away and the next-nearest is 18 away the nearest counts three times higher. But it's not really trivial, still.

[[Alcatraz]], wow, that's something... how is he getting 80%+ against random linear targeting? Must watch his bot for bit. :-) -- [[Jamougha]]

Well, you have seen my code for it quite a few times. Your ratios sound much sounder though. And I also use bullet flight time.. Maybe it's my Excel sheet that's wrongly set up... -- [[PEZ]]

Yes, your code for it looks fine, I've checked it a few times as you say. :-) I'd say it's an Excel issue. -- [[Jamougha]]

Cool. That's sets a piece of my mind at peace. I really couldn't figure it out. -- [[PEZ]]

@[[PEZ]]&[[Axe]]: IMHO, you must have some kind of serious bug or logical flaw in your code if your WaveSurfing implementation doesn't get you a 1950+ rating. I have tried countless variations of the same idea, and it seems to work everytime. I tried looking only at the closest bullet, at all the bullets with and without weighting (linear/exponential,bulletTime/distance), with/without bin smoothing, high/low segmentation, more/less bins (it works with as few as 5 bins!), multiple ways of comparing continue/invert positions, and many others. I would sugest you guys start by making sure your EnemyWaves and future position prediction are working correctly, and then try to flatten RoboGrapher's output with a simple non-segmented flattener. If you can get a "flat sugar on top" profile from Robographer it means you are on the right track, and probably in the 1950+ club. -- [[ABC]]

Tell me about it. =) Of course I have a serious bug. And I also have noticed that as few as 5 bins work and that the weighting of the waves seems to be something to worry about when the bugs are gone. It feels good that you say this ABC. Feel free to review P 1.4.4's code some. =) You know my e-mail address. -- [[PEZ]]

Thnx for your attention, [[ABC]]. I was thinking 'bout it these days... There is something very rotten in the state of denmark. Probably is my lack of knowledgment about the GF & Waves theory. The wave/bullet synchronization i can tell u that it is ok (RobocodeGLV014 gave me a huge hand with it). I am know suspecting of the GF "measuring". When i detect a wave, i am using the most simple way to calculate the GF points: i assume that i can go instantly to vel 8 to get the GF 1.0, and also instantly to vel -8 to calculate the GF -1.0. That would give me a much wider escape angles, and what i'm thinking that is GF 0.5 for example, can sometimes actually be GF 1.0... Don't know, but i'm suspecting that it could be this... -- [[Axe]]

I doubt it. The nature of GFs takes care of that for you. I think we all use a GF1 defined like that. -- [[PEZ]]

Really? To bad, i had hopes that it was only this... I was thinking that way because we are successfully avoiding GF 0.0 against HeadOnTargeting bots. Must be something that is giving us bad GFs above and/or below 0.0. Tell me something: how do u distinguish from positive/negative GFs? I am using only my velocity sign, is that good enought? -- [[Axe]]

I don't do it at all. All I do is check the forward and reverse positions and reverse should there be less danger that way. My reverse position I decide is the one I get to if I change my lateratVelocity sign and go for full speed. Maybe there's something inherently wrong with this... -- [[PEZ]]

Yep, i was thinking that it might be something like that. An error in it can easily explain our problems. I am thinking in a test: I´ll try to take out the sign of the negative GFs and sum with the positives. And when moving, consider that i´m always in a positive gf. That is: if i´m hit in GF 1.0, i´ll avoid also GF -1.0. What do u think? Btw: PEZ, what bot do consider the best simple gf gun to test? I´m using your Tityus, since it is strong and u described as "low segmentated", what do u think? -- [[Axe]]

Well, it's not lightly segmented. That must refer to an old version. Since [[Jamougha]] showed that my assumption that heavy segmentation slows learning was wrong I switched strategy. Still it's a straightforward GF gun. No rolling averages or anything like that. So it is easily fooled by good AM. It should be easy enough for you to remove segemnation dimensions though. If you want to test against a distance-only segmentation for instance. Keep me posted on how your esperiment turns out. -- [[PEZ]]
*(edit conflict) Right, i was thinking another thing: this should help also if the enemy gun isn´t distinguing well the gf signs. I´ll try the testings with TGB (Tityus-like, ain´t?). The idea of taking of the segmentation is good, i have once changed segmentation of your old RoboGrapher, this shouldn´t be difficult. Btw, nice and clean coding, congrats... Very different from my stuffed code (i really hate to organize my things, u should see my desk :). -- [[Axe]]

Axe, I believe it is very important to precisely simulate the acceleration/decceleration when projecting your future position, just assuming you'll instantly get from 8 to -8 will make your projected position miles away from where you'll really be. The tranjectory is not that important, I assumed a perfect orbit in Shadow 2.31 and it worked very well. About the +/- GFs, you must do it exactly like a GF gun: if you were moving clockwise when the enemy fired, the positions clockwise to where you were are positive GFs and the anti-clockwise are negative, and vice-versa. -- [[ABC]]
* I´ll make both tests...Don´t think that this diff. in both methods can be a problem to AM? For example: if Shadow is doing the precise gf calculation to avoid and Tityus is firing with the simple method, won´t be Shadow in disadvantage? More far: Shouldn´t SilverSurfer & Okami beating Tityus easily? -- [[Axe]]

I'm not sure what you mean by "simple method", using the absolute GF value is allways wrong, there is nothing more different than GF-1 and GF1... -- [[ABC]]

I don't think Axe means he is predicting his future positions using the assumptions of instant max velocity. It's just a definition of what is GF1. I think. -- [[PEZ]]

[[ABC]], i think that we misunderstood each other... What i was mentioning was about the definition of what is GF 1.0. The formula asin(8/bvel) for max escape angle (or gf 1) is only correct if u asume that u can go in an instant to vel. 8 (or -8 for gf -1), right? Wouldn´t be more realistic if u use a precise-prediction method to calculate the max escape and then call it gf 1? That value would be at max. asin(8/bvel), and the difference can be very great if the distance is short or if u are stopped. Please feel free to correct me, as i said i´m a rookie with gfs. -- [[Axe]]

Ah, ok, I imagine that the fact that your maxAngle is dependent of your current speed could be used in a GF gun (it would be complicated, though), distance is not a factor. But for the dodger, considering you are doing precise prediction, you will allways evaluate possible angles. "(or -8 for gf -1)", not really, GF -1 is in fact impossible to reach. The GF sign is allways relative to your movement direction when the bullet/wave was fired. -- [[ABC]]

Woosh... Version 1.11 scored, at last, 1950+... Credits goes all to [[Jamougha]]´s "GF rating" formula:
<pre>
// Jamougha´s gf rating formula

private static double rateGF(int gf,double[] hits,double[] visits){

double rate = 0;
for (int i = 1; i < hits.length ; i++)
{
rate += (hits[i]+(0.1*visits[i]))/Math.pow(Math.abs(gf - i)+1, 0.5);
}
return rate;
}
</pre>
Amazing and simple. The funny thing is that my tests with TGB never show a big increase (as a matter of fact, pointed to zero increase). The real increase came from mid-ranked bots, i think. Congratulations Irish, u are really a bainiac (nothing that i didn´t knew it already)! -- [[Axe]]

You made it to 1950+ with SilverSurfer, congratulations! Best of luck in reaching the 2k barrier. :) -- [[ABC]]

Thanks, but the credits should really go to Jam. It saved me from beeing stucked within my own convictions. 
I think that i have room for some extra points, since SilverSurfer & Okami are probably one of the few top bots without WallSmoothing. As [[PEZ]] said, (and i agree very much) i might be loosing some points. Graphed it with TGB, and the near walls segmentation seems very, very, very bad. -- [[Axe]]

SilverSurfer 1.16 is looking pretty good! :) -- [[ABC]]

Yep. Did u saw? It reached 2011 with ~100! First time ever above 2000 for me! Unfortunately it probably will fall a lot now (it uses to be like this.). -- [[Axe]]

Interesting... I have runned(?) ~800 rounds with 1.16 in my client. Before the upload SilverSurfer was with aprox. 580 battles and scoring ~1964. After the upload it gone to ~1300 battles and 1979.9! is that delta normal? Take in count that is AM and with very few pre-data. Strange... -- [[Axe]]
* Have anyone explanation for the above? -- [[Axe]]

Unusual. I've noticed that you bots are *ahem* on the slow side, perhaps you have an exceptionally fast computer and it doesn't skip as many turns? Good work on the improvements, anyway! -- [[Jamougha]]
* Thanks, but i don´t think that is the machine... My home computer is a win-XP, 1.7 athlon, 512Mb ram... No super machine... -- [[Axe]]

I was thinkin' in two possibilities:
1. Is 500 really stable? With ~250 bots is 2 battles per bot stable enough?
2. The saved data. With few pre-saved data, is expected that running more battles in one client, the results in that client to be better (perhaps also a 1.4.2 security bug in the other client too). -- [[Axe]]

When you run 800 battles on the same client, your ranking is not really in the same "scale" as everybody else, imho. The distributed nature of RR@H is a big factor in the ranking, it only works because every bot fights in the same basic conditions. If you really want to see your true ranking after 1300 battles you'll have to wait for it to get there "naturally"... -- [[ABC]]

I understand what u are saying, i really never thought that way... But in other hand, is this so different from pre-saved data (I mean, isn´t naturall too..)? -- [[Axe]]

Pre-saved data can also be considered a "trick", that's why I don't like it too much either. Fortunately the RR@H ranking is very resistant to those tricks, in the end they wont get you very far. [[Aleph]] is a great example of that, no data saving at all and very close to 2k points. -- [[ABC]]

It came to me now ( a little late, of course) that [[Aleph]] is in fact an example encouraging saved data. If he start to use saved data, probably the 2K club would have three members by now. -- [[Axe]]

Yes, but how many data saving bots have been completely out-classed by a well executed idea? Btw, congrats on your improvements with SilverSurfer, great work, hope to see you up there soon. :) -- [[ABC]]

Let's see exactly how much of Shadow's raking depends on data saving, should be interesting... -- [[ABC]]

Released with pre-saved data? SilverSurfer versions 1.18 & 1.20 have pre saved data, but only from low ranked bots (I suspect that the pre-saved could not be so usefull against GF guns, but against HeadOn & similars...). -- [[Axe]]
* I meant data for the AM moving, of course... -- [[Axe]]

Nevermind, just saw... without data. Any data? Movement & Gun? -- [[Axe]]

I disabled Shadow's AM data saving, I never used pre-saved data. I also never saved any gun-related data. -- [[ABC]]

The gun saved data isn´t that good (too large to be saved a good amount). It only serves to fill the 80 ticks lacune i have at the start without it. -- [[Axe]]

Turned out better than I expected! After 600 battles it has the 2020 points it had and a positive momentum. And I just edited the poperties file inside the jar, didn't touch the code... I'm considering going back to no data saving for future versions. -- [[ABC]]

Yep. Probably the saved data ain't that worth afterall... But don't think that it hurts too... -- [[Axe]]

Hey, add SilverSurfer to The2000Club! By the way, how did it get so many battles so fast? -- [[Alcatraz]]

Yep. 2K... I barely believe it... The number of battles is because of a bug with Freya in my client. Setted to 200 battles, and left it running, but with the exceptions the 200 battles cycle never get to 200 and the uploads accumulated (this plus the fact that it seems that my client was the only one running..). -- [[Axe]]

April 17, 2004: It seems that i finally made my way to the 2K at last! This must be one of the most "sweated" AMs ever. -- [[Axe]]

Congrats dude! Hard work payed off it seems. -- [[PEZ]]

Welcome to the 2k club, great work. Don't give up now, with that kind of dedication nothing can stop you from getting to #1. :) -- [[ABC]]

Thanks! That's the idea. :) -- [[Axe]]

just thought i'd cast your mind back to the "Musashi days" todo list:

<pre> Beat VertiLeach :). Beat Shadow & Tron :)). Beat DT :)))).</pre>

I just pe you've grown 3 new mouths to let you do the DT smile... --[[Brainfade]]

The To-Do list... Old stuff, that! Yes, that was before even the amazing appearance of Jamougha... 
Good to see that i´m on the right way. But to be honest with [[Paul]], I have only beatten [[DT]] in the ranking, he still one of the worst headaches to me (Let´s not talk loud, he ([[Paul]]) might wake up and blow up my 3rd place :)... -- [[Axe]]

Added a comemorative image for the 2K, also included a link to the latest source included version (since i am packing my versions with some pre-saved data, and the repository have a restriction on uploads > 250Kb, i had to made some space, so the competition version is not including source.) -- [[Axe]]

I'll really have to spare some time with those ram bots... They became the worst PBI difference between expected & acquired. Ramers are cool! -- [[Axe]]

What are you segementing your EnemyWaves on? -- [[PEZ]]

Distance (3 segs: 0-200;200-400;400-), acceleration (3 segs: accelerating, "deacelerating"(?), constant) and absolute velocity (3 segs: 0-2;2-5;3-8) -- [[Axe]]

Good. loose ~10 points. Probably the "lightened" gun, but it could be also the anti-ram tweaking... Repeat 10 times with me: "I shall never work in movement and gun in the same version."... -- [[Axe]]

I'll try your segmentations next. That will free some bytes in P as well. -- [[PEZ]]

When you get S back in the 2K club. Maybe you can try summarize what it was you think was bad with the current tweaks and such. I think that could make very interesting reading. -- [[PEZ]]

Of course. I was compiling some material, like a "diary of suffering" about these days :) -- [[Axe]]

2.11 has a bug where it gets disabled in the first round if it meets a new enemy. I'm not sure if this matter much for your rating, but anyway... -- [[PEZ]]

Thanks. I´ll take a look, never saw it in my computer... Didn´t understood exactly what u mean by "new enemy", do you remember against witch bot it was? Could be also that saving/loading files SecurityException issue, what JRE are u running? -- [[Axe]]

"New enemy" == enemy you don't have data on. Like dev Pugilist and such. -- [[PEZ]]
* That was what i thinked... Is your JRE 1.4.2 or higher? -- [[Axe]]
* Yeah, I think so. (I'm not at home now and I have about 12 or 15 or so JVM's installed...). -- [[PEZ]]
* Aren't you having data saving/loading problems with that SecurityException with JRE 1.4.2? Or have u found a way to avoid it (if u found a solution, do u mind to share it)? -- [[Axe]]
* [[Jim]] solved that. Add <tt><nowiki>-Dsun.io.useCanonCaches=false</nowiki></tt> to your java command when starting robocode. The bug in SilverSurfer seems to be of another nature. At the momement it doesn't even seem to be there any longer on my machine. Now I get this instead, regardless if the enemy is a new one or not:
<pre>
=========================
Round 1 of 100
=========================
SilverSurfer scorer new Round!
StaticDataCenter:ahf.r2d2.R2d2 0.7
ahf.r2d2.R2d2 0.7 scorer new Round!
IOException trying to read: java.lang.NullPointerException: name can't be null
CREATING STRATEGO FOR:ahf.r2d2.R2d2 0.7
********** PULOU ROUND:3 - 27
</pre>
-- [[PEZ]]
* That exception just means that it hadn't found a data file for that bot, it's expected. I'll try at home with 1.4.2, now with [[Jim]]'s solution. Thanks a lot! -- [[Axe]]
* Arggg... I just can´t reproduce that bug that disable it in the first round... It simply doesn´t happens when i´m watching (as usual with these weird bugs). If someone out there notice it, please post the trace here... -- [[Axe]]

@ [[ABC]] & [[PEZ]]:
The results of the saving & pre-saved data experiments:
{| border="1"
|Data saving
|Pre-saved data
|Score
|-
|Yes
|Yes
|2009.46
|-
|Yes
|No
|1988.63
|-
|No
|No
|1984.64
|}
Seems that the big difference here came from the pre-saved data, next version I'll try a fast learning approach (based on [[ABC]]'s brilliant idea, probably...), and without the pre-saved data. 
That fast-learning idea can also give me room for new segmentations. -- [[Axe]]

A good implementation of that fast-learning strategy will allow you to add as many segmentations as you fancy. =) Collecting data in the rumble doesn't give too many points of course, since you seldom meet the same opponent twice and when it happens chances are that it's on a different computer anyway. -- [[PEZ]]

Yep. Thats why [[ABC]]'s idea is so nice. As [[ABC]], I don't like much the pre-saved data idea, it seems unnatural. Your ([[PEZ]]) approach for the problem (if there is no data in that segment use a "general" segment) is very fancy too. Don't know yet how i'll do it, tests will tell... -- [[Axe]]

My approach obviously doesn't gain me any rating points so I can't really recommend it. =) -- [[PEZ]]

Still think that is a good idea. SS is very SlowBot, your idea probably will require less processing than [[ABC]]'s... Well, tests will tell... -- [[Axe]]

My solution doesn't cost much at all. It's just a few (less than 10) more calls to Math.sqrt() per tick. And that's only while I haven't got a hit in the segmented container. -- [[PEZ]]

I´m recalling the versions. 2.07 will be untill i have time to work on the blitz-adaptation. I really enjoy that 3rd. place :) -- [[Axe]]

@ [[PEZ]] (or someone that have experience with that): This is the first time that i "downgrade" a version of a bot of mine... My client is priorizing SS 2.07 battles, but it was already with > 500 battles. Strange, is that normal? -- [[Axe]]

I've seen it happen. Don't know why though. But the priority-code is quite entangled and hard to follow so from what I can understand anything can happen. =) Funny that you grew fond of your test bot. I was thinking that would happen. =) -- [[PEZ]]

Sorry, "grew fond of" = ?? -- [[Axe]]
* "grew fond of" == to be proud of? If is that, sure! But if you meant that it would be permanent, no. I'll make Okami = SilverSurfer when I consider the WaveSurfing development completed (and take out SS from the rumble until i start my new cannon dev.) -- [[Axe]]

I would translate it to "afeiçoou-se". -- [[ABC]]

If you say so. =) It means something like "begin to like". -- [[PEZ]]

Yep. it's very convenient to know someone that speak the same language and with a better english, thanks! :) Yes, i grew found of SS (is that correct?), as a matter of fact, i don't like much the idea of SS suffer that much to give Okami all his knowledge... But life isn't supposed to be easy to SilverSurfer, right? :) -- [[Axe]]

You're right. [[Okami]] is a demanding master it seems. "afeiçoou" looks like the same word as "affection" by the way. We have that word in swedish too. (And it's "fond", not "found", since you asked.) -- [[PEZ]]
* right, fond. And you r right too about affection (only that affection is a substantive, the correpondent would be more to "afeicão", that is a substantive too. "afeiçoar" is a verb, and "afeiçoou" is the past-tense). But the master (Galactus) is me and not Okami, obvious. Even if my disciples dont obey me that mutch (for example: I gave to SilverSurfer the order to take the 1st place from RaikoMX...) :))-- [[Axe]]

Well, my heralds don't do as I tell them either. =) -- [[PEZ]]

@[[PEZ]] & [[ABC]]: From my history control, entry for version 2.14: 
"Trying a FastAdaptation solution, that is a merge of [[ABC]]´s across-segments smoothing solution and [[PEZ]]´s "unsegmented segment" approach (credits for them both)". 
I thinked in one interesting approach to that adaptation speed problem (at least i think it´s interesting :): 
First i mantain an extra "unsegmented segment" for the GF hits (like [[PEZ]]), and every hit-me event i update not only the segment that the enemy´s bullet wave matches to, but also that "unsegmented segment". 
Then when chosing the good gf for the incoming next wave, i just add the bins of the unsegmented segment to the bins of the incoming-wave-matching segment. 
Probably this will give me a similar result that [[ABC]]´s across-segments smoothing achieved, but without the processing cost of smoothing across all segments (that is specially good for me, seen that i´m using 97 bins). 
It seems good in theory, let´s see if it works... (btw, 2.14 was released without pre-saved data). -- [[Axe]]

Congrats, you did it. Like I said, no (pre)data saving is needed for a 2k rating. What you describe sounds just like what I did in most of Shadow's versions. Actually, I had 4 arrays: GF0[], GF1[][], GF2[][][], GF3[][][][], updated with every bullet. I used the extreme smoothing in 2.49 because I was experimenting with different kinds of rolling averages. Since then (in Tron, f.e.), I went back to "normal" visit counts and multiple segmentations, only this time I save memory by just adding up sub-segments on the fly to get the less segmented counts. It is my opinion that, after you get a good wavesurfing scheme (fast learning + long term FloodMini fooling), it becomes less important to tweak it, the "extra" ranking points are in the small movement details and probably in the gun. I believe your next step in joining RaikoMX in the 2050 club is trying to get the least possible hits by a headOnTargeting bot in 35 rounds, and that is all about avoiding wall traps and similar "no escape" situations... -- [[ABC]]

Cool! Do you weight the GFs in the unsegmented bins lower or do you just make a straight sum? I would guess the latter is rather like going fully unsegmented to begin with. Maybe you should try that? P seems to do equally well with unsegmented as it does with the fast-learning thingy applied.

As for the 2050 club. I agree with ABC that it could be with the "other" movement details. [[Aristocles]] can totally shut out head on targeters because it refuses to wall bounce against them. RaikoMX doesn't wall bounce either. It uses its wave surfing stats to know when it's time to reverse. All my experiments with this fails. Very probably because I only have rough estimates on my future positions and these get very faulty near walls. Thus I am doomed to wall bounce. Thus I tend to give head-on targeters a free hit now and then.

But the next thing you might consider is that RaikoMX's gun is super strong. And P has taught me that there are still rating points to gain by improving the gun.

-- [[PEZ]]

I have used 2 solutions for the wheighting of multiple segmentation levels. I used normal wheighting: GF3*dists*acels*vels + GF2*dists*acels + GF1*dists + GF0 works nicely. Other times I used percentages: you keep the total hits for each segment in bin[GF-1] and use the percentage of hits in each bin instead of the count (bin[GF] / bin[0]), that way the danger value is proportional to the quantity of samples in each segment, and you can just add them up. -- [[ABC]]

I figured that would be the way to do it. After I released P 1.7.3 that is. =) There I just divide fast-learning by 100... Now I'll try something completely different. Code name: "Doris". Let's see if it fools those PM guns like I think it might... -- [[PEZ]]

Can't you try a 2.17.2 fully without segmentation please? I'm very curious! -- [[PEZ]]
*no problem. -- [[Axe]]
*Released 2.17.3, only the unsegmented_segment. But i´m curious... Did u saw something interesting? Version 2.17.1 seems to show that the higher i weigth the unsegmented_segment, the worst gets my score. -- [[Axe]]
** I missed that. And now when you weight it 100% your down on 1980 points. So, your segmentation gains you 30+ points. That's good to know. Thanks! -- [[PEZ]]

An antry with a bang, 2.19 did! 25 battles, 1997 points and a momentum of 355. =) Let's see if you can bring RaikoMX down! -- [[PEZ]]

These weirds things sometimes happens, too soon to tell (although, i´ll not be sad if u r right). I´m trying a version with your idea of "mirror the edges" for edge-protection. A little modified: While smoothing the bins, i smooth 46 in each direction, and if it falls over the edges (0-96), they´ll refer to the "mirrored" position (like two mirrors at the both edges). 
The old code (discussed at [[Pugilist/HelpRequests]] page:
<pre>
// Jamougha´s gf rating formula
public double[] rateGFs(double[] allHits, double[] hits, double[] visits) {
double rate[] = new double[hits.length];
for (int i = 0; i < hits.length; i++) {
double rating = 0;
for (int j = 0; j < hits.length; j++) {
rating += ((SEGMENTED_WEIGHT * hits[j])
+(UNSEGMENTED_WEIGHT * allHits[j])
+(FLATTENER_WEIGHT * visits[j]))
/ Math.pow(Math.abs(j - i) + 1, 1.5);
}
rate[i] = rating;
}
return rate;
}
</pre>
The new code with the mirror edges:
<pre>
// Based on Jamougha´s gf smoothed-rating formula
public double[] rateGFs(double[] allHits, double[] hits, double[] visits) {
double rate[] = new double[hits.length];
int delta = (int)(hits.length/2);
for (int i = 0; i < hits.length; i++)
{
double rating = 0;
int start = i-delta;
int end = i+delta;
// loop based on PEZ´s idea of mirror the edges for
// edge protection uppon the smoothing
for (int j = start; j <= end; j++)
{
int index = (j<0)?Math.abs(j):(j>=hits.length)?Math.abs((2*(hits.length-1))-j):j;
// allHits[] is an "unsegmented segment" that uses PEZ´s "unsegmented segment"
// to accomplish ABC´s brilliant idea of fast-learning.
rating += ((SEGMENTED_WEIGHT * hits[j])
+(UNSEGMENTED_WEIGHT * allHits[j])
+(FLATTENER_WEIGHT * visits[j]))
/ Math.pow(Math.abs(j - i) + 1, 1.5);
}
rate[i] = rating;
}
return rate;
}
</pre>
-- [[Axe]]

Funny, that's very much how I tried to apply it. But i faied utterly. I must read your code and see what little detail it is I have missed. SS stayed at 1997 with this applied though it seems, so maybe it's not the way to go? -- [[PEZ]]

Here's my stab at it BTW. Maybe you or someone else sees where I go astray?
<pre>
double smoothedVisits(int index) {
double smoothed = 0;
int i = Math.min(index - Pugilist.MIDDLE_FACTOR, 0);
int k;
do {
k = i;
if (i < 0) {
k = -i;
}
if (i > Pugilist.FACTORS - 1) {
k = Pugilist.FACTORS - 1 - (i - Pugilist.FACTORS + 1);
}
smoothed += (double)visits[k] / Math.pow(Math.abs(index - k) + 1.0, 2.0);
i++;
} while (i < Math.max(index + Pugilist.MIDDLE_FACTOR, Pugilist.FACTORS));
return smoothed / Math.sqrt(distanceToTarget() / bulletVelocity);
}
</PRE>
It should be compared with the version posted on the Pugilist pages I guess. There I replaced the byte saving do loop with a more readable for loop before posting it though.

-- [[PEZ]]

Aren't you still having an edge smoothed problem with your code [[Axe]]? It looks to me like the edge bins still will have fewer neighbours than the GF0 bin. I try to avoid this in my code. Even though I have some other failure in it... -- [[PEZ]]

I'm still not convinced that edge smoothing is a problem. Think of it this way: if you have a perfectly flat profile, the best place to go to, where you are furthest away from where the enemy might shoot at, is to the edges, since he might shoot with equal probability at every guess factor. And the most dangerous place is GF0.

Today I implemented exactly what [[Axe]] described, something like this:
<pre>
gFact = new double[bins];
for (int i = 1; i < bins; i++)
for (int j = 1; j < bins; j++)
gFact[i] += 1 / Math.pow(Math.abs(i - j) + 1, 2);
</pre>

Then I did "danger /= gFact[index]", so that the smoothed curve is flat when the visit counts are flat. It didn't help much, in fact I think it works slightly better without it ([[Tron]] vs FloodGrapher)...

-- [[ABC]]

Why's GF0 the most dangerous place? -- [[PEZ]]

Probably because many bots default the guess factor to 0, Meaning that on a perfectly flat profile they'd fire straight at you. --[[Brainfade]]

If you define danger as the proximity to the enemy's bullet, GF0 is the most dangerous one because it has the most "close neighbours". -- [[ABC]]

Could that be right? In my thinking GF0.5 has as many close neighbours. And the edge GFs have no neighbours on one side only because you can't reach them (by definition). Which makes me think I should count the neighbours it has twice. But it doesn't seem to improve my bot when I do that so I suspect you are right in your reasoning, even if I can't really understand it... -- [[PEZ]]

Well excluding the "near-edge" guess factors would have the same number of "close neighbours" wouldn't they?? The large (far from zero) guess factors have an added risk, as they are more likely to wake you bounce (or smooth) the walls). Speakign as someone who has no knowledge of wavesurfing; when counting the neighbours around a guess factor, when your on an edge factor, would it not make more sense to just count the GF1 value repeatedly rather than using the values from just inside?? To be honest i can't think of any situation where it would make much difference, but it just sounds more logical in my mind... --[[Brainfade]]

The problem is smoothing it correctly. If you just add it up then you might easily overweight it. But as long as you "move" it away while you are recounting it, it could work. I'll have to see if that's easier than my mirroring strategy.

[[ABC]], you divide "danger" by the factor for the particular index there above. What's "danger" before that division? I just use the index factor. But applying your trick to that would end up in all danger being 1...

-- [[PEZ]]

My reasoning is like this: You have 3 bins, 1 visit to each of them. Bin 0 has 2 neighbours at distance 1, bin -1 and bin 1 both have 1 neighbour at distance 1 and 1 at distance 2. Defining danger as the visit count divided by "sqr(abs(distance) + 1)":
<pre>danger(-1) = 1 + 1/4 + 1/9 = 1.36
danger(0) = 1/4 + 1 + 1/4 = 1.5
danger(1) = 1/9 + 1/4 + 1 = 1.36</pre>

[[PEZ]], danger is your smoothed var, the sum of the visits weighted by distance. The gfFact[] array is constant (initialised in the constructor), it stores the pre-calculated proportions of each GF in a flat profile to compensate for the inverted U curve that [[Axe]] mentioned.

-- [[ABC]]

Ah, I missed the precalc thingy. Well, I can't fit it in Pugilist anyway I think. Unless... yeah, I can calculate it in the same loop as I calculate the danger value. Must try that. Should cost less bytes than my mirroring thingy with some luck. Thanks!

About your danger reasoning above. I'm with you so far. But does it follow that it is more dangerous to surf to GF0? What happens for me (when graphing with [[TGrapher]] at least) is that I get a GF1 spike. I have thought this is because the smoothing under-rates GF1 and makes P go for it even though it might still be the most visited GF.

-- [[PEZ]]

If you consider dangerous to be near the enemy bullet (even if it doesn't hit you), then yes, GF0 is the most dangerous.

About the pre-calc, I just did it like that because my math skills are not the best ;). It can surely be done on the fly, you need to divide the danger by the area below the smoothing function's curve for the current GF.

-- [[ABC]]

I thought I could calculate it the same way as you do above, just using my existing loop structure. Less efficient CPU-wise, but costs less bytes. But I haven't tried it yet, so I'm not sure I'm thinking correctly. -- [[PEZ]]

Hey, been busy that keyboards, ain´t ?:) I´ve wasted a lot of brain cycles thinkin ´bout that edge thing. First i came with that "adjusting" factor to compensate the inverted U graph, but made some calculations and moved to PEZ´s mirroring the edges idea (afterall if u put two mirrors in front each other u´ll get the infinite), and the tests with 2.19 went really bad. 
Reading ABC´s words makes echo with my own thoughts: It really makes sense that GF0 is the most dangerous if u apply a smoothing formula. The question that i´m thinkin now is: and what if we just don´t smooth, or smooth by a higher power factor? -- [[Axe]]

Tests increasing the participation of the flattener in 2.17.4 (the best scoring SS version till now) indicates that the flattener isn´t that useless... The diff. is small, but i think that it increased the performance against PM guns. 2.17.5 was just released with an even higher participation factor for the flattener. Let´s see. -- [[Axe]]

For that flattener; Are you firing EnemyWaves every tick or just when the enemy fires? Or rather; Is the flattener updated with every-tick waves or follow-bullet-waves? -- [[PEZ]]
* Only real waves -- [[Axe]]

Here's my adaption of [[ABC]]'s implementation of BinSmoothing/EdgeProtection using an inverted smoothed flat curve like you suggested [[Axe]]:
<pre>
double smoothedVisits(int index) {
double smoothed = 0;
double edgeFactor = 0;
for (int i = 0; i < FACTORS; i++) {
edgeFactor += 1.0 / Math.pow(Math.abs(index - i) + 1.0, 1.5);
smoothed += (double)visits[i] / Math.pow(Math.abs(index - i) + 1.0, 1.5);
}
return (smoothed / edgeFactor) / Math.pow(distanceToTarget(), 0.5);
}
</pre>
Note that the main difference from [[ABC]]'s implementation is that I don't have an outer loop updating the smoothed value of every bin. I just check the bin I am currently interested in. Saves some CPU I guess. And also it's very easy to request an all-bins array (should I ever need one):
<pre>
double[] smoothedVisitsArray() {
double smoothed[] = new double[FACTORS];
for (i = 0; i < FACTORS; i++) {
smoothed[i] = smoothedVisits(i);
}
return smoothed;
}
</pre>
-- [[PEZ]]

* Very fancy, let me know the results when u get them. I really have my doubts on that idea. For example: try to apply it into 5 five bins array like that: 1.0;0.0;1.0;0.0;1.0. The resulting wave isn´t correct too... But I hope that it work for u :). -- [[Axe]]

Well, after some excel graphing, I came to the conclusion that the best edge smoothing protection is the repeating of the edge values. Like this:

<pre>
for (int b = index - (bins - 1); b <= index + (bins - 1) ; b++)
danger += visits[Math.max(0, Math.min(bins - 1, b))] / Math.pow(Math.abs(index - b) + 1, 2);
</pre>

-- [[ABC]]

I'm a bity too giddy waiting for the Hockey World Championships final to start. Sweden is meeting Canada in a repeat of last years final. Let's hope it's not a total repeat though. =) But your code resembles my edge mirroring. Is that what's going on or is it just a reapeat of the edge value? I'll try your code once I figure it out. Doesn't eat many bytes. Thanks for sharing! -- [[PEZ]]

It's just a repeat of the edge value. -- [[ABC]]

I've been focused on my bot so much the latest day that I just now noticed that you've pushed SS past [[Shadow]]. Way cooooool!!! -- [[PEZ]]

I am seeing right now! 2nd! But i´m afraid that it won´t last... Only 1 point of diff. and the [[Shadow]]´s score seems to be in a "low tide" of the scoring oscillation. 2nd (at least for now)!... :))) -- [[Axe]]

Wow, congrats! 1 point isn't much, but it's enough to get me working on Shadow again... ;) -- [[ABC]]

Thnx. And thanks also for updating Shadow only after SS have surpassed it :) -- [[Axe]]

But speaking seriously, SS had already reached 2015+ in other versions, the reason for surpassing Shadow is only because of the scoring tide humor (I think that is one of the few times that i saw Shadow bellow 2015). Actually i think that kind of diff. is more to a draw. -- [[Axe]]

But those tides happen to everyone, I usually look at Shadow's score in relation to RaikoMX, it's always around -30. It's a draw, but it's the first time SS manages to draw against Shadow, regardless of the actual score ;). -- [[ABC]]

Nice Axe! -- [[Pulsar]]

Maybe you can leave SilverSurfer at version 2.22? Then I stand a chance to grab that #3 slot. =) -- [[PEZ]]
* :^) ! -- [[Axe]]

That probably won´t last, but... :)))!! 

http://robowiki.net/robocode/uploads/axe/SS_2060_1ST.GIF

-- [[Axe]]

The version of SS in the repository is not the same as in the RoboRumble/Participants page (2.43 vs. 2.42) which keeps my RR@H client from running any SS battels. -- [[Strider]]

I noticed when running in other computer... Fixed it. Thanks! -- [[Axe]]

Hey Axe, I just thought you might like to know: SilverSurfer doesn't fire 3.0 power bullets if you set "TC = true" in the AxeBot.java. At first, I was amazed by the 96% score for TargetingChallenge2K6, but I quickly noticed that he wasn't firing 3.0 bullets :) -- [[Voidious]]

SilverSurfer/Archived Talk 20060602

2009-10-08T03:51:57Z

Robobot: moved SilverSurfer/Archived Talk 20060602 to Archived talk:SilverSurfer 20060602: move to talkarchive

#REDIRECT [[Archived talk:SilverSurfer 20060602]]

Archived talk:Shadow 20090724

2009-10-08T03:51:55Z

Robobot: moved Shadow/Archived Talk 20090724 to Archived talk:Shadow 20090724: move to talkarchive

{{Talkarchive|Talk:Shadow}}
{{Navbox small
| title = Shadow Sub-pages
| parent = Shadow
| page1 = Version History
| page2 = Archived Talk 20040725
| page3 = Archived Talk 20090724
| page4 = Melee Gun
}}

== Old talk ==
It looks like there may have been a coup. A new king may be in town. 2073 after 470 battles. I wonder whats changed? -- [[jim]]
* The King is dead. Long live the King! Congrats for taking the crown, [[ABC]]. Almost 20 points up since I last looked! I second jim's query :-) --[[Vic]]
* Wow it stayed that high, saw it at 250battles at 2075 or so buton it's way down. Seemed very interesting and just now got an internet connection again (still in the US with work) and I quickly wanted to see if we had a new king... and we have! Well done! -- [[Pulsar]]

Thanks guys :). It was a very small change, I reactivated the flattener against all but the simplest guns (HeadOn). It solved a lot of mid/top range problem bots and made me win against everyone except DT (49.5%!). I hope I meet him a couple of times more soon, I believe Shadow can score 50%+, and that would mean 100% wins in the PL ;) -- [[ABC]]
* The most depressing part is your 60%+ against DH. Every time I get close someone ups the bar even further. I still have loads of room for improvement but I am begining to question my commitment to a GF gun. Looking at your scores vs. the cx.* bots and comparing them to the other 3 top bots I can see where you have distanced yourself some right there. Congrats again. Still not sure how I am going to catch this bot -- [[jim]]

Like you said, it wouldn't be fun to fight alone, I just changed the name of the bot to beat ;). I saw you TC results, you have a pretty good gun already, GF or PM is not important, as long as it works. -- [[ABC]]

Newsflash: [[Locke]] 0.7.2 just beat [[Shadow]] =^D ..... Ok, it's a fluke, but a nice one :-) --[Vic]]

Grr, another green dot in my LRP! ;) Are you sure it is a fluke? Have you tried running a 500+ round battle? -- [[ABC]]
* No I haven't tried that. It is a fluke in that [[Locke]] does not consistently beat [[Shadow]], but does sometimes. This time it felt special because now [[Shadow]] is king :-) --[[Vic]]
* It is not a fluke, I ran a 400 round battle that resulted in a very close win (50.3%) for Locke. -- [[ABC]]
* Wow! It must be because my gun is so different from GF guns. That probably means wavesurfing doesn't work that well against [[Locke]] as it does against GF targeters. I'm curious how far I can go with this gun. --[[Vic]]

Hey! Way cool. I've not checked the rankings for very long and now we have Shadow as the king again. Big congrats! -- [[PEZ]]

Thanks. Good to hear from you again, did you replace that Xbox yet? I recommend a GBASP and Advance Wars, one of my favourite time killers after/while Robocoding. ;) -- [[ABC]]

Yes, I got the XBox fixed. And finished all the levels of Blinx too. =) Advance Wars, I saw it on sale the pther day. Will pick it up next time. My GB advance needs a good game. -- [[PEZ]]

Hey! Been a week out of rc, and only saw it now: ABC is the new King! Congratulations, man! Portuguese spoken at the court! -- [[Axe]]

Thanks, and welcome back :). PEZ, I can heartly recommend that you buy Advance Wars (1 or 2, doesn't matter). It's the best strategy game I have ever played, it's like modern chess. I've been playing it for ages and can't get enough of it... -- [[ABC]]

Wow, a close match in the Melee Rumble. Who will win?? --[[Loki]]
<pre>
2 abc.tron3.Tron 3.11 1714.97 details graph 666 22-7-2004:14:30

3 abc.tron3.Shadow 3.13 1714.93 details graph 680 22-7-2004:14:14
</pre>
p.s. ABC, this page is getting so large it takes ages to load. Maybe you can create something like an 'old-shadow'-page?

This ancient bot deserves a large page. =) (Well, I moved away a load of the comment log to a new page (/CommentsAsOf20040725).

[[ABC]] this [[Shadow]] is a truly worthy King. It has a firm grip on both the ELO and the PL crowns. I'm soooooooo envious!

-- [[PEZ]]

Thanks, for the compliment and the clean-up. I'm trying to tweak it to beat DT more consistently, 100% wins in the PL is my goal now ;). - [[ABC]]

3.24 is going good! Impressing [http://rumble.robowiki.net/servlet/RatingDetails?game=roborumble&name=abc.tron3.Shadow%203.24 details sheet]. Insane even. A year back it would have been considered plain impossible. -- [[PEZ]]

It has been a frustrating period for me, though. I had to go back to a setup very similar to 3.13, because everything I touch makes me rank lower. Looks to me like I can't win against DT by more than 52% (like 3.13 did, 1k rounds) without losing ranking points against everybody else... -- [[ABC]]

Poor you. =) -- [[PEZ]]

Couldn't stand losing back the crown to [[Jam]], could you? =) -- [[PEZ]]

Not when I have a version that scores +6 points than RMX 0.32... ;) -- [[ABC]]

----

It seems Shadow is still a bit too tough for CassiusClay:
<pre>
55.66% 1st: abc.tron3.Shadow 3.25 80893 28600 5720 40756 5799 16 0 575 426
2nd: pez.rumble.CassiusClay 1.9.9.06 64430 21300 4260 34967 3899 3 0 428 572
</pre>
-- [[PEZ]]

That's good to know :). -- [[ABC]]

"Nothing major" costed you 12 points or something! What did you do? -- [[PEZ]]

I used a slightly different danger function, together with lots of small tweaks. The usual stuff, I don't know were the points went, but at least now I don't have the pressure of being #1, I can go forward instead of backwards. ;) -- [[ABC]]

Tell me about it. I couldn't imagine it would be this scary to be #1! Evrything I try costs me points. And I don't try lots of small tweaks in one release. Just one at a times. Interesting (and depressing) to find that I must by accident have tuned everything to the optimum. -- [[PEZ]]

Btw, I can't find a single bot that beats this version of Shadow in the long run, I must have done something right... I suspect close combat is one of the things dragging me down, I'll look into it. -- [[ABC]]

Not even [[Ascendant]]? (I think that's the only bot that could beat your last version.) Now, what's your current danger function like? -- [[PEZ]]

Bad luck maybe, but it looks like this [[Shadow]] might have to qualify to the StrongestBotRumble. But since the qualification is with 1000 round battles, that's not a problem for you I guess. But maybe you relaxed a bit too hard about not being #1? You ''were'' #1 in PremierLeague before. And, with better support from the RR@H client/server setup, that is the league that counts anyway. -- [[PEZ]]

Not even Ascendant, that was one of my first tests. How come I have to qualify? I think Shadow is ''still'' #1 in the PL. -- [[ABC]]

Yeah, strange. When I looked I counted 6 losses. But now it looks much better! -- [[PEZ]]

More, I tested 10x35 rounds against Aleph, Shadow won 8 in 10. A couple more encounters with him and it's back to undefeated status. I believe I improved Shadow's performance against top bots, I just have to find where in the mid/low ranks I lost those points... -- [[ABC]]

I get only 88.5% in the DevilFISHChallenge, there is definately something wrong with my close combat strategy... -- [[ABC]]

Well, I think I have told you that before. =) Anyway, it's nothing new, and can't explain where you lost those points. But I have noticed that good surfing against the mid and top bots is not the same as the pixel-perfect surfing that's so successful against the low-ranks. Maybe you have lost some of your edge against these? In a perfect world this shouldn't be something to worry about, but now the RR Ranking is what it is... I use different danger functions for simple targeters and not-so-simple targeters. I have just set a threshold on the average amount of hits I have taken per round and those that fall below the threshold get a different danger function. Maybe you already do something like this? But then again, maybe you can revisit it and make it a bit more extreme? Like using the 3.25 function for simple targeters and the 3.31 one for the rest? -- [[PEZ]]

I thought you said you didn't have any special-casing ;). Anyway, one of the things I changed in 3.31 is I separated the visits/hits statistics (in 3.25 I had only one set of stats arrays). I could make a third set for the "old" way, but I'd rather try to optimise the current setup because I think it makes more sense. Like you said elsewhere, sometimes you optimise a certain (sometimes buggy or illogical) method so much, that you then lose points by "correcting" it. Without the #1 pressure I can explore other methods more freely, a big jump is better than a lot of small ones... -- [[ABC]]

Indeed. It's the big jumps that marks the real progress. About special cases... I do have a few where I think they really matter. The "trash-lowranks-harder" special cases is just a result of the ranking system favouring that. Then I have special case treatment for rammers too. They are special after all. =) -- [[PEZ]]

Shadow was slow before. But now it slows down the RR@H clients something really bad!

What about the small bugfix? And can you share some on what it is you are trying now?

-- [[PEZ]]

It will soon be almost as fast as it was before. I'm trying a new way of surfing, I'll keep the details for myself for now ;). It looks very promissing so far, the bugfix wasn't really a bugfix, I noticed my performance against simple bots was lower than it could be and fixed it. It was cool to see a bot be undefeated and score ''just'' 2020 because of the imperfect HOT avoidance, like DT, only better. :) -- [[ABC]]

Yes, I also noted 3.34 didn't have that nice arrow-head in the LRP graph that is so typical for the pixel-perfect surf of Shadow. -- [[PEZ]]

Hehe:
<pre>
Fighting battle 40 ... abc.tron3.Shadow 3.36,pez.mini.Pugilist 2.0.9
RESULT = pez.mini.Pugilist 2.0.9 wins 2443 to 2414
</pre>
-- [[PEZ]]

Nice, but a fluke :). 58% for Shadow is what my tests indicate... -- [[ABC]]

Of course it's a fluke. A nice fluke. Shadow should trash a sloppy surfer like Pugilist anyway. =) -- [[PEZ]]

I'm working on it, version 3.35+ represent a major change in Shadow, I'm happy if it only just wins against a great surfer like Pugilist, for now... ;) -- [[ABC]]

Something is definately broken though:
<pre>
Fighting battle 67 ... abc.tron3.Shadow 3.36,wiki.nano.DevilFISH 1.0
RESULT = abc.tron3.Shadow 3.36 wins 4844 to 1042
</pre>
-- [[PEZ]]

My standards? =) I'm delighted to hear 3.37 is much faster anyway. Let's hope it's much better too! -- [[PEZ]]

You always refer to Shadow as a SlowBot, when it is much faster than most pattern matchers. If you compare it to Cigaret it is almost a FastBot. And your own "shoot a wave every tick" wavesurfing movement is not the fastest one around either... ;) -- [[ABC]]

Yes, CC isn't the fastest bot around. Not because it shoots EnemyWaves every tick though. That's only used to update the visit counts. What takes time is iterating my predicted destination alternatives and to evaluate the danger associated with them. Every tick. I believe you do that too? Or did before your current experiment started anyway. Shadow might be faster than Cigaret, but that says very little. My guess is that Shadow maybe is 3 times as fast as Cigaret. But CC is at least 5 times as fast as Shadow. Not talking about S 3.36 here, that one must have been slower than Cigaret. Both Shadow and Cigaret seem to get payback for being slow though. Those guns are good. All I ask is that now and then people with slow bots take a close look at their code and try see if there is something that could be rearranged or refactored to gain speed while not losing performance. I know some versions of my surfing has been unecessarily slow because of design flaws. And I'm pretty sure I can't speed my current surfing up significantly without changing it functionality-wise (or render the code even harder to follow than it already is...). So my standards can be summed up something like that it's OK to be slow as long as it's paying back in performance. (Or code size or readiability or whatever one might be chasing). And it's not as OK to be slow if it's just because you don't care about execution speed at all. Thus: The Shadow 2.25 line was OK slow. 2.36 was not. But then again you did warn us and did tell us you cared. So it was OK slow anyway. =) -- [[PEZ]]

Yep, 2.36 was very slow. I still haven't fixed it, 2.37 is only faster because I optimised it for 35 round battles and not because I fixed the fundamental problem that makes it slow. I'll have to refactor some classes to make it run as fast as before while doing exactly the same thing as 3.36, I hope to find time for it this weekend. I try my best to make my bots fast, I spent a lot of time working on my gun's speed. This time I just had to test my new surfing style in the rumble, it's great to have something new to play with, especially when it scores 60%+ against Aleph in the rumble. :) -- [[ABC]]

I would like that too! -- [[PEZ]]

Hey, you tangent CassiusClay in the SandboxDT/Challenge! -- [[PEZ]]

Cool, but that 58% result was in one of the many tests I made while tweaking, I don't know if it is repeatable. I forgot about that challenge I'll try the released version and post the results later. -- [[ABC]]

132 battles, 2080 points and a 70+ momentum. Looks good so far! -- [[PEZ]]

2083, looks almost too good to be true... -- [[ABC]]

Wow, amazing! Looks like you won back that crown, and maybe even set the record for highest rating ever... even SilverFistWT barely reached 2080 and you're above that right now! --[[David Alves]]

At 166 battles quite a few bots have touched that ground and higher. It's too early to tell. But it looks good. Very good. And I'm very curious what's behind that often used word in the change log, tweak. -- [[PEZ]]

Me too, me too! :) -- [[Axe]]

It's way too early to tell, that's for sure. This time I changed the dodging/flattening behaviour, now it has a special case for top bots instead of HOT bots. I turn on the flattener only if I'm getting hit 10% or more, there are very few guns in the rumble that trigger it. As for the new surfing style, take some ideas from my gun, mix it with GF theory, throw in some dynamic segmentation thoughts, and simplify as much as possible. I'll try coding a gun using the same method one of these days, the idea is to take advantage of my gun's learning speed and the speed/power of a gf gun at the same time. -- [[ABC]]

And when you do use the flattener, you weight it a bit higher than before? I've experimeneted a lot with different hitrates and stuff to trigger this or that part of my stats to get used. Haven't got exactly solid results though... As for your new surfing style. That's about what my guess was. You could turn any good gun backwards and surf it I guess. And your gun is the best one around, so it's a very good choice. -- [[PEZ]]

BTW, you bp=1.9 theory did wonders to my gun, many thanks :). Now I don't really "weight" in the flattener, my danger function returns gfDanger_visits * gfDanger_hits. -- [[ABC]]

Cool. You're welcome! That danger function... Does that mean you weigh visits and hits equal? -- [[PEZ]]

It means I multiply visits and hits. One of the effects is that I avoid the visited bins only after the hits are > 0, so simple guns are taken care of without special cases. -- [[ABC]]

I don't quite follow. Simple guns in this case means HOT? -- [[PEZ]]

Brilliant... Simply brilliant... -- [[Axe]]

Hot, linear, or any other gun that doesn't learn. I'm off to bed now, I hope it doesn't drop much more... I'll be happy with 2050+ anyway. L8r, -- [[ABC]]

2055, good enough. Axe, the fact is that I ended up removing the flattener for the simple guns, so the multiplication "trick" isn't in effect against them anyway. It does pretty good against top guns, though, I don't know why, but I made so many changes that it's hard to know what worked and what didn't. -- [[ABC]]

That part about multiplication trick protecting against simple gun flattening really confuses me. You must still have some default behaviour when you have not been hit yet and that behaviour just can't protect against all kinds of simple guns, can it? Oh yes, congrats on your come-back to the 2050+ club! Strong bot you have there. Especially in 35 round battles. I ran some 100 round matches CC vs S and CC holds to itself a bit better there than it does in short battles. Like the 14+ battles these bots have fought in the rumble shows. In multiplying the dangers from visits and hits, is it smoothed dangers you multiply? And have you normalized them before the multiplication takes place? Nagging about those weights again, just in discuise this time. =) -- [[PEZ]]

My default behaviour when I have not been hit yet is GF0 avoidance. The idea behind the multiplication was to never avoid a certain GF until I get hit at least once in that particular GF. Currently, and only against top guns, I multiply vists times hits, both smoothed and normalized. If it is better than wheighting and adding them, I don't know. The fact that my performance against DT (and Ascendant) improved a lot may also be explained by the many other changes I did. -- [[ABC]]

Ok, I tested 1k rounds vs DT with visits+hits instead of visits*hits, 57% (61% wins). That change was not the reason for my improved performance against DT. -- [[ABC]]

I still think that the multiplying trick is brilliant, it's nice and clean. I think that even against medium guns this might help... I have a theory (ok, it's much more to a feeling than to a theory, so u all are welcome to laught loudly) that some guns might have "blind spots" (GFs that they dont ever fire), even if they are more sophisticated than HOTs or Linears. This trick maybe help you to take advantage of these "blind spots". -- [[Axe]]

I fail to see where multiplying should be better than adding. There must be something here that I miss... -- [[PEZ]]

By multiplying the danger function returns zero when only one of the two parameters is zero. If gfDanger_visits is zero and gfDanger_hits is not, appearantly the this was a lucky hit and the bin is still considered safe. The other way round the bin seems unsafe, but the opponent actually never shoots in that direction, so the danger level is still zero. When you add values, some directions will seem to be unsafe, while they are not. just my idears, correct me if i am wrong. --[[Loki]]

Unless you register BulletHitBullet events or use the bullet position for the hits statistic, gfDanger_visits is never zero when gfDanger_hits is not. I look at it the other way around, if gfDanger_hits is zero there is no point in avoiding that GF any more than any other zero danger GF. A normal (addition) flattener would avoid it more than another more frequently visited (even if not hit) one. It was just a crazy idea that seemed to work at the time... :) -- [[ABC]]
* But that's the whole point to why I have the flattener on in the first place. I think there is every reason to avoid the most visited of two equally hit (even if no hits) bins. Unless of course I have judged that the gun I am up against is non-learning, but then I switch of the flattener completely. -- [[PEZ]]

Ok forgive me if this is a bad place to ask, (feel free to move it) but here is my question: Seeing as I havnt been around in the robocode world while WaveSurfing apeared and developed, im wondering why you bother recording both the visits and the hits? Afterall, if your WaveSurfing works correctly, the visits shouldnt matter as you should be dodging all the actual bullets anyway. I can imagine that in the short term recording visits means your profile will flatten out when the bot is newly installed with no data on opponents, but once the data is gathered it seems to me that the visits data would be interfering with your hits data. Or maybe I have got the wrong end of the stick, and your using a different method of WaveSurfing compared to the one I am going to try to implement in the near future which means its usefull in the long term?? --[[Wolfman]]

Wavesurfing works great with just hits surfing. But against fast adapting guns your enemy almost never fires where it fired before (hits), it will fire at the peaks in your current movement profile (visits). I would say that, If you had the exact same statistics as you opponent, surfing hits wouldn't even be necessary, just pure flattening would work perfectly... -- [[ABC]]
* So are you saying the "pure wavesurfing" is used for simple bots targeting like HOT, Linear etc, and that flattening is more usefull than true WaveSurfing vs advanced bots like Shadow?? -- [[Wolfman]]
* Yes. But don't make the distinction you do there. Visits surfing is just as pure as hits surfing. Against learning guns you want to be ahead of your opponent as much as you can and then visits surfing plays an important rule. This has been proven by all current top surfers, they lose rating points if you remove the flattener. -- [[PEZ]]
* (edit conflict :)) Yes, but for me "flattening" and "pure waveSurfing" are the same, it's just the waves you surf (hits, visits or a combination of both) that are different. -- [[ABC]]

[[Wolfman]], imho, if u are starting now a [[WS]] development, the best idea is NOT to include a flattener. Actually, i would recommend u to start with a single unsegmented WaveSurfing. This should be enought to beat all [[HOT]]s by 99+%, once u achieved that (and this might not be that easy, [[WS]] is a nest of potential bugs), u will be sure that at least your "basic" surfing is working, and this would give u a solid plataform to start into more advanced surfing... -- [[Axe]]

Axe that is exactly what I was planning on doing. I was just wondering if I needed to think about adding features later, so that I wouldnt need a complete re-write when I need to add something like this. -- [[Wolfman]]

Hey! My warning bells are ringing loud here. You should never ever think about later features when implementing an idea IMHO. Complete re-writes are nothing bad in themselves. But modifying code that only solves the problem at hand is much easier than modifying code that also solves future predicted problems. Problems that might never arrive. That code will hang around like a backpack on your bot forever and make changes harder than they need to be. I completely agree that you should make sure your hits surfing works before you add complexity like flattening and what-have-you. Adding visits surfing is a piece of cake even if you haven't made room for it to begin with. Easier I would say, since you might change your mind on the hits surfing implementation as you go. -- [[PEZ]]
* Pez, I think its much easier to plan for future eventualities at the beginning, and plan for future problems so that you dont have to rewrite. Its much better (IMHO) to spend a little more time on a properly designed system that is easier to intergrate future ideas into (that might not ever get used), than to write a poorly designed system that is a nightmare to add new ideas etc. And its complete rewrites that has stopped me from releasing a new bot for the past year+. --[[Wolfman]]
* Different philosphies. But to make my standpoint a bit clearer I can asure you that I am '''not''' an advocate of poor design. What I am opposing is [http://c2.com/cgi/wiki?BigDesignUpFront Big Design Up Front]]. I think good design solves todays problems and only todays problems. And that when tomorrow arrives with demands for change you refactor. Re-writes are rarely needed with this design philosphy. But if it comes to that, it's not necessarily a bad thing. A think complete re-writes are more common with that big-design-up-front. Because if you didn't get it right the first time it's harder to refactor it than with a small-design-as-you-go solution. I have never had to completely re-write anything in CassiusClay. -- [[PEZ]]

I was wondering when you would mix in some of your old proven stuff into your new structure. It looks great! 503 battles and 2070 points. Time to throw [[Ascendant]] 0.9.2 in again and let S and A duke it out about the crown? -- [[PEZ]]

Wow, definitely a strong release. I'm reinserting the best version of Ascendant now. --[[Mue]]

No need, I'm below CC now. I still have some pairings to do, though. How do you guys handle the HOT shutdown problem? -- [[ABC]]

Hm i see, but i'm done with the 0.9.5 branch anyway. What is this shutdown problem? --[[Mue]]

I guess you mean shutout problem? When there are three rounds left and I have taken no hits I start waiting for a low power bullet and if one is coming I let it hit me. In the last round I am not picky I just let any bullet hit me. -- [[PEZ]]

Well, i have not dealt with this yet. Actually i dont think that this is a real problem for [[Ascendant]], since these 100% results are rather rare i guess. --[[Mue]]

(edit conflict)Exactly the way I do, only that i control this via score... (see ImperfectPerfection) -- [[Axe]]

The problem, [[Mue]], is that even if they are rare, u might be throwing away your best possible results... -- [[Axe]]

Yeah i know, i just dont want to put effort into making my bot less perfect. I think that if this shutout thing is really considered a common problem, the rule of ignoring perfect results should be removed. --[[Mue]]

I already thinked like you, but now I think that this exists to protect the ranking against buggy results (clients wrongly configurated, etc..). When problems like that happens, u oftenly see robocode outputs like "SandboxDT didn´t started after xxxx miliseconds, no score will be generated.". Taking this protection, could actually make a lot of damage in weird situations. (personnaly, I use this to prevent [[SS]] from beeing damaged by clients without the appropriated configuration to deal with the [[JRE_1.4.2_SecurityException_Bug]]... so these words might sound a lil selfish, but I assure u that they are my opinion...) -- [[Axe]]

Note that i´m not saying that we shouldn´t take that "protection" from the server... But that we should at least think much better before doing this. -- [[Axe]]

Yup. I've seen my client go nuts too many times now to persist in my previous quest for removing that server protection. -- [[PEZ]]

Hm, maybe you are right, didnt consider configuration problems in RR@H clients. Perhaps its worth to take a look at what misconfigurations can be avoided by the client. The [[JRE_1.4.2_SecurityException_Bug]] for instance can be avoided since its possible to check at runtime whether <code>sun.io.useCanonCaches</code> is switched off. --[[Mue]]

Thanks for the tips, but I don't think I'll implement something like that into Shadow. It eventually gets hit by those HOT bots and the pairings get complete. I like the 100% score invalidation rule because I don't think 100% makes sense in the ELO ranking method, it would translate into infinite ranking points. And it does also protects against many problems. ph.Archer, for example, always loses by 350/0 here because my client runs on java 1.4 and its code is compiled with 1.5. -- [[ABC]]

I don't think that's why the 350/0 score shows up. I've seen it on many bots. On my clients it has helped to rebuild the .robotcache. I have written about the shutout "solution" elsewhere and said I can't recommend it. In fact I'm going to remove it from CC. But in a perfect world Robocode would inform the client about any failures and shutout scores would be acceptable. I don't think the rating system of the RR@H would go nuts on such a score. I've made some tests and it seems it's not as exponential as one would think from some discussions on this site. In fact producing a ranking table totally on raw % score produces a carbon copy of the rankings produced by the strange 1600-based rating we're currently using. That wouldn't be the case in these days of surfers if it was that near 100% closed in on infinity. -- [[PEZ]]

Near 100% doesn't close on infinity, but 100% equals infinite rating difference. Or maybe it is just undefined? -- [[ABC]]

infinite. -- [[Axe]]

I made some tests. Assuming the max score difference in 35 rounds is around 5000/5001 = 99.98%, the max rating difference between two bots would be around 2274 points. A 100% score is undefined (1/0) in the current ELO formula. -- [[ABC]]

Version 3.48.1 looks very strong. Good work man! Tell us what the latest changes was about please. =) -- [[PEZ]]

I made my movement flat again :). Lots of changes, I changed the wavesurfing to yet another method, seems to work better overall. It is, in some ways, closer to how you do it in BumbleBee. I don't want to describe the details just yet because I might change it again soon. That is unless I get to #1, in that case I'll probably wait for someone to dethrone me... ;)-- [[ABC]]

Cool. Incidentically I have a dev version of [[Ali]] surfing a reversed BumbleBee. It's buggy yet, but I have big hopes for it! =) -- [[PEZ]]

I saved a snapshot of the PL rankings. (I really should get it done automatically together with the ELO archivings...)

http://pezius.com/robocode/PL20041113.png

-- [[PEZ]]

Hey Ya! King again , eh? Congrats again! 4 entries in the Kings table is indeed amazing... All hail [[ABC]], the eternal (at least until it last) RR King! -- [[Axe]]

Yeah, congratulations from me too. An amazing bot you have there. --[[Mue]]

Thanks, the same can be said about Ascendant. -- [[ABC]]

2076! Your'e the man! -- [[PEZ]]

Can't imagine, the tops are improved against time, congratulate for the great works, i am imagine few days latter there should be a first into 2100Club.~;] -- [[iiley]]

Thanks, it's great to fix things and go up for a change :). I think I'll work on my gun now, Ascendant is coming! -- [[ABC]]

Something isn't quite OK with the latest Shadow. It only collected 1% score share agains [[MCoolDNA]]. -- [[PEZ]]

Something isn't ok with that battle, all others look ok to me... I'll test it anyway. -- [[ABC]]

The battle was delivered from your machine actually:
 <code>35,800x600,ABC,1100693585750,metal.small.dna2.MCoolDNA 1.5,6269,3474,35,abc.tron3.Shadow 3.51,65,65,0</code> 
Maybe you can still scroll up in the window running your RR@H client and see if you got any messages?

-- [[PEZ]]

FYI. The 1% score battle against GrubbmOne was also delivered from your machine. -- [[PEZ]]

That's my home computer, I'm at work now. Just got another 1% against gh.mini.GrubbmOne_0.9, something is wrong with Shadow or with my home RR@H client... :( -- [[ABC]]

And now you've got a 1% score against MakoHT. But that one was delivered by a signatre '''MN'''. So it's probably an array indexing problem or some such in Shadow. -- [[PEZ]]

Well, I found a possible division by zero, it shouldn't happen anymore in 3.51.1. In the process I found a major logic flaw with my lastest "tweak", what I did has nothing to do with what I intended, I should know better than trying crazy stuff while I'm playing Pikmin2 :). I'll test it in the rumble anyway, it seems to work against DT... -- [[ABC]]

So you have a GameCube? I'm thinking of buying one too because of Pikmin 2. Maybe I can disguise it as an x-mas present to my daughter. =) -- [[PEZ]]

Yep, I like Nintendo games, just ordered Paper Mario 2 and Zelda Minish Cap, since I already finished Pikmin2. I can't get excited with the likes of Halo 2, Half Life2, GTA, etc, got bored of FPSs around the time when Quake 2 was the latest thing... -- [[ABC]]

But few things beats multiplayer FPS. Of course multiplayer anything is hard to beat. =) -- [[PEZ]]

That depends, on-line multiplayer FPS is not my kind of game. I'd rather play good strategy/puzzle multiplayer, online or offline. It's very stressing to play a game that you can't pause... -- [[ABC]]

Somehow my latest Pugilist upload to the RobocdeRepository hijacked [[Shadow]]'s repository id of 198! This might mean that you have lost it forever, unless you can persuade the admins there to fix it. Until it's fixed Shadow is not downloadable using that link though. =( -- [[PEZ]]

That sucks! I was proud of that id... :( -- [[ABC]]

It was the coolest ID ever! Try make them fix it. -- [[PEZ]]

Even if you lost almost 10 RR@H points with the latest update I would say it's a success. Your details sheet is totally awesome now. If somehow you can figure out where you lost those points and reclaim them without losing the top-bot-trasher quality... It really is time you described your new movement scheme some. -- [[PEZ]]

Yep, my LRP is practically horizontal, and no bot I know can defeat Shadow in the long run, I'm happy. I hope I can get my 2070+ ranking back without many changes. -- [[ABC]]

Damnit! You reclaimed the PL title with the latest version. Ehm. I mean, congrats of course. =) -- [[PEZ]]

Thanks. But I never really lost it, 2.52.3 was just a test version. :) -- [[ABC]]

Can you give us a hint on what you do for evaluating the dangers in Shadow. Its [http://pezius.com/lrp?game=roborumble&name=abc.tron3.Shadow%203.55.1 LRP graph] is simply incredible! -- [[PEZ]]

First I need to bring my gun to Bee's standard! ;) It's a fast adapting, log based wavesurfer. But what works for me probably won't work for you. It seems to be all about the small details, like my gun experiment just showed. I lost 10 points just by adding your segmentations to my gun. In the movement department it must be similar, it gives you points if it is better against your problem bots... -- [[ABC]]

Amazing. I've been doing some small precision tweaks to my gun lately, and I was worried that some of them might be lowering my rumble score. But then I ran this test:
<pre>
1st: abc.tron3.Shadow 3.55.1 90642 32800 6560 44628 6606 48 0 657 344 0
2nd: mue.Ascendant 1.0 63155 17200 3440 38856 3653 6 0 344 656 0
</pre>
I must be doing something right! 66% survival and 59% score, I'm impressed with myself... :) -- [[ABC]]

Amazing! Do you crush CassiusClay as easily? -- [[PEZ]]

Yep, less survival but same %score:
<pre>
1st: abc.tron3.Shadow 3.55.s 83955 31400 6280 40203 5903 168 0 631 369 0
2nd: pez.rumble.CassiusClay 1.9.9.93 58296 18450 3690 32601 3402 153 0 372 628 0
</pre>

-- [[ABC]]

Wow, I thought my 70%+ score against RMX in the rumble was just a lucky battle. It wasn't:
<pre>
1st: abc.tron3.Shadow 3.55.s 93994 40500 8100 38560 6752 81 0 810 190 0
2nd: jam.RaikoMX 0.32 38401 9500 1900 25259 1682 60 0 190 810 0
</pre>
When does the StrongestBotsRumble start? ;) -- [[ABC]]

Cool~~Amazing~ Real beating everyone bot and beat easily, how about [[Pear]] and other top10 bots? -- [[iiley]]

Wow, Shadows performance in long battles is incredible. I already have some ideas what it could be thats holding [[Ascendant]] back in these battles. Cant wait to experiment with them, but sadly i've had not much time recently. I hope i'll find some time for this in the weekend. --[[Mue]]

When you crush a [[Pear]] you get...
<pre>
1st: abc.tron3.Shadow 3.55.s 88296 32900 6580 42448 6365 2 0 659 342 0
2nd: tide.pear.Pear 0.61.9.5 58840 17100 3420 34943 3377 0 0 344 658 0
</pre>
tasty juice. :)

-- [[ABC]]

You really are stepping on the heels of [[Aleph]] now. I think you need at least 1000 battles to have a reasonable stable meleeranking, although it will never be as stable as the one-on-one ranking. If you add the line below at the bottom of your meleerumble.txt file, your bot will keep fighting prioritybattles until the number is reached.
BATTLESPERBOT = 999
-- [[GrubbmGait]]

Thanks for the tip, I'll change it right away. There are a couple of problems with the melee rumble rating system. Each pairing is uploaded twice, inflating the battle count, and the number of rounds per battle should be at least 100. There is just too much randomness in a 35 round melee battle.

About [[Aleph]], if my latest test results are any indication, the title is already mine:

<pre>
1st: abc.tron3.Shadow 3.58.t 216224 149700 11880 50467 4163 13 0 133 74 45
2nd: rz.Aleph 0.34 196719 140950 7380 45212 3174 2 0 82 69 53
3rd: pe.SandboxDT 2.71m 183223 134050 6120 40733 2275 44 0 69 37 68
4th: abc.tron3.Tron 3.11 155150 106050 4680 41648 2666 105 0 52 40 57
5th: rz.HawkOnFire 0.1 152760 108200 1080 41177 2136 144 21 12 80 57
6th: shinh.Entangled 0.3 152388 108800 5040 36255 2184 79 29 56 47 45
7th: kawigi.micro.Shiz 1.1 149104 105800 2250 39538 1461 55 0 26 58 46
8th: jekl.StoneGhost .1 144755 102900 3150 37061 1638 6 0 35 44 47
9th: myl.micro.Troodon 1.10 126252 87100 1170 36348 1545 88 0 13 28 40
10th: tm.Yuugao 1.0 116018 80250 2070 32059 1329 309 0 25 23 43
</pre>

I'm just waiting for the rumble to reflect this. ;) -- [[ABC]]

The nice thing about the rumble is that it is not only important how you perform against topbots, but also against the minor bots such as [[Walls]]. Note that if you added the line I suggested, you will prioritize every bot which hasn't the number of battles yet.

Looking at the rankings after 54 battles, isn't it time that a page called TheMelee1800Club is opened? -- [[GrubbmGait]]

Prioritizing every bot with <1000 pairings is exactly what I wanted, it's very frustrating watching the client run random battles when you only fought 500 (250, actually).

Looks like 3.58.2 is finally going to make it, cool. Shadow is great at killing simple bots in a melee, last time tested it wins a battle against the sample bots while only firing .1 power bullets... :) -- [[ABC]]

Still 8 points difference, I think I'll run some 35 round tests now. Just like in 1on1, Shadow beats everybody else but doesn't reach the top spot in the rumble. -- [[ABC]]

In melee nothing is certain, one bad battle just has 18 times more impact than in one-on-one. [[Aleph]] still seems to have the upperhand though. About testing against the samplebots with only 0.1 power bullets, I've tried it and I come in third, not even close to number one [[Walls]]. I saw a flaw in my targetting though, missing SittingDuck just after switching targets, so there is still some hope to get close to rank 25 . . . ;-) 3.58.2 at least is an improvement over 3.55.1, so keep up the good work! -- [[GrubbmGait]]

Welcome back... We tried to keep the Rumble warm for you. ;) -- [[Voidious]]

I noticed, thanks :). Lets see if I can squeeze some points out of Shadow, otherwise I'm afraid I'll get caught in the testing loop again. It's very hard to make changes to a bot that wins every single 1000 round match I run... -- [[ABC]]

Well, If we could make the testing process easier by beating Shadow we would... But that's a *long* way off (for me anyway). Welcome back, [[ABC]]! --[[wcsv]]

I'm not sure if you noticed, but v3.62 is undefeated with over 1,000 matches. Nice job! -- [[Voidious]]

Thanks, I noticed ;). Unfortunatly it still didn't manage to go up in the rankings. I have high hopes for the next version, though, I'm doing some promising gun experiments. -- [[ABC]]

Seriously, that's <A HREF="http://rumble.fervir.com/rumble/PremierLeague?game=roborumble">extremely impressive</A>. To me, that's more impressive than topping the ratings chart. Once again, nice work. -- [[Voidious]]

If nothing ever went wrong, what would you learn from it. As you have far more experience than me in robocoding, you know the drill: one step back, two steps forward! -- [[GrubbmGait]]

I don't know if I'd say, "something went wrong." ;) The air's pretty thin around 2050. I imagine it's hard to find points way up there... and I can only imagine. Shadow's phenomenal - even 3.64. --[[Corbos]]

I'm usually more like: 10 steps back, 1 big step forward. You bet the air is thin up there! :) -- [[ABC]]

Hey, congrats on finally taking over the #3 spot! -- [[Voidious]]

Thanks. Got a bad luck fight against Ascendant, though. In my 1k round tests I win by 60% survival (56% score)! -- [[ABC]]

Woha! Well done ABC! Nice return! --[[Pulsar]]

Wow, another undefeated version... Awesome job, ABC! -- [[Voidious]]

3.69g, could you tell us some about what you are testing with the movement? I'm pretty flesh out of ideas on what to test with my surfing... -- [[PEZ]]

Nothing new, I'm registering multiple hits for each enemy bullet and adding the danger values instead of computing only the danger of a center hit. Going back to basics really, I must have tried it like this many times before.... I'm also fine-tuning the wavesurfing precison, I made some tests against WSC bots and was getting hit too many times for my liking. -- [[ABC]]

Yeah, I've tried that too many times. Never got it to deliver. Running WSC is depressing at times. =) -- [[PEZ]]

Of course I never release a new version without testing against [[Ascendant]] first, this one scored an impressive 59% (66% survival!) in 1000 rounds... ;) -- [[ABC]]

Great! Funny, I never release without testing against Shadow first. That's never very encouraging, but anyway. I like a challenge. =) -- [[PEZ]]

I almost never test against the previous version of Shadow, it is always the hardest one to beat for me too... :) -- [[ABC]]

For your information CC's results against Ascendant are now 54% and 58% wins. Not as impressing as Shadow's but extremely good for being CC. Ascendant used to pick CC apart with disgusting ease. Shadow (3.69f) gets 57% with 60% wins against CC still. I think that is better than it used to be. -- [[PEZ]]

Great results you got there, I remember CC being almost too easy for Shadow, like 65%/70% wins. -- [[ABC]]

Now I can't repeat the results against Ascendant. Checking it I see that my log says that it was Ascendant's hit ratio on me that was pretty low during that match. Probably it locked in on the wrong gun in its VirtualGuns array. VGs are a bit scary really... Anyway, CC still beats Ascendant, but not as clear as I would like. -- [[PEZ]]

3.69j is a strong bot! It seems not even close to losing a single pairing. I'm impressed and envious. -- [[PEZ]]

Thanks, but I had to revert almost everything to 3.66 level. I found a huge bug in my recent attempt at "dynamic dimension weighting" that wasn't working as expected. Turns out that correcting that bug costs me at least 30 ranking points... talk about PerformanceEnhancingBugs! -- [[ABC]]

Maybe you can't comprehend your own genius.. -- Martin

That must be it, Thanks! :). The fact is that Shadow's source is full of redundant/obsolete code that makes it very hard to try new stuff. Maybe I should start working on a new bot... -- [[ABC]]

Hey, did you change the gun at all from 'm' to 'n'? I was just running TC2K6/FastLearning for Shadow 3.69m. -- [[Voidious]]

Nope, I'm trying to get my movement back to 3.66 level without the huge bug I found. The current gun should be pretty good for the TC2K6, iirc. -- [[ABC]]

Shadow's dev version now crushes Ascendant by 60% score (69% wins), I'll release it tonight (v3.66o). If it doesn't bring me back close to 2060 ranking, I don't know what else to do except fully reverting back to 3.66, with all it's bugs, and dedicate my time to Tron/Melee/Teams/Something else... -- [[ABC]]

Man, that sucks! Are you sure you haven't introduced some other bug in fixing the first one? It really seems hard to think you could have a major bug and be at a rating of 2050+, but I guess it could happen. (Shadow is a unique tank, after all.) Anyway, good luck in your bug hunt! -- [[Voidious]]

I think you can feel very, very, pleased with your awesome bot. It is the strongest bots of all. It is against the strong that strength is measured, remember? Ascendant is a very strong bot too but pitted against Shadow it too has to bow deeply in all its royalness. I will probably never have to choose, but I am pretty sure that in choosing between a bot who has known hard-to-fix bugs with 2060+ rating which wins, but only just against Ascendant and a bot which I have more trust in the code and which crushes Ascendant to pieces and reaches 2040+ I would choose the latter. Maybe you can analyze what catagories of bots you "lose" points against and see if you can figure out some special case or adaption of your movement system that would take care of them too. Or think of it like this: Which bot do you think holds the bigger potential for 2080+ rating scores? -- [[PEZ]]

I know, I'm very proud of my PL crown, and I believe Shadow has 2080+ potential. In fact, I know its has, since the AShadow experiment. But I would have to resort to a "mainstream" gun, and I don't want to do that ;). About the bug, it's not really a bug, it's some new code that wasn't doing what I thought it was. It was reseting the statistics for my dinamic weghting every time it registred a enemy bullet instead of accumulating the stats. I replaced it with an bullet "age factor", since I believe that was it's unintended result, but I'm fighting hard to make it perform as good as the "buggy" version. -- [[ABC]]

Well, maybe working on something else for a bit would help, actually... pounding away at a single problem works sometimes, but other times it can help to just take a breather for a little while and clear your head. Anyway, I must say that I have the utmost respect for (and fear of) Shadow, no matter what his rating is. Personally, I still think that going undefeated in the PremierLeague - not to mention doing it *consistently* - is more of a feat than a high rating. The rating system is just a little more arbitrary to me, while "winning against all opponents" leaves no room for argument. Anyway, once again, good luck in your quest for 2060 (or 2080). -- [[Voidious]]

Nice job with 3.66b... I'm curious, did you have to restore that "bug"? -- [[Voidious]]

Yes, it's the exact same movement code as 3.66. I'm not giving up on trying to make it work just as well without that bug though... -- [[ABC]]

This has always been my favorite robot, has that grace that I've never seen in any other bot, for some reason, I can't find a link to download it, any idea? - Avihoo Ilan

Most bots you can find on http://www.robocoderepository.com, the entrynumber (or the direct link) you can find on RoboRumble/Participants . The repository seems down at the moment by the way. -- [[GrubbmGait]]

Thanks for the compliment, you can download Shadow's latest version at http://robocode.aclsi.pt/abc.tron3.Shadow_3.70d.jar. -- [[ABC]]

I thought it was [http://robocode.aclsi.pt/abc.tron3.Shadow_3.70e.jar 3.70e]? =) -- [[Voidious]]

Sorry, I'm currently snowboarding instead of surfing enemy waves, so I'm a bit distracted ;). [http://robocode.aclsi.pt/abc.tron3.Shadow_3.66b.jar 3.66b] is still the best version, acording to the rumble, iirc. -- [[ABC]]

----

[[ABC]]: Is Shadow a [[WaveSurfing/TrueSurf|TrueSurfer]]? or does it surf like [[CassiusClay]] and [[Dookious]]? -- [[KID]]

I don't know, I believe CC and Dokious method is very similar to Shadow, what makes them non [[WaveSurfing/TrueSurf|TrueSurfers]]?

The fact that they calculate their movement risk only where the wave will hit them, where a [[WaveSurfing/TrueSurf|TrueSurfer]] calculates the risk for all the positions that it will be, going forward and backward till the wave hits (at least that's how I do it). -- [[KID]]

What advantage does that have? If the wave is not going to hit until a certain time, the intermediate danger shouldn't be an issue... Or am I missing something? -- [[Greywhind]]

Checking all positions in the range and choosing the best is more like [[WaveSurfing/GoToStyle|GoTo Style]], I would say. The idea (IMO) of [[WaveSurfing/TrueSurf|TrueSurfing]] is to simplify the decision to: "which direction should I go ''right now''?" I consider the CassiusClay algorithm (not to say [[PEZ]] invented it, though he may have), which Dookious is based on, to be the ultimate evolution of TrueSurfing. If you think about how the forward/stop/backwards positions will be evaluated tick by tick, you'll notice that both GoTo and TrueSurf/CC-style should end up at about the same (least dangerous) point - but the TrueSurfer might overshoot it and come back instead of going right to it. -- [[Voidious]]

Shadow only calculates the danger of the wave(s) hitting position(s). So, [[KID]], by your definition, Shadow is not a [[WaveSurfing/TrueSurf|TrueSurfer]]. Also, calculating every single position forward/backward would be too slow because of my current way of computing the danger. Voidious, I thought GoTo style would be calculating the lowest risk reachable position, going there and stopping till the wave passed, that is not what I think KID is describing. -- [[ABC]]

You're right, I think I did misunderstand him... sorry [[KID]]. Still, I personally consider CC a TrueSurf style. It seems like some of those surf style descriptions could use some updating... -- [[Voidious]]

@[[Greywhind]]: The advantage is that I can set myself up for the next wave (which I weigh based on dist) where a "normal" surfer really only looks at the first wave and then a point on the next wave that may not factor in, in the end. So I end up surfing all the waves not just the first one.

@[[ABC]] How do you calculate the risk for a position? or is that classified?

@[[Voidious]] It's ok, it wasn't a very good definition.

If you guys want some code, [[Gladiator]] is open source, but has no comments. It shows in the class "kid.Movement.OneOnOne.TrueSurf.java" how I calculate the risk for going forward/backward.

-- [[KID]]

I calculate the danger using a log-based method, like DinamicClustering but with guessFactors. Thinking about it, it would'nt be so slow to do what I think you are describing, since I end up with an array of guessfactors/visitcounts. But I do factor in all the flying waves, weighted by distance, at the positions I would be hit by each one of them if I went in each (forward/backward/stop) direction. Like Greywhind said, I don't see why calculating the danger of positions I'll probably never be in is important. You make a decision by adding all the dangers and chosing the best direction? -- [[ABC]]

Thought you might appreciate confirmation that you are still the 500 round champ =) (Over Dookious, at least).
<pre>
1st: Shadow 3.66d 38872 14000 2800 19444 2627 1 0 281 219
2nd: Dookious 1.40cNDS 31656 10950 2190 16585 1930 0 0 220 280
</pre>
Dookious 1.40 beat Shadow with 50.6% over 8 matches in the rumble, and with 50.88% over 10 matches in my own tests, so I may just (finally!) have Shadow beat in 35-round matches...

-- [[Voidious]]

Uh-oh. -- [[Skilgannon]]

Woohoo. =) Btw, you might be interested to see some of the DynamicClustering stuff going on. Mainly, [[Simonton/DCResearch]], [[David Alves/PhoenixDC]], and less impressive, [[Lukious/Rewrite]]. (Some reference scores at [[TargetingChallengeRM]].) With [http://en.wikipedia.org/wiki/Kd_tree kd-tree]'s, David and Simonton can store hundreds of thousands of scans without a problem! Good to see you around again. =) -- [[Voidious]]

Hey, that's some "precision"! At 290 battles you're up over 1.3% per bot compared to 3.66d. That should get you, what, like 25 points? But yeah, check out those trees! I have an implementation at [[KdTree/BucketPRKdTree]] you can use, if you'd like. It makes DC just as fast as the GF guns. Welcome back! -- [[Simonton]]

Thanks, I've been following your DC research, you're the man! :) In fact, your success is probably what made me look at Shadow's code again, and from there to total addiction is a very small step. I'll definitely look into your tree code, thanks. -- [[ABC]]

I was working on a version but never finished the search function (which is only half done as is). :P --[[Chase-san]]

Way cool, 20+ points and PL king! :) And it's the same gun as 3.66 with some bug fixes. -- [[ABC]]

Very impressive! Have you thought of surfing a DC gun as well? Several bots are doing that these days. Although I feel silly giving you movement suggestions... Shadow is well-known for being impossible to hit. =) --[[David Alves]]

Shadow has been surfing a DC gun for years! Its movement is an inverted DC-GF gun, buggy as hell, it's a wonder how it works so well :). But I'll concentrate on the gun for now, I won't be happy until it outscores DCResearch. -- [[ABC]]

Well then I'll see what I can do to keep you unhappy :). -- [[Simonton]]

Hey, since you're back, maybe I can pick your brain a little. =) You once said you use entropy-based calculations to determine your DC weighting. Unless you want to do integrals (which I don't), this means slicing GFs into bins and segmenting on attributes. How do you do this? Or if you don't want to just give the answer, any tips? =)

I've tried a couple things: first, keeping singly segmented VisitCountStats buffers, one for each attribute, and using the entropy of each as the weight for that attribute; second, I tried (once per shot, different tick than aiming) segmenting the last X (eg, 500-1000) scans into singly segmented buffers, calculating the entropy for each, and adding that to a running total that is the weight for that attribute. The advantage of that second method is I am able to also calculate the [http://en.wikipedia.org/wiki/Mutual_information mutual information] between every pair of attributes, so, for instance, if two attributes measure the exact same thing (mutual info = max), I would cut each of their weights in half. My dynamic weighting does better than unweighted, but I don't have too many concrete stats beyond that, like how much the mutual info helps or how it compares to intuitive weights.

-- [[Voidious]]

* I had an idea somewhat similar to the entropy-based dynamic attribute weighting, but I figured it wouldn't work. What it was was to take the last x scans that had hits in the same bin (or do this for a range of different GFs), see which attributes are the closest (on average), and then weight those attributes the highest. Unfortunately, you might get high/low GFs due to a combination of different circumstances, so I'm not sure how well that would work. -- [[Skilgannon]]

Hah, ABC your as skilled as ever, +20 points, crushing many bots who makers worked many sleepless nights to defeat Shadow. I must say well done. It was my goal originally to beat Shadow in every targeting challenge with my neural network gun, but I have yet to dive back into my lattice design. --[[Chase-san]]

Unfortunatly I never found a way to make dynamic dimension wheighting work. I tried using VCS/entropy, correlation, variance, and probably other crazy ideas I don't remember anymore. Shadow's current gun is just a bunch of unweighted normalised dimensions. Maybe I'll try it again someday, but this time with a more scientific aproach, like those concrete stats you mention. Got to stop tweaking based on a single good/bad 100 round battle result.. :) -- [[ABC]]

Not to sound like [[Simonton]]'s advertising campaign, but that's what [[RoboResearch]] is for! =) A bunch of unweighted factors, huh... wow. -- [[AaronR]]

Tweaking on a single 100 round result, sounds familiar, hrm...... in my case its called being lazy. --[[Chase-san]]

Hmm - I thought Shadow did even better than 55% against Dookious over 500+ rounds. =) I seem to remember it being like 4-3. Anyway, Simonton tested his gun on Dooki's movement a little while back and it was very close to Shadow over 500 rounds, so that might be one you'd like to grab and test against: [http://upload.frozenonline.com/view/simonton/wiki.Dookiton_1.0.jar Dookiton 1.0]. Perhaps I should stop toying with the [[TwinDuel]] if you ''and'' David are going to make a push for #1... =) -- [[Voidious]]
* Well technically, it would be just trying to reclaim #1. ;) --[[Chase-san]]
In my 1k rounds tests Shadow 3.71 won by 52%/53% against Dookious 1.56 (I always test against the #1 bot ;)). I always test against Shadow's previous version too, so I don't really need another good DC gun bot. I'm expecting this new version to maybe lose a few points in the rumble, it's a work in progress, both the TC and TCFast results are slightly lower than v3.71. -- [[ABC]]

If anything, your rating went up. That tree of Simonton's is awesome! And with my tests of Shadow 3.66b vs Dookious over 500 rounds, Dookious wins by quite a big margin (about 56%)-- [[Skilgannon]]
* I just checked the details, and you now have a few losses, so no longer the PL king =( -- [[Skilgannon]]

Just gun tweaks!?? Very impressive... -- [[Skilgannon]]

Holy 2094 Batman! Great work, dude! -- [[Voidious]]

Holy cow, Shadow just smacked Ascendent. If we're not careful, Jamougha, Mue, and Paul will come back and try to take the kingdom back aswell. Actually, I donno about everyone else, but that would be awesome to see. --[[Chase-san]]

I'm trying to figure out a decent method to surf a DC gun, yet keep the movement strong against simple GF guns (Raiko, FloodMini, etc), and to do this I need decaying stats. Now, obviously Shadow has this down pat, so do you mind sharing secrets? I've tried adding 'distance' to scans that are older (ie. further back in the log), weighting them lower when deciding what angle to shoot at, and even restricting the log size. Nothing helped. Any clues? -- [[Skilgannon]]
* My early experiments have failed miserably, but I have an idea that seems like it could do the trick. The KdTree/BucketPRKdTree comes with a "max depth" parameter to its constructor. If you keep that low, new scans that land in the same leaf replace old ones. This seems like it should have a decaying effect per "segment". If you get it working, though, let me know the secret! -- [[Simonton]]
** Actually, I had a question about that parameter. What would be a "typical" value for the max depth constant for a slow-learning gun? I figured out what it did after several hours of retyping most of your code into Horizon (to avoid Ctrl-C Ctrl-V, =) but I didn't know a good value for it. I just set it to the number of dimensions (in my case, seven) and left it alone. -- [[AaronR]]
** That would be a very low value. I use 500 in DCResearch. The original purpose of that parameter is to prevent the tree from becoming infinitely deep when several scans are exactly the same ... or at least deep enough to cause a StackOverflowError when they are very close to the same. I tried several other solutions to that problem first before coming up with using a max depth, then got excited when I realize it might be a good way to decay stats, too! But don't be afraid to Ctrl-C Ctrl-V, that's why I put the jar out there! -- [[Simonton]]

It's been a while since I tweaked Shadow's movement, it's messy code. It currently surfs 2 enemy bullet logs, one for fired bullets and one for hit bullets, I think it just adds the dangers. I "decay" stats by limiting the log sizes, removing old data when it reaches its max size. I don't think I'll need to use a kd-tree unless I start surfing non-fired waves, otherwise the quantity of data doesn't justify a tree, currently 6000 and 1000 waves. It also has a failed attempt at dynamic wheighting code that, IIRC, slightly wheights the more recent waves higher than the older ones. -- [[ABC]]

* Wow - so it's basically like you just always have CurveFlattening on? I know your movement is killer, so I'm hesitant to offer advice, but based on my own experience with flatteners, I would definitely experiment with making that a dynamic decision based on enemy hit percentage. I guess it's not that surprising with Shadow's PL prowess, after all. -- [[Voidious]]

* Agreed with Voidious. Leaving the flattener on all the time hurts my score against all but the best guns. I'm curious - how many scans from your logs do you surf at a time? --[[David Alves]]

* Of course, I forgot, I enable/disable the flattener based on enemy hit rate. About the number of scans surfed: I surf them all! :) You are making me look into some strange code, it currently just builds a kind of VCS array with all the scans wheighted by the inverse squared distance to the current scan. It's not really dynamic "clustering" anymore... :-O -- [[ABC]]

** Actually I think what part your talking about. I think that entire long block might not be used at all (there was something like that in there o.O) --[[Chase-san]]

** Wait wait wait. Does this mean we have to kick you out of the TopTenDCParty? And for that matter, I believe FireBird is doing the same thing now, which might disqualify it, too. I mean, you ''could'' say it's cluster the same size as your history ... but that doesn't really make it dynamic anymore ... -- [[Simonton]]

*** Unfortunately we can't kick Shadow, as it is the original DC bot, since it was ABC who introduced it into Robocode.. with Shadow. --[[Chase-san]]

*** But wait, it's ''more'' dynamic, because the cluster size is also dynamic! =) Just kidding. Anyway, I don't think this is such a dealbreaker to call it "not DC". If the scans are weighted by inverse squared distance, most of them are getting infinitesimal weights, so you would get the same behavior with some normal cluster size. And it wasn't [[Shadow]] that introduced DC / [[TronsGun]], it was [[Tron]], of course! =) -- [[Voidious]]

I'm getting an error with the latest Shadow...
<pre>
Trying to download abc.Shadow 3.74
java.util.zip.ZipException: invalid END header (bad central directory offset)
Downloaded file is wrong or corrupted:abc.Shadow_3.74.jar
</pre>

Oh yes, and could everybody start their rumble clients? There are a lot of bots that don't have many battles... -- [[Skilgannon]]

Thanks, should be ok now. -- [[ABC]]

I ran mine all day yesterday but never caught up to the rate bots were being submitted... I'll run them again once the TC I'm running finishes. --[[David Alves]]

I had my machine running MeleeRumble overnight, but I killed that and kicked off two RoboRumble clients this morning when I got up. -- [[Voidious]]

It must be the plethora of DC bots slowing things down then. The rumble's been very active lately, though, which is a good thing =) -- [[Skilgannon]]

What's been going on with the latest versions of [[Shadow]]? -- [[Skilgannon]]

I touched the movement code, Shadow din't like it, now everything I do loses me 20+ points. :) -- [[ABC]]

Maybe it's time for that full re-write you mentioned a while back? =) -- [[Voidious]]

No time for that now, got a race going! ;) Anyway, I just found the reason for the huge rating drop in 3.74b, back to the normal "a tweak a day until I have the time for testing" program. -- [[ABC]]

Some of my best tweaks have come out of that program! =) Good luck with the hunt for 2100. The ground beneath that #1 spot feels shakier by the day... -- [[Voidious]]

Holy cow - you sure you didn't mean "DT killer"? =)
Fighting battle 20 ... abc.Shadow 3.74g,pe.SandboxDT 3.02
RESULT = abc.Shadow 3.74g wins 2797 to 1796
-- [[Voidious]]

I packaged it after I noticed I was getting 70% survival rate against Ascendant over 500 rounds! Since then I ran a few battles against Voidious, over 60%. I guess it's a "TopBot killer" version :). Got to find out why it doesn't rank above version 3.73, though...

----

FYI -- [[Simonton]]
Trying to download abc.tron3.Shadow 3.75
Could not find abc.tron3.Shadow 3.75 from http://robocode.aclsi.pt/abc.tron3.Shadow_3.75.jar

Thanks, corrected. 3.69 still used the abc.tron3 package name, wow. -- [[ABC]]

----

Strange question, I know: Why would segmenting on the enemy's circling direction significantly improve my gun's score in the TC500? -- [[ABC]]

I know why, but I'm not sure how to explain it. I thought you must have some way to deal with this....but it seems you don't. It has to do with your using PlayItForward, which is not dependant on lateral direction. I think it would help even more if you segmented instead actual velocity, not just the absolute value. -- [[Skilgannon]]

How is PlayItForward not dependant on lateral direction? I store the enemy's heading using "back-as-forward", so it shouldn't matter if the velocity is + or - . -- [[ABC]]

* Oh...so you mean the heading is rotated 180 if they are going backwards? Yeah...that should fix that problem...But how about this one: If they are going clockwise/anticlockwise then the deltaheading will be positive/negative, making them moveing in reference to an object 'mirrored' on the other side of them, instead of relative to you, 50% of the time. -- [[Skilgannon]]

* I'll think a little more about that one, I'm feeling kinda slow right now, must be because of all the festivities... :) -- [[ABC]]

* Maybe this will be easier to understand: by storing the lateral direction, you are in effect storing which side of them you are on, and thus which side they are moving relative to. -- [[Skilgannon]]
** An easy way to check would be to store whether <code>sin(eHeading - absBearing) > 0</code>, and if that situation doesn't match the current one add PI to the angle you project your bot at when rebuilding the movement. In fact, that might even be more accurate. I really shouldn't be telling you this, but new years good spirit demands otherwise :-p -- [[Skilgannon]]
* Thanks, I think I got it. My solution was a bit different, though. I trace the enemys path in the "negative" space, where clockwise and anti-clockwise are swapped, seems to work.-- [[ABC]]
* That was my original idea, but I wasn't sure if that was possible with your optimized PlayItForward. If you were reconstructing using delta-heading it would be easy just to stick a negative sign in there. -- [[Skilgannon]]

(Edit conflict) Other than Skilgannon's answer (which certainly seems plausible, depending on your setup), I had some of my own:

* First thought: It wouldn't. =)
* It's possible some enemies really do move differently in each direction - particularly if they have some subtle bug related to relative direction or some such.
* You could have a similar bug in your gun somewhere; segmenting on direction might minimize the effect of that bug.

Have you checked if one of the directions is always the more accurate one? And you're sure it's consistent enough, statistically? Sometimes it takes a whole lot of tests to get results accurate down to 1 or 2 decimal places.

-- [[Voidious]]

It sure is consistent, I've been running 10 season TC2K7 tests for the past 2 days! The difference is from a high 90% to a low 92%, one of the big score differences beeing against GrubbmGrb (88->91). I've checked the code over and over for a bug that could "counter-ballance" it, no luck. -- [[ABC]]
*Hey, why is my bot so popular to increase the score against, pick someone else! ;-) -- [[GrubbmGait]]

That is weird! Anyway, please don't rush to make Shadow's gun any stronger than it already is. =) -- [[Voidious]]

Don't worry, this is one of those situations where you think you found a big bug in your code but "fixing" it degrades your performance. I now understand why it worked and may have found a way to maybe slightly increase the learning speed in 1on1, got to run some more tests. -- [[ABC]]

I doesn't work, obviously. Sometimes I seem to forget that this is not a GF gun :). I would have to use polar coordinates in relation to my position, and that would make it much worse against the sample bots, can't have that. Maybe I'll try it someday, for now it's back to seeing if I can make it score a consistent 92 in the TC2k7 without major changes. -- [[ABC]]

Um....are you sure you're talking about the TC2K7? Shadow currently scores about 81 there...maybe you mean the TCRM? But nevertheless, nice one on the improvement! -- [[Skilgannon]]

Sorry, too much testing against GrubbmGrb, I meant 82! -- [[ABC]]
----
Getting really close to [[The2100Club]] now! -- [[GrubbmGait]]

Yep, 3.77c almost did it. I still have a few more variants to try. Lucky for you the versions optimised against GrubbmGrb seem to score slightly lower. ;) -- [[ABC]]

Oh, so close. I'm crossing my fingers for you, bro! I wouldn't count it out after 1143 battles. A lot can happen with another 850 battles, even if it has faced everyone already (which it has). It's kind of scary seeing Shadow with that high a rating... I already feared it enough when I was still 60 points ahead of it. =) -- [[Voidious]]

What's up with data saving? Isn't the cannonCaches problem solved? I'm trying the simplest data saving (create/delete a file per opponent) in Shadow and I start getting 0% results after a while in the rumble. -- [[ABC]]

Yes, it definitely should be solved. Java 1.5 fixed it, right? And Robocode now requires 1.5. I suppose it's feasible someone's running a 1.4 client with Robocode 1.07 and no -canonCaches argument, but that seems like a longshot. Maybe we can check the server's text files to see who the bad results are coming from. Now if I could just remember how/where to do that... I'll look around. -- [[Voidious]]

Just checking, do you have some way of preventing Shadow from saving too much data? That could be throwing exceptions and disabling you after enough battles against different opponents on the same machine. -- [[Skilgannon]]

* Still, wouldn't that fail at the end of the match when you write the data, and not at the very beginning when you read it? You actually can read from an over-quote directory (like if you package > 200kb of data with your bot). -- [[Voidious]]

The problem is not the amount of data, that's for sure. v3.77q saves an empty file for each enemy after the last round. It deletes the file at the beginning, that's where it must be crashing. I checked the battles file in the server, all the bad results come from someone named Rednaxela. -- [[ABC]]

* Erm, sorry about that. That was me trying out roborumble for the first time and I'm not sure what's going wrong. I'll refrain from running it for now. Gah, what an embarassement that my first intoduction in the public Robocode community goes like this (Hopefully my first public bot will enter more gracefully). Anyways, I'll run some tests with Shadow outside of Roborumble and report back here with if I figure out why I'm generating bad data on roborumble with it. -- [[Rednaxela]]
* Okay, update on my tests. Running Shadow v3.77q in normal Robocode (not rumble) at full speed for 35 rounds seems to show Shadow operating normally to my knowledge (note, debug output for Shadow reports a total of 1736 skipped turns over the course of that, but I'm not sure if that's considered normal for Shadow or not). Anyone have any suggestions to figure out why running RoboRumble here seems to be generating polluted data? -- [[Rednaxela]]

Hi, and welcome! Don't worry, the rumble client is sometimes hard to configure properly. And it's great to see a newcomer contributing. Do you have a separate directory for the rumble or do you use the same where you run your local tests? I don't know if those skipped turns are normal, I always increase the robocode.cpu.constant.1000 in my clients so I don't know how Shadow behaves in a standard setup. These last versions are kind of slow, so 1736 skipped turns doesn't sound too bad, as long as it still wins the fight ;). Best of luck with your bots, btw. -- [[ABC]]

Thought the least I could do for roborumble before I enter my current obsession was contribute a few cpu cycles. Well for local tests I've just been using plain-old-Robocode 1.5.1 built from SVN with nothing else. I run Roborumble from the same build, and they also share the robots directory. By the way, when I adjust the slider to run the battle slower in Robocode, Shadow does more like 500 skipped turns instead even though the CPU constant is the same, and yes Shadow still wins the fight at least against my current bot in development (Though I do tend to get about 2 wins out of 35 rounds, and that's with my current movement blindly running into walls too.... so we'll see...) Thanks. -- [[Rednaxela]]

Strange, if you use the same dir the error should happen in a normal battle too. Could you check Shadow's data dir in the robocache to see if it saves a file for each opponent? -- [[ABC]]

Not seeing any exceptions at all or anything odd looking in Shadow's output text. Just checked in the robocache, and I am seeing Shadow having (0 byte, which is expected given what you noted above about v3.77q) data files for opponants it's fought. I'll soon give updating Robocode/rumble to newer SVN if no other ideas show up. Anyways as it's now 4AM here, I'll sleep on it

Alright, I did some more testing using the newer Shadow 3.77r. I ran Roborumble with upload disabled, and found that some bots, including Shadow were still posting 0 or very low score alot. I then ran some of those matchups where Shadow got 0 score, outside of roborumble, and Shadow is back to winning. I'm very puzzled as to why my rumble client is behaving like this -- [[Rednaxela]]

Can you check the .sh / .bat file for the RoboRumble and see how much RAM it is allocating? It's an argument like -Xmx512M. I think the RoboRumble defaults to 256 while the Robocode one defaults to 512. That ''could'' be the problem, but I'm not sure. Anyway, welcome! And like ABC said, no need to be embarrassed - setting up Robocode / RoboRumble has gotten easier in recent years, but it's still common for newcomers to run into these issues. -- [[Voidious]]

Yes, you're right that RoboRumble is defaulting to 256. I just tested though, adjusting RoboRumble to 512, and the results are still showing Shadow and others abnormally losing with 0 score. -- [[Rednaxela]]

Why don't you give the packaged 1.4.9 a try, instead of a self-built 1.5.1? Maybe you've uncovered a bug... -- [[Skilgannon]]

Ah wait, I didn't remember correctly, my copy of 1.5.1 was packaged. Anyways, I justed tested with 1.4.9 roborumble (upload disabled), and Shadow started scoring again. I then downloaded the 1.5.2 package and tested with that, and it also worked, so it's looking like a 1.5.1-specific bug. I'll update my main install for 1.5.2 in a moment and hopefully everything will be good. -- [[Rednaxela]]

Make sure you remove the results1v1.txt so that all your faulty battles don't get uploaded. Of course if you've completely re-installed that shouldn't matter =) -- [[Skilgannon]]

Done, and now Shadow and friends seem to giving good results, so now uploading real data to RoboRumble :) -- [[Rednaxela]]

Unfortunatly Shadow 3.77r is still getting bad results, I re-enabled the data saving for testing. I checked the server again, and it's not your client uploading the bad data, but someone named ProudsHost. I will install Robocode 1.5.1 to see if I can figure out what's going on. I always end up disabling data saving, but now I'm curious if/why it doesn't affect other data saving bots... -- [[ABC]]

Best of luck figuring out what is going wrong with 1.5.1. I recall that there were some other bots that were getting unusual zero scores though can't remember which ones. I'll keep uploading good results with 1.5.2 to do the best I can to balance the bad results coming from some people using 1.5.1 -- [[Rednaxela]]

Well, coudn't reproduce the eror locally with 1.5.1. But with Shadow 3.77u I tried saving data in a more "standard" way, namely not deleting the file at the beginning of the battle. So far there have been no strange results (apart from it not scoring as good as I expected ;)), so the problem must be some security exception when deleting files. I also just noticed that it doesn't save data when run from Roboleague, anyone knows why? -- [[ABC]]
* Well, this might be a bit late, but I think I came across an explaination for your RoboLeague issue the other day. If you look on the RoboLeague page, it appears [[Voidious]] is asking about the same thing and [[Florent]] replies with <nowiki>"You should add user.cmdline=-Dsun.io.useCanonCaches\=false to launcher.properties"</nowiki> which I'm guessing will fix this for you too. -- [[Rednaxela]]
* Thanks, that fixed it. -- [[ABC]]
----

In Shadow 3.81f I went all the way with the gun. It uses 2 trees with slightly different dimensions, each with 2 cluster sizes and 3 different MultipleChoice methods. A total of 8 "guns", or predictions per aim, with a simple virtual gun setup: the one with the most virtual hits gets used. I optimised it against most of the TC2K7 no-surf bots. It scores high up there with Dookious and Phoenix in the no-surf category (87.6 after 5 seasons), with some impressive highscores against DM (92.83), RMC (84.71) and GG (93.17!). I lost a few points against the surfers with this setup, but still the total score is very good, 81.72. How can this gun not be worth some good points in the Rumble? -- [[ABC]]

The Rumble is a cruel mistress... :-\ Sorry, man, I know how frustrating that can be. It reminds me of when I gained 5 points in the RRGunChallenge and actually lost points when I released that gun with [[Dookious]]. It can't hurt to try a rerelease of each version you're comparing, though, right? Maybe there's some drift or fluctuation behind this. I'll keep a client or two going for you if you do... Maybe there are just not many points left in your gun at all, anyway? Feel free to try a version with Dooki's gun for reference, if you'd like. -- [[Voidious]]

Heh, I feel kind of like that with the neural pattern matcher gun I'm working on in Gwynfor because I'm just a brick wall with one specific issue. Perhaps movement becomes worth far more points at this point? Perhaps it would be worth looking at the results of specific bots the changes lose points against? -- [[Rednaxela]]

Movement is always worth more points than the gun ;). I just don't believe there is a situation where "there are no more points left in my gun", especially when a very small tweak can change the TC500 score against GG from 88 to 93 :). Anyway, I would love to get back to movement, but I just can't for now. I know that I'm close to some significant gun improvement, I won't stop until I find it, or until I get into "RC overdose" mode and have to take a break... cruel mistress indeed. :\ -- [[ABC]]

Hmm, well... I suppose one thought is that movement and the gun are not entirely seperate. For example, if I understand what happened correctly, DrussiousGT didn't do better than DrussGT and [[Dookious]] despite taking what was thought to be the stronger gun and movement of each. Perhaps there is more points left in the gun, but I'm suspecting that maybe when the gun gets a a certain point, tweaks under one movement are invalid for under another movement, due to how your movement affects the opponant's evasion quality. After all, if you gave my TwinDuel team a high quality gun tweaked for it's movement, the same tweaks may not be effective if that gun were put on a different team. That example is particularly biased due to how agressive LunarTwins movement is and that it will almost always trigger things like dive protection if it exists, however, surely your movement would always effect the opponant's movement and thus evasion quality to some degree. Of course I've yet to experience tweaking a bot for the rumble and I'm just rambling about by what I've observed. I might be rambling about the obvious or spouting nonsense, so sorry if I'm being redundant or wrong :) -- [[Rednaxela]]

Sure, the movement can influence the enemy's behaviour and your own gun performance. But with the exact same movement the gun can always be improved upon, except if you have 100% accuracy against everyone, and we are still a bit far from that ;). The changes that will impact your rumble rating the most may be dependant on your gun balancing out your movement's problem bots, but still an "absolute" gun improvement is always possible. Then there are the surfers, quite a few these days, against who your gun improvements can actually degrade your performance and make it so that sometimes small bugs actually gain you points. That's why I've been optimising mostly against the random movers. -- [[ABC]]

----

One thing that I noticed during testing againts 3.81f is that you don't rebuild the waves' dangers after being hit by a bullet. Only new waves get the updated stats. Doing this can save you a couple bullet hits during early rounds... at not much of a performance hit. -- [[Skilgannon]]

* I haven't watched Shadow's behavior in this regard but I thought I'd chime in with my thoughts about rebuilding wave dangers in such situations. For normal surfing dangers, I do it like [[Skilgannon]] and update the danger of all waves when I get new information, however in the flattener dangers I don't update old waves with new information. My thought is that with normal surfing dangers, you're trying to reconstruct a rough model of how their gun fires over an extended time period so new data can be helpful in waves that have already fired, with flattener dangers however you're essentially presuming the opponant is an adaptive GF gun or something similar (at very least, some sort of adaptive gun) and dodge that, in which case I think it makes the most sense to only use the information the enemy had avaliable when they fired. I haven't been able to verify if my theories about this help much in practice, but that's my thoughts/theories/ramblings about when wave dangers should and shouldn't be updated. -- [[Rednaxela]]

* I reached exactly the same conclusions, however due to my implementation, if the hit data gets updated for the wave, the flattener data also gets updated. It would be fairly easy to fix, but I doubt worth the bother. -- [[Skilgannon]]

You are right Skilgannon, Shadow never rebuilds the waves' dangers. Maybe I'll try changing that sometime, but I'm not sure that those hits are important in a battle. My reasoning is that I'm reenforcing the enemy's gun data, so maybe I'll dodge a couple of hits later because it will take him longer to realise I'm not there anymore. Anyhow, I'm not ready to mess with my movement code just yet, I'll just try a few small gun ideas I had while "away" (you can leave, but Robocode stays in your head like a plague :)) and see where that leads me. -- [[ABC]]

The main reason I was suggesting this is because against the simple targeters the quicker you adapt the less hits they can get against you. But perhaps it doesn't matter, I dunno =) -- [[Skilgannon]]

You are probably right, I always think about optimising against the better guns. Maybe I'll try it only in the first round. -- [[ABC]]

Ok, version 3.82a recalcs all the flying waves in the first 3 rounds. -- [[ABC]]

Interesting, 3.82a lost the edge against some top bots while still maintaining its ranking. 3.82b recalcs dangers only when it's not using the flattener. -- [[ABC]]

It works, thanks for the tip Skilgannon :). And it should be much faster against weak guns, I was computing the flattener danger (= big log) even when I wasn't using it. Now I feel tempted to tweak the theshold for activating the "simple gun" mode... -- [[ABC]]

One little thought, is in some ways it may make sense to have a separate threshold for when to activate the flattener and when to stop updating waves that are in midair. My reasoning is, mistakenly not updating midair waves is far less harmful of a mistake than mistakenly turning the flattener on, and in addition not updating midair waves should be good against most adaptive guns even if weak where as the flattener may not be helpful against some of the weaker adaptive guns. Just a little thought that came to mind. -- [[Rednaxela]]

Agreed, I'll try separating them soon. I already have separate simple/top gun flags, originally intended to separate the simple/learning/anti-surfer guns, but currently I only use the simple one for the flattener (and now for danger recalc). It's very hard to optimise these things, and I always tend to reject changes that decrease my PL ranking. ;)

Version 3.82d separates those 3 groups. The flattener is on for all but the simplest guns, and flying waves are recomputed on hitByBullet (and bulletHitBullet ) for all but the best guns. The few tests I made look promising, as do the first few rumble results. I'm going to bed with my fingers crossed. :) -- [[ABC]]