Download

[Plugin] Myo

Development Discussion Engine Source & GitHub
#1

An event-driven plugin for the Thalmic Myo. Has a modern rewritten architecture since v0.9.0 see the github repo for documentation and examples.

Let me know what you think, and what improvements should be included, or if you can, contribute and extend the code!

NB: Currently only supports Windows 64 & 32 Platform.

Download
Latest Version

Older
0.7.14 for UE4.10
0.7.13 for UE4.9 Myo Connect 1.0
0.7.12 for UE4.8 Myo Connect beta-9
0.7.10 for UE4.7 Myo Connect beta-9
0.7.7 for UE4.6 Myo Connect beta-8
0.7.6 for UE4.5 Myo Connect beta-7
0.7.2 for UE4.5 Myo Connect beta-6
0.7.2 for UE4.5 Myo Connect beta-5
0.7 for UE4.5 Myo Connect beta-4
0.6.3 for UE4.4
0.6 for UE4.3

Documentation & How To
See the Github repository - Contains Plugin Source, Releases, and Documentation

Old Resources
Myo Connect and device firmware - ensure these are up to date.
Thalmic Myo Unleashed Blog Post - How to add Myo support to your project in under a minute.
Thalmic UE4 Plugin Thread
Quick How To Example

*Changelist

0.9.1*
-Compile fixes for 4.19
-Documentation updated for v0.9
-Suppressed default pose log to reduce spam

0.9.0
-modern rewrite for 4.18 that runs on a separate thread in a input module scoped architecture.
-Mainly accessed through a MyoControllerComponent, but bare basics can be implemented using only input mapping.
-supports latest Myo SDK v0.9.0 including raw emg
-supports multiple myos
-hot-pluggable myo connect and hub
-bare bones documentation for now, explore code MyoControllerComponent.h and MyoController.hfor how-to.
-auto-casting blueprint conversions from data to controller to call actions such as vibrate device

0.7.14
-Synced binaries with UE4.10

0.7.13
-Updated to work with myo connect 1.0. The pitch/roll are now correctly
reversed
-Code fixes for UE4.9 compile

0.7.12
-Should no longer crash in the cases where Myo Disabled is emitted but no
delegate is set.

0.7.11
-Update to UE4.8

0.7.10
-Update to Myo 0.9

0.7.9
-Added a work around that fixes the UE editor crash if you do not have Myo Connect running when you begin play. This will allow for safe integration of myo with multiple other plugins.

0.7.8
-updated binary for UE 4.7
-moved convenience content into the plugin, delete if you do not want to
use it and wish to save space.
-updated myo sdk bind to 0.8.1

0.7.7
-Myo SDK bind updated to beta 8
-Now supports raw streams see readme for documentation
-Added convenience content called Myo Utility BP Library, which has convenience functions for debug output.
-Updated documentation, check github readme

0.7.6
-Packaged file fix by removing try/catch block. No longer needed since
Myo Connect handles hot plugging of hub

0.7.5
-removes C4273 suppression by including SlateCore in build rules

0.7.4
-Contains compile fixes to sync code base to UE4.6. Note that warning
C4273 is suppressed due to 4.6 changes to Input Mapping.
-Syncs Myo SDK to Beta 7 (0.7)
-As per 0.7 Thumb to Pinky is now DoubleTap
-Added locking mechanism, this plugin defaults to none, but you can call
SetLockingPolicy on your MyoComponent to change this on say BeginPlay.
-As per 0.7 Added Lock/Unlock functions on MyoController class
-Arm Orientation space now persists throughout PIE sessions, will only
get lost when quitting app.

0.7.3
-As per 0.6, onArmRecognized and onArmLost is now onArmSync and
onArmUnsync
-Tested with Myo firmware 1.0.3

0.7.2
-Minor code consistency fix
-Added platform white list
-added gitignore

0.7.1
-This update syncs the plugin to beta-5, update your myos to firmware
0.8.17 or later to use with this plugin.
-Fixed unpairing event issues caused by beta-3, now supports full
features again.

