I’m working on a door at the moment. Sounds pretty simple, I know. I’m testing out as many elements of this blueprint as possible. Currently, I have a door which you can pull/push (by scrolling down/up respectively). This works by using a float for the door relative rotation as shown here:
However, I’m trying to find out when my door is open or closed so that I can start playing some sounds (and other actions) depending on it’s state.
I’ve tried checking “IF Door Rotation is equal to 0”, and if so, setting a bool to true, however this doesn’t seem to work well as (according to my printed string), the door will flicker between true and false while open and not moving, and stay true while closed.
So, I’m a little stuck. I’m trying to figure out a way that I can know when the door is first opened, closed and (if possible) if it’s currently rotating/moving. This way, I’m able to create events for these states and start playing sounds, etc.
The idea to see if the rotation is equal to zero is correct in principle, you just need to take into account the inherent imprecision of floats. The chance that the value ends up at exactly zero is in fact very slim. So what you could do is to check if it’s close to zero, say less than 1 and greater than -1. That should give you more stable and reliable results.
Thanks for the help. This is something I’ve tried, but didn’t seem to work. I’ve just tried it again and this time with -2/2 as my ‘is closed’ region. I’m getting these results:
As you’ll notice, while open, the print string is reporting it flickers extremely quickly between true/false whenever the door is open, but stays true while shut.
Isn’t that simply because you have two instances of the door, one closed and one open, and they just have to take turns printing out their respective messages?
This seems like a very unique issue and if possible, would you mind sending me the blueprint and the door asset you are testing this on so I can take a look at it to dissect it and see what is going on?
Which obviously meant no input was being accepted. I changed this to Player 0, however now only the most recently placed version of this blueprint (within the level) actually works.
I know this is different to the original question, but figured I’d ask now before making a whole new question.
Turns out it was printing incorrectly because I had two of the same blueprint printing, but it’s in fact working as intended. Silly me!
I do actually have another slight issue when it comes to putting two versions of this blueprint (or more) down. It only seems to accept input on the most recently placed.
Not sure sending the blueprint will help much, as all the assets would be missing.
What you are saying is now that you have changed this value in your blueprint, compiled, and saved. The versions you currently had that were broken are still broken, but dragging in a new door it is fixed?
Not really, everything works on a single door blueprint as expected, however if I drag out any more copies of this blueprint into the level, only the most recently added/created copy actually works, the rest seem to ignore input entirely.
