Control Mouse Cursor with Gamepad Joystick

Hi all.

Quick question (I hope).

I have a TPS where I’m trying to make the game fully playable on mouse/keyboard or solely on a gamepad. Theres a part where theres a CURSOR during game play. The mouse works fine, but when I’m using the gamepad, the right stick doesn’t control the cursor. In crosshair mode, both mouse and stick work fine… but in cursor mode only the mouse will move it around.

Is there a way in blueprints to force the stick to do the same movements as the mouse on a cursor? OR make the stick emulate the mouse somehow?

Thanks in advance for any help.

can anyone help?

Need to know this myself.

To be honest, this seems like a failure of design. You shouldn’t ever be asking the player on a gamepad to be pointing and selecting with a cursor. Its a very difficult thing to do.

Instead you should be removing that layer, and designing the functions to work with Axis input. Maybe if you can clarify exactly what it is the cursor is needed for we can help you see a better way to do it.

I imagine he’s talking about something like Destiny did with their UI, which works wonderfully.

For example:
7b9d05bc0ea25a8e1c42b25ab77c2b19c0136ead.jpeg

Tesla Dev told me a while back this was going to be implemented in 4.8, but it doesn’t look like it made it in. Hopefully I’m wrong and I’ve just not found it yet.

Yea that’s exactly what I’m talking about. I couldn’t figure out how to move the mouse cursor, so I abandoned that and am working on moving a widget instead. I’ll post my solution when I get it working halfway decent

Yep. I tried sorting this out a few months back and, ultimately, just decided to wait for Epic to implement something that should have been there already. It’s not a pressing issue for me, so I’ll continue to wait on them instead of trying to reinvent the wheel.

Your solution is to move the widget and trigger events when widgets overlap, then? I see your post here - very curious to see how this works out for you.

Got the widget moving and I’m working on the trigger event. I’ll be posting it when I get it finished.

Hey Mcgillchris, any updates?

Na not yet, I couldn’t figure out how to cast the widget position in a way that updated as I changed the position. I got discouraged by it so I spent a little while working on my 3d models to give myself a break. I will be starting back on it in an hour or two. I’ll post what I have so far here. I don’t really have much experience with casting so the more eyes on it the better.

This is how I’m moving the widget (coming off of tick on my character):

For the cast, I created a sphere collision around the particle effect (magic actor) I am trying to interact with. It is called “mouse collision”. This is coming off of the event tick on the “magic actor”. I realize that it will always return true at the moment because I was testing my print to make sure I had a good check. Right now it casts from a single location that does not update as I move the cursor.

I’ve been thinking about this problem a good bit, myself. Definitely not an easy solve. Just to make sure we’re on the same page, you have some 2D screenspace widgets or buttons that you want to ‘click’ with your 2d screenspace cursor widget? Is that correct or are you trying to use your 2d cursor widget to click on objects in world space?

Either could work. I currently have a 2d screenspace widget that I’m just trying to do an overlap check on with a collision sphere in world space. Which, in order to do, I need to cast a ray from screenspace to world space, which is a function built into the actual mouse cursor, but I’m having trouble replicating it.

I’ve also looked a little at trying to “click” a 2d screenspace widget but I haven’t figured that out either. I couldn’t figure out any way to do an overlap or collision with the 2d widget. The click is def something I will need for my menu system. But I’ve got a magic system I’m working on that can work either way.

Ok, I’m with you and I think you’re on the right track. I’ve been focusing on 2D to 2D scenario which, as you say, is problematic when you want to do some kind of widget overlap detection or ‘on hovered’/‘on released’/etc. button visual feedback. For the moment, I’m using this method that allows d-pad and thumbstick input to jump from button to button and solves most of those issues. It’s not perfect but it works and didn’t take much time to implement.

That said, your 2D to 3D problem I may be able to help with. Two possibilities pop into my head and I’m half thinking out loud as I type this. First, as you’re doing in the last screenshot - running a line trace from the camera manager (so you can use its forward vector) but offset the position from which it starts by an amount equal to your 2D cursor’s screenspace position. You’re using the Start Trace X and Start Trace Y, which I’m not familiar with, but seems to be where your problem is from what you describe. When you PIE, do the line trace debug lines come from the center of the screen?

Alternatively, have you explored the ‘project’/‘deproject’ nodes? They are only available within a HUD class BP, but might be cleaner. You could simplify the starting point of your line trace to just the camera manager (i.e. center of screen without any offset) and then set the line trace end point to the 3D coordinates that come from the result of the cursor deprojection. The ray trace wouldn’t be orthogonal to the screen but that shouldn’t matter.

Is this what you were talking about for camera manager? What should I set as the end location to get it to project directly from the camera view out into space? Obviously it doesn’t need to be infinite.

I believe that could work, as well, but can’t be sure as I haven’t ever tried it that way. Something like this is what I had in mind…

This gives you a line trace starting from the center of the screen and going perfectly straight out into the game world 1,000,000 units. Play around with this a bit with the debug lines turned on and it will make better sense than I can explain. Then the question just becomes how to offset the starting line trace position. In this example, you’d need to add some offset logic after the ‘get actor location’ node.

Just realized something. I don’t need to change the trace start position, all I need to change is the trace end position. It doesn’t matter where it starts from.

Yep, that’s what I was saying with the deprojection method. Just be aware that you may have instances where the ray trace hits an obstruction before reaching the cursor target since it’s following a different vector than the player’s eye is.

Over here https://answers.unrealengine.com/questions/259606/how-to-move-widget-with-gamepad-or-better-ideas.html a guy is suggesting to just use Rama’s plugin. Have you tried that?

EDIT: tried to install and it isn’t compatible with my version of the engine, could be the plugin is outdated or it could be because I’m on a mac. So back to the drawing board.