Talk:LunarTwins

From old wiki

Sorry, I actually ran the tourney last night (Thursday is the "normal" day), but didn't get time to upload the results before leaving the house this morning. I look forward to seeing your new team in action next week! -- Voidious

No worries, I know it's too late for this week. I'm looking forward to seeing it next week too! Actually, I find watching LunarTwins about as fun as Wolverine's finish, though that just might be me being weird. :) -- Rednaxela

Hmm, I'm sorry to say that I'm running into some JVM problems with LunarTwins. I'm still running the TwinDuel with an old Robocode (1.1.3) because I need to update the code some for the new versions. I am ready and willing to update it if/when someone has a team that works in the current version but not in 1.1.3, so that's not really the issue, but just background. This is the error I get in 1.1.3 and 1.4.9:

LunarLeader [0.1] (1): Exception: java.security.AccessControlException: Preventing LunarLeader [0.1] (1) from access: (java.io.FilePermission /Users/pcupka/robocode_1.4.9/robots/.robotcache/ags.lunartwins.LunarTwins_0.1.jar_/robocode/RobotStatus.class read): You may only read files in your own root package directory. 
java.security.AccessControlException: Preventing LunarLeader [0.1] (1) from access: (java.io.FilePermission /Users/pcupka/robocode_1.4.9/robots/.robotcache/ags.lunartwins.LunarTwins_0.1.jar_/robocode/RobotStatus.class read): You may only read files in your own root package directory. 
    at robocode.security.RobocodeSecurityManager.checkPermission(Unknown Source)
    at java.lang.SecurityManager.checkRead(SecurityManager.java:871)
    at java.io.File.length(File.java:813)
    at robocode.security.RobocodeClassLoader.loadRobotClass(Unknown Source)
    at robocode.security.RobocodeClassLoader.loadClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
    at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:374)
    at ags.lunartwins.util.EnemyRobot.onScannedRobotEvent(EnemyRobot.java:31)
    at ags.lunartwins.LunarLeader.onScannedRobot(LunarLeader.java:27)
    at robocode.peer.robot.EventManager.onScannedRobot(Unknown Source)
    at robocode.peer.robot.EventManager.processEvents(Unknown Source)
    at robocode.peer.RobotPeer.tick(Unknown Source)
    at robocode.AdvancedRobot.execute(Unknown Source)
    at ags.lunartwins.LunarBase.run(LunarBase.java:54)
    at robocode.peer.RobotPeer.run(Unknown Source)
    at java.lang.Thread.run(Thread.java:613)

In 1.5.4, I get this:

LunarLeader [0.1] (1): Throwable: java.lang.NoSuchMethodError: java.lang.Math.copySign(DD)D
java.lang.NoSuchMethodError: java.lang.Math.copySign(DD)D
    at ags.lunartwins.LunarLeader.doRadar(LunarLeader.java:93)
    at ags.lunartwins.LunarBase.run(LunarBase.java:52)
    at robocode.peer.RobotPeer.run(Unknown Source)
    at java.lang.Thread.run(Thread.java:613)

I'm running Apple's Java 5 JVM on Mac OS X 10.5.2. Are you using Java 6? What version of Java and OS are you using? And are you using built in Robocode classes in your bot (in regards to the 1.1.3 / 1.4.9 error)? Glad I decided to test it out right away, as that gives us almost a full week to iron out any issues...

-- Voidious

I'm using Java 6, however I am compiling with the Java 5 compatible target. Using Sun JDK 1.6.0.04 on Linux more specifically. I do reference the robocode.peer.RobotPeer.WIDTH/HEIGHT constant for bot size, of course hard coding that shouldn't be an issue because it's not like that changes. I also reference the DefaultBattleField class (Which is basically just a shell that stores height/width) in order to store my own representation of the battlefield size. As for the error in 1.5.4, it appears that java.lang.Math.copySign() isn't part of Java 5 (and the Java 5 target doesn't check if the APIs used exist in the old versions). I'll try and remove those Robocode internal references and the copySign() reference. Hopefully this won't hurt the codesize too much as this bot is pretty bloated as far as codesize per function -- Rednaxela

Cool - I'm glad to hear at least the errors all make sense to you. =) I'll gladly help you shrink some CodeSize if you need it. I'm not the master (that'd be Simonton or David Alves), but I've got some experience with it and I'm sure I could find some bytes. -- Voidious

