################################################################# Remaining Work ####################################### • When dropping skater vertically onto horizontal track: - sometimes he stops entirely - sometimes he has some horizontal velocity - it seems like if you just drop him from a little ways up (~1/4 inch on screen) his horizontal velocity is actually bigger than when you drop him from higher up. o I searched briefly for the cause of this, but couldn’t isolate it. • Sometimes the skater can get stuck in the track when crashing into it with enough speed (this may have been a problem in previous versions as well). See also Keller's document. 2. When the user releases the skater partway into the track, the skater gets stuck. Fix this (if easy). Okay to not conserve energy right on release. 6. performance problem after lots of runs. 9. Skater sometimes falls beneath the ground and zooms out to the side. Issue: Control points can no longer be dragged below ground. Mouse and control point can become separated from each other, I estimate 30-45 minutes to fix, should I? The spline definition allows the spline to go below ground even if all control points are above ground. Future versions should allow plotting time series data without recording the entire history, and should put the record & playback buttons on the time series panel only. On a double-potential well where the skater slightly leaves the track, sometimes he attaches to the wrong side of the track. After going to space, then dragging the gravity slider to some nonzero value, the floor is invisible. 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. Running multiple tests (in sequence, not in parallel) has performance problems. Zoom in/out buttons are backwards for the energy vs position plot. - when you zoom out grid does not cover entire area. - when you are recording and make changes to the PE definition line, and then playback... playback does not capture those changes but the graph shows those changes in PE. - when you do have negative PE b/c you change the PE def line ... the zoom out does not scale itself to have this negative PE on scale. - When resetting after zooming out, and adding a grid: (see screen shot) Grid still, pie chart still on, mountains not redrawn correctly. (Mountains redrawing incorrectly is NOT reproducible). What do we want reset to do? (Reset all?) - for energy vs position ... same comment as above for dealing with changes in PE def line ... cannot get negative potentials to be on scale. - Recording path ... got in mode where BOGGED down even though cleared all points and cleared graph. It wasn't actually clearing something. Eventually froze. - Another thing I was wondering was if the dots had a fixed time spacing, and if so what was it. - the +/- zoom on the energy vs position seem to work opposite of what I would expect (the + zooms you out so you see more of the axis). ################################################################# Low Priority or Deprecated ####################################### 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... 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. -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. -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?) 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 postponed 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.