refactor: internally breaking, send no longer has client obj parameter #407
Conversation
|
what does "internally breaking" mean? |
|
To my thinking, internally breaking just means code that's internal to the project has a (slight in this case) API change. I guess it does ask the question whether users would ever call InternalMessaging.Send() themselves. If so, it's a regular breaking change. |
oh okay, I see. well, they can't because they are entirely internal static class InternalMessageSenderinternal static class InternalMessageHandler |
|
For the record, in a slack convo w/ @TwoTenPvP on the question of break the current AOI system before bringing in the new one, I wrote... At least from what I could see, the part that is being removed is a 'just before transmission' check if the target object has visibility for that client id and from looking at the code, that seemed to be a final last-ditch check in case other parts of the library don't filter it first. e.g. NetworkedObject.cs checks for this in 9 places, so does NetworkedBehaviour.cs, in particular before updating network variables or sending RPCs So I didn't think I was removing / breaking AOI so much as removing that one last safeguard to clean up the send interface and prepare for the new AOI stuff Or to put it another way, seemed to me the role of send is to, well, send, and the elements above it should be on the hook for filtering what gets sent. @TwoTenPvP was going to check my work and then help me understand whether this would break (current) AOI |
|
|
After working on the AOI stuff, it dawned on me that passing in the client object into send is less and less useful. In fact I think we can remove it.