2004-03-07: version 1.04. Tweaking to regain the lost positions.
2004-03-07: version 1.03. (@2004-03-07: 11th, 1878.35)
- Complete WaveSurfing restructuration. Expect improve against weaker weapons, little improve against GFGuns and probably problems against PMs...
2004-02-30: version 1.02. (@2004-03-07: 7th, 1921.26)
- Added a little secret that might help.
2004-02-29: version 1.01. (@2004-02-29: 7th, 1927.96)
- First version with WaveSurfing.
2004-02-24: version 0.02. (@2004-02-29: 14th, 1845.29)
- Gun tweaking. GF0 avoiding tweaked. Saving bug & occasional Condition.test exception solved.
2004-02-17: version 0.01 released. (@2004-02-24: 9th, 1852.03)
- Movement WaveSurfer implemented, not AM yet. Althought the EnemyWaves & GFs work is done, i'm only using them to do the MusashiTrick job more accurately. This version uses by experiment a flattening formula based on Jamougha's ideas, so well implemented in Raiko series (think that my job wasn't so good), actually the class is named JamPilot :), all credits to him.
Note: The Jamougha formula is an experiment while putting together the real AM.
2004-02-11: version 0.01 under development.
What's special about it?
It's my AM bot.
Great, I want to try it. Where can I download it?
How competitive is it?
How does it move?
WaveSurfer movement, version 0.01 uses the Jamougha's flat formula.
How does it fire?
Same as Musashi
Where did you get the name?
Short for Kozure Okami, Lone Wolf in english or Lobo Solitário in portuguese.
A japanese manga writen by Kazuo Koike, art by Goseki Kojima.
Can I use your code?
It will be open-source, as usual for me.
It is based on any other bot?
based on Musashi.
Inspired by all good bots.
Althought the EnemyWaves & GFs wok is done - GFs wok , hmmm.Tastes well!!! :D --deathcon
- Imagine if i add a pinch of 'r's, even better... -- Axe
- rotfl ! Maybe we should write a cookbook.
That 0.01 version had became a disappointment. The movement is entirely different from Musashi's, and the final result is: Almost the same scoring that Musashi... I would be happier even if it stayed bellow Musashi, the same is meanless... I'm gonna review that Jamougha's formula implementation, probably that weightening (and/or a wall-dist factor that i have added) are affecting it. It's just an experiment, but i'm curious now... -- Axe
That movement breaks if you change virtually anything, especially the distancing controls. Blackpearl actually dropped 10 points or more after implementing it. I'm experimenting with one final tweak which might improve it, and then I think I'll give up on it and start from scratch. Maybe even with an adaptive movement. -- Jamougha
That's my idea too. Okami's movement will be pure AM, but in the meantime, I implemented that JamPilot (consider it an homage) class, since your (1/bulletTime)^(1/bulletTime) seems brilliant and natural for me. One thing that bothers me is that factor (u use 0.59..), i used tweaked ones by my self (but not so diff), theorically the formula is perfect, and that factor should be 1. My best guess is, that isn't 1 because of the walls (even if u dont kick, u will reduce your scape angle). The walls reduce the "possibilities" of the more hight GF vals, so to compensate that we use a factor to reduce the turning probability... And the formula became un-pure. I have to say that i loosed faith on formula based flat movements, if your formula can't do the job... The best way, probably, is to do it on-the-fly, by keeping a record of your own gfs and then adjust it every wave. -- Axe
The tuning factor takes into account a few of things; firstly the bot is not of zero size, secondly my assumption that we only ever reach positive guess factors is incorrect, and thirdly and most importantly as you note the damned walls. :-) My new version has no tuning factors at all, pure theory, but doesn't work against power 3 bullets because the probability of intersecting with a wall is wrong, and I'm not certain it's as good against certain segmentation. :-( -- Jamougha
Ach... My head is aching!!! Ther is the first version with the WaveSurfing movement. I really should had tested it more, but i'm tired of GF's and wave directions bumping inside my head... The code is a mess, probably there is a lot of room for bug corrections and parameters tweaking. Alea jacta est. -- Axe
Where can I find Jam's "flat formula"? -- Scoob
Can anyone help me with the syntax at Participants page? I had to upload here because Repository won't accept files that size (251Kb). Wowww! I had uploaded it to wiki, but the syntax that i had put in Participants isn't working... -- Axe
Nevermind, i had cutted out some garbage: 236Kb now. I don't know why that size retriction at repository, my bot isn't that big, it isn't not even a MegaBot... (0,2 MegaBot actually!) :)) -- Axe
I already heard that: "My AM might have a problem against those PM guns."... -- Axe
It'll fix itself once the guilty RR@H client is fixed. If I were Paul I would remove the configuration option from my next DT... -- PEZ
I'm thinking about something like if(getNumRounds() == 35) behavior = "normal", but then there is the fast learning challenge... -- ABC
Er.... there wasn't a 30th of February last time I checked... ;-) -- Tango
@Tango Huh? Anyway... I thought of a way to cancel out the bad results. Suppose Okami is expected to lose 60%-40% against DT, and it won 6000-2000. All we have to do is manually submit a match of Okami vs. DT where DT wins by 10000-2000. This brings their total up to 12000-8000, which matches the expected ratio. Would this work? --David Alves
1) Look at the History at the top of this page. 2) I think it would, but isn't that breaking things even more in order to fix them? -- Tango
1) lol :-) 2) Well the right way to do it would to remove the bad matches, but I'm assuming that's impossible, because otherwise I think PEZ would have done it already. :-p --David Alves
That particular result with Okami isn't a real problem, since i'll probably release a new version in the next days, the problem is all the other results... If i were Paul and ABC, i'll probably do as PEZ says. It's sad, but true. -- Axe
RR@H could be modified slightly to use a battlefield of 801x600, so bots can easily check getBattleFieldWidth()==801, and there would be no reason for anyone to use such a battlefield in non-RR@H battles, and it wouldn't significantly effect battles. -- Tango
I can't know what matches are bad really. (Quite a few suspicious in DT's details sheet.) The file format isn't exactly readable like that and editing is error prone. Besides I think we have the bad client running still. Let's wait until we don't see it deliver crazy results. If we're gonna modify the client we should think harder first I think. Modifying a few bots seems better if you ask me. -- PEZ
The following pairings are bad:
- DT vs. axeBots.Okami_1.02 (One of the four battles)
- DT vs. bvh.fnr.Fenrir_0.305
- DT vs. rz.Aleph_0.32
- DT vs. kawigi.nano.ThnikkaBot_0.9 (One of the three battles may be bad, or it may be a ProblemBot, unclear)
Note that they're all bots that have been recently released. The results vs. PrairieWolf and DogManSPE are not bad, those are ProblemBots for DT. --David Alves
Arghhh! Lesson #1: Test it. Lesson #2: remember lesson #1. Aprox. -50 pts... Let´s go back to worksheet (that last one was a workshit actually).:( -- Axe
plus 74 points in 18 hours for me. :-D Now if it were only possible to maintain this pace... --David Alves
I saw JALT... Prime work. If i only could reverse my pace :)... -- Axe
There it is, i never learn do i? Few tests again... Version 1.04 tweaked, expecting at least ~1920. -- Axe