RepNotify from c++ confusion.

Ya I think you are right. I just noticed I call functions that call my OnRepFunc so I never noticed this flaw before. I am seeing the same issue with it only called on the client and not the server when directly setting via blueprints.

So I guess the workaround is to always call setter functions defined in c++ via blueprints on the server that automatically call the OnRepFunc.

Thanks for checking. I’ll try to report it as a bug.

Is there any update for this? It would be extremely helpful if there was a setting to have RepNotify called on the server as well as the clients in C++. I am disliking having to litter my code with netmode checks and manual calls to repnotify in order to keep our multiplayer game compatible with P2P and Standalone.

I can’t believe it’s designed like this. Game code shouldn’t have to worry about what kind of NetMode it’s running in.

You can’t expect to just code the game normally and expect it to work in Multiplayer…

You get more control in C++. I dislike the fact that BP automatically calls the RepNotify function tbh. If you want to call it in C++, just call the function normally…



if (Role == ROLE_Authority)
{
    MyVariable = 5;
    OnRep_MyVariable();
}


Easy. You shouldn’t be changing replicated variables in too many places anyway, it’ll make netcode issues a nightmare to track down otherwise.

1 Like

“Normally”?

More control compared to what? This is just nonsense. I never mentioned blueprints or anything else for that matter. I work solely in C++, but that’s not the topic here and it doesn’t matter where I come from.

In a game class like a ACharacter derived one, I shouldn’t have to worry about whether my code works on a Listen server, when it already works on a Dedicated one. This low level logic should be made elsewhere. This is the very essence of abstraction.

Having different code paths for things like this shoots complexity trough the roof. It’s not consistent and it increases code maintenance. It also means we have to test two times with both combinations.

  • What I mean by “normally” is as if you’re writing it for single player. Maybe I misunderstood but it looked like you were saying that game code shouldn’t care about the netmode (as in client or server).

  • You get ‘more control’ in the fact that you can choose whether to call the RepNotify function on the Server or not in C++, whereas in BP you don’t get that option. That and about a hundred other ways in which you get more control over replication in C++ than BP.

  • I haven’t really run into this problem to be honest. I write game code to run on a Listen Server, then go through and exclude/wrap code that doesn’t need to run on a Dedicated Server with !UE_SERVER or something.

I haven’t seen any case where game logic is vastly different depending on what kind of server it’s running on. In the case of CMC, the only major thing I know of is the smoothing code, which doesn’t run on a dedicated server (because why bother… nobodies going to see the smoothing anyway).

EDIT: I’ve gone back and found this. I have no idea why you would ever do this ever. I wouldn’t bother with the if statement, I’d just call the OnRep_MyBool on the server regardless of netmode.

If OnRep_MyBool is only used for some visual element, then I guess you could wrap it with a netmode check (which is fine IMO). I prefer preprocessor though personally.


if (Role == ROLE_Authority)
 {bMyRepBool = true;    if (GetNetMode() != NM_DedicatedServer)    {       OnRep_bMyRepBool();    } } 

EDIT 2.0: Spaces instead of tabs? Eww.

2 Likes

This is confusing, the difference between cpp and blueprints.
Manually calling is error prone.
I guess the only workaraund is to create a set method and call it everytime you want to change the variable. In that set method you diffirintiate server with client…
There should be an option to allow repnotify to happen both on server and client if user wants this. Why not to give such option?

This thread is ancient, but here goes:

RepNotifies in Blueprint aren’t really RepNotifies, they are just called via reflection when the variable changes. You can’t do that in native CPP without using a setter function anyway.

Blueprint should use the same (aka, correct) behaviour as C++ IMO, but it’s probably too late to change this now.

1 Like

I personally like that notification is called on both server and client. It makes programming more straightforward.

I want to revive this thread again because this is super helpful for working with a somewhat overcomplicated replication system.

IN C++, YOU NEED TO CALL THAT ■■■■ REP NOTIFY MANUALLY IN THE SERVER FUNCTION WHICH SETS A NEW VALUE TO THE REPLICATED PROPERTY.

Example for new people like me:

UPROPERTY(ReplicatedUsing = BroadcastEmote)
TSoftObjectPtr<UAnimSequence> CurrentEmote;

UFUNCTION(BlueprintImplementableEvent)
void BroadcastEmote();

UFUNCTION(server, reliable)
void UpdateEmote(const FInputActionInstance& InInputActionInstance);

void UpdateEmote_Implementation(const FInputActionInstance& InInputActionInstance)
{
	CurrentEmote /* = something */;
	BroadcastEmote();
}
1 Like

Another useful notice: Property replication is not generally good for “instant” changes.
For something like “start playing an emote,” you will probably want to use a broadcast RPC, rather than just relying on RepNotify.

For the property, you’ll probable want to store both “which emote is it,” and “what was the time I started playing it,” so that someone who walks in / late joins a conversation, can see the correct animation timing (which is more important the longer the emote actions are.)

2 Likes