* 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
Remove all the recursionCount nonsense.
This was added to prevent infinite recursion with types that reference themselves.
No need to check anymore, the weaver can generate readers and writers for types that reference themselves such as:
```cs
class Tree {
Tree child1;
Tree child2;
}
```
This works by the weaver doing it the way the compiler does: Create a function first, memoize it, then write the body. If the body needs the function, it will get itself and issue a call to itself.
Currently, whenever we want to serialize an enum,
we simply serialize the underlying type (byte, short, int)
This works fine, but in order to get the reader and writer
at runtime I need a function for each type.
With this PR, we generate a reader and writer function for enums too,
the function body simply calls the underlying reader and writer.
* throwing Exception instead of returning null
* re-adding null check until later PR
* removing error from test
* removing extra error
* adding comment
* replacing error with throw for abstact
The plan is to remove WeaverLists at some point so moving the functions
out of weaver to here for now and then move them closer to where they
are actaully used when we start to remove WeaverLists.
