Editing revision 98 of RougeDC/TargetingLab

Robo Home | Changes | Preferences | AllPages

Editing old revision 98. Saving this page will replace the latest revision with this text.

Well, inspired by [[Simonton/DCResearch]] and my poor targeting results, here's a page where I'll document my progress with the gun in RougeDC, including versions that won't get to the RoboRumble.

----

[[TargetingChallenge2K7/ResultsFastLearning]]
| '''RR Version''' | '''TC Version''' | '''CC''' | '''RMX''' | '''SHA''' | '''WS''' | '''WOE''' | '''Surf''' | '''DM''' | '''FT''' | '''GG''' | '''RMC''' | '''WLO''' | '''No Surf''' | '''Total''' | '''Comment''' 
| Alpha15 | TC_RAIKO | 58.51 | 56.58 | 58.22 | 61.92 | 62.85 | '''59.61''' | 86.77 | 80.17 | 82.11 | 78.24 | 86.28 | '''82.71''' | '''71.16''' | 103.0 seasons
| Beta3 | TC01 | 51.03 | 69.51 | 59.16 | 60.15 | 58.35 | '''59.64''' | 87.59 | 73.75 | 71.49 | 74.19 | 76.96 | '''76.80''' | '''68.22''' | 15.0 seasons
|           | TC02 | 51.91 | 65.88 | 58.87 | 59.57 | 58.91 | '''59.03''' | 86.23 | 73.59 | 74.34 | 73.63 | 76.73 | '''76.90''' | '''67.96''' | 16.0 seasons
|           | TC03 | 51.38 | 66.41 | 61.82 | 62.30 | 63.72 | '''61.13''' | 82.49 | 77.31 | 69.67 | 74.78 | 70.66 | '''74.98''' | '''68.05''' | 15.0 seasons
|           | TC04 | 59.06 | 76.54 | 62.82 | 76.33 | 79.53 | '''70.86''' | 81.53 | 73.99 | 69.21 | 70.64 | 75.76 | '''74.23''' | '''72.54''' | 15.0 seasons
|           | TC05 | 51.68 | 70.76 | 60.72 | 64.79 | 61.43 | '''61.87''' | 84.44 | 75.47 | 70.25 | 74.26 | 75.08 | '''75.90''' | '''68.89''' | 25.0 seasons
|           | TC06 | 65.00 | 83.24 | 64.38 | 85.72 | 78.58 | '''75.38''' | 83.22 | 76.74 | 74.88 | 73.29 | 76.85 | '''77.00''' | '''76.19''' | 16.0 seasons
|           | TC07 |           |           |           |           |           |              | 87.08 | 78.54 | 80.34 | 79.17 | 81.29 | '''81.28''' |              | 25.0 seasons
|           | TC08 |           |           |           |           |           |              | 86.30 | 79.08 | 81.54 | 78.96 | 81.22 | '''81.42''' |              | 15.0 seasons
|           | TC09 | 66.40 | 79.80 | 62.69 | 76.97 | 69.78 | '''71.13''' | 86.77 | 79.88 | 80.57 | 78.40 | 81.66 | '''81.46''' | '''76.29''' | 114.0 seasons
|           | TC10 |           |           |           |           |           |              | 85.35 | 78.68 | 79.82 | 77.89 | 79.65 | '''80.28''' |              | 16.0 seasons
|           | TC11 |           |           |           |           |           |              | 87.86 | 80.48 | 80.89 | 77.91 | 82.85 | '''82.00''' |              | 115.0 seasons
|           | TC12 |           |           |           |           |           |              | 86.46 | 79.45 | 80.04 | 77.90 | 82.66 | '''81.30''' |              | 18.0 seasons
|           | TC13 |           |           |           |           |           |              | 87.23 | 79.39 | 79.80 | 77.34 | 82.81 | '''81.32''' |              | 15.0 seasons
|           | TC14 |           |           |           |           |           |              | 87.42 | 81.56 | 78.34 | 78.25 | 83.25 | '''81.76''' |              | 15.0 seasons
|           | TC15 |           |           |           |           |           |              | 86.81 | 80.17 | 81.13 | 78.41 | 82.32 | '''81.77''' |              | 119.0 seasons
| Beta4a | TC16 | 65.64 | 77.91 | 63.22 | 75.33 | 69.38 | '''70.29''' | 87.28 | 80.27 | 80.38 | 78.04 | 83.07 | '''81.81''' | '''76.05''' | 183.0 seasons
|           | TC17 | 68.43 | 80.32 | 61.73 | 77.52 | 70.96 | '''71.79''' | 86.76 | 80.27 | 80.13 | 79.95 | 83.13 | '''82.05''' | '''76.92''' | 43.0 seasons
|           | TC18 | 67.57 | 78.95 | 62.13 | 76.98 | 71.35 | '''71.40''' | 85.91 | 80.49 | 80.62 | 79.30 | 84.18 | '''82.10''' | '''76.75''' | 125.0 seasons
|           | TC19 | 68.23 | 80.74 | 63.20 | 76.94 | 72.04 | '''72.23''' | 86.46 | 81.15 | 81.40 | 79.62 | 83.11 | '''82.35''' | '''77.29''' | 107.0 seasons
| Gamma1 | TC20 | 69.08 | 80.25 | 63.84 | 77.69 | 72.42 | '''72.66''' | 86.38 | 80.86 | 81.74 | 78.49 | 84.12 | '''82.32''' | '''77.49''' | 113.0 seasons
|           | TC22 | 68.84 | 80.82 | 63.79 | 77.66 | 71.27 | '''72.48''' | 86.46 | 80.16 | 80.38 | 78.90 | 83.34 | '''81.85''' | '''77.16''' | 45.0 seasons
|           | TC23 | 70.03 | 85.56 | 65.06 | 83.92 | 83.19 | '''77.55''' | 82.44 | 77.40 | 76.26 | 75.64 | 79.76 | '''78.30''' | '''77.92''' | 41.0 seasons
|           | TC24 | 69.58 | 82.56 | 65.77 | 83.49 | 83.99 | '''77.08''' | 81.69 | 74.85 | 74.42 | 73.41 | 77.20 | '''76.31''' | '''76.70''' | 16.0 seasons
|           | TC25 | 69.49 | 76.97 | 66.56 | 75.55 | 72.74 | '''72.26''' | 78.39 | 74.85 | 82.83 | 75.63 | 80.70 | '''78.48''' | '''75.37''' | 2.8 seasons
|           | TC26 | 73.55 | 86.94 | 65.82 | 87.70 | 83.70 | '''79.54''' | 85.75 | 79.59 | 79.90 | 79.04 | 83.08 | '''81.47''' | '''80.51''' | 84.0 seasons
| Gamma2 | TC27 | 73.73 | 87.15 | 66.57 | 86.48 | 82.45 | '''79.28''' | 86.45 | 80.40 | 80.54 | 78.47 | 82.06 | '''81.58''' | '''80.43''' | 60.0 seasons

