Player Event States

Player Event States — 1.0.0

Conservez des états booléens par joueur ou pour tout le serveur, puis lisez-les depuis un plugin de gameplay. Player Event States est obligatoire pour Dialogs, mais ne crée lui-même ni conversations, ni quêtes, ni récompenses, ni événements mondiaux.

Aucun réglage utilisateur

Ce plugin n’a pas de fichier de réglages ni de configurateur. Dialogs gère les états par son API ; un autre plugin peut faire de même. Les fichiers sous oxide/data/PlayerEventStates/ contiennent la progression en cours, pas des réglages réutilisables. Ne les remplacez pas par des exemples.

API

bool GetEventStatePlayer_API(ulong playerId, string eventName);
bool GetEventStateGlobal_API(string eventName);
void SetEventStatePlayer_API(ulong playerId, string eventName, bool value);
void SetEventStateGlobal_API(string eventName, bool value);
bool PlayerHasRecquiredStates_API(ulong playerId, Dictionary<string, bool> states);

Conservez l’orthographe publiée PlayerHasRecquiredStates_API. Employez une clé stable préfixée, comme quests.intro.complete, avec la même portée chez producteur et consommateur. Une lecture joueur retourne false pour une clé absente ; Set joueur la crée si nécessaire. Get global crée une clé globale absente à false ; Set global refuse une clé absente, donc initialisez-la avec Get.

Écrivez l’état après acceptation effective d’une action. Lisez les états requis avant d’autoriser une action conditionnelle. Ne supposez ni expiration, ni reset au wipe, ni migration automatique : cette version ne définit pas ces politiques. Aucune commande publique joueur ni permission n’est documentée.

Exemple dans un plugin consommateur

Il s’agit de C# pour un plugin Rust existant, pas d’une commande console serveur. Ajoutez using Oxide.Core.Plugins; en haut de son fichier, puis ces membres dans sa classe RustPlugin. Installez d’abord PlayerEventStates.cs dans oxide/plugins.

[PluginReference] private Plugin PlayerEventStates;

private bool HasCompletedIntro(BasePlayer player)
{
    if (PlayerEventStates == null)
        throw new System.InvalidOperationException("PlayerEventStates is not loaded.");

    return PlayerEventStates.Call<bool>(
        "GetEventStatePlayer_API", player.userID, "quests.intro.complete");
}

private void StartFestival()
{
    if (PlayerEventStates == null)
        throw new System.InvalidOperationException("PlayerEventStates is not loaded.");

    PlayerEventStates.Call("GetEventStateGlobal_API", "events.festival.active");
    PlayerEventStates.Call("SetEventStateGlobal_API", "events.festival.active", true);
}

Appelez HasCompletedIntro avant d’autoriser une action conditionnelle. Après réussite de l’action qui termine l’introduction, enregistrez-la avec PlayerEventStates.Call("SetEventStatePlayer_API", player.userID, "quests.intro.complete", true). Appelez StartFestival seulement lorsque votre logique de jeu démarre cet événement : la lecture initialise la clé globale avant son écriture. L’exemple refuse explicitement une dépendance absente, au lieu de la traiter comme un état normalement faux.

Persistance et vérification

L’état global est dans global_events.json ; chaque joueur est dans user_<steamid>.json sous le dossier data du plugin. Les changements sont marqués pour sauvegarde lors de la sauvegarde serveur et de l’unload ; un appel API n’est pas une écriture immédiate sur disque. Sauvegardez le dossier entier et ne remplacez pas des états en service par des exemples.

Avant utilisation réelle, testez les valeurs false/true, l’isolation entre deux joueurs, l’initialisation globale et le comportement de votre plugin consommateur sur un serveur privé. Vérifiez la persistance après rechargement ou redémarrage propre.