PropriétésJeu
Les logements des personnages lus en jeu, en lecture seule, sur leur fiche citoyen : adresse, rôle, co-habitants, entrée sur la carte. Scripts pris en charge.
Avec Propriétés des personnages, la fiche citoyen d’un personnage du jeu gagne un onglet Propriétés : ses logements tels que le jeu les connaît. Avant une perquisition, tu sais où il habite, s’il est propriétaire ou locataire, et qui vit avec lui.
Tout est en lecture seule : SuperMDT ne modifie jamais rien en jeu.
L’activer
Section intitulée « L’activer »- Vérifie que ton script de logement est dans le tableau de compatibilité.
- Dans Configuration › Jeu › Intégrations, active Propriétés des personnages (administrateurs, ou un grade qui a Administration déléguée › Régler le jeu). Désactivé par défaut.
- Sous l’interrupteur, SuperMDT affiche le script détecté.
game-integrationsCôté serveur : Config.Integrations.properties.enabled dans config.lua.
L’onglet Propriétés
Section intitulée « L’onglet Propriétés »citizen-propertiesPour chaque logement :
- l’adresse ou le nom du logement ;
- le type : Maison, Appartement ou Logement ;
- le rôle du personnage : Propriétaire, Locataire ou A les clés ;
- les co-habitants : un lien vers leur fiche quand SuperMDT les connaît, sinon « Un autre personnage » ;
- l’entrée sur la carte (Voir sur la carte, puis Masquer la carte), quand le script la donne ; sinon « Entrée inconnue ».
En haut, SuperMDT indique quand les propriétés ont été lues en jeu et par quel script. Un script Expérimental est signalé : vérifie les informations en jeu.
Au plus 20 logements par personnage et 8 co-habitants par logement.
Quand elles sont lues
Section intitulée « Quand elles sont lues »- à chaque connexion, reconnexion ou changement de personnage, sur tous les frameworks, sauf si le personnage a été lu il y a moins d’une minute ;
- puis toutes les 30 minutes pour les personnages connectés
(
Config.Integrations.properties.resyncMinutes).
La passerelle lit un personnage à la fois. Une liste inchangée n’est pas renvoyée.
Qui les voit
Section intitulée « Qui les voit »| Permission | Ce qu’elle permet | Par défaut |
|---|---|---|
| Propriétés › Voir les propriétés | L’onglet Propriétés des fiches venues du jeu | tous les grades, services police et justice seulement |
Elle se trouve sous le module Citoyens de la matrice des permissions, et n’y apparaît que si l’intégration au jeu est activée. Dans un service médical ou personnalisé, donne-la à la main si tu en as besoin.
Compatibilité
Section intitulée « Compatibilité »Testé en jeu essayé en jeu sur un vrai serveur. Vérifié sur le code écrit d’après le code source ou l’API native du script, couvert par les tests de la passerelle, pas encore essayé en jeu. Expérimental d’après la documentation publique de l’éditeur, jamais essayé : vérifie-le sur ton serveur avant de t’y fier.
| Script | État | Ce qui est lu |
|---|---|---|
| ps-housing | Vérifié sur le code | Table properties : propriétaire et has_access (a les clés). Les appartements n’ont pas de position d’entrée. |
| qbx_properties (Qbox) | Vérifié sur le code | Table properties : propriétaire, locataire (logement avec loyer), détenteurs de clés (keyholders), entrée. L’appartement de départ (prix nul, sans loyer) est un Appartement. |
| qb-houses | Vérifié sur le code | Tables player_houses et houselocations : propriétaire, détenteurs de clés, entrée. |
| esx_property (ESX Legacy) | Vérifié sur le code | Fichier properties.json de la ressource (lu par LoadResourceFile) : Owner, Keys, Entrance. |
| qs-housing (payant) | Expérimental | Mêmes tables que qb-houses. |
| loaf_housing | Expérimental | Tables loaf_properties et loaf_houses. |
| bcs_housing | Expérimental | Export GetOwnedHomeKeys. Une location est lue comme Locataire. |
| nolag_properties | Expérimental | Export GetAllProperties. Le rôle est déduit. |
Si plusieurs scripts sont démarrés, la passerelle prend le premier de cet ordre : ps-housing, qbx_properties ou qs-housing, bcs_housing, nolag_properties, loaf_housing, esx_property, qb-houses.
La lecture par oxmysql est en lecture seule : une requête bornée par personnage, jamais
d’écriture. Tu peux la couper avec Config.Integrations.properties.sql = false : seuls
restent alors les scripts à exports (bcs_housing, nolag_properties) et esx_property.
Ton script est personnalisé ?
Section intitulée « Ton script est personnalisé ? »| Ton script de logement… | Résultat |
|---|---|
| garde les tables ou le fichier d’origine d’un script du tableau | Lu. |
| range les logements dans ses propres tables, ou renomme les colonnes du propriétaire | Non lu. |
Réglages de la passerelle
Section intitulée « Réglages de la passerelle »Dans config.lua, Config.Integrations.properties :
| Réglage | Rôle | Défaut |
|---|---|---|
enabled |
L’intégration côté serveur de jeu (false : coupée, quoi que dise SuperMDT) | activé |
resyncMinutes |
Relecture des personnages connectés (0 : jamais) | 30 |
readIntervalMs |
Un personnage lu au plus toutes les… | 2 000 ms |
sql |
Lecture des tables par oxmysql | activée |
Dépannage
Section intitulée « Dépannage »| Ce que tu vois | Cause | Que faire |
|---|---|---|
| Pas d’onglet Propriétés | Intégration non activée, ou permission manquante | Configuration › Jeu › Intégrations ; Propriétés › Voir les propriétés. |
| « Pas encore lues en jeu » | Le personnage ne s’est pas connecté depuis l’activation | Elles arrivent à sa prochaine connexion. |
| « Aucun logement connu » alors qu’il en a un | Script non pris en charge ou personnalisé | supermdt status (ligne « Propriétés ») dit ce qui est utilisé. |
| « Entrée inconnue » | Le script ne donne pas de position (appartements de ps-housing) | Normal. |