Une intégration réelle

Voici une intégration réelle, pas un exemple de démonstration. Un plugin d’événements de faction branche SomaHider sur deux événements, un KoTH et un totem géant. Le schéma est le même à chaque fois : la zone s’ouvre autour de l’arène au démarrage de l’événement, révèle quelques groupes, puis se ferme à l’arrêt.

Les deux événements passent par un petit helper, pour que le branchement à l’API tienne à un seul endroit. Il récupère l’API, associe chaque joueur à sa faction, applique le déguisement lu dans la config, puis ouvre la zone.

public static HiderZone open(ConfigurationSection hider, Region region, VisibilityRule... reveal) {
    SomaHider somaHider = SomaHiderProvider.getOrNull();
    if (somaHider == null || region == null) {
        return null;
    }
    if (hider != null && !hider.getBoolean("enabled", true)) {
        return null;
    }
    return somaHider.hide(region)
            .groupResolver(Hiders::factionId)   // chaque joueur -> l'id de sa faction
            .disguise(hider)
            .reveal(reveal)
            .open();
}

public static String factionId(Player player) {
    Faction faction = FactionUtils.getFactionByPlayer(player);
    return faction != null && faction.isNormal() ? faction.getId() : null;
}

getOrNull() et le test qui suit laissent le plugin fonctionner même si SomaHider n’est pas installé, ce qu’implique un softdepend. Le resolver renvoie null pour un joueur sans faction, et un groupe null n’est jamais révélé.

Passer directement la section de config à disguise(...) signifie que les administrateurs règlent l’apparence du déguisement dans le fichier de l’événement, avec les mêmes clés que dans config.yml, sans que le plugin ait une ligne à écrire pour ça.

Au démarrage, une zone couvre l’arène. Tout le monde est masqué, sauf votre propre faction et celle qui tient le KoTH à cet instant. Le propriétaire est lu en direct, la révélation suit donc la capture.

// au démarrage de l'événement
ConfigurationSection hider = getConfig().getConfigurationSection("koths." + koth.getName() + ".hider");

zone = Hiders.open(hider, Hiders.around(koth.getArea().getMiddle(), hider),
        Reveal.sameGroup()
            .or(Reveal.group(() -> Hiders.factionId(currentKoth.getOwner()))));

// à l'arrêt
zone.close();

sameGroup() garde les coéquipiers reconnaissables entre eux. Reveal.group(Supplier) révèle la faction propriétaire à tout le monde, et comme il prend un Supplier plutôt qu’un identifiant figé, la révélation se déplace vers le nouveau propriétaire dès que le point change de mains. Aucun code ne tourne au moment de la capture. Tant que personne ne tient le point, le supplier renvoie null et seuls les coéquipiers se voient.

Même forme, autre règle. Autour du totem, on révèle sa propre faction et les trois premières factions du classement. Quand le classement bouge, l’ensemble révélé suit.

ConfigurationSection hider = getConfig().getConfigurationSection("giant-totems." + totem.getName() + ".hider");

zone = Hiders.open(hider, Hiders.around(totem.getLocation(), hider),
        Reveal.sameGroup()
            .or(Reveal.groupsTogether(() -> Hiders.top(standings, 3))));

public static List<String> top(List<EventData> standings, int count) {
    List<String> ids = new ArrayList<>();
    for (int i = 0; i < standings.size() && i < count; i++) {
        ids.add(standings.get(i).getId());
    }
    return ids;
}

groupsTogether(Supplier) révèle entre eux les membres d’un ensemble de groupes : l’observateur et la cible doivent tous deux en faire partie. Ici l’ensemble est celui des factions de tête, recalculé au fil de l’événement, si bien que le classement s’ouvre à mesure qu’il évolue.

Une règle est évaluée pour chaque couple observateur / cible, plusieurs fois par seconde. Sur une zone chargée, lire le classement à cet endroit reviendrait à le payer des milliers de fois.

Les fabriques à base de supplier évitent ça : SomaHider appelle le supplier au plus une fois par passe et transmet le résultat à tous les couples de cette passe. Construisez donc la lambda une seule fois, à l’ouverture de la zone, comme dans les exemples ci-dessus. En créer une nouvelle à chaque appel annulerait la mise en cache, qui repose sur l’identité de l’instance.

• Un seul helper centralise l’accès à l’API, le resolver de groupe et le déguisement.
• La zone s’ouvre au démarrage et se ferme à l’arrêt avec zone.close().
• Les règles à base de Supplier suivent l’état du jeu, sans logique supplémentaire.

Le catalogue complet des fabriques est dans règles de révélation.