0.7
-Converted entire architecture to support component based extension in
blueprints, please refer to the documentation
-Each event now emits a UMyoController pointer allowing for additional
controller data to be obtained in the context of the event and to also
easily perform checks such as IsLeftMyo
-Updated to UE4.5
-MyoComponent/Convenience base classes can now obtain left/right and
primary myo as a convenience.

0.6.3
-Fixed arm space orientation to work with myo attached to arm in any direction. Requires doing the setup gesture to detect arm and direction.
-Fixed bodySpaceNull acceleration (component space acceleration without gravity), after calibration this will report the expected acceleration.
-Added calibration direction, allowing you to calibrate in arbitrary orientation relative to the user facing screen (e.g. calibration in facing direction is R(R0,P0,Y0) and pointing right is a R(R0,P0,Y90) rotator)
-Input Mapping will now use the last paired myo as input
-Fixed Play In Editor myo spam caused by waiting a long while with a paried myo before playing. Myo will now correctly initialize only on BeginPlay()

0.6.2
-Added support for multiple myos, tested with up to 3. Use blueprint events for multiple myos as input mapping uses only primary myo.
-Added xArmDirection to raw myo device data
-Fixed PIE spam caused by stopping and resuming after a long duration; the hub will be destroyed between sessions.
-Added preliminary support for calibrated values. Call MyoCalibrateArmOrientation(int32 myoId) when arm is facing the screen, after which all arm and body values are calibrated, some values are not fully correct at this stage, use with care.

0.6.1
-Updated to 4.4

0.6

  • First Public Release, bound to beta-1 SDK.

Todo
-Confirm shipping/packaging works with the plugin.
-Move Hub to separate thread (removing the current 1ms performance penalty)
-Video
-Add wiki on subject

#2

Thanks for posting this. I did not know about the Myo and may order one now :slight_smile:

#3

Updated now to beta-4 sdk which added support for multiple myos and made some plugin bug fixes (will no longer crash when you don’t have the hub connected, reduced PIE spam between sessions, etc).

Video, wiki, and tutorial still pending.

Edit:
Update 0.6.3 brings all the necessary bug fixes to use calibrated values and removed all PIE spam.

Expect a video soon showing how to use the device!

#4

Major update to 0.7
-Converted entire architecture to support component based extension in
blueprints, please refer to the documentation
-Each event now emits a UMyoController pointer allowing for additional
controller data to be obtained in the context of the event and to also
easily perform checks such as IsLeftMyo
-Updated to UE4.5
-MyoComponent/Convenience base classes can now obtain left/right and
primary myo as a convenience.

See the Thread post for how to use the new API.

With the new API you can for example show a debug myo orientation like this

with a Draw Orientation function like this

which gives the following result in the Rolling template

Note in this example two myos were paired and the orientation was obtained from calibrated values thus needed a calibration call to each myo when the user was pointing them toward the screen (e.g. point to screen and bind calibration to make fist).

Edit:
Plugin Update to 0.7.1
-This update syncs the plugin to beta-5, update your myos to firmware
0.8.17 or later to use with this plugin.
-Fixed unpairing event issues caused by beta-3, now supports full
features again.

#5

Getnamo,

Thank you for the Myo plugin and for providing setup instructions on how to use this awesome toy. I really appreciate it! In following the tutorial, it seems the Myo Arm Orientation (arrow and box) is off (not pointing forward when I point the Myo forward). You mentioned “calibration” above. Is there a way to set the initial arm orientation at start or maybe a way to re-orient to a forward position by making a pose?

#6

This is what calibration does exactly. The problem with an IMU-based vs a direct position controller is that you have no fixed reference to your forward direction (only to the magnetic north). So to make sure your input is calibrated for your forward direction all you have to do is point your arm forward and call the calibration function. You can, for example, bind that to pressing F or the thumb to pinky pose key/event. then after calibration your arm space positions will automatically be calibrated for both forward orientation and the roll offset around your wrist (your myo may be rotated around your wrist arbitrarily). Before calibration is called however the arm space values output the raw ones instead, which is why you see them pointing in a wrong direction.

Here’s an example of how to calibrate a myo

