Skip to main content
Up and Coming
July 26, 2014

Getting rid of health and safety warning

What is the proper way to get rid of the health and safety warning in Unity?
In OVRDevice.cs, I tired commenting out this:

if (HMD != null && Input.anyKeyDown && HMD.GetHSWDisplayState().Displayed)
HMD.DismissHSWDisplay();

and adding this to the end of Awake():

HMD.DismissHSWDisplay();


But that only works in the Editor but in the standalone version the head tracking stops working and the warning is not removed.

    261 replies

    Up and Coming
    August 19, 2014
    "8igby" wrote:
    "jherico" wrote:
    "n00854180t" wrote:
    Regardless what the lawyers think, there's no good reason to force the user to see that message every time they play the game.

    Once, fine (then never again unless they reinstall/delete the setting).


    The software doesn't know who has the headset on. So I'm over at a friend's house and he invites me to try out some Rift demo. I trip and break my nose. I decide to sue Oculus for failing to provide a warning. They point to the license requirement and put liability onto the software maker and or my friend.

    In fact, if Oculus ever implements on-head-detection in hardware for the Rift, the warning will probably automatically pop up whenever the headset goes from the off-head to the on-head state.

    The solution for developers is pretty easy. Modify the SDK to disable the warning completely in only in debug builds. For other platforms like Unity and Unreal, I don't know how they distinguish debug from release builds, but hopefully some similar solution will be available.


    Holy crap I'm happy I don't live in the US. Try this in any European country and the judge(and/or jury) would laugh their socks off and charge you with contempt of court or some other "Too stupid for your own good" sentence. I agree with another post here, if this is required in the US, please make it regional, so that the civilized world doesn't have to care...


    That whole argument would be laughable here in the US, too. No judge would take that seriously, nor would they apply liability for that situation to Oculus. It's honestly a joke.

    The people here arguing that "oh it's justified to show it every single time because XYZ poorly-thought-out hare-brained reason" are just grasping at straws to try and find reasons to justify the poorly implemented warning.
    Twitter IndieDB
    Inspiring
    August 19, 2014
    "n00854180t" wrote:
    The people here arguing that "oh it's justified to show it every single time because XYZ poorly-thought-out hare-brained reason" are just grasping at straws to try and find reasons to justify the poorly implemented warning.


    I'm not trying to justify the lawsuit / liability focused mentality of the US or predict the outcome of any potential trial. I'm just trying to explain one potential viewpoint on liability.

    But the fact is that I don't need to justify the warning logically. It's required by the license. If you fail to obey the license, you potentially lose your right to make applications using the SDK.
    Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action
    Up and Coming
    August 19, 2014
    But my question is: What is required?

    I am very soon going to make a submission for Live for Speed's DK2 support, so I need to know the answer.

    The amount of work required to put up a new full version means it would be extremely frustrating to do that and then have a submission rejected.

    The document is not clear, at all. The only relevant words I can find are:

    All applications that use the Oculus Rift must integrate code that displays a health and safety warning when
    the device is used. This warning will appear for a short amount of time when the Rift first displays a VR scene;
    it can be dismissed by pressing a key or tapping on the headset...

    ...in App rendered mode it is left for developers to implement.

    For some unknown reason, no-one at Oculus is able to reply, what the actual requirements are.
    viewtopic.php?f=53&t=12439

    They are treating us with contempt and I have heard this is how facebook treat their developers. I hope this is not the way of the future, due to the facebook influence.
    Live for Speed - www.lfs.net
    Inspiring
    August 19, 2014
    "scawen" wrote:
    But my question is: What is required?


    What's unclear to you? The SDK includes both the content of the warning and the code required to display it in SDK-distortion. Applications doing their own distortion can therefore model the behavior on that and reproduce the content in whatever fashion seems appropriate.
    Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action
    Up and Coming
    August 19, 2014
    It doesn't include the content of the warning. There is just that hsw.tga file, that someone was able to find for me. There is no mention in the SDK that we should use that text. If that text is required, it should be somewhere in plain text format.

    "Model the behaviour on that". On what? This?
    To support timing and rendering the safety warning, we’ve added two
    functions to the C API: ovrHmd_GetHSWDisplayState and ovrHmd_DismissHSWDisplay.
    ovrHmd_GetHSWDisplayState reportsthestateofthewarningdescribedbythe ovrHSWDisplayState
    structure, including the displayed flag and how much time is left before it can be dismissed.
    ovrHmd_DismissHSWDisplay should be called in response to a keystroke or gamepad action to dismiss
    the warning.

    I can hardly make any sense out of that.

    This is not a specification, on how I should make my code behave.

    A specification, for something, if it is important, should be clear, concise, unambiguous. Not... this...
    Live for Speed - www.lfs.net
    Up and Coming
    August 19, 2014
    "jherico" wrote:
    It's required by the license.


    It's required to be DISPLAYED, not required to be displayed on every run of the game/app. Until that changes there is no justification for spamming it every time a game opens.

    And regardless, there's no justification for Oculus to implement it that way (and no, "liability" isn't one - every other product in the world gets by with a notice IN THE BOX).

    The way the warning is implemented is pure stinking garbage and needs to be fixed, and the licensing needs to be unambiguous.

    If they want it to be displayed EVERY TIME for no good reason (and ensure that people HATE VR), fine, but it does NOT say that right now.
    Twitter IndieDB
    Inspiring
    August 19, 2014
    "n00854180t" wrote:
    "jherico" wrote:
    It's required by the license.


    It's required to be DISPLAYED, not required to be displayed on every run of the game/app. Until that changes there is no justification for spamming it every time a game opens.


    must integrate code that displays a health and safety warning when the device is used


    That seems pretty unambiguous to me.
    Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action
    Inspiring
    August 19, 2014
    "scawen" wrote:
    It doesn't include the content of the warning. There is just that hsw.tga file, that someone was able to find for me. There is no mention in the SDK that we should use that text. If that text is required, it should be somewhere in plain text format.


    It would be disingenuous to suggest that because the warning isn't available as a text file right now you can't figure out what to put in it. If you're clever enough to implement client side distortion, you're clever enough to look into the SDK and find the image file that contains the warning.


    I can hardly make any sense out of that.

    This is not a specification, on how I should make my code behave.

    A specification, for something, if it is important, should be clear, concise, unambiguous. Not... this...


    No, it's not a specification, it's a readme. The closest we have to a specification is the C API header and the (rather limited) documentation. So the functionality is available before the documentation is complete. That's doesn't mean you're incapable of looking at the header file and examining the functions mentioned in the readme. The code is actually pretty heavily commented, with example code and everything.


    /// Used by ovrhmd_GetHSWDisplayState to report the current display state.
    typedef struct ovrHSWDisplayState_
    {
    /// If true then the warning should be currently visible
    /// and the following variables have meaning. Else there is no
    /// warning being displayed for this application on the given HMD.
    ovrBool Displayed;
    double StartTime; /// Absolute time when the warning was first displayed. See ovr_GetTimeInSeconds().
    double DismissibleTime; /// Earliest absolute time when the warning can be dismissed. May be a time in the past.
    } ovrHSWDisplayState;

    /// Returns the current state of the HSW display. If the application is doing the rendering of
    /// the HSW display then this function serves to indicate that the the warning should be
    /// currently displayed. If the application is using SDK-based eye rendering then the SDK by
    /// default automatically handles the drawing of the HSW display. An application that uses
    /// application-based eye rendering should use this function to know when to start drawing the
    /// HSW display itself and can optionally use it in conjunction with ovrhmd_DismissHSWDisplay
    /// as described below.
    ///
    /// Example usage for application-based rendering:
    /// bool HSWDisplayCurrentlyDisplayed = false; // global or class member variable
    /// ovrHSWDisplayState hswDisplayState;
    /// ovrhmd_GetHSWDisplayState(Hmd, &hswDisplayState);
    ///
    /// if (hswDisplayState.Displayed && !HSWDisplayCurrentlyDisplayed) {
    /// <insert model into the scene that stays in front of the user>
    /// HSWDisplayCurrentlyDisplayed = true;
    /// }
    OVR_EXPORT void ovrHmd_GetHSWDisplayState(ovrHmd hmd, ovrHSWDisplayState *hasWarningState);

    /// Dismisses the HSW display if the warning is dismissible and the earliest dismissal time
    /// has occurred. Returns true if the display is valid and could be dismissed. The application
    /// should recognize that the HSW display is being displayed (via ovrhmd_GetHSWDisplayState)
    /// and if so then call this function when the appropriate user input to dismiss the warning
    /// occurs.
    ///
    /// Example usage :
    /// void ProcessEvent(int key) {
    /// if(key == escape) {
    /// ovrHSWDisplayState hswDisplayState;
    /// ovrhmd_GetHSWDisplayState(hmd, &hswDisplayState);
    ///
    /// if(hswDisplayState.Displayed && ovrhmd_DismissHSWDisplay(hmd)) {
    /// <remove model from the scene>
    /// HSWDisplayCurrentlyDisplayed = false;
    /// }
    /// }
    /// }
    OVR_EXPORT ovrBool ovrHmd_DismissHSWDisplay(ovrHmd hmd);
    Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action
    Up and Coming
    August 19, 2014
    "When the device is used" is ambiguous. It does not mean the same thing in legalese as "on every operation" or something that is actually not ambiguous.

    And regardless, it's a crap warning - it's implemented poorly, it does not follow UI or VR standards, and it's obnoxious.

    Oculus talks about the dangers of bad VR so often, you'd think they'd avoid putting it out themselves, but that's exactly what this warning garbage causes.... bad VR.

    "jherico" wrote:
    "scawen" wrote:
    It doesn't include the content of the warning. There is just that hsw.tga file, that someone was able to find for me. There is no mention in the SDK that we should use that text. If that text is required, it should be somewhere in plain text format.


    It would be disingenuous to suggest that because the warning isn't available as a text file right now you can't figure out what to put in it. If you're clever enough to implement client side distortion, you're clever enough to look into the SDK and find the image file that contains the warning.


    At this point it seems like it's your personal mission to defend this craptastic, poorly implemented, BAD VR warning.

    If the text is required, it needs to be made available. Stop acting like that's unreasonable.
    Twitter IndieDB
    Inspiring
    August 19, 2014
    I don't like the H&S warning, and in fact I've advised a number of people on how to disable it in debug builds, and made the function to do so publicly visible in my Github version of the SDK.

    What bugs me is people appearing to be perfectly capable of using the SDK and then suddenly becoming baffled when they encounter a requirement they don't like. You can berate me all you like, but I didn't write the license, nor the SDK.
    Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action