Feedback mFI and tvOS abandoned?

I know that Unity's working on an over-engineered excuse to not fix input bugs but in the meantime, have you completely abandoned mFI and tvOS?

1. Input.GetButtonDown does not work properly.
Was reported in March. ( 1135106 ) Nothing changed.

2. Remote.allowExitToHome does not work at all and it working is required to submission.
It has been known since March. Nothing has changed since.

3. Remote.allowRemoteRotation does absolutely nothing.

4. Using the Siri remote touch area with Input.GetAxis is impossible since it immediately return 1 with the smallest movement so you can only have diagonal (1,1 : -1,1 etc) input. Even with Remote.reportAbsoluteDpadValues it's impossible to get a clear 0,1 direction, only diagonal ones.

 

Please announce that you are deprecating tvOS. You simply do not care.

Latest 2018.4.6 release notes state that allowExitToHome is fixed, and it sort of is, but now once you turn it to true, PRESSING THE "B" BUTTON EXITS TO HOME.

What is even worse, is that returning allowExitToHome to false, NOTHING CHANGES PRESSING THE "B" BUTTON EXITS TO HOME.

 

Sounds like a horrible situation. I do hope someone on the iOS team can respond to the issues (presumably issue tickets are already opened).

In the meantime, though, has OP looked into fixing the odd behavior in the exported Xcode project where (fortunately) all native implementations are available as source? I used to be in a similarly bizarre situation and have to patch the issues myself every time I export a clean copy of Xcode project, because (fortunately) I do iOS development as my day job so at least I knew what was going on.

BTW Lost Echo is an awesome game!

 

Yeah, I think that's what I'll resort to, but my process for building already contains a whole bunch of steps I have to do in XCode, I'm not looking forward to adding some more.

But I may have to, because according to QA, "B" acting like the "Menu" button is by design.

And they linked me to this : https://developer.apple.com/design/...tvos/remote-and-controllers/game-controllers/

So I'm not very hopeful it will be fixed, even though the page they linked actually says:

Which is not quite "By default, the "B" gamepad button has the same behaviour as the "Menu" button", which is simply untrue.

 

Latest 2019.3 12 beta seems to have taken out harmony controller because it broke the Apple TV remote.
Is it fixed now?

 

No, actually that's the equivalent LTS update that broke things for me.

The annoying part is QA is gaslighting me, telling me things are "by design" according to Apple.

 

I think I may have an explanation of the "Exit to Home" behavior.

In the "Expected behavior in an app", Apple says pressing B in an app would exit to Apple TV Home screen.



In iPhone_Sensors.mm, the "Allow Exit to Menu" control was implemented by simply setting [UIViewController controllerUserInteractionEnabled] to true or false:

Code (CSharp):

1. // [iOS/tvOS SDK] GCController.h : Line 45
2. #if TARGET_OS_IPHONE || TARGET_OS_TV
3. NS_CLASS_AVAILABLE(10_11, 9_0)
4. @interface GCEventViewController : UIViewController
5. #else
6. NS_CLASS_AVAILABLE(10_11, 9_0)
7. @interface GCEventViewController : NSViewController
8. #endif
9.  
10. ...
11.  
12. // [Unity-iOS] iPhone_Sensors.mm : Line 1063
13. extern "C" int UnityGetAppleTVRemoteAllowExitToMenu()
14. {
15.     return ((GCEventViewController*)UnityGetGLViewController()).controllerUserInteractionEnabled;
16. }
17.  
18. extern "C" void UnitySetAppleTVRemoteAllowExitToMenu(int val)
19. {
20.     ((GCEventViewController*)UnityGetGLViewController()).controllerUserInteractionEnabled = val;
21. }

If this is the intended implementation, I think the issue may have been the default behavior of UIViewController itself: when B button is pressed, the current ViewController would handle the interaction and pops itself from the hierarchy, and if there is no ViewController left, exits to home screen.

Granted, I don't have any relevant device to test this behavior (iOS 13 has Xbox controller support maybe I can try that), but, since tvOS/iOS template Unity made uses only one ViewController, if my speculation is true, pressing B button with controllerUserInteractionEnabled being true in a Unity game is the supposed correct behavior. I think the way to do is to only enable allowExitToMenu on the title screen of the game. Quoting Apple:

Re:

tvOS / iOS itself cannot distinguish if an app is also a game to behave differently. I think what Apple is trying to say is that developers are encouraged to defer button actions in a game type app. I think what Unity could have done is indicating this behavior in the API documentation so that people don't have to jump hoops to find answers.

 

As for why this is happening, have you tried DllExport the native C functions shown above in your C code and call those function directly in your C# code?

 

I mean, I'm making a game, why are you reading the "Expected behavior in an app" instead of "Expected behavior in a game"?

As such, Unity should not hard code such things and should give us options.

You're quoting Apple about the Menu button, not the "B" button.

Thank you for the other info, I'll make a serious attempt for a workaround in the next couple of days, I'll post my findings here.

 

tvOS is not using a UIViewController, it uses GCEventViewController instead, which is what Apple suggests for games that use a controller.

 

AcidArrow, you are a lifesaver.
I had a workaround for a Menu button not working and was planning to update to 2018.4.6. But you stopped me. I think I should stick with my workaround for a bit.

 

I'm only using this expected behavior of an app to deduce the default behavior of the event responder on ViewControllers.

I see your point and I apologize for not thinking deep enough on the issue, but I think Unity is not the one to blame here (at least partially). Apple is. I'm also shocked at the idea of quitting the app with B button on the top level screen on a console platform. It is unheard of.

If Unity wants to handle this like other gaming console, they'll have to add logic similar to this CocosSharp issue:

• Subclass the event delegate, and always set controllerUserInteractionEnabled to false
• In event delegate method, if the menu button is pressed, and only if Remote.allowExitToHome is set to true, set controllerUserInteractionEnabled to true and pass the event parameters to super class to get the default behavior i.e. quit to main menu.
• set controllerUserInteractionEnabled to false immediately after calling super class.

 

From what I have gathered:

B to exit is default when using UIViewController.

Unity is, correctly, not using UIViewController and are using GCEventViewController.

That makes 'B' work properly.

The issue is with Remote.allowExitToHome. It wasn't doing anything at all until recently, (actually AFAIK, most of the Remote API wasn't doing anything). Now that they "fixed" it, setting to true, somehow makes a game, fall back to UIViewController behaviour. I don't know why. The even more infuriating thing, is that setting it then to false again doesn't really change anything.

So, maybe the idea that 'B' being an exit under any circumstances (I'm guessing they did it for the Remote?), came from Apple, and that's kind of preposterous, but the way Unity has it set up now, is completely Unity's fault.

 

Did you manage to find a workaround? We are forced to update and uncancellable B button is something unacceptable.

 

Not quite. For the time being we have given up on using Remote.allowExitToHome. If you never touch it, "B" works properly.

 

As my investigation has shown for now - "B" button suspending an app is a native behavior - tvOS decides to convert "B"-press to a Menu call. From what I've dug - there is not specific code in Unity to force And it seems like a correct behavior for X1 and PS4 gamepads which don't have dedicated Menu button.

Unity no longer sets controllerUserInteractionEnabled and tries to check allowExitToHome inside pressesBegan:withEvent:

This almost seems to work. But there is a problem with SteelSeries Nimbus controller - somehow if it suspended once there is no means to disable suspend behavior at all - it just starts ignoring pressesBegan:withEvent: handlers.

And there was no such issue before 2018.4.6

So I really don't know who is here to blame. But it seems like Unity didn't really test this behavior.

There is also a minor issue when you change allowExitToHome right after you have received pressesBegan:withEvent. Then when you let "B" button go - it catches pressesEnded:withEvent and forces this suspend behavior. But this can be hacked and is more an issue of game logic rather than Unity bug.

Right now I'm stuck with SteelSeries Nimbus incorrect behaviour and I can't even use controllerUserInteractionEnabled anymore because it turns off B button completely.