Thread history

I think the super samples should all be rewritten so they are about the same level of complexity, like the original samples (newer samples vary a bit more certain reasons). Also with fully detailed comments not only on what something does, but why it does it. Many of these concepts would make absolutely not sense to newer coders and so wouldn't be as helpful if we don't explain why they are done.

Bad comment (assuming it has one, and is half this long)

// random number to add variance to movement, makes it harder to hit with bullets

Good comment

/* Adds a random amount of extra time before the robot will change direction, this makes it more difficult for targeting to predict where it will be when it does. */

Also the code should be EXPANDED for clarity. Sure you can cram that entire algorithm onto a single line, but the goal isn't a nanobot here, its for teaching purposes. Even beginner programmers can cram it all onto a single line, but even my head swims trying to piece through parenthesis insanity.

Bad Code (taken from super crazy, so my fault)

// Distance we want to scan from middle of enemy to either side
double extraTurn = Math.min(Math.atan(baseScanSpan / distance), Math.PI/4.0);
setTurnRadarRightRadians(radarTurn + (radarTurn < 0 ? -extraTurn : extraTurn));

Good Code

/* Deterime how far to scan to each side of the enemy, to get the radar 'arc' */
double extraTurn = Math.atan(baseScanSpan / distance);
/* Limit it to the maximum the radar can turn in a single round, so we can stay locked on. */
if(extraTurn > Math.PI/4.0)
    extraTurn = Math.PI/4.0;
/*
 * The radar ends on a certain side of the robot, so the radarTurn variable determines
 * the direction from where it ended towards where the enemy is now, taking advantage of
 * this we can just turn the radar even further in that direction for a cheap radar arc.
 */
if(radarTurn < 0)
    radarTurn = radarTurn - extraTurn;
else
    radarTurn = radarTurn + extraTurn;
setTurnRadarRightRadians(radarTurn);

On that topic. Also need to break out of our need to write 'strong' robots, and instead focus on writing decent robots that are well explained and easy to understand. Easy to understand does not mean using only elementary programming (if, for, else) but rather structuring the tried and true algorithms into their simpler forms, even if this reduces their overall performance or effectiveness. Such as VCS vs GF List. Symbolic PM vs Bruteforce PM. Surfing vs Gun Heat based Head-on dodging. Etc.

They are suppose to be a decent step up from samples, they shouldn't force them entirely from their comfort zone into one made of razor blades.