[Bug] ReflectionsTools.cs

NodeCanvas Forums Support [Bug] ReflectionsTools.cs

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #13551
    psykaw
    Participant

    I think there is a bug in ReflectionsTools.cs::GetType()

    It shouldn’t be “return typeMap[typeFullName] = type;”?

    #13552
    Gavalakis
    Keymaster

    Hey!

    The idea here, is that we do not replace the name/type lookup, for another possible type that exists in it’s correct FullName that we inquire it for. If we replace a failed lookup that returned due to FallbackNoNamespace with a FullName we requested, then we are essentially replacing all further lookups with that requested FullName, to point to a previously found type failed by namespace, instead of the actual type that exists in the correct namespace (FullName) we inquire it for.
    That was the idea at least and it could be possible that I misjudge something here 🙂
    Let me know if want to elaborate further.

    Thanks!

    Join us on Discord: https://discord.gg/97q2Rjh

    #13560
    psykaw
    Participant

    Hey,

    I don’t understand because if you found a type due to fallbackNoNamespace you don’t use the typeFullName which is bad. You have to cache it to not lookup twice or more for the next time you have the same typeFullName. So the best solution is to do this:

    PS: I edited my NodeCanvas version to avoid resolution type by attribute(DeserializeFromAttribute) or without namespace. It causes a huge CPU spike when I instanciate a blackboard at runtime. Could it be resolved at serialization or something like that but not at runtime?
    And for ReflectionTools::GetDirectType() it could be resolved quickly if you concat assembly name of the type at the end separated with a comma. Ex: Type.GetType(“UnityEditor.ProfilerWindow,UnityEditor.dll”).

    #13562
    Gavalakis
    Keymaster

    Hello,

    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

Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.