BonelabRP Téléphone 0.8.9

Projet complet BONELAB PCVR : .NET 6 x64, MelonLoader, BoneLib 3.2.2, Fusion 1.14.2 et LabRP 1.1.2. Module Téléphone indépendant du métier Éboueur.

Installation

1. Fermer complètement BONELAB.
2. Extraire ce ZIP dans un nouveau dossier et ouvrir BonelabRP.Telephone.csproj dans Visual Studio.
3. Compiler en Release / x64.
4. Remplacer BonelabRP.Telephone.dll dans C:\Program Files (x86)\Steam\steamapps\common\BONELAB\Mods par bin\Release\net6.0\BonelabRP.Telephone.dll. Ne conserver qu'une DLL du Téléphone.
5. Installer la version 0.8.9 chez l'hôte et tous les clients, puis relancer.

Le chemin du jeu est déjà renseigné dans le projet. Les références sont celles du jeu installé. Si une DLL Il2CppAssemblies manque, lancer BONELAB avec MelonLoader puis le fermer. Les pallets Phone (CharaWhy.Phone.Spawnable.Phone) et Fusion Content sont nécessaires au prop et au laser du doigt.

Le protocole Téléphone passe à 15. Les anciennes versions du module ne sont pas compatibles avec cette version. L'archive contient les sources complètes et les tests, pas une DLL prête à jouer.

Garder UserData\BonelabRP\Telephone. Les numéros, contacts, SMS, posts Windy, réglages et placement de l'écran sont conservés. Le correctif du premier grab et les dates françaises compatibles avec le mode invariant restent présents. Aucune interception Harmony des méthodes BaseController n'est utilisée.

Rappel et maintien au spawn 0.8.9

BoneMenu > Téléphone > Rappeler mon téléphone devant moi : si le téléphone existe encore, le même objet réseau est ramené devant la tête du propriétaire. Le rappel ne détruit plus le prop ni son écran et ne repasse pas par le spawn réseau complet. Fusion récupère l’autorité sur l’objet pour le repositionnement. Si le téléphone est tenu, le rappel est refusé : le relâcher d’abord. Un délai de deux secondes limite les rappels successifs. Une préparation déjà en cours n’est pas relancée.

Si le téléphone est absent, une création réseau reste nécessaire. La référence du spawnable est mise en cache ; la recherche n’énumère plus tous les crates. L’écran local n’est construit qu’à la première prise en main et reste réutilisable sur le téléphone relâché. Les coins arrondis sont calculés dans un tableau C# avec MathF puis envoyés à Unity par SetPixels, au lieu de milliers de SetPixel et de calculs natifs séparés. Cela réduit le travail lié à l’écran ; le chargement initial et l’instanciation native du modèle BONELAB ne sont pas rendus entièrement asynchrones.

Au premier spawn et après chaque rappel, les vitesses sont annulées une seule fois et la gravité est suspendue jusqu’à la prise en main. Aucun blocage des contraintes, de la rotation ou du transform n’est appliqué. Le grab reste libre de déplacer le téléphone ; la gravité native est restaurée dès la prise locale ou distante. Après le lâcher, la physique reste normale jusqu’au prochain rappel. Un choc peut déplacer le téléphone en attente.

Installer 0.8.9 chez l’hôte et tous les clients : protocole 16. Fermer BONELAB, compiler Release/x64, remplacer la DLL puis relancer. Conserver UserData. Le traitement de la voix et les notifications sont conservés.

Test en jeu à deux : créer le téléphone et attendre cinq secondes sans le toucher, vérifier sa stabilité des deux côtés. Le prendre puis le lâcher, vérifier sa physique normale. Le rappeler au sol plusieurs fois, comparer le temps de blocage à 0.8.2, puis reprendre. Refaire ces tests côté client et avec le téléphone pris par un autre joueur ; vérifier le refus du rappel lorsqu’il est tenu. Changer de map puis recommencer. Aucun chronométrage natif ni test physique Fusion réel n’a été réalisé ici : la disparition complète du blocage de la première création n’est pas garantie.

Notifications Windy 0.8.2

Quand un autre joueur publie un post Windy, les joueurs connectés avec le module Téléphone reçoivent une notification Windy : pseudo de l’auteur et aperçu du texte. Les publications avec seulement une photo donnent aussi une notification. Lorsqu’un joueur démarre un live avec succès, une notification indique son pseudo et le début du live.

Les notifications utilisent le système du téléphone : sonnerie de message existante, bannière de six secondes et historique Notifications de vingt éléments maximum. Aucun popup Fusion ajouté. Toucher la notification d’un post ouvre le fil Windy et l’actualise ; toucher celle d’un live ouvre la liste des lives actualisée, où le joueur choisit de rejoindre. Un live terminé n’est pas rejoint automatiquement.

L’auteur ne reçoit pas sa propre notification. Les demandes de synchronisation, les commentaires, likes et simples mises à jour ne déclenchent pas de nouvelle notification. Une publication rejouée avec le même nonce ne notifie pas à nouveau. Les notifications sont destinées aux comptes des téléphones : pour un téléphone prêté et déverrouillé, elles suivent le compte utilisé. Le système respecte les règles de verrouillage de l’interface existante. Les notifications ne rattrapent pas les événements survenus hors connexion. Libellés français et anglais.

Installer 0.8.2 chez l’hôte et les clients ; protocole 13 inchangé. Conserver UserData. Tests à deux : B publie un texte puis une photo, A voit la bannière, entend sa sonnerie et ouvre Windy ; B lance ensuite un live, A reçoit l’alerte et peut ouvrir la liste pour le rejoindre. Vérifier que B ne reçoit pas sa propre alerte, qu’Actualiser ne crée pas de doublon, et que les alertes apparaissent dans Notifications. Les sources audio sont identiques à 0.8.1.

