Runtimes hybrides

Cette page explique ce qui change, et comment préparer un serveur hybride pour obtenir des résultats fiables. Pour les autres types de serveurs, voir Compatibilité.

Runtimes reconnus

VoxelBench reconnaît Mohist, Arclight, Banner, NeoTenet, Magma, CatServer et Cardboard. Il les identifie aux classes que fournit le serveur (et, en dernier recours, à sa chaîne de version), avant de chercher Paper ou Spigot : un hybride se présente souvent comme Paper ou Spigot, et serait sinon déclaré comme tel.

Reconnu ne veut pas dire testé : la section Intégration continue indique les runtimes réellement démarrés avec VoxelBench.

Un serveur Bukkit sur mod loader absent de cette liste est déclaré comme le serveur qu'il prétend être (le plus souvent Paper ou Spigot), et rien de ce qui suit ne s'applique à lui. Ses mods figurent tout de même dans les rapports (voir Les mods dans les rapports).

Au démarrage

VoxelBench écrit dans les logs le runtime détecté au démarrage. Sur un hybride reconnu, une seconde ligne suit :

[VoxelBench] Runtime: Mohist (MC 1.20.1-R0.1-SNAPSHOT)
[VoxelBench]   ⚠ Hybrid runtime detected — Bukkit-on-mod-loader. Most tests work but Paper-only optimisations are skipped and modded BlockData may interact unpredictably with block-placing tests.

La version entre parenthèses est la version Bukkit annoncée par le serveur. Si cette ligne indique Paper ou Spigot sur votre hybride, le runtime n'a pas été reconnu.

Le bloc VoxelBench Server Compatibility, écrit lui aussi au démarrage, donne le même type de serveur et liste les API disponibles (TPS et MSPT natifs, tickets de chunk, chunks chargés de force). /bench info server affiche le type sur sa ligne Type.

Ce qui change

Mondes de benchmark

Sur un hybride Forge ou NeoForge, demander un monde plat au serveur peut donner un terrain normal, parce que le mod loader prend la main sur la génération du monde. Sur un hybride reconnu, VoxelBench génère donc lui-même chaque monde qu'il crée, avec /bench world create ou comme monde temporaire d'un run : de la bedrock, deux couches de terre et une couche d'herbe (les couches du superflat classique), sans structures. Les autres serveurs utilisent le générateur plat vanilla, avec les mêmes couches.

Le serveur peut malgré tout déclarer ce monde NORMAL. VoxelBench reconnaît son propre générateur : ni /bench start ni ses vérifications préalables n'avertissent donc que le monde n'est pas plat. Chaque création est journalisée avec ce que le serveur a réellement appliqué :

[VoxelBench] Bench world 'voxelbench_bench' created — type=NORMAL (asked FLAT), seed=… (asked …), generator=FlatChunkGenerator.

Si le serveur rend un monde sans point d'apparition, ou dont le chunk d'apparition ne se charge pas, VoxelBench le supprime au lieu d'y tourner. /bench world create indique alors qu'il n'a pas pu créer le monde. Un run complet qui avait besoin d'un monde temporaire (/bench start, /bench stresslimit, un profil personnalisé) se rabat sur le monde principal du serveur, et la console affiche falling back to default world. Un /bench test qui écrit dans le monde est refusé à la place (voir Benchmarks). Épingler un monde évite l'un comme l'autre (voir Configuration recommandée).

Fonctions de Paper et de Folia

VoxelBench ne suppose jamais qu'un hybride est un Paper. Chaque fonction qui repose sur Paper (dialogues natifs, événement de tick qui sert à mesurer la durée des ticks, chargement de chunks et téléportations asynchrones, TPS et MSPT de Paper) est cherchée séparément et n'est utilisée que si le serveur la fournit. Sinon, VoxelBench fait comme sous Spigot, par exemple en mesurant lui-même le TPS et le MSPT. C'est ce que le message de démarrage appelle ignorer les optimisations propres à Paper. Le code Folia n'est jamais utilisé sur un hybride : les tests sont ordonnancés sur le thread principal, comme sous Spigot et Paper.

Méthodes absentes du serveur

Si un test appelle une méthode que l'hybride n'implémente pas, ce test seul échoue, avec une erreur qui commence par HybridCompat: (par exemple HybridCompat: NoSuchMethodError: …). La console affiche Runtime API mismatch in <test> (likely a hybrid-server compatibility issue), et le reste du run continue.

Les mods dans les rapports