[[TargetingChallengeRM/Results]]
| '''RR Version''' | '''TC Version''' | '''Aspd''' | '''Sprw''' | '''Fhqw''' | '''Yngw''' | '''<nowiki>FlMn</nowiki>''' | '''EASY''' | '''Tron''' | '''HTTC''' | '''<nowiki>RnMB</nowiki>''' | '''<nowiki>DlMc</nowiki>''' | '''Grbb''' | '''MEDIUM''' | '''<nowiki>SnDT</nowiki>''' | '''Cgrt''' | '''Frtn''' | '''<nowiki>WkOb</nowiki>''' | '''<nowiki>RkMc</nowiki>''' | '''HARD''' | '''TOTAL''' | '''Comments'''
| Gamma1 | TC20 | 91.65 | 97.50 | 94.84 | 96.50 | 92.18 | '''94.53''' | 87.27 | 87.86 | 87.94 | 85.98 | 80.64 | '''85.94''' | 75.15 | 83.55 | 80.23 | 83.65 | 79.68 | '''80.45''' | '''86.98''' | 50.0 seasons
| Gamma2 | TC27 | 89.34 | 96.95 | 94.67 | 96.45 | 92.79 | '''94.04''' | 86.32 | 87.37 | 88.09 | 86.45 | 80.54 | '''85.75''' | 75.18 | 83.13 | 80.40 | 82.06 | 78.47 | '''79.85''' | '''86.55''' | 53.0 seasons
| | TC28 | 88.47 | 95.21 | 94.68 | 96.50 | 91.95 | '''93.36''' | 85.87 | 87.15 | 87.48 | 85.47 | 77.14 | '''84.62''' | 73.13 | 82.95 | 79.88 | 81.93 | 79.16 | '''79.41''' | '''85.80''' | 48.0 seasons
| | TC29 | 90.81 | 96.82 | 95.90 | 96.55 | 93.00 | '''94.62''' | 87.39 | 88.27 | 87.97 | 88.27 | 81.30 | '''86.64''' | 75.29 | 83.85 | 79.19 | 83.99 | 78.62 | '''80.19''' | '''87.15''' | 50.0 seasons
| | TC31 | 90.19 | 97.53 | 95.29 | 96.13 | 92.94 | '''94.42''' | 87.25 | 88.00 | 88.69 | 89.11 | 80.70 | '''86.75''' | 73.92 | 84.36 | 78.30 | 82.07 | 77.71 | '''79.27''' | '''86.81''' | 50.0 seasons
| | TC32 | 92.92 | 95.97 | 94.65 | 96.42 | 92.50 | '''94.49''' | 87.22 | 88.35 | 87.01 | 87.37 | 81.61 | '''86.31''' | 74.33 | 84.20 | 80.44 | 82.23 | 78.47 | '''79.93''' | '''86.91''' | 50.0 seasons
| | PM01 | 67.30 | 95.51 | 92.36 | 94.58 | 84.01 | '''86.75''' | 83.76 | 82.12 | 87.23 | 62.91 | 70.10 | '''77.23''' | 61.72 | 60.59 | 70.10 | 78.35 | 72.29 | '''68.61''' | '''77.53''' | 30.0 seasons
| | PM05 | 85.21 | 96.42 | 91.85 | 94.75 | 87.28 | '''91.10''' | 81.59 | 80.48 | 86.69 | 87.41 | 76.23 | '''82.48''' | 63.13 | 74.91 | 75.52 | 79.08 | 76.84 | '''73.90''' | '''82.49''' | 30.0 seasons
| Gamma3 | TC33 | 89.87 | 97.53 | 94.47 | 96.93 | 93.59 | '''94.48''' | 87.52 | 87.94 | 88.10 | 89.50 | 81.54 | '''86.92''' | 74.62 | 83.87 | 78.95 | 82.21 | 80.63 | '''80.06''' | '''87.15''' | 50.0 seasons
| | TC34 | 90.57 | 96.06 | 94.29 | 96.23 | 92.57 | '''93.94''' | 85.83 | 86.64 | 88.22 | 87.75 | 80.05 | '''85.70''' | 73.47 | 82.41 | 79.26 | 82.81 | 78.84 | '''79.36''' | '''86.33''' | 10.0 seasons
| | TC36 | 90.27 | 97.03 | 94.41 | 96.48 | 92.95 | '''94.23''' | 86.01 | 88.59 | 88.41 | 88.03 | 81.64 | '''86.54''' | 74.82 | 84.56 | 77.90 | 82.35 | 77.27 | '''79.38''' | '''86.71''' | 50.0 season
| Gamma4 | TC37 | 89.40 | 97.50 | 95.26 | 96.77 | 92.46 | '''94.28''' | 85.62 | 87.52 | 88.15 | 88.33 | 80.04 | '''85.93''' | 74.70 | 84.64 | 81.01 | 81.22 | 80.13 | '''80.34''' | '''86.85''' | 50.0 seasons
| | TC39 | 91.13 | 95.02 | 93.39 | 96.57 | 92.44 | '''93.71''' | 86.81 | 87.40 | 86.92 | 86.71 | 82.24 | '''86.02''' | 75.07 | 84.24 | 79.16 | 81.59 | 77.64 | '''79.54''' | '''86.42''' | 50.0 seasons
| | TC40 | 92.91 | 96.93 | 96.32 | 97.28 | 92.00 | '''95.09''' | 90.00 | 87.42 | 88.05 | 86.88 | 82.55 | '''86.98''' | 77.31 | 82.58 | 80.75 | 82.55 | 79.95 | '''80.63''' | '''87.56''' | 40.0 seasons

