r_communityservice de rumaier est la ressource de l’aperçu original ci-dessous. Le code 3.3.0 examiné assigne un nombre de tâches dans une zone configurée. Il n’étaye pas les anciennes durées fixes, cinq métiers, gilets orange ou pénalité de déconnexion de 25 %.
Dépôt original et source actuelle
Installer les dépendances et régler les accès
Le manifeste exige ox_lib et r_bridge. Vérifiez que votre bridge couvre framework, inventaire et interface de progression, puis démarrez les dépendances avant r_communityservice. La commande par défaut est /communityservice. Cfg.AllowedJobs contient police ; le personnel utilise la permission ACE r_communityservice. Limitez-la au groupe voulu et testez le refus d’un joueur ordinaire.
Configurer des tâches plutôt que des minutes
Cfg.MaxTasks vaut 60 et Cfg.TaskTime 10 secondes par tâche par défaut. Position et rayon sont configurables. Déplacements, échecs et interruptions empêchent d’en déduire une durée exacte. Le serveur contrôle affectation, lieu, temps écoulé et accès, avec limites de requêtes. Ces contrôles ont été lus dans le code, pas certifiés en jeu.
Protéger objets saisis et affectations
Le script stocke affectations et inventaire saisi dans core/server/tasks.json par identifiant joueur. Il tente la restitution à la libération et gère manque de place ou échec de sauvegarde. Copiez ce fichier avant remplacement de la ressource sans écraser les affectations actives par une copie vide. Ce stockage est JSON ; le framework peut toujours dépendre d’une base.
Sur une instance séparée, testez quantités et métadonnées à l’affectation, reconnexion, redémarrage, fin normale et retrait par le personnel. Incluez inventaire plein et écriture refusée, sans perte ni duplication. Vérifiez qui peut assigner ou retirer les tâches d’autrui. La revue utilise le commit 9a95c65 ; ce n’est pas un audit complet ni un test en jeu.