question

Garrett Fleenor avatar image
Garrett Fleenor asked

UE4-cpp blueprint nodes crash and other issues (PlayFabProxy module),The "PlayFabProxy" Module in the Unreal CPP SDK is broken and crashy

Ok, this module is all kinds of busted.

First off, for every node, there is a PlayerController parameter that isn't used and isn't useful. That can just be removed.

Secondly, every node crashes on call, as every parameter is passed as a const reference. This crashes the blueprint runtime. They should be passed by value except in rare circumstances.

Additionally, the UPFClientRegisterPlayFabUser::RegisterPlayFabUser function has this line of code

*Proxy->Request.InfoRequestParameters = InInfoRequestParameters.Data;

Which is _completely_ wrong. It's trying to store a local reference into a TSharedPtr, which starts off by crashing when you dereference a null ptr, but this data wouldn't persist past the end of the stack frame. It should look something like this:

Proxy->Request.InfoRequestParameters = MakeShareable(new PlayFab::ClientModels::FGetPlayerCombinedInfoRequestParams(InInfoRequestParameters.Data));

Finally, the functions only return data on success, not on failure. So if a call fails, you have no idea why, only that it does.

Doing a combined C++/Blueprint project is currently impossible without writing your own blueprint nodes with the Unreal C++ SDK.

,

I'm playing around with the C++ Unreal Integration, and the PlayFabProxy module is just nonsensical.

All of the static Proxy call functions have a param list where all of the parameters are const references of whatever their type is. (ie, const FString&, const bool&, etc). This causes a number of issues, like having to pass in a variable into the blueprint call.

Secondly, because all of the params are const references, any calls into those blueprint nodes instantly crash in the Unreal Engine's generated blueprint exec function!

Also, every node requires a PlayerController, which nothing makes use of. That should probably be removed.

Also, the PFClientRegisterPlayFabUser::RegisterPlayFabUser has this line:

*Proxy->Request.InfoRequestParameters = InInfoRequestParameters.Data;

Which is _completely_ wrong. Proxy->Request is a TSharedPtr<>, which is being deref'd (a crash), and then assigned a const reference from an object that exists on the stack and dies after this function completes.

The proper code should be something like this:

Proxy->Request.InfoRequestParameters = MakeShareable(new PlayFab::ClientModels::FGetPlayerCombinedInfoRequestParams(InInfoRequestParameters.Data));

I've just scratched the surface on these functions. It looks like this code is auto generated, and it's just crashy and wrong. Trying to do a combined C++ and Blueprint project with the C++ SDK is currently impossible.

10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

1 Answer

·
1807605288 avatar image
1807605288 answered

I'm going to break this down into a few discrete answers.

You're right. The UnrealCppSdk isn't designed for blueprints. That SDK was donated to us by a customer, whose primary usage was just C++, and not blueprints. If you wish to use Blueprints, you should use the UnrealBlueprintSdk. Otherwise, the specific code you're referencing is unfinished. I admit, it should not have been released in this form. Looking at the code and the generator, it's clear that blueprints won't work in the UnrealCppSdk.

You're right. The UnrealCppSdk (and all of our SDKs) is (are) auto-generated. Thus, if there's an error then the error is probably in the generator.

The best answer for you is that we have two Unreal SDKs, and neither is perfect. If you wish to use Blueprints, use UnrealBlueprintSdk. It is possible to make PlayFab API calls from C++ using the blueprint SDK, but it's awkward and not ideal. If you wish to use C++ exclusively, and don't intend to use blueprints at all, then you should use UnrealCppSdk. As you've already discovered, the blueprints there don't really work at all.

Unfortunately they are deeply structurally different from one another, and if you are already deeply invested in one, conversion to the other is going to be difficult.

Your frustrations are pretty much why we have two separate SDKs for two distinct use case scenarios. Both of those SDKs were provided by other customers who were more familiar with Unreal than any of our current employees, and who sought to solve their own specific use-cases.

We would be happy to review and accept any changes that would make blueprints in the UnrealCppSdk functional. The relevant SdkGenerator files are here:
https://github.com/PlayFab/SDKGenerator/blob/master/targets/cpp-ue4/make-bp.js
https://github.com/PlayFab/SDKGenerator/tree/master/targets/cpp-ue4/templates/blueprint

As you have seen our Unreal SDKs are not as fully mature as our others, which is also reflected by those SDKs still being released as "version 0.0.date". We have done our best to maintain those SDKs since customer submission, but we don't have an Unreal expert on staff to make significant improvements.

In conclusion, it sounds like you need the UnrealBlueprintSdk. If you wish to make improvements to the C++ SDK, I'll work with you on that. Over half of our SDKs were originally customer submitted, and nearly all have had improvements submitted directly from customers.

10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.