User talk:Jdev/Questions

From Robowiki
< User talk:Jdev
Revision as of 18:48, 19 February 2010 by Miked0801 (talk | contribs) (my take)
Jump to navigation Jump to search
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'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)