'Set Ignore Look Input' delayed response

[Tieske909090]

So I have the following thing set up:

I am using an adjusted version of the FPS template, combined with the top-down template for moving the player.
This is what my ‘right-click’ is doing:

• When I right-click, and the mouse is not moved (less than 10 pixels) before releasing, then a ‘Get hit result’ is run to move the player to the location.
• When I right-click, and the mouse is moved (more than 10 pixels), a ‘view mode’ is started, and moving the mouse rotates the camera.
• When the right mouse button is released, the ‘view mode’ is disabled again, setting the static camera for the mouse movement.

Picture below shows that ‘right click pressed’ is set to true when the button is pressed, and both ‘right click pressed’ and ‘view mode’ are set to false when the mouse button is released.

The picture below shows that ‘Ignore look input’ is set by using this boolean for ‘view mode’.

Then, when ‘right click pressed’ is set to true, and ‘view mode’ to false, the offset of the cursor is calculated. If this exceeds 10 pixels, then ‘view mode’ is set to true, setting the parameter ‘New Look Input’ to false (see second image), therefore allowing ‘look input’.

However, the problem is, that whenever the parameter ‘New Look Input’ is set to false, that it takes a long time (1-5 seconds), before a movement of the mouse actually moves the camera. I have checked with debug, and the lines show that ‘New look input’ is set to false instantly. Also the mouse cursor is disabled instantly. Furthermore, when setting ‘New Look Input’ to true, it seems to be instantaneous.

So how come that it takes time for the camera to accept ‘Look input’, but that the mouse cursor (function after the look input function) is disabled instantly?

I hope I am somewhat clear about the problem, and if more information is needed, let me know.

P.S.: The rest of the blueprint can be seen below:

[PenguinTD]

okay, I can’t see what SetIgnoreNewLook function looks like, so I can’t really tell what might be causing the lag.
But I do see that in last screencap, there is a weird redline right for the branch node.
See, you are using the result from a different execution line, which might or might not occur in the order you’d like it to happen.
So I’d fix that immediately, in ghost busters, you don’t cross beams, in UE4, you should never rely on results from another execution line.
By clean up any of that, and then try to see where the actual problem is.

[Tieske909090]

I have deleted the branch out (ray casting), as this is not the cause of the problem.
Nothing else has been changed, except for the layout.

• So from the event tick, the ‘false’ branch of ‘view mode’ is running all the time.
• Then when a right-click is found, the blueprint checks the distance between the original mouseclick, and the current mouse position (in pixels).
• If this amount exceeds 10 pixels, then the ‘view mode’ is set to ‘true’.
• This results in ‘Set ignore look input’ to be set to false, therefore movement of the mouse should move the camera.

I will also post a video of the problem soon.

[Tieske909090]

Okay I found a solution (as I still dont really know what the problem was):

But this seems to work

[PenguinTD]

took me a while to spot the problem
see image annotation.

[PenguinTD]

This is such a classic example that most new to UE4 would go crazy when run into this.(I think this graph is wiki worthy for new to intermediate level UE4 to learn from.)
so what’s possible solution then, first of course you need to get rid of disable click event since your whole logic depends on those event to happen.

But, the MouseXYClick value update however can not be solved when using tick, as tick event run independently regardless of your other event, so this type of branching problem need more careful solution.
What then assuming you still need to check for mouse moved range after click? first to come up is just using MouseX and MouseY axis event to check pixel range.
So same thing with tick could happen if you happen to click and drag at the same time, but you reduced the chance to cause this bug. Not really satisfied since it’s not guaranteed.

Now since we know click and drag can happened at the same time, how to avoid it trigger like in this graph(imagine event click is replaced with MouseX and MouseY)?
We can :

1. have a gate right after event MouseX and MouseY that use right click pressed/release as open/close event
2. set MouseXYClick right before the execution line enter the gate
   So we make sure that what ever runiing behind the gate is guaranteed to get latest MouseXYClick position even if you click and dragged(really easy to happen if you have a high dpi mouse).
3. we can then have a branch later after gate that determined if we choose to update view mode or not.

Here is my proposed solution, I encourage anyone visited this thread to give it a go and see if you can come up with a better solution and post here.

I really think this is wiki worthy stuff for people to think about, so maybe we have a proper before and after, with multiple solution and put a wiki page for future reference.

[Tieske909090]

PenguinTD thank you for the help!

So I have cleaned up my code a little bit, and used the gate.

Screenshots of the blueprint (I will not include the actual raycast, as it is a little bit messy at this moment):

The function ‘SetInputViews’:

Everything appears to work as I want it to for the time

If you need anything from me for the wiki page, let me know as I’m happy to help.

[PenguinTD]

Like I said before, you have to be careful about turning off click event in this case, if it’s not really necessary, try not to include it.
If you want to disable other click events(left and middle,etc) to run their corresponding event, use view mode with branch after their event instead of turning it off.

also, if you’d like to contribute, you can duplicate your current project, try to trim it down as much as possible.(like all using default assets)
Remove most content in “Saved” folder as it’s the biggest one with redundant backup of all blueprints/etc.
Then we can just use images on this thread in wiki page and let people play around with the project files.

[anonymous_user_e11ff324]

I’am also trying to achieve a similar system for camera movement. If press and hold the right mouse button I can move the camera, if I release it I can normally move the mouse and interact with the game world / HUD.
However, the mouse is blocked at the edges of the screen and therefore prevents all other camera movement. How can I prevent this?

[DrHobo]

@Leandros;161403

I’am also trying to achieve a similar system for camera movement. If press and hold the right mouse button I can move the camera, if I release it I can normally move the mouse and interact with the game world / HUD.
However, the mouse is blocked at the edges of the screen and therefore prevents all other camera movement. How can I prevent this?

I’m experimenting the same thing in C++. I had a solution working under 4.4 and now with 4.5, I can’t anymore.

[Edit] It may still be the case of the left-click game enabling: Bug with mouse control of game in editor? - Programming & Scripting - Epic Developer Community Forums
If I press down the right mouse-button to hide the mouse cursor and get rotation control AND left-click to enable the mouse cursor in the game, then the right-button rotation works a full 360 degrees and is not blocked by the edges.

[popawheelie]

Hello, I don’t know if this will help for your situation, I am building a interaction UI and it uses the XY coordinates to drive a slider and need to ignore mouse input. I found “Set Ignore Input” to be not useful because of the delay.

The easiest way I found is to set a branch on the Input Axis to turn off Add controller Yaw/ Pitch. Then set a bool when you need to turn off mouse Input.