Hi Gavalakis, no problem. I use it in NodeCanvas FSM to trigger a condition from one state to another. I want to use it to pass a Vector3 via a dynamic var in FSM. The Vector3 is the position where the HoloLens gaze touches the HoloLens spatial map.
The class that fires the Unity event provides the position upon an airtap and this is correctly received in other non-NodeCanvas methods that are connected to the Unity event. However it does not fire in NodeCanvas when build for HoloLens. In Unity Play it does fire. So what I do now as a workaround is store this position somewhere else and fire a non-parameter Unity event, which does work in NC with HoloLens. This is a little dirty code so I would very much like UnityEvent<Vector3> to work in NC.
Strange isn’t it. I could dig into the code, was just wondering if you know if any reason why this does not work, e.g. compiler directives set for UNITY_WSA.
Hmm. This is strange indeed. I can’t really come by any reason why this would not work in NC specifically, since there is no special/explicit code that would stop a UnityEvent<T> from working in UWP for example.
Can you please post for me your code in how you are using the UnityEvent more specifically in regards to NC so that I can check it out?
I presume it is a custom ConditionTask that subscribes to the UnityEvent in it’s OnEnable and unsubscribes in it’s OnDisable, and when it is fired it makes the condition return true, or something entirely different?
Hi Gavalakis, remember this issue? It is much worse and very easy to reproduce: Even direct assignment of blackboard variables bool, int and float do not work in HoloLens/UWP. Assignment of string vars does work. Assignement of an int var in another way, like via the return value of a component method does work.
Please note that as of version 2.9.1, support for native UWP (meaning NETFX_CORE), has been removed and is now only possible to built for UWP via IL2CPP backend. The reason for the native UWP support removal was because native UWP was the only platform that required an excessive amount of extra (and almost duplicate) code and the codebase was becoming unmanageable. However building to UWP is still possible via IL2CPP.
Thank you and I hope this is not an issue for you.
Thanks, but this is not the issue, we switched to IL2CPP a year ago already, especially because you do not support it (and Unity depcrecated it). So the bug is still there, also with IL2CPP
Have you built the required AOT classes (as well as link.xml) files via the Preferred Types Editor? IL2CPP is an AOT compiler and as such this is also a requirement for that. From your information provided this since to be the case, but please let me know 🙂