I have a base class that goes smth. like this (BaseClass.h):
UCLASS()
class UBaseClass : public UObject
{
GENERATED_UCLASS_BODY()
public:
/** Some base method.*/
UFUNCTION(Server, Reliable, WithValidation)
virtual void Damage();
...
Now this will generate _Validate() and _Implementation() functions in the header which I have to implement in the BaseClass.cpp:
void UBaseClasse::Damage_Implementation()
{
UE_LOG(LogTemp, Warning, TEXT("Empty method stub. Should not be called."));
}
bool UBaseClass::Damage_Validate()
{
UE_LOG(LogTemp, Warning, TEXT("Empty method stub. Should not be called."));
return true;
}
There is a child class that inherits from the BaseClass which provides the actual implementation of the Damage() method: ChildClass.h
UCLASS()
class UChildClass : public UBaseClass
{
GENERATED_UCLASS_BODY()
public:
bool Damage_Validate() override;
void Damage_Implementation() override;
...
Now overriding the Damage_Implementation method is not a problem since UFUNCTION macro defined it as virtual. But Damage_Validate() method is not! Is there a particular reason for this?
Note: UBaseClass is kind of an interface so the use case looks smth. like:
// Somewhere in the header MyVar variable is of UBaseClass type
UBaseClass* MyVar;
...
// An instance of the UChildClass is created
MyVar = ConstructObject<UBaseClass>(UChildClass::StaticClass());
By design in that it was felt that _Validate could be performed on the data regardless of the behavior of class. I may be stretching
A bug, and we just need to change our header tool to emit a virtual on it.
In the case where there is no input to validate, it may be moot for you. The intent of the function is to do basic “cheat/hack/invalid” detection of the input parameters and let the engine know whether or not you want to proceed with the call itself. With no params, there isn’t much to check, aside from maybe state that dictates you couldn’t/shouldn’t call it at this time.
update consensus declares it a bug, so we’ll look to update that when possible
Well, I’d say it’s definitely a bug And I’ve simplified my example - the actual Damage() method has parameters. By the way it’s the row number 3478 in CodeGenerator.cpp that needs a fix
Unrelated to this bug: _Validate as you said is supposed to detect “cheat/hack/invalid input parameters”. And it will disconnect the player in case parameters are invalid. Which is kind of harsh thing to do because parameters can be invalid due to other reasons other than cheating or hacking. Is it also by design?
Thanks, it’s been added to our bug tracking to fix this issue.
As for the intent of the _Validate code, it is as you understand it. I don’t disagree that it may be a little harsh, and it is possible through a bug in the game for invalid parameters to be passed in RPC. You can always return true regardless.
It’s a new feature that we’ve added in UE4 and as we try to use our own features, and get feedback from others, we’ll see if it needs improvement or possible redesign.
Thanks, it’s been added to our bug
tracking to fix this issue.
Thank you. Is the bug tracker open to watch to for non-epic devs? Any chance this fix will be done before 4.4?
And I’ve simplified my example - the actual Damage() method has parameters. By the way it’s the row number 3478 in CodeGenerator.cpp that needs a fix