By the way, java.awt.geom.Point and java.awt.geom.Point2D.Double are good replacements for how you're using DefaultBattleField, I think. A lot of us use Point2D.Double like that all over the place. -- Voidious

Okay, I removed those references to Robocode internal classes, and replaced java.lang.Math.copySign(). Except for fixing copySign() the CodeSize actually decreased slightly. Also made on minor tweak that looks like it helps a little. It's re-released under the same filaname/url, so you can download and try again Voidious. I just replaced DefaultBattleField with a simple blank class with public ints of height and width, and that only takes 5 CodeSize, Point2D.Double might work better though (Actually, I already have an AbsolutePoint and RelativePoint class derived from Point2D which handles all the nice trig as well as making it easy to keep track of which variables are relative points and what ones are absolute points). Some help shrinking CodeSize might be nice some time, though at the moment shouldn't be necessary, besides if my CodeSize was shrinked I might have room for features to let it threaten your LuminariousDuo ;) -- Rednaxela

Oh, one thing I forgot to mention, it still wouldn't work in RoboCode versions below 1.5.x, because it relies on the onStatus() callback which was introduced then. I'll see if I can get rid of reliance on that without hurting CodeSize too much. In the meantime, feel free to watch it on 1.5.4 -- Rednaxela

Yep, it's working on 1.5.4 for me and failing on pre-1.5, like you said. I should just get my automation code updated to work with 1.5.4, as I don't think it's right to force people to code to 1.1.3 compatibility to support my own laziness. :) I'll look into that this weekend / week and I'll make a post once I've got that done. Good luck next week! -- Voidious

Woo! What do you think of it's behavior? ;) Anyways, I just re-released again, after very quickly making it not reliant on onStatus(), and this actually decreased CodeSize a little too so I think I'll keep it this way even if it's a little less safe anyways. You can test on lower version again if you want, I think it will work. Anyways, thanks! Good luck too, hopefully LuminariousDuo won't get knocked out before facing LunarTwins in the bracket style tourney :) -- Rednaxela

Hmm, at least according to some new test battles.... it's seeming that making LunarRover use CircularTargeting too, and re-adding one small feature I commented out and forgot that I commented (checking if goal points for movement are within the battlefield), brings it's test battles with LuminariousDuo to a point where either could easily win a given match. I might just making a 0.2 release before 0.1 even gets a chance to see the TwinDuel battlefield... Hopefully I'm not too threatening Voidious :) -- Rednaxela

Just a heads up, I did encounter this error once in Robocode 1.1.3, but I'm not sure if it's specific to that or just happens very rarely, so you might want to just check it out:

ags.lunartwins.LunarLeader [0.1]: Exception: java.lang.NullPointerException
java.lang.NullPointerException
    at ags.lunartwins.util.RelativePoint.fromPP(RelativePoint.java:80)
    at ags.lunartwins.LunarBase.run(LunarBase.java:37)
    at robocode.peer.RobotPeer.run(Unknown Source)
    at java.lang.Thread.run(Thread.java:613)

As for the strategy, I like it a lot. =) Having more focus on strategy than advanced movement and targeting is something I've always wanted to see in the TwinDuel. In fact, my first attempt at a team was a RamBot teamed with Komarious - the hope was that the RamBot would enable them to kill one enemy bot quickly, leaving the other bot to battle with my champion MiniBot duelist. =) It didn't work out that well, but David Alves later tweaked my KomariousTeam into a strong contender (and even reigning champ for a short while). Speaking of which, I notice that KomariousTeam seems to beat LunarTwins pretty consistently.