You could do this on the Input Mapping (e.g. Myo Pose Thumb to Pinky) gamepad events instead of the Event On Pose, but then the calibration target would always be your main myo, any secondary myo poses wouldn’t be picked up and calibrated. For this reason I recommend using a Myo Interface event, or explicitly calling which myo you want to bind (e.g. Primary myo, left/right Myo convenience functions callable on the Myo Component)

Note that you should perform a ‘Sync Gesture’ first in order to establish which arm the myo is on and which direction it is facing (toward wrist/arm), calibration picks this up and automatically adjusts for it as well, but if your arm isn’t detected (synced), your movements may be inverse if you have the device on the opposite direction compared to default.

#7

Thanks so much for the fast reply! I didn’t realize that to access the calibration function I had to drag from the MyoInterface target “Myo” and search that way (Previously, I was trying to search by right-clicking in the grey area). But once I found the function, it worked like a charm! Thanks again this is great!

#8

Update to 0.7.3
-Updated to Myo SDK beta 6
-As per 0.6, onArmRecognized and onArmLost is now onArmSync and
onArmUnsync
-Tested with Myo firmware 1.0.3

#9

I’m having some issues with the compiled plugin, I’ve also had some issues downloading the source and re-compiling the plugin from there, not because of anything in the plugin but because Unreal Sees 2 versions of Visual C++ and gets confused.

Either way when I put the compiled myo plugin into unreal I get the plugin to load, and I can create a blueprint, I add the Interface, so far so good, and then when I add the Myo Component it crashes with the following:

MachineId:5DCF350A40B7FF4EE819BD9CFB6EF7DD
EpicAccountId:e39aa2721d64432ca8ab3d139c6eadb9

Unknown exception - code 00000001 (first/second chance not available)

Assertion failed: O != NULL [File:D:\Users\Admin\Documents\Unreal Projects\MyoPluginCode\Intermediate\Build\Win64\Inc\Plugins\MyoPlugin\MyoPlugin.generated.cpp] [Line: 82]

KERNELBASE + 37901 bytes
UE4Editor_Core + 3174852 bytes
UE4Editor_Core + 1677512 bytes
UE4Editor_Core + 1566866 bytes
UE4Editor_MyoPlugin + 52381 bytes
UE4Editor_MyoPlugin + 15726 bytes
UE4Editor_MyoPlugin + 38176 bytes
UE4Editor_MyoPlugin + 42002 bytes
UE4Editor_Engine + 1648784 bytes
UE4Editor_Engine + 1830583 bytes
UE4Editor_Engine + 7191649 bytes
UE4Editor_Engine + 7192899 bytes
UE4Editor_Engine + 1647125 bytes
UE4Editor_Engine + 1873269 bytes
UE4Editor_Engine + 1807878 bytes
UE4Editor_CoreUObject + 1064249 bytes
UE4Editor_UnrealEd + 9351013 bytes
UE4Editor_Kismet + 1236720 bytes
UE4Editor_Kismet + 930296 bytes
UE4Editor_Kismet + 952813 bytes
UE4Editor_Engine + 835540 bytes
UE4Editor_UnrealEd + 9342141 bytes
UE4Editor_Kismet + 3128023 bytes
UE4Editor_Kismet + 3127496 bytes
UE4Editor_Kismet + 3808735 bytes
UE4Editor_Kismet + 3381574 bytes
UE4Editor_Kismet + 3406928 bytes
UE4Editor_UnrealEd + 4186989 bytes
UE4Editor_UnrealEd + 4343154 bytes
UE4Editor_UnrealEd + 4183185 bytes
UE4Editor_UnrealEd + 4191174 bytes
UE4Editor_UnrealEd + 4187777 bytes
UE4Editor_UnrealEd + 4453411 bytes
UE4Editor_UnrealEd + 1162089 bytes
UE4Editor_Slate + 822092 bytes
UE4Editor_Slate + 756518 bytes
UE4Editor_Core + 2506393 bytes
UE4Editor_Core + 2450091 bytes
UE4Editor_Core + 2510873 bytes
UE4Editor_Core + 2438466 bytes
user32 + 105425 bytes
user32 + 104666 bytes
UE4Editor_Core + 3157718 bytes
UE4Editor!FEngineLoop::Tick() + 3106 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.5\engine\source\runtime\launch\private\launchengineloop.cpp:2111]
UE4Editor!GuardedMain() + 479 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.5\engine\source\runtime\launch\private\launch.cpp:133]
UE4Editor!GuardedMainWrapper() + 26 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.5\engine\source\runtime\launch\private\windows\launchwindows.cpp:125]
UE4Editor!WinMain() + 249 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.5\engine\source\runtime\launch\private\windows\launchwindows.cpp:201]
UE4Editor!__tmainCRTStartup() + 329 bytes [f:\dd\vctools\crt\crtw32\dllstuff\crtexe.c:618]

