User talk:Jdev/Questions

RhinoScriptEngine - it's fair play or not?

I find out today, that there're embed script engine may be used, to reduce codesize. Example:

package lxx.test.js;

import robocode.AdvancedRobot;
import com.sun.script.javascript.RhinoScriptEngine;

import javax.script.ScriptException;
import javax.script.ScriptContext;
import javax.script.SimpleScriptContext;

/**sure
 * User: jdev
 * Date: 11.11.2009
 */
public class JSTest extends AdvancedRobot {

    public void run() {
        RhinoScriptEngine rse = new RhinoScriptEngine();
        try {
            ScriptContext ctx = new SimpleScriptContext();
            rse.eval("var a = 100;", ctx);
            Double i = (Double) ctx.getAttribute("a");
            ahead(i);
        } catch (ScriptException e) {
            e.printStackTrace();
        }
    }
}

so i can rewrite most part of my code on js and only call it it nanobot. but i don't sure, that it is fair. What do you think about it? --Jdev 16:37, 11 November 2009 (UTC)

I think it was generally agreed that using interpreted languages to bypass the codesize utility isn't exactly fair, so although you can put your bot in the rumble to see where it would score, it would be better if you didn't leave it there, because based on the amount of code you have, it probably isn't a nanobot anyways. Look at White Whale and Talk:White Whale for more discussion on this =) It's quite cool that there is an included script engine in Java, I didn't even know about it =) --Skilgannon 17:19, 11 November 2009 (UTC)

Why i so honest?=) I glad, that i give something new in java=) there're also interpreters for php python, as i know. And i'm sure that there're also engines for other languages. --Jdev 17:28, 11 November 2009 (UTC)

Aside from what Skilgannon said... I'm very doubtful it can be used to reduce codesize actually for the following reason: I'm 95% certain that Robocode does not let robots access packages that are not part of the core java standard, in particular, I'm pretty certain you can't access the com.sun package from inside robots, maybe not even the javax package. Nice trythough, hah. --Rednaxela 17:35, 11 November 2009 (UTC)

I check it before publishing - it works=) --Jdev 17:55, 11 November 2009 (UTC)

I'm running OpenJDK, which doesn't include Rhino. So I can't compile this bot, and any bot based on this would get 0 on my system =) --Skilgannon 19:15, 11 November 2009 (UTC)

Yes, you right=) I try to use

new ScriptEngineManager().getEngineByName("JavaScript")

, but "Preventing lxx.UltraMarine 1.0 from access (java.lang.RuntimePermission createClassLoader)" appears. So question is closed=) --Jdev 19:29, 11 November 2009 (UTC)

It's not possible to get around it by going the other way either:

   package jk;

   import robocode.AdvancedRobot;

   import javax.script.*;
   import java.util.*;


    public class JSTest extends AdvancedRobot {
   
       public void run() {
         ScriptEngineManager manager = new ScriptEngineManager();
         List <ScriptEngineFactory> l = manager.getEngineFactories();
         ScriptEngine engine = null;
         for(ScriptEngineFactory sef:l){
            engine = sef.getScriptEngine();
            System.out.println("Engine found: " + sef.getEngineName());
         }
      
      	
         try {
            Double i = (Double)engine.eval("var a = 100; return a;");
            ahead(i);
         } 
             catch (ScriptException e) {
               e.printStackTrace();
            }
      }
   }

throws

