Download

Dynamically creating widget and adding to current hudui

SO after equipping this item (which works; is an engram, can craft, etc) I can see the nightvision post process effect from the buff, but it crashes after approximately a second with exception handler event from unknown function and unknown module. The one thing I noticed is that the UI widget I created for use with this item did not appear on the screen as intended. When I get rid of the ui element all together, the item works as it should; that is, I can craft it from its engram, equip it, and see the buff post process effect and still play the game. So the error has to be related to my attempting to dynamically create a new UI widget based on the item being equipped. Here is what I have done when attempting to create the widget and add to the current player ui:

dynamicwidgetcreation.png

really want to get around this hurdle, as I know I am most likely going to have to debug the for/each logic to dynamically cast a new text block to this widget, but first I need to successfully dynamically create and add the widget to the viewport while keeping the player hud ui.

First, add a delay after Event Begin Play.

Second, use Get Owner Controller to get your controller reference.

Third, I’m not entirely sure how accurate your Get Actor Location(self) is… while Buffs are actors, they don’t really have a physical presence in the game-world. I personally would use the playercontroller retrieved from the node above(promoted to a variable for ease of use) then placing a get node for that in your graph and using a Get Controlled Pawn node as your target for that location.

Side note: How exactly is your begin overlap firing? I can’t see that ever firing like that because there’s nothing to actually overlap. Generally how you would use that in this case is by using a OnComponentBeginOverlap(ComponentNameHere) event node that you can access by clicking on the component and right clicking in the graph.

Alas, all of the above is just my opinions and thoughts. Do what works for you.

-WM

Thanks for the quick reply. I went ahead and changed it as you suggested, and now at least I am seeing the widget show up! But after it does, again, lasts about a second, then crashed with unknown error in unknown function in unknown module… :(. I am glad at least I learned a trick to adding the widget dynamically to the hud, but why does it keep crashing after I add it? I disconnected the collision nodes for now and it still crashes (again this time still adding the widget to the hud). All I have running in the buff graph right now is this:
dynamicwidgetcreation.png

This time, it actually appears to add the widget, but still crashing. I even got rid of this all together to just test the helm and the buff by itself, and it works fine in that regard. Only once I begin coding for this dynamic entry does it seem to crash. Could it possibly be due to a non-optimized widget? I know the UMG lets you set where the new anchor point should be for your widget depending on screen size. Since I am using the editor and test map to test it, could it be due to this, even though it actually showed up in the right location?

FYI: Still very new at UE4 and modding, have only been at this for about 3 weeks, winging it ever step of the way! Sorry is this is too noob, but after spending two days of my holiday on JUST this part of the mod…well it’s making me start to pull hair out lol.

You need to parent your Widget to “PrimalUI”. Open up your widget blueprint, go to File > Reparent Blueprint. Then select “PrimalUI”.

OMG that was it, thank you both!
Now this noobie is on to getting my ridiculous for/each loop to dynamically cast the right info to that widget WOOOHOOO!

Speaking of parenting: if I have a separate widget that is only a text block set up inside of the ui widget i just got to properly show ( i.e. two widget bluprints: one for the area I want the info to be and one for the actual information to place there) would I parent the second widget that is to hold the information to be posted inside the first widget to the first widget (the one it “resides” in as a text block) or still to the PrimalUI?

Again thank you both for helping me figure that part out!

Just be aware, you need to handle replication properly with widgets or you will crash servers.

Or your own damned EDITOR! Ya, not twenty minutes after I read this post, I unequipped my modded item in the testworld in the editor and got a cef log, had to re download the editor, lost all my work, but hey, I am sure you meant that we need to make very sure that all proper items regarding the ui are created and destroyed correctly to prevent such a crash yes?

End Play > Remove from Viewport will stop crashes from occurring.

There really is no replication when it comes to widgets, really the only thing that needs to be done is to stop widgets from trying to interact with servers, as they can’t replicate servers have no knowledge of them and any logic that tries to make an interaction occur will 8/10(very few things are 100% with the ADK) crash clients and servers alike. Or the Kit.

-WM

If you are adding to the view port on equip, then you need to check is from save game or it will crash. Also, from everything I have read on UE forums and documentation, all of the viewport handling should be done client side to reduce load server side.

But thats just what I have read.

How I’ve come to understand it is you need only do that if the PrimalItem has been specifically told to use Blueprint Equipped Notifications(the only way you can access/use the node you’re talking about correctly).

And viewports are only handled client side, they don’t/can’t exist on servers environments, at least, not traditionally as the server is almost 100% logic/code only. Well, they are with ARK anyway, wildcard have mentioned - somewhere - that Widgets will crash the servers if you attempt to do anything with them on them as they either can’t do anything with them or can’t “see” them or something along those lines. I can’t remember what they said exactly, something along those lines, it was a little while ago now.

-WM

All i know is that without proper replication I would crash, and without checking is from save game on the primalitem that was adding the widget on equp crashed it too when server was booting from a save game where someone had it equiped. I had to branch from EBP->is from save game->true? do nothing. False? add to view port (replicated). This is my offhand altimeter i am referring to.

And yes, you would need to have equip noti turned on

Something I haven’t ran into then. Odd.

Oh well, guess I should be thankful then anyway haha.

-WM

Yeah went in circles for a bit. I will say this. Creating a custom event and replicating it takes 5 seconds and thats that. And it definitely doesn’t hurt. :stuck_out_tongue:

Ok, so my concern then, is it possible, even replicating, to generate a list of nearby pawns (dinos/characters) and dynamically cast to this info to the replicated widget, without causing a crash? I don’t believe this would have the widget directly communicate with the server, since the variables can get the information and then print them on a replicated widget. And the info is not saved, just generated during a collision with a sphere attached to the player pawn and dynamically added and removed on begin and on end collision. Would something like this work without causing the server to crash? Don’t want to keep putting in the time if this method can’t even be executed…
Side note: Funny how weeks worth of modding can be crammed into a single day when you know what you are doing! Took me one day to get my mod back to where it was after the engine crash!