This is on Unreal 4.5.1 with Myo Connect 0.7.0 Firmware Version 1.1.4

#10

I’m looking at the source code to try and re-compile for 4.6 but I’m having some issues, for one Unreal has changed the button handling, and the code needs to be re-written. Somehow EControllerButtons::Type no longer allows / contains special Structs of buttons.

Error 2 error C2664: ‘bool FSlateApplication::OnControllerButtonPressed(EControllerButtons::Type,int32,bool)’ : cannot convert argument 1 from ‘const FKey’ to ‘EControllerButtons::Type’ D:\Work\UnrealEngine-release\Engine\Plugins\Runtime\MyoPlugin\Source\MyoPlugin\Private\FMyoPlugin.cpp 108 1 UE4

There is a guy on github that did a Joystick Implementation, and documented this issue, and I tried replicating what he had, but I’m not as well versed at C++ to fully comprehend how he got around the issues.

[EDIT] LOL (NM, that’s you, I didn’t connect the user names at first) Can you fix the Myo implementation ? Also checking its compatibility with the latest firmware, as it’s supposedly a lot better at recognizing gestures ?

I’ll keep on trying small changes and see if I can find a way around this, please let me know if you’re working on this so I can focus on some other aspects of the VR Project I’m trying to complete

#11

I usually update all my plugins within a week of new UE version, if that is not fast enough, then by all means make compile fixes and help out by making a pull request with the fixes! UE4.6 made a mess of custom input mapping so it took a bit longer to find a workaround. Did most of the testing on a simpler plugin (Joystick) which is why it got pushed earlier. Glad you found it useful :slight_smile:

Your previous errors were due to using Myo 0.7 when 0.6 was the supported version. The plugin is now updated to UE4.6 and Myo 0.7.

Update to 0.7.4
-Contains compile fixes to sync code base to UE4.6. Note that warning
C4273 is suppressed due to 4.6 changes to Input Mapping.
-Syncs Myo SDK to Beta 7 (0.7)
-As per 0.7 Thumb to Pinky is now DoubleTap
-Added locking mechanism, this plugin defaults to none, but you can call
SetLockingPolicy on your MyoComponent to change this on say BeginPlay.
-As per 0.7 Added Lock/Unlock functions on MyoController class
-Arm Orientation space now persists throughout PIE sessions, will only
get lost when quitting app.

Let me know if any bugs crop up!

#12

I’m sorry if I came off as entitled, I understand that Epic does some frustrating things between releases, and I greatly appreciate your efforts. If you ever want to set up a donation with paypal or put these up in the Unreal Marketplace, I’d gladly compensate you for your work. And in reality, I just wanted to know if you were aware of the changes and working on them yourself, or if the thread was dead (Has Happened to me), and I needed to look elsewhere for help / support.

I’m actually a bit disappointed that all the manufacturers that you support Hydra, Leap, and Myo don’t support their own plugins, yet they support Unity, which is pretty short sighted if you ask me… (but nobody asks :smiley: )…

And thank you again for all the time / effort to support the Unreal / VR Community.

-Derek

#13

I’m looking through the new archive, and I see the date has been updated, but it seems the .uplugin file has the Engine version as 4.5 and the .dll states it needs to be re-compiled… was that so I could do my own compile, while you finish the release, or was that an oversight? I’m Verifying, I have the latest build of 4.6 just in case I got my side tangled up somehow…

