Creating a "Radar" system that lists nearby targets on a UMG scrollbox, sorted by distance.

Hello, I’m working on a space flying game for fun and my goal is to create a UMG widget that will list nearby enemies, planets etc on a scrollbox in ascending order of distance, not unlike something you would see in any space or flying sim. At the moment my setup is essentially a “Populate List” function that is called with an event (not tick, should start fresh each time) that does the following:

-Fires a sphere overlap to grab all the actors of class in range
-Does some mucking about with arrays to re-arrange the actors by distance from the player
-References the new sorted array to create “Radar Entry” widgets for each actor.

And it works, sort of. The “Entry” widgets are successfully added as children to the scrollbox parent, in ascending order of distance as desired, however the problem is that it only works once. Once the widgets are created once, they always re-create exactly the same, even when the actors in range have changed, or the distance from player has changed as if the player was in the exact same spot they were the first time the function was fired. You might be thinking that I just wasn’t updating cosmetic data on the entry, but I definitely am because if I check the arrays with a print string I know the arrays are working properly and if I check the distances from player on a tick, they are reading correctly. Besides, as you can see in the screenshot I’ve attached, I’m clearing the scrollbox children and wiping clear the arrays on each call, with the intention of just re-populating the list fresh each time, and yet it doesn’t work.

I have read a lot that UMG widgets can be fussy when doing lots of parenting/unparenting because they are held in memory even when they are cleared. I tried messing around with garbage collection and that didn’t do anything.

My current solution also just doesn’t feel that polished, I would like it if it could keep track of distances dynamically and update so it’s always in order of distance without rebuilding the entire UI but I can’t wrap my head around how to do that in blueprint.

Bottom line, I feel like this is a pretty typical mechanic you would see in a game and I would be very curious to know how someone else would implement it better. Feel free to tell me I’m way off-track :slight_smile:

FYI, I’m pretty handy with blueprints but I don’t know how to C++ unfortunately.

Thanks in advance for any help from the community!

and yet it doesn’t work.

Judging by the pic, you’ve yet to plug in an array into the loop at the bottom. Not sure if that’s just a badly timed screenshot. May be.

I have read a lot that UMG widgets can
be fussy when doing lots of
parenting/unparenting because they are
held in memory even when they are
cleared. I tried messing around with
garbage collection and that didn’t do
anything.

True, but manual Garbage Collection will work providing you do dereference the widgets. Clear variables / arrays and remove from parent (viewport is also a parent).

Bottom line, I feel like this is a
pretty typical mechanic you would see
in a game and I would be very curious
to know how someone else would
implement it better.


My current solution also just doesn’t
feel that polished, I would like it if
it could keep track of distances
dynamically and update so it’s always
in order of distance without
rebuilding the entire UI but I can’t
wrap my head around how to do that in
blueprint.

You’re approaching it correctly as far as blueprints go. It’s still a thing with UMG - one cannot insert a child where needed so you need to flip arrays all day.

  • have each actor own their own widget (created once and only on request)
  • sort those actors by distance
  • clear the widget container and repopulate with those actors’ widgets

Thanks for your take on it! Being able to insert a child at an index would definitely be on the wishlist.

Judging by the pic, you’ve yet to plug
in an array into the loop at the
bottom. Not sure if that’s just a
badly timed screenshot. May be.

That’s right, I was plugging things in and out all over the place, just forgot when I was showing my setup.

You’re approaching it correctly as far
as blueprints go.

Glad to know my thought process at least makes sense in the context of the engine. I would be very curious to know how developers implement this in other games. Maybe this is the sort of thing that would be better implemented from scratch in hard code? I’ll keep playing with it and see what I come up with. Either way, looking forward to seeing some improvements to UMG in the future! :wink:

Thanks again for your take.