CannonRTP (WorldCannon)

CannonRTP est un plugin de téléportation aléatoire multi-canons pour les serveurs Minecraft. « WorldCannon » est un ancien nom / nom de section du wiki ; le plugin s'enregistre sous le nom CannonRTP dans Bukkit, est distribué sous le nom CannonRTP.jar, et c'est ce nom que les joueurs et les administrateurs voient.

Détails de nommage importants :

• Nom du plugin : CannonRTP
• Commande racine : /cannonrtp
• Alias : /crtp, /wc
• Permissions : cannonrtp.admin, cannonrtp.use
• Dossier de configuration : plugins/CannonRTP/

Ce qu'il fait

CannonRTP est un système d'atterrissage aléatoire multi-canons plutôt qu'un unique lanceur fixe. Chaque canon configuré peut être placé à un ou plusieurs emplacements dans le monde, et chaque placement surveille les joueurs entrant dans son rayon de déclenchement.

Chaque canon peut :

• être placé plusieurs fois via /wc create et /wc place -- une seule configuration de canon pilote tous les placements
• surveiller les joueurs entrant dans un rayon de déclenchement propre au canon (1,75 bloc par défaut)
• précharger et maintenir une file d'emplacements d'atterrissage sûrs dans un monde cible configuré (le ciblage inter-mondes est pris en charge)
• rejeter le terrain dangereux, les espaces obstrués, les terrains protégés et les emplacements hors des limites du monde
• exiger optionnellement une permission supplémentaire propre au canon
• propulser les joueurs à travers une séquence cinématique en cinq phases
• afficher un canon 3D animé via FreeMinecraftModels (customModel propre au canon ou via une liste de priorité globale) ; à défaut, des particules orbitales aux couleurs changeantes sont utilisées si FMM n'est pas installé
• afficher une étiquette de statut flottante en panneau d'affichage au-dessus du canon (Ready / Charging / Maintaining / Exhausted / Disabled)

Déroulement du lancement

Générez ou explorez la zone de recherche configurée du monde cible avant d'utiliser le canon. CannonRTP charge les chunks existants sans générer de terrain ; un rayon inexploré peut donc ne fournir aucune destination.

La séquence de lancement est pilotée par une machine à états en cinq phases (SEARCHING -> FIRING -> TELEPORTING -> DROPPING -> LANDING). Lorsqu'un joueur entre dans le rayon de déclenchement d'un canon éligible :

