Automatic Converter/List Support For MDRpc & MDRset

[Beider]

By default you can't send custom classes or lists with RPC, it would not be difficult to add a feature to MDRpc where if it detects a custom class or a list we automatically try to resolve the relevant converter or in the case of a list send it as a special mode so it is reassembled as a list on the other end.

Suggested Implementation

• Check if what we are sending is a list/dictionary (Don't forget MDList / MDDictionary), if so turn on list/dictionary sending mode (recursive so List<List<string>> would work)
• Check if what we are sending/content of list is outside of the System / Godot workspace, if so resolve converter.
• Send the data to a custom rpc function in the MDReplicator that accept some settings at the start that sets sending mode (eg. list / dictionary) and also converter to use.

This should allow us to send any type of data with MDRpc

More Detail

One way to do this would be to just implement something like a command replicator that we already have. You would have an enum describing what is being sent and add length as well. So for instance if you send a Dictionary<string, List<MyClass>> and you have two string keys + two custom classes for each string key the data might look something like this.

[0] = ModeEnum.Dictionary#string#MyClass#22 // Start of the dictionary, type <string, MyClass> next 22 values are dictionary
[1] = ConvertEnum.NativeValue#1         // First dictionary key, native value so no converter, length 1
[2] = "KeyString1"              // The dictionary key
[3] = ModeEnum.List#8               // Start dictionary value for first key, type list, length 8
[4] = ConvertEnum.CustomClass#MyClass#3     // First value in list, converter of type MyClass, length 3
[5] = data from custom class converter (1)  // Data for converter
[6] = data from custom class converter (2)  // Data for converter
[7] = data from custom class converter (3)  // Data for converter
[8] = ConvertEnum.CustomClass#MyClass#3     // Second value in list, converter of type MyClass, length 3
[9] = data from custom class converter (1)  // Data for converter
[10] = data from custom class converter (2) // Data for converter
[11] = data from custom class converter (3) // Data for converter
[12] = ConvertEnum.NativeValue#1        // Second dictionary (Same deal as above, won't repeat comments)
[13] = "KeyString1"
[14] = ModeEnum.List#8
[15] = ConvertEnum.CustomClass#MyClass#3
[16] = data from custom class converter (1)
[17] = data from custom class converter (2)
[18] = data from custom class converter (3)
[19] = ConvertEnum.CustomClass#MyClass#3
[20] = data from custom class converter (1)
[21] = data from custom class converter (2)
[22] = data from custom class converter (3)

[Beider]

In scope of this bug we also want to extend the DataConverter registry in MDStatics. A method to add custom converters should be added so we don't need to add new MDRpc and MDRset with custom convert parameters as well.

Something like, MDStatics.AddDataConverter(Type ConverterForType, IMDDataConverter TheConverterInstance)

[Beider]

We should consider having two sending modes, if everything is inside System or Godot namespace we send as is. If anything is outside of that namespace we send with data converters. This would allow for enum/custom class support.

[DoubleDeez]

Would the mode be detected automatically based on the params?

[Beider]

I suppose, we can just do a namespace check on all of the parameters, if any parameter is outside of the Godot or System namespace we send in Data Converter mode, if not we just send with a standard Rpc call. We can at least test it, I have no idea how that would work if you send a Godot enum across the network, would have to test it. Maybe we also have to do an enum check to see that there are no enums.

[DoubleDeez]

Yeah seems like that's the right approach, enum check and namespace check