How do i code server rpc in 4.7 ?

Hey guys,

How am i supposed to deal with server rpc in 4.7 ?

I have a ton (one for each rpc) of warnings like that one:

 warning C4996: Function YagActor::ServerSetBodyTexturePath needs native implementation by virtual void ServerSetBodyTexturePath_Implementation(const FString& NewBodyTexturePath) due to its properties.

Maybe it is obvious and self explanatory but i am not a big guy in c++ and couldn’t find a way to get rid of those.

Here is my code, it has been ok until 4.7:

UFUNCTION(Server, WithValidation, Reliable)
	 void ServerSetBodyTexturePath(const FString& NewBodyTexturePath);
 bool AYagActor::ServerSetBodyTexturePath_Validate(const FString& NewBodyTexturePath)
	 return true;
 void AYagActor::ServerSetBodyTexturePath_Implementation(const FString& NewBodyTexturePath)
	 bla bla

Could anyone give me an example of how server rpc should be declared in 4.7 ?

Thanks !



Look at my code, this is what i am already doing.

It worked well in 4.5 and 4.6 and now generates a warning.

If i declare it with _Implementation i get a compilation error, which, interestingly enough, comes back to warning if i add the word virtual.


UFUNCTION(Server, WithValidation, Reliable)
	virtual void ServerSetupYagFdPGeneral_Implementation();

produces this:

