Skip to content

refactor!: remove network variable settings, network behaviour cleanup #1097

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 10 commits into from
Aug 26, 2021

Conversation

mattwalsh-unity
Copy link
Contributor

No description provided.

@mattwalsh-unity mattwalsh-unity requested a review from 0xFA11 August 26, 2021 18:52
@@ -425,7 +425,7 @@ internal void InitializeVariables()
sortedFields[i].SetValue(this, instance);
}

instance.NetworkBehaviour = this;
instance.Initialize(this);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Don't want NetworkBehaviour to be exposed, want tighter control over this

@@ -624,15 +624,15 @@ private bool CouldHaveDirtyNetworkVariables()
return false;
}

internal static void HandleNetworkVariableDeltas(List<NetworkVariableBase> networkVariableList, Stream stream, ulong clientId, NetworkBehaviour logInstance, NetworkManager networkManager)
internal void HandleNetworkVariableDeltas(Stream stream, ulong clientId, NetworkBehaviour logInstance)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Besides just generally making more sense as an instance method, if and when we remove NetworkBehaviour dep from NetworkVariable, this will make it much easier for reasons that were clear to me as I experimented doing so

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, this appears to have been jammed in for logging messages so I can clean up further

@@ -717,20 +717,20 @@ internal static void HandleNetworkVariableDeltas(List<NetworkVariableBase> netwo
}
}

internal static void WriteNetworkVariableData(List<NetworkVariableBase> networkVariableList, Stream stream, ulong clientId, NetworkManager networkManager)
internal void WriteNetworkVariableData(Stream stream, ulong clientId)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Same story here, no good reason to make this static

writer.WritePadBits();
}
}
}
}
}

internal static void SetNetworkVariableData(List<NetworkVariableBase> networkVariableList, Stream stream, NetworkManager networkManager)
internal void SetNetworkVariableData(Stream stream)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Same story here, cleaner as instance method

@@ -222,7 +222,7 @@ public void HandleNetworkVariableDelta(ulong clientId, Stream stream)
}
else
{
NetworkBehaviour.HandleNetworkVariableDeltas(instance.NetworkVariableFields, stream, clientId, instance, NetworkManager);
instance.HandleNetworkVariableDeltas(stream, clientId, instance);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is unclear to me if this second 'instance' parameter (which is the log instance) makes sense. We only call this HandleNetworkVariableDeltas method once, which is here. Do we sometimes want a different instance for this log behaviour than this?

m_DirtyEvents.Add(dictionaryEvent);
}

m_DirtyEvents.Add(dictionaryEvent);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

It just doesn't seem to be the right abstraction that the dictionary should know how many clients are connected. I would prefer the decision to be made 'upstream' even if it means a slight performance cost when no clients are connected, which seems like a performance-not-important moment anyway

/// <summary>
/// The temporary accessor to enable struct element access until [MTT-1020] complete
/// </summary>
public ref T ValueRef
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Forgot to remove this in my prev PR

// demolish me
// or better setter?
internal protected NetworkBehaviour NetworkBehaviour { get; internal set; }
private protected void EnsureInitialized()
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Avoids being replicated in all the container classes. I suppose we could have a new subclass just for containers and put this in it, but didn't seem worth it

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Again I think we can nuke this from @MFatihMAR 's observation

@@ -291,6 +291,12 @@ internal NetworkObject CreateLocalNetworkObject(bool isSceneObject, uint globalO
// Ran on both server and client
internal void SpawnNetworkObjectLocally(NetworkObject networkObject, ulong networkId, bool sceneObject, bool playerObject, ulong? ownerClientId, Stream dataStream, bool readNetworkVariable, bool destroyWithScene)
{
networkObject.IsSceneObject = sceneObject;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This initialization should happen up here before we call SetNetworkVariableData. Technically, yes, since we still have a NetworkBehaviour ref in each NetworkVariable the old code works because we don't access the NB until after these initializations. However it's not good practice, and if and when we break the NB dependency this initialization has to happen up here

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Matt will reconsider if we want to be this daring to move this up here

@@ -475,14 +465,6 @@ public int LastModifiedTick
return NetworkTickSystem.NoTick;
}
}

private void EnsureInitialized()
Copy link
Contributor Author

Choose a reason for hiding this comment

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

We think we can just nuke this

@mattwalsh-unity mattwalsh-unity enabled auto-merge (squash) August 26, 2021 20:47
@mattwalsh-unity mattwalsh-unity enabled auto-merge (squash) August 26, 2021 21:58
@mattwalsh-unity mattwalsh-unity merged commit 15d5bef into develop Aug 26, 2021
@mattwalsh-unity mattwalsh-unity deleted the feature/remove_netvar_settings branch August 26, 2021 22:51
SamuelBellomo added a commit that referenced this pull request Sep 2, 2021
…nsform

* develop: (26 commits)
  fix: client connected InvokeOnClientConnectedCallback with scene management disabled (#1123)
  fix: removed `public` class `NetcodeObserver` (MTT-1157) (#1122)
  feat: add NetworkMessageSent/Received metrics (#1112)
  feat: snapshot. MTU sizing option for Snapshot. MTT-1087 (#1111)
  Add metrics for transport bytes sent and received (#1104)
  fix: Missing end profiling sample (#1118)
  chore: support standalone mode for netcode runtimetests (#1115)
  feat: Change MetricNames for a more complex value type (#1109)
  feat: Track scene event metrics (#1089)
  style: whitespace fixes (#1117)
  feat: replace scene registration with scenes in build list (#1080)
  fix: mtt-857 GitHub issue 915 (#1099)
  fix: NetworkSceneManager exception when DontDestroyOnLoad NetworkObjects are being synchronized (#1090)
  feat: NetworkTransform Custom Editor Inspector UI (#1101)
  refactor: remove TempGlobalObjectIdHashOverride (#1105)
  fix: MTT-1124 Counters are now reported in sync with other metrics (#1096)
  refactor: convert using var statements to using var declarations (#1100)
  chore: updated all of the namespaces to match the tools package change (#1095)
  refactor!: remove network variable settings, network behaviour cleanup (#1097)
  fix: mtt-1088 review. Safer handling of out-of-order or old messages (#1091)
  ...

# Conflicts:
#	com.unity.netcode.gameobjects/Prototyping/NetworkTransform.cs
mollstam pushed a commit to Keepsake-Games/com.unity.netcode.gameobjects that referenced this pull request Feb 13, 2023
Unity-Technologies#1097)

* refactor!: remove network variable settings, network behaviour cleanup
* remove ensure initialized
* moved init, removed unused var
* refactor!: remove network variable settings, network behaviour cleanup
* remove ensure initialized
* whitespace / include fixes
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.

2 participants