You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Today if a door is open even a little, it is considered "open". This is annoying when working with doors since scripts like the following don't work:
open the "test door"
wait until the "test door" is open
Describe the solution you'd like
It might be better if "open" and "closed" were separate states, meaning both return false if the door is opening or closing. It also might be nice if there was a property representing the door's "State", i.e. is it open, opening, closed or closing?
The documentation for door handler could also be improved as it doesn't provide many examples or warn you of the above behavior.
Describe alternatives you've considered
The Door Ratio can be used to wait until a test door is fully open, though this isn't as intuitive.
Additional context
Today there's only one property for "Open", which is why "open" and "closed" must be mutually exclusive. The fix here is likely to separate those two properties. Thankfully only a couple block handlers (door, parachute) use the Open property, so seems doable. Perhaps we need a new property to represent "state" (or maybe "mode") to represent the door state?
The text was updated successfully, but these errors were encountered:
door states: Opening, Open(ed), Closing, Closed
however, states Opening and Closing are not always proceeding towards Open or Closed (respectively).
if a door loses power (or is scripted to lose or not have power) while it is in states Opening or Closing, the animation locks, and the end-state is never advanced to.
Is your feature request related to a problem? Please describe.
Today if a door is open even a little, it is considered "open". This is annoying when working with doors since scripts like the following don't work:
Describe the solution you'd like
It might be better if "open" and "closed" were separate states, meaning both return false if the door is opening or closing. It also might be nice if there was a property representing the door's "State", i.e. is it open, opening, closed or closing?
The documentation for door handler could also be improved as it doesn't provide many examples or warn you of the above behavior.
Describe alternatives you've considered
The Door Ratio can be used to wait until a test door is fully open, though this isn't as intuitive.
Additional context
Today there's only one property for "Open", which is why "open" and "closed" must be mutually exclusive. The fix here is likely to separate those two properties. Thankfully only a couple block handlers (door, parachute) use the Open property, so seems doable. Perhaps we need a new property to represent "state" (or maybe "mode") to represent the door state?
The text was updated successfully, but these errors were encountered: