Quests erstellen
Beispiel-Quest
EliteMobs wird mit einer vorgefertigten test_quest.yml ausgeliefert, die hier als einfaches Quest-Format zum Nachvollziehen analysiert wird.
Benutzerdefinierte Quests befinden sich im Ordner ~plugins/EliteMobs/customquests!
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!"
Falls deine Quest-Oberfläche nicht so aussieht, kannst du sie mit /em alt entsprechend anpassen.
Diese Beispiel-Quest gibt Spielern die Aufgabe, 1 test_boss.yml zu erlegen. (Der tatsächliche Name des Bosses, der im Quest-Tracker angezeigt wird, ist der in test_boss.yml festgelegte name:.) Und als Belohnung für das Abschließen der Quest erhalten sie 1 Magmaguy's Toothpick.
Benutzerdefinierte Quests erstellen
isEnabled
Legt fest, ob die Quest aktiviert ist.
| Key | Werte | Standard |
|---|---|---|
isEnabled | Boolean | true |
Beispiel
isEnabled: true
customObjectives
Legt die Quest-Ziele fest.
| Key | Werte | Standard |
|---|---|---|
customObjectives | Speziell [1] | keiner |
Hinweis: Wenn du einen Mehrphasen-Boss als Ziel verwendest, sollte das Ziel die erste Phase als Zielvorgabe nutzen.
Beispiele
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:
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"
Speziell [1]
Tabelle aufklappen
Benutzerdefinierte Ziele werden aus den folgenden Werten zusammengesetzt:
| Key | Beschreibung |
|---|---|
objectiveType | Legt den Typ des Ziels fest, das dies darstellt. Gültige Werte sind KILL_CUSTOM, FETCH_ITEM, DIALOG und ARENA. KILL_CUSTOM bedeutet, dass die Quest das Töten eines bestimmten Custom Bosses beinhaltet, FETCH_ITEM bedeutet, dass die Quest das Beschaffen eines bestimmten Custom Items beinhaltet, DIALOG bedeutet, dass die Quest das Sprechen mit einem NPC beinhaltet, und ARENA bedeutet, dass die Quest das Abschließen einer bestimmten Arena beinhaltet. |
filename | Legt den Dateinamen des Custom Bosses, des Custom Items, das der Spieler töten / beschaffen muss, des NPCs, mit dem er sprechen muss, oder der Arena, die er abschließen muss, fest. Erforderlich – ein Ziel ohne filename wird mit einer Warnung in der Konsole verworfen. |
amount | Legt die Anzahl der Custom Bosses fest, die getötet werden müssen, oder der Items, die beschafft werden müssen. Standardwert ist 1, falls nicht angegeben. Wird von DIALOG (immer 1) und ARENA ignoriert. |
dialog | Nur DIALOG – die Zeilen, die der NPC sagt, wenn der Spieler mit ihm spricht. |
location | Nur DIALOG – ein Freitext-Hinweis darauf, wo der NPC ist, wird als $location in der Zusammenfassungszeile des Quest-Menüs angezeigt. |
name / npcName / itemName | Drei austauschbare Namen für dasselbe Feld: der Anzeigename des Zielobjekts im Quest-Tracker und in den Menüs. Nur zu Anzeigezwecken – verwende, was für den jeweiligen Zieltyp am besten passt. Bei FETCH_ITEM wird ohne Angabe auf den in der Custom-Item-Datei konfigurierten name zurückgegriffen. Bei DIALOG wird ohne Angabe auf den in der NPC-Datei konfigurierten name zurückgegriffen, wodurch auch die Übersetzung dieses NPCs übernommen wird. |
Jedes Ziel liegt unter seinem eigenen Schlüssel innerhalb von customObjectives (Objective1, Objective2, …), und seine Felder sind gewöhnliche YAML-Schlüssel. Älteren Quest-Dateien, die das einzeilige String-Format KILL_CUSTOM:filename=X.yml:amount=Y verwendeten, wird beim ersten Laden automatisch in dieses Layout umgewandelt und zurück auf die Festplatte geschrieben.
Verhalten von FETCH_ITEM
Der Fortschritt bei FETCH_ITEM wird jedes Mal neu aus dem Inventar des Spielers gezählt, wenn er ein Item aufnimmt oder wegwirft, wenn die Quest angenommen wird und wenn er versucht, sie abzugeben — Items, die vor dem Annehmen der Quest beschafft wurden, zählen also ebenfalls. Der Spieler muss die erforderliche Menge bei der Abgabe immer noch bei sich haben: Ist das nicht der Fall, wird die Abgabe abgebrochen. Bei einer erfolgreichen Abgabe werden die Quest-Items aus dem Inventar des Spielers verbraucht.
customRewards
Legt die Quest-Belohnungen fest.
| Key | Werte | Standard |
|---|---|---|
customRewards | Universelles EliteMobs-Loot-Format | keine |
Beispiel
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
Hinweis: Benutzerdefinierte Quests erzeugen keine Belohnungen automatisch. Lässt du customRewards leer, gewährt die Quest beim Abschluss überhaupt nichts — definiere Belohnungen also immer explizit. (Automatische, levelskalierte Belohnungen — Währung und Items nach Quest-Schwierigkeit — gelten nur für prozedural generierte dynamische Quests, nicht für in der Konfiguration definierte benutzerdefinierte Quests.)
Quest-Belohnungen werden direkt ausgegeben: Items gehen unmittelbar ins Inventar des Spielers (was nicht hineinpasst, wird zu seinen Füßen abgelegt), und Währung wird seinem Guthaben hinzugefügt. Um beim Abschluss Befehle auszuführen, verwende questCompleteCommands statt eines command=-Loot-Eintrags.
questAcceptPermission
Legt die Berechtigung fest, die der Spieler besitzen muss, um die Quest annehmen zu können.
| Key | Werte | Standard |
|---|---|---|
questAcceptPermission | String | keine |
Beispiel
questAcceptPermission: elitequest.my_permission
questAcceptPermissions
Legt die Berechtigungen fest, die der Spieler besitzen muss, um die Quest annehmen zu können.
| Key | Werte | Standard |
|---|---|---|
questAcceptPermissions | String-Liste | keine |
Beispiel
questAcceptPermissions:
- elitequest.my_previous_quest_one.yml
- elitequest.my_previous_quest_two.yml
questLockoutPermission
Legt die Berechtigung fest, die der Spieler nach Abschluss der Quest erhält und die ihn davon abhält, die Quest erneut zu absolvieren. Wird sie nicht angegeben, wird keine Sperrberechtigung vergeben und die Quest bleibt offen.
| Key | Werte | Standard |
|---|---|---|
questLockoutPermission | String | keine |
Beispiel
questLockoutPermission: elitequest.my_quest.yml
questLockoutMinutes
Legt fest, wie lange (in Minuten) der Spieler warten muss, bevor er die Quest erneut absolvieren kann.
| Key | Werte | Standard |
|---|---|---|
questLockoutMinutes | Integer | -1 (wird nie wiederholt) |
Es gibt zwei Sperrsysteme, und dieser Schlüssel entscheidet, welches davon verwendet wird:
- Jeder Wert über
0nutzt den zeitbasierten Sperr-Tracker. Der Spieler ist nach dem Abgeben dieser Quest für die angegebene Anzahl an Minuten für sie gesperrt, erfährt beim erneuten Annahmeversuch, wie lange die Sperre noch gilt, undquestLockoutPermissionwird für die Verfügbarkeitsprüfung ignoriert. 0oder kleiner fällt auf den alten MarkerquestLockoutPermissionzurück, der beim Abschluss dauerhaft vergeben wird. Ist auch keinquestLockoutPermissiongesetzt, bleibt die Quest wiederholbar.
Beispiel
questLockoutMinutes: 60
name
Legt den Quest-Namen fest. Akzeptiert Color Codes.
| Key | Werte | Standard |
|---|---|---|
name | String | [filename] |
Beispiel
name: "&aMy Great Quest Name"
questLore
Legt die Lore der Quest fest, die im Ingame-Quest-Menü erscheint.
| Key | Werte | Standard |
|---|---|---|
questLore | String-Liste | keine |
Beispiel
questLore:
- "Interesting lore sentence."
- "Yet another interesting lore sentence."
temporaryPermissions
Legt die Berechtigungen fest, die dem Spieler zugewiesen werden, bis er die Quest abgibt.
Wenn du diese Einstellung verwendest, um sicherzustellen, dass ein Item nur dann droppt, wenn Spieler eine bestimmte Quest aktiv haben, musst du außerdem die Same Permission in der Konfigurationsdatei des Items einrichten.
| Key | Werte | Standard |
|---|---|---|
temporaryPermissions | String-Liste | keine |
Beispiel
temporaryPermissions:
- elitequest.item_that_should_drop_only_during_quest.yml
questAcceptDialog
Legt den Dialog fest, der beim Annehmen der Quest im Chat erscheint.
Sind die Boss-Bar-Dialoge für Quests aktiviert, dient diese Liste zugleich als der Dialog, den der Quest-Geber vor dem Annehmen der Quest im Dialogfenster spricht. Ist sie leer, wird stattdessen questLore für diesen Dialog verwendet.
| Key | Werte | Standard |
|---|---|---|
questAcceptDialog | String-Liste | keiner |
Beispiel
questAcceptDialog:
- "My hero! You are so helpful!"
- "I wish you the best of luck!"
questCompleteMessage
Legt den Dialog fest, der bei der Abgabe der Quest angezeigt wird. Sind die Boss-Bar-Dialoge für Quests aktiviert (useQuestDialogueBossBars in QuestsConfig), wird er im Dialogfenster dargestellt, andernfalls im Chat gesendet. Bedrock-Spieler erhalten immer die Chat-Variante.
| Key | Werte | Standard |
|---|---|---|
questCompleteMessage | String-Liste | keiner |
Beispiel
questCompleteMessage:
- "My hero! You have completed my difficult quest!"
- "As a reward you can have this loaf of bread!"
questCompleteCommands
Legt die Befehle fest, die beim Abschließen der Quest ausgeführt werden. Befehle werden von der Konsole aus abgeschickt — lasse den führenden Schrägstrich also weg und verlasse dich nicht darauf, dass der Spieler die Berechtigung dafür hat.
Unterstützte Platzhalter: $player für den Namen des Spielers, $getWorld für den Namen der Welt, in der er sich befindet, und $getX, $getY, $getZ für seine Standortkoordinaten.
| Key | Werte | Standard |
|---|---|---|
questCompleteCommands | String-Liste | keine |
Beispiel
questCompleteCommands:
- say $player has finished a quest at $getX, $getY, $getZ!
- give $player diamond 1
turnInNPC
Legt den Dateinamen des NPCs fest, mit dem die Spieler sprechen / interagieren müssen, um die Quest abzuschließen. Dies muss nicht derselbe NPC sein, der die Quest vergeben hat.
| Key | Werte | Standard |
|---|---|---|
turnInNPC | Dateiname | keiner |
Beispiel
turnInNPC: my_cool_quest_npc.yml
Quest-Geber
Um einem NPC eine Quest zuzuweisen, die er an Spieler vergibt, musst du die NPC-Datei konfigurieren, nicht die Quest-Datei.
Füge in deiner NPC-Konfigurationsdatei (~/plugins/EliteMobs/npcs/) Folgendes hinzu:
interactionType: CUSTOM_QUEST_GIVER
questFileName: my_quest.yml
Für NPCs, die mehrere Quests vergeben:
interactionType: CUSTOM_QUEST_GIVER
questFileName:
- quest_one.yml
- quest_two.yml
interactionType: CUSTOM_QUEST_GIVER ist erforderlich – ohne diese Zeile ignoriert der NPC questFileName vollständig.
Weitere Informationen zur Konfiguration von NPCs findest du in der Dokumentation zur NPC-Erstellung.
trackable
Legt fest, ob die Quest den Quest-Tracker verwendet.
| Key | Werte | Standard |
|---|---|---|
trackable | Boolean | true |
Beispiel
trackable: true
questLevel
Legt das Level der Quest fest. Dies ist lediglich eine optische Orientierungshilfe, damit Spieler einschätzen können, wie anspruchsvoll die Quest sein wird. Dies verändert in keiner Weise die Level von Bossen, Items oder anderen Werten.
| Key | Werte | Standard |
|---|---|---|
questLevel | Integer | 0 |
Beispiel
questLevel: 10
questAcceptSound
Legt den Sound fest, der beim Annehmen einer Quest abgespielt wird. Es ist möglich, sowohl Minecraft-Sounds als auch Sounds aus einem Ressourcenpaket abzuspielen.
| Key | Werte | Standard |
|---|---|---|
questAcceptSound | String | keiner |
Beispiel
questAcceptSound: entity.experience_orb.pickup
questCompleteSound
Legt den Sound fest, der beim Abschließen (Abgeben) einer Quest abgespielt wird. Es ist möglich, sowohl Minecraft-Sounds als auch Sounds aus einem Ressourcenpaket abzuspielen.
| Key | Werte | Standard |
|---|---|---|
questCompleteSound | String | keiner |
Beispiel
questCompleteSound: entity.player.levelup
Lokalisierungsunterstützung
Die folgenden Felder unterstützen Lokalisierung für mehrsprachige Server:
namequestLorequestAcceptDialogquestCompleteMessage- Innerhalb jedes Eintrags von
customObjectives:dialog,npcNameundlocation
Dies ermöglicht es dir, Übersetzungen für verschiedene Sprachen auf deinem Server bereitzustellen.
Berechtigungen
Wie in den obigen Tabellen erwähnt, sind Berechtigungen üblicherweise Strings oder String-Listen. Aber gehen wir genauer darauf ein, wie du diese verwendest, um Quests zu sperren und freizuschalten.
Wichtig: questAcceptPermission und questAcceptPermissions sind keine Nodes eines Berechtigungs-Plugins. EliteMobs prüft seine eigenen internen Quest-Marker, die ein Spieler nur durch das Abschließen einer Quest erhält, deren questLockoutPermission passt. Denselben String über LuckPerms oder ein anderes Berechtigungs-Plugin zu vergeben schaltet die Quest nicht frei. (temporaryPermissions ist etwas anderes – diese werden als echte Berechtigungs-Nodes angehängt, solange die Quest aktiv ist, weshalb die permission-Sperre bei Items damit funktioniert.)
Nehmen wir an, du erstellst quest_3 in einer von dir geplanten Quest-Reihe und möchtest nicht, dass Spieler quest_3 annehmen können, bevor sie quest_2 abgeschlossen haben. Wir würden die Quest-Datei so konfigurieren:
questAcceptPermission: elitequest.quest_2.yml
questLockoutPermission: elitequest.quest_3.yml
Indem wir die questAcceptPermissions auf elitequest.quest_2.yml setzen, haben wir nun verhindert, dass Spieler quest_3.yml annehmen, bevor sie quest_2.yml abgeschlossen haben.
Indem wir questLockoutPermission auf elitequest.quest_3.yml setzen, haben wir verhindert, dass Spieler diese Quest erhalten können, solange sie sie bereits in ihrem Tracker haben oder bereits abgeschlossen haben. Dies hält Spieler davon ab, die Quest zu wiederholen.
Solltest du eine Quest erstellen wollen, die erst verfügbar wird, nachdem die Spieler eine Reihe von Quests abgeschlossen haben, würdest du die Quest-Datei so konfigurieren:
questAcceptPermissions:
- elitequest.quest_2.yml
- elitequest.quest_3.yml
- elitequest.quest_4.yml
Wenn du möchtest, dass Spieler bestimmte Items nur dann erbeuten können, wenn sie die richtige Quest aktiv haben, können wir das mit temporaryPermissions erreichen. Wir würden eine Berechtigung in der Quest-Datei mittels temporaryPermissions erstellen und dann eine passende permission in der Item-Datei mittels permission erstellen.
Wir würden zum Beispiel unsere Quest-Datei öffnen und Folgendes hinzufügen:
temporaryPermissions:
- elitequest.my_cool_item.yml
Dann würden wir die Item-Datei öffnen, in unserem Fall my_cool_item.yml, und Folgendes hinzufügen:
permission: elitequest.my_cool_item.yml
Beide Dateien haben nun übereinstimmende Berechtigungen, wodurch unser Item nun nur noch droppen sollte, wenn die Spieler die richtige Quest aktiv haben.
Gruppen und gemeinsamer Tötungsfortschritt
Der Besitz einer Quest bleibt immer persönlich: Der Beitritt zu einer Gruppe nimmt für einen anderen Spieler keine Quests an, gibt sie nicht ab und schüttet keine Belohnungen aus. Erhält jedoch ein Gruppenmitglied Tötungsgutschrift, bekommen verbundene Gruppenmitglieder in derselben Welt und innerhalb von sharedProgressRange (standardmäßig 128 Blöcke in der Party.yml) ebenfalls Fortschritt für jedes passende aktive Tötungsziel, einschließlich Zielen für einen bestimmten Custom Boss.
Sammelgegenstände, NPC-Dialoge und Arenaziele werden nicht geteilt. Nahe Spieler müssen weiterhin ihre eigene passende Quest aktiv haben, und Mitglieder, die sich in einer unabhängigen aktiven Instanz befinden, sind ausgeschlossen.
Dynamische Quests
Dynamische Quests sind prozedural generierte Quests, die von EliteMobs automatisch erstellt und aktualisiert werden. Anders als die in Konfigurationsdateien definierten benutzerdefinierten Quests erfordern dynamische Quests keinerlei manuelle Einrichtung und passen sich an den Fortschritt jedes Spielers an.
Wie sie funktionieren
- Quest-Stufe: Die dynamische Quest-Stufe eines Spielers wird aus seinem Kampflevel abgeleitet:
tier = combatLevel / 5, begrenzt auf einen Bereich von 1 bis 20. Ein Spieler mit Kampflevel 45 erhält zum Beispiel dynamische Quests der Stufe 9. Die Quests selbst (und ihre Belohnungen) werden auf das tatsächliche Kampflevel des Spielers skaliert, das auf einen Bereich von 1 bis 100 begrenzt ist. - 3 Quests pro Stufe: Für jede der 20 Quest-Stufen generiert das System gleichzeitig genau 3 zufällige Quest-Ziele. Spielern werden die 3 Quests angeboten, die ihrer aktuellen Stufe entsprechen.
- Automatischer Aktualisierungszyklus: Der Pool dynamischer Quest-Ziele wird alle 60 Sekunden (alle 1200 Ticks) neu generiert. Wenn sich der Pool aktualisiert, ersetzen neue Ziele die alten, was den Spielern eine rotierende Auswahl an Aufgaben bietet.
- Anpassung an dynamische Dungeons: Wenn ein Spieler einen dynamischen Dungeon mit einer bestimmten Levelauswahl betritt, passen sich alle seine aktiven dynamischen Quests an das Mob-Level des Dungeons an. Quest-Level, Ziele und Anzeigename werden entsprechend aktualisiert, sodass die Quests für den Dungeon-Inhalt relevant bleiben.