Roblox – Implémentation d’un Friend Panel sécurisé (toggle accès amis)

L'attendu

Tu devras n’autoriser le toggle qu’au propriétaire du plot.

Tu devras stocker un booléen FriendsAllowed par plot (synchro répliquée).

Tu devras, quand FriendsAllowed == true et que le plot est “bloqué” (ex. BlockEndTime actif), autoriser le passage uniquement aux amis du propriétaire.

Tu devras empêcher le passage des non-amis tant que le plot est bloqué.

Tu devras, quand le plot est non bloqué, désactiver l’effet du Friend Panel (collisions ouvertes).

Tu devras mettre à jour l’UI du panneau (texte + icône) en temps réel lors du toggle et lors des changements d’état serveur.

UX / UI (client)

Tu devras afficher un ProximityPrompt sur PlotModel.FriendPanel.Main.ProximityPrompt.

Tu devras changer dynamiquement le ObjectText :

Allow Friends si l’accès amis est désactivé,

Disallow Friends si l’accès amis est activé.

Tu devras commuter l’icône sur PlotModel.FriendPanel.Main.SurfaceGui.ImageLabel.Image (deux IDs d’assets, “On/Off”).

Tu devras masquer/ignorer l’interaction si le joueur n’est pas le propriétaire.

Règles de sécurité (anti-abus)

Tu devras vérifier côté serveur que :

le joueur qui déclenche le toggle est bien plot:GetAttribute("Owner").

le RemoteEvent ne prend pas de paramètres “libres” modifiables par le client (ou les revalider).

Tu devras ajouter un debounce serveur (par ex. 0.5–1s) pour éviter le spam.

Tu devras journaliser (print/log structuré) les toggles (qui/quoi/quand), utile pour debug.

Collisions / accès (LaserHitbox)

Tu devras recalculer les collisions des parties de PlotModel.LaserHitbox à chaque changement :

Owner présent → collisions désactivées pour l’owner (ou globalement ouvertes si tel est le design actuel).

BlockEndTime actif + FriendsAllowed == true → collisions désactivées pour les amis du propriétaire, activées pour les autres.

BlockEndTime inactif → collisions désactivées (libre accès).

Tu devras aussi réappliquer cet état lors d’événements système : owner change, FriendsAllowed change, BlockEndTime change, liste d’amis change, tier change.

Architecture & intégrations

Tu devras réutiliser le RemoteEvent PlotService/ToggleFriends (ou le créer s’il manque).

Tu devras écouter côté client :

Channel:OnChanged("FriendsAllowed", ...) → maj UI + UpdateBlocked.

Éventuellement Friends.OnFriendsUpdate → re-UpdateBlocked.

Tu devras écouter côté serveur :

l’appel ToggleFriends:FireServer() → valider propriétaire, inverser FriendsAllowed, répliquer via Channel/Synchronizer.

Tu devras respecter les modules existants : Synchronizer, Friends, Trove, Timer, etc.

Tu devras faire en sorte que le code soit idempotent (pas de multiples connexions fantômes après re-setup).

Persistance

Tu devras persister FriendsAllowed avec les autres propriétés du plot (le même flux de sauvegarde déjà utilisé pour Owner/BlockEndTime, si applicable).

Tu devras restaurer l’état à la reconnexion et au changement d’owner (réinit par défaut à false si pas de data).

Performances & robustesse

Tu devras éviter les boucles coûteuses : utilise les OnChanged ciblés et un Timer léger (1s) si déjà en place.

Tu devras prévoir des garde-fous si FriendPanel ou LaserHitbox est absent (warnings non-bloquants).

Tu devras nettoyer proprement toutes les connexions (Trove) au Destroy/re-setup.

Tests d’acceptation (tu devras vérifier)

Owner toggle : le propriétaire peut passer de OFF→ON et ON→OFF ; l’UI change ; les collisions se mettent à jour.

Non-owner : l’interaction n’a aucun effet (server refuse, rien ne change).

Ami autorisé : avec BlockEndTime actif + FriendsAllowed == true, un ami peut traverser la LaserHitbox ; un non-ami est bloqué.

Plot non bloqué : peu importe FriendsAllowed, la LaserHitbox ne bloque pas.

Changement d’amis : quand la liste d’amis change en cours de partie, l’accès se met à jour sans respawn.

Reconnexion : après restart du serveur et reconnexion du joueur, l’état FriendsAllowed est restauré.

Spam : spam client sur le RemoteEvent ne casse rien (debounce + vérif owner).

Fallback : si FriendPanel ou LaserHitbox manque, le jeu ne plante pas (log d’avertissement).

Livrables

Tu devras livrer :

Le script client modifié (PlotClient) avec :

gestion UI Friend Panel, écoute FriendsAllowed, appel ToggleFriends, UpdateBlocked robuste.

Le script serveur complémentaire (ex. PlotHandler/LockService/PlotService) avec :

RemoteEvent PlotService/ToggleFriends (validation owner, flip + réplication).

Persistance (si datastore du plot existe déjà).

Une note technique (README) expliquant où le code a été ajouté, la logique, et comment tester.

Des IDs d’images Roblox proposés pour les états ON/OFF (ou placeholders).

Des logs de debug activables/désactivables facilement.

Accès & collaboration (Roblox Studio)

Tu devras travailler directement dans le projet : tu seras invité sur le serveur Roblox Studio (Team Create) afin de modifier toi-même les scripts (PlotClient, PlotHandler, services/Modules).

Tu devras accepter l’invitation (Universe/Place) et rejoindre la session Team Create.

Prérequis : compte Roblox actif, 2FA recommandé, Roblox Studio à jour.

Tu auras les droits d’édition nécessaires (Edit/Play Test). Les publications seront faites selon le flux convenu (draft → review → publish).

Tu devras committer tes changements proprement :

Nommer clairement les scripts modifiés, commenter les parties sensibles (RemoteEvents, vérifs serveur, collisions).

Garder le style existant (Trove/Timer/Synchronizer).

Activer les logs de debug uniquement en dev.

Tu devras tester en Play Solo/Start Server dans Team Create (amis/non-amis, toggle on/off, BlockEndTime on/off) avant demande de review.

Si un dépôt externe existe (Git), on te donnera l’accès en miroir ; la source de vérité reste le projet Team Create.