x

Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

Problem with UMG / Networking 4.5

I have troubles making a HUD with UMG. The HUD created for each blueprinted character on begin play.
The HUD has 3 progress bars, health, energy and a "cast bar". Each of those bars is driven by a replicated value, they are replicated because I want the player to see hovering versions of these bars for all other players (this will actually be another UMG widget than the HUD).
I had everything working but I had to use really inconvenient ways to get to that point.

Now the actual problem:
When creating the HUD widget inside the character blueprint on begin play, I pass a reference to self to an "exposed on spawn" character variable, from which the progress bars get their information.
Both characters seem to share the same information (the cast bar progresses the same on both clients), like if it was only one widget displayed on both clients (it doesn't matter btw if I use a listen server or a dedicated one).
I am trying to fix this for at least 2 days now and can't find the problem, so I thought it might be a bug.
Logical both widgets should have their own character to get their information from, I am replicating the information to all clients, but still that information should be linked to its own character instance (shouldn't it?). Just for testing I added a print string node to begin play and the log result was:

LogBlueprintUserMessages: Server: Hello
LogNet: Join succeeded: 268
LogNet: Join request: /Game/Maps/Example_Map?SplitscreenCount=1
LogBlueprintUserMessages: Server: Hello
LogNet: Join succeeded: 269
LogBlueprintUserMessages: Client 1: Hello
LogBlueprintUserMessages: Client 1: Hello
LogBlueprintUserMessages: Client 2: Hello
LogBlueprintUserMessages: Client 2: Hello

It seems strange to me that both clients trigger begin play twice. The way I got it working first was to actually use the possessed event and then use a client rpc to add the widget clientside, but only if the character isn't controlled locally on the listen-server.

The widget function for retrieving the cast progress:
cast progress function
The character blueprint: begin play blueprint
The character c++ base class beginplay method and replication: c++ character base

Product Version: Not Selected
Tags:
hudcastbar.png (44.7 kB)
beginplay.png (111.3 kB)
c++character.png (42.5 kB)
more ▼

asked Oct 23 '14 at 10:47 PM in Bug Reports

avatar image

JerryTheRook
116 7 16 15

avatar image Nice_Rain Oct 24 '14 at 02:04 AM

When did you start noticing this issue? I just noticed it today. I have two progress bars as well. One of them being health. The value for CurrentHealth is replicated using DOREPLIFETIME as well. When the game loads, it reads the CurrentHealth value correctly and the bar sets normally. As soon as I decrease the CurrentHealth on Player1, Player2's health bar decreases as well.

  • CurrentHealth is replicated correctly on Player1 and Player2

  • I'm noticing that the progress bar update is being called more than once per client (the function breaks twice)

  • The progress bar values are reset the 2nd time around. (by looking at the value of CurrentHealth)

I think this is a bug as well, but it is SEVERELY hurting my game setup right now.

avatar image JerryTheRook Oct 24 '14 at 04:19 PM

Hey, I had problems with this immediately after implementation of my UMG widgets.
I was able to fix the bars before by using really ugly ways and many checks, but I doubt that was the proper way to do this... I mean it should just work by using begin play and spawning the widget for each character.

avatar image Nice_Rain Oct 24 '14 at 04:23 PM

Exactly man, the problem is, that for some reason, the bars are getting overridden with another variable. If I manually change the currenthealth that the player has (by hitting eject and changing the value), the bars don't reflect it. They dont' reflect it if I change it by running a function to. They all have the same number being sent to them for the %. And like I said, the breakpoint is hit twice for every time the bar is updated, per player on the server.

avatar image JerryTheRook Oct 24 '14 at 04:39 PM

I just did a test by printing a message on replication (using "ReplicatedUsing=OnRep_CastProgress").
By logic it should log the message twice on each progress change ,the simulated clientside character of the server character and the actual client character both need to know each others progress.
When using a dedicated server instead - so that there are 2 client players - the log gets printed twice, that is correct, but it is still a synced result (both have the same progress).
Either I never really understood how replication works or this is definitely a bug (and I hope it is :D)

avatar image Nice_Rain Oct 24 '14 at 04:44 PM

Yep, exactly. I was meaning that the first time I see my var, it's like 95.0 because I healed my player. The second time I look at the var (the second breakpoint), the var is like 65.0. You would arguably say that it's because the increase in health was not replicated correctly. If I eject and click on any player, they all show the correct var (95.0 instead of 65.0). For some reason the server isn't syncing this up. This occurs with any progress bar I have.

I know that UMG works correctly, though, because my list inventory works correctly. If I have an item in player 1's inventory, it displays correctly in the list. Player 2's inventory will be empty. This is reflected perfectly by looking at the arrays on each player as well.

Do you have your progress bars on your Character class or HUD class? My progress bars are on my HUD class, but my inventory is on my Character class.

avatar image JerryTheRook Oct 24 '14 at 04:49 PM

Well I create the widget inside the characters begin play, I don't have a HUD class.
The progress bars are embedded in a UMG widget that I named HUD.

avatar image Nice_Rain Oct 24 '14 at 07:15 PM

I just did a printstring on my variable when I do the UpdateHud command. Every time the health bars update, the printstring will print out the CurrentHealth:

 LogBlueprintUserMessages: Server: 49.0
 LogBlueprintUserMessages: Server: 49.0
 LogBlueprintUserMessages: Client 1: 48.0
 LogBlueprintUserMessages: Client 1: 48.0
 LogBlueprintUserMessages: Client 2: 48.0
 LogBlueprintUserMessages: Client 2: 48.0

I then used an item to heal my player by 30:

 LogBlueprintUserMessages: Server: 47.0
 LogBlueprintUserMessages: Server: 77.0
 LogBlueprintUserMessages: Client 1: 76.0
 LogBlueprintUserMessages: Client 1: 46.0
 LogBlueprintUserMessages: Client 2: 46.0
 LogBlueprintUserMessages: Client 2: 76.0

Are you having the same results on yours as well? Client 1 is repeated twice, 76, then 46. Which is why the health bar retains the original value.

avatar image Nice_Rain Oct 24 '14 at 07:55 PM

Another note - If I create a dedicated server with only 1 person on it (same coding and everything). The bar updates and works correctly. This also works if I run it with one client, non-dedicated from the editor. Edit:I can confirm the issue only occurs with more than 1 client connected. The progress bar will always update to the newest client's CurrentHealth. Client1 and Client2 will display Client2's health.

avatar image JerryTheRook Oct 24 '14 at 08:38 PM

Actually after thinking about this the execution rate makes sense:
There are 2 characters - both exist on the server and the clients.
The 2 server outputs are for the 2 characters on the server.
Each client then outputs for its own client and the simulated second client - so it actually makes sense.
But this still won't explain the behaviour with the progress bars (when going with pure logic) The differences of 1.0 in your results from server to client seem to be a rounding error which is strange since those are in fact already round numbers.

avatar image Nice_Rain Oct 24 '14 at 08:50 PM

The differences of 1 are perfectly fine. They are rounding errors, ya. But it has to do with event tick removing the health. The issue is that client2 is overriding client 1's progress bar. The latest client will always override the bars for all other clients.

avatar image JerryTheRook Oct 25 '14 at 12:51 AM

Checking if the current character is locally controlled actually fixes creating wrong widgets, without the delay node however, the clients character won't be recognized as locally controlled - I guess on begin play the character isn't immediately possessed by a controller.
So this is a really ugly fix like before - and I doubt that this is the intended way of doing this... but I will continue working with this until we get an official answer. alt text

umgfix.png (79.2 kB)
avatar image sinoth Dec 10 '14 at 06:17 AM

THANK YOU! I am having a similar issue. "Is Locally Controlled" returns an incorrect value if during Begin Play. Driving me crazy. Wish we could get official word on this.

avatar image viisual Mar 20 '15 at 12:56 PM

This caused an issue for me this week as well, and I really don't like the solution... but I guess I'll have to use it?

avatar image Rudy Q ♦♦ STAFF Dec 23 '14 at 07:29 PM

Hello wraith321,

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.

(comments are locked)
10|2000 characters needed characters left

3 answers: sort voted first

Hello SentientBot,

I was able to reproduce this issue on our end. I have written up a report ( UE-10285) and I have submitted it the developers for further consideration. I will provide updates with any pertinent information as it becomes available. Thank you for your information and time.

Make it a great day

more ▼

answered Feb 20 '15 at 02:51 PM

avatar image

Rudy Q ♦♦ STAFF
47.7k 545 132 522

avatar image viisual Mar 19 '15 at 10:57 PM

I ran into this issue today and am glad to say I found this UE4 answers post about it.

I was able to get the workaround going, but now I'm left contemplating which implementation is "more correct"

Using the HUD class or using the Player Controller to instantiate widgets.

avatar image Komahz May 10 '15 at 01:52 PM

May 5 2015. Still exists for me

avatar image Rudy Q ♦♦ STAFF May 11 '15 at 01:08 PM

Hello Kheka,

There are two issues listed here. I went ahead and checked on both of these issues for you. It appears that UE-7021 has not been resolved as of this time, however, UE-10285 has been fixed internally and will be available in a later release of the engine. I hope that this information helps.

Make it a great day

(comments are locked)
10|2000 characters needed characters left

I have found a solution to my own health bars. It was as I originally suspected. The HUD itself is being drawn by the Character class. I'm not exactly sure why this is causing the problem, but it could be as you said, no controller is assigned immediately.

In order to fix it, you will need to derive a HUD class. Inside of your blueprint, you will just need to cast to your owning pawn and pull the vars you are updating with. My other menus and stuff worked fine (because they were in the HUD class). Moving my health bar to the HUD class, everything updates perfectly, no replication errors. alt text

playercast.jpg (212.5 kB)
more ▼

answered Oct 25 '14 at 03:07 AM

avatar image

Nice_Rain
249 13 14 29

avatar image JerryTheRook Oct 25 '14 at 12:43 PM

I guess this is a way to do it for now, since the actual HUD blueprint will be instantiated at the right time for our purposes, but still, widgets shouldn't depend on a HUD blueprint because it is actually used for the old canvas type of making HUDs.
Widgets should work independently, so I won't mark this as resolved yet.
But thanks for working on this problem with me :P.

avatar image JerryTheRook Oct 25 '14 at 06:10 PM

I just tried using a HUD blueprint but it results in the same for me - without a delay the clients won't have the widget.

avatar image Nice_Rain Oct 25 '14 at 09:20 PM

Really? Inside my HUD class I use beginplay to bind the bar to the player. I create the widget, set the HUD. Before adding it to viewport I check is dedicated server, if false, add to viewport then update.

alt text

beginplay.jpg (127.1 kB)
avatar image Rudy Q ♦♦ STAFF Dec 16 '14 at 06:30 PM

Hello wraith321,

After reading through the conversation between you and walk12288 I still have a few questions that would help narrow down what exactly it is that is causing this issue.

Quick questions:

  1. Are you still experiencing this issue?

  2. Can you tell me what version of the engine it is that you are using?

  3. Can you reproduce this issue in a clean project?

  4. Can you provide a list of detailed steps to reproduce this in a clean project?

avatar image FS Creations Dec 24 '14 at 01:34 PM

Hi Rudy -- this is still happening. These are the steps to reproduce this:

1 - Create a 3rd person bp project, set up N° of players to 2.

2 - Create a UMG Widget with anything inside it (e.g. a button)

3 - On MyCharacter BP add: "On Begin Play" => "Create Widget (the one we just made)" => Add to viewport

4 - Play

5 - Open the test widget and debug it. 4 widgets are created.

alt text

This still happens using 4.7 preview.

The workaround around it is to, instead of using "OnBeginPlay" "OnTick" with a "Is Locally Controlled?" bool and a DoOnce node

OnTick > Is Locally Controlled? > If true, then DoOnce > create the widget and all.

avatar image SentientBot Feb 18 '15 at 05:34 PM

Thank you for the work around. Hopefully this gets fixed in 4.7

avatar image SentientBot Feb 19 '15 at 04:42 AM

Ok so i just got 4.7 preview 8 and this looks fixed. the funny thing is the editor now crashes with the workaround.

avatar image Rudy Q ♦♦ STAFF Feb 19 '15 at 02:02 PM

Hello SentientBot,

I have a few questions for you to help narrow down what issue it is that is causing the crash that you are experiencing.

Quick questions:

  1. Can you reproduce your crash in a clean project?

  2. If so, could you provide a detailed set of steps to reproduce the issue on our end?

  3. Could you provide screen shots of the blueprints involved with your issue?

  4. Are you receiving any other errors?

avatar image SentientBot Feb 20 '15 at 12:33 AM

Yes I can.

Start with a blank map.

Create a widget bp and a player controller bp. Save them and close the editor. (this is required. i dont know why)

Open your project again, open the player controller and add this code

alt text

Click compile and it will crash. if you save this before clicking compile, your editor will crash when opening.

bug.jpg (28.5 kB)
(comments are locked)
10|2000 characters needed characters left

Hello wraith321,

I was able to reproduce your issue. I have submitted a report (UE-7021) to the development team for further consideration. Thank you for all of your information and time. I will provide updates with any pertinent information as it becomes available.

more ▼

answered Dec 24 '14 at 03:20 PM

avatar image

Rudy Q ♦♦ STAFF
47.7k 545 132 522

avatar image Komahz Feb 24 '15 at 09:03 AM

Hi, Any news?

avatar image Rudy Q ♦♦ STAFF Feb 25 '15 at 02:42 PM

Hello Kheka,

I looked into the issues listed on this page and there have been no updates into the status of either issue.

(comments are locked)
10|2000 characters needed characters left
Your answer
toggle preview:

Up to 5 attachments (including images) can be used with a maximum of 5.2 MB each and 5.2 MB total.

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question