We’ve had the same issue (difficult to resolve conflicts in the single-line JSON embedded in the YAML of the FSM asset file). I think that having the serialisation source option to pick between a TextAsset or storage internal to the FSM asset sounds reasonable, but only if the _serializedGraph field in the FSM asset is empty if using the TextAsset as the source. If you continue to serialise to the internal field (as a copy) as well as the TextAsset, that would mean that you would still get conflicts that git / perforce / etc. would find difficult to resolve automatically in the FSM asset file, while the TextAsset with pretty-printed JSON might well be resolved automatically.
I can see the benefits of keeping the default option as an internal serialisation in the FSM asset (e.g. the Unity object references are serialised in the same file as the indices into that array making it harder for things to be out of sync), but it would really be useful to be able to have something that merges cleanly without a lot of extra effort. Keeping internal serialisation as the default would also ensure backwards compatibility with existing assets.
Login
Register
By registering on this website you agree to our Privacy Policy.