Class YellowBelly

java.lang.Object
  jrobots.simulation.simulationObjects.AbstractPilot
      jrobots.simulation.simulationObjects.Pilot
          jrobots.simulation.simulationObjects.JRobot2009
              YellowBelly

All Implemented Interfaces:

java.io.Serializable

public class YellowBelly
extends jrobots.simulation.simulationObjects.JRobot2009

One of the simple Bots. And: The first Bot to lay mines.

Driving states

1. full speed at momentary orientation
2. latest valid scan value exists -> full backward speed to the direction of this scan value

Scan states

1. 360° search
2. latest valid scan value exists -> -90° to +90° of momentary orientation (assumes there is no panzer behind), from left to right. Scan aperture is adjusted to scan/shoot reload ratio. A bit more time is applied to the scanning than would be allowed by the ratio, in order to be able to shoot right after the successful scan.

Shoot states

1. No valid scan value -> don't shoot
2. "Fresh" scan value -> shoot right on spot, employ some derivation, as this Pilot is not assumed to narrow up its scan aperture.

Mine states

1. Whenever mine is reloaded -> lay mine
2. Mine position is stored but not used yet.

Since:

2008, 2009 - The first Bot spamming tank traps.

See Also:

Serialized Form

YellowBelly

public YellowBelly()

actions

protected void actions()

Description copied from class: jrobots.simulation.simulationObjects.JRobot2009

Everytime the simulation has progressed, each Pilot may plan the next actions. This is done through execution of this method.

Knowledge a Pilot has of the momentary simulation state is limited to what its Panzer's sensors may display. Access to the Panzer's sensor states is best done via the following methods:

• Moving: getPosition, getOrientation, getVelocity, getTime
• Scanning: getLastScanResult, isScanFromNow, isScannerUpdated, getTimeOfLastScan, getScanInterval
• Shooting: getTimeOfLastShot, getProjectileSpeed

A Pilot is able to steer its Panzer. The Panzer will follow those decisions until the Pilot canges its commands. Decisions are made by calling the following routines:

• Driving: setAutopilot, setTrackspeedLeft, setTrackspeedRight
• Scanning: setScanDirection, setScanAperture
• Shooting: setCannonCommand
• Debug: setDebugText, setDebugLines

You may add fields as you like to keep some state through the coarse of the simulation run. But remember not to waste memory, as the framework checks the size of your Pilot's state and may refuse to permit it to the arena.
You can always use static fields, but that makes the timeline slider obsolete for debugging.

Also keep track of the computing time you spend, because if you exeed a certain treshold, the framework may exert punishment upon your Pilot. If you try to not waste time, there shouldn't be a problem, however.
If your Pilot causes an exception, there will also be some detriment, but a new instance of your Pilot will be established, so you may be able to carry on.

Package visibility. Pilots with a partial programming interface may want to have an invisible partial implementation of actions().

Specified by:

actions in class jrobots.simulation.simulationObjects.JRobot2009

init

protected void init()

Description copied from class: Pilot

This method is called once if the bot is set into the arena and whenever the pilot needs to be reset.

Please remember: If you overwrite this routine, call super.init().

Overrides:

init in class Pilot