article

1807605288 avatar image
1807605288 posted

SDK Update Blog Feedback

This is the feedback forum for discussion about the recent SDK Update Blog.

If you have any questions or comments about the announced changes, please post them here.

(PLEASE NOTE, the blog post is not public yet, but the link will work soon)

sdks
17 comments
10 |1200

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

1807605288 avatar image 1807605288 ♦ commented ·

There is now an upgrade guide

0 Likes 0 ·
1807605288 avatar image 1807605288 ♦ 1807605288 ♦ commented ·

UPDATED: Removed an unnecessary step about memory management (testing seems to indicate it's not necessary, and we added a fix to the next build which will definitely make it irrelevant)

0 Likes 0 ·
Montana Tuska avatar image Montana Tuska commented ·

Alright, so for starters, the fact that UFUNCTION's is now a solid requirement means anyone not using a UObject based class is simply screwed. My OnlineSubsystem can't use UObject. Also, you can't call functions without specifying callbacks and the customData object. These should just default to blanks/nullptr, since some calls don't need callbacks or customData. I'm trying to prototype a nice resolution to the UFUNCTION issue for now.

0 Likes 0 ·
1807605288 avatar image 1807605288 ♦ Montana Tuska commented ·

It's my understanding that Unreal garbage collection requires all references to UObjects to be from other UObjects. In the Blueprint SDK, everything has to be UObjects to work with blueprints at all. Not using UObjects means using your own memory management, which is probably more natural for many C++ programmers.

I'm not sure how we will resolve this long term, but for the short term, the two SDKs will continue to exist with their independent patterns and requirements.

0 Likes 0 ·
Montana Tuska avatar image Montana Tuska commented ·

I spent a while thinking about this, and I decided I'll just use your SDK Generator and maintain my own C++ SDK. This way I get to strip out that useless FMultitypeVar and replaced with a Json value struct handler and a few other changes.

0 Likes 0 ·
1807605288 avatar image 1807605288 ♦ Montana Tuska commented ·

We are aware that FMultitypeVar is very weak, and that was one of our reasons for trying to discontinue the CPP SDK. The Blueprint SDK has a better solution, but as we discovered, the C++ calls don't work properly.

0 Likes 0 ·
Patches avatar image Patches commented ·

It wasn't clear from the strikeout text exactly what is happening with the C++ version of this SDK. For those of us considering PlayFab with our Unreal game, this is a red flag. Are you planning on full parity between C++ versions of the SDK and the blueprint versions?

Having the C++ SDK is more useful since we can debug the source ourselves if needed...

0 Likes 0 ·
Montana Tuska avatar image Montana Tuska Patches commented ·

Well, now since people are kinda wanting it, I will make a public gitlab that you guys can take a look at. I have no intent to maintain backwards comparability however. Though I will keep different branches for previous versions in case people want to use that.

https://gitlab.com/mtuska/PlayFab-UnrealCPP/tree/master

0 Likes 0 ·
1807605288 avatar image 1807605288 ♦ Patches commented ·

It's a big problem, I agree, and apologize for the delay. The two SDKs are incompatible with one another, and both are incomplete. They're also both not built correctly for submission to the Unreal Marketplace.

Ultimately our only choice is to start over with a new SDK built correctly from the ground up, but we won't be able to even begin this process for potentially months.

For the foreseeable future, both original SDKs will continue to exist. We will make another attempt to update the CPP SDK to 4.17 as soon as possible, but this too will likely be delayed as other SDKs were prioritized ahead of it.

0 Likes 0 ·
Kain avatar image Kain commented ·

Looking forward to having those issues with UnrealCPPSDK fleshed out. This was our introduction to PlayFab, and it was a bit of a rude awakening. If not for that blog post about the current status and intent to address those issues, we would have been a lot more concerned about the prospect of adopting PlayFab for our Unreal 4.17 C++ centric project.

0 Likes 0 ·
Montana Tuska avatar image Montana Tuska Kain commented ·

Well, now since people are kinda wanting it, I will make a public gitlab that you guys can take a look at. I have no intent to maintain backwards comparability however. Though I will keep different branches for previous versions in case people want to use that.

https://gitlab.com/mtuska/PlayFab-UnrealCPP/tree/master

1 Like 1 ·
1807605288 avatar image 1807605288 ♦ Kain commented ·

The primary PlayFab product is the API, and the online service. We have one employee managing all of the SDKs, and Unreal is not at the top of the maintenance list. This is just an unfortunate reality based on the distribution of our customers.

We'll do our best to try to get these issues worked out for you as fast as we can.

0 Likes 0 ·
Kain avatar image Kain Kain commented ·

I totally empathize with the difficulty of having one employee maintain API wrappers for all of the constantly changing SDKs. Now that I've had some time to work with the UnrealBPSDK, I think I came on a little too strong in my post above. The provided API wrappers for the Unreal engine are actually quite simple to follow with its recurring patterns of calls and delegate handlers. It serves as an excellent starting point for us... especially when it came to all of the http and json wrangling in C++.

<darn that 1200 word limit>

0 Likes 0 ·
Show more comments
Show more comments

Article

Contributors

1807605288 contributed to this article

Related Articles