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)
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)
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)
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.
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.
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.
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.
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...
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.
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.
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.
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.
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.
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>
Contributors
1 Person is following this article.
