* NetworkIdentity.isServer simplified via one flag instead of helper variable + netId check
* simplify teardowns
* NetworkIdentityTests can set isServer directly now
* networkbehaviourtests simplified
* NetworkServerTests can set isServer directly now
* remove comment
* fix#1484: revert isServer simplifiy. Fixes a bug where isServer was already false in OnDestroy, but we need sometimes still need it there to save skillbars etc.
* update comment
* failing tests for virutal methods used by syncvar hook
* replacing Assert.fail to stop OnDeserialize failed error
* adding tests to make sure classes are set up correctly
* fix: call overriden hooks
Use a virtual call for hooks. fixes#1581
Co-authored-by: Paul Pacheco <paulpach@gmail.com>
* Move comments to the previous Lines
We have a mix of comments at on the previous line and at the end of
the line. We need to "pick one way and stick with it".
Per the C# code guidelines, comments go on the previous line. See here:
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/inside-a-program/coding-conventions
This also makes pull requests more readable since comments are less
likely to wrap
There are no code changes here, just a search and replace for all comments
This also makes cloc counts more accurate as it can better determine
how many lines of comments vs code we have
* Update Assets/Mirror/Components/NetworkTransformBase.cs
* Update Assets/Mirror/Examples/ListServer/ListServer.cs
* Update Assets/Mirror/Tests/Editor/WeaverTests~/TestingScriptableObjectArraySerialization.cs
* Update Assets/Mirror/Tests/Editor/WeaverTests~/TestingScriptableObjectArraySerialization.cs
* Adding check to make sure weaver adds code
* tests for network behaviour
* marking methods as static
* adding comment to method body
* making Weaver internal
* replacing string
Once upon a time, connections could be null here. This is no longer
the case, connections always have something,
Even if they were null, this method would not work at all because
the conn.Send call at the bottom would throw NRE.
Therefore the null checks here are unnecesary
Since messages behave similar to events and given the process is not technically breaking, using LogError seems incorrect. Using Log, maybe LogWarning would be more appropriate. Added additional text to clarify why the user may be seeing that log entry.
