Skip to content

feat: Added GenerateSerializationForGenericParameterAttribute and GenerateSerializationForTypeAttribute #2694

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 8 commits into from
Oct 2, 2023

Conversation

ShadauxCat
Copy link
Collaborator

@ShadauxCat ShadauxCat commented Sep 7, 2023

This enables users to control the generation of serialization code through codegen, making it easier to create their own network variable subtypes, and also making it possible for them to easily generate serialization for specific types they know they need to use. NetworkVariable and NetworkList have been changed to use these attributes so they are no longer special cases in our codegen.

This PR also exposes methods in NetworkVariableSerialization<T> to further support this type of serialization need.

resolves #2686

Changelog

  • Added: Added GenerateSerializationForGenericParameterAttribute, which can be applied to user-created Network Variable types to ensure the codegen generates serialization for the generic types they wrap.
  • Added: Added GenerateSerializationForTypeAttribute, which can be applied to any class or method to ensure the codegen generates serialization for the specific provided type.
  • Added: Exposed NetworkVariableSerialization<T>.Read, NetworkVariableSerialization<T>.Write, NetworkVariableSerialization<T>.AreEqual, and NetworkVariableSerialization<T>.Duplicate to further support the creation of user-created network variables by allowing users to access the generated serialization methods and serialize generic types efficiently without boxing.
  • Added: Added NetworkVariableBase.MarkNetworkBehaviourDirty so that user-created network variable types can mark their containing NetworkBehaviour to be processed by the update loop.

Testing and Documentation

  • Includes unit tests.
  • Includes documentation for previously-undocumented public API entry points.

…teSerializationForTypeAttribute`

This enables users to control the generation of serialization code through codegen, making it easier to create their own network variable subtypes, and also making it possible for them to easily generate serialization for specific types they know they need to use. NetworkVariable and NetworkList have been changed to use these attributes so they are no longer special cases in our codegen.

This PR also exposes methods in `NetworkVariableSerialization<T>` to further support this type of serialization need.

resolves #2686
@ShadauxCat ShadauxCat requested a review from a team as a code owner September 7, 2023 16:39
@@ -584,15 +584,15 @@ public void Write(FastBufferWriter writer, ref T value)
{
if (UserNetworkVariableSerialization<T>.ReadValue == null || UserNetworkVariableSerialization<T>.WriteValue == null || UserNetworkVariableSerialization<T>.DuplicateValue == null)
{
throw new ArgumentException($"Type {typeof(T).FullName} is not supported by {typeof(NetworkVariable<>).Name}. If this is a type you can change, then either implement {nameof(INetworkSerializable)} or mark it as serializable by memcpy by adding {nameof(INetworkSerializeByMemcpy)} to its interface list. If not, assign serialization code to {nameof(UserNetworkVariableSerialization<T>)}.{nameof(UserNetworkVariableSerialization<T>.WriteValue)}, {nameof(UserNetworkVariableSerialization<T>)}.{nameof(UserNetworkVariableSerialization<T>.ReadValue)}, and {nameof(UserNetworkVariableSerialization<T>)}.{nameof(UserNetworkVariableSerialization<T>.DuplicateValue)}, or if it's serializable by memcpy (contains no pointers), wrap it in {typeof(ForceNetworkSerializeByMemcpy<>).Name}.");
throw new ArgumentException($"Serialization has not been generated for type {typeof(T).FullName}. This can be addressed by adding a [{nameof(GenerateSerializationForGenericParameterAttribute)}] to your generic class that serializes this value (if you are using one), adding [{nameof(GenerateSerializationForTypeAttribute)}(typeof({typeof(T).FullName})] to the class or method that is attempting to serialize it, or creating a field on a {nameof(NetworkBehaviour)} of type {nameof(NetworkVariable<T>)}. If this error continues to appear after doing one of those things and this is a type you can change, then either implement {nameof(INetworkSerializable)} or mark it as serializable by memcpy by adding {nameof(INetworkSerializeByMemcpy)} to its interface list to enable automatic serialization generation. If not, assign serialization code to {nameof(UserNetworkVariableSerialization<T>)}.{nameof(UserNetworkVariableSerialization<T>.WriteValue)}, {nameof(UserNetworkVariableSerialization<T>)}.{nameof(UserNetworkVariableSerialization<T>.ReadValue)}, and {nameof(UserNetworkVariableSerialization<T>)}.{nameof(UserNetworkVariableSerialization<T>.DuplicateValue)}, or if it's serializable by memcpy (contains no pointers), wrap it in {typeof(ForceNetworkSerializeByMemcpy<>).Name}.");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Not required suggestion)
Not a blocker, but it might be worth while making this exception a const that is used in this and the next two argument exceptions...up to you but it does seem like it might be less problematic in the very....very very...off chance that the message needs to be adjusted.

Copy link
Collaborator

@NoelStephensUnity NoelStephensUnity left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

@@ -580,19 +580,24 @@ public class UserNetworkVariableSerialization<T>
/// <typeparam name="T"></typeparam>
internal class FallbackSerializer<T> : INetworkVariableSerializer<T>
{
private void ThrowArgumentError()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😻

@ShadauxCat ShadauxCat enabled auto-merge (squash) October 2, 2023 20:48
@ShadauxCat ShadauxCat merged commit 5a2b607 into develop Oct 2, 2023
@ShadauxCat ShadauxCat deleted the feat/user_serialization_generation_attributes branch October 2, 2023 21:07
NoelStephensUnity added a commit that referenced this pull request Oct 5, 2023
…GenerateSerializationForTypeAttribute` (#2694)

This enables users to control the generation of serialization code through codegen, making it easier to create their own network variable subtypes, and also making it possible for them to easily generate serialization for specific types they know they need to use. NetworkVariable and NetworkList have been changed to use these attributes so they are no longer special cases in our codegen.

This PR also exposes methods in `NetworkVariableSerialization<T>` to further support this type of serialization need.

resolves #2686

---------

Co-authored-by: Noel Stephens <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Custom Network Variables do not trigger Code Generation for Network Serialization
2 participants