Getters/setters are for blueprints only. We’re not calling them but instead rely on the engine property reflection to get/set raw values.
Server
1) Yes, we have a shadow copy of the source state too to determine what changed. Typically via the property Identical as mentioned
2) Quantize reads from the shadow copy of the source data
3) Yes, it can only access the quantized form of the data (regardless of whether that representation is the same as the source data or not)
Client
1) Yes.
2) Yes
3) Yes, into a temporary instance of the source data form. It’s still not operating on the game target data!
4) Yes. From my perspective I only ever required a few serializers to implement Apply. I do have a couple of cases where I needed to implement a custom fragment instead to avoid doing very expensive temporary copies of arrays… If you have a lot of structs with the delegate then I’m afraid Apply is going to be a common for you to implement.
FGameplayCueParameters. Yes it looked good enough from my perspective to avoid implementing a NetSerializer. One big caveat with custom serializers is that because UE reflection doesn’t provide a hash or anything one must manually detect via custom code if a struct has changed and the serializer needs revision. So not implementing one if one can avoid it can be a big maintenance win.
Cheers,
Peter