Audio natif 48 kHz et pertes réseau 0.8.1

Installer 0.8.1 chez l’hôte et tous les clients : protocole 13. Fermer BONELAB, compiler Release/x64, remplacer la DLL puis relancer. Conserver UserData et ne garder qu’une version du Téléphone dans Mods.

Les appels et les lives utilisent une capture PCM mono 16 bits à 48 kHz lorsque le clip micro fournit au moins cette fréquence. Si le micro fournit une fréquence inférieure, la transmission utilise 32 kHz ou 16 kHz sans fabriquer un signal plus détaillé. Les blocs restent de dix millisecondes : 480 échantillons et 968 octets à 48 kHz avant l’enveloppe réseau. Les messages vocaux choisissent aussi 48/32/16/8 kHz selon la fréquence du clip ; les anciens fichiers de ces fréquences restent lisibles. La durée maximale reste quinze secondes.

Pour les appels, les lives et l’écoute en haut-parleur, le lecteur détecte les numéros de paquets manquants après la remise en ordre. Il insère une courte descente vers le silence puis une reprise progressive lorsque la voix revient. La compensation est limitée à 200 ms ; une interruption importante reste audible. Cela réduit les changements brusques sans prétendre reconstruire les mots absents. Une limitation douce des fortes amplitudes remplace une partie des coupures nettes de crêtes et la bande du filtre de lecture est adaptée à la fréquence supérieure.

Les voix de proximité à deux mètres restent présentes dans les lives, les vocaux et les appels en haut-parleur. Elles restent issues du vocal Fusion reçu et conservent les limites de ce codec. Le son des sources du téléphone n’est pas repris dans le mélange. La saturation déjà enregistrée par un micro ne peut pas être annulée par ce traitement.

Un vocal de quinze secondes à 48 kHz peut peser environ 1,44 Mo. Les limites de réception et de file fiable ont été adaptées ; le transfert est cadencé. Les autorisations, la récupération du cache et les relances restent actives. Les vieux messages et les réglages restent conservés.

Test à trois joueurs : nouveau vocal de cinq secondes, préécoute puis écoute après réception ; appel, haut-parleur activé/désactivé avec un joueur proche ; live avec le même joueur proche puis distant. Tester aussi un vocal de quinze secondes et un redémarrage. Comparer à volume identique. Les tests simulés vérifient les pertes et transitions ; ils ne reproduisent pas le réseau Steam ni le matériel audio en jeu.

Audio 32 kHz et voix proches 0.8.0

Installer 0.8.0 chez l’hôte et tous les clients : protocole 12. Conserver UserData. L’archive contient le projet complet ; compiler Release/x64 avec les DLL du jeu installé.

Appels et lives : le micro déjà ouvert par Fusion est lu directement, en conservant la correction de copie native Il2Cpp. La voix du propriétaire est filtrée et convertie en PCM mono 16 bits à 32 kHz. La transmission utilise des trames de dix millisecondes : 320 échantillons, 648 octets avant l’enveloppe réseau, cent trames par seconde. Cette voie ne passe plus par l’encodage G.711 de Fusion. Le décodeur réadapte le signal à la fréquence du lecteur Unity ; les tampons de remise en ordre et de lecture restent en place. La voix normale de proximité du créateur d’un live continue de fonctionner via Fusion. Les appels restent privés.

Messages vocaux : nouveaux enregistrements à 32 kHz, avec filtrage avant conversion et interpolation continue entre blocs. Les anciens fichiers 8 et 16 kHz restent lisibles. Quinze secondes maximum, jusqu’à environ 960 Ko ; file d’envoi adaptée à 2 048 fragments et réception fiable à 4 096. Les transferts fiables sont cadencés pour rester sous le budget de réception et peuvent être plus longs. Les droits de téléchargement et les relances de 0.7.5 restent présents.

Voix proches : le téléphone reprend les voix de proximité des autres joueurs reçues par Fusion, à deux mètres maximum du téléphone. Elles sont mélangées dans les vocaux et les lives, et dans les appels seulement lorsque le haut-parleur local est activé. En appel normal, le correspondant reçoit uniquement le micro de l’utilisateur. Les contacts muets et le correspondant de l’appel sont exclus du mélange. Le volume des voix proches est réduit, les données périmées ou hors portée sont retirées et une limitation douce évite le débordement lors d’un mélange de voix fortes. Le son des sources de lecture du téléphone n’est pas repris ; aucun son du jeu ou haut-parleur physique n’est ajouté. La qualité des voix proches reste celle reçue par Fusion : elles ne retrouvent pas des détails perdus par son codec. Huit intervenants proches simultanés maximum dans le mélange.

La capture des autres voix utilise une interception gérée UnityVoiceSpeaker.OnVoiceDataReceived. Aucune nouvelle interception native BaseController et aucun deuxième Microphone.Start/End. Les voix proches doivent être reçues par le vocal Fusion : les joueurs muets ou hors réseau vocal ne peuvent pas être ajoutés. Un filtre ne répare pas un micro saturé et aucune suppression totale des grésillements n’est garantie.

Test en jeu à trois : A appelle B, C se place près de A. B ne doit entendre C que lorsque A active le haut-parleur ; éloigner C au-delà de deux mètres et vérifier la coupure. A enregistre ensuite un nouveau vocal pendant que C parle, le réécoute puis l’envoie à B. Faire un live A vers B avec C proche, puis distant, et vérifier le mélange sans boucle. Tester micro muet, contact muet, changement de map, réception de quinze secondes et relecture. Comparer la voix du propriétaire avec 0.7.5 à volume identique. Micro, réseau Steam/Fusion et rendu VR natifs restent à confirmer dans BONELAB.

