Search Unity

  1. We are migrating the Unity Forums to Unity Discussions. On July 12, the Unity Forums will become read-only. On July 15, Unity Discussions will become read-only until July 18, when the new design and the migrated forum contents will go live. Read our full announcement for more information and let us know if you have any questions.

Lock input to game

Discussion in 'Input System' started by KospY, Nov 10, 2018.

  1. KospY

    KospY

    Joined:
    May 12, 2014
    Posts:
    153
    I maybe missing something obvious, but I can't find how we can force the "Lock input to game" to a final build. I can do it easily in the editor, but it's not working in the build. I tried to force the setting from script with
    Code (CSharp):
    1. InputConfiguration.LockInputToGame = true
    , but the game won't build because it seem to be an editor function.
    I'm working on a VR game and this is a pain as any popup or click outside the game window (using the VR Dashboard for example) stop all inputs.

    Thanks for your help :)
     
  2. Rene-Damm

    Rene-Damm

    Joined:
    Sep 15, 2012
    Posts:
    1,779
    Yup, this is meant to be an editor-only override to override the behavior where the game view needs to have focus to receive inputs so that all EditorWindows can get input.

    In the game, input is always "locked" to the game.

    We're currently giving focus handling a pass and should get resolved as part of that so as to not tie XR inputs to window focus the same way that mouse input is, for example.
     
  3. KospY

    KospY

    Joined:
    May 12, 2014
    Posts:
    153
    Good news! It was the last remaining issue for me about XR inputs (HTC, Oculus and WMR are all working). Do you know if that need to be resolved in Unity (so I must wait 2018.3 or 2019 :( ) or it's something that can be fixed in the plugin on Github?
    Thanks!
     
    Last edited: Nov 13, 2018
  4. Rene-Damm

    Rene-Damm

    Joined:
    Sep 15, 2012
    Posts:
    1,779
    Native changes, where necessary, will get backported to 2018.2 for as long as we can so it shouldn't require upgrading. However, in this case, I believe we have the pieces we need already in place. At least I think we do.... :)
     
  5. KospY

    KospY

    Joined:
    May 12, 2014
    Posts:
    153
    Any ETA about when that will be resolved?
     
  6. Rene-Damm

    Rene-Damm

    Joined:
    Sep 15, 2012
    Posts:
    1,779
    The managed side changes have landed but the native changes will still take a bit to make their way to the various releases.
     
  7. KospY

    KospY

    Joined:
    May 12, 2014
    Posts:
    153
    Yeah I saw a commit yesterday about that, that's great!
    However do you know if the native changes will be available in 2018.2 or only 2018.3?
     
  8. Rene-Damm

    Rene-Damm

    Joined:
    Sep 15, 2012
    Posts:
    1,779
    Backporting to 2018.3 is in progress (ATM the native changes are only in 2019.1). We're looking into a backport to 2018.2 but don't have a final conclusion there yet.
     
  9. KospY

    KospY

    Joined:
    May 12, 2014
    Posts:
    153
    Just updated to 2018.3.0f2.
    Inputs lock still doesn't work, I'm so sad.
    Maybe I missed an option somewhere?
     
  10. Rene-Damm

    Rene-Damm

    Joined:
    Sep 15, 2012
    Posts:
    1,779
    Yeah sorry it's taking a while. Changes on the native side always take their sweet time... The backport hasn't gone through yet so 2018.3 is still missing the native changes. I'll let you know as soon as it hits.
     
    FROS7 likes this.
  11. KospY

    KospY

    Joined:
    May 12, 2014
    Posts:
    153
    Thanks for your quick reply :)
    Hope this native change will come soon, my game has released recently and it's my main issue with the new inputs currently (well I got some new ones with 2018.3 and 0.0.14 but I will post something else about that).
    Thanks for your hard work!
     
    FROS7 likes this.
  12. KospY

    KospY

    Joined:
    May 12, 2014
    Posts:
    153
  13. Rene-Damm

    Rene-Damm

    Joined:
    Sep 15, 2012
    Posts:
    1,779
    Changes have landed in 2019.1 and, as far as the existing changes go, latest develop branch together with 2019.1b1 should have all the changes. There's also a couple of fixes for XR bugs that have landed. 2018.3 probably won't see the backports happening after all and there's a decent chance we'll be forced to move on to 2019.1 for good sometime soon.

    Unfortunately, I messed something up and latest develop doesn't compile with 2019.1 ATM. Will fix.

    When the next package is out (expected this week; 0.1.3-preview), run-in-background should be functional with 2019.1 and hopefully give you at least an option to make XR input work regardless of focus. Overall, I expect we still have to polish things here some.
     
  14. KospY

    KospY

    Joined:
    May 12, 2014
    Posts:
    153
    @Rene-Damm
    Oh damn :eek: Any chance to have this landing on 2018.3 too?
    I was close to have a build with nearly everything working on 2018.3 (not only inputs), but now I need to move on 2019.1 :confused:

    I know that the new input system are still in beta, but being forced to always update to the next beta/alpha version is a nightmare, it's endless and almost impossible to get a stable build.

    With haptic being fixed recently it was the last thing to fix for VR inputs working 100% on 2018.3 :(
    Now I need to wait 2-3 months more, and unfortunatly, from my experience with the last updates of Unity, nothing assures me that 2019.1 (even final release) will be working without any major issue.
     
    Last edited: Jan 31, 2019
  15. Rene-Damm

    Rene-Damm

    Joined:
    Sep 15, 2012
    Posts:
    1,779
    Mhm, totally understand it's painful. Really sorry about that. Definitely not happy about it either. Was hoping that at the very least, if we can't manage to support multiple versions, we'll at least manage to wait with moving on to a new version of Unity until that one is released as final. Pushing users onto betas sucks.

    There's still some hope we'll manage to keep 2018.3 going at least to some extent and manage to defer the full switch until later.

    Unfortunately, at some point we're kinda forced to pick our battles. Pushing native changes through the succession of Unity release trains and synchronizing it with managed changes is a massive headache. Much more than it could and should be. Think we'll get better here as the package ecosystem in Unity evolves. ATM it's tear-your-hair-out kinda material.
     
  16. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,371
    You are planning for the new Input system to for sure work with 2018.4 LTS, right? We'll be sticking on that for our next release, and it'd be a real PITA to have to deal with the old input system again.

    Since games should probably ship on LTS releases, skipping support for 2018 entirely would mean that the new Input system won't really be useful for serious productions until around summer next year.
     
    Lurking-Ninja likes this.
  17. KospY

    KospY

    Joined:
    May 12, 2014
    Posts:
    153
    Any news on this? Does the fix is still in Unity 2019.1 beta only?
    Does a LTS version of Unity 2018 is planned? I didn't found any information on this.
     
    Last edited: Mar 10, 2019
  18. Rene-Damm

    Rene-Damm

    Joined:
    Sep 15, 2012
    Posts:
    1,779
    2018.3 LTS was the original plan as it looked like we'd have the native parts sufficiently stabilized by the time 2018.3 goes final and would then mainly keep refining the managed parts to work with both 2018.3 and 2019.1 while landing some native fixes here and there.

    Unfortunately, since then we've been slipping against that target to a position now where supporting 2018.3 -- *especially* given that it's an LTS release -- has become increasingly unviable. So with 0.3-preview, we'll probably have to move on to 2019.1 for good.

    I know this sucks. Sorry we didn't manage to line this up better :/

    I took us (especially me) a bit to give up on the plan and admit we won't make that, but yeah, unfortunately at this point no support for Unity 2018 is planned anymore. We missed our window there.
     
  19. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,371
    That's disappointing, but fair. I was holding off on making improvements to our input handling in order to switch it to the new input system, now I at least know that's not viable.


    It's probably a good thing that you're postponing it to 2019.1. Improved prefabs seemed ready, but has some very obvious drawbacks. That system wasn't ready for a LTS version, but here we are, and now we have to live with it. The approach you're taking with the Input system is much better.
     
    Rene-Damm likes this.
  20. KospY

    KospY

    Joined:
    May 12, 2014
    Posts:
    153
    Thanks for your reply. I hope 2019.1 will be stable enough then.

    @Rene-Damm However, could you tell us if fixes will be backported to 2019.1? Or does fixes will continue to be pushed in the latest alpha/beta version?
     
  21. Rene-Damm

    Rene-Damm

    Joined:
    Sep 15, 2012
    Posts:
    1,779
    2019.1 is the target. We are planning to backport/develop everything against that version and also to release against that version as the min supported version for 1.0-preview of the new system.
     
  22. Deleted User

    Deleted User

    Guest

    We're on 2020.1.0b11 and version 1.0.0 of the input system, and still seeing that XR Input requires game window focus (so your head doesn't move if you anything pops up).

    We're not shipping just yet, so we don't mind using editor functions as a workaround, but that "Lock Input To Game View" checkbox seems to be finnicky. sometimes it works, sometimes not.

    Is there an issue # we can track, or a github issue link or something?
     
  23. Deleted User

    Deleted User

    Guest

    For my own future-self reference when I google this issue again (hello, future me!):

    Window > Analysis > Input Debugger > Options > Lock Input To Game View.

    This option doesn't save with the editor so it has to be done periodically/with new projects/library refreshes/etc.
     
    loekgeelen, nonemec, Gruguir and 3 others like this.
  24. Tinus

    Tinus

    Joined:
    Apr 6, 2009
    Posts:
    437
    This post saved my life twice now.