Unreal Engine 4 is available for Win10 UWP app dev now

StarGameStudios · May 16, 2018, 8:12pm

anonymous_user_582995091:

When you’re seeing the immediate close on launch, is that under the debugger? If not, I’d suggest trying with the debugger attached to see whether you get better info. Use Debug->Other debug targets->Debug Installed App Package in Visual Studio. Depending on how early in startup the failure occurs you may need to check the ‘Do not launch, but debug my code when it starts’ box, in which case you should wait for the debugger to fully attach and then launch your app normally to observe the results.

A couple of things that I know offhand can cause failures early in the startup process:

Incorrectly setting the ‘Use Retail Windows Store Environment’ flag in UWP project settings. If you check this on, then you must have a catalog entry for your product in the retail environment of the store (hidden is fine); if you check it off (default), your OS must be in development mode to run the app. You must check it on when building a final package for submission.

Long stalls on the game thread during startup. UWP apps are required to get their message pump up and running within a few seconds of launch. If they don’t the OS will summarily kill them. If you have long-running work that occurs early in the launch flow you could be getting caught by this.

Failure to launch when double-clicking the exe in the folder is to be expected. There’s extra work the OS does to set up the UWP environment before passing control to your code. A part of that is setting up paths so that those dlls can be found.

This fork hasn’t been updated to specifically understand SDKs past 16299. Looks like 17134 includes some schema additions that need to be accounted for. As you’ve discovered you can explicitly lock to an earlier SDK. That should fix the first complaint in your log.

As the text notes, however, that first message should be non-fatal. I think it’s the stuff that comes after that is causing the real trouble:

You should check UWP project settings for this value. If you’re not using Xbox Live you should leave the field empty.

I suspect this is ultimately what kills the build. It looks like we have a bug in Engine\Plugins\Runtime\ApexDestruction\Source\ThirdParty\PhysX\ApexDestructionLib.Build.cs - it’s still looking in the old pre-4.19 locations for the APEX dll . In the latest version everything should be in Binaries\ThirdParty\PhysX3\UWP64. If you adjust the values of ApexBinariesDir for UWP64/32 it might get you up and running .

@anonymous_user_582995091 Thank you very much!