Vocaux reçus : téléchargement 0.7.5

Correction du cache manquant : PhoneNoteStore.Read lançait InvalidDataException pour un fichier absent, tandis que Listen ne capturait que IOException. Cette exception empêchait la demande voiceFetch au serveur. TryRead distingue désormais un cache disponible d’un fichier absent/invalide ; seul ce dernier déclenche un téléchargement. Un cache corrompu est retiré localement avant de recevoir à nouveau le fichier valide, sans supprimer l’original serveur.

Le bouton affiche Chargement pendant la récupération ; le toucher annule l’attente. Trois tentatives maximum espacées de dix secondes, puis un message explicite si le téléchargement expire. Chaque réception garde les vérifications de session, de déverrouillage et de présence du vocal dans la conversation ; chaque envoi serveur garde la validation des droits du lecteur. La lecture démarre une fois le fichier entièrement assemblé et validé.

La réception fiable accepte jusqu’à 2 048 fragments en attente au lieu de 256 afin de limiter les pertes lors d’une arrivée groupée d’un vocal 16 kHz. La limite des flux vidéo reste à 256. Le nettoyage des données privées du téléphone de l’hôte conserve les réponses serveur destinées aux clients et les requêtes serveur entrantes ; les droits restent revérifiés avant l’envoi. Une déconnexion complète efface toujours ces files.

Installer 0.7.5 chez l’hôte et tous les clients, redémarrer BONELAB, conserver UserData. Protocole 11 inchangé. À deux joueurs : envoyer un nouveau vocal vers un destinataire qui ne l’a jamais écouté ; appuyer Écouter, attendre Chargement puis vérifier le son. Réécouter pour vérifier le cache local. Inverser les rôles hôte/client, tester quinze secondes, annuler le téléchargement et verrouiller le téléphone de l’hôte pendant qu’un client télécharge.

259 vérifications passent, dont cache manquant, valide, corrompu et remplacement après récupération. Compilation de contrôle sans erreur. Les tests automatisés ne reproduisent pas une connexion Steam/Fusion réelle. Les assertions Steam networking ICE du journal fourni ne permettent pas à elles seules de conclure qu’elles causent ce problème.

Qualité vocale 0.7.4

Les nouveaux messages vocaux sont enregistrés en PCM mono 16 bits à 16 kHz, au lieu de 8 kHz. Le rééchantillonnage garde l’état du filtre et sa phase entre les blocs du micro. Les blocs sont assemblés selon leurs échantillons consécutifs, sans les déplacer selon les horodatages des images du jeu : cela évite les petites coupures et les chevauchements dus aux variations de FPS.

La capture comporte un filtre passe-haut à 75 Hz pour réduire les basses parasites, et deux sections passe-bas avant la réduction de fréquence pour réduire le repliement spectral. Les messages ont une courte montée et descente de volume à leurs extrémités. Les appels et les lives ont aussi le filtre de parole avant le tampon PCM ; le tampon de lecture et ses protections contre les retards réseau restent présents. Ce traitement ne reconstruit pas un micro qui sature et ne garantit pas l’élimination de tous les bruits dans la bande de la voix. Les appels gardent le codec utilisé par Fusion.

Les anciens vocaux à 8 kHz sont toujours lisibles. Leur qualité enregistrée ne change pas ; enregistrer un nouveau vocal pour comparer. La durée maximale reste quinze secondes. Le transfert d’un vocal à 16 kHz peut peser environ 480 Ko ; les limites de transfert ont été adaptées. Données, numéros, PIN et réglages restent conservés.

Installer 0.7.4 chez l’hôte et tous les clients : protocole 11. Tester un nouveau message de cinq à dix secondes, réécouter avant envoi puis depuis le fil. Comparer un appel puis un live, au même volume. 255 tests automatisés réussis : continuité indépendante de la taille des blocs, fréquences parasites atténuées, conservation de la parole à 1 kHz, compatibilité 8/16 kHz et transfert du vocal maximal. Compilation de contrôle sans erreur. Le résultat auditif réel reste à confirmer dans BONELAB.

Tableau natif du micro 0.7.3

Correction du transfert Il2Cpp : AudioClip.GetData doit remplir un Il2CppStructArray<float>. Passer un float[] C# créait une conversion vers un tableau natif, mais ne recopiait pas les valeurs dans le tableau C# ensuite lu. Cette version lit explicitement le tableau natif et copie ses échantillons via InteropUtilities.Copy, comme UnityVoiceReceiver dans la DLL Fusion 1.14.2 fournie.

Le niveau visuel est amplifié par 10, comme l’indicateur Fusion, pour rendre les voix faibles visibles ; il s’agit d’un indicateur, pas d’une mesure calibrée. Démarrage du micro / Micro actif indiquent l’état de capture. Si aucun clip n’est ouvert, si le micro ne capture pas ou si son curseur ne bouge pas, l’enregistrement s’arrête avec une erreur précise après deux secondes. Un diagnostic Capture vocal et le nombre d’échantillons lus sont alors écrits dans le journal MelonLoader. Le contrôle du silence reste actif.

Compiler Release/x64, remplacer la DLL puis redémarrer BONELAB. Tester un nouveau vocal de cinq secondes : parler, arrêter, réécouter avant envoi. Le niveau doit réagir. Si cela reste muet, conserver le message Capture vocal du journal et le statut affiché sur le téléphone. Le rendu et le périphérique audio natifs ne sont pas exécutables dans cet environnement. Les données précédentes et le protocole 10 sont conservés.

