Robocode 1.7.1.4 (final) has been released

[Flemming N. Larsen]

A new beta of Robocode has been released:

http://robo-code.blogspot.com/2009/09/robocode-1714.html

 

Download:

https://sourceforge.net/projects/robocode/files/robocode/1.7.1.4/robocode-1.7.1.4-setup.jar/download

 

This version is dedicated for the RoboRumble@Home community where many issues seen with the RoboRumble client have been solved.

Thank you all for reporting as many known issues as possible, and also help out solving these - especially with the issue seen with the robot movement that had a big impact on the scores and rankings! :-)

 

Bugfixes

·         Bug [2845608] - java.io.FileNotFoundException in RobotFileSystemManager.init

·         Bug [2845612] - Can't load Katana 1.0 or DrussGT 1.3.1wilo

·         Bug [2854692] - Lockup on start if too many bots in robots dir

·         Bug [2852860] - IllegalArgumentException on painting in some robots

·         Fixed NullPointerException that could occur with the -battle command-line option

 

Changes

 

Banning

·         The previous 1.7.x.x versions have been very strict so that robots that could not be loaded, started, skipped too many turns etc. would be disallowed to participate in battles. With the bugfix for bug [2845612] above this policy has been changed so robots are only "banned" if the cause a security violation or they could not be loaded or started (meaning that they are not able to run). In addition, ALL security violations are always written out in both the main console and robot's console. A message will be written out in the main console like "xxx has caused a security violation. This robot has been banned and will not be allowed to participate in battles".

 

Painting

·         With the bugfix for bug [2852860] a change was made so a robot will now receive this message in its console window, if it is painting too much between actions:

"SYSTEM: This robot is painting too much between actions.  Max. capacity has been reached."

 

·         Notice that a robot is not allowed to perform an unlimited amount of paint operations for two reasons:

1) It takes up a lot of memory as the painting operations are recorded in a buffer before being processed, and potentially this buffer must be recorded to a file (for replays). A robot is allowed to use up to a maximum of 64 KB per action. An average painting operation like e.g. fillRect(x, y, width, height) takes up 15 bytes, meaning that more 4000 painting operations should be possible, which is a lot.

2) It takes a lot of CPU cycles to process the painting buffer to the display making the painting slow if the buffer is too large.

 

·         It is possible to remove the limit of the robots painting buffer by using the command-line option: -Ddebug=true

 

Regards,

- Flemming