Hi,
When I first saw a new Equal implementation for float, vectors and rotators using a new error tolerance parameter (NearlyEqual node like), i was surprised and I though “Great, I can now use this out of the box, probably running faster than my little custom function used to compare 2 rotators!”.
So I replaced my nodes in blueprints to use the new Equal node for Rotators and just putting the same error tolerance I’ve choosen for my specific case, which is indeed quite small: 0.000001
Unfortunately, the results were not the expected ones. My case is pretty simple: some component in the scene is aiming at another one and, at some point (when current aiming rotator is nearly equal to target rotator, whis is given by FindLookAtRotation) then I start some Event.
Here was my custom function used to check if 2 rotators are nearly equals:
As you can see, I was comparing each element of directions vectors from the first rotator against elements of the other one.
I’m not saying that is the most performant way to do that but it works.
As I said, with UE46 I’ve replaced the calls of this function with calls to new Equal Node with my error tolerance.
With the new one, the aiming component never enter, in a consistent way, to the state in wich its supposed to enter when both rotators are nearly equals. Either the error tolerance used in the new node is not really the one used for Rotators, I mean not at the exact same precision given in the input pin, which can be the reason why I’m saying “consistent” above, either something maybe wrong in the new Equal Node logic used for Rotators.
After that I’ve choosed to reuse my function but a bit updated.
This time, the function uses itself the new Equal node but against direction vectors, directly.
Already a lot better than the first version but this time, I have the expected behavior (same results as the first version), so this time it’s working.
So, can we conclude that the new Equal method is not really working for Rotators with quite small error tolerance like 0.000001 ?