I have a problem with the leap motion plugin. Everything works fine in the editor but after we package the game, without any error, the leap hands are not shown. I made several empty projects in multiple computer but still nothing. The setup is really simple. An empty project and a BS_LowPolyHand in the middle. After starting simulation everything is fine but after packaging the project the hands are not shown.
We are using the latest plugin for 4.19 with 4.0 SDK and the leap motion control center says everything is fine. Diagnostic Visualizer works as well. We tried it with 2 different leap motions and more than 3 computers.
I also draw a debug sphere to the L_Palm socket and it stays at the same position after the package like there is no incoming signal from the leap motion.
Hi,
Did you try to go back to the old version of Leap SDK 3.2.1 ?
I was able to work with my leap motion in my editor, but same, nothing appears in package.
I’m using the UE4.18 version and I had the issue having the SDK 4.0 installed on my computer. Going back to Leap SDK 3.2.1 made my package works with the hands.
I was getting the same issue but I found the correct solution. This is not a packaging problem, it is a driver incompatibility problem.
I had a known, working packaged build where leap motion was tracking hands. This was running on UE4.19.2, and I was using the Leap Motion 2.0 plugin which is included with the engine. I was using the Orion 3.2.1 drivers. Everything worked.
Recently, I upgraded my leap motion drivers to Orion 4.0.0 and continued to use the Leap Motion 2.0 plugin within the engine. In development, this works perfectly find. When I create a packaged build, I have no hand tracking. I rolled back my Leap Motion drivers to Orion 3.2.1 and retried the packaged build and it worked just fine.
So, you have two options:
Download the latest Leap Motion plugin from Github and update your plugin version (compatible with Orion 4.0.0)
Roll back your Leap Motion drivers to Orion 3.2.1 and tell your customers/clients to do the same
Option 1 is more future facing, but it may break things in your current build. Option 2 will get you up and running right away, but will potentially cause end user confusion and create more support calls.
