-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a range for Score.targetXProperty #192
Comments
After some more investigation, it looks like this could benefit from having a dynamic range, just like in phetsims/gravity-force-lab#172. This is because the range is based on the current zoom (in view coords). I will investigate supporting this and report back. |
In the above commits I added a range to the In general this is an excellent improvement for studio. Another bonus we got was a behavior change where now the score target won't get "lost" off to the right of the screen when you zoom out, move it far away from the cannon, and then zoom back in. I set it up to clamp back within the draggable area of the score. @arouinfar would you please review these two pieces.
Let me know what you think! |
As a note, @samreid, @chrisklus @zepumph all discussed the changes to NumberProperty. We noticed that when updating the rangeProperty, you need to make sure the current value of the Property is within that range otherwise you will error out when changing the range. In PM this meant adding this line before setting the range:
We thought about having an option in NumberProperty, like // if false, error out, otherwise, when the range Property changes the value,
clampValueOnRangeChange: false but didn't feel like it was perfectly in line with how axon Propeties tend to work, and fail validation. It felt too graceful. Also, what is the difference between that, and just clamping on No action steps here, just a note of a review discussion. |
Note it is from the downstream sim. @arouinfar this issue is still assigned to you to just discuss the last part of #192 (comment). |
Behavior's looking great!
I think this is looking good in studio. I would not feature the |
That sounds like a great plan. I added a checkbox to your comment in #219. Closing |
Ooops, I still see a checkbox for me to investigate. |
This is easily reproducible.
The state wrapper will try to set the NumberProperty before its range has been updated to the new, larger I'm unsure how to handle this. Perhaps I will bring it to the other PhET-iO devs to see. |
The state setting bug was fixed by treating the range and value of a NumberPropertyIO as one atomic operation during setValue of the state set. This is now fixed and can be closed. |
I wonder if work over in phetsims/axon#274 has changed how I should implement this. Perhaps it would be better for this Property to be nested underneath the NumberProperty. |
The |
@zepumph when reviewing the sim in studio for #244, I saw some odd behavior with Twice now, I've seen the current value of We'd also like to remove the slider from studio interface for |
Good find. Because the range is based on the modelViewTransform (in the view), but is created in the model (before the view is created), we need a bogus initial value to fill the range to start. I made this [-100,100]. This is not ideal, but wasn't buggy expect that I wasn't re-calculating based on the transform on reset. Above fixes this because it recalculates the range on reset. Please review. |
I haven't been able to reproduce in master, so closing. |
No description provided.
The text was updated successfully, but these errors were encountered: