The signature for the LoadSharedResource method in CVRResources has the incorrect parameter type for pchBuffer.
The existing implementation has it as a string which is immutable in C#, despite this being the intended buffer to put the output in. It should be a StringBuilder, as per the adjacent "GetResourceFullPath" method.
This bug has likely flown under the radar due to other parts of this API being missing, preventing it from being used, see #1873.
Example working code post-fix, this loads the contents of an input device action manifest, which lists all of the available inputs for the attached device. The same approach can also be used to load other resources such as icons, render models etc, as is the intended use of this API.
int index = 2; // the device index
StringBuilder sb = new StringBuilder((int) Valve.VR.OpenVR.k_unMaxPropertyStringSize);
OpenVR.System.GetStringTrackedDeviceProperty(
index,
ETrackedDeviceProperty.Prop_InputProfilePath_String,
sb,
Valve.VR.OpenVR.k_unMaxPropertyStringSize,
ref error
);
string manifestPath = sb.ToString();
sb.Clear();
// note: the StringBuilder would likely need to be larger in practice, but this works enough for this example
OpenVR.Resources.LoadSharedResource(
manifestPath,
sb,
Valve.VR.OpenVR.k_unMaxPropertyStringSize
);
A PR will be issued for this bug shortly.
Note: a byte-buffer might be more appropriate as many resources are binary and therefore loading via a StringBuilder might not be possible. Changing this would likely require changes at the driver. Perhaps an overload could be added for this in a future version of the API.
The signature for the LoadSharedResource method in CVRResources has the incorrect parameter type for pchBuffer.
The existing implementation has it as a string which is immutable in C#, despite this being the intended buffer to put the output in. It should be a StringBuilder, as per the adjacent "GetResourceFullPath" method.
This bug has likely flown under the radar due to other parts of this API being missing, preventing it from being used, see #1873.
Example working code post-fix, this loads the contents of an input device action manifest, which lists all of the available inputs for the attached device. The same approach can also be used to load other resources such as icons, render models etc, as is the intended use of this API.
A PR will be issued for this bug shortly.
Note: a byte-buffer might be more appropriate as many resources are binary and therefore loading via a StringBuilder might not be possible. Changing this would likely require changes at the driver. Perhaps an overload could be added for this in a future version of the API.