Loading screen fade-in animation problems

[pravusjif]

The loading screen feels super broken due to its fading animations and the timings that animation has with the world teleportation:

1. When a new user is created we see the broken world before the fade-in animation of the loading screen...

https://user-images.githubusercontent.com/1031741/182938938-4bdaa2d3-2c60-4b16-936d-8d529abf1ff9.mp4

2. When a user executes a jump-in using the scene-triggered jump-in prompt the same problem can be seen...

https://user-images.githubusercontent.com/1031741/182939245-555dbed1-7cb3-430e-9086-6a62db5d9f0b.mp4

3. When a user executed a jump-in from the Explore panel, the panel closes showing the world, then the world is unloaded and then the loading screen fade-in animation starts...

https://user-images.githubusercontent.com/1031741/182939310-fde380db-67cb-404f-953e-8d1bcaa3df72.mp4

4. The same happens doing a jump-in from the world map...

https://user-images.githubusercontent.com/1031741/182939490-e06a1e72-125f-4241-b9e6-a002fe9cc61c.mp4

---

I think all of this would be fixed with 2 changes

• Every time a teleportation is triggered from a full-screen UI (like the Explore panel or the Worldmap) the loading screen should appear instantly (no fade-in animation)
• Every time a teleportation is triggered in-world (/goto chat command, jump-in prompts, etc.) the loading screen should have the fade-in animation BUT the teleportation logic should start AFTER the fade-in animation finishes...

The fade-out animation of the loading screen is never a problem, only the fade-in.

[pravusjif]

This is affecting the desktop client

[pravusjif]

Updated issue description and proposed solution.

The main problem to fix this issue with the loading screen fade-in is that Kernel controls the toggling of the loading screen.

These are the 3 possible approaches I can think of:

A. Update Client-Kernel communication to take into account if the teleport is being started from a fullscreen UI and affect the loading screen fade-in usage with kernel's message

NOTE: this approach can't solve the issue of starting teleportation before the fade-in finishes its effect

1. Implement new requestedFromFullScreenUI boolean to be sent from the Client to the Kernel with every GoTo/JumpIn messages sent
2. Track that new value internally in Kernel to be able to know in which situation Kernel should tell the client to enable the loading screen instantly or using fade-in. This requires refactoring the teleportObservable logic and teleportTriggered dispatching.
3. Update Kernel->Client SetLoadingScreen message to have the new boolean so that Kernel can tell the Client when to set the loading screen instantly or with fade-in
4. In the client we should refactor how we trigger the FadeIn animation since now we do that just toggling values in the DataStore, and the LoadingHUDController listens to those value changes and triggers the animation accordingly. But adding a new value in the DataStore for knowing if it should be toggled instantly or not is super hacky

B. Trigger loading screen from the client ignoring most/all Kernel messages regarding the loading screen.

NOTE: this approach probably breaks the loading screen text/tips that Kernel sends to the client, since those come in kernel's message

1. Centralize the teleportation logic into a new TeleportController class instead of having disperse calls to WebInterface.GoTo()/WebInterface.JumpIn() in 6 scripts (JumpInAction.cs, TeleportHUDController.cs, ExplorePlacesUtils.cs, ExploreEventsUtils.cs, GotoPanelHUDController.cs, NavmapToastView.cs)
2. Provide the option of triggering the loading screen instantly or with fade-in when using the new TeleportController
3. Ignore most/all Kernel calls to LoadingBridge.SetLoadingScreen() to override Kernel's loading screen toggling that messes up the client-triggered toggling.
4. Implement the loading screen toggling on every point it's needed (since we would start ignoring Kernel's messages for that) and that includes for example checking that all the scene assets have finished loading to trigger the fadeout as well.

C. Stop using fade-in for loading screen. Fix time between assets unload and loading screen enabling.

1. Update LoadingHUDController to NEVER use fade in animation for the loading screen, and always enabling it instantly
2. Fix time between scenes unloading and loading screen enabling
3. When the teleport is triggered from a full screen panel (Explore panel, Worldmap panel) the panel should wait for the loading screen to be enabled, before auto-closing the panel

Extra

• The instant parameter in ShowHideAnimator.Show() and ShowHideAnimator.Hide() must be fixed because this doesn't work.

---

Probably C. is the most cost-effective but it also involves uncertainty with the needed debugging.

[pravusjif]

After trying to go with approach C., I've reached the conclusion that this can't be fixed without giving full control of the loading screen to the client (or something hacky in kernel to wait some time after signaling the loading screen enabling to the client, before triggering the real teleport logic).

When debugging C.2 I see that the loading screen toggling message is sent at the correct moment in Kernel, but the entrypoint in the client takes like 3 seconds to receive the message and start its logic... so we always see the world unloading before our eyes and the loading screen is toggled after that.

I attempted several ways of achieving the desired effect, but got nowhere.

[aixaCode]

After discussing with @menduz and @AjimenezDCL we agreed to start working on RFC to move loading controll to Unity side and define conditions for new messages on kernel side.

[aixaCode]

RFC started for agreeing on next steps