You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The main thing here is that we should make sure that comments written on microservice Callables propagate all the way to C++ and BP nodes in the client.
That being said, we can explore other things such as:
Declaring federation ids as easily accessible constants fields
Allowing users to flag constants in microservices that get put into the OAPI Schema as extensions that then get generated as static const in UE.
Declaring Stubs for a few UE types such that they can be generated as such: SoftObjectPath, GameplayTags, FVector3f, etc...
We have a few of these for Unity. We should do the same for UE --- these should become primitives in the UE code-gen pipeline.
Allowing users to flag semantic types via Attributes or hard-coded Struct wrappers (BeamGamerTag, BeamAccountId, etc...)
Same as the stubs thing, but... these would be encoded in the OAPI just like the backend does today.
In addition to this, we should generate a Runtime Subsystem for the microservice. This should expose each endpoint as an operation as well as expose an interface that allows extending its functionality (see new RuntimeSubsystem extension hooks ticket). But... this might not be worth doing depending on how the extensibility feature pans out (see #166 )
The goal here is to make usage of C#MS more in-line with other Runtime Subsystems as well as enabling finer-grain control of the output code to make it more UE-friendly.
The main thing here is that we should make sure that comments written on microservice Callables propagate all the way to C++ and BP nodes in the client.
That being said, we can explore other things such as:
static constin UE.In addition to this, we should generate a Runtime Subsystem for the microservice. This should expose each endpoint as an operation as well as expose an interface that allows extending its functionality (see new RuntimeSubsystem extension hooks ticket). But... this might not be worth doing depending on how the extensibility feature pans out (see #166 )
The goal here is to make usage of C#MS more in-line with other Runtime Subsystems as well as enabling finer-grain control of the output code to make it more UE-friendly.