* perf: NetworkIdentity DirtyComponentsMask code removed entirely. OnSerialize now includes the component index as byte before serializing each component. Faster because we avoid GetDirtyComponentsMask() and GetSyncModeObserversMask() calculations. Increases allowed NetworkBehaviour components from 64 to 255. Bandwidth is now smaller if <8 components, and larger if >8 components. Code is significantly more simple.
* Update Assets/Mirror/Runtime/NetworkIdentity.cs
Co-authored-by: James Frowen <jamesfrowendev@gmail.com>
Co-authored-by: James Frowen <jamesfrowendev@gmail.com>
* Users must initialize syncobjects (#391)
Previously we initialized syncobjects, so this is valid:
```cs
public class Pepe : NetworkBehavior {
public SyncList<int> mylist;
}
```
With this change, users must initialize their own fields:
```cs
public class Pepe : NetworkBehavior {
public SyncList<int> mylist = new SyncList<int>();
}
```
BREAKING CHANGE: You must initialize all your SyncLists
* Add null check
* This is no longer a weaver error
* Update Assets/Mirror/Runtime/NetworkBehaviour.cs
Co-authored-by: James Frowen <jamesfrowendev@gmail.com>
* Remove unnecesary using
Co-authored-by: James Frowen <jamesfrowendev@gmail.com>
* Server Teleport Enchancement for NetworkTransform
Related to this issue: https://github.com/vis2k/Mirror/issues/2200
* Improvements on NetworkTransformBase
We disable clientAuthority until teleportation is finished and acknowledged. We set the goal and start data points to null before teleportation.
We set the clientAuthority back to it's initial value registered on server, both on the server and client side; it seems like we don't need to change it to anything on Client side because to my understanding clientAuthortiy is not affecting anything on client side. I may be wrong but still it is a great practice to set it back to it's initial value just in case...
* Added teleportation with rotation
I forgot to add a rotation functionality on my previous commit. It wouldn't be a teleportation without also changing the rotation. If provided a rotation input it will teleport with a rotation, if not it will simply protect the original rotation before the teleportation.
* Removed my debug statement
I forgot to remove the debug log statement lol silly me
* fixing up code
* resetting goal and last pos on server and client
* renaming variables
* making sure TeleportFinished can't request authority at any time
* moving teleport block
* removing duplicate lines
Co-authored-by: Emre Bugday <47198270+EmreB99@users.noreply.github.com>
* breaking: no need to override Serialize/Deserialize in messages
Messages no longer serilize themselves. This has been decoupled. Serializing a message is now done
via readers and writers, which can be either generated or user provided.
This lifts some restrictions,
* you no longer need to have a default constructor in messages
* Messages types can be recursive
* struct Messages don't need to provide an empty Serialize and Deserialize method
Before:
```cs
public struct ReadyMessage : IMessageBase
{
public void Deserialize(NetworkReader reader) { }
public void Serialize(NetworkWriter writer) { }
}
```
After:
```cs
public struct ReadyMessage : IMessageBase
{
}
```
BREAKING CHANGE: Messages must be public
BREAKING CHANGE: Use custom reader and writer instead of Serialize/Deserialize methods
* Remove unused method
* remove unused methods
* remove unused methods
* make all messages struct
* Fix test code generator
* Get rid of MessageBase
* Rename IMessageBase -> NetworkMessage
* add MessageBase as obsolete
* Use a default request
* Empty file to make asset store happy
* Apply suggestions from code review
Co-authored-by: James Frowen <jamesfrowendev@gmail.com>
Co-authored-by: James Frowen <jamesfrowendev@gmail.com>
* Fixed OnStopClient not being called on Client Side
* Moved identity.OnStopClient() two scopes above
Co-authored-by: Emre Bugday <47198270+EmreB99@users.noreply.github.com>
* feat: Use SyncLists directly
Previously, you had to write an intermediary class to use synclists, syncsets and syncdictionaries.
The weaver would populate that intermediary class with a serialization and deserialization method
This PR gets rid of 90% of the weaver code for synclists.
There is no need to generate these methods anymore.
Instead the lists use `writer.Write<T>` and `read.read<T>` to serialize their Data.
Since there is no code generate in synclists, you can now use the synclists directly instead
of subclassing them.
BEFORE:
```cs
public class MyComponent : NetworkBehaviour {
// nonsense class to make the weaver happy
class SyncListData : Synclist<Data> {}
SyncListData mySyncList;
}
```
AFTER:
```cs
public class MyComponent : NetworkBehaviour {
Synclist<Data> mySyncList;
}
```
* linting
* feat: Use SyncLists directly (no overrides)
Previously, you had to write an intermediary class to use synclists and syncdictionaries.
The weaver would populate that intermediary class with a serialization and deserialization method
This PR gets rid of 90% of the weaver code for synclists.
There is no need to generate these methods anymore.
Instead the lists use `writer.Write<T>` and `read.read<T>` to serialize their Data.
Since there is no code generate in synclists, you can now use the synclists directly instead
of subclassing them.
Same as #2305 ,but it removes the deprecated Serialize and Deserialize methods from syncobjects,
This way you get a nice compiler error for the code that no longer works, instead of a warning you might accidentally ignore.
BEFORE:
```cs
public class MyComponent : NetworkBehaviour {
// nonsense class to make the weaver happy
class SyncListData : Synclist<Data> {}
SyncListData mySyncList;
}
```
AFTER:
```cs
public class MyComponent : NetworkBehaviour {
Synclist<Data> mySyncList;
}
```
BREAKING CHANGE: Serialize and Deserialize methods in synclists don't do anything anymore
* Remove old comment
* Fix compilatio error
Currently in mirror, there is no way for Mirror itself to invoke
readers and writers for types it does not know about.
This causes us to have to generate code for lists, dictionaries and messages.
This PR makes it so that if there is a reader and writer anywhere in the
code for type X, then the writer can be invoked like this:
```cs
X x = ...;
writer.Write<X>(x);
```
and the reader can be invoked like this:
```cs
X x = reader.Read<X>();
```
* fix: generic arguments lookup
The weaver was not able to figure out the synclist type in code like this:
```cs
public class SomeList<G, T> : SyncList<T> { }
public class SomeListInt : SomeList<string, int> { }
```
This code fixes that problem, and greatly reduces the complexity
of argument lookup.
* linting
