I feel the SteamVR functionality exposed to C++ is severely lacking. Is there any reason for this?
Unless I missed something, we only have the SteamVRFunctionLibrary.h available, with these functions:
GetValidTrackedDeviceIds
GetTrackedDevicePositionAndOrientation
GetHandPositionAndOrientation
The USteamVRChaperoneComponent is a UCLASS(MinimapApi) so I can’t access its GetBounds function from code. Why only expose this to Blueprints? This is of course easy enough to change and recompile the engine, but was wondering about the official roadmap.
I get around it now by having a BlueprintCallable function and pass the GetBounds result from the blueprint down to C++ on begin play.
I also noticed there are a lot more things that aren’t exposed that would be very useful for all kinds of things. These are all in the main plugin (private) class SteamVRHMD, where GetBounds comes from in the first place.
Are there any plans to expand the SteamVR C++ interface?
You can call blueprint functions in code, you can also directly include header files in your own project when it is a c++ project…you have access to everything.
In fact, the USteamVRFunctionLibrary was like that before, but it was changed. Again, In pure C++ code, this wouldn’t be a problem, as including any headers would give you access to any public interface, but I’m guessing UE does a lot of things under the hood with their UBT and those meta tags. https://forums.unrealengine.com/archive/index.php/t-73844.html
How would I go about including the UMotionControllerComponent? I found the header file for it, but my class doesn’t like include “MotionControllerComponent.h”
You’ll need to make the module it is in a dependency in your build.cs file, add “HeadMountedDisplay”, “SteamVR”, “SteamVRController” to PublicDependencyModuleNames to give access to most relevant modules.
Honestly you can pretty much access any source file in the engine anyway (even module private exports) but it is kind of bad practice to directly include the entire file path unless you really have to as referencing a module and using its exports is cleaner.
Yeah, whats up? Pretty please 6 months since this issue have been reported and 4 months since a pr had been submitted and 4.15 preview is already out and does not contain any fix for this