Capture micro 0.7.2

L’enregistrement lit les échantillons flottants du clip micro déjà ouvert par Fusion 1.14.2, au lieu de dépendre des paquets vocaux sortants. Aucun deuxième Microphone.Start/End et aucune interception native supplémentaire. La capture respecte le micro choisi dans Fusion et exige qu’il soit activé et non muet. Le clip du récepteur UnityVoiceReceiver est lu par réflexion dans la version Fusion ciblée ; une API incompatible bloque le démarrage.

L’écran indique Niveau micro pendant l’enregistrement. Une capture sans signal audible est refusée avec un message explicite. Les échantillons sont convertis en PCM mono, le bouclage du clip est traité et les voix faibles sont amplifiées avec un gain plafonné. La préécoute et la lecture utilisent la même piste locale. Le format et le protocole 10 restent inchangés.

Test en jeu : après redémarrage avec 0.7.2, sélectionner le bon micro et désactiver Muet dans Fusion. Enregistrer un nouveau vocal de cinq secondes : le niveau doit réagir quand tu parles. Arrêter, réécouter deux fois avant envoi, puis envoyer au contact déjà enregistré, même hors ligne, et écouter dans le fil. Enregistrer ensuite sans parler : vérifier le refus si aucun signal n’a été capturé. Les anciens fichiers contenant du silence ne peuvent pas retrouver la voix manquante ; il faut les réenregistrer. Conserver UserData.

248 vérifications automatisées et compilation de contrôle sans erreur. Le micro, la préécoute et le rendu natifs doivent être confirmés dans BONELAB.

Correctif vocaux 0.7.1

La lecture des fichiers vocaux et la préécoute du brouillon ne dépendent plus de la disponibilité du gestionnaire vocal Fusion. Le micro Fusion reste nécessaire pour enregistrer. À chaque lecture, une nouvelle source audio locale démarre depuis le début ; arrêter puis réécouter ne réutilise plus une ancienne source native. Le vocal envoyé est aussi conservé dans le cache de l’expéditeur. Les échecs de lecture restent visibles au lieu de déclencher un téléchargement inutile.

L’onde sonore décorative est dessinée avec des barres Unity, sans caractères spéciaux manquants dans la police. Boutons Écouter / Arrêter en texte, traduits en anglais.

Le contact n’a pas besoin d’être connecté pour relire un vocal dans sa conversation. Son compte doit déjà exister sur ce serveur pour l’envoi, comme pour un SMS. Protocole 10 inchangé ; installer 0.7.1 chez tous les joueurs pour bénéficier des corrections. Conserver UserData.

Test en jeu : rester seul dans la session, enregistrer puis réécouter trois fois un brouillon, envoyer vers un contact enregistré hors ligne et relire le message trois fois. Arrêter en cours puis relancer ; chaque lecture doit repartir du début. Vérifier les barres dans les deux thèmes. La validation automatisée ne remplace pas ce test audio natif.

Messages, AirDrop et vocaux 0.7.0

Messages : conversations avec aperçu, indicateur non lu, bulles envoyées/reçues, heures et photos directement dans le fil. Toucher un texte pour le lire en entier ; toucher une photo pour l’agrandir. Le fil affiche deux messages par page, les plus récents en premier à l’ouverture.

Dans une conversation, sélectionner Vocal > Enregistrer, parler, puis Arrêter. Réécouter permet de vérifier avant Envoyer ; Réenregistrer remplace le brouillon. Arrêt automatique à 15 secondes, durée minimale de 0,5 seconde. Le micro Fusion doit être actif. L’enregistrement est indisponible pendant un appel ou un live ; quitter cette page ou verrouiller annule le brouillon. Pendant l’enregistrement, la voix capturée n’est pas diffusée en proximité. Le destinataire reçoit une notification sur le téléphone puis touche ▶ dans la conversation pour écouter ; ■ arrête. Les vocaux sont mono, enregistrés côté serveur, et consultables uniquement dans les comptes participants après déverrouillage. Un téléphone prêté suit les mêmes droits et le même code que pour les SMS.

AirDrop : cartes des joueurs compatibles à moins de 3 mètres, distance affichée, partage ciblé en touchant une carte ou partage à tous. Jusqu’à trois joueurs proches affichés. Les numéros reçus ont leur propre liste paginée ; toucher + ouvre la fiche contact avant enregistrement. Le serveur vérifie lui-même la distance et impose un délai entre partages.

Installer 0.7.0 sur l’hôte et tous les clients : protocole 10. Les anciennes données restent conservées. Ne pas supprimer UserData\BonelabRP\Telephone. Les dossiers server-voice et voice-cache contiennent les nouveaux vocaux ; limites de stockage : 100 vocaux envoyés par compte, 1 000 sur le serveur et 2 000 dans le cache local. Le lecteur vocal des appels reste inchangé.

Tests en jeu à deux : envoyer texte, photo et vocal ; écouter de chaque côté, interrompre puis réécouter. Tester l’arrêt automatique, le verrouillage pendant l’enregistrement et la conservation après redémarrage. Vérifier AirDrop à moins puis à plus de 3 mètres, partage ciblé, notification et ajout du contact. Tester thèmes clair/sombre et langue anglaise. Audio, interactions et rendu VR natifs restent à valider dans BONELAB.

Thème et fond d’écran 0.6.6

Réglages > Apparence : choisir Clair ou Sombre. En anglais : Settings > Appearance > Light / Dark. Le thème change les fonds, cartes, textes et légendes des applications, de l’accueil et du verrouillage. L’écran d’appel conserve son fond sombre pour le contraste. La préférence est locale et enregistrée avec les réglages, comme la langue ; les anciens réglages restent en thème clair.

Apparence > Choisir dans la Galerie : choisir une photo déjà synchronisée de ce téléphone. Cette même image apparaît sur l’écran de verrouillage et sur l’accueil après déverrouillage. Elle est recadrée au centre sans déformation, avec une couche sombre pour garder lisibles l’horloge, les icônes et le code. Retirer le fond d’écran restaure le fond du thème.

Le fond est enregistré côté serveur avec le compte du téléphone : il reste après redémarrage et sur un téléphone prêté. La photo choisie est volontairement visible avant déverrouillage. Le serveur vérifie la prise physique du téléphone pour autoriser ce téléchargement sans PIN ; les autres images, SMS et contacts restent soumis au déverrouillage. Si l’original est retiré de Galerie, l’image affectée reste protégée du nettoyage serveur tant qu’elle sert de fond.

Protocole 9 : installer 0.6.6 chez l’hôte et tous les clients. Numéros, codes, contacts, historiques, langue et réglages précédents restent conservés. Le correctif vocal reste inchangé.

Tests en jeu : sélectionner les deux thèmes et parcourir contacts, Téléphone, banque, Windy et Galerie. Choisir un fond, verrouiller puis déverrouiller, vérifier son cadrage et la lisibilité, puis redémarrer. Tester un téléphone prêté encore verrouillé : son fond doit être visible mais ses images privées rester inaccessibles. Retirer le fond et vérifier le retour au thème. Rendu VR natif non exécuté dans cet environnement.

Application Téléphone et appels masqués 0.6.5

Téléphone s’ouvre sur un vrai pavé numérique : saisie directe, effacement, bouton Appeler et Visio, onglets Clavier / Récents / Contacts. La touche crayon ouvre un éditeur numérique. Le texte reste lisible sur un fond clair. Après un appel, l’application revient à Récents.

Pour appeler en masqué, saisir # avant le numéro, par exemple #0612345678 ou #06 12 34 56 78. La touche # du pavé ajoute ou retire ce préfixe. Sans #, l’appel est normal. Le serveur retire uniquement ce préfixe au moment de rechercher le destinataire et impose le masquage dans l’état d’appel envoyé au destinataire.

Le destinataire voit Numéro masqué / Private number, sans nom de contact ni photo. Son état d’appel ne contient pas le numéro, même après acceptation, et son historique conserve une entrée masquée sans numéro ni rappel possible. L’appelant voit le numéro appelé et un indicateur Appel masqué. Le masquage ne change ni le numéro attribué ni les SMS. Une visio volontairement activée peut montrer la caméra comme dans un appel normal. Le masquage concerne l’identité affichée par WindyPhone ; le serveur hôte et le routage Fusion connaissent toujours les participants.

Récents affiche les cinquante derniers appels par compte : entrant, sortant, manqué, refusé ou annulé, heure et durée pour un appel répondu. L’historique est enregistré par l’hôte à la fin de l’appel et conservé dans accounts.json ; les anciennes versions n’ont pas de données d’appels à importer. Sélectionner une entrée normale prépare le numéro dans le clavier. Une entrée masquée sortante conserve le préfixe # pour le rappel. Les téléphones prêtés utilisent l’historique du propriétaire du téléphone déverrouillé.

Le protocole passe à 8 : installer 0.6.5 chez l’hôte et tous les clients. Numéros, codes, contacts, photos, langue et réglages restent conservés. Le lecteur vocal reste celui de 0.6.2.

Tests en jeu : appel normal puis appel # entre deux joueurs, avec un contact enregistré et une photo associée côté destinataire. Vérifier l’absence du nom et de la photo en masqué, puis répondre, raccrocher et consulter Récents des deux côtés. Tester appel manqué, refus, annulation, durée, rappel depuis Récents, téléphone prêté et conservation après redémarrage. Rendu natif VR et audio non exécutés ici.

Langue et nom 0.6.4

Réglages > Langue > Français ou English. Le changement est immédiat ; une coche indique la langue active. En anglais, le chemin est Settings > Language. La préférence est locale au PC et sauvegardée avec les réglages de sonnerie : les autres joueurs conservent leur propre langue. Les anciens réglages sans langue restent français.

Les libellés de navigation, contacts, SMS, banque, Galerie, photo, appels, verrouillage, réglages et Windy sont bilingues. Les dates n’utilisent pas de culture fr-FR système : elles restent compatibles avec le mode invariant de MelonLoader. Le clavier de saisie passe de AZERTY à QWERTY en anglais. Les noms de contacts, SMS et publications des joueurs restent dans leur texte original. Les principaux statuts sont traduits ; un diagnostic technique inconnu reste affiché tel que reçu.

L’en-tête du téléphone affiche WindyPhone. Sur l’accueil, WindyPhone est suivi du numéro comme auparavant. LabRP reste le nom de la dépendance et des comptes bancaires du serveur. Les numéros, codes, contacts, photos et le lecteur vocal sont conservés. Protocole inchangé : 7.

Tests en jeu : ouvrir Réglages > Langue, passer en English, visiter les applications puis redémarrer pour vérifier la préférence. Retourner à Settings > Language > Français. Vérifier le nom WindyPhone en haut et la conservation des noms de contacts et messages. Rendu natif VR non testé dans cet environnement.

Contacts et photos 0.6.3

Contacts affiche maintenant un carnet clair avec recherche par nom ou numéro, tri alphabétique, miniatures et pagination. Une fiche contact propose trois boutons avec icônes : Appeler, SMS et Visio. Modifier le contact permet de changer son nom ; le numéro d’un contact enregistré reste fixe, il faut créer une nouvelle fiche pour un autre numéro. La suppression demande confirmation et conserve les conversations.

