NimBlock : composer un plugin Paper en briques, sans écrire de Java

[Mollenthiel]

Salut,

Je poste ici parce qu'une bonne partie des fils de cette section sont des « je cherche un plugin qui… » qui n'ont jamais de réponse, et que c'est exactement le problème sur lequel je travaille depuis quelques mois.

Ce que c'est. Une page web où tu composes un plugin Paper avec des briques : quand ceci arrive, si ces conditions tiennent, alors faire cela. Toute la grammaire tient dans cette phrase. Tu l'enregistres, tu l'installes sur ton serveur, et il tourne. Pas de Java, pas de compilation, pas de fichier à téléverser.

Ce qui est différent d'un générateur de code. Il n'y a pas de Java produit quelque part. Le serveur charge un moteur qui lit ta règle et l'exécute. La conséquence qui m'intéresse : quand Minecraft sort une nouvelle version, ce n'est pas ton plugin qui casse, c'est le moteur qui encaisse, une fois, pour tout le monde. Une règle écrite aujourd'hui tourne encore dans trois ans sans que tu y touches.

Ce que ça ne fait pas, parce que ça vaut mieux dit tout de suite : la grammaire est fermée. Ce qui est dans le catalogue est faisable, le reste est impossible, et ça restera impossible. Si ton besoin c'est un système de guildes avec sa base de données et ses interfaces, ce n'est pas l'outil. Si c'est « quand un joueur entre dans cette zone, s'il n'a pas la permission, le repousser et lui écrire un message », c'est fait en deux minutes.

Il y a aussi un serveur hébergé pour essayer, en Paper 26.1.2, avec la console en direct dans la page. C'est le moyen le plus rapide de voir la règle tourner sans rien installer, mais le studio marche aussi pour un serveur que tu héberges ailleurs.

Où j'en suis. C'est ouvert depuis une semaine et il n'y a encore personne dessus, donc autant le dire franchement : je cherche une dizaine de propriétaires de serveurs qui essaient pour de vrai et qui me disent ce qui casse. Il y a douze places sur la machine, c'est une contrainte technique et pas une opération commerciale. Gratuit, aucune carte bancaire, et il y a un bouton pour récupérer son monde en archive si tu veux partir.

NimBlock, crée ton serveur et tes plugins Minecraft

Crée un serveur Minecraft Paper hébergé et compose tes plugins en briques, sans écrire une ligne de code.

nimblock.com

Précision d'usage : c'est mon projet, je l'ai développé et je l'héberge. Je réponds ici à tout ce qu'on me demande, y compris technique (Paper 26 en conteneurs isolés, un réseau par serveur, sortie filtrée).

 

[ShE3py]

Bonjour,

Aurais-tu un document avec le langage sous la forme de Backus-Naur ou autre ?

Cordialement,
ShE3py

 

[Mollenthiel]

Salut, et bonne question : il n'y en avait pas, il y en a une maintenant.

https://nimblock.com/grammaire (et /en/grammar)

Tu y trouveras la forme EBNF complète, plus le catalogue déroulé : chaque déclencheur, condition et action, avec ses paramètres, leurs types et leurs bornes. Les deux fichiers qui font foi sont servis à côté, et le schéma répond enfin à l'adresse qu'il annonce dans son propre $id :

• https://nimblock.com/spec/plugin-1.schema.json : le JSON Schema (draft 2020-12), généré depuis le catalogue.
• https://nimblock.com/spec/catalogue-1.json : le catalogue, la source dont dérivent le validateur, le schéma, les briques de l'éditeur et le moteur Java.

La charpente, pour te donner la forme sans cliquer :

<plugin>    ::= "{" "specVersion" ":" 1 ","
                    [ "id" ":" <slug64> "," ]
                    "name" ":" <label> ","
                    [ "description" ":" <text500> "," ]
                    "rules" ":" "[" <rule> { "," <rule> } "]" "}"     (* 1..200 *)

<rule>      ::= "{" [ "id" ":" <slug32> "," ]
                    "name" ":" <label> ","
                    [ "enabled" ":" <boolean> "," ]                   (* = true  *)
                    [ "match" ":" ( "all" | "any" ) "," ]             (* = "all" *)
                    "trigger" ":" <trigger> ","
                    [ "conditions" ":" "[" [ <condition>
                          { "," <condition> } ] "]" "," ]             (* 0..20 *)
                    "actions" ":" "[" <action>
                          { "," <action> } "]" "}"                    (* 1..50 *)

<trigger>   ::= "{" "type" ":" <trigger-id>   [ "," "params" ":" <params> ] "}"
<condition> ::= "{" "type" ":" <condition-id> [ "," "not" ":" <boolean> ]
                                              [ "," "params" ":" <params> ] "}"
<action>    ::= "{" "type" ":" <action-id>    [ "," "params" ":" <params> ] "}"

<template>  ::= { <literal> | <variable> | <colour> }                 (* 0..2000 *)
<literal>   ::= /[^{}]/ | "{{" | "}}"
<variable>  ::= "{" /[a-zA-Z][a-zA-Z0-9_]*/ "}"
<colour>    ::= "&" ( "0".."9" | "a".."f" | "k".."o" | "r" )

<trigger-id>, <condition-id> et <action-id> sont des listes fermées de terminaux (9 déclencheurs, 8 conditions, 14 actions aujourd'hui). Elles sont énumérées sur la page, et engendrées depuis le catalogue plutôt que recopiées : elles ne peuvent pas s'écarter de ce que le moteur sait exécuter.

Deux choses ne rentrent pas dans les règles de production, et sont donc à la charge du validateur :

1. Le contexte. Chaque déclencheur déclare les variables qu'il pose ({player}, {block}, {x}…), et une condition ou une action qui exige un joueur ne s'écrit que sous un déclencheur qui en pose un : « soigner le joueur » sous « toutes les N secondes » est refusé à l'écriture. Un {joueur} mal orthographié l'est aussi, plutôt que de partir tel quel dans le chat.
2. L'annulation. cancel_event n'est admis que sous un déclencheur annulable.

Et une limite assumée pendant qu'on y est : les conditions ne s'imbriquent pas. Pas d'arbre booléen, seulement all / any et un not par condition. Ça se dessine mal en briques et ça couvre presque tout, mais c'est bien une limite de la version 1, pas un oubli.

Merci pour la question : elle a produit la page qui manquait.