I’m new to UE4 and was going through the character movement tutorial by to familiarize myself with blueprint visual scripting. I noticed that to invert a Boolean value, the guide generally used a “!= true” block, as opposed to the “not” block. Is there any difference between these two blocks in regard to functionality?
Another time it takes a boolean value and passes it through an “== true” block (pictured below) before passing the output value, which seems unnecessary, as the output will always be identical to the input “Is Prone”. Is there any reason for this as opposed to passing the original boolean value?
I’m confused because I can’t imagine that the guide would have unnecessary complexity or unnecessary blocks, but I also don’t understand why “!= true” is used over “not” or why “== true” is used at all. Thanks!
The “!=” & “==” are used to compare two values, where as “Not” is used to flip the boolean value. In the first screenshot, I believe they’re not trying to invert the value, but rather just checking if the value of “Is Crouching” is not equal to True. So if the character is not Crouching, then it can enter the animation transition.
You can actually check out this video to understand what each boolean node does:
Furthermore, that channel has information on most blueprint nodes in Unreal. A lot more so than what you can find in the documentation.
Hello there, (disclaimer - This is just my understanding, I could be wrong)
So as Stormrage256 said the difference is between comparison and logic operations. So taking the == as an example. If you were to write in code that myVariable = 1, then you are setting the value of myVariable to 1 (in blueprints you’d use the set node to set the value). However, if you wrote myVariable == 1, you are asking if the value of myVariable is 1 and you need to put a condition before it like “if” and some resulting code after it to do something. There are a bunch of comparison operators for example, less than, greater than, less than or equal to…etc. == is also a comparison.
The != is the same. It’s comparing the value to something (so if myVariable is not equal to myOtherVariable do something). In this case because if crouching is a bool and the second pin of the != is ticked it’s saying, If the value of the bool (Is Crouching) is not set to true, then you can enter the transition (IF IsCrouching != True enter tranistion). So the if because this is a transition so it’s asking the question, and the result of the comparison determines whether or not it will enter the transition.
NOT, is a logic operator, along with OR, AND etc. I understand them as acting like gates allowing things through or not based on the inputs. So In the second example the AND is saying both of these things must be true to enter the transition. If one of them was false, the AND would evaluate false, and you couldn’t enter the transition. If you were to switch that with an OR for example, as long as one of them was true, then it would enter the transition. A NOT would output the inverse of the value you give it. So, if IsCrouching was true, a NOT would output the value false (it wouldn’t actually set it though, it would just output the opposite value) and vice versa. It would just be saying If the value of IsCrouching is one value, tell me the opposite (but don’t actually store that) and enter the transition. Where what you actually want to do is say only enter the tranistion if IsCrouching is definitely not true.
Sorry if that’s a bit rambly and difficult to understand, but hopefully it helps.
Here’s the thing - inverting the value and checking if the value of “Is Crouching” is not equal to True have the same effect for Boolean values:
[TABLE=“border: 1, cellpadding: 1, width: 1000”]
Is Crouching
Block Used
Code Expression
Substitution
Output
Is Original Value Changed
True
NOT
!(Is Crouching)
!(True)
False
No
True
!=True
(Is Crouching) != True
(True) != True
False
No
[TABLE="border: 1, cellpadding: 1, width: 1000"]
Is Crouching
Block Used
Code Expression
Substitution
Output
Is Original Value Changed
False
NOT
!(Is Crouching)
!(False)
True
No
False
!=True
(Is Crouching) != True
(False) != True
True
No
The top chart represents when Is Crouching is True, and the bottom chart represents when Is Crouching is False. In each chart the middle row represents a “NOT” block and the bottom row represents a “!=True” block (and top row is of course column titles). For any given input, the output is the same regardless of whether a “NOT” block or a “!=True” block is used. To make absolutely sure, I tested both versions in UE4 and found that they did indeed have the same effect.
I believe that it will only enter the transition if the condition is true, where the condition is whatever Boolean value is passed into the Result block. Even with a “NOT” block it won’t just enter the transition automatically; it only will do so if the inverted value is True, because it is the output of the NOT block that would be connected to the result block. Testing confirms this.
I’m starting to think that the choice between “!=True” and “NOT” is purely personal preference. Stormrage256’s video and Kettlefish’s response both help me see that each might make more sense to someone viewing the code in different situations. And of course, the != block has further functionality when another variable or expression is used in the second socket instead of the True checkbox.
What I do not understand is the “== True” block on the second image. The first image it’s choosing between two blocks that both convert true to false and false to true, but ultimately a block is needed, it’s just a question of which one. The “== True” block in the second picture is totally unnecessary though, the code works exactly the same with or without it, since an input of true always outputs true and an input of false always outputs false. So why would it be there at all?
Yea, to some extent, it is a personal preference. For example, I generally end up using != and == a lot more than Not since it comes more natural to me and find it easier to process immediately while looking at a blueprint graph, especially when there are lots of operations involved. I suppose the opposite could be just as true for some.
