Widget interprets screen location different than expected

I have a tank, and I want the 3rd-person reticle to land at the expected impact point of the projectile. To do this I have a line trace coming out of the barrel that I take the impact point of, translate into screen space, and place the reticle at that location. However, this is not working correctly.

Note, this code is inside the HUD object and (currently) using the “Event Receive Draw HUD” node to execute, although I have used “Event Tick” in the past.

(Edit: the line trace is purely for debug purposes, just to see if the coordinates are where I want them to be, which they are)

As seen here, the drawn line lands at the correct position. However, when the reticle widget is placed at that same set of coordinates, it instead lands at the bottom right (the T shape on top of the first “25”). I also tried using “Project World Position to Widget Position” instead, which only moved both further to the bottom right, with the reticle barely visible:

Looking at various posts online, I also tried manipulating the vector with the following calculations, which placed it closer to where it should be, but ultimately still very wrong.

While I tried many versions of this expression, it is possible I missed out on one that is correct, so if there are any ideas to reorder the variables in a new way I am open to them. Finally, here is a picture of the widget BP itself.

1 Like

Hey @EpikAura99! I think I can get you moving in the right direction.

So here:

Notice you have your start screen X and Y as the current screen position. So that’s the exact middle of your screen. That’s your START point, and then the end you have “0,0.” because you have no input on the end X and Y-which is the top left corner of the screen. So that’s why it’s going up and to the corner.

I don’t see where you are getting the line trace and getting the impact point. Have you thought of using a 3D space Widget as part of the pawn and simply changing its location on tick to the impact point of the line trace?

I apologize, I was a bit unclear. My bad. The line trace is purely for debug purposes, to see if my coordinates were wrong. But the line trace is going exactly where I want it to. The widget moved by the “Set” command, however, is in the complete wrong place despite using the exact same coordinates. Here is a better picture where I have highlighted the problem widget in red, in the bottom right.

I would like it to be centered where the line endpoint is, but it is not. And subtracting half of the screen size does not fix it.

Forgot to mention, yes I tried a widget object but I could not get it to be only visible to this player, no matter how much I messed around with “Only Owner See” and ownership.

Ah, I think I get it now.

It kind of seems like it’s placing it with the origin (top left of the widget) being at that point instead of the center. Have you tried using a canvas instead of an overlay? Overlay is generally used for putting details on top of another widget, like a name or number value on a progress bar.

Try replacing that with a canvas and making it the appropriate size for the image (don’t use an overall screen size like here, make it the size OF the image) and see what happens!

I believe I did this correctly, but I am not sure. It had the same result as with the overlay. I’m not certain what you mean by ‘make the canvas the size of the image’, I didn’t see anywhere to adjust canvas size by pixel, unless you mean the “Transform” box. Am I correct in thinking that the circled menu does not affect the in-game behavior?

(The bottom “Set” just centers the reticle when no location is given. That part works fine.)

That box is what determines desired size, so yes it will affect in-game behavior. The setting you’re on now just means it will scale the canvas down to its contents, so that’s the correct setting!

Just asking, you did save the widget before trying it in-game, right?

And there was no change? It’s still down there on the ammo count?

What about checking player viewport relative “on project world to screen?”

Also I noticed a difference in the recent picture- the “Reticle image” vs “reticle box”. Make sure any connections are carried over, like you don’t accidentally use the wrong widget as the target! It happens to the best of us. :slight_smile:

Apologies for the delay. I just tried checking the “viewport relative” box and it also makes no difference, unfortunately. All the connections appear to be correct.

No worries!

I had a few additional questions though, mentioned above. Specifically

if you saved the widget each time before trying it in game,

whether there was no change and it is still down on the ammo count when using the canvas? ANY difference at all could be a clue.

Also is it possible you are drawing this widget somewhere else and the widget you’re trying to make isn’t appearing at all?

Here is where I make the widgets, as you can see the tester one (using a canvas) is the only one being set, the original one (using an overlay) would be a None reference even if it was used. This is in the Begin Play of the HUD, the rest of the logic for this reticle is in the HUD as well.

I’ve double checked and as far as I can tell the behavior is identical.

I checked the reference viewer and confirmed that the HUD is the only place that refers to these widgets.

So try this (If you already have tried this let me know what happens):

You have that circle widget that’s center screen working, correct?

So if that’s working correctly,
Replace the created circle widget’s class in the create widget node with the T shape one.
If that doesn’t work… it HAS to be something to do with the widget.

OH one thing I thought of. Highlight each individual piece of the widget below the canvas and make sure the anchoring is centered. If you open the anchoring window with all the squares and rectangles, when you click one hold shift+Ctrl to anchor AND change location in the widget.

The circle one stays centered and is never moved, but the point of the T one is to move with my tank’s turret. I can center the T shaped one just fine as well. When I set the coordinates to 0,0 it goes to the center just fine. It is when I convert from world to screen and use those coordinates that the issue arises. And subtracting half the screen size does not solve the problem.

Everything in the widget appears to be centered, yes. The test version only contains the canvas and the image.

Okay. I think I might have a thread to follow. Can you show me the line trace you’re doing and all of the code right before it, and the code up through the end of that execution line? :slight_smile:

Currently the code is running off of “Event Draw HUD” to allow the draw line to be used for debugging, however it behaves identically off of “Event Tick”.

I believe that is everything.

WAIT have you tried using “Convert World Location to Screen Location” Instead of “Project World to Screen”? The verbiage is a BIT different and I think maybe the node you’re using is for maps and such.
image
Change to
image

It is weird. They do have almost identical descriptions but they seem to be different nodes.

Unfortunately, it behaves identically. I had not tried that one though.

Okay let’s gather a little bit more info.
Run that V2 into a print string and let’s get the X and Y it’s functioning off of. Maybe we’re barking up the wrong tree and the problem lies on the widget and not in this code at all.

Assuming you’re using 1080p it should be close to (1920x1080)/2=910x540 if you start with the turret aimed at center, right?

I FIGURED IT OUT! I also feel so incredibly dumb. I stumbled upon it while trying to show you what the screen resolution is. It turns out that when I tried subtracting half the screen resolution before, I was using the wrong number. Here is the functional version:

And here is the broken version I had been using:

Thank you so much for helping me though! Even if I did end up rubber-ducking you in the end :sweat_smile:

Edit: Adding here because I marked this one as the solution, I ended up moving the code from the HUD to the widget itself (everything remained identical), and grabbing the viewport size every time instead of setting it in “Begin Play” because otherwise it would just be 0,0.

Honestly a rubber-duck situation is what we prefer- because that means what was learned is more likely to stick than us just giving the solution!

AHHHHH GET VIEWPORT SIZE! Because resolution != Viewport size!
Wait.
Check it in a windowed mode. With a strange size.

I was worried for a bit because it didn’t work at first! But I found that if I take the viewport size when needed instead of at Begin Play, it works. Hopefully the difference in performance from not using a set variable is negligible.

1 Like