Maybe you are right and I am wrong in this :). I will need to re-think this with a clear mind.
Regarding [DeserializeFromAttribute], it is uber slow indeed, but is only called if there is a request for a missing type FullName, that has not been resolved. Normally, OnAfterDeserialize in the editor though, the correct “found” type is Serialized back and as such would no longer result as “missing” and thus not fallback to using [DeserializeFromAttribute] any longer. For your information, this is taking place in the “fsRecoveryProcessor” class, which handles this for Nodes, Connections, Tasks, BBParameters and Blackboard Variables.
Can you please let me know the stack from which the [DeserializeFromAttribute] resolution is called from?
Thanks!
Join us on Discord: https://discord.gg/97q2Rjh
Login
Register
By registering on this website you agree to our Privacy Policy.