Créer des Quêtes
Exemple de quête
Cet exemple simplifié suit le format du fichier fourni test_quest.yml.
Créez des fichiers .yml aux noms uniques dans plugins/EliteMobs/customquests/, depuis le dossier du serveur. Chargez la quête et les contenus référencés avec /em reload, puis attribuez-la à un PNJ comme indiqué ci-dessous.
test_quest.yml
isEnabled: true
customObjectives:
Objective1:
amount: '1'
filename: test_boss.yml
objectiveType: KILL_CUSTOM
customRewards:
- filename=magmaguys_toothpick.yml:amount=1:chance=1
name: "&aKill the Test Boss"
questLore:
- "&cEnd the test boss' reign of terror!"
L'image montre l'ancienne interface de livre. /em alt change la préférence de menu : les joueurs Java qui la sélectionnent reçoivent des livres avant Minecraft 1.21.6 et des dialogues Minecraft sur les versions plus récentes. Les joueurs Bedrock et ceux qui préfèrent les menus d'inventaire reçoivent une interface d'inventaire.
Cette quête d'exemple donnera aux joueurs la tâche d'abattre 1 test_boss.yml. (Le nom réel du boss affiché dans le suivi de quête sera le name: défini dans test_boss.yml.) Et en récompense de la complétion de la quête, ils recevront 1 Cure-dent de Magmaguy.
Les objectifs deviennent actifs ensemble à l'acceptation ; Objective1, Objective2, etc. n'imposent aucun ordre. Tous doivent être remplis avant de recevoir les récompenses. Par défaut, le joueur rend ensuite la quête à son PNJ. Avec requireQuestTurnIn: false dans Quests.yml, remplir les objectifs tente immédiatement de terminer la quête, avec vérification et consommation des objets à rapporter. maximumActiveQuests limite les quêtes acceptées à 10 par défaut.
Créer des quêtes personnalisées
isEnabled
Définit si la quête est activée.
| Clé | Valeurs | Défaut |
|---|---|---|
isEnabled | Booléen | true |
Exemple
isEnabled: true
customObjectives
Définit les objectifs de la quête.
| Clé | Valeurs | Défaut |
|---|---|---|
customObjectives | Spécial [1] | aucun |
Pour un boss à plusieurs phases, référencez le fichier de sa première phase. La progression est accordée à sa mort, pas à chaque transition. KILL_CUSTOM compare le nom du fichier sans imposer questLevel comme niveau minimal du boss éliminé.
Exemples
KILL_CUSTOM :
customObjectives:
Objective1:
amount: '1'
filename: my_cool_boss.yml
objectiveType: KILL_CUSTOM
DIALOG :
customObjectives:
Objective1:
dialog:
- "&a[Dialog NPC] &fCome here often?"
- "&7&oI should eat more apples."
filename: dialog_npc.yml
npcName: Dialog NPC
location: at dialog location.
objectiveType: DIALOG
FETCH_ITEM :
Les objectifs de collecte comptent les objets portant les étiquettes d'objet personnalisé EliteMobs dans l'inventaire. Lors de la remise, tous sont vérifiés sur une même copie de l'inventaire avant toute consommation ou récompense. Si deux objectifs demandent le même objet, leurs quantités s'additionnent ; une pile ne peut pas satisfaire les deux à la fois. Lâcher un objet peut rendre un objectif de nouveau incomplet.
customObjectives:
Objective1:
amount: '99'
itemName: Red Apples
filename: my_quest_item_red_apples.yml
objectiveType: FETCH_ITEM
ARENA :
customObjectives:
Objective1:
objectiveType: ARENA
filename: my_arena.yml
name: "Complete the Arena"
Spécial [1]
Déplier le Tableau
Les Objectifs Personnalisés sont construits à l'aide des valeurs suivantes :
| Clé | Description |
|---|---|
objectiveType | Type d'objectif : KILL_CUSTOM élimine un boss personnalisé, FETCH_ITEM réunit un objet personnalisé, DIALOG demande de parler à un PNJ, ARENA termine une arène et CLASS_UNLOCK observe le déblocage d'une classe. |
filename | Nom de fichier .yml obligatoire du boss, de l'objet, du PNJ de dialogue, de l'arène ou de l'entraîneur. Utilisez une définition chargée, pas son nom affiché. Un objectif sans filename, ou dont l'objectiveType est absent ou inconnu, désactive toute la quête avec un avertissement dans la console. Un CLASS_UNLOCK invalide reste dans la quête mais ne peut pas être accompli. Corrigez tous les avertissements avant de proposer la quête. |
amount | Nombre entier positif de boss à éliminer ou d'objets à réunir ; 1 par défaut. Une valeur inférieure à 1 désactive la quête. DIALOG, ARENA et CLASS_UNLOCK ont une cible de un et ignorent ce champ. |
dialog | DIALOG uniquement — les lignes que le PNJ prononce lorsque le joueur lui parle. |
location | DIALOG uniquement — une indication en texte libre sur l'endroit où se trouve le PNJ, affichée sous forme de $location dans la ligne de résumé du menu de quête. |
name / npcName / itemName | Alias facultatifs du libellé de FETCH_ITEM, DIALOG, ARENA et CLASS_UNLOCK. N'en définissez qu'un. Tous sont traduisibles et permettent une formulation particulière ou de cacher une information. Sans remplacement, FETCH_ITEM utilise le nom traduit de l'objet et DIALOG celui du PNJ. KILL_CUSTOM utilise le nom configuré du boss. |
class | CLASS_UNLOCK uniquement : ID de la forme de classe à observer, par exemple adventurer. |
Fournissez une table customObjectives non vide avec une clé unique par objectif (Objective1, Objective2, ...). Les noms de champs sont sensibles à la casse ; les types utilisent les valeurs en majuscules indiquées ci-dessus. Les anciens fichiers utilisant des chaînes comme KILL_CUSTOM:filename=X.yml:amount=Y sont convertis à ce format au premier chargement et enregistrés sur disque.
Les libellés ont leurs propres entrées de traduction, identifiées par le fichier de quête et un chemin comme customObjectives.Objective1.itemName. Traduisez cette entrée du CSV même si l'objet sous-jacent est déjà traduit. Sans traduction, le libellé original reste affiché afin de ne pas révéler un nom caché. Le texte source reste dans le YAML et les traductions existantes sont conservées.
Comportement de FETCH_ITEM
FETCH_ITEM identifie l'étiquette du fichier de l'objet, pas son matériau, son nom visible ou sa description. Les objets obtenus avant l'acceptation comptent, y compris dans les emplacements d'armure et de main secondaire. L'acceptation, le ramassage ou l'abandon d'objets correspondants et les récompenses de quête programment un recomptage au tick suivant. Les autres modifications de l'inventaire peuvent ne pas se refléter immédiatement, mais la remise vérifie toujours l'inventaire à nouveau. En cas de réussite, les objets requis sont consommés ; une quantité totale insuffisante annule la remise sans retrait partiel.
DIALOG progresse lors de l'interaction avec un PNJ correspondant, avant l'ouverture de son menu habituel. Le joueur n'a pas besoin de finir de lire. location n'est qu'une indication textuelle, pas des coordonnées pour la boussole. ARENA progresse lorsque le joueur termine l'arène indiquée avec la quête active ; une victoire antérieure ne compte pas.
Objectifs de déblocage de classe
CLASS_UNLOCK observe une classe débloquée avec le système de combat avancé. Il ne donne pas la classe. Par exemple :
customObjectives:
Objective1:
objectiveType: CLASS_UNLOCK
class: adventurer
filename: class_trainer_adventurer.yml
class doit identifier une forme existante. filename dirige le suivi vers son entraîneur ; name remplace facultativement le libellé. L'objectif compte jusqu'à un et reconnaît une classe débloquée avant l'acceptation, même si elle n'est pas équipée. La progression de classe doit être disponible et le déblocage est revérifié à la fin. Une classe invalide ou un fichier d'entraîneur manquant laisse un objectif impossible à terminer ; il n'est pas ignoré.
Suivi et abandon
Un joueur ne peut suivre qu'une quête à la fois. Avec autoTrackNextQuestOnCompletion: true dans Quests.yml, terminer la quête suivie en sélectionne une autre active et suivable au tick suivant. questAutoTrackNextMessage accepte $questName. autoTrackQuestsOnAccept vaut également true par défaut, mais utilise actuellement le bouton de bascule : accepter une quête alors qu'une autre est suivie peut arrêter le suivi au lieu de le transférer. Réactivez-le depuis le menu si nécessaire.
La boussole cherche les destinations prises en charge : boss personnalisés, PNJ de dialogue ou entraîneurs, et boss ou coffres dont les tables de butin contiennent l'objet demandé. Elle ne trouve pas toutes les sources possibles d'objets ; les objectifs d'arène ou d'élimination dynamique n'ont pas de recherche de destination spécifique. Pour un autre monde, elle peut indiquer un portail direct approprié ou le monde de destination, sans garantir un chemin praticable. L'absence de destination n'empêche pas de progresser.
L'abandon normal demande une seconde confirmation. Le message et son survol utilisent questAbandonConfirmationText et questAbandonConfirmationHover. Abandonner retire la quête active et son suivi ; cela ne déclenche pas le délai de fin défini par questLockoutMinutes et n'accorde pas le marqueur de fin. La quête peut être reprise si ses conditions habituelles le permettent.
Les indicateurs de quête des PNJ sont propres à chaque joueur et apparaissent dans un rayon de 30 blocs. La boussole comprend des indications verticales. Pendant un dialogue par barres de boss, la zone est réservée : les autres barres gérées sont masquées et l'ancienne option hideKeyedBossBarsDuringQuestDialogue est supprimée. hideQuestScoreboardDuringQuestDialogue contrôle séparément le panneau latéral.
Sur Java, s'accroupir révèle la page en cours, puis permet d'avancer. Le dialogue applique Lenteur III pendant 30 secondes au maximum, sans immobiliser le joueur. Des dégâts non annulés supérieurs à zéro ferment les écrans et le dialogue de quête. Bedrock reçoit ce dialogue dans le chat. Son illustration nécessite les ressources correspondantes du pack.
customRewards
Définit les récompenses de la quête.
| Clé | Valeurs | Défaut |
|---|---|---|
customRewards | Format de butin universel d'EliteMobs | aucun |
Exemple
customRewards:
- currencyAmount=50:amount=1:chance=0.05
- material=COOKED_COD:amount=3:chance=1.0
- filename=magmaguys_toothpick.yml:amount=1:chance=1.0
Les quêtes personnalisées ne génèrent pas automatiquement de récompenses. Si customRewards est vide, cette table n'accorde ni objets ni monnaie ; les commandes de fin configurées séparément s'exécutent tout de même. Les récompenses automatiques concernent les quêtes dynamiques.
Les objets à niveau adaptable utilisent le niveau sélectionné du donjon dynamique ou le niveau de combat actuel du joueur, avec 10 % de chances de gagner un niveau. Les objets fixes et limités conservent leurs règles. questLevel ne définit pas le niveau réel de la récompense.
Les récompenses sont remises directement : les objets vont dans l'inventaire, le surplus tombe aux pieds du joueur et la monnaie est ajoutée à son solde. Pour exécuter des commandes, utilisez questCompleteCommands plutôt qu'une entrée de butin command=.
L'aperçu et la remise effectuent des tirages séparés. Une récompense aléatoire ou un niveau bonus affiché n'est pas réservé au joueur.
questAcceptPermission
Exige un marqueur de fin de quête EliteMobs pour accepter la quête. Accorder une permission ordinaire du même nom ne satisfait pas cette condition.
| Clé | Valeurs | Défaut |
|---|---|---|
questAcceptPermission | Chaîne | aucun |
Exemple
questAcceptPermission: elitequest.my_permission
questAcceptPermissions
Exige tous les marqueurs de fin de quête indiqués. Si questAcceptPermission est également défini, son marqueur est requis en plus de la liste.
| Clé | Valeurs | Défaut |
|---|---|---|
questAcceptPermissions | Liste de chaînes | aucun |
Exemple
questAcceptPermissions:
- elitequest.my_previous_quest_one.yml
- elitequest.my_previous_quest_two.yml
questLockoutPermission
Définit le marqueur accordé après une réussite. Il peut débloquer d'autres quêtes et, si questLockoutMinutes est nul ou négatif, empêche de refaire celle-ci. Son omission ne désactive pas un délai positif.
| Clé | Valeurs | Défaut |
|---|---|---|
questLockoutPermission | Chaîne | aucune |
Exemple
questLockoutPermission: elitequest.my_quest.yml
questLockoutMinutes
Définit le nombre de minutes à attendre avant de pouvoir refaire la quête.
| Clé | Valeurs | Défaut |
|---|---|---|
questLockoutMinutes | Entier | -1 (règle du marqueur ci-dessous) |
Deux systèmes de verrouillage existent :
- Au-dessus de
0, le suivi temporel bloque cette quête après sa remise pendant la durée indiquée et affiche le temps restant. La disponibilité ignore alorsquestLockoutPermission. - À
0ou moins, le marqueurquestLockoutPermissionest accordé définitivement et bloque la répétition. Sans ce marqueur, la quête reste répétable.
Si les deux champs sont définis avec une durée positive, le marqueur est tout de même accordé, mais expire après cette durée. Une quête suivante qui l'exige doit être acceptée avant son expiration. Le délai est enregistré par nom de fichier de quête, séparément du marqueur de prérequis.
Exemple
questLockoutMinutes: 60
name
Définit le nom de la quête. Accepte les codes couleur.
| Clé | Valeurs | Défaut |
|---|---|---|
name | Chaîne | vide |
Exemple
name: "&aMy Great Quest Name"
questLore
Définit le lore de la quête qui apparaîtra dans le menu de quête en jeu.
| Clé | Valeurs | Défaut |
|---|---|---|
questLore | Liste de chaînes | aucun |
Exemple
questLore:
- "Interesting lore sentence."
- "Yet another interesting lore sentence."
temporaryPermissions
Accorde de véritables permissions Bukkit à l'acceptation et les réapplique lorsqu'une quête active est restaurée après connexion. Terminer ou abandonner la quête les retire, et la déconnexion les libère jusqu'à la connexion suivante. Chaque quête accorde ses nœuds séparément : deux quêtes actives peuvent donc partager un nœud, et terminer l'une d'elles laisse le nœud accordé par l'autre.
Pour la génération normale d'objets, configurez la même permission dans l'objet. Ce contrôle ne couvre pas toutes les voies de remise.
| Clé | Valeurs | Défaut |
|---|---|---|
temporaryPermissions | Liste de chaînes | aucun |
Exemple
temporaryPermissions:
- elitequest.item_that_should_drop_only_during_quest.yml
questAcceptDialog
Définit le dialogue qui apparaît dans le chat lors de l'acceptation de la quête.
Lorsque les dialogues par barres de boss sont activés, cette liste sert aussi de texte au donneur de quête avant l'acceptation. Si elle est vide, questLore est utilisé à la place.
| Clé | Valeurs | Défaut |
|---|---|---|
questAcceptDialog | Liste de chaînes | aucun |
Exemple
questAcceptDialog:
- "My hero! You are so helpful!"
- "I wish you the best of luck!"
questCompleteMessage
Définit le dialogue de remise. Avec useQuestDialogueBossBars dans Quests.yml, il peut apparaître avant le menu de remise ; sinon, il apparaît après une réussite. Un dialogue de remise affiché récemment n'est pas répété à la fin. Bedrock reçoit du texte dans le chat. Voir ce dialogue ne prouve pas que les récompenses ont été accordées.
| Clé | Valeurs | Défaut |
|---|---|---|
questCompleteMessage | Liste de chaînes | aucun |
Exemple
questCompleteMessage:
- "My hero! You have completed my difficult quest!"
- "As a reward you can have this loaf of bread!"
questCompleteCommands
Définit les commandes qui s'exécuteront lors de la complétion de la quête. Les commandes sont envoyées depuis la console : n'incluez donc pas de barre oblique initiale et ne comptez pas sur le fait que le joueur ait la permission de les exécuter.
Placeholders pris en charge : $player pour le nom du joueur, $getWorld pour le nom du monde dans lequel il se trouve, et $getX, $getY, $getZ pour ses coordonnées.
| Clé | Valeurs | Défaut |
|---|---|---|
questCompleteCommands | Liste de chaînes | aucun |
Exemple
questCompleteCommands:
- say $player has finished a quest at $getX, $getY, $getZ!
- give $player diamond 1
turnInNPC
Définit le fichier du PNJ auquel rendre la quête. Il peut différer du donneur initial ; s'il est omis, ce dernier est utilisé. Un PNJ de remise séparé doit utiliser interactionType: CUSTOM_QUEST_GIVER, même avec une liste d'offres vide.
| Clé | Valeurs | Défaut |
|---|---|---|
turnInNPC | Nom de fichier | aucun |
Exemple
turnInNPC: my_cool_quest_npc.yml
Donneurs de quêtes
Pour attribuer une quête à un PNJ qui la donnera aux joueurs, vous devez configurer le fichier du PNJ, et non le fichier de la quête.
Dans le fichier du PNJ (plugins/EliteMobs/npcs/), ajoutez :
interactionType: CUSTOM_QUEST_GIVER
questFileName:
- my_quest.yml
Pour les PNJ qui donnent plusieurs quêtes :
interactionType: CUSTOM_QUEST_GIVER
questFileName:
- quest_one.yml
- quest_two.yml
Utilisez une liste YAML même pour une seule quête ; la valeur scalaire questFileName: my_quest.yml n'est pas chargée comme liste d'offres. interactionType: CUSTOM_QUEST_GIVER est nécessaire pour l'ouvrir.
Consultez la documentation sur la création de PNJ pour plus d'informations sur la configuration des PNJ.
trackable
Autorise le suivi manuel et automatique par boussole. Le désactiver n'arrête ni la progression, ni les récompenses, ni les panneaux temporaires de progression.
| Clé | Valeurs | Défaut |
|---|---|---|
trackable | Booléen | true |
Exemple
trackable: true
questLevel
Définit le niveau de la quête. Il s'agit uniquement d'un guide visuel permettant aux joueurs de savoir à quel point la quête sera difficile. Cela ne modifie en aucune façon les niveaux des boss, des objets ou autres.
| Clé | Valeurs | Défaut |
|---|---|---|
questLevel | Entier | 0 |
Exemple
questLevel: 10
questAcceptSound
Définit le son à l'acceptation, provenant de Minecraft ou d'un pack de ressources. Si le champ est omis, le son global d'acceptation de SoundsConfig est utilisé.
| Clé | Valeurs | Défaut |
|---|---|---|
questAcceptSound | Chaîne | aucun |
Exemple
questAcceptSound: entity.experience_orb.pickup
questCompleteSound
Définit le son lorsque la quête est terminée, provenant de Minecraft ou d'un pack de ressources. Si le champ est omis, le son global de fin de quête de SoundsConfig est utilisé.
| Clé | Valeurs | Défaut |
|---|---|---|
questCompleteSound | Chaîne | aucun |
Exemple
questCompleteSound: entity.player.levelup
Traduction
Les champs suivants prennent en charge la localisation pour les serveurs multilingues :
namequestLorequestAcceptDialogquestCompleteMessage- Dans chaque entrée de
customObjectives:dialog,name,npcName,itemNameetlocation
Cela vous permet de fournir des traductions pour différentes langues sur votre serveur.
Permissions
Les permissions sont des chaînes ou des listes de chaînes. Voici comment les utiliser pour verrouiller et débloquer des quêtes.
Important : questAcceptPermission et questAcceptPermissions vérifient les marqueurs internes d'EliteMobs, pas les permissions ordinaires. Terminer une quête avec le questLockoutPermission correspondant crée le marqueur. Accorder le même nom avec LuckPerms ne débloque pas la quête. temporaryPermissions accorde au contraire de vraies permissions tant que la quête est active.
Disons que vous créez quest_3 dans une série de quêtes que vous avez planifiée et que vous ne voulez pas que les joueurs puissent prendre quest_3 avant d'avoir terminé quest_2. Nous configurerions le fichier de quête comme ceci :
questAcceptPermission: elitequest.quest_2.yml
questLockoutPermission: elitequest.quest_3.yml
La quête 2 doit accorder elitequest.quest_2.yml par son propre questLockoutPermission. La quête 3 exige alors ce marqueur avec questAcceptPermission. Avec la durée non positive par défaut, terminer la quête 3 accorde son marqueur permanent et empêche de la répéter. Proposer une quête déjà active depuis un autre PNJ n'en crée pas une seconde copie indépendante.
Si vous souhaitez créer une quête qui ne devient disponible qu'après que les joueurs ont terminé une série de quêtes, vous configureriez alors le fichier de quête comme ceci :
questAcceptPermissions:
- elitequest.quest_2.yml
- elitequest.quest_3.yml
- elitequest.quest_4.yml
Pour que l'acceptation autorise la génération normale d'un objet, ajoutez un nœud à temporaryPermissions et utilisez le même dans le champ permission de l'objet.
Par exemple, nous ouvririons notre fichier de quête et ajouterions ce qui suit :
temporaryPermissions:
- elitequest.my_cool_item.yml
Ensuite, nous ouvririons le fichier d'objet, dans notre cas my_cool_item.yml, puis nous ajouterions ce qui suit :
permission: elitequest.my_cool_item.yml
La quête accorde maintenant le nœud contrôlé lors de la génération normale tant qu'elle est active, et le retire lorsqu'elle est terminée ou abandonnée.
Groupes et crédit d'élimination partagé
Les quêtes restent personnelles : rejoindre un groupe n'accepte, ne rend et ne récompense aucune quête pour autrui. Lorsqu'un membre obtient le crédit d'une élimination, les membres connectés dans le même monde et à portée de sharedProgressRange (128 blocs par défaut dans Party.yml) progressent aussi dans leurs objectifs actifs correspondants, y compris ceux visant un boss personnalisé.
Les objets de collecte, dialogues et objectifs d'arène ne sont pas partagés. Les bénéficiaires doivent avoir leur propre quête correspondante active et leurs données chargées. Si leur partie a dépassé l'attente ou le démarrage, ils doivent figurer dans sa liste initiale de participants. Le contrôle ne compare pas séparément leur instance à celle de l'élimination ; la proximité dans le même monde reste nécessaire.
Quêtes dynamiques
Les Quêtes Dynamiques sont des quêtes générées de manière procédurale qui sont automatiquement créées et actualisées par EliteMobs. Contrairement aux quêtes personnalisées définies dans les fichiers de configuration, les quêtes dynamiques ne nécessitent aucune configuration manuelle et s'adaptent à la progression de chaque joueur.
Fonctionnement
- Donneur : utilisez un PNJ avec
interactionType: QUEST_GIVER. Ses offres viennent des modèles dynamiques, pas dequestFileName. - Palier : limitez le niveau de combat à 1–100, divisez-le par cinq avec une division entière, puis limitez le palier à 1–20. Le niveau 45 donne le palier 9. Le palier détermine les modèles et le nombre de victimes ; le niveau minimal des ennemis utilise le niveau de combat borné du joueur.
- Trois modèles par palier : chacun choisit un type d'entité dans
questEntityTypesdeQuests.yml. Les types d'entité inconnus et ceux sans propriétés de mob EliteMobs sont ignorés avec un avertissement, et une liste sans entrée utilisable désactive les offres de quêtes dynamiques. Chaque modèle choisit aussi un nombre de victimes entretier + 1ettier * 10, bornes incluses. L'Elite Mob correspondant doit atteindre ou dépasser le niveau minimal ; un monstre Minecraft ordinaire ne compte pas. - Actualisation : les modèles changent toutes les 1200 ticks, soit environ 60 secondes à 20 TPS. Les quêtes existantes et leur progression sont conservées. Le menu les combine avec les trois modèles du palier actuel, sans dupliquer leurs IDs ; il ne contient donc pas forcément trois entrées.
- Donjons dynamiques : entrer dans un donjon adapte le niveau minimal des ennemis, le niveau affiché et le nom des quêtes dynamiques existantes au niveau choisi, borné à 1–100. Les quantités et la progression sont conservées. La monnaie n'est pas recalculée.
- Récompenses : la monnaie est fixée à la création de l'offre par
floor(questLevel / 2 * targetKillCount). L'objet est généré par le système normal de butin à la remise, au niveau sélectionné du donjon dynamique ou au niveau de combat actuel, avec 10 % de chances de gagner un niveau et une limite finale de 1–100. Les règles de disponibilité et d'adaptation des objets s'appliquent ; l'aperçu est un tirage séparé.