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)