## 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

Nested Class Summary

Nested classes/interfaces inherited from class jrobots.simulation.simulationObjects.Pilot
`Pilot.DropperCommand, Pilot.LauncherAmmunition`

Field Summary

Fields inherited from class jrobots.simulation.simulationObjects.Pilot
`DOWN, LEFT, RIGHT, UP`

Fields inherited from class jrobots.simulation.simulationObjects.AbstractPilot
`memoryConsumption`

Constructor Summary
`YellowBelly()`

Method Summary
`protected void` | `actions()` Everytime the simulation has progressed, each `Pilot` may plan the next actions.
`protected void` | `init()` This method is called once if the bot is set into the arena and whenever the pilot needs to be reset.

Methods inherited from class jrobots.simulation.simulationObjects.JRobot2009
`addDebugArrow, addDebugCrosshair, addDebugLine, addDebugLine, getLastScan, getMaxArenaDiameter, getMaxBackwardVelocity, getMaxForwardVelocity, getMaxScanAperture, getMineReloadTime, getMissileReloadTime, getMissileSpeedMax, getOrientation, getPosition, getProjectileReloadTime, getProjectileSpeed, getScanInterval, getTankTrapReloadTime, getTimeOfDropperReloaded, getTimeOfLauncherReloaded, getVelocity, isScanFromNow, setAutopilot, setBodyColor, setDebugLines, setDebugText, setDropMineCommand, setDropTankTrapCommand, setLaunchMissileCommand, setLaunchProjectileCommand, setMissileTarget, setNameColor, setScanAperture, setScanDirection, setTurretColor`

Methods inherited from class jrobots.simulation.simulationObjects.Pilot
`getBodyColor, getEnergy, getHealth, getName, getNameColor, getTime, getTurretColor`

Methods inherited from class jrobots.simulation.simulationObjects.AbstractPilot
`clone`

Methods inherited from class java.lang.Object
`equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait`

Constructor Detail

### YellowBelly

    public YellowBelly()

Method Detail

### 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`