Baking and code generation
Last updated
Was this helpful?
Last updated
Was this helpful?
Out of the box, coherence will use C# Reflection to sync all the data at runtime. This is a great way to get started but it is very costly performance-wise.
Fresh projects require to bake at least once to generate reflection mode support (and generate a valid Schema ID).
For optimal runtime performance, we need to create a schema and perform code generation specific to our project. Learn more about this in the How does coherence work section.
coherence offers an automatic way of doing that called baking.
Click on coherence -> Schema and Baking -> Bake Schemas
.
This will go through all CoherenceSync
components in the project and generate a schema file based on the selected variables, commands and other settings. It will also take into account any LODs
added.
For every prefab with a CoherenceSync
object, the baking process will generate a bespoke C# file in the coherence/baked
folder in the project.
Adding that file to the prefab will make that prefab use bespoke generated code instead of C# reflection.
Once the Schema has been baked, you will be able to switch to baked mode in the CoherenceSync inspector.
The name of the baked script will be CoherenceSync[prefabName]
.
When you bind to your script's fields and bake, coherence generates specific code that accesses your code directly, without using reflection. This means, whenever you change your scripts, you might break compilation.
For example, if you have a Health.cs
script which exposes a public float health;
field, and you mark health
as a binding in the Bindings window, the baked script will access your component via type name, and your field via field name.
Your baked script might now reference your component:
This means that if you decide to change your component name (Health
) or any of your bound field names (health
), Unity script recompilation will fail. In this example, we will be deprecating health
and adding health2
in its place.
Our watchdog is able to understand when this happens, and offer you a solution right away.
It will suggest you to bake in safe mode, and then diagnose the state of your prefabs. After a few seconds of script recompilation, you'll be presented with the diagnosis window.
In this window, you can easily spot bindings in your prefabs that are no longer valid. In our example, health is no longer valid since we've moved it elsewhere (or deleted it).
Click on the hand pointing button to open the bindings window, and take a look at your script:
Now, we can manually rebind our data: unbind health
and bind health2
. Once we do, we can now safely bake again.