Chaque rapport indique si le serveur est un hybride reconnu, quel mod loader VoxelBench a trouvé (forge, neoforge, fabric, ou none) et combien de mods sont chargés. La liste des mods (identifiant, nom et version) est jointe elle aussi, sauf avec l'anonymisation FULL (voir Confidentialité).

Dans l'interface, Informations Serveur → Serveur Minecraft → Mods affiche le loader et liste les mods.

Ce qui ne change pas

Les commandes, les permissions, config.yml, le catalogue des tests, les profils personnalisés et l'API d'extension fonctionnent comme sur n'importe quel serveur. Les rapports gardent le même format, avec les champs ci-dessus en plus, et partent sur voxelbench.com comme d'habitude.

Configuration recommandée

1. Vérifiez la détection. La ligne Runtime: doit nommer votre hybride.
2. Créez un monde de benchmark et épinglez-le :

   /bench world create bench
   /bench world set voxelbench_bench
   

   Les tests construisent alors leurs zones sur le terrain plat de VoxelBench, loin du terrain et des structures moddés, et les runs ne dépendent plus de l'hybride pour accepter un nouveau monde temporaire à chaque fois. Voir Mondes de benchmark. /bench world set enregistre l'épinglage dans config.yml :

   benchmark:
     target-world: "voxelbench_bench"
     auto-temp-world: true
   

3. Laissez auto-temp-world activé (c'est le défaut). Il ne s'applique que si aucun monde n'est épinglé, ou si le monde épinglé n'est pas chargé. Désactivé, ces runs partent dans le monde principal à la place (voir Configuration).
4. Les redémarrages sont pris en charge. Au démarrage, VoxelBench recharge chaque monde voxelbench_<nom> présent sur le disque mais non chargé, avec le même générateur : l'épinglage survit donc à un redémarrage, même sans gestionnaire de mondes. C'est vrai sur tous les types de serveurs. Les logs les listent (Auto-loaded 1 persistent benchmark world(s) from disk:), avec un ! et la raison pour ceux qui n'ont pas pu être chargés.
5. Comparez ce qui est comparable. Les mods ajoutent leur propre travail : comparez les résultats d'un hybride à des runs sur le même runtime, avec les mêmes mods.

Si un monde de benchmark n'a pas pu être rechargé, son dossier reste sur le disque et /bench world create refuse de réutiliser ce nom, car les anciens chunks se mélangeraient au nouveau terrain. /bench world delete ne supprime qu'un monde chargé : choisissez un autre nom, ou arrêtez le serveur et supprimez le dossier.

Limites connues

• Contenu moddé. Les mods qui modifient la génération du monde, les dimensions, la pose de blocs ou les entités peuvent perturber les tests qui posent des blocs ou font apparaître des entités. Un monde VoxelBench épinglé tient le terrain moddé à l'écart des zones de test, pas les mods qui agissent sur tous les mondes ou toutes les entités.
• Couverture. Les hybrides ne sont que démarrés en CI, jamais benchmarkés, et leur comportement varie d'un build à l'autre. Si un test échoue avec HybridCompat:, signalez-le avec le runtime et sa version.
• Déchargement des mondes. Certains hybrides refusent de décharger un monde. Un monde temporaire (voxelbench_temp_<horodatage>) qui n'a pas pu être supprimé à la fin d'un run l'est au démarrage suivant du serveur.
• spark installé comme mod. L'intégration Spark peut l'utiliser si l'API de spark est accessible aux plugins. Le récapitulatif du démarrage indique alors ce qu'elle a trouvé : Spark hooked (forge-mod), neoforge-mod ou fabric-mod.

Intégration continue

Le workflow runtime-compat démarre des serveurs hybrides avec un build de développement de VoxelBench chaque jour, et à chaque modification du code du plugin :

Chaque job démarre le serveur, vérifie que VoxelBench est activé, lance bench info et bench tests list depuis la console, et échoue sur une erreur d'édition de liens dans VoxelBench (NoSuchMethodError, NoClassDefFoundError, LinkageError) ou une erreur à son activation. Que la ligne Runtime: nomme bien l'hybride attendu ne donne lieu qu'à un avertissement. Aucun test ni benchmark n'est lancé.

Ces jobs ne bloquent rien : un échec apparaît dans le résumé de l'exécution mais laisse le workflow au vert, et un serveur impossible à télécharger, ou qui plante pendant son propre démarrage, est ignoré. Les autres runtimes reconnus (Banner, NeoTenet, Magma, CatServer, Cardboard) et les autres versions ne sont pas démarrés en CI.