Calling C++ NetMulticast from Blueprint is bugged

Development Programming & Scripting Multiplayer & Networking
, , , , ,
1

A parameterized NetMulticast function in C++ that is also BlueprintCallable seems to only properly pass parameter values to one client while other clients just receive 0 values.

Example:

  • We have 3 clients connected to a dedicated server.

  • MyGameStateC is a C++ class with a NetMulticast function called BroadcastByte(uint8 InByte).

  • BroadcastByte is a UFUNCTION(BlueprintCallable, BlueprintAuthorityOnly, Category = “MyGame”).

  • MyControllerBP is a PlayerController with a To-Server RPC called BroadcastMyByte.

  • A player calls this event and BroadcastMyByte successfully receives byte (let’s say 0x3).

  • Now on server, BroadcastMyByte calls C++ BroadcastByte on a MyGameStateC object.

  • Client 1’s BroadcastByte receives 0x3. Client 2’s BroadcastByte receives 0x0. Client 3’s BroadcastByte receives 0x0.

  • So why didn’t Clients 2 and 3 receive 0x3?

Client 1 is not a listen server. He’s just only client that happened to receive correct byte.
I stepped through UE4 in debug and it would appear that a BlueprintCallable NetMulticast takes a special route instead of C++ route. This route apparently does not properly package byte to be sent to all clients after it sends it prepares it for first client.
Upon discovering this, I simply added another BlueprintCallable C++ function that would call my NetMulticast function, and that fixed issue. All clients then received correct byte. This is a workaround though, and not a solution.

2

Thanks for reporting this issue. We’re now tracking this bug internally and will look at fixing it in a future release.

3

Reported in UE-5191.

4

Hi Cobryis,

I’ve attempted to recreate this issue, but haven’t been able to reproduce it. Does it still occur in 4.7.5? If so, a small sample project demonstrating issue would be very helpful.

5

Setting UFUNCTION to BlueprintAuthorityOnly results in it only being broadcasted to server from server, so removing that allows for a more accurate reproduction. issue does still exist. I just tested it. Only 1 client got byte 0x3 and rest got 0x0.

6

// Header
UFUNCTION(BlueprintCallable, Reliable, NetMulticast, Category = UBGameState)
void BroadcastByte(uint8 InByte);

// CPP
void AUBGameState::BroadcastByte_Implementation(uint8 InByte)
{
	UE_LOG(LogTemp, Warning, TEXT("Client recieved: %d"), InByte);
}

38264-bptocppmulticastfail.png
38264-bptocppmulticastfail.png1406×860 241 KB

Output:

[2015.04.10-00.14.47:650][201]LogTemp:Warning: Client recieved: 3
[2015.04.10-00.14.47:652][201]LogTemp:Warning: Client recieved: 3
[2015.04.10-00.14.47:653][201]LogTemp:Warning: Client recieved: 0
[2015.04.10-00.14.47:655][201]LogTemp:Warning: Client recieved: 0

first Log is server, second is 1 client to receive, and other 2 0s are clients receiving 0 when they should be receiving 3.

7

Thanks for extra information, I was able to reproduce this and we’re working on a fix. There is a bug with how we are processing parameters for a native multicast function when it’s called from Blueprints.

8

This has now been fixed, and will make it into 4.8. Thanks again for report!