Pour ajouter une photo : Contacts > sélectionner un contact enregistré > Ajouter une photo > choisir une image dans la Galerie du téléphone. Attendre sa synchronisation serveur si elle vient d’être prise. Changer la photo et Retirer permettent de modifier ou supprimer l’association. L’image est cadrée au centre sans déformation et apparaît dans le carnet, la fiche, la composition SMS et l’écran d’appel entrant ou sortant. Elle ne remplace pas la vidéo pendant une visio active.

Les photos sont des associations privées dans ce carnet : elles ne changent pas le profil du correspondant ni les carnets des autres joueurs. L’hôte valide que la photo choisie appartient à ce téléphone et figure dans sa Galerie. Les associations sont sauvegardées ; si le téléphone est prêté et déverrouillé, son porteur voit les mêmes contacts et images. Une photo affectée reste accessible sur la fiche après retrait de la Galerie ; Retirer sur la fiche libère cette association.

La composition SMS dispose de cartes, d’un destinataire visible, d’un bouton écrire/modifier, d’un trombone pour joindre une photo et d’un bouton Envoyer. Les appels et le correctif audio 0.6.2 sont conservés. Installer cette version sur tous les PC ; codes, numéros et données restent conservés (protocole 7).

Tests en jeu : prendre une photo, attendre sa présence synchronisée en Galerie, l’affecter à un contact, appeler puis recevoir un appel de ce contact. Vérifier aussi après redémarrage, sur un téléphone prêté, après changement de nom, après retrait de Galerie et après suppression de l’association. Tester recherche, pagination, SMS avec texte et photo, visio et confirmation de suppression. Le rendu VR natif n’a pas été testé ici.

Correctif vocal 0.6.2

Le téléphone utilise maintenant son propre AudioClip Unity en streaming, avec un tampon PCM protégé entre le thread réseau et le thread audio. Il ne passe plus par la file AudioStreamFilter de Fusion, limitée à 8 192 échantillons. Les appels privés, haut-parleurs et lives Windy utilisent cette nouvelle lecture.

Le tampon garde une réserve initiale de 120 ms, en complément des 80 ms de remise en ordre réseau. La voix démarre progressivement sur 5 ms ; une sous-alimentation revient doucement au silence puis recharge la réserve. La latence accumulée est plafonnée à 500 ms pour éviter une conversation de plus en plus décalée. Le volume des contacts, le volume global et le codec Fusion sont conservés. La lecture coupe le son quand Fusion désactive l'écoute ; terminer un appel détruit le lecteur et vide son tampon.

Installer 0.6.2 sur l'hôte et tous les clients. Aucun nouveau PIN à créer si tu as déjà installé 0.6.1 : les codes quatre chiffres et les numéros existants restent identiques. Le protocole reste 7.

Tester un appel audio à deux, avec parole continue, parole simultanée et pauses de quelques secondes. Tester aussi haut-parleur et Windy. La réserve ajoute environ 200 ms avant lecture ; le but est d'absorber les arrivées irrégulières et d'éviter les claquements. La capture micro et le codec restent ceux de Fusion : un grésillement déjà présent dans la voix de proximité peut rester audible. Les tests natifs BONELAB ne peuvent pas être exécutés ici.

Correctifs 0.6.1

• PIN à quatre chiffres. Les anciens hash à six chiffres sont réinitialisés : seul le propriétaire peut créer le nouveau PIN à la prochaine prise. Un téléphone sans nouveau PIN reste inaccessible aux autres joueurs. La migration conserve un backup accounts.json.bak ; ne pas effacer UserData.
• Numéros aléatoires uniques, sauvegardés par joueur. L'hôte migre automatiquement la base existante.
• Écran calibré une seule fois après stabilisation du premier grab, puis placement et taille restaurés à chaque frame. Le passage entre les mains ne déclenche plus de recalibrage. Les réglages manuels de taille restent disponibles.
• Appels : nom du contact, numéro, avatar initiale, durée, commandes micro / haut-parleur / caméra, boutons répondre et raccrocher vert / rouge. La visio reste disponible.
• Audio privé, haut-parleur et lives : tampon de 80 ms, remise en ordre des paquets retardés, anti-rejeu sur 64 paquets et décodage G.711 Fusion sans amplification x10. Les échantillons PCM sont plafonnés à ±0,96. Le micro et les volumes des contacts restent ceux de Fusion. Le correctif vise les coupures réseau et la saturation ; la qualité audible dépend aussi du micro et doit être vérifiée à plusieurs en jeu.

Déverrouillage et prêt du téléphone

À la première prise de ton téléphone, créer un code PIN à quatre chiffres, puis le confirmer. Les zéros au début sont acceptés. Chaque reprise du téléphone demande son code. Réglages > Changer le code permet au propriétaire de modifier son code une fois déverrouillé ; Verrouiller ferme immédiatement l'accès.

Un autre joueur peut tenir ton téléphone : son écran local affiche le verrouillage. S'il connaît le code, il accède au compte de ce téléphone : contacts, SMS, Galerie, Banque et pseudo Windy. Ses actions utilisent ce compte, y compris les publications Windy et les virements. Les appels utilisent le numéro de ce téléphone et le micro du porteur. Un appel effectué depuis un téléphone prêté est interrompu quand ce porteur perd son accès.

L'hôte vérifie la main qui tient l'entité physique, le propriétaire, le code et le jeton d'accès. Lâcher le téléphone, changer de téléphone, quitter le lobby ou changer de map révoque l'accès. Une réponse réseau ancienne ne déverrouille pas une nouvelle prise du téléphone. Le code est sauvegardé sous forme de hash salé dans accounts.json ; il n'est pas envoyé dans les profils. Après cinq codes incorrects, trente secondes d'attente sont imposées.

