#################################################################
Remaining Work
#######################################

The performance degrades significantly after 10 minutes or so.

On a double-potential well where the skater slightly leaves the track, sometimes he attaches to the wrong side of the track.

If you zoom out, then change locale, the background refits to the zoomed-out screen. (so that a subsequent zoom-in looks weird).
        When I tried fixing this by always rescaling the background, it causes 2 problems:
        1. The house on earth becomes huge.
        2. Performance degrades on zoom in/out.

Out of memory error after running 10+minutes.

Running multiple tests (in sequence, not in parallel) has performance problems.

The bar graph doesn't have a zoom, should there be one?

#################################################################
Low Priority or Deprecated
#######################################
User-selectable skater/vehicle graphics.

Crashing skater?

add spanish

Add game-ish modes to sk8r application
	. 2-skater mode
	. Grab the apple?
	. Jump the buses?

Another bug ...
The sim was running in the background for the last hour or so, and
now when I bring it to the foreground I can't get it to redraw it's
screen .. it's all white until I mouse over sections, but even then
it's erratic whether it will redraw or not.
        Is this problem resolved?

Bug: The dragging constraints are not skater-centric; after dragging against a constraint,
the mouse is no longer directly over the skater.

One question I have is were we going to have a mystery planet where 
they would have to figure out the acceleration due to gravity?
With a Mystery Planet, we'd want to remove other features from the simulation (readout of gravity on the slider), etc.
Maybe we shouldn't implement this until we have decided on the activity, what the user should be able to do, what measurements she will be able to take, etc...

Jetpack is shown in an incorrect position when the character is on the track.

-If curvature of the track is too great (not gradual enough) the skater
cannot move passed
the vertex and will bounce off of it.
        This only happens if it's not 'rollercoaster mode' and if the skater flys away from the track.
        
- slow motion button doesn't seem to work right
        Clarifying...
        
-If the skater goes off screen and the user is holding down an arrow key
when they click "bring back the skater" or "return skater" the skater will return and
immediately start thrusting in that direction regardless of what arrow keys are or are not
being pushed.  The only way to fix this is to reset the entire simulation.
        We couldn't reproduce this.
        
After some combination of recording and playback, the track graphic becomes dissociated from the skater.
        The skater will continue to traverse the path where the track used to be, even after it has been dragged.
        This solution is a bit of a hack.

Save/Load not working sometimes
        Could be: throwing an exception, "body.debug angles inconsistent"
        This may be fixed now; I was unable to reproduce the problem so I can't claim this with much certainty.

-When coefficient of friction is turned to maximum and there is a lot of
gravity (maximum) the skater falls through the track at the bottom point and
bounces around the bottom of the screen before shooting off in a random direction 
(his exact reaction varies each time).
        This problem is partially reduced.  Friction + Gravity + Track Curvature increases probability of getting this problem.
        
after record/playback/reset, then gravity in space, friction is not working
	This is correct behaivor.
	
Does BackgroundScreenNode depend on using same instance of floor graphic?
>>that's ok, we're reusing instance.

If left on and the yellow dots of the path record allowed to accumulate, it 
seems to cause tremendous lag in the program (maybe set a limit on how long it can be 
left on?)

Dropping from a height, sometimes the skater gets stuck in the ground
    I think we discussed this and decided it's okay to leave this.
    
Sometimes the skater gets stuck.
        Difficult to reproduce.
        Could try searching ahead a few steps to see if the skater will get stuck...

One run caused the skater to behave as if he had 0.001 mass (in space).  Couldn't reproduce this.

arrow keys in space made him vanish on one run...
        Couldn't Reproduce this.

These ideas are scratched indefinitely:
    I'm still leaning towards the world ending when he goes off one side or the
    other.  I can't see value in tracking his actions when we can't see him.  On
    top of that, we reset things when he is returned.  I think as soon as the
    return skater label appears, students realize they have fallen out of range
    and need to start again.
     >>Maybe we should pause the simulation when he moves off?
     >>Or maybe we should add walls?
     >>Or maybe we should have the camera follow him when he moves off?
      >>I think it would be confusing to have different physics based on whether the camera can see the skater.
      >>A popup that says "landed on grass"

Error with normal force computation:
    getNormalForce( double x, Body body )  in SplineMode is sometimes pulling the skater to the track.
    1. The skater sticks to the track when traveling in a loop at a speed that would never allow him to stay on the track.  He would crash on his head for sure.  I can create a loop where he falls off as he comes to the top, bounces off the track below and then sticks to the track above him again
            This picture shows him after he bounces on his head because he fell off the track as he was traveling to the left upside down.  He still has an upward velocity in this picture.  He will get to the track and stay on after this show.  He keeps repeating this path indefinitely.
    4. He should have at least 1/2mgr (where r is radius of curvature of track) worth of kinetic energy to be able to stick to it (when he is vertical). Right now his stickiness doesn't seem to be affected by the local r.