phetsims / forces-and-motion-basics

"Forces and Motion: Basics" is an educational simulation in HTML5, by PhET Interactive Simulations.
http://phet.colorado.edu/en/simulation/forces-and-motion-basics
GNU General Public License v3.0
7 stars 10 forks source link

Significant delay before being able to push again after a fallen position #180

Closed phet-steele closed 8 years ago

phet-steele commented 8 years ago

If the pusher enters his fallen position because max speed is reached, there is a significant amount of time before the pusher will "stand" again after an object dips back below max speed. @jessegreenberg Disclaimer: it makes sense to me that the pusher won't immediately stand again when he is still on screen (for various reasons); this issue deals with the pusher being off screen for awhile and an object being at max speed for a good handful of seconds.

This can be seen via two ways:

  1. Either make an object reach max speed, then grab and (immediately) release the object: famb01
  2. or, make an object reach max speed, then apply lots of friction: famb02

I'm thinking that in cases like the above, wouldn't it be better to be able to apply force right away? Each video above has a 3-4 second wait where an object is not at max speed but still cannot be pushed.

jessegreenberg commented 8 years ago

This is question for @ariel-phet since this is how the deployed version behaves. For the disclaimer:

Disclaimer: it makes sense to me that the pusher won't immediately stand again when he is still on screen (for various reasons)

I am not sure what those reasons are so maybe there is a purposeful delay even when the pusher is off screen.

phet-steele commented 8 years ago

@jessegreenberg In regards to the disclaimer, If any friction is applied to the object, then the object will immediately dip back below max speed. The pusher would, I assume, only be fallen for a frame or so in this case (which sure doesn't seem ideal to me) if there was no logic to keep the pusher fallen for a bit.

phet-steele commented 8 years ago

Actually this brings up a bigger issue I'll detail in a new issue and reference to this one shortly.

Edit: decided against referencing.

jessegreenberg commented 8 years ago

Ah, good point @phet-steele. So maybe if the pusher is off screen we should have no delay.

ariel-phet commented 8 years ago

Agreed, if the pusher is off screen there should be no delay

Also agreed that as @phet-steele show in https://github.com/phetsims/forces-and-motion-basics/issues/180#issue-145763985 if you grab the object and release you should be able to push on the object.

@jessegreenberg wouldn't a simple rule be that if the object is below max speed the pusher is always "available" in a sense. So for example an extreme case...

The object is a max speed, the pusher falls off, but there is a bit of friction acting, so the object quickly dips below max speed, the pusher is in the splits going off the screen, but if you use the slider the pusher just appears standing up again (and quickly falls off again if you push hard enough). I don't really see any reason for a delay, it seems the simple rule of just allowing the slider to be active as long as the object is below max speed would work. Do you see any issues there?

phet-steele commented 8 years ago

it seems the simple rule of just allowing the slider to be active as long as the object is below max speed would work. Do you see any issues there?

@jessegreenberg @ariel-phet I don't see any problems right away with this. As long as the sim NEVER grays half of the slider when friction > 0, I think this will be a decent change. Otherwise I'm thinking the sim will have an annoying "flicker" when the slider grays then immediately enables when dipping below max speed. So the "Motion" screen will always gray at max speed (since no friction), and the last two screens will only gray when friction is zero.

jessegreenberg commented 8 years ago

I don't really see any reason for a delay, it seems the simple rule of just allowing the slider to be active as long as the object is below max speed would work. Do you see any issues there?

It will be important to cancel the drag event on the pusher and the slider if the user is applying force. Otherwise, the pusher will stand up and fall down again very quickly while the user is still dragging. This would also fix the flickering gray slider mentioned by @phet-steele.

Otherwise, I can't think of any other issues.

jessegreenberg commented 8 years ago

34b0d0c295f97bfdefb4b8ee49c47f1269918022 related to this.

jessegreenberg commented 8 years ago

This is done in the commits above, marking status as pending testing for the next dev version.

phet-steele commented 8 years ago

@jessegreenberg the current fix has indeed broken the sim in the way I described over Skype and repeated here:

  1. Begin by applying force with friction enabled followed by pausing the sim.
  2. Step the sim right up to the point where the object reaches max speed, but not one step further.
  3. Due to the fix, whenever friction is > 0, sliders do not disable. So at this moment exactly when the pusher falls, force can still be applied. Do just that.
  4. The object will then indefinitely be moving with a continuous force applied (with of course no increase in speed).

famb07

ariel-phet commented 8 years ago

@jessegreenberg this is definitely a "Steele Special" so if it is not an easy fix, it does not need to be done for the redeploy. Someone would need to be very devious to recreate this situation

phet-steele commented 8 years ago

@ariel-phet I don't know, I don't find it too hard to believe a user would investigate the sim state just as max speed is reached. It wouldn't be much of a logical leap from there to apply more force.

ariel-phet commented 8 years ago

@phet-steele I am not saying to not fix the issue, I am saying to not fix it for the redeploy if it is a coding rat hole

phet-steele commented 8 years ago

@ariel-phet gotcha, I was thinking you were going to mothball this like you would a multitouch issue :smile:

ariel-phet commented 8 years ago

Nope, basically it will be a judegement call on the part of @jessegreenberg

phet-steele commented 8 years ago

Commit fixed it, thank @jessegreenberg. I don't see other problems at the moment so closing.