Hello,
we’ve been experimenting with/evaluating OSSv2 for our next project and found some uncertainties in the current transition state. In general, as far as I understand it, OSSv2 currently only has native support for EOS, Null and some consoles, while all other online platforms are handled by the single OnlineServicesOSSAdapter class, which internally only wraps the OSSv1 platform-specific subsystem. That’s where we see the issue, however, as the platform-specific OSSv1 implementations varied quite heavily, which was basically one of the top reasons we wanted to try OSSv2 out, to see whether the interface-pain situation has improved.
One such example which we’ve already found is that OnlineSubsystemSteam (OSSv1) used IOnlineLeaderboards to write stat values (which could possibly be linked to achievement progress/unlocking in the backend) but it didn’t have a IOnlineStats-implementing class at all, but the OSSv2 adapter internally attempts to use the latter when writing out stats regarding achievement unlocks. This means, in the current state, you can’t unlock Steam achievements with OSSv2 at all, because the calls would internally end in an non-existent IOnlineStats interface if directly attempted to write via IStats::UpdateStats. IAchievements::UnlockAchievements could be attempted to be used instead, but that API both doesn’t support progress anymore (compared to OSSv1 IOnlineAchievements::WriteAchievements) and also is just not implemented at all in the adapter or its FAchievementsCommon base class.
I’m afraid we’re just scratching the tip of the iceberg here and we’d find a lot of similar issues when more platforms and their different approaches to OSSv1 interface implementations would get added to the mix, all attempted to be handled by a single adapter class. An obvious solution to this would be to just write our own adapters for other subsystems or heavily modify the adapter to handle these per-platform quirks, but that would just take us the same route that OSSv1 did, having to write custom wrappers for a lot of things.
From the quick research we’ve done on UDN, it seemed that OSSv2 was already being used by quite a lot of people, so we were under the impression it’s more production-ready across the board, but that currently seems to be true only with EOS platform or totally custom implementations. This finally leads to the questions:
1) Is there perhaps something painfully obvious that I’ve missed when attempting to use OSSv2 with Steam, i.e. not using the adapter at all but a different kind of approach? If not, is OSSv2 expected to have native support for Steam soon, or is it not yet on the timeline?
2) Is there an expected engine version planned for OSSv2 to go out of beta already?
3) When OSSv2 goes out of beta, will OSSv1 instantly get deprecated with it, or will there be some transition period while both will be maintained? In other words, does it still make sense to just use OSSv1 in a fresh project now, even if it will most likely update the engine version at least once in the future?
4) What’s the status of console implementations of OSSv2, should we consider them to be “beta” as well, or are they more in the “experimental” zone? Will they take longer to get out of beta, or will they be production ready at the same time as the “main” plugin? I didn’t want to make separate posts asking this in each relevant console group, hence I’m talking quite vaguely about consoles.
Thanks in advance for any insights:)
[Attachment Removed]