Investigating a bit more, when I add the files all of a sudden Unreal Engine 4.6.0 Doesn’t recognize the project anymore, and asked me to convert in place, or copy to a new folder or ignore. I’ve always copied or converted in place if I had a perforce backup, this time I hit Ignore and it worked. Strange though that it’s asking this…

After that it seems to work :smiley:

#14

I understand where you’re coming from, and thank you for the kind words :). I’m just trying to get VR input to be a bit more standardized and easier to use so that all those cool applications can be found. In that vein it doesn’t make sense to charge for input plugins, but I’m hoping to make a middleware ‘body input’ plugin in the future (which will also be open source), any additional testers are always welcome.

The version specified in the .uplugin file specifies the minimum engine version to my knowledge and shouldn’t have an impact if you are using a newer version.

If you’re using a vanilla version of the engine the pre-compiled plugin will work with that major version (e.g. 4.5 will work for 4.5.0 and 4.5.1 etc). If you’re compiling a custom version of the engine you may need to compile the plugin yourself (which is as simple as add code to project and hit compile). Do remember to delete your MyoPlugin (only the Plugins folder in general) before replacing it with the new version as some files may have been removed between versions.

Minor update to 0.7.5
-removes C4273 suppression by including SlateCore in build rules

#15

Edit: My bad, you answered it in the previous post (it was about recompiling the engine)

#16

I’m referencing the Docs,

I’m wondering if you can elaborate, on point 1.
So I have to have Visual Studio express to create an empty class, and then re-compile the project ? Or is there a way around this by putting the .dll in the proper folders, as the whole, can’t find Plugin .dll seems to still be an issue in 4.6.
Or is there a way to create an empty class in the editor based on nothing.

I have another bug in with epic, where I can’t “generateProjectFiles.bat” because of a fatal error. Hence me generating an empty class isn’t something I can do until I resolve the issue.

#17

So the reason you need code is that without it, the plugin doesn’t get detected and will not be included in a packaged build. This is because all of your dependencies collapse into a monolithic .exe in a packaged build, as it currently stands this is an unavoidable step (though there are some hints that it may change come 4.7).

So step 1 with a bit more verbose instructions:

  1. Projects require code, if you are using a blueprint only project, add an empty class and compile your project module. You simply do File->Add Code to Project and it can be anything so I usually just pick None->Create Class and then it will ask you to open visual studio where you just hit compile (Build solution). If you haven’t added code before follow the unreal engine programming Quick Start guide. Essentially it boils down to downloading the free Visual Studio Community and changing a few small configs.

The rest of the steps should be clear enough.

Edit:
Updated github readme with the clarifications

#18

Thanks !

I’ve resorted to compiling the source with my own laptop, where everything works, until epic resolves the generateProjectFiles issue…

#19

I seem to be able to move 1 step forward and then get hit a wall again… I checked, I’m using 0.7.0 and I have the latest from you, and it works fine when I use it in editor. But when I try and play it in its own window or Build for Distribution, which I have to do to get Oculus to work, I get the following:

