Error: Couldn't find file for package /Script/SteamVRInputDevice requested by async loading code. NameToLoad: /Script/SteamVRInputDevice

[TarasDev]

Steps to reproduce:

• Create new empty project
• Add any SteamVR Input BP node to Level BP
• Cook content for Linux
• Build Development Server for Linux
• Try to start executable

Log.txt

[1runeberg]

Hi - At the moment, the plugin was designed for Winx64 builds only.

Will keep this open however, so we can inform Linux users as we start adding support for it.

Sorry for the inconvenience.

[ericranstrom]

Seeing this same error when executing on android (Oculus Quest).

[1runeberg]

Seeing this same error when executing on android (Oculus Quest).

Hi @ericranstrom, as it requires SteamVR Input, this plugin is not compatible (nor useable) for Quest executables :)

[getnamo]

We ideally need a way to disable the incompatible code paths for linux/android so the plugin can be used in a project that supports both android (quest) and win (valve index) and dedicated server builds without enabling/disabling the plugin.

[Biggsism]

We ideally need a way to disable the incompatible code paths for linux/android so the plugin can be used in a project that supports both android (quest) and win (valve index) and dedicated server builds without enabling/disabling the plugin.

Thanks for bringing this up Getnamo. Saw this pop up in my email updates and want to dogpile onto the topic-

We have this exact challenge when we attempt to use this plugin. Our title performs cross-platform between Quest, IOS, Android, and PC using iphones, android devices, Oculus HMDs, and Steam VR HMDs.

Steam VR plugin breaks our ability to build on everything but PC so we have had to remain on native vive support that is built into Unreal.

Understand this is a big ask, but please consider this need for the future. Especially so now that Quest/SteamVR/Mobile cross play has so many issues using this plugin.

[1runeberg]

@getnamo - what's the workflow you are trying to achieve? Is this for test builds only? Not entirely sure if you are wanting the plugin to build for a non-whitelisted platform (including being added unnecessarily to packaged builds) or if you have a specific use case in mind?

also, does the oculus quest checks not require exclusion of other vr platform dlls similar to the PC to pass certification?

[getnamo]

The problem largely comes from the fact that just including the plugin breaks packaging for non-supported plugins. Enable/Disable dance on a project is a path of developer pain. What I'm suggesting is something like how epic uses HAL to abstract platform specific implementation.

You have one module that defines api (interfaces/base classes etc however it needs to be structured) and you can also include dev consumable parts there such as bp meshes. This module will load on both supported and unsupported platforms and should have a global function that you can use to query if the backend is available (SteamVR), default is false. Meshes in this setup will simply call dummy functions, but importantly including the blueprints wouldn't break anything.

Then you have another module that depends on the first module but only loads for supported platforms. This module overrides the api with the working bits of code and brings all the blueprints to life.

This way as a dev you can enable the plugin and use it for all platforms, query a global static function to determine if you need to use your own codepath to supply input or not, but importantly it won't break builds, which is ideal. You would also automatically not include any DLLs/libs for platforms that do not support it.

I understand that this feature is a fairly big ask as it would require a bit of refactoring, but it would be immensely worth it for devs and vr in general.

[1runeberg]

I understand your concern and the bit of pain on manual builds, at the moment however the plugin is only whitelisted for Win64 and this is specified in the uplugin file.

Haven't checked recently but ideally, builds bound for a non-whitelisted platform specified in the uplugin shouldn't be included by the engine.

The issue with other plugins is largely out of our control as the defaults in the engine favor for example oculus when the two Plugins are enabled. There is a way to override this in the Configs but this would need to be part of any CI scripting on the developer end.

I have reservation on creating architecture specifically to support something that the plugin isn't bound for (e. g. Mobile) and build workflows should be the domain of the Engine rather than plugin code devs imo.

To be fair, all of these are already possible by CI scripting via modifs to the uproject prior to any build step. Unsure if its changed recently but the only way to pass cert for Oculus for example is to ensure steamvr DLLs aren't present in the build and usually done manually or via CI scripts to disable SteamVR prior to packaging.

[getnamo]

You raise some very good points, there may be some ways to mitigate some of the issues on the dev side, but we'd need some best practice hints. There are also a few factors I think that complicate possible solutions:

