Compiled but can't see...

Jump to navigation Jump to search
Revision as of 1 October 2012 at 21:33.
The highlighted comment was edited in this revision. [diff]

Compiled but can't see...

I set up a robot project on my NetBeans. I loaded the robocode libraries, etc. All this seemed to go successfully. I can even compile my robot class with success. I also pointed robocode to the directory my robot class is in.

But my robot doesn't show up in the robot list for fights!

Any ideas? Thanks.

    Therealdrag005:35, 1 October 2012

    Hi! How you "pointed robocode to the directory my robot class is in"? What this directory contents? Do you added ${robot.name}.properties file? Which package are you use?

      Jdev12:34, 1 October 2012
       

      Thanks for the reply!

      I added the directory, "C:\MyRobots\build\classes\zjk", to development options. In that directory is only the class file, "drag0.class"

      Okay, since you mentioned properties file, I looked around (I don't see any ${robot.name}.properties file). I tried adding the other directories above the one mentioned above and it still doesn't work. how is a .properties file generated and what is its purpose?

        Therealdrag021:37, 1 October 2012
         

        The .properties file is added to the JAR when you package your bot, but it shouldn't be needed in order to see a development version of your bot. I'm not sure, but I think you'll need to add the top level directory in Robocode - e.g., if your bot is zjk.MyRobot, under ...\build\classes\zjk\MyRobot.java, you'd need to point Robocode to ...\build\classes.

        I have my things setup the other way, with Eclipse compiling the .class files into robocode/robots/, but that's kind of a stupid setup that I've just never bothered to change.

          Voidious22:06, 1 October 2012

          Not that stupid. Many times I saw a development version working, only to generate a non-working JAR. Wrong .properties file, security violations, wrong file names...

          And the opposite problem (non-working development versions) arises when you use the engine API directly instead of the GUI . i.e. genetic tuning with full battles.

          I also develop and test using JARs instead of raw .class files.

            MN22:30, 1 October 2012