jk.JSTest: Exception: java.security.AccessControlException: Preventing jk.JSTest from access: (java.lang.RuntimePermission createClassLoader)
java.security.AccessControlException: Preventing jk.JSTest from access: (java.lang.RuntimePermission createClassLoader)
    at robocode.security.RobocodeSecurityManager.checkPermission(Unknown Source)
    at java.lang.SecurityManager.checkCreateClassLoader(SecurityManager.java:611)
    at java.lang.ClassLoader.<init>(ClassLoader.java:242)
    at org.mozilla.javascript.DefiningClassLoader.<init>(DefiningClassLoader.java:54)
    at org.mozilla.javascript.ContextFactory.createClassLoader(ContextFactory.java:352)
    at org.mozilla.javascript.Context.createClassLoader(Context.java:2262)
    at org.mozilla.javascript.SecurityController.createLoader(SecurityController.java:143)
    at org.mozilla.javascript.optimizer.Codegen.defineClass(Codegen.java:142)
    at org.mozilla.javascript.optimizer.Codegen.createScriptObject(Codegen.java:101)
    at org.mozilla.javascript.Context.compileImpl(Context.java:2409)
    at org.mozilla.javascript.Context.compileString(Context.java:1359)
    at org.mozilla.javascript.Context.compileString(Context.java:1348)
    at org.mozilla.javascript.Context.evaluateString(Context.java:1101)
    at com.sun.script.javascript.RhinoTopLevel.<init>(RhinoTopLevel.java:72)
    at com.sun.script.javascript.RhinoScriptEngine.<init>(RhinoScriptEngine.java:92)
    at com.sun.script.javascript.RhinoScriptEngineFactory.getScriptEngine(RhinoScriptEngineFactory.java:74)
    at jk.JSTest.run(JSTest.java:21)
    at robocode.peer.RobotPeer.run(Unknown Source)
    at java.lang.Thread.run(Thread.java:636)

--Skilgannon 19:59, 11 November 2009 (UTC)

The improved security manager is partly my fault, as I awhile ago demonstrated hackbots which staticly accessed the internal classes in robocode. I also took the route of showing I could access parts of the JDK which allowed web access (which I later tested by downloading a file from my server), this in turn caused FNL to beef up the security manager, which for the most part is for the best, as running one of the built in script engines in your bot could allow it to run unsigned or hazardous code which could get around the security manager. --Chase 20:42, 11 November 2009 (UTC)

---

What of fire situation attributes (like lateral velocity, distance, near wall etc.) you use for segmentation you data?

I understand, that it may be "professional secret", but if any of top bot authors share this info - it will be cool=) Thank you=) --Jdev 10:32, 19 February 2010 (UTC)

Easy -- Lateral Velocity seems to be the most important. Distance and near wall can split the movement type in situations. Try to look at Top Bot source code =) --Nat Pavasant 11:12, 19 February 2010 (UTC)

It's important for me to don't see other bot's source code =) --Jdev 11:30, 19 February 2010 (UTC)

Then it is what I said, plus some experiment. This information is vary between different implementation. --Nat Pavasant 12:02, 19 February 2010 (UTC)

Yep, lateral velocity, distance (I'd use "bullet flight time" instead), wall distance, and velocity change (accelerating/decelerating or time since velocity change) are the most important ones. Somewhere on the wiki is a table of what attributes/how many slices some top bots use (starting with Skilgannon/DrussGT), but I'm failing to find it with a quick Google search right now... --Voidious 12:40, 19 February 2010 (UTC)

I think the tables you're referring to are here: http://old.robowiki.net/cgi-bin/robowiki?TargetingChallenge2K7/ResultsChat --Darkcanuck 14:47, 20 February 2010 (UTC)

Thanks! I swear I spent like 20 minutes Googling and wiki-searching for those. =) (I thought they were on the new wiki, too...) --Voidious 15:23, 22 February 2010 (UTC)

I'm considering the same issues right now as well. Right now LBB only segments on Distance - but it segments its movement as well as its gun. I'm currently investigating Lateral velocity and averaged velocity acceleration right now, combined with distance and the results are decent. I'm not yet sold though as my firepower management still needs improvement. Funny thing though, even distance by itself does ok against simpler bots. --Miked0801 17:48, 19 February 2010 (UTC)

A quick little note about distance: In some experiments, I was finding that distance was ranking as very unimportant actually, however those experiments were in a 'Targeting Challenge' environment where only the enemy moves and distances stay relatively stable. As soon as I put it on a movement and into the rumble, I found that adding some more distance-related (bullet travel time), segmentation helped significantly. --Rednaxela 18:45, 19 February 2010 (UTC)