1. Including a blueprint that depends on plugin content will obviously break that build if the plugin is missing. I believe you may be able to get around this in C++ by doing platform based code branches (#if), that leaves bp only projects/devs in the current limbo.
2. Even if code is whitelisted, the dependency on SteamVR will break a package process. This would require you to use some form of CI to programmatically disable plugins before building. This leaves indie devs in the current limbo.
3. SteamVRInput makes a lot of changes (input mapping, meshes that replicate hand state/etc). It's not easily isolated from core vr interaction. There may be a way to create a base class that only attaches e.g. steam meshes via text based loading in c++ code, but that would again lead us back to 1)
4. Dedicated server builds (which is the source of this issue). A good litmus test for the best path forward is the linux dedicated server build. What would be the best way (i.e. least amount of dev work) to having a project that can do win64 client builds and linux dedicated server builds?
5. For me dev friction is the biggest determinant if something gets used. Atm if there won't be a refactor I'll likely need to patch or include the openvr libs in a separate module to get good hand input for the valve index, which I really would love to avoid as you've done a great job with the rest of the plugin.

This brings me back to native Epic VR support. It is hardware agnostic, each device targets the same api so those parts can all be used nearly interchangeably. Do we need to push for new API to ensure we can feed skeletal data from multiple sources? If so what would that look like?

As an aside, when you enable both Oculus and SteamVR for pc VR, it will only favor oculus if you have the oculus runtime active. I have both enabled on a valve index and it has no issues using the SteamVR path with it disabled and the Quest launches/packages without issue (albeit from the small sample size of my own tests).

[1runeberg]

Thanks for the feedback. At the moment not sure if a code architecture solution to a build workflow issue is really appropriate.

There are a number of built in engine build tools and third party scripts which shouldn't be too difficult to produce and does not require any monetary investment.

I'll try to open source some build scripts in either python or powershell or tutorials on UE build systems if that helps. It's outside the scope of this plugin but I'll try to cover it in my UE community efforts. This is likely a better solution than adding unnecessary bloat to packaged builds imo. Unless Epic produces a more targeted build process which honours whitelists. Having plugins rearchitecture their code for this express purpose though is I feel overkill as this is purely a build workflow issue.
And in the case of UE, it's just a matter of using the appropriate tooling and scripts for which their build process was designed.

For plugin clashes, the engine default pri is Oculus and there's no way to uniformly control users run times, so the "unreal" solution is via the defaultengine inis that can be configured for each project and build depending on target platform.

Sorry this is probably not what you'd like to hear, but a code archi solution to augment an engine build system is personally I feel not appropriate - to make an Engine's multiplatform build process easier and more efficient shouldn't be a burden by each Plugin dev imo but rather an engine process or UI improvement.

[MJEND7]

HEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEELP THIS IS MY ERROR Couldn't find file for package /Game/Blueprints/Game/FPS_GameMode requested by async loading code. NameToLoad: /Game/Blueprints/Game/FPS_GameMode I AM TRYING TO MAKE A SERVER WITH UNREAL

[1runeberg]

HEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEELP THIS IS MY ERROR Couldn't find file for package /Game/Blueprints/Game/FPS_GameMode requested by async loading code. NameToLoad: /Game/Blueprints/Game/FPS_GameMode I AM TRYING TO MAKE A SERVER WITH UNREAL

Hi - not sure if you are asking an issue with the SteamVR Input plugin? or a general network issue with Unreal?

[MJEND7]

sorry its a network problem for unreal

…

On Tue, 25 Aug 2020 2:05 PM Rune Berg ***@***.***> wrote: HEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEELP THIS IS MY ERROR Couldn't find file for package /Game/Blueprints/Game/FPS_GameMode requested by async loading code. NameToLoad: /Game/Blueprints/Game/FPS_GameMode I AM TRYING TO MAKE A SERVER WITH UNREAL Hi - not sure if you are asking an issue with the SteamVR Input plugin? or a general network issue with Unreal? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#24 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOL4MB76HTJ6WEISXZ3KMQDSCMZ7NANCNFSM4HNQDJ5A> .