Custom Surfer Challenge. TargetingChallenge2K7 surfers, plus: [[Dookious]] 1.573c, [[Chalk]] 2.5.Al, [[Komarious]] 1.78b, [[GresSuffurd]] 0.2.10, [[DarkHallow]] .90.9, and [[stelokim|MatchupWS]] 1.2c
| '''RR Version''' | '''TC Version''' | '''CC''' | '''RMX''' | '''SHA''' | '''WS''' | '''WOE''' | '''TC2K7''' | '''Dooki''' | '''Chalk''' | '''Kom''' | '''Sub1''' | '''Gres''' | '''DH''' | '''MWS'''| '''Sub2''' | '''Total''' | '''Comment''' 
| Gamma1 | TC20 | 68.80 | 79.67 | 64.90 | 78.63 | 73.47 | '''73.09''' | 58.31 | 67.50 | 84.68 | '''70.16''' | 86.59 | 76.21 | 85.07 | '''82.63''' | '''75.29''' | 50.0 seasons
| Gamma2 | TC27 | 73.84 | 87.15 | 66.57 | 86.48 | 82.45 | '''79.30''' | 55.08 | 71.14 | 90.14 | '''72.12''' | 94.60 | 84.09 | 89.21 | '''89.30''' | '''80.24''' | 40.0 seasons
| Gamma3 | TC33 | 67.35 | 76.17 | 62.42 | 75.21 | 70.73 | '''70.38''' | 58.68 | 68.72 | 82.30 | '''69.90''' | 86.12 | 74.94 | 80.77 | '''80.61''' | '''73.63''' | 50.0 seasons

[[PatternMatcherChallenge/PMCIndex]]
| '''Version''' | '''PMCIndex''' | '''Comment''' 
| PM01 | 95.00% | 3 seasons
| PM02 | 58.74% | 1 season*
| PM03 | 100.02% | 1 season
| PM04 | 98.71% | 1 season
| TC20  | 97.71% | 1 season
| PM05 | 99.32% | 1 season