Thanks for all. Now I develop autosegmentet gun, which use currently about 40 fire situation attributes, and it seems (imaging, looking?) not bad. --Jdev 11:57, 22 February 2010 (UTC)

---

Question for native english speakers.

Which text is better readable:

1) I found out new application for google translator: i write text on english, but I do watching to how, google translate it on russian. This text is written by this way

2) I found a new use for an interpreter Google: I am writing in English, but look how he takes what I write in Russian. But this text was translated to english from russian by Google Translator

--Jdev 16:39, 15 September 2010 (UTC)

I think #1 is a little better. And if it helps, I would write it like this:

• I found a new way to use Google translator: I write text in English and then examine how Google translates it to Russian.

--Voidious 17:45, 15 September 2010 (UTC)

Thank you:)

and It will be cool, if native english speakers will show me my mistakes. Especially in time (past simple, present simpl etc) - i didn't study them (i was been lazy schoolboy and student:)) in 4 class and still didn't done it:) --Jdev 18:00, 15 September 2010 (UTC)

Just a note though, watching Google Translate translating between languages is not really learnable, perhaps some pairs may be translated correctly (from what I've seen, French-English pair is usually accurate). And do I need to be native English speaker to help you? --Nat Pavasant 18:18, 15 September 2010 (UTC)

I use Google tranlator not for learning, but for to be more understandable:)

No, but yours English must on expert level, because switch one mistake on another one isn't good idea:) --Jdev 18:36, 15 September 2010 (UTC)

I remeber, that there was discussion about migrate RoboRumble to robocode version 1.7, but i cannot find it. When migration will happen?

--Jdev 09:45, 19 November 2010 (UTC)

When the community decided that Robocode 1.7 is stable enough. But I think we must find one responsible for this migration first. The RoboWiki seems quiet lately. --Nat Pavasant 12:14, 19 November 2010 (UTC)

Thanks. It seems like the fate thinks that UltraMarine isn't ready for release:) --Jdev 12:35, 19 November 2010 (UTC)

---

Null victim name in BulletHitEvent

I notice, that in version 1.7.3.0 BulletHitEvent.getBullet.getVictim returns null. I hear about "hide enemy name" feature, but idea was to return "Enemy 1" etc. It's bug or normal behavior?

I do some more research and find out, that if "Hide enemy names" checkbox is setted, then ScannedEvent.getName returns "1#", but BulletHitEvent.getName() returns not hidden enemy name. I think, that this bug will seriously impact to melee bots --Jdev 09:31, 6 June 2011 (UTC)

Those two things definitely sound like a bug. Could you please report it at the bug tracker? --Rednaxela 11:18, 6 June 2011 (UTC)

Bullet.equals semantic has been change

In my code i has condition bulletObjectReturnedBySetFire.equals(bulletObjectInBulletHitEvent) which doesn't works in 1.7.3.0 (returns false for all recorded bullets). But in earler version (i don't remember exactly number) it works fine It's bug or normal behavior? --Jdev 08:49, 6 June 2011 (UTC)

BulletHitBulletEvent.getHitBullet().getName() and HitByBulletEvent.getBullet().getName() returns not hidden enemy name too --Jdev 09:38, 6 June 2011 (UTC)

The equals method changing behavior for bullets in that way would definitely be a bug as well. Could you report that at the bug tracker as well? Thanks. --Rednaxela 11:18, 6 June 2011 (UTC)

Thank you, Rednaxela, for answer. I've submit bugs:

• https://sourceforge.net/tracker/?func=detail&aid=3312402&group_id=37202&atid=419486
• https://sourceforge.net/tracker/index.php?func=detail&aid=3312341&group_id=37202&atid=419486

--Jdev 11:30, 6 June 2011 (UTC)

LRP

What is LRP in problem bots graph? --Jdev 09:37, 10 August 2011 (UTC)

Those graphs in the roborumble robot details page. OldWiki Roborumble/LRP — Chase-san 10:26, 10 August 2011 (UTC)

Thank you, Chase. I forgot about old wiki