1. CannonRTP vérifie cannonrtp.use.
2. Il vérifie le requiredPermission optionnel du canon.
3. Il vérifie le délai de récupération de lancement propre au joueur (runtime.launchCooldownSeconds, 30 secondes par défaut). Ce verrou s'applique à tous les canons et ne consomme aucune destination en file.
4. Il vérifie que le canon dispose d'au moins un emplacement d'atterrissage préchargé dans la file. (Les canons désactivés, ceux situés dans un monde non chargé et ceux situés dans un chunk non chargé n'atteignent jamais cette étape -- ils sont entièrement exclus de la boucle de tick et ne peuvent donc pas être déclenchés du tout.)
5. Il consomme un emplacement d'atterrissage sûr préchargé dans la file de ce canon.
6. Il déclenche l'événement CannonRTPLaunchEvent (annulable). Si un listener l'annule, la destination est remise dans la file et aucun délai de récupération ne démarre.
7. Phase Searching (42 ticks par défaut, configurable via launchWarmupTicks) : le joueur reçoit Lévitation, le canon joue son animation fire si un modèle personnalisé est actif, et des aperçus de coordonnées aléatoires défilent dans le titre/sous-titre. Tant qu'un modèle est actif, le joueur reçoit également Invisibilité pour que l'animation soit lisible.
8. Phase Firing (45 ticks par défaut via verticalBoostTicks) : Lévitation/Invisibilité sont retirées, le son de décollage est joué, une explosion de flammes+fumée+explosion apparaît, et verticalBoostVelocity est appliqué à chaque tick. Les véritables coordonnées de destination sont révélées.
9. Phase Teleporting (un seul tick) : la destination en file est revalidée (colonne de terrain, intégrations de protection, listeners de l'API). Si elle passe toujours, le joueur est téléporté exactement 50 blocs au-dessus d'elle et Chute Lente est appliquée. La hauteur du largage n'est jamais bornée -- le validateur d'atterrissage garantit déjà que le bloc d'arrivée se situe sous la hauteur maximale du monde, et une destination qui ne se valide plus annule le lancement et récupère le joueur à la place.
10. Phase Dropping : le joueur descend doucement avec une traînée de fumée (LARGE_SMOKE + CAMPFIRE_SIGNAL_SMOKE).
11. Phase Landing : entamée dès que le joueur touche le sol. Chute Lente est retirée, une explosion d'impact se déclenche (onde de choc nuageuse, anneau de flammes, transition de poussière) et CannonRTPLandingEvent est déclenché. Si la chute dépasse au contraire sa durée maximale (slowFallingSeconds x 20 ticks), CannonRTP récupère le joueur et aucun événement d'atterrissage n'est émis.

Règles de sécurité d'atterrissage

Avant qu'un emplacement ne soit accepté dans la file de préchargement, le code actuel vérifie, dans l'ordre :

• que le monde cible est chargé (tant qu'il ne l'est pas, le canon arrête de précharger et signale Target world <name> is not loaded.)
• que le centre de recherche se résout -- le searchCenter configuré, sinon la position du canon lui-même lorsqu'il se trouve dans le monde cible, sinon le point d'apparition du monde cible
• que le candidat est dans les limites du monde
• que le chunk candidat est chargé (chargé à la demande sans génération)
• qu'un bloc non-air le plus haut existe dans la colonne candidate
• que le bloc de surface directement sous le point d'atterrissage est solide et non liquide
• que ce bloc de surface n'est pas dans la liste de matériaux de sol dangereux configurée, et n'est pas le plafond de bedrock du Nether
• que le point d'atterrissage est au niveau ou au-dessus de la hauteur minimale du monde, et que le bloc d'arrivée situé 51 blocs plus haut reste sous la hauteur maximale du monde
• que chaque bloc de la colonne de largage de 52 blocs (du point d'atterrissage jusqu'au bloc de tête d'arrivée) est de l'air ou franchissable
• qu'aucun bloc de cette colonne n'est dans la liste de matériaux corporels dangereux configurée
• que toutes les intégrations de plugins de protection activées autorisent l'emplacement
• qu'aucun listener CannonRTPLocationValidationEvent ne rejette le candidat

Dans le Nether, CannonRTP rejette le plafond de bedrock et scanne vers le bas à la recherche d'un sol de caverne dégagé dont la colonne de largage complète est sûre. Cela permet de cibler le Nether sans larguer le joueur au-dessus du plafond ni à travers du terrain solide.

Les tentatives de recherche sont limitées globalement à une par tick (20/s), réparties équitablement entre tous les canons actifs selon un tourniquet. Chaque canon a son propre compteur de timeout (searchTimeoutAttempts, 100 par défaut, minimum 10).

États du canon

Chaque canon possède un état interne visible via /wc status ou /wc list :

Affichage	État interne	Signification
Disabled	--	Le canon est explicitement désactivé dans sa configuration
Charging	SEARCHING (file vide)	Toujours en cours de préchargement de son premier lot d'emplacements sûrs
Maintaining	SEARCHING (file non vide)	Possède des emplacements mais comble encore les places consommées
Ready	READY	Possède suffisamment d'emplacements préchargés (>= chargedLocationsPerCannon) pour lancer les joueurs
Exhausted	EXHAUSTED	A épuisé searchTimeoutAttempts sans remplir la réserve

L'état de recherche interne prend exactement l'une de trois valeurs (READY, SEARCHING, EXHAUSTED) ; Disabled est décidé avant même qu'il soit consulté, et Charging / Maintaining sont les deux rendus de SEARCHING. Ready l'emporte sur Exhausted -- un canon qui conserve sa réserve chargée s'affiche comme Ready même si sa dernière fenêtre de recherche a expiré.

Il n'existe pas d'état « configuration invalide » distinct. Lorsque le targetWorld d'un canon ne peut pas être résolu, le canon conserve l'étiquette de son état de recherche actuel et la colonne $reason de /wc status devient Target world <name> is not loaded. (La clé de message statusLabels.invalid existe dans messages.yml mais rien ne l'affiche dans la version actuelle.)

Un canon lancera les joueurs dès qu'il aura au moins une destination en file. Le seuil chargedLocationsPerCannon n'affecte que l'étiquette visuelle READY.

Exigences d'exécution

• Minecraft : plugin.yml déclare api-version: 1.21.4 ; l'arborescence source actuelle est compilée contre l'API Spigot 26.2-R0.1-SNAPSHOT
• Java : 21
• Logiciel serveur recommandé : Paper ou un fork compatible actuel
• MagmaCore : 2.2.0 ou plus récent (bibliothèque partagée, incluse dans le plugin)
• Dépendance optionnelle : FreeMinecraftModels (pour les modèles 3D animés du canon)

Résilience

CannonRTP maintient ses visuels et ses files cohérents à travers les événements du cycle de vie des mondes et des chunks :

• lorsque le chunk d'un canon se décharge, son étiquette et son modèle sont supprimés ; ils réapparaissent au rechargement du chunk
• lorsque le monde d'un canon se décharge, le canon est suspendu ; il se réveille si le monde est rechargé
• lorsque FreeMinecraftModels est activé ou désactivé en cours de session, le cache de modèles est invalidé et les visuels sont rafraîchis au tick suivant
• avant la téléportation de largage, la destination en file est revérifiée face au terrain, aux intégrations de protection et aux listeners de l'API ; si elle est devenue dangereuse, le lancement récupère le joueur au lieu de s'engager sur des coordonnées périmées
• le nettoyage de lancement ne retire que les effets Lévitation, Invisibilité et Chute Lente que CannonRTP possède encore, et restaure tout effet plus ancien qu'il avait temporairement remplacé au lieu de supprimer l'état plus récent d'un autre plugin
• si un lancement ne peut pas continuer parce que son monde de destination se décharge, CannonRTP récupère le joueur sur le siège du canon ou sur le point d'apparition d'un autre monde chargé, et conserve Chute Lente lorsqu'aucun monde de récupération sûr n'est disponible

Pour commencer

• Commandes et Permissions
• Configuration
• Packages de Contenu
• Messages et Titres
• Intégrations de Protection
• Événements API