Search Unity

  1. Unity 6 Preview is now available. To find out what's new, have a look at our Unity 6 Preview blog post.
    Dismiss Notice
  2. Unity is excited to announce that we will be collaborating with TheXPlace for a summer game jam from June 13 - June 19. Learn more.
    Dismiss Notice

Bug [Case 1402627] MultiplayerEventSystem breaks interaction and button visuals

Discussion in 'Input System' started by CDF, Feb 12, 2022.

  1. CDF

    CDF

    Joined:
    Sep 14, 2013
    Posts:
    1,321
    Hey, so using Input system 1.3.0, Unity 2021.2.7
    The MultiplayerEventSystem is breaking interaction and visual state of buttons contained underneath "playerRoot" objects.

    Here's a video showing the issue:


    Basically, when 2+ players are joined. Only the last player is able to navigate and interact with buttons under its associated playerRoot. The first player is unable to interact at all.
    Also, the visual state of all buttons seems to be in a constant change between "normal/selected" and "disabled".

    I assume this is because MultiplayerEventSystem manages a CanvasGroup on the "playerRoot" object. And every update is toggling "interactable" which causes nested Selectables to constantly switch between "normal/selected" and "disabled".

    And lastly, if you disable the first player gameObject then re-enable, interaction suddenly works correctly. However, the visual state is still incorrect.
     
    Last edited: Feb 12, 2022
    LeonidDeveloper likes this.
  2. LeonidDeveloper

    LeonidDeveloper

    Joined:
    Jan 23, 2021
    Posts:
    17
    dannyalgorithmic likes this.
  3. CDF

    CDF

    Joined:
    Sep 14, 2013
    Posts:
    1,321
    Yeah, it's going to be a tricky problem to solve. Feels like the Selectable API needs changing to support this functionality.
    Something like a SelectableGroup component, that Selectables are aware of and when making navigation choices, they query the SelectableGroup to see if the next navigation target is valid.

    The main problem is that the EventSystem was never designed to be used like this. And I'm not sure that even UIToolkit is fixing these issues as well, as that depends on the EventSystem in its current state too. And is the MultiplayerEventSystem even supported in UIToolkit? Since MultiplayerEventSystem requires a root gameObject, UIToolkit doesn't use gameObjects, so how does that work?

    Not a great situation for local co-op devs :(
     
  4. MarsCitizen_1

    MarsCitizen_1

    Joined:
    Jun 2, 2016
    Posts:
    20
    Just helping confirm this situation further. I just posted about it in the 1.3.0 announcement thread. I'll relay that info to save time for anyone curious.

    1. Selectables coloring settings goes right in the trash. Disabled vs Normal is not obeyed correctly. Almost everything starts showing up as disabled by default. Happens once you have more than 1 PlayerInput w/ their own canvases.
    2. Again, multiple players, multiple canvases: when new Selectables are instantiated on Player X's canvas, Player Y loses currently selected gameObject in MultiplayerEventSystem and is also unable to navigate back to items in their currently active canvas group.
     
    LeonidDeveloper likes this.
  5. LeonidDeveloper

    LeonidDeveloper

    Joined:
    Jan 23, 2021
    Posts:
    17
  6. dannyalgorithmic

    dannyalgorithmic

    Joined:
    Jul 22, 2018
    Posts:
    100
  7. MarsCitizen_1

    MarsCitizen_1

    Joined:
    Jun 2, 2016
    Posts:
    20
    The issue persists in inputsystem 1.4.1 FYI for anyone digging around on this topic. Still 1.2.x was the last time this problem didn't exist.
     
    dannyalgorithmic likes this.
  8. dannyalgorithmic

    dannyalgorithmic

    Joined:
    Jul 22, 2018
    Posts:
    100
    bumped the F*** out of this glorious comment
     
    MarsCitizen_1 likes this.
  9. andrew_oc

    andrew_oc

    Unity Technologies

    Joined:
    Apr 16, 2021
    Posts:
    77
    So this issue should be fixed by this pull request https://github.com/Unity-Technologies/InputSystem/pull/1547 but because that fix has a new public API property, it has to go into the 1.5 release. There's no release date for that yet, but you can change your input system package to point at the git repo if you want to at least verify that it fixes the issue for you.