Ce qu'un script ne peut pas bloquer

Le joueur peut toujours ouvrir le menu, réapparaître et quitter ton monde. NodeWorld le garantit quoi que fassent tes scripts : les quelques choses ci-dessous sont refusées ou annulées pour ça. Les joueurs lisent les mêmes règles dans Blocages, expulsions et bannissements.

Touches et boutons#

Input.GetKey, Input.GetKeyDown et Input.GetKeyUp ne voient jamais Key.Escape (le menu) ni Key.P (l'appareil photo) : ils renvoient toujours false. Key.Tab libère aussi le pointeur de la souris, et tes scripts la lisent quand même : un monde peut ouvrir un panneau avec, la souris est alors libre pour cliquer dessus. Key.R appuyé pendant qu'une touche Maj est tenue, c'est la réapparition du joueur : il reste non appuyé jusqu'à ce qu'il soit relâché. Maj, V et les autres touches sont à toi.

En VR, InputButton.LeftSecondary (Y sur les manettes Meta Quest Touch) ouvre le menu : Input.GetButton, Input.GetButtonDown et Input.GetButtonUp renvoient toujours false pour lui.

Un script peut donner le clavier à un de ses champs de texte (Select()) : tant que le joueur y écrit, tes scripts ne reçoivent aucune touche. Échap ouvre quand même le menu : il quitte d'abord le champ.

Le joueur#

Player.immobilized, walkSpeed, runSpeed, strafeSpeed, jumpImpulse, gravityStrength, velocity, sittingPoint et Player.Teleport n'empêchent jamais le menu : il s'ouvre, et en VR il suit le joueur quand tu le téléportes ou le pousses.

Quand le joueur choisit Réapparaître dans le menu, ou appuie sur Maj+R, NodeWorld lui rend d'abord ses propres mouvements (pas immobilisé, les vitesses et le saut de son rig, gravité 1, plus de vitesse donnée par toi, plus de point d'assise), puis le ramène au point d'apparition. Tes scripts reçoivent OnPlayerRespawn() comme pour toute réapparition : remets-y tes valeurs si ton monde en a besoin. Ton propre Player.Respawn() n'en change aucune.

Quand le joueur quitte ton monde, rien de ce que tes scripts ont réglé ne le suit.

L'interface reste devant#

Le menu, ses fenêtres, les notifications, le clavier et l'icône du micro sont dessinés après ton monde sur la couche 31 (NodeWorld UI), sans test de profondeur, et reçoivent les clics du joueur avant tout ce qui est à ton monde : avant un de tes canvas trié au-dessus d'eux, et avant un collider ou un objet interactif placé devant. Pour ça :

• la couche 31 n'est pas à ton monde : mettre layer à 31 sur un objet, ou sur un dessin par instances, est une erreur ; un objet de ta scène, ou une copie faite par tes scripts, trouvé sur la couche 31 passe sur Default (un avertissement dans le journal) ;
• une caméra de ton monde ne dessine que dans une render texture (miroirs, écrans, caméras de surveillance) : une caméra sans texture cible, allumée par un script, un Animator ou un événement, est éteinte ;
• un canvas de ton monde dessiné sur l'écran (Screen Space - Overlay, ou Screen Space - Camera sans caméra) garde un Sort Order de 31999 au plus : un ordre plus haut redescend à 31999, sous les écrans du client, qui commencent à 32000 ;
• tes caméras, miroirs compris, ne montrent jamais l'interface du client.

Seulement les objets de ton monde#

Tes scripts atteignent les objets de ta scène telle que tu l'as publiée, et les objets qu'ils créent (copies, caméras, render textures, copies réseau). Le menu n'est pas du tout dans ta scène. Pendant que ton monde tourne, NodeWorld pose aussi ses propres objets dans ta scène : les avatars des joueurs, les portails, les appareils photo des joueurs, leurs voix. Ils ne sont pas à toi :

• GameObject.Find, transform.Find et les recherches de tes scripts ne les voient pas, et les raycasts et les overlaps les traversent ;
• en changer un, ou mettre un de tes objets dessous, est une erreur ;
• un événement peut quand même t'en donner un à lire, comme le collider d'un joueur dans OnTriggerEnter.

Un objet de ta scène que tu sors de son parent (transform.parent = null) reste à toi. Le Play mode fait pareil : son rig et son avatar ne sont pas à ton monde.

Scripts qui ne finissent jamais#

Un appel de tes scripts dans lequel ton code tourne plus de 10 secondes (60 secondes pendant le chargement du monde ; le travail du jeu lui-même ne compte pas) est arrêté, avec tous les threads du monde, et le monde reste affiché ; le joueur voit une notification et le menu répond juste après. Tes threads de calcul ne sont pas surveillés : un thread qui ne finit jamais ne fige pas le joueur. Voir Threads et asynchrone.