Edit conflict... but... The LRP shows your problem bots by comparing the score you get against them vs. what you were expected to score. This makes it easy to see whether you tend to do better or worse than expected against good or bad bots. --Skilgannon 10:46, 10 August 2011 (UTC)

ok, thank you too:) --Jdev 10:52, 10 August 2011 (UTC)

Veterans, i think it will be interesting for community to know a history of rumble throne. As i know, it was something like this:

• SandboxDT - ??? - ???
• Shadow - ??? - March 2004
• RaikoMX - March 2004 - July 2004
•  ??? Shadow - July 2004 - November 2004
• Ascendant - November 2004 - April 2006
• Dookious - April 2006 - ??? 2008
• DrussGT - ??? 2008 - now days

Correct me, please, if there is mistakes and add dates, if you know. Then, i think, this list may be moved to separate page

This page] should really be migrated to the new wiki =)

O, thank you, i always forgot about old wiki:)

Hi to all. Who which test beds use to test robots? I cannot find out test bed which will give stable results (+/- 0.05 APS). Now i use every 5th bot roborumble with 5 season vs each and results is in interval -/+ 0.3 APS.

I speak about results stable in reasonable time and meaningful in APS terms

Well, I suspect it's total number of battles that matters most. A recent version of Diamond dropped 0.12 APS after 2000 battles in the rumble, but perhaps that was a fluke due to someone's client skipping turns. My APS test beds are 100 bots and I run 5 seasons (500 battles) to get an idea, 10 seasons I consider accurate enough even for pretty minor tweaks, or 20 seasons if I want to feel very confident. I'm not sure what the statistical accuracy is, but +/- 0.05 for 20 seasons (2000 battles) would be about my guess. That's pretty much my experience with the accuracy of RoboRumble results after 2k battles, too.

I've been thinking about adding to RoboResearch the feature to calculate the confidence interval of the overall result, assuming normal distributions. It should be pretty easy.

I run 30 seasons of 35 rounds against 40 bots (taking approx 18 hours). No idea if it is stable though, it is my first testbed. I do know my testbed does not reflect the rumble correctly, because 0.3.2 and 0.3.5 score on par, and 0.3.7 approx 1.5 APS lower.

GrubbmGait, you're a hero:) for me 4 hours for test it is limit and i want to get test which give me results in 2 hours. And may be you will try to use Distributed_Robocode - now i can share with you my home netbook (i3 1.3 x 2) and on this week i plan to setup old duron 1.6 as dedicated robocode server. So, i guess, your's test will take at maximum 6 hours (but it's strong depends from which robots is in yours test bed)

One quick little thought, is theoretically, it should be possible to use PCA to come up with the most significant axes of the roborumble, and rank robots by how well they correlate with each axis. Then, you also rank robots by their standard deviation. You then pick robots which simultaneously have a low standard deviation, and highest correlation with the axes that the PCA determined. Then you can use some linear regression to determine the weight to give each of the robots selected.

That I think, would probably be a good way to find a testbed which simultaneously represents the rumble well and has low noise... Hmm... maybe I should make a patch to Voidious' testbed maker that uses the algorithm I describe in the paragraph above...

I found out good test bed - 7 seasons against every second bot from roborumble (~2900 battles). It produces repeating results within +/- 0.05 APS and error against real RR within +/- 0.1 APS

I'd think 1 battle against each bot from the rumble would probably give better results... maybe not as reproducible but closer correlated to the rumble.

No Skilgannon, even 3 battles against every bot is worse in terms of stability and correlation with RR

I totally agree with using very large test beds (lately ~100 bots for me), but I think you're wasting some CPU cycles testing against bots that are unlikely to be affected by your changes. Bots you get 98+ against probably won't be affected unless you're testing changes to your core surfing algorithm or something. Most changes to surf stats are not going to affect HOT bots at all, and flattener tweaks won't affect any bots that have no chance of triggering your flattener.

My last release show, that you never know what will be affected:) So better if test will execute 7 hours, against 6.5, but give confidence in results:)