Difference between revisions of "User:D414/Personal Gotchas"
(Roborumble melee competitions aren't what I'd assumed) |
|||
| Line 1: | Line 1: | ||
| + | = The Mini / Micro / Nano melee rumbles aren't what you might expect= | ||
| + | I had always assumed that scores for the mini, micro and nano melee rumbles were based on matches consisting only of robots from those weight classes. '''This is incorrect!'''. The scores for, say, the mini melee rumble are from any battles that have at least two minibots and upto eight bots from the general population. | ||
| + | |||
= Event Priority = | = Event Priority = | ||
The documentation for event priorities is unclear. [https://robocode.sourceforge.io/docs/robocode/robocode/AdvancedRobot.html#setEventPriority-java.lang.String-int- setEventPriority] says lower values are higher priority while [https://robocode.sourceforge.io/docs/robocode/robocode/AdvancedRobot.html#getEventPriority-java.lang.String- getEventPriority] says higher values are higher priority. Testing confirms the later is correct. | The documentation for event priorities is unclear. [https://robocode.sourceforge.io/docs/robocode/robocode/AdvancedRobot.html#setEventPriority-java.lang.String-int- setEventPriority] says lower values are higher priority while [https://robocode.sourceforge.io/docs/robocode/robocode/AdvancedRobot.html#getEventPriority-java.lang.String- getEventPriority] says higher values are higher priority. Testing confirms the later is correct. | ||
Revision as of 23:24, 9 April 2024
Contents
The Mini / Micro / Nano melee rumbles aren't what you might expect
I had always assumed that scores for the mini, micro and nano melee rumbles were based on matches consisting only of robots from those weight classes. This is incorrect!. The scores for, say, the mini melee rumble are from any battles that have at least two minibots and upto eight bots from the general population.
Event Priority
The documentation for event priorities is unclear. setEventPriority says lower values are higher priority while getEventPriority says higher values are higher priority. Testing confirms the later is correct.
The documentation also has errors for the default priorities for several events.
| Event | setEventPriority docs | Source Code (1.9.5.2) |
|---|---|---|
| RoundEndedEvent | 100 | 110 |
| BattleEndedEvent | 100 | 100 |
| WinEvent | 100 | 100 |
| SkippedTurnEvent | 100 | 100 |
| StatusEvent | 99 | 99 |
| Key and Mouse Events | 98 | 98 |
| CustomEvent (Default) | 80 | 80 |
| MessageEvent | 75 | 75 |
| RobotDeathEvent | 70 | 70 |
| BulletMissedEvent | 60 | 60 |
| BulletHitBulletEvent | 55 | 55 |
| BulletHitEvent | 50 | 50 |
| HitByBulletEvent | 40 | 20 |
| HitWallEvent | 30 | 30 |
| HitRobotEvent | 20 | 40 |
| ScannedRobotEvent | 10 | 10 |
| PaintEvent | 5 | 5 |
| DeathEvent | -1 | -1 |
Execute Method
The documentation for the execute method says that it must be called otherwise set* methods will never be performed. This doesn't seem to be strictly true as a robot that uses set methods to spin its radar, gun and body in the run method will spin even without calling execute.
Skipped Turns
The documentation for SkippedTurnEvent says a robot will be removed from the battle after skipping 30 turns however a robot using the example code will skip many more turns than this without being removed from the battle.
Ramming / ROBOT_HIT_BONUS / HitRobotEvent
Based on some quick tests with RamFire vs SittingDuck it looks as though Rules.ROBOT_HIT_BONUS isn't actually applied.
It also appears that a ramming robot that gets stopped effectively gets its movement for that turn cancelled and remains in the same position. However, it can still move closer to the target on subsequent turns (Also tested with RamFire vs SittingDuck). This is mostly unimportant except for the case of using a HitRobotEvent to determine the position of an enemy that wasn't scanned that turn (eg in melee or a Droid in a team battle).
