Whats up everyone…I’m stuck and could use a little bit of help with UMG.
In the images below…my goal is to the orb from point G to point F. You can see in the BP image I have moved the orb from starting point to G with the G-key which works fine. The orb passes the trigger box and stops at point G. The trigger box fires the UMG which populates a (G – F) button for the user to interact with. HOWEVER, this is where I am stuck. Within UMG, there must be someway to get the event graph to either handle the next movement itself, or reference back to the level blueprint and create some kind of linkage there. Is it some kind of casting process i need? Obviously in UMG you cannot drag right off the OnClicked node and link it to target point F, so something must be in between. I would be thankful if anyone can shed some light on this type of activity and/or do a mock image that would be helpful to me and the community as well. Please let me know if you have any questions. Thanks again all!
I would take the “Other Actor” of the Overlap and cast it to your mesh. Then create a variable in your widget blueprint that can hold a mesh reference.
After create your widget with the overlap event, i would use the casted other actor and fill the newly created variable of the widget with that other actor.
Now you have a reference of the mesh in your widget. You would now need to performe the same thing you already did with the “Move Component to”
in your widget. Since you now need the endpoint “Point F” so you can get its location, you would also want to create a second variabel for this actor
inside of your widget and set it the same way as you did with the other actor.
Then you can use this variable inside your widget and get its location.
EDIT: So i went ahead and made an example for you:
Inside your widget, create 2 variables, one of type actor and one of the actor type you want to move (i called mine “ActorToMove”). For both, click on “Editable” and “Expose on Spawn”:
My ActorToMove was just a simple Mesh that i turned into a Blueprint:
I don’t know if this is the exact setup like you have it, but i guess you get the point.
But i don’t really think that this is a good way to handle these kinds of things. Then again
i don’t have a fast solution to handle it differently.
eXi, this is great stuff, thanks a lot for taking a moment to provide a visual example. I see where the linkage with the casting is important and the process you laid out definitely works. As you mentioned in the last comment, I had something similar to this but like you, there didn’t seem to be something more simplistic. The variables is a great solution – I think I need to look into variable use alot more. I think it’ll save time. Excellent work – I think this is something the community can use again for other similar movements.