Just to be sure, you do remember that it's survival that counts in the TwinDuel, right? I just happened to notice that LunarTwins has the higher score even more often than higher survival, and I hope you didn't misinterpret that. Not that it doesn't do well there... It crushes MarioBros and Shiz, and it has close matches with GeminiTeam and NightAndDay. I'm definitely impressed! I confess I didn't expect a team with a Droid to do so well. This should really shake things up!

-- Voidious

Hmm... odd error, however I can see how that would occur if LunarTwins is skipping turns... When coding LunarTwins I wasn't really thinking of efficiency, and I was calling the very slow getGoal() (which is what does the bulk of the work) multiple times per turn, and same with getTarget() which does the CircularTargeting. Anyways, I just made a fix for this, so it will only call each once, and will also make this error impossible even if it is skipping turns. I should release that fix along with other improvements in 0.2 soon. According to a benchmark I just did though, I don't see how it would be slow enough to be skipping even with that inefficiency, but anyways that fix I made should fix the error even if it still skips.

Hmm, KomariousTeam beats LunarTwins? Hmm, just testing that now on my system seems to show that fight as very very even. Well 1.1.3 did have a lower cpu constant, and in LunarTwins I have some very inefficient code in places (recalculating things too much) the fix for the above error should drastically reduce CPU use of LunarTwins and should thus improve performance if it's turns were indeed taking too long. Also, after enabling the little improvements I mentioned above that I haven't released yet, it seems to beat KomariousTeam fairly consistently (and crush MarioBros by a bigger margin than before). I guess we'll see if you'll see that improvement on your system too once I release 0.2 (which I hope to improve against LuminariousDuo's wiggling before releasing, but that might happen today even) :)

Yes, I do know it's survival that counts, and that LunarTwins tends to dominate in score more often. It's not like I mind having a good score too of course, and yes I do look at the survival counts not score. Anyways, I hope this will shake things up indeed :)

-- Rednaxela

I believe I was running 1.5.4 for the KomariousTeam battles, but you've probably tested more exhaustively than I have. I ran 3-4 battles and they all seemed to be solid wins for KomariousTeam, but they may be closer in general. Looking forward to seeing 0.2 in the TwinDuel next week! -- Voidious

Well either way, KomariousTeam seems to be my biggest ProblemBot besides LuminariousDuo I suppose :) What's encouraging is I am seeing some intermittent narrow wins against LuminariousDuo now, and just have to work to improve that a little. Thanks, I'm looking forward to it too! :) -- Rednaxela

Oh, one thing I just found, is that I was using a 800x600 field instead of 800x800, and that using 800x800 does cause a rather large decrease in my performance. That may explain differences we were seeing. -- Rednaxela

Okay, well the performance decrease on an 800x800 field is disappointing, but makes sense as that makes it harder to pin an opponant against a wall this way. Anyways, I've now released 0.2, which according to my tests may be a match for KomariousTeam and LuminariousDuo even in the 800x800 field... :) -- Rednaxela

Another thing to consider is that many teams probably assume an 800x800 field (pretty sure KomariousTeam does), so it may have more been that their performance decreased on the 800x600. -- Voidious

True true. Of course, the LunarTwins 0.2 seems to do better than the last revision even on the 800x800 field :) I presume your earlier testing was on the proper 800x800? One thing I'm finding interesting, is that in my testing of 0.2 on an 800x800 field, it seems to win about 50% of the time against KomariousTeam except it seems to get a head start in the early game before they've learned where LunarTwins tends to move/fire. This head start seems to be about 5 to 15 rounds worth (and I would guess is spread through the first 20 or 30 rounds). Against LuminariousDuo it seems to win more often than not, but it seems very close and doesn't seem to have the same kind of head start that it has against KomariousTeam. -- Rednaxela

