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:
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:
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.
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.
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.
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)
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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:
Are you still experiencing this issue?
Can you tell me what version of the engine it is that you are using?
Can you reproduce this issue in a clean project?
Can you provide a list of detailed steps to reproduce this in a clean project?
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.