Les réglages de sonnerie et de fluidité restent des préférences du PC utilisateur. Le verrouillage protège l'utilisation dans le jeu ; les données du serveur restent administrées par son hôte.

Banque

LabBank affiche une carte de compte courant, le solde, les opérations récentes et le formulaire de virement. Faire un virement > saisir le numéro et le montant > Continuer > Confirmer. Les fonds viennent de la banque LabRP de l'hôte. L'historique conserve les vingt derniers virements enregistrés à partir de cette version.

Un téléphone prêté débite le compte de son propriétaire. Un virement déjà réservé ne peut pas être exécuté deux fois en rejouant sa commande. Le destinataire doit être connecté. La transaction financière reste celle de LabRP ; la réservation anti-rejeu et l'historique sont conservés par le téléphone. Comme auparavant, il n'existe pas de transaction disque distribuée entre ces deux mods.

Photo et Galerie

Documents devient Galerie : les photos apparaissent en grille, neuf miniatures par page. Toucher une miniature l'agrandit ; Envoyer et Supprimer restent disponibles sur la vue détaillée. Les photos reçues par SMS et celles regardées dans Windy restent consultables dans leur application et dans le cache, sans être ajoutées à la Galerie.

Photo : tenir le téléphone déverrouillé, viser, puis appuyer sur B à droite ou Y à gauche sur les contrôleurs Quest. Le bouton secondaire de la main porteuse déclenche une seule prise. Le menu natif du rig est temporairement désactivé pendant l'utilisation de Photo, puis restauré à la sortie ou au lâcher.

Les captures sont des JPEG 640×480, limités à 64 Kio. L'aperçu garde ses réglages 15/30/45 images/s. Le bouton Caméra avant/arrière permet le selfie ou la prise vers l'extérieur.

Chaque nouvelle capture porte une marque de provenance locale et est inscrite dans la Galerie du compte utilisé. Elle est conservée localement dès la capture et synchronisée avec l'hôte. Une synchronisation interrompue reprend au prochain déverrouillage. Le compte de l'hôte conserve les références de Galerie pour les retrouver depuis le téléphone prêté. Les miniatures distantes se chargent progressivement. Limite de cent photos en Galerie ; supprimer une photo ne supprime pas les copies déjà publiées ou envoyées.

Anciennes photos : les versions précédentes stockaient les images reçues et les prises personnelles avec la même marque de propriétaire. Leur provenance ne peut pas être reconstituée de manière fiable. Les anciens JPEG restent dans le dossier photos, mais ils ne sont pas importés automatiquement dans le nouvel index de Galerie. Les prises effectuées à partir de la 0.6 sont identifiées correctement. Aucune ancienne image n'est effacée par la migration.

Conserver accounts.json et server-media chez l'hôte pour préserver Galerie et pièces jointes. Le cache local photos est limité à huit cents fichiers ; le stockage serveur à mille images, dont deux cents par compte. Les images serveur non référencées sont nettoyées après quinze minutes. Les copies envoyées et les posts Windy ont leurs propres références.

Windy

L'interface affiche un en-tête, le pseudo de l'auteur, son texte et la photo directement dans le fil. Aucun bouton Voir la photo n'est nécessaire pour l'afficher. Toucher l'image ouvre le détail. Plus récent / Plus ancien parcourt le fil, une publication par écran pour garder les images lisibles dans ce téléphone VR.

Le compte conserve un pseudo unique de trois à vingt lettres/chiffres/underscore, normalisé en minuscules. Publier accepte un texte de 280 caractères maximum et/ou une photo de la Galerie. Les trois cents dernières publications sont conservées sur cet hôte, dans windy.json. Le brouillon est effacé après confirmation de publication.

Lives Windy

1. Windy > Lives > Passer en live.
2. Choisir Caméra avant ou Caméra arrière avec l'aperçu.
3. Commencer le live : le micro Fusion et la caméra choisie sont diffusés aux spectateurs inscrits.
4. Les autres joueurs ouvrent Windy > Lives et sélectionnent le direct.
5. J’aime ajoute un like par spectateur. Commenter ouvre le clavier puis Envoyer le commentaire. Les commentaires apparaissent dans le direct.
6. L'auteur peut changer de caméra ou Terminer. Les spectateurs peuvent Quitter.

Les participants doivent déverrouiller leur téléphone. L'auteur garde son téléphone en main ; le lâcher arrête le live. Un spectateur qui lâche son téléphone est retiré. Déconnexion, changement de map ou perte de heartbeat termine les routes correspondantes. Un appel et un live ne se cumulent pas sur le même participant.

La caméra filme la scène BONELAB depuis le téléphone, pas une webcam réelle. La voix provient du micro Fusion : activer la voix Fusion avant de commencer. Le live utilise une source sonore locale pour les spectateurs et garde la voix de proximité de Fusion. Près du diffuseur, ces deux sources peuvent donc se cumuler.

L'hôte relaie uniquement aux participants du live. Quatre lives simultanés maximum, seize spectateurs par live. Images JPEG 320×240, cible jusqu'à 15 images/s, adaptée au nombre de spectateurs (au-delà de quatre, la cible diminue pour limiter le trafic). Le débit et les FPS réels dépendent du réseau, du PC et de la charge du serveur. Le live n'est pas enregistré et ses commentaires/likes ne sont pas conservés après sa fermeture.

Notifications intégrées