Well, I just dropped between 100 and 200 CodeSize by getting rid of some old performance optimizations in RelativePoint in favor of simplicity, and that felt nice. :) Also, I just implemented smarter selection of the initial target by making it target the leader first (though if at a later time it sees both at once it will go for the closest one), and compared modes of first-seen-first, leader-first, and non-leader-first in actual battle against a few different teams. Interestingly, it made absolutely no difference (or even very slightly better with first-seen-first) against bots that I already crushed. Against bots LunarTwins had a closer match with before, it seems that going for the leader first gave a rather notable improvement in how often it won. I guess I'm keeping this feature. Hmm... I think I'm feeling confident enough in it for a 1.0 release now, and I'll leave it to rest until the TwinDuel is next run. After all I need to be able to concentrate on things besides Robocode :) -- Rednaxela

Well, currently LunarTwins used a fixed bulletpower of 3, which seemed to work decently. I promise I won't make any more released until after TwinDuel is run this week, but I decided to experiment with bulletpower a bit. Power level 1 was horrible and could virtually never win, it just didn't do enough damage, and I didn't expect better from it anyways. Power level 2 seemed to work decently, however it was worse than 3 still. I then tried 2.5, and that was a notable improvement over either 2 or 3, so clearly there's some sweet spot between 2 and 3 that's somewhere near 2.5. So, if I'm going to optimize bulletpower a bit I might as well go all the way and and make it depend on distance to the opponant, after all I do have some free codesize and at sufficently close range there's no reason not to use pwer level 3. Anyways, I guess that's going on my "What's next" list up there. -- Rednaxela

Wow, graphing statistics is too fun. Today I ran some more comprehensive (150 trials of 75 rounds each, for each configuration) tests of LunarTwins verses LuminariousDuo at 3 bulletpower and 2.5 bulletpower, and made a pretty graph of the results. It seems to show that as I thought 2.5 bulletpower was an overall improvement though it seems to reduce how consistent the score is slightly.

http://homepages.ucalgary.ca/~agschult/LunarTest.png

The blue line is with 3.0 bulletpower and the red line is with 2.5 bulletpower. Running those 150 trials took over an hour for each configuration. Anyways, now I'll need to figure out a method to use for figuring out the optimal firepower for different distances. I'm suspecting that to do that, it may actually be most sensible to use VirtualBullets at various bulletpower levels in the robot, instead of gathering the statistics externally from the robot. I have some nice ideas to plot those statistics, but I'm not sure I'll get the motivation to code the gathering of these statistics in the robot, considering it doesn't use VirtualBullets/Waves anyways due to codesize.

-- Rednaxela

Here's another pretty image!

http://homepages.ucalgary.ca/~agschult/LunarTest2.png

The green was my first attempt at adjusting bulletpower based on distance, which used either 3.0, 2.5 or 2.0 depending on distance, which was certainly an improvement from 2.5 bulletpower. Then I tweaked the distances at which it changed bulletpower, and got some further improvement, as shown in the orange curve. Of course, the orange didn't improve my worst battles compared to the green, but it did increase the average margin that I won by without a negative effect on anything else. I'm liking this method of statistical measuring of tweaks. I made these plots using a combination of the raw data from Rednaxela/SurvivalTest.sh as well as using GNU R , and if anyone is interested I can post more details about the workflow/configuration I'm using for this. Anyways it seems that since 1.0 release I've managed to improve my rate against LuminariousDuo from averaging at 58% to about 66%, while eliminating the bad losses and slightly increasing more overwhelming wins. I'm thinking I'll generate statistics on these configurations against other bots like MarioBros or GeminiTeam before doing more tweaking. Anyways, these graphs are a pain to produce as at least on my machine it each line needs about 100 trials of 75 rounds to give stable enough graphs. -- Rednaxela

Wow, very nice testing methods and pretty graphics - way to be! Except the part where you demolish my team. =) Might be the inspiration I need to make some updates. I've tweaked bullet power quite a bit in Dookious, but not so much in LuminariousDuo. This week might be my last chance to make an update, as next week Smash Bros comes out, and you will never seeme again. =) (Just kidding ... sorta.) -- Voidious

