-
Notifications
You must be signed in to change notification settings - Fork 459
fix: if-guard NetworkManager.__rpc_name_table access
#1056
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -19,14 +19,11 @@ public class NetworkManager : MonoBehaviour, INetworkUpdateSystem, IProfilableTr | |
| // RuntimeAccessModifiersILPP will make this `public` | ||
| internal static readonly Dictionary<uint, Action<NetworkBehaviour, NetworkSerializer, __RpcParams>> __rpc_func_table = new Dictionary<uint, Action<NetworkBehaviour, NetworkSerializer, __RpcParams>>(); | ||
|
|
||
| #if UNITY_EDITOR || DEVELOPMENT_BUILD | ||
|
|
||
| #if DEVELOPMENT_BUILD || UNITY_EDITOR | ||
| // RuntimeAccessModifiersILPP will make this `public` | ||
| internal static readonly Dictionary<uint, string> __rpc_name_table = new Dictionary<uint, string>(); | ||
| #else // !(UNITY_EDITOR || DEVELOPMENT_BUILD) | ||
| // RuntimeAccessModifiersILPP will make this `public` | ||
| internal static readonly Dictionary<uint, string> __rpc_name_table = null; // not needed on release builds | ||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. we kept this field for the old ILPP implementation (pre-2020.3 ILPP, targeting 2019.4) because we needed it for |
||
| #endif // UNITY_EDITOR || DEVELOPMENT_BUILD | ||
| #endif | ||
|
|
||
| #pragma warning restore IDE1006 // restore naming rule violation check | ||
|
|
||
| #if DEVELOPMENT_BUILD || UNITY_EDITOR | ||
|
|
@@ -35,7 +32,6 @@ public class NetworkManager : MonoBehaviour, INetworkUpdateSystem, IProfilableTr | |
| private static ProfilerMarker s_TransportConnect = new ProfilerMarker($"{nameof(NetworkManager)}.TransportConnect"); | ||
| private static ProfilerMarker s_HandleIncomingData = new ProfilerMarker($"{nameof(NetworkManager)}.{nameof(HandleIncomingData)}"); | ||
| private static ProfilerMarker s_TransportDisconnect = new ProfilerMarker($"{nameof(NetworkManager)}.TransportDisconnect"); | ||
|
|
||
| private static ProfilerMarker s_InvokeRpc = new ProfilerMarker($"{nameof(NetworkManager)}.{nameof(InvokeRpc)}"); | ||
| #endif | ||
|
|
||
|
|
@@ -1263,10 +1259,12 @@ internal void InvokeRpc(MessageFrameItem item, NetworkUpdateStage networkUpdateS | |
|
|
||
| __rpc_func_table[networkMethodId](networkBehaviour, new NetworkSerializer(item.NetworkReader), rpcParams); | ||
|
|
||
| #if DEVELOPMENT_BUILD || UNITY_EDITOR | ||
| if (__rpc_name_table.TryGetValue(networkMethodId, out var rpcMethodName)) | ||
| { | ||
| NetworkMetrics.TrackRpcReceived(item.NetworkId, networkObjectId, rpcMethodName, item.StreamSize); | ||
| } | ||
| #endif | ||
| } | ||
| } | ||
| } | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This definitely fixes it for me.
I'm assuming it's the
NetworkManager.NetworkMetricsis null?What I don't know is if the tools team indeed intended this to be dev / editor only. I dunno, maybe they would want to be able to track RPCs in a production app? @becksebenius-unity ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We compromised on this one because there was a fairly long-winded discussion about whether the additional memory footprint of rpc names should exist in release builds - and since the Profiler (the only tool being released with this version) is only enabled in Development builds, we decided to close the conversation and go this route. It does seem fairly unlikely that we would need the names of RPCs reported in any tool other than the profiler, but that remains to be seen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we might bring them back once we justify their use-cases and even then, we might follow a different approach to reduce memory footprint (thinking aggressive inlining here).