'''Version History:'''
* '''TC_RAIKO:''' The old [[Raiko]] gun that I used in the RougeDC Alpha series, then adapted to follow the TC2K7 rules. Here for reference.
* '''TC01:''' Exactly the same as in the Beta3 RoboRumble release. A brand new DC/GF gun that I quickly wrote and reuses the DC work I did in [[RougeDC]]'s surfing. Segments only on LateralVelocity and RetreatingVelocity. Uses precise 'botwidth', including watching '''all''' guessfactors the bot intersects for '''all''' ticks that the wave intersects the bot (This goes beyond the precision in [[Garm]] if I understand correctly). Uses a 'cluster size' of 30 for DC and weights further away situations from the current situation lower. Chooses a GF overlapped by the 'greatest number' (with non-exact matches weighted as less than 1) of situations in the 'cluster'.
* '''TC02:''' Added a distance segment. Doesn't seem to be very helpful contrary to it's popular usage by others.
* '''TC03:''' Fire at random positive guess factors before any any info is known. Replaced the distance segment with a "how many times has the opponent been hit" segment. As expected this seems to improve performance against surfers overall, but decrease performance against other bots.
* '''TC04:''' Increase the weighting a lot against the non-exact matches. This seems to give me nearly a 10 point boost against the surfers!
* '''TC05:''' Give the "how many times we hit" segment 1/20th of it's weighting. This seems to kill performance against surfers too much. On the bright side, it appears I've come up with a somewhat useful anti-surfer segment that I haven't heard of used before. Instead of constantly rolling the stats, it only rolls them when the opponent gets a chance to know where we fired.
* '''TC06:''' Hahaha! It works! Put the "how many times we hit" segment back to it's old weighting. Added forward/backwards wall distance segments and they seem to work great. This score is finally getting close to something good, it's not far behind [[Lukious]], [[Garm]] and such.
* '''TC07:''' Decreased the "how many times we hit" to 1/200th strength (just strong enough to weakly prefer new data over old). Seems to bring non-surfer score up to nearly-Raiko level.
* '''TC08:''' Added a time-since-decel segmented and a weakly weighted distance segment. Doesn't seem to perform significantly better.
* '''TC09:''' Remove the distance segment, keep the time-since-decel segment. Haha! Up to Raiko standards against non-surfers now!
* '''TC10:''' Change 'cluster size' to 10. As I expected it hurt the score, but was worth a try.
* '''TC11:''' Change 'cluster size' to 60. Doesn't seem to do much good for the most part. A good DuelistMicro score though, wonder why that and not the others... '''Update:''' A re-run more through test seems to show that it only hurts against RaikoMicro and overall helps :)
* '''TC12:''' Change 'cluster size' back to 30. Cut the weighting against non-precise matches by 20x. Didn't do any good... running out of ideas a little bit now
* '''TC13:''' Revert to TC09. Reduce the weighting of my "anti-surfer" segment 1000x (1/200000th of the weight that it was in the anti-surfer specializing TC06). It decreased the score a bit, so it looks like that segment still has some (but much lesser) relevance to the non-adaptive bots too? Interesting...
* '''TC14:''' Reduce the weighting of the reverse wall distance segment to 10%. This doesn't seem to help either.
* '''TC15:''' Based on TC11, and reduce weighting of the reverse wall segment like TC14. Doesn't seem helpful.
* '''TC16:''' <strike>Based on TC11.</strike> Actually based on TC09 accidentally. As a rule, fire at GF 0 if the enemy is disabled and unmoving. Also account for my own movement when aiming (shouldn't affect this challenge of course though). Same as Beta4a release. 
* '''TC17:''' Based on TC16. Add CircularTargeting, as 1) The default gun to use before the DC gun has data and 2) A contributer to a dynamically weighted [[MultipleChoice]]/[[CrowdTargeting]] scheme. It appears that even CircularTargeting can add a little value with CrowdTargeting! I look forward to seeing how it does when I replace it with something more useful like a PatternMatcher... :)
* '''TC18:''' Based on TC17. Try a somewhat different tweaking of the dynamic weighting algorithm for the CrowdTargeting. Seems to improve results against some bots, hurt results against others, but overall acts similarly.
* '''TC19:''' Based on TC18. Change the dynamic weighting algorithm for the CrowdTargeting some more. This revision seems to choose rather nice weights, so I'll start working on the PatternMatcher to replace the CircularTargeting with now.
* '''PM01:''' First revision of my [[PatternMatching/SingleTick|SingleTick]] PatternMatcher. No MultipleChoice yet but that will be coming later. Matches on acceleration and deltaheading and has a maximum search depth of 25.
* '''TC20:''' Based on TC19. Replace the CircularTargeting with PM01 (modified to 15 depth). Seems to help overall, better than the CircularTargeting. Should be improved further when I give the PM the big advance of being MultipleChoice...
* '''PM02:''' First attempt to adapt into a MultipleChoice PatternMatcher. Looks like I introduced some kind of major bug... Confirmed to be very buggy: It gets the same score when I configure it to only project a single future 'reality' instead of multiple
* '''PM03:''' Fixed the bugs! I now have a working MultipleChoice [[PatternMatching/SingleTick|SingleTick]] PatternMatcher (10 MC options right now) which seems to perform quite nicely! The MultipleChoice part seems to improve the hitrate in the early parts of the round where the old pattern matcher fails.
* '''PM04:''' Reduce pattern depth to 15 ticks, and limit it to simulate 5 possible future realities at a time instead of 10. This is for performance reasons.
* '''TC21:''' TC20 with PM04, also known as: Biggest SlowBot Ever! Running a mere 3 seasons of TC2K7 (fast learning) took at least 45 minutes! While I was able to run PM04 in the PatternMatcherChallenge fast enough because there are not many possible future permutation paths to explore against PatternBot and the required bullets are far faster (have to simulate FAR fewer ticks), running that pattern matcher in more realistic targeting like in TC2K7 is far too slow!
* '''TC22:''' Based on TC20. Change the CrowdTargeting weightings to have a negative offset of 10% to account for the part of the rating that would just be from dumb luck. Doesn't seem to help.
* '''TC23:''' Based on TC20. Turn up the volume on the "anti-surfer" DC segment 200x, because right now I'm going to see how well I can tune it to hit surfers, and then later combine both versions via CrowdTargeting.
* '''TC24:''' Based on TC23. Make the "anti-surfer" segment 5x stronger again. Well that doesn't seem to help. Don't need to run many seasons to tell it's overall worse.
* '''TC25:''' Based on TC23 and TC20. Make a quick hack to use both tweaks of the DC gun in CrowdTargeting. Bah! Doesn't work! My quick hack had major bugs! For one, I wasn't even using the anti-surfer gun at all, and secondly I was horribly corrupting my CrowdTargeting weights by accident! Ignore this revision...
* '''TC26:''' Based on TC25. TC25 done right (bugs worked around). Looking pretty good! There's a slight drop in the non-surfer score that I'll have to fix, but this is the best anti-surfer score I've ever seen besides [[Simonton/DCResearch|DCResearch]] 0037!
* '''TC27:''' Based on TC26. Turned the "cluster size" up to 60 on the non-surfer DC. Seems to improve results a little, so I'll release Gamma2 based on this. Non-surfer scores aren't quite up to TC20 level still though.
* '''TC28:''' Based on TC27. Only activate the "wall distance" segments when closer than 1 GuessFactor unit. Doesn't seem to do any good.
* '''TC29:''' Based on TC20. Use 'cluster size' 60 and cut the advancing velocity segment to half strength.
* '''PM05:''' Not at all based on PM01 to PM04. It's my brand new MultipleChoice PatternMatcher. Nothing special about it yet, it's rather similar to the multiple choice matchers showing up in the micro rumble, except it's far larger in codesize and by my estimation more efficient in pattern search speed.
* '''TC31:''' Based on TC29. Replace PM01 with PM05. Huh... it decreased the score even though I'm pretty sure the pattern matcher is stronger. I think this indicates my CrowdTargeting weighting algorithm is probably weighting PM05 too strongly...
* '''TC32:''' Based on TC31. Use the DC gun only, not the PM.
* '''TC33:''' Based on TC31. Change the CrowdTargeting to use a multiplicative scheme instead of an additive scheme as I expect is more statistically sound. Seems to work... BUGGY!
* '''TC34:''' Based on TC33. Try a new way of generating the CrowdTargeting weights. Still needs some work... BUGGY!
* '''TC36:''' Based on TC33. Try weighting relative to the baseline of what random targeting should get. Doesn't help... Is there no more potential to be squeezed out of the weighting system? =\ BUGGY!
* '''TC37:''' Based on TC33. Use a non-rolling average until the the amount new data would affect it reaches equilibrium with the rolling average. Also fixed a bug since TC33 that would cause the bot to occasionally freeze for an entire match. Based on this scoring poorer than TC33, I am suspecting that the method I am using to generate the weighting values, is at fault...
* '''TC39:''' Use the main DC gun alone.
* '''TC40:''' Use tick waves instead of just firing waves.

'''Todo:'''
* <strike>Build a [[MultipleChoice]] [[PatternMatching/SingleTick|SingleTick]] variable-length PatternMatcher to add to the CrowdTargeting</strike> Unsuccessful. I managed to build such a pattern matcher but it was far too slow. Sticking with non-[[MultipleChoice]] [[PatternMatching/SingleTick|SingleTick]] for now...
* Improve the PatternMatcher
** Thinking of going the route of MultipleChoice non-[[PatternMatching/SingleTick|SingleTick]] eventually
* Try out other segments
** <strike>In particular, forward/reverse wall distance looks promising</strike> done!
* <strike>Create an AntiSurfer configuration of the DC gun and test running it alongside the normal one in CrowdTargeting configuration.</strike> Done! Seems to work rather nicely!
* Try making guessfactors relative to lateral acceleration direction instead of lateral velocity direction
* <strike>Just plain make it not so horrible :)</strike> Done? Well I wouldn't call it horrible now... but I still have plans for it :)

=== Discussion ===

Hmm, one trend I'm finding, is that many things I do that help against surfers, hurt against non-surfers, and vice versa. It's rather bothersome really. It's looking like I'll either need to go the [[VirtualGuns|virtual gun]] route, OR use dynamic weighting of some kind. What bothers me about dynamic weighting though, is I'm not sure how I could make that work with my kd-tree. At best, it would be a very invasive change to my kd-tree to make it able to support dynamic weightings... not to mention how I'm somewhat dissatisfied with most existing metrics I've seen for dynamically deciding weightings. I think for now I'll first focus on adding some wall segments, because firing out of bounds when CassiusClay has run away to the other wall, is tiresome. -- [[Rednaxela]]

Don't put too much weighting on the Surfer score - having a strong surfer gun will at most give you a 10-15 point boost. The majority of the bots in the rumble don't have adaptive movement, and they are where you get the majority of your points from. If you can increase your gun against non-adaptive movement by 1% I would say it is worth a 8% drop against surfers. Oh yes, a *very* useful segment is time-since-deceleration, or time-since-lateral-direction-change, possibly divided by bullet flight time to make it relevant at all distances. -- [[Skilgannon]]

Well, while a strong surfer gun doesn't give much of a bonus in ELO rating, I think that it can still be very worthwhile as far as primere league score (which I am rather interested in) because it tends to be more about beating as many different bots as you can in 1v1 as opposed to trashing the weak bots by as big a margin as possible. Right now, it's my goal to try and make the gun as strong as I can in both categories, and then see how well I cam make some sort of dynamic weighting tune against both sorts (and if not, split the gun into two version and use virtual guns). About time-since-lateral-direction-change segments and such, yes, I have heard good things about those and those are up soon on my list of things to try :) -- [[Rednaxela]]
 '''Update:''' Well I just added the results with the Raiko gun above to compare. As I had been expecting it scored a fair bit lower against the surfers, but a fair bit higher against the non-surfers, in fact it's non-surfer score is among the best in [[TargetingChallenge2K7/ResultsFastLearning]]. Hmm, I suppose I'll do some tests with the non-surfers only, but primarily because that will speed the test runs up (waiting at least 2 hours to get results is kind of tiresome). -- [[Rednaxela]]

By the way Skilgannon, I'm currently experimenting with the time-since segments as you noted. One interesting thing I found though, is that dividing by "bullet flight time" makes it perform even worse than without the time-since segments at all. Haven't been able to get much out of the time-since segments yet though either way... still experimenting with it though. -- [[Rednaxela]]

Hmm, lately the numbers I'm getting seem bothersomely similar for the most part. I wonder if the 15 or even 24 seasons is not enough to get a reasonably noise-free result. I'm going to run a much larger number of seasons on version TC09 overnight and see how that goes. I hope I won't have to start using more seasons to get useful results, because even 15 seasons takes longer than I'd really like on my not-quite-state-of-the-art Core 2 Duo 1.7GHz laptop. Unfortunately, the only other computer I could possibly use to augment the processing speed is an old AMD Athlon 2000+ and if I'm lucky an Athlon 2400+ too perhaps, which even together probably would at best double the rate I could run seasons. Of course I can't get RoboResearch to work in a distributed way anyway for some reason too. Processing power limitations are rather bothersome, they really make me wish I had access to a computer lab like Simonton had access to during one stage of his [[Simonton/DCResearch|DCResearch]].  -- [[Rednaxela]]

Another suggestion for clustering, try making some of the dimensions non-linear. The best example I can think of is the time-since segments, take a sqrt of the result before putting it into your tree, so that for short times small differences have a larger effect, but for big values of time-since they don't make as much of a difference (think of a sqrt graph, as it flattens out as the x value gets higher, so the delta-y is smaller for the same delta-x). -- [[Skilgannon]]

Actually, I already am making some of my segments non-linear kind of like that. In particular, my wall-distance and time-since segments go through the function f(x) = 1 / (1 + x) which would should a similar effect as the sqrt one except it's always bounded between 1 and 0 (note, like sqrt, only makes sense for when x is greater than or equal to 0) :) -- [[Rednaxela]]

Hmm, after re-running test 09, with 114 seasons now, it appears my earlier luck with that test was partially luck... So this means that 24 seasons is not enough, and to be honest I'm not sure that 114 seasons is really enough for a decently accurate value anymore with some of the smaller changes I've been working with. It's times like these that I wish I had either a faster computer or access to a larger number. -- [[Rednaxela]]

Huh....  one thing that's interesting, is that based on the roborumble results, even the rather crappy-against-everything Beta3 gun (TC01), seems to score better than Raiko against one specific rare subset of bots: DC-Surfers. In particular, RougeDC Beta3, is scoring at least 5 or 10 points higher against [[Lukious]], [[Hydra]], [[Horizon]], and [[Firebird]], all of which are DC-surfers, than Alpha15 did... I wonder what about my gun throws off some DC-surfers so much [http://rumble.fervir.com/rumble/RatingDetailsComparison?game=roborumble&name1=ags.rougedc.RougeDC%20Beta3&name2=ags.rougedc.RougeDC%20Alpha15 trouble] when it's so harmless to most other things... -- [[Rednaxela]]

Well, RougeDC Beta4a seems to be doing pretty good so far. Tomorrow morning I'll have the TC test corresponding to it (TC16) done, but it should be nearly exactly the same as TC11. I'm getting a little tired of trying endless tweaks, so now I'll try to add a 'secret' ingredient. If anyone is curious I might say more, but for now I'll keep it a surprise until I've run a test on it. :) -- [[Rednaxela]]

Haha! I've successfully combined a DC/GF gun and a PM gun in a way that makes a better gun! Now if only I can get the MultipleChoice feature into the PM gun! I'm curious, anyone know if anyone has put both GF and PM in the same bot (other than with VirtualGuns) before? -- [[Rednaxela]]

Nope, although I wouldn't be surprised if SandboxDT had some sort of mixture =). I've mixed DC with VCS for movement (not that it worked), but that's as far as its gone AFAIK. PEZ always wanted to, and that was one of my earlier ideas (look at the WaveSurfing/Goto page). I'm curious - are you weighting each gun based on what its individual hitrate is and how sure the gun is of being correct (number of overlapping GF ranges/height of spike for DC/VCS, match length for PM)? Because long ago, before I got distracted with perfecting my surfing, that was what I was planning to do =) Seems you beat me to it =) -- [[Skilgannon]]

Well, currently I weight by a rolling rate-like value based on "the maximum height of the profile within the GF range the enemy covered". So basically it's rather similar to a rolling hitrate, however it accounts for the fact that any intersection has at least some value, as far as getting a better MultipleChoice result is concerned. I'm not 100% satisfied with my weighting scheme though. For one, the way that I normalize the max height prevents how confident a targeting method is of itself from being taken into account, so I'm intending to fix that some time by normalizing the area of the profile instead of the maximum height (which will also make the handling more mathematically consistent with how probability curves should be dealt with). While I'm not completely happy with the weighting right now though, it does seem capable enough of even extracting targeting value from something as mundane as CircularTargeting, so it's clearly not bad either. I also believe that the way that I use perfect-precision (perfect botwidth) GF ranges is part of what makes my MultipleChoice use effective too, due to how it finds peaks to be extracted that less accurately inclusive GF range calculations may not see. By the way, I see you make a comment about match length for PM, which I find interesting. I haven't implemented it quite yet, but for my soon-to-be-multiple-choice PM gun I believe I've also come up with a way (which I think statistically sound) to calculate a probability/confidence in a PM match, which while generally higher with longer matches can occasionally be highest in a match which isn't quite longest, so I hope to use that to prioritize different possible permutations of the future in the MC-PM. -- [[Rednaxela]]

Gah! I finally get my [[MultipleChoice]] [[PatternMatching/SingleTick|SingleTick]] [[PatternMatcher]] working, only to discover that it is FAR too slow (45 minutes to do 3 seasons of [[TargetingChallenge2K7/ResultsFastLearning]])! I think I unfortunately need to either:
 - Go the route of just improving the non-MultipleChoice [[PatternMatching/SingleTick|SingleTick]] PatternMatching
 - Go the route of non-[[PatternMatching/SingleTick|SingleTick]] MultipleChoice PatternMatching
 - Or find some MASSIVE performance optimization...
 In any case... I'm rather disheartened now... :( -- [[Rednaxela]]

I was thinking it might be slow, but that is SLOW! Although, thinking of the algorithm: regular pattern matching has 1 nested loop (to find the match), followed by an inline loop (rebuild data), therefore x*x + x iterations. [[PatternMatching/SingleTick|SingleTick]] has a nested loop (find first match) followed by a loop  within a loop (find another match for each tick) within a loop (rebuild data) therefore x*x + x*x*x - it's bound to be a lot slower. Put the entire thing in a loop again (multiple choice) and it's just going to slow down even more (x*x*x + x*x, and x*x*x + x*x*x*x). Thus, I guess MultipleChoice with a regular PatternMatcher would be about as fast as a [[PatternMatching/SingleTick|SingleTick PatternMatcher]] because they have the same depth of nested loops - make sense? It's kind of like doing limits of rational functions in calculus =) -- [[Skilgannon]]

Yep... It's really slow like that, even with a limiting factor of never considering more than the 5 most likely permutations of each tick. Personally, I think [[MultipleChoice]]-[[PatternMatching/SingleTick|SingleTick]] has to most raw potential as an algorithm (i.e. with the method I was using, you could very accurately calculate the probability of a given "reality", and consider a large number of possible branchings) however it seems prohibitively time consuming. Of course, one factor contributing factor to it, was that my coding style for it was not at all designed for speed, and rather for flexibility and "correctness" to my intuitions about what is completely statistically sound. I'm sure that someone could make something functionally identical if they really tried, but is 5x faster at least (by using more raw arrays as opposed to OOP-ness, avoiding a bunch of the unnecessary object allocation and recalculation I tend to do, etc.) but even so I'm not sure it could be optimized enough to be practical. Of course.... despite that failed experiment, not all is a waste... I've learned a bit about PatternMatching, and also some of my theories about how to improve the statistical accuracy (or at least "Correctness") of MultipleChoice PatternMatching may still end up useful to me in a non-[[PatternMatching/SingleTick|SingleTick]] gun. Also, if you're wondering why I'm a little lighter spirited than when I was disheartened, some of that green in the diff column [http://rumble.fervir.com/rumble/RatingDetailsComparison?game=roborumble&name1=ags.rougedc.RougeDC%20Gamma1&name2=ags.rougedc.RougeDC%20Beta4a here] can be rather uplifting :) -- [[Rednaxela]]

Oh, just wondering, are you only aiming your gun when your gunheat is low? If you're aiming your gun the whole time it could slow you down a LOT. In DrussGT I start aiming my gun as soon as the number of ticks for my gun point at MaxEscapeAngle  >= the number of ticks until my gunheat is 0 -- [[Skilgannon]]

Already do that to an extent: I aim head-on except for 4 ticks of time given to aim which seems to be enough. -- [[Rednaxela]]

Woah there! It's not even close to done running yet, but TC26 is looking extremely promising! Very good scores against [[WaveSerpent]] and [[Shadow]] for one! It would place in [[TargetingChallenge2K7/ResultsFastLearning]] just a hair below [[Dookious]] and [[Phoenix]]! I've sure got one strong gun! -- [[Rednaxela]]

Wow! That's one strong anti-surfer gun you have there! And not at all shabby against the random movers, either. -- [[Skilgannon]]

Thanks! Indeed, and hitting surfers better than [[Master D]] is not a small feat I think! Now I just need to get that random mover score increased some, at least back to TC20 levels. It's frustrating how I still haven't been able to beat Raiko's random mover score yet. -- [[Rednaxela]]

Oh! Just to check, did you disable [[Raiko]]'s data saving? That would influence the results a lot! -- [[Skilgannon]]

Yeah, it's the same version of [[Raiko]]'s gun as is required for [[MovementChallenge2K7]], which does have the data saving disabled. -- [[Rednaxela]]

Heh, Gamma2 is performing worse than I had hoped... In particular, my AntiSurferTargeting additions actually decreased score against [[Dookious]], [[DrussGT]], [[Chalk]] and some others I was hoping for an increase against, not to mention it seemed to have notably more trouble with a few bots that use StopAndGo at first and later switch to RandomMovement for some reason. Overall it scores about the same as Gamma1, but with a very different profile of problematic and unproblematic bots... -- [[Rednaxela]]

Well, I've decided that due to in the inadequacies of [[TargetingChallenge2K7]], I'm going to do my further testing in two sections. I will use [[TargetingChallengeRM]] for my testing against random movement as it seems fairly good, and for surfing I will use a custom challenge consisting of: The surfers from [[TargetingChallenge2K7]], 3 surfers that my anti-surfer gun hurt results against ([[Dookious]], [[Chalk]], and [[Komarious]]), and 3 surfers that anti-surfer gun helped results against ([[GresSuffurd]], [[DarkHallow]], and [[stelokim|MatchupWS]]). All the added bots modified not to fire of course, like the TC2K7 reference bots. I feel that this should give me notably more helpful challenge stats... (though it will be more time consuming to run) -- [[Rednaxela]]

Huh... this is bothersome how giving a better PM gun degraded overall performance. I'm suspecting that this is because now the new PM gun is getting higher weighting than is best for the overall health of the gun. Running tests now with the PM gun along and the DC gun alone, and it's looking like the DC gun alone is stronger overall in the RandomMover challenge than the combined gun now, however against certain bots, is measurably weaker than the PM gun alone (and the combined gun is usually somewhere inbetween against those ones). I think this means that the biggest thing I need to work on right now, is improving my CrowdTargeting weighting and profile mixing scheme... -- [[Rednaxela]]

Well, after testing TC32 (DC gun only), it appears that it's strength is somewhere between TC31 and TC29, which to me indicates that either my CrowdTargeting weighting is indeed the problem, or that my new matcher is unexpectedly weaker than the old matcher. I suspect the former more, but I'm running [[TargetingChallengeRM]] tests with the PM guns only to see how they each compare. -- [[Rednaxela]]

So... PM05 is indeed overall far stronger against most random movers than PM01, though it's weaker against a couple (Perhaps weaker against a couple because of the change from matching on acceleration to matching on velocity?). The places I make the notable losses though on TC31 are against the "hard" category bots, which PM05 performs far better against than PM01, therefore I guess I can conclude that the CrowdTargeting weighting algorithm is what needs some work... gah... -- [[Rednaxela]]

Alright... seems like the new multiplicative CrowdTargeting scheme in TC33 brings performance up to TC29 levels, however I'm still hoping for better, because after all, the PM is much stronger now. I think my merging of the profiles from each gun is better now, but the dynamic weighting could still use a little work -- [[Rednaxela]]

Well... I'm having a lot of trouble evaluating changes... When I test something in the random mover challenge, even at 50 seasons, things that are virtually no different and only affect the first 20 bullets I ever fire and should at that improve results then, seem to erratically show as half-point performance degradations sometimes!I have no clue what the heck is going on anymore really and I really wonder if I'd be better off not spending time with these tests and instead just do more frequent rumble releases. Also for example, when I first added PatternMatching it a very slight increase against surfers and random movers,  yet in the Rumble I gained 14 points overall. To make matters worse, when I switched to a multiplicative scheme in the CrowdTargeting weighting, it seemed to show a measurable increase in the challenge score against random movers, for some bothersome reason it killed results against surfers a bit. While I was successful in making an anti-surfer mode and integrating it, any rumble points I gained against surfers was canceled out by losses against other things (though it did help the PL rank). Also, it's seeming like I've hit somewhat of a BrickWall as far as the gun. Adding a PatternMatcher that's confirmed to be considerably stronger didn't help gun performance at all despite how adding the first simple PatternMatcher gained 14 rumble points. All in all, I'm quite frustrated with my lack of being able to improve the gun past RougeDC Gamma1 in rumble points or RougeDC Gamma2 in PL ranking. Making matters worse, is preliminary tests with RoussGT and DrugeDC seem to indicate that even after all this hard work, my gun is STILL my weak spot compared to my surfing which was only developed over a far far smaller number of revisions. They say WaveSuffering is bad? Bah! It ain't so bad! At least not compared to these gun woes! -- [[Rednaxela]]

I personally like movement more than gun, so for gun, rather than going the perfectly-tuned-rumble-gun ([[Raiko]], [[Ascendant]]) I did the brute force method: Just throw as many attributes as you can at them, you'll catch them on one of them :-D. Which is why DrussGT currently has 10 attributes for the gun =). If you're going for rumble points, distance is a very important attribute. Lots of bots don't have movement as good as the ones in the challenges, and a distance attribute can help a lot. Time-since-direction-change or time-since-deceleration helps against bots that have a simple oscillation, acceleration is obviously important, as is lateral velocity. But maybe your problem is getting the recordings into a decent gun angle? Do you smooth the angles? ie, if you have about 10 shots all right next to each other, but not quite overlapping, and 2 shots on the other side that do overlap, which do you shoot for? Heavy smoothing would make you shoot for the 10. In DrussGT I do smoothing until I have about 7000 scans, and I'm pulling a cluster size of 80, after which I follow a method similar to DCBot, but with a constant botwidth tolerance. The smoothing method seems better at hitting random movers with limited information, but the 'overlap' method seems a little better once a lot of info has been gathered, and against surfers. -- [[Skilgannon]]

Well, I currently use a time-since-deceleration segment, and indeed that seems to help, plus the PM helps destroy most oscillators even more throughly too. I tried adding distance a couple times, but at least in the challenges, I got absolutely no gain from it and in fact some loss of score. As far as smoothing and such, the method I use, is the "overlap" one, however instead of going by their current botwidth, I instead overlap the whole perfect-precision GF range that would have hit them, from the wave where the original record is from. I think this causes fewer "not-quite-overlapping" cases probably. It seems to work fairly well though I suppose I might try other things. By the way, you should see my bot's debugging graphics some time, which include very pretty graphs of the "movement profile" it estimates for the enemy at the current moment in time, I find it fun to watch anyways. What frustrates me the most though, is that I'm 90% certain that my CrowdTargeting weighting scheme has room for improvement, yet I can't seem to find where that room to improve it is, particularly considering how adding a much better PM didn't do any good (in fact it now seems to give the PM too much weight when the DC is significantly better, because the PM's guesses aren't so bad anymore against non-simple movers). In any case, that about the smoothing is interesting and I might give switching away from the overlap method a try. -- [[Rednaxela]]

I like your idea of weighting non-maximized segments by f(x) = 1/(x + 1), but that might not have enough variation to let your DC gun get strong enough differences on it. How about using something like Math.sqrt(Math.min(timeSinceDecel/BFT/1.5,1)) ?

You are weighting the guns by their virtual bullet hitrate, right? How about making the weighting more sensitive, something like adding the two hitrates together, and then giving them back, but the difference more exaggerated? And how are you taking the weightings into account when finding an angle? If you're multiplying the bins (I personally don't like that, because if your good gun has a nice angle, but the bad gun doesn't see it it won't shoot there), you need to take the (1/weighting)th root to get it to weight them properly, or add a constant value to every bin of the weaker gun/ subtract from the stronger gun to make the weightings still appear when you multiply. But you probably already got that =) -- [[Skilgannon]]

Hmm, I might try that nonlinear function some time. And no, I'm not quite weighting by virtual bullet hitrate, as I consider that to be too slow at learning. Instead, I weight by "maximum movement profile height within the GF range that /would/ have actually hit". It seems to give similar ratings of the strength of the gun against the movement but is capable of producing useful data quicker and adapting quicker. Well, I'm not plain multiplying the 'bins' (note, I don't use bins at all, I use a continuous overlap spectrum of sorts), I'm using the weighting and multiplying like this: for each profile I pass it through the function f(x,w) = x*w + (1 - w), where x is the height and w is the weight, and only after that multiply the resultants. This means that if a gun is given a weighting of 10%, then it's profile after the weighting function ranges from 90% to 100%, and thus that weak gun can't influence where a stronger gun aims very much. In a similar way, if my PM gun has near-100% accuracy on PatternBot, then the result after the multiplication is that it will completely avoid shooting anywhere that's outside of the range the PM predicts would hit (with my precise botwidth, this occasionally means I hit PatternBot at funny places that don't visually look like they hit but my bot knows they do, which can be fun =P). I think this scheme is just about perfect for making strong/weak guns interact nicely provided the weights are right, and is in essence a form of what you said with "add a constant value to every bin on the weaker gun". The problem, I believe, is in my generation of the "w" values, and I'm not quite sure straight virtual bullet hitrate would be any better either. -- [[Rednaxela]]

Are you only doing your 'maximum movement profile height' on waves that have bullets? How about making the weightings more extreme? IMO if you have a gun that is only weighted 10% of the other gun you shouldn't listen to it at all. It's just getting lucky. I see you're weighting relative to a random targeter now... good idea. So the weight of the random targeter is subtracted from all gun's weights, right? Oh yeah, I just noticed RoussGT has a few funny results, TheHulk and [[Toorkild]]. I'm pretty sure they weren't me. -- [[Skilgannon]]

Well, I tried subtracting the theoretical weights that a random targeter would get on average. In theory this could allow really nice effects, such as if a gun somehow becomes consistently WORSE (as unlikely as that is, haha) than the baseline of the random targeted, it would then actively avoid aiming where that gun wants to fire. It didn't seem to quite work though, because the weights were then too small and too erratic. Against a good surfer like Shadow the weights would be bouncing about near-zero and on occasion negative, meaning that my guns were apparently not much better than random targeting against Shadow after it had learned my guns (though the PM seemed to hold up a little better than the DC). I might try it again though some time, but I think I'll need to 1) Roll the weights slower and 2) making them a bit larger. About RoussGT, I think it's falling victim to the bug I mentioned on [[RougeDC|RougeDC's page]] where it could in rare cases start throwing exceptions till the end of the match. I think I'll re-release both RougeDC Gamma4 and RoussGT to fix that. Good luck on your chem exam! -- [[Rednaxela]]

What about using the precise maximum escape angle and the botwidth to calculate the predicted score of random targeting? And rolling your stats very deep would be very important for this I think, perhaps rolling them slower as the battle progesses? -- [[Skilgannon]]

For the predicted score of random targeting to calculate incrementing/decrementing the weights, I take the average height of the predictor's profile within the range GF -1.0 to GF 1.0, which is basically like saying "What if this profile had the same area but was flat?" which I think is a sound way of doing it. One note, is that I don't use precise maximum escape angles anywhere in my bot, all of my guessfactors are of the "simple" variety where it's just based on theoretical maximum/minimum angle for a given bullet speed, not accounting for current velocity or anything like that. If I did, it would make sense for the "random targeting" to use the same measure, but in any case it should be consistant I think. As far as rolling, I already have a setup where it uses a non-rolling average, until amount the new data impacts the average is in equilibrium with how much the new data would affect the rolling average. I think this is a sound way of having the average work, though I just need to set a higher depth I think. -- [[Rednaxela]]

Woah! The upcoming TC38, resurrects my anti-surfer gun, uses the new weighting scheme (allowing negative weightings), switches back to the old non-multiplicative crowd-targeting, and keeps the new MultipleChoice PatternMatcher. It's too early to say much yet as only 4 seasons have run so far, but it's score on the surfer componant of [[TargetingChallenge2K7/ResultsFastLearning]] is slightly over 84 points, when the record in the challenge page is just under 81 points with most top bots being more like 79. It's possible I might just have created the most potent anti-surfer gun ever! -- [[Rednaxela]]
 '''Update:''' Well I feel really dumb now... I forgot to disable energy management and that's why it was doing so well... doh... -- [[Rednaxela]]

* Doh, sorry to hear about that man. If it's any consolation, I've been "dumb" too. =) -- [[Voidious]]

Well, after a few days break from my multiple week long robocode-marathon, I think I'll get back to the grindstone a bit. Lately my gun experiments have in trying to get the CrowdTargeting to work just right. The most successful form in practice so far was how it was in RougeDC Gamma2, however that version has a problem that it doesn't seem like it deals with weightings in a truly optimal way at all. I've been trying more "theory based" configurations, including things like setting a baseline performance of RandomTargeting and using semi-multiplicative profile merging using the weightings as "confidence" values for that. For some reason though, all of my more "theory based" forms seem to be giving worse results though which is awfully frustrating. I'm now suspecting that the flaws in the Gamma2-style crowd system, enhanced the results just by coincidence. -- [[Rednaxela]]

How about working on your DC gun by itself? If I can get better scores with my DC gun than you can, it means yours needs improvement. Once that's up to scratch, *then* try stuff like mixing it with PatternMatching. I still think you need some sort of 'smoothing' on your stats, due to the uncertain nature of the enemy's movement. And as for the CrowdTargeting, how about doing several different searches in the DC tree, weighting different attributes (or make different trees)? This would have a similar effect to dynamically weighting your attributes for effectiveness. (Or you could go the route of hundreds of them, like DrussGT does for its movement ;-) ) -- [[[Skilgannon]]

Perhaps I should tune the DC gun more by itself indeed, at least for a little. As far as 'smoothing', lately I am thinking of possibly using a gaussian curve with the width dependent on the precise bot-width at the entry, however the difficulty is that finding the maximum point is not as easy when working with curves as discrete increases/decreases and not working with bins either. Either I'd need to get fancy with calculus, or do sightly CPU-intensive and less accurate checking of the value at small intervals. As far as doing multiple different attribute weightings of DC tree lookups, I've been planning to do that actually, however I want to perfect my CrowdTargeting weighting/merging scheme with the PatternMatcher and AntiSurfer first so I know I have a solid foundation for dynamically weighting the different segment combinations (including negative weightings when valid). -- [[Rednaxela]]

Well then... it looks like tick waves do give a significant boost against the random movers -- [[Rednaxela]]

Yep, I wasn't aware that you weren't using tickwaves, or I would have suggested that earlier. The only bots they don't help against in this challenge are [[Cigaret]] and FloodMini (I see you scores against them dropped slightly), but nobody else reacts on bullet fire (and tickwaves speed up your learning about 15x). It might be useful to increase your cluster size as well, now that you have much more data to work with. Seeing as you're tuning a seperate gun fsNonor surfer-killing, I'm guessing it would be best to leave the tick waves in... -- [[Skilgannon]]

Yep, and I am thinking of leaving them in for sure. I'm also thinking that when I get around to layering multiple DC searches in CrowdTargeting, that I may make 3 groups of DC configurations for these categories of movements:
 - Non-adaptive non-bullet-reactive (Use tickwaves, very slow rolling)
 - Non-adaptive bullet-reactive (Don't use tickwaves, very slow rolling)
 - Adaptive bullet-reactive (Don't use tickwaves, very fast rolling)
 And of course, I doubt "Adaptive non-bullet-reactive" would do much good, except maybe against surfer flatteners that use tickwaves, but I don't think there's even exist any bots that surf tickwaves anyway. -- [[Rednaxela]]

Summary:
Consciousness check: 4 + 1 =
This change is a minor edit. Send email notification that RougeDC/TargetingLab has been changed.
(Visit Preferences to set your user name.)

View other revisions
Robo Home | RougeDC | Changes | Preferences | AllPages