Crazy that I stumbled upon this trying to get info about Slate Remote, but I have quite a lot of info from my travels through remote control!
I had to implement a system recently that needed to work similar to remote control, but needed to be a bit faster and less safe and not be stuck using the message format JSON that remote control requires. It’s a nice and flexible system but I didn’t need all the jazz so I butchered it into something that “worked”.
Essentially at a low level the plugin is leveraging the reflection system to set values via reflection.
There is a FieldPath struct that is used to recursively find a void* to the value inside of a container in order to achieve this. IE you have a float UPROPERTY() inside a struct so the field path calls itself recursively to get 3 things. The Owning struct, the container address and the field (which is basically an FProperty*)
You can find the function that is setting property values and getting them in the module.cpp file.
All the different protocols get stacked on top at a higher level but eventually they all come down and set/get via that system.
There’s also a lot of checks to find the object whether you are in PIE or not (Basically tries to find the object counterpart in the PIE work from the Editor Object or vice versa)
To get the type safety correct there’s a bunch of casts from FProperty to check if it’s the right type IE FFloatProperty.
I have notices that remote control isn’t trying to be runtime friendly, but technically speaking everything is setup to work. I would suggest making a subsystem that handles storing your Entities and then can register them with the remote control module when need be. Preferably in code also you are handling setting up the server yourself so you can ensure some behavior. If you have an actor do all this you might have trouble with handling map changes etc.