docs: document scriptable objects (#1494)

This commit is contained in:
Paul Pacheco 2020-02-12 08:39:38 -06:00 committed by GitHub
parent 22c8d3da5f
commit 6aa2d001e2
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -11,6 +11,8 @@ Mirror supports a number of data types you can use with these, including:
- NetworkIdentity
- Game object with a NetworkIdentity component attached.
- Structures with any of the above (it's recommended to implement IEquatable\<T\> to avoid boxing and to have the struct readonly, cause modifying one of fields doesn't cause a resync)
- Classes as long as each field has a supported data type.
- ScriptableObject as long as each field has a supported data type
- Arrays of any of the above (not supported with syncvars or synclists)
- ArraySegments of any of the above (not supported with syncvars or synclists)
@ -144,9 +146,11 @@ public static class ItemSerializer
## Scriptable Objects
People often want to send scriptable objects from the client or server. Mirror will not generate a reader and writer for scriptable objects because there is no generic way to tell how to create or load the scriptable object.
People often want to send scriptable objects from the client or server. For example, you may have a bunch of swords created as scriptable objects and you want put the equipped sword in a syncvar. This will work fine, Mirror will generate a reader and writer for scriptable objects by calling ScriptableObject.CreateInstance and copy all the data.
A typical use case is to create scriptable objects in the Resources folder. The scriptable objects may have arbitrarily large amount of data. If you pass them in a `Command` or `Rpc`, typically you want both sides to load the same scriptable object from the Resources folder. To do this, create a custom Reader and Writer for your type. For example:
However the generated reader and writer are not suitable for every occasion. Scriptable objects often reference other assets such as textures, prefabs, or other types that can't be serialized. Scriptable objects are often saved in the in the Resources folder. Scriptable objects sometimes have a large amount of data in them. The generated reader and writers may not work or may be inneficient for these situations.
Instead of passing the scriptable object data, you can pass the name and the other side can lookup the same object by name. This way you can have any kind of data in your scriptable object. You can do that by providing a custom reader and writer. Here is an example:
```cs
[CreateAssetMenu(fileName = "New Armor", menuName = "Armor Data")]
@ -155,6 +159,7 @@ class Armor : ScriptableObject
public int Hitpoints;
public int Weight;
public string Description;
public Texture2D Icon;
// ...
}
@ -162,13 +167,13 @@ public static class ArmorSerializer
{
public static void WriteArmor(this NetworkWriter writer, Armor armor)
{
// no need to serialize the data, just which armor it is
// no need to serialize the data, just the name of the armor
writer.WriteString(armor.name);
}
public static Armor ReadArmor(this NetworkReader reader)
{
// load the same armor. The data will come from the asset in Resources folder
// load the same armor by name. The data will come from the asset in Resources folder
return Resources.Load<Armor>(reader.ReadString());
}
}