Sorry about demolishing your team there. :) If it makes you feel any better, it still gets demolished by a smaller margin than other teams I've tested against. Actually from what I've observed, your team's wall avoidance and distancing seems of rather good quality particularly considering the CodeSize limit, it makes it awfully hard to trap. In some ways I would say that LunarTwins is kind of a benchmark of how good a team's wall avoidance and distancing is at avoiding getting trapped. Anyways, I do hope that this upcoming shake up in TwinDuel will inspire some people to update their teams... of course the timing of Smash Bros could indeed be a problem.... :) -- Rednaxela

Well, I think I'm done with spewing pretty graphs for a while after this one:

http://homepages.ucalgary.ca/~agschult/LunarTest3.png

Here's a nice graph showing that the same bulletpower tweaks also improved results against InevitableTeam by a notable amount. The shape of the curve wasn't affected in the same way but it was also an overall improvement. Anyways, next I'll be be looking at adjusting the bulletpower by a smooth formula instead of in steps like this.-- Rednaxela

Well, I didn't have any luck getting better results by adjusting bulletpower via a smooth formula rather than steps, however I was able to get a big leap against various teams by, instead of moving relative to their current possition, moving relative to their predicted position a mere 1 tick in the future. I won't show the graph for that one though, as I don't want to cause Voidious and others to dispair too much. :) One other thought, is I think I may be able to improve this a little more even, by telling the droid to move relative to the enemy's location 2 ticks ahead instead of 1 tick ahead, due to how the droid's information on the enemy is always 1 tick older than the leader's information. -- Rednaxela

All this exciting development is making me want to make a TwinDuel bot :P I'm going to start abstracting later today, after I work on Claude some more. So have fun at the top this week Rednaxela, because I'm coming for you -- Baal

Best of luck Baal! I'm certainly hoping this may spark more activity in the TwinDuel arena. Just remember I'm not going to make LunarTwins an easy one to take down though ;) -- Rednaxela GruwelTwins Hmm, results were slightly improved a little more after making it more stubborn about killing the leader first. I think I'll probably make a 1.1 release as soon as this week's TwinDuel results are posted. -- Rednaxela

Nice team, real sticky bulleys. They crush GrauwuarG and it seemes I can't do anything about it. You may have another problemteam though: GruwelTwins slaughters your 1.0 version with 60-15. Looking forward to the next TwinDuel! -- GrubbmGait

It seems the trick to beating LunarTwins may be fighting up close...counter-intuitive as that may seem. =) -- Skilgannon

Hmm, I haven't tested against GruwelTwins. I think I'll have to do that some time to improve it's weak spots. Yes Skilgannon, that is one of the tricks against it. So long as LunarTwins is in close range to one enemy, while the other enemy hangs back a long distance, LunarTwins will have a rather significant energy advantage (unless the far away enemy somehow gets a 100% hit rate). If the robot that isn't being ganged up upon gets close enough to have a high enough hit rate, the LunarTwins loses the advantage. I'm thinking implementing an idea based on BombSheltering may help LunarTwins a bit though. Anyways, thanks for the compliment GrubbmGait! -- Rednaxela

Cool to see GruwelTwins laying some smack down where nobody else can! That team won the first TwinDuel (by quite a margin) and hasn't been updated since. -- Voidious

GruwelTwins does not run away, which is deadly against CircularTargeting. It just says "come to daddy" and blows you away when you're closing in. Not the best strategy against advanced targeting and/or movement, but very effective in the early stages of melee (read close combat). -- GrubbmGait

By the way, just tested now, and as of the updates I've made so far for 1.1, GruwelTwins is somewhat less of a big problem, however it can still beat me 50-25, though on the other hand I can beat it 50-25 too in another trial. This is looking interesting, I think I might make a graph like the one above, for my performance against GruwelTwins... It will probably show a very broad range... -- Rednaxela

Update: Well this is rather odd... I'm having a lot of difficulty reproducing that 50/25 loss to GruwelTwins. Maybe I just didn't see right when I looked the first time, however running a large number of matches for the graph, is so far indicating that it's harder to beat than LuminariousDuo but I still beat it very often. I guess the changes I've made so far for 1.1 have had a massive impact on its GruwelTwin performance though I'm not sure how. This kind of tempts me to release 1.1 for this week's TwinDuel.... -- Rednaxela

Well... I give in... I'll make the 1.1 release, because I don't want to stuff too many changes into one release, and want to have a code backup before I got into a CodeSize reducing spree and start exploring some more disruptive enhancements.... hopefully I can find enough places to reduce CodeSize -- Rednaxela

Well I'm glad I just released at that point... becuase in trying to rewrite the scanning code for smaller CodeSize, I seem to keep introducing bugs I can't track down... Not that it managed to get rid of much CodeSize anyways... -- Rednaxela

Well, for a fun test I set up a ShadowTeam with 2 Shadows instead of 5, and tested it against LunarTwins 1.1, the results were LunarTwins winning 39-36, 40-35, and 49-26, then LunarTwins losing 37-38. In other words, it seems ShadowTeam is a closer match for LunarTwins than anything in TwinDuel but even with it's massive megabot intelligence and learning it cannot reliably beat the tactics of LunarTwins. This makes me feel a little warm inside :-) -- Rednaxela

Cool! Did LunarTwins also win on points? I never optimised ShadowTeam for survival, it's just 2 Shadows with a slightly modified melee strategy and scan sharing. Maybe I can use your team for 2vs2 optimisations, did you use one of Shadow's latest versions? -- ABC

Yep, it won on points too. It gets about equal points in "Bullet Dmg" but has around double the "Survival" column points (which, should be noted is per-bot unlike survival as TwinDuel defines it) and nearly double in the "Bullet Bonus" column. I used the same ShadowTeam 3.66t that's currently entered in the team Roborumble. -- Rednaxela

Well, there's a bothersome amount of bug-finding as I've made codesize changes, but currently I've managed to cut the codesize from the 1.1 level by nearly 200 while maintaining identical functionality... I'm hoping to get another 100 or 200 cut off before I go back to features though not sure how realistic that will be... -- Rednaxela

Now I got it cut to 1691 CodeSize with still identical functionality to 1.1... the code however is looking slightly messier than I'd like it in places. I'm not sure if I want to try to cut more CodeSize off or if it's time to go back to feature development. Either way, I'm calling it a night now :)
Update: Well, spoke too soon, I got distraceted and reduced it to 1634 by hardcoding the field size as a static final variable. Anyways, now sleep :)
-- Rednaxela

Hmm... while 1.2 gave some improvements, I of course don't feel safe yet. As an experiment I tried switching form the CircularTargeting to PatternMatching. The results aren't good though, perhaps my PatternMatcher just plain sucks, but it was under-shooting far more often causing the twins to hit eachother a lot... I wonder if I can manage to make something work better for LunarTwins than the CircularTargeting (w/ RollingAverage AngularVelocity) that I was using. -- Rednaxela

Well, in current absence of TwinDuel running, I decided to do that fun little test against a twin-version of ShadowTeam (3.66t as is in team RoboRumble) again, now against LunarTwins 1.2. The result? Well LunarTwins won 51-24, 53-22, 53-22, 53-22, and 56-19. So, in other words, it seems that LunarTwins 1.2 is really kicking some ass out there :) | Rank | Robot Name | Total Score | Survival | Surv Bonus | Bullet Dmg | Bullet Bonus | Ram Dmg * 2 | Ram Bonus | 1sts | 2nds | 3rds | 1st | Team: ags.lunartwins.LunarTwins | 40564 | 11200 | 1840 | 22374 | 3891 | 1000 | 259 | 56 | 19 | 0 | 2nd | Team: abc.ShadowTeamTwin | 27759 | 3800 | 460 | 20621 | 1614 | 1135 | 129 | 19 | 56 | 0 -- Rednaxela

Very impressive! Could you try it with the latest Shadow? I made a lot of melee/teams tweaks but never updated the team rumble, versions after 3.76 should preform slightly better due to the gun improvements. -- ABC

Sure! Just made a team of 2 Shadow 3.81f bots (latest in 1v1 rumble) and well... here's how that goes: LunarTwins wins 48-27, 55-20, 50-25, 52-23, and then 50-25. It appears that the latest Shadow does indeed fare a little bit better:

Rank	Robot Name	Total Score	Survival	Surv Bonus	Bullet Dmg	Bullet Bonus	Ram Dmg * 2	Ram Bonus	1sts	2nds	3rds
1st	Team: ags.lunartwins.LunarTwins	40293	10900	1660	22733	3831	1063	107	50	25	0
2nd	Team: abc.ShadowTeamTwin2	28770	4100	540	20679	1987	1270	194	25	50	0

A couple thoughts about ShadowTeam that I notice here: Interestly it's ram damage is always higher than that of LunarTwins, so I think that means that both Shadows are occasionally hitting eachother, also the new version doesn't seem to do significantly better in bullet damage than the old version which makes me suspect that perhaps the largest gains that Shadow has made are in terms of the melee/team tweaks as opposed to the gun improvements.
Update: Er... whoops, I did the trial with the new version in a 800x600 field when LunarTwins is hardcoded for 800x800 (TwinDuel standard). Running it again with the proper field size: LunarTwins wins 57-18, 52-23, 57-18, 55-20, and 56-19

Rank	Robot Name	Total Score	Survival	Surv Bonus	Bullet Dmg	Bullet Bonus	Ram Dmg * 2	Ram Bonus	1sts	2nds	3rds
1st	Team: ags.lunartwins.LunarTwins	41011	11400	1860	22998	3845	671	238	56	19	0
2nd	Team: abc.ShadowTeamTwin2	27150	3600	400	20642	1577	842	88	19	56	0

So, it looks like the newer version of Shadow doesn't perform significantly better against LunarTwins really, perhaps a little worse event. My ponderings about the Shadows possibly hitting eachother still applies though for both versions.
-- Rednaxela

Interesting, your strategy really is amazing for 2vs2. Are you ever going to release a killer robot team? -- ABC

Well, I have a RoboRumble (5-bot) team based on the strategy of LunarTwins on the drawing board (codname RedMoons), however, the difficulty is that I've been having is in adding proper scan sharing to the base of RougeDC (which I'm using as the base for a couple reasons). Once I get that scan sharing figured out and working smoothly, I'll probably start getting towards a killer RoboRumble team far faster :) -- Rednaxela

IIRC, there was one really bizarre thing I had to do with scan sharing - something like the constructor for a ScannedRobotEvent expecting an angle in degrees instead of radians. (Since you can only send Serializable objects, you have to make your own class to send the data, then new up an SRE on the other end.) I was able to fit full scan sharing / locking into a TwinDuel team, actually, but it surprisingly didn't seem to help at all when compared to Lumi's current optimal radar that just goes back and forth. It was only like 200 bytes bigger than Lumi's current radar, but Lumi's could also be made a bit smaller if I did it how Skilgannon does it. -- Voidious

Hmm that is interesting. Well, converting back to a SRE isn't really what my issue is. My issue is more to do with making my code able to handle receiving the 1-tick-old shared data, and ignore it when it already got that scan itself last tick, etc. It wouldn't be so so bad if my code wasn't making some assumptions that either location is either brand new or completely out of date. About usefulness of it: Well, some of my plans of how to best adapt LunarTwins tactics to a 5v5 setting, do require all of my robots to have the identical knowledge of enemy locations according to the scans last tick in order to cooperate as I intend ;) -- Rednaxela