1>C:\Users\cedric\Documents\Unreal Projects\yag 4.7\Source\yag\game/YagGameState.h(49)( : warning C4996: Function YagGameState::ServerSetupYagFdPGeneral_Implementation needs native implementation by virtual void ServerSetupYagFdPGeneral_Implementation_Implementation() due to its properties. Currently ServerSetupYagFdPGeneral_Implementation_Implementation declaration is autogenerated by UHT. Since next release you'll have to provide declaration on your own. Please update your code before upgrading to the next release, otherwise your project will no longer compile.

Notice the function_Implementation_Implementation: the macro now thinks my function name is now function_Implementation and wraps it with a new _Implementation, but still recognizes the same cpp code with no error.



Have not tested 4.7 yet but here is a snip for you from 4.x - 4.6

	UFUNCTION(Server, Reliable, WithValidation)
		void SERVER_SetPlayerHealth(float NewHealth);

void AMyPlayerClass::SERVER_SetPlayerHealth_Implementation(float NewHealth)

bool AMyPlayerClass::SERVER_SetPlayerHealth_Validate(float NewHealth)
	return true;


Thanks, but if i am not mistaken, that’s exactly what i am currently doing (see the code in my initial post). Worked well until 4.6, but generates warnings in 4.7.



Did you tried to switch Reliable and WithValidation attributes ? UBT can be sometimes picky about order things in UFUNCTION() or UPROPERTY().

Good idea, but unfortunately the warning is still there after the switch.

I have idea.
Change passing by reference, to passing by value and see of that fix it.

Good one too :slight_smile:
But with server rpc you have to use const ref for FStrings.
Anyway, the warnings don’t depend on arguments, i have a lot of server rpc’s in my code, some with arguments, some without, and they all give warnings since 4.7.

I think we need to choch this up to a Preview build issue.
the rest of the C++ changes are coming for 4.7 so am guessing its due to that.

I whould report it on AnswerHub just in case.

Might be an issue in 4.7 because your code seems good.

You can check on the other hand the source code and see how they are doing RPC call in 4.7

I’m pretty sure this is because you’ve declared your function in the header file, already with the ‘_Implementation’ suffix. You only do that in the .cpp and the compiler/VAX will automatically figure out what it’s supposed to do.

If I’m right then you’re getting the build error because it’s adding _Implementation on again in the compilation process and it can’t find that function. I’m guessing that in 4.7 UBT has been changed slightly to not bother checking if you’ve already added _Implementation on… maybe

Hey all !

@WCode: yes, i am starting to think something like that. I was hoping for some official confirmation, just to know if this pb is worth the time i spend on it. Those warnings are annoying, i can’t see my errors, ha ha !

@Elvince: good idea, i’ll try to check that tonight

@TheJamsh: i don’t think so. The initial code (see the initial post) was ok, the added _Implementation came later as tries to get rid of the warnings.

Cheers !


PS: i actually started with a answerhub question 3 days ago with no success, so i tried the forum.

Ahh I see, my mistake. In that case I can’t see an issue with it either then… Elvince & WCode have the right idea :slight_smile:

Edit: Also… that’s Answerhub for you :stuck_out_tongue: I often double post here and on answerhub and usually the forum yields a better discussion about it (that’s if answerhub even get’s a response!), especially programming related things!

You need to do this:

UFUNCTION(Server, WithValidation, Reliable)
void ServerSetupYagFdPGeneral();

virtual void ServerSetupYagFdPGeneral_Implementation();

In 4.6 this part virtual void ServerSetupYagFdPGeneral_Implementation(); was auto generated, but it is no longer, which is why you now need both declarations. The first method and UFUNCTION prompts UE to create all the rpc code and search for a [Function Name]_Implementation method to call.

In short, the cpp part can stay how it was, but you need to create two declarations for an rpc now.


Hm. I’m using lots of RPCs I’m also using 4.7, and it works just fine without explicit declaration of virtual void _Implementation.

@FTC: thanks, but i had already tried this, it gives a compilation error, something like “member function already defined”.

@Iniside: the usual code works for you in 4.7 ? So there is something wrong somewhere in my pc^^
Someone else has the same problem here:

So something needs to be clarified anyway, as for me the warnings appeared in 4.7 with no change on my side.
To be continued… :slight_smile:


@uced: That should be the it, maybe you need to clean your solution and rebuild it entirely. I have had problems with the unreal header tool not deeming it necessary to generate the headers correctly until I fully rebuild.

@Iniside: Yes, the code still works, as in runs, but the deprecation warnings indicate that it will no longer in 4.8.

Hey FTC,

I did retry, clean, rebuild, no success.

Here is my exact code:

UFUNCTION(Server, WithValidation, Reliable)
	void ServerSetupYagFdPGeneral();

virtual void ServerSetupYagFdPGeneral_Implementation();


bool AYagGameState::ServerSetupYagFdPGeneral_Validate(){ return true; }
void AYagGameState::ServerSetupYagFdPGeneral_Implementation(){SetupYagFdPGeneral();}

And the messages i get:

1>C:\Users\cedric\Documents\Unreal Projects\yag 4.7\Source\yag\game/YagGameState.h(80): error C2535: 'void AYagGameState::ServerSetupYagFdPGeneral_Implementation(void)' : fonction membre déjà définie ou déclarée
1>          C:\Users\cedric\Documents\Unreal Projects\yag 4.7\Source\yag\game/YagGameState.h(49) : voir la déclaration de 'AYagGameState::ServerSetupYagFdPGeneral_Implementation'

The messages are in french so they come from VS, not from UE4.
“fonction membre déjà définie ou déclarée” means “member function already defined or declared”
“voir la déclaration de” means “see declaration of”

I am a beginner in c++ and have no experience with the virtual keyword. From what i understood on the net, when overridding a method, the virtual keyword allows to ignore the type of the pointer and always call the derived method.
So my guess would be that the story goes like that:
4.6: the macro adds void ServerSetupYagFdPGeneral_Implementation();
4.7: the macro generates a warning and adds void ServerSetupYagFdPGeneral_Implementation() override;
4.8: the macro will add nothing and will gives us a warning telling us to suppress the virtual keyword

In this scenario my “already defined” error would mean that the macro forgets to add the override kw behind its own declaration. But if anyone of you guys manages to compile with no errors and no warnings, my guess is wrong. With my current knowledge i can’t come up with a better scenario :slight_smile:

I don’t know if “virtual” and “override” allow to override the method in the same namespace though. It’s the sort of knowledge experience gives you and i don’t have.
Appareantly VS doesn’t appreciate.

I might be entirely wrong, again, i’m still a padawan in this field^^