As the image above, such event is fired even though ‘Axis Value’ is zero ie the associated input is not pressed/touched. I wonder why UE4 fire the event even if technically, the input device is not doing anything. The benefits of firing the event only when axis is not zero are many:-
Performance improvement!
Easier to debug.
Why even fire in the first place? I think 99.9% of the time, it is not needed.
Just in case if there are specific uses for such behavior to continue, one can just add a BP node to Enable/Disable this behavior. Even better, the current behavior can be left on by default.
I’ve used it a couple of times to detect when specific input binding is no longer in use. Seemed like a good enough solution for what I needed. Something along the lines of:
This may qualify as 0.01%, though. Not encouraging anyone to write sloppy code but the performance hit is negligible at best.
edit: remember now - I used it to transition from manual state to idle camera control state. I was throwing a tantrum and refused to use bools for everything as they were piling up on me.
Input is always ticked and it’s quite a core engine ‘thang’, so I wouldn’t expect to see this changed (also 99% of the time, you do want to know when it’s zero). Even if an input is zero, it’s still being polled.
A simple branch with an if == 0.0 check is the way around it. Alternatively, you can just use ‘Get Axis Value’ for that frame when you need to.
Yes of course I can add a BP node to check value > 0 and then only execute. But the thing is, it is not ‘clean’ - I dont want to see it being cluttered with what should be unnecessary if branches. Secondly it is performance - UE4 has indeed fired this event, and then aborted (by the if branch) which is quite wasteful, dont you think?
And also as I mentioned above, the debugging is easier. I want to check the code flow only when there is an axis value - 0 simply defeats the purpose. I really think the code changes inside UE4 is minimal, but I do now where to check for that. And also, it is very reasonable request (+ minor code changes).
Even though the UE4 keep polling for all input binding events, the execution point doesn’t need to go to BP - it stops right in the UE4 internal which is perfectly fine.
Not really, as you will gain nor lose zero measurable performance with an extra branch. If you somehow add a checkbox to the node in C++, you still have a branch (if) anyway - so it makes no difference to performance whichever way you do it. One way or the other, you have to do a comparison op.
Oddly enough, it’s a bigger change than you’d think. Add the branch, collapse it to a macro and put the break point after the macro. ez-pz.
It the check happened within the C++ UE4 engine, there is no need to making extra call to BP (which is not fast). I am not sure how fast is the underlying C++ code calling the BP node, but if it can be avoided then it is free performance with better looking BP code. More so when there are hundreds of input binding being fired in every tick - if this is fully multi-threaded, then I would be pleased. Just imagine UE4 keep firing hundreds of events every time, whereas only a few are active at one given time.
Thanks. Btw I think this fall into minority cases… probably very small number. As for my case, I have none of the need for value equal to 0. If I ever need be, I will be happier for workaround - eg if I haven’t received any event within certain period of time… then …
&stc=1