- Fixed security flaw with the Event Dispatch Thread, where robots could use the SwingUtilities.invokeLater() for running any code they should like to.
- Thanks goes to John Cleland who reported this security flaw and provided some very good examples of robot that could do some nasty cheats.
Wednesday, 12 December 2007
Wednesday, 5 December 2007
Robocode 1.5 has been released
Compared to the 1.5 Beta, the following was added.
New features:
- Added the Robot Cache Cleaner tool created by Aaron Rotenberg (aka AaronR).
- Used for cleaning the cache files for the robots, which is very useful with the RoboRumble client, where most problems can be solved by cleaning the robot cache files.
- This tool is activation by selecting "Clean Robot Cache" in the Options menu or by running the tool from a command line (standing in the robocode home directory):
Changes:
- Improved the output of the command line usage of Robocode when called from the command line with the -? or -help option.
New features:
- Added the Robot Cache Cleaner tool created by Aaron Rotenberg (aka AaronR).
- Used for cleaning the cache files for the robots, which is very useful with the RoboRumble client, where most problems can be solved by cleaning the robot cache files.
- This tool is activation by selecting "Clean Robot Cache" in the Options menu or by running the tool from a command line (standing in the robocode home directory):
java -cp ./libs/robocode.jar;./libs/cachecleaner.jar ar.robocode.cachecleaner.CacheCleaner
Changes:
- Improved the output of the command line usage of Robocode when called from the command line with the -? or -help option.
Thursday, 22 November 2007
Robocode 1.5 Beta is ready for testing
Changes:
- Redundant HitRobotEvents are no longer occurring when Robocode is performing collision detection between two robots. Previously: If a collision between a stationary robot (i.e. not moving) and another robot that was moving, then two HitRobotEvents would first be sent to each robot based on the stationary robot even though no damage was done. Next, two HitRobotEvents would be sent to each robot based on the robot that was moving, which WAS causing damage. Now: HitRobotEvents will only occur when damage is done to each robot, and no HitRobotEvents will be ever be sent when no damage is done, i.e. when a stationary robot is "colliding" with another robot.
- The events in the robot event queue are now sorted in chronological order so that events that occurred before newer events gets processed first. Previously, the event queue was ordered based on the event priorities so that the events with the highest priorities were processed first. This could cause some problems with robots with skipped turns, as their event queue would potentially contain events from different time frames. Now it is perfectly safe for robots to assume that events occurring before other event are processed first. Events occurring in the same time frame is still sorted based on their priorities so that the events with higher priorities are processed before events with lower priorities.
- The priority of the DeathEvent was changed from the reserved priority 100 to -1 in order to allow robots to process all pending events before they die. Previously, robots were not able to process all events when it died as the DeathEvent was having the highest possible priority. Now when the DeathEvent has the lowest priority, this will be the last event left on the robot's event queue before it dies. That is, all events in the event queue have already been processed when reaching the DeathEvent.
- The CPU constant is now measured in nanoseconds rather than milliseconds. Using the new features introduced of Java 5.0 provides more precise timing and also offer better granularity of timings
- The "Number of Rounds" value on the New Battle Dialog is now saved and restored when the game is restarted, i.e. Robocode remember that value you used last time.
New feature:
- The Robot class has got a new onStatus(StatusEvent e) method which is automatically called for each turn of a battle, and which contain a complete snapshot of the current robot state at that specific time/turn. This new method makes it possible to map a specific robot field to a specific time.
- Redundant HitRobotEvents are no longer occurring when Robocode is performing collision detection between two robots. Previously: If a collision between a stationary robot (i.e. not moving) and another robot that was moving, then two HitRobotEvents would first be sent to each robot based on the stationary robot even though no damage was done. Next, two HitRobotEvents would be sent to each robot based on the robot that was moving, which WAS causing damage. Now: HitRobotEvents will only occur when damage is done to each robot, and no HitRobotEvents will be ever be sent when no damage is done, i.e. when a stationary robot is "colliding" with another robot.
- The events in the robot event queue are now sorted in chronological order so that events that occurred before newer events gets processed first. Previously, the event queue was ordered based on the event priorities so that the events with the highest priorities were processed first. This could cause some problems with robots with skipped turns, as their event queue would potentially contain events from different time frames. Now it is perfectly safe for robots to assume that events occurring before other event are processed first. Events occurring in the same time frame is still sorted based on their priorities so that the events with higher priorities are processed before events with lower priorities.
- The priority of the DeathEvent was changed from the reserved priority 100 to -1 in order to allow robots to process all pending events before they die. Previously, robots were not able to process all events when it died as the DeathEvent was having the highest possible priority. Now when the DeathEvent has the lowest priority, this will be the last event left on the robot's event queue before it dies. That is, all events in the event queue have already been processed when reaching the DeathEvent.
- The CPU constant is now measured in nanoseconds rather than milliseconds. Using the new features introduced of Java 5.0 provides more precise timing and also offer better granularity of timings
- The "Number of Rounds" value on the New Battle Dialog is now saved and restored when the game is restarted, i.e. Robocode remember that value you used last time.
New feature:
- The Robot class has got a new onStatus(StatusEvent e) method which is automatically called for each turn of a battle, and which contain a complete snapshot of the current robot state at that specific time/turn. This new method makes it possible to map a specific robot field to a specific time.
Subscribe to:
Posts (Atom)