Les SMS, AirDrop et virements utilisent des bannières dans l'écran du téléphone et le centre Notifications de l'accueil. Le son des messages reste configurable. Les notifications du téléphone n'appellent plus le système de popups Fusion. La bannière ouvre l'application concernée ; le verrouillage masque le contenu privé. Les notifications restent liées au compte du téléphone concerné et ne sont pas transférées au téléphone suivant pris en main.

Tests en jeu à deux ou trois joueurs

1. Lancer Fusion : chaque téléphone apparaît. Vérifier le premier grab sans toucher aux réglages X/Y/rotation.
2. A crée son code, pose puis reprend son téléphone : il demande de nouveau le code. Redémarrer l'hôte et vérifier la conservation du code.
3. B prend le téléphone de A. Un code incorrect ne donne accès à rien ; le bon code affiche les contacts, SMS et le numéro de A. Relâcher puis reprendre : code demandé de nouveau.
4. Dans ce téléphone prêté, vérifier un post Windy et un virement : ils doivent utiliser le compte de A. B ne peut pas modifier le code de A. Rendre le téléphone et vérifier que celui de B montre bien le compte de B.
5. A prend deux photos, ouvre Galerie et voit directement les miniatures. Envoyer une photo à B : B peut la lire dans Messages mais elle ne doit pas apparaître dans sa Galerie.
6. Publier une photo sur Windy : B la voit directement dans le fil. Le simple visionnage ne l'ajoute pas à la Galerie.
7. Recevoir un SMS téléphone tenu : bannière sur le téléphone, aucune popup Fusion. Tester aussi la réception téléphone verrouillé.
8. A commence un live arrière ; B rejoint à distance. Vérifier vidéo et voix, ajouter un like et un commentaire. A passe en caméra avant : vérifier le changement côté B et le rendu de son avatar.
9. C regarde sans rejoindre : il ne doit pas recevoir le flux. B quitte : il ne doit plus entendre la voix distante du live. A lâche son téléphone : tous les spectateurs sont sortis.
10. Refaire client/client avec l'hôte observateur, puis déconnexion et changement de map. Vérifier aussi les appels et les pièces jointes existants.

Ces tests natifs restent à faire sur vos PC. Les contrôles locaux ne garantissent ni le rendu VR, ni les FPS, ni la réplication des mains par Fusion.

Vérifications locales

Le dossier tests contient un projet .NET 6 indépendant du jeu. Il teste les comptes, SMS, appels, médias, limites, Windy, PIN, baux d'accès, Galerie, lives, likes/commentaires et routes réseau. La compilation de contrôle utilise les DLL fournies, avec des déclarations temporaires pour les dépendances Unity/MelonLoader manquantes dans cet environnement. Ces déclarations et la DLL de contrôle ne sont pas livrées. Le projet à compiler sur ton PC reste en .NET 6 x64.

Tests ciblés 0.6.1 en jeu

Installer cette même version sur tous les PC. Au premier lancement de l’hôte, noter les nouveaux numéros et recréer un PIN de quatre chiffres. Vérifier contacts et conversations après migration puis après redémarrage. Passer le téléphone plusieurs fois d’une main à l’autre, le lâcher puis le reprendre, et vérifier la taille, l’orientation et le laser. Faire un appel audio de deux minutes, parler simultanément puis laisser un silence ; tester le micro coupé, le haut-parleur à deux mètres, la visio et le raccrochage. Répéter comme client et avec un téléphone prêté. Tester aussi un live Windy : son continu, départ et retour d’un spectateur.

Correction 0.8.9 : suppression complète du FreezeAll de parking. Suspension de gravité uniquement, restauration de sa valeur initiale au grab et au nettoyage, aucune annulation de vitesse au grab.

Banque et touche B/Y — 0.8.9

Le blocage/support B/Y pendant les lives est supprimé. Poser le téléphone laisse le live actif, mais B/Y ne le fige plus. B/Y déclenche toujours une photo dans l’application Photo. Le maintien initial au spawn reste inchangé.

L’application Banque dispose d’un code distinct de quatre chiffres. À la première ouverture, le propriétaire crée et confirme son code. Les codes sont conservés sous forme de hash salé dans la base du serveur. À chaque nouvelle entrée dans l’application, saisir le code bancaire. Quitter Banque, verrouiller ou changer de porteur révoque l’autorisation ; connaître le code du téléphone ne suffit pas pour faire un virement. Après cinq erreurs de code bancaire, attendre trente secondes. Le code peut être partagé en RP, mais seul le propriétaire peut le créer. La version actuelle ne propose pas de changement/récupération du code bancaire dans l’UI.

Installer 0.8.9 chez TOUS les joueurs (protocole 16), compiler Release/x64, remplacer la DLL et redémarrer. Conserver UserData pour préserver les numéros, contacts, photos et comptes existants.

Test à deux : créer le code, consulter les comptes, faire un virement ; quitter et rouvrir Banque ; tenter un mauvais code ; relâcher/changer de porteur et vérifier le nouveau verrouillage. Tester la reprise d’un live après pose du téléphone, B/Y pendant le live puis B/Y dans Photo.

Publication Thunderstore

manifest.json inclus : WindyPhone 0.8.9 avec BoneLib, Fusion et LabRP. Compiler Release/x64, ajouter icon.png (PNG 256 × 256) à côté du projet, puis exécuter : powershell -ExecutionPolicy Bypass -File .\Prepare-Thunderstore.ps1. Publier le ZIP WindyPhone-0.8.9-Thunderstore.zip généré, pas le ZIP des sources. Le script inclut uniquement manifest.json, README.md, icon.png et Mods/BonelabRP.Telephone.dll. Ne pas publier UserData ni les DLL des dépendances.