Leap motion is not working in packaged project
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.
Do you have any idea what can cause this?
asked Oct 17 '18 at 06:26 PM in Packaging & Deployment
Actually i was able to solve this problem by accidentally adding the built in python scripting plugin. I have no idea why this is a sollution though :)
answered Oct 31 '18 at 02:46 PM
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:
1) Download the latest Leap Motion plugin from Github and update your plugin version (compatible with Orion 4.0.0)
2) 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.
answered Nov 17 '18 at 02:51 AM
Follow this question
Once you sign in you will be able to subscribe for any updates here