[4.8.1] - Bug w/ Comparing Object Reference Inside UMG UserWidget

Hey Guys,

Got another one I think is a bug. I’m not 100% just in case it has to do with a lack of understanding about something underlying in the engine. What is happening is when this Custom UserWidget is created, it grabs the Owner Pawn Reference, casts it to a custom Pawn class type and stores it to be referenced later.

The UMG Widget I’m creating is a ChatWindow and it calls down into a custom Pawn class in C++ to pass the new chat text off to a custom PlayerState to redistribute to all connected clients.

What is happening from what I can see, is I do a check seeing if the ‘Pawn Reference’ variable is valid when needing to call any members within. I can see right before the ‘IsValid’ call is that it is storing a reference to the correct Pawn however when I try to evaluate it with IsValid or doing an != and leaving the second value NULL, it always shows as not a valid reference.

So it’s a little confusing but hopefully not too bad to solve. Let me know what you want me to try.

EDIT: BTW, this only happens on a Client and not Server instance. Since UMG only runs on the client, I’m scratching my head on where the reference has gone to.

Thanks Again!

Hello MC Stryker,

I was unable to reproduce this issue on our end. I have a few questions for you that will help narrow down what issue it is that you are experiencing.

Quick questions:

  1. Can you reproduce this issue in a clean project?
  2. If so, could you provide a detailed set of steps in order to reproduce the issue on our end?
  3. Could you provide a screen shot of any blueprints that may be involved with this issue?
  4. Is the custom pawn that is being used to store the information ever instantiated in the level?

Hey Rudy and thank you for chiming in on this one!

Absolutely I can try those out. I didn’t initially post a screenshot as I needed to get approval from other parties that in this case it’s okay or if I would need to email it directly to you but it’s not a problem whatsoever.

I’ll try to evaluate this shortly for you. Worst comes to worse, you should expect an answer by tomorrow afternoon (PST) at the latest.

Stay tuned and hope you and the team are doing well!

Thanks again!

  1. I didn’t have an opportunity to repro this in a clean project. Today is unfortunately way too slammed but I was able to capture some screenshots for you.

  2. I have a UMG Widget that serves as a ChatWindow. I have an underlying C++ interface and base class (so I can see it in C++ and its functions). In the UMG Event Graph for the ChatWindow, I have the Event (from interface) OnTextCommitted’ inherited and overridden from the text box where this happens. At ‘BeginPlay’ I grab the Widget Pawn Owner from UserWidget, cast it to my custom Pawn and store it in a variable, ‘Pawn Reference’. Back in OnTextCommitted once it is called, I check if the reference is valid and if so to call the SubmitChatText function. As a note, the ‘Pawn Reference’ variable is set to be Replicated. When debugging, Pawn Reference is holding a reference but when evaluating with Is Valid or just seeing if its simply not NULL, its still showing failed and not Valid.

  3. Screenshots below…


Link: Microsoft OneDrive - Access files anywhere. Create docs with free Office Online.

  1. Yes

So it’s pretty odd that IsValid still thinks its empty but hopefully you can help me understand what’s going on better. Thanks again!

Hello MC Stryker,

Could you try and resubmit the screen shots from the post above. There seems to have been some sort of error. Also, I wanted to check in and see if you have had any time available to try and reproduce this issue.

Absolutely… I noticed this with a post with Eric K the other day. It might be due to changes in OneDrive… hang tight buddy. brb

Okay Rudy, try now and let me know if you see it. I also went ahead and posted a link to view just in case. Thanks again and hope you are having a great day!!!

Hello MC Stryker,

I have a test I would like for you to try. Could you try setting “Pawn Reference” to public and add in a delay for 0.1 seconds just before you set the variable. I believe that this issue occurs due to an issue with the order at which things are taking place. I believe that your “Pawn Reference” variable is getting set before the pawn is spawned in for the client. Using a delay will allow you to rule this out as a possibility.

Definitely! I’m doing an upgrade to 4.8.2 right now so once that’s complete, I’ll get that tested out and get right back to you.


Okay Rudy, got an update for you! I unset it as being private and did what you said but slightly altered it and got two different results.

If I delay w/ 0.1 s, it fails like before…

However, if I set the delay to 0.2, it succeeds!

I can try and remember to do a Delay before storing a Pawn reference but maybe this is enough for you or an engineer to track it down and eliminate it.

Thanks Rudy!

Hey Rudy,

I’ve got another update for you.

I just tested this again and it didn’t work. I was testing a Dedicated Server running 2 client Windows and was able to fix it by delaying storing the Pawn even longer. In the case I just tried it was 2 seconds but that may be too long.

EDIT: Just tried again w/ .2 and it worked. :expressionless:

Hello MC Stryker,

Thanks for all of the updates. I am happy that we were able to find workaround for you. I have another way that should be more reliable. In the example that I provided below, I set the pawn reference variable every 0.1 seconds that the pawn reference variable returned an “Is Not Valid”. As soon as the logic gets a Valid response it will end the loop. I hope that this helps.

Make it a great day

Hello MC Stryker,

We have not heard back from you in a few days, so we are marking this post as Resolved for tracking purposes. If you are still experiencing the issue you reported, please respond to this message with additional information and we will offer further assistance.

Thank you.

Hey Rudy!

I just saw this post and had missed your reply from last week. I’ll apply that fix asap and thanks a bunch for getting back to me :slight_smile:

I’m guessing this isn’t by design and will likely change but were you able to determine the original cause? I’m guessing its something as simple as when the order of things fire in the engine underneath the covers.

Does this only affect UMG widgets or should I replicate this across every Blueprint that needs to gather and store a reference going forward in the future?

Thanks Rudy and hope you had a great weekend! Take Care.

Hello MC Stryker,

This is a current limitation. The order that objects are instantiated cannot always be guaranteed between machines. It’s good practice to have contingency plans in place for this potential occurrence. I hope that this information helps.

Make it a great day

It absolutely did Rudy and thank you very much :smiley:

Thanks again for your assistance on the issue and I’ll keep this in mind in the future if I encounter similar problems.

You and the team have a great rest of the week!