My UMG radar finally got released, it’s a texture based radar and can be customized easily, (background image, border etc) it can track any actor in the world at anytime basically you can choose when to track and stop tracking something at runtime, it supports persistent tracking as well which means targets that are off screen can still be targeted by displaying a customized (icon/texture) at the border of the radar. Tracking target rotation is also possible.
The radar supports on hover tooltips meaning that you can add custom tooltips to your target when you hover over them in the radar, you can also click on the radar to get the world location, or add a marker by calling the AddMarker/RemoveMarker function at any point during the game.
When adding a target you get to choose what texture to display the size and color, and of course the tooltip and whether it’s persistent or not.
You can enable the height indicator which displays an arrow up for targets above you and arrow down for targets below, you can change the texture displayed in the TargetWidgetComponent.
**Update: **Added a blinking effect that can be enabled/disabled at runtime (You get to choose the blink speed)
It’s very easy to add to your project and can work in a multiplayer game as well.
Hi Dude… It’d be helpful to know a little more about the advantages of UMG-Radar over alternatives like this 100% free one from Coquigames… It looks like tool-tips are one clear advantage. Questions: 1. If this is dragged into a Spaceship or Plane-Cockpit-BP as a widget component, will the tool-tips work out of the box? … 2. Is there any radar hint/clue for enemies above / below the player as the sample video just shows a flat level. 3. Any plans for adapting the mouse/tool-tips functionality for games that use gamepads versus mouse?
Hi, thanks for replying. The advantages are like you said tooltips, persistent tracking (off screen targets can still be tracked as you can see in the video when the target is too far away the target texture changes to something like an arrow indicating the direction of that target (you decide what texture to use)), Height indicator, clicking on the radar gives you the world location, adding a marker onMouseClick (the marker can be persistent if you want), I just submitted an update that includes the option to add a blinking effect (you can specify the blink speed for each target you add) you can stop the blinking effect at anytime during the game, I’ll keep updating this radar by adding requested features and of course providing support to whoever buys my product.
**1- **After adding the widget that contains the radar you can then call the AddTarget(s) function which gives you all the customization you need for that or those targets you want to add, including what tooltip you want to show, if you don’t want to show a tooltip you can leave it empty (there’s an example map included which shows how it’s done)
**Edit: **I missed the drag as a widget component part sorry, obviously the tooltip triggers when you hover your mouse, if you want the tooltip to display you might need to display it permanently or automatically display it for nearby targets without relying on mouse hover (that can be good with a game pad I guess), I can implement that if you need it.
**2- **Yes, an up arrow will be displayed for targets above you based on the acceptable height difference you specify in the settings, and an arrow pointing down for targets below you, if you open the **RadarTargetWidgetComponent **you can customize the texture you want to display when targets are above or below. (I can add a different effect if you prefer something else)
**3- **Yes I can do that, if you need it you can tell me the way you would like it to be (Cycle through nearby targets, or show a cursor etc) and I can do it.
Here’s a function used to add multiple targets at once, which shows the options you can enable (this is the updated version)
If you have any questions feel free to ask.
Cheers for the reply… Regarding Gamepad support, yeah it’d be great if this was built-in for Tooltips…:)… The main reason I was asking before was, I was thinking to myself, can Tooltips be extended as a Targeting system… Example: Click on 3 Tooltips and it fires off 3 homing missiles etc. Seems doable when UMG-Radar is flat or 2D on screen.
But what if UMG-Radar is a Widget Component in a jet-fighter-cockpit angled at 20-45-degrees with high FOV… Will ‘mouse hover’ etc still work, especially with different end-user screen-scalings. Your thoughts?
Hi, for the gamepad support I have a couple ideas I’ll work on adding, as for the widget component yes it should work by adding the interaction component to your Jet BP which allows us to simulate all mouse movements over the widget (I believe this is a good solution when using a gamepad) I just tested it and the hover tooltip worked just fine (take a look at some videos about the interaction widget).
Note: If you change the space property of the widget component from Space to screen then everything will work as if you added the widget to the viewport yourself which means you don’t need the interaction component, but you won’t be able to change the geometry mode.
Screen scaling and FOV should not prevent the on hover event from triggering properly so no worries there.
The targeting system is doable all you need to do is handle the Onclick event of the TargetWidget (just like the OnHover for tooltips) and trigger an event dispatcher which will be handled by the Jet BP (the event will have the target actor in it) from there the jet can send the missile toward that actor. (I will add the event dispatcher in the next update)
Ok cool, cheers… Curious to compare notes about 2 things you mentioned…
I looked back over old notes and re-tested in 4.18… Outside of First-Person-Character, the Interaction-Widget never worked for me in either 3rd-Person-Character or Pawn (Jet-fighter). In all 3 cases the Debug-Line goes right through the working widget. First Person works fine with an Interact-Source of Center-Screen or World, and Interact-Distance of 5000 for Characters and 10000 for Pawns (Jet-fighter). I only rely on Hover events too, to rule out ‘lost’ Mouse/Gamepad inputs being the cause. As an idiot test I even searched for 3rd-Person / Pawn Interaction-Widget tutorials on YouTube and on the forums and found nothing???
This has never done anything for me either. Changing the property to ‘Screen’ just makes the widget disappear.completely???
I’ve never had that problem, make sure the widget is blocking the collision channel that the interaction widget is using, I tested every scenario and it seems to work just fine.
Here’s an example with the radar: UMG Radar InteractionWidget - YouTube
Everything is set to default: Same Trace-Channel or Widget is blocking the same channel (‘Visibility’) on both Widget and Interaction-Widget (Default UI ‘Block’ Visibility). Thanks for showing the clip, its nice to see the Radar in action. BTW: Is there anything special or non-default about the 3rd-Person-Character that’s in your clip. For example, the center green blip crosshair is merely cosmetic or an added setting etc…???
Nothing special about the 3rdP character everything is default, that center green blip is just an image I added to a widget then added the widget to the viewport just to be able to see where’s the center screen.
Thanks dude. I quickly created a brand new Third-Person-Character without even anims, and that works.
So I’ll just have to take a step back here, take time comparing the 2 BP’s, then do the same for Pawn etc…
Turns out it was a simple misalignment of the 3rd-Person-Character mesh versus where the Interaction-Widget ‘Show Debug’ Line was pointing etc… Not sure why as everything looks ok. But I solved it using a large ‘billboard’ Widget with a color-change ‘Hover-event’ (to rotate the character around in a 360 to see where the real rotational-offset was). Different story for the Pawn (jet-fighter) though. That’s a whole world of hurt…
Having multiple Interaction-Widgets in the level appears to break the entire system or cause conflicts etc. But there’s nothing in the Docs about this… If for example, I stand the 3rd-Person-Character in front of the same ‘Billboard’ Widget and have Gamemode spawn in a Pawn (Jet-fighter with its own Interaction-Widget), this causes the Character’s billboard to stop working (Hover event no longer responds).
I tried making some educated guesses about Virtual-User-Index / Pointer-Index. But overall, not sure how to solve this. I may have to assign a unique Interaction-Widget to each player and have them ‘carry’ this between Vehicles, but that would be a pain…
I made a few more discoveries in case anyone else ever experiences odds things using the Interaction-Widget:
The most striking is this: Spawn a 3rd-Person-Character without Interaction-Widget, and walk up to the ‘billboard’ Widget -> No reaction. But Spawn a Pawn (Jet-fighter). Then have the Character enter and exit. The character actor is destroyed and re-created but this is all still PC0. Then have the Character walk back up to the ‘billboard’ Widget -> Reaction. The Character is behaving as if it has an Interaction-Widget now. WTF??? In effect its behaving like an extension of the Pawn (Jet-fighter), even if the Pawn is flown well out of range. So how is that possible?
Spawning a second Character (PC1), without an Interaction-Widget, doesn’t cause issues with PC0’s existing Interaction-Widget… But spawning a new Pawn (Jet-fighter) breaks the Interaction-Widget… Even if that Pawn doesn’t have an Interaction-Widget at all. That is, unless its spawned far enough away from PC0… So again, WTF???
I’ll do more tests, but I might wait for 4.20 installed on a second rig, before reading too much into all of this…**
Solved - The clues were always there: 1. Every spawned Pawn (Jet-fighter) even those without Interaction-Widgets could break the interaction. 2. The range of distance that each Pawn had to be away from the ‘billboard’ Widget for things to work normally, was curious.
Each Pawn (Jet-fighter) has a Collision Sphere for local-proximity-radar. For some reason spawning Pawns with this Sphere after the Level ‘starts-up’ causes conflicts for the Interaction and Widget if they lie within the radius of the Sphere. Seems strange, but that’s it. The answer probably lies in the Collision settings. But for now a simple solution is just shrink the Sphere radius whenever the local radar isn’t being used.**
Volumes by default ‘consume’ all WIC Traces. Adding a custom-collision-channel dedicated to WIC and set to Ignore solves this.