MainFrameActions: Packaging (Windows (64-bit)): UnrealBuildTool: [189/191] Link MyoTest-WmfMedia-Static.lib
MainFrameActions: Packaging (Windows (64-bit)): UnrealBuildTool: -------- End Detailed Actions Stats -----------------------------------------------------------
MainFrameActions: Packaging (Windows (64-bit)): UnrealBuildTool: ERROR: UBT ERROR: Failed to produce item: D:\Users\amara_000\Documents\Unreal Projects\MyoTest\Plugins\MyoPlugin\Binaries\Win64\MyoTest-MyoPlugin-Static.lib
MainFrameActions: Packaging (Windows (64-bit)): UnrealBuildTool: Cumulative action seconds (8 processors): 0.00 building projects, 3326.44 compiling, 0.00 creating app bundles, 0.00 generating debug info, 1.28 linking, 0.00 other
MainFrameActions: Packaging (Windows (64-bit)): UnrealBuildTool: UBT execution time: 878.96 seconds
MainFrameActions: Packaging (Windows (64-bit)): CommandUtils.Run: Run: Took 879.1203049s to run UnrealBuildTool.exe, ExitCode=2
MainFrameActions: Packaging (Windows (64-bit)): ErrorReporter.Error: ERROR: AutomationTool error: Command failed (Result:2): D:\Work\Unreal\UnrealEngine-release\Engine\Binaries\DotNET\UnrealBuildTool.exe MyoTest Win64 Development “D:\Users\amara_000\Documents\Unreal Projects\MyoTest\MyoTest.uproject”
MainFrameActions: Packaging (Windows (64-bit)): -noxge. See logfile for details: ‘UnrealBuildTool.txt’
MainFrameActions: Packaging (Windows (64-bit)): BuildCommand.Execute: ERROR: BUILD FAILED
MainFrameActions: Packaging (Windows (64-bit)): Program.Main: ERROR: AutomationTool terminated with exception:
MainFrameActions: Packaging (Windows (64-bit)): Program.Main: ERROR: Exception in AutomationTool: Command failed (Result:2): D:\Work\Unreal\UnrealEngine-release\Engine\Binaries\DotNET\UnrealBuildTool.exe MyoTest Win64 Development “D:\Users\amara_000\Documents\Unreal Projects\MyoTest\MyoTest.uproject”
MainFrameActions: Packaging (Windows (64-bit)): -noxge. See logfile for details: ‘UnrealBuildTool.txt’
MainFrameActions: Packaging (Windows (64-bit)): Stacktrace: at AutomationTool.CommandUtils.RunAndLog(String App, String CommandLine, String Logfile, Int32 MaxSuccessCode, String Input, ERunOptions Options) in d:\Work\Unreal\UnrealEngine-release\Engine\Source\Programs\AutomationTool\ProcessUtils.cs:line 792
MainFrameActions: Packaging (Windows (64-bit)): at AutomationTool.CommandUtils.RunUBT(CommandEnvironment Env, String UBTExecutable, String CommandLine, String LogName) in d:\Work\Unreal\UnrealEngine-release\Engine\Source\Programs\AutomationTool\UBTUtils.cs:line 33
MainFrameActions: Packaging (Windows (64-bit)): at AutomationTool.UE4Build.BuildWithUBT(String ProjectName, String TargetName, UnrealTargetPlatform TargetPlatform, String Config, String UprojectPath, Boolean ForceMonolithic, Boolean ForceNonUnity, Boolean ForceDebugInfo, Boolean ForceFlushMac, Boolean DisableXGE, String InAddArgs, Boolean ForceUnity) in d:\Work\Unreal\UnrealEngine-release\Engine\Source\Programs\AutomationTool\UE4Build.cs:line 321
MainFrameActions: Packaging (Windows (64-bit)): at AutomationTool.UE4Build.Build(BuildAgenda Agenda, Nullable1 InDeleteBuildProducts, Boolean InUpdateVersionFiles, Boolean InForceNoXGE, Boolean InForceNonUnity, Boolean InForceUnity) in d:\Work\Unreal\UnrealEngine-release\Engine\Source\Programs\AutomationTool\UE4Build.cs:line 1299 MainFrameActions: Packaging (Windows (64-bit)): at Project.Build(BuildCommand Command, ProjectParams Params, Int32 WorkingCL) in d:\Work\Unreal\UnrealEngine-release\Engine\Source\Programs\AutomationTool\Scripts\BuildProjectCommand.Automation.cs:line 114 MainFrameActions: Packaging (Windows (64-bit)): at BuildCookRun.DoBuildCookRun(ProjectParams Params) in d:\Work\Unreal\UnrealEngine-release\Engine\Source\Programs\AutomationTool\Scripts\BuildCookRun.Automation.cs:line 256 MainFrameActions: Packaging (Windows (64-bit)): at BuildCommand.Execute() in d:\Work\Unreal\UnrealEngine-release\Engine\Source\Programs\AutomationTool\BuildCommand.cs:line 37 MainFrameActions: Packaging (Windows (64-bit)): at AutomationTool.Automation.Execute(List1 CommandsToExecute, CaselessDictionary`1 Commands) in d:\Work\Unreal\UnrealEngine-release\Engine\Source\Programs\AutomationTool\Automation.cs:line 371
MainFrameActions: Packaging (Windows (64-bit)): at AutomationTool.Automation.Process(String] CommandLine) in d:\Work\Unreal\UnrealEngine-release\Engine\Source\Programs\AutomationTool\Automation.cs:line 343
MainFrameActions: Packaging (Windows (64-bit)): at AutomationTool.Program.MainProc(Object Param) in d:\Work\Unreal\UnrealEngine-release\Engine\Source\Programs\AutomationTool\Program.cs:line 167
MainFrameActions: Packaging (Windows (64-bit)): at AutomationTool.InternalUtils.RunSingleInstance(MainProc Main, Object Param) in d:\Work\Unreal\UnrealEngine-release\Engine\Source\Programs\AutomationTool\Utils.cs:line 649
MainFrameActions: Packaging (Windows (64-bit)): at AutomationTool.Program.Main() in d:\Work\Unreal\UnrealEngine-release\Engine\Source\Programs\AutomationTool\Program.cs:line 114
MainFrameActions: Packaging (Windows (64-bit)): Program.Main: ERROR: Command failed (Result:2): D:\Work\Unreal\UnrealEngine-release\Engine\Binaries\DotNET\UnrealBuildTool.exe MyoTest Win64 Development “D:\Users\amara_000\Documents\Unreal Projects\MyoTest\MyoTest.uproject” -noxge. See logfile for detai
MainFrameActions: Packaging (Windows (64-bit)): ls: ‘UnrealBuildTool.txt’
MainFrameActions: Packaging (Windows (64-bit)): ProcessManager.KillAll: Trying to kill 0 spawned processes.
MainFrameActions: Packaging (Windows (64-bit)): Program.Main: AutomationTool exiting with ExitCode=2
MainFrameActions: Packaging (Windows (64-bit)): Domain_ProcessExit
MainFrameActions: Packaging (Windows (64-bit)): ProcessManager.KillAll: Trying to kill 0 spawned processes.
MainFrameActions: Packaging (Windows (64-bit)): AutomationToolLauncher exiting with ExitCode=2
MainFrameActions: Packaging (Windows (64-bit)): copying UAT log files…
MainFrameActions: Packaging (Windows (64-bit)): RunUAT.bat ERROR: AutomationTool was unable to run successfully.
MainFrameActions: Packaging (Windows (64-bit)): BUILD FAILED
LogRenderer:Warning: Reallocating scene render targets to support 1200x904.

Which is strange since it builds the engine/project just fine in VS2013. And this is before I can even copy the .dll’s to the target folder. So I did what the instructions stated. Create an Empty Class, Modify the .ini file. But the last part eludes me due to not being able to compile the code for release.

#20

I believe the error you got was from having Try/Catch blocks within the myo plugin (which UE compiler doesn’t support by default). patched update 0.7.6 with these fixes which will allow the packaging to work correctly again.

Do note that you can try oculus in development by choosing Play->Standalone. Never use launch, this is not supported until automatic copying is fixed by Epic.

If you want to use an older version of the plugin with this fix instead of 0.7.6, just change Startup() to comment out the try/catch block in FMyoPlugin.cpp

e.g.



			//try{
				hub = new myo::Hub("com.plugin.unrealengine4");
				UE_LOG(MyoPluginLog, Log, TEXT("Myo Hub Initialized."));
			//}
			//catch (const std::exception& e) {
				/*UE_LOG(MyoPluginLog, Error, TEXT("Myo did not initialize correctly, check if Myo Connect is running!"));
				UE_LOG(MyoPluginLog, Error, TEXT("Error: %s"), e.what());
				hub = NULL;*/
			//}

Update to 0.7.6
-Packaged file fix by removing try/catch block. No longer needed since
Myo Connect handles hot plugging of hub