Difference between revisions of "Polylunar/Archived Talk"

From Robowiki
Jump to navigation Jump to search
(Migrate from the old RoboWiki)
 
m (oops)
 
Line 5: Line 5:
 
| page2  = Archived Talk
 
| page2  = Archived Talk
 
}}
 
}}
{{Talkarchive|Talk:Shadow}}
+
{{Talkarchive|Talk:Polylunar}}
  
 
Well then... it isn't faring quite so well on the field and I think I know why. In my earlier tests, I was using the default 800x600 field when the team RR uses a 1200x1200 field. It seems like the larger field causes Polylunar some very serious problems. The main issues seem to be:
 
Well then... it isn't faring quite so well on the field and I think I know why. In my earlier tests, I was using the default 800x600 field when the team RR uses a 1200x1200 field. It seems like the larger field causes Polylunar some very serious problems. The main issues seem to be:

Latest revision as of 18:31, 6 September 2017

Sub-pages:
PolylunarVersion History - Archived Talk
       Archive        This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.     

Well then... it isn't faring quite so well on the field and I think I know why. In my earlier tests, I was using the default 800x600 field when the team RR uses a 1200x1200 field. It seems like the larger field causes Polylunar some very serious problems. The main issues seem to be:

  • Larger distances to travel mean that Polylunar is in a vulnerable situation for significantly longer and that chasing based on an enemy's current location becomes increasingly inefficient.
  • The AntiGravityMovement that's currently in use for unpaired robots often tends to cause the bot to end up moving along right against the walls. In the large field this means that it takes far too long to get into the action if it becomes required for a pairing.
  • At these larger distances, linear targeting with nothing preventing firing out of bounds is far less effective.
  • In the larger fields, the other bots tend not to be cornered so much
  • Only firing 3.0 power bullets is probably more of a problem on the larger field size.

This is a little disappointing. Hopefully I'll manage to get these problems solved...
-- Rednaxela

Well, despite the setback due to the larger field, Polylunar is not dead in the water. I've been using Valkiries as a TestBed and have made some notable improvements that I think would hold true against most if not all bots. Here's a pretty graph of the incremental improvements I've been making:
http://homepages.ucalgary.ca/~agschult/Polylunar1.png
I'm too tired to write about what changes I made in each increment right now, but in each revision, I did make an improvement which is uplifting (as opposed to changes in RougeDC more often than not degrading performance). Between the first (red) and last (orange) the difference is certainly notable. I think I'll make a 1.1 release soon based on the improvements, but first I want to get the missing battles in the rumble filled in. -- Rednaxela


Oooh... version 1.3 is sitting at the top of the PremierLeague... ;-) -- Rednaxela

Congratulations! I'm also working in a new team. Enjambre is only a proof of concept but the new one is intended to be another ProblemBot for the TeamRumble :P -- Jab

Thanks! It seems that position was somewhat frail though, because after further battles, Polylunar seems to be beaten by kid.team.OmegaSquad. So my next goals? Not fail so much against OmegaSquad, and make how much I beat PhoenixTeam and Xmen by a bit more robust. After that I might being my first MeleeBot, partially with the intention of brining what I learn back to the team scene to improve Polylunar. -- Rednaxela

Well... released 1.4 now, which after just a small change beats PhoenixTeam with considerably more robustness (average score of 57.5 instead of 52.5 in my 150 trial tests). We'll see how this goes... :-) -- Rednaxela

Well then... version 1.4 is sure doing quite well... Xmen appears to be the only thing I don't get better than 55 against and I've put some rather ugly looking red marks in the details pages of the only teams with over 1900 points. :-) -- Rednaxela


Well, I made a logo for Polylunar to celebrate seeming to have the team PL crown with reasonable stability. Hope it isn't grinning too much :-) -- Rednaxela

The logo is indescribable. :P But this comment is about another thing,it seems that I have to have the robocode security disabled to test my underdevelopment team against Polylunar! Access control Exception. -- Jab

Hmm, that is very strange. What version of Robocode are you using? I'm not having any issues like that here and I've tested it on a few different installations of Robocode 1.6.0 none of with with security disabled. Are there any other details to the error? -- Rednaxela

If you are able to reproduce the problem, then tell me what version of Robocode you are using, the setting (if you changed them), and also how exactly to reproduce the problem. Then file a bugreport on SF (http://sourceforge.net/tracker/?group_id=37202&atid=419486). Then I'll make sure that the issue is solved. :-) --Fnl

It happens to Polylunar against any team. Robocode version: 1.4.9 Settings: java -Xmx512M -Dsun.io.useCanonCaches=false -cp libs/robocode.jar;libs/codesize.jar robocode.Robocode

 ags.polylunar.Luna [1.4]: Exception: java.security.AccessControlException: Preventing ags.polylunar.Luna [1.4] from access:     (java.io.FilePermission G:\robocode\robots\.robotcache\ags.polylunar.Polylunar_1.4.jar_\robocode\StatusEvent.class read): You may only read files in your own root package directory. 
 java.security.AccessControlException: Preventing ags.polylunar.Luna [1.4] from access: (java.io.FilePermission   G:\robocode\robots\.robotcache\ags.polylunar.Polylunar_1.4.jar_\robocode\StatusEvent.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(Unknown Source)
   at java.io.File.length(Unknown Source)
   at robocode.security.RobocodeClassLoader.loadRobotClass(Unknown Source)
   at robocode.security.RobocodeClassLoader.loadClass(Unknown Source)
   at java.lang.ClassLoader.loadClass(Unknown Source)
   at java.lang.ClassLoader.loadClassInternal(Unknown Source)
   at ags.polylunar.robotdata.AllyData.updateTick(AllyData.java:57)
   at ags.polylunar.core.Moon.updateStatus(Moon.java:58)
   at ags.polylunar.core.Moon.runTick(Moon.java:39)
   at ags.polylunar.base.BotBase.run(BotBase.java:153)
   at robocode.peer.RobotPeer.run(Unknown Source)
   at java.lang.Thread.run(Unknown Source)

-- Jab

It looks like Polylunar is dependant on the StatusEvent, which isn't available in the earlier versions of Robocode. If you use a later version there shouldn't be a problem. -- Skilgannon

Ahh yes, it does use StatusEvent (like I tend to do in just about any of my bots that are not very tight on codesize limits). So yes, use 1.5.4 or 1.6.0 and you'll be fine, besides, 1.5.4 is to my understanding supposed to be considered the "minimum" version that should be run with RoboRumble anyways. -- Rednaxela

Ok, I didn't know that the API was extended in new versions. Is this legal? ;). I will check these new classes and functions :P. For contributing battles I always use another robocode installation which version is 1.5.4. -- Jab


Hmm... I'm nearly regretting putting some of my very very well tested and fine turned code from LunarTwins into Polylunar... It's hard to improve on the previously low-hanging-fruit of bullet power selection and stuff that I've already tuned in LunarTwins! ;-) Of course... still lots to improve, like unpaired/solo-movement/targeting, and seeing if I can find something better than LinearTargeting at close range chasing. It's actually really hard to find anything better than LinearTargeting for close range chasing! -- Rednaxela