I’ll start with your original questions:
1. There’s a lot here.
- FOnlineServiceCommon’s LoadConfig is intended as a way to configure the individual components/operations with a hierarchy corresponding to the OnlineServices/Interface/Component/Operation so that common values can be set at any layer. In addition, it provides overrides (AddConfigSectionOverride) that can be used to provide values unique to a specific runtime configuration. For example, we use that to select a configuration for the specific backend/environment that the game is running in. To dynamically enable/disable components, I could see us adding a general per-component setting here that could be used to disable a component.
- An example of how the config and the overrides work is as follows. Say that you want to use the OnlineServicesEOSGS leaderboards. You want to adjust the operating caching policy for it, setting different amount of times for how long you want the result of a JoinableOperation to be cached.
; DefaultEngine.ini [OnlineServices.EOS] ; define defaults for the entire oss, only reuse a result if the operation has been called with the same parameters while it is in flight CacheExpiration=UponCompletion bCacheError=false [OnlineServices.EOS.Leaderboards] ; define defaults for all operations in the leaderboard interface, reuse the result if it is called with the same parameters within 5 minutes CacheExpiration=Duration CacheExpirySeconds=300 [OnlineServices.EOS.Leaderboards:Development] ; provide an override when AddConfigSectionOverride("Development") is called, reusing the result if it is called with the same parameters within 10 seconds CacheExpirySeconds=10
- OnlineServices is very much GConfig driven, so it wouldn’t exactly cover your user stories with data assets, but it could possibly work with inis + the config section overrides, along with some additional logic to enable/disable components based on that.
- You could implement a different config provider (IOnlineConfigProvider) for your implementation that utilizes data assets and register it via FOnlineServicesCommon::SetConfigProvider to have a non-GConfig based approach for configuring it.
- As for adding blueprint defined/implemented interfaces, I could see a couple approaches:
- If the specific interface can be defined in code, define the interface, make a basic implementation of the apis and then internally use a UObject based pimpl that can be extended by BP.
- I’ll have to spend some more time investigating this, but we could look at adding support for data defined interfaces (for example, an interface defined in blueprint). It would involve extending the component registry with an additional component registration path that has a runtime/data defined type name and appropriate hooks so that systems like the exec handler could also extend to the data defined interface operations.
2. UObjects were avoided for a couple reasons:
- It allows OnlineServices to be utilized in lightweight programs/commandlets that do not need to initialize the engine and/or UObjects.
- The available types are not limited to those supported by UHT, which enables us to use more standard types (eg, TVariant) without needing to wrap them or create an equivalent USTRUCT
3. There are not any visual tools yet, but we are hoping to develop some in the future, such as being able to inspect the internal state, run scriptable scenarios, have a ui for running the various operations on the interfaces (the common layer already provides exec commands for this), and tracing the operations.
And for your latest questions:
1. Common is not necessary, but is intended to be the base on which to build an OnlineServices implementation. You will be missing out on some features if you don’t utilize it. For example, the hooks to the exec system are all handled by that. Future tools may also be built in the common layer.
2. I agree that TOnlineAsyncOp should only reference the IOnlineServices interface and not FOnlineServicesCommon. I have created an internal ticket for us to address this in a future release.