koobas.hobune.stream
Has anybody had trouble using UnityUI after returning from Handheld.PlayFullScreenMovie on Android?
Currently helping a friend with her documentary project on an Android tablet and we've encountered what seems like an odd problem - when playing the video (in streamingassets) and skipping to the end in the Android viewer, upon returning to Unity it seems as though the UI buttons on screen are disabled. However, the buttons become active again after a short time - almost as if there's an interact delay until after the time it would have taken for the video to have played if uninterrupted.
The video instruction runs in a cooroutine with a yield return new waitforendofframe() at the end, followed by some debug.logs just to help keep track of things when not running the program in Android.
Does this ring a bell for anybody? Any clues on what this could be? Incredibly frustrating...
--Rev
I've been having a similar issue. $$anonymous$$y uGUI is unresponsive after skipping the video and my raycasts work partially. I have spent days thinking that it might have been a bug in my coding until I started searching the internet and realized that others are having similar experiences.
It also seems that Handheld.PlayFullScreen$$anonymous$$ovie method was not regression tested enough with the uGUI - just speculation on my end; mainly because there are a lot of people following this issue. I will keep you posted if I find out about a workaround or just more information in general.
Appreciate the follow-up! As it happens, further testing on the device seemed to show that the Android navigation UI seems to interfere with any UGUI elements towards the bottom of the screen immediately after leaving the device player. Our solution was to move our interface further up out of the extreme lower area of the screen where the Android/UGUI conflict was happening - and hey presto, everything worked responsively on return from video.
If you can afford to move your interface further up from the absolute bottom of the screen, this seems to be a decent workaround (assu$$anonymous$$g that this is where you're having interface issues!).
Depending on how this situation develops for other folks in the next week or so, I'll probably convert this comment to an answer and mark it correct.
Not a problem! I also found a workaround for my issue.
About $$anonymous$$y Project The project that I am working on uses the accelerometer for movement and screen touches to look around (the player can use any part of the screen to do this). The reticle changes shape and color when an item or NPC is in range and interaction can occur. The user progresses through the application by interacting with these action points; each of which activates subsequent points. Overall it is being used to assess the player's knowledge retention, empathy, and decision making skills.
The Problem After the video is skipped (on mobile builds only), the raycast would not recognize the triggered NPC. This effectively blocked player progression and users would have to force quit the application altogether.
Dev Notes Something else that is worth noting: $$anonymous$$y player character uses two simultaneous raycasts. The first of which is the 'vision raycast' which is used to spot items and NPCs within a certain range and line of sight. The second is the 'interaction' raycast - this is much shorter (relatively speaking) and deter$$anonymous$$es if an object or NPC can be interacted with.
After adding feedback 'hooks' in the code (which communicated states to a few different cubes via color changes), I found out that only the vision raycast was working as intended after the video had been skipped. This is very odd - especially because the system worked everywhere else.
The Workaround I tried nearly everything you could imagine in efforts to restore the raycast functionality after the video was skipped. I finally decided that the NPC should automatically begin speaking after the video ended (by any means). This actually resulted in a better user experience (when measuring necessary vs. unnecessary inputs) and a new, reusable feature for NPCs that cannot be interacted with because of distance restrictions on the interactive raycast.
It would be interesting to see if others come forward with other issues related to Handheld.PlayFullScreen$$anonymous$$ovie.
