Quests erstellen

Beispiel-Quest

Dieses vereinfachte Beispiel folgt dem Format der mitgelieferten test_quest.yml.

Erstelle eindeutig benannte .yml-Dateien unter plugins/EliteMobs/customquests/, ausgehend vom Serverordner. Lade die Quest und ihre referenzierten Inhalte mit /em reload und weise sie anschließend wie unten beschrieben einem NPC zu.

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!"

Das Bild zeigt die ältere Buchoberfläche. /em alt ändert die Menüpräferenz: Java-Spieler mit dieser Einstellung erhalten vor Minecraft 1.21.6 Bücher und in neueren Versionen Minecraft-Dialoge. Bedrock-Spieler und Spieler mit Inventarmenüs erhalten eine Inventaroberfläche.

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.

Alle Ziele werden beim Annehmen gleichzeitig aktiv; Schlüssel wie Objective1 und Objective2 legen keine Reihenfolge fest. Für Belohnungen müssen alle Ziele erfüllt sein. Standardmäßig gibt der Spieler die Quest danach beim NPC ab. Mit requireQuestTurnIn: false in Quests.yml wird der Abschluss sofort versucht, sobald die Ziele erfüllt sind, einschließlich Prüfung und Verbrauch der Sammelgegenstände. maximumActiveQuests begrenzt angenommene Quests standardmäßig auf 10.

Benutzerdefinierte Quests erstellen

isEnabled

Legt fest, ob die Quest aktiviert ist.

Schlüssel	Werte	Standard
isEnabled	Wahrheitswert	true

Beispiel

isEnabled: true

---

customObjectives

Legt die Quest-Ziele fest.

Schlüssel	Werte	Standard
customObjectives	Speziell [1]	keiner

Verwende bei einem Boss mit mehreren Phasen den Dateinamen der ersten Phase. Fortschritt gibt es beim Tod des Bosses, nicht bei jedem Phasenwechsel. KILL_CUSTOM vergleicht den Dateinamen und verlangt questLevel nicht als Mindestlevel des getöteten Bosses.

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:

Sammelziele zählen die passenden EliteMobs-Kennzeichnungen benutzerdefinierter Items im Inventar. Bei der Abgabe werden alle Sammelziele anhand desselben Inventarabbilds geprüft, bevor Items entfernt oder Belohnungen vergeben werden. Verlangen zwei Ziele dasselbe Item, wird ihre gemeinsame Menge benötigt; derselbe Stapel kann nicht beide Anforderungen erfüllen. Wegwerfen kann ein zuvor erfülltes Ziel wieder unvollständig machen.

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:

Schlüssel	Beschreibung
objectiveType	Zieltyp: KILL_CUSTOM tötet einen benutzerdefinierten Boss, FETCH_ITEM sammelt ein benutzerdefiniertes Item, DIALOG spricht mit einem NPC, ARENA schließt eine Arena ab und CLASS_UNLOCK beobachtet eine Klassenfreischaltung.
filename	Erforderlicher .yml-Dateiname des Bosses, Items, Dialog-NPCs, der Arena oder des Klassentrainers. Verwende eine geladene Definition, keinen Anzeigenamen. Ein Ziel ohne filename oder mit fehlendem oder unbekanntem objectiveType deaktiviert die gesamte Quest mit einer Warnung in der Konsole. Ein ungültiges CLASS_UNLOCK bleibt in der Quest, kann aber nicht abgeschlossen werden. Behebe alle Warnungen, bevor du die Quest anbietest.
amount	Positive ganze Anzahl zu tötender Bosse oder zu sammelnder Items; Standard 1. Ein Wert unter 1 deaktiviert die Quest. DIALOG, ARENA und CLASS_UNLOCK haben jeweils die Zielmenge eins und ignorieren dieses Feld.
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	Optionale Aliasnamen für die Beschriftung von FETCH_ITEM, DIALOG, ARENA und CLASS_UNLOCK. Setze nur einen. Alle drei sind übersetzbar und erlauben eigene Formulierungen oder das Verbergen von Informationen. Ohne eigene Beschriftung verwendet FETCH_ITEM den übersetzten Itemnamen und DIALOG den übersetzten NPC-Namen. KILL_CUSTOM verwendet den konfigurierten Bossnamen.
class	Nur CLASS_UNLOCK: ID der beobachteten Klassenform, beispielsweise adventurer.

Gib eine nicht leere customObjectives-Map mit einem eindeutigen Schlüssel pro Ziel an (Objective1, Objective2, ...). Feldnamen beachten Groß- und Kleinschreibung; Zieltypen verwenden die oben angegebenen Großbuchstaben. Alte Dateien mit einzeiligen Einträgen wie KILL_CUSTOM:filename=X.yml:amount=Y werden beim ersten Laden automatisch umgewandelt und gespeichert.

Zielbeschriftungen besitzen eigene Übersetzungseinträge, gekennzeichnet durch Quest-Dateiname und Feldpfad wie customObjectives.Objective1.itemName. Übersetze diesen CSV-Eintrag auch dann, wenn das Item bereits übersetzt ist. Ohne Übersetzung bleibt die ursprüngliche Beschriftung erhalten, damit kein verborgener Itemname verraten wird. Der Quelltext bleibt im YAML; vorhandene Übersetzungen werden bewahrt.

Verhalten von FETCH_ITEM

FETCH_ITEM erkennt die Dateinamen-Kennzeichnung des Items, nicht Material, Anzeigename oder Beschreibung. Bereits vor Annahme erhaltene Items zählen, auch in Rüstungsslots und Nebenhand. Annahme, Aufheben oder Wegwerfen passender Items und Quest-Belohnungen veranlassen eine Neuzählung im nächsten Tick. Andere Inventaränderungen aktualisieren die Anzeige möglicherweise nicht sofort; bei der Abgabe wird jedoch immer erneut geprüft. Bei Erfolg werden die benötigten Items verbraucht. Reicht die Gesamtmenge nicht, wird ohne teilweise Entnahme abgebrochen.

DIALOG schreitet bei der Interaktion mit einem passenden NPC fort, bevor dessen gewöhnliches Menü geöffnet wird. Der Dialog muss nicht zu Ende gelesen werden. location ist nur ein Texthinweis, keine Kompasskoordinate. ARENA schreitet beim Abschluss der angegebenen Arena mit aktiver Quest fort; frühere Abschlüsse zählen nicht rückwirkend.

---

Klassenfreischaltung als Ziel

CLASS_UNLOCK beobachtet eine über das erweiterte Kampfsystem freigeschaltete Klasse. Es schaltet die Klasse nicht selbst frei. Beispiel:

customObjectives:
  Objective1:
    objectiveType: CLASS_UNLOCK
    class: adventurer
    filename: class_trainer_adventurer.yml

class muss eine vorhandene Klassenform bezeichnen. filename führt den Kompass zum Trainer; name überschreibt optional die Beschriftung. Die Zielmenge ist eins. Bereits vor Annahme freigeschaltete Klassen zählen auch dann, wenn sie nicht ausgerüstet sind. Die Klassenprogression muss verfügbar sein; beim Abschluss wird die Freischaltung erneut geprüft. Eine ungültige Klasse oder ein fehlender Trainerdateiname erzeugt ein unerfüllbares Ziel, das nicht übersprungen wird.

Verfolgung und Abbruch

Pro Spieler kann nur eine Quest verfolgt werden. Mit autoTrackNextQuestOnCompletion: true in Quests.yml wird nach Abschluss der verfolgten Quest im nächsten Tick eine andere aktive, verfolgbare Quest gewählt. questAutoTrackNextMessage unterstützt $questName. Auch autoTrackQuestsOnAccept ist standardmäßig true, nutzt derzeit aber die Umschaltfunktion: Wird bereits eine Quest verfolgt, kann die Annahme einer weiteren die Verfolgung stoppen statt wechseln. Aktiviere sie dann erneut im Quest-Menü.

Der Kompass sucht unterstützte Ziele: benutzerdefinierte Bosse, Dialog-NPCs oder Trainer sowie Bosse und Schatztruhen, deren Beutetabellen das gesuchte Item enthalten. Er findet nicht jede mögliche Itemquelle; Arena- und dynamische Tötungsziele haben keine eigene Zielsuche. Für eine andere Welt kann er ein geeignetes direktes Wurmloch oder den Zielweltnamen anzeigen, garantiert aber keinen begehbaren Weg. Ein fehlendes Kompassziel verhindert keinen Quest-Fortschritt.

Der normale Abbruch verlangt eine zweite Bestätigung. Nachricht und Hinweistext verwenden questAbandonConfirmationText und questAbandonConfirmationHover. Abbrechen entfernt die aktive Quest und ihre Verfolgung, startet jedoch keine Abschlusssperre aus questLockoutMinutes und vergibt keinen Abschlussmarker. Bei erfüllten normalen Voraussetzungen kann die Quest erneut angenommen werden.

NPC-Questmarker sind pro Betrachter verschieden und erscheinen innerhalb von 30 Blöcken. Der Kompass enthält Höhenhinweise. Während eines Bossleisten-Dialogs ist der Bereich exklusiv: Andere verwaltete Bossleisten werden ausgeblendet; die alte Option hideKeyedBossBarsDuringQuestDialogue wird entfernt. hideQuestScoreboardDuringQuestDialogue steuert die Seitenanzeige getrennt.

Bei Java zeigt Schleichen zunächst die vollständige aktuelle Dialogseite und blättert danach weiter. Der Dialog setzt für höchstens 30 Sekunden Langsamkeit III, friert den Spieler aber nicht ein. Nicht abgebrochener Schaden über null schließt Quest-Oberflächen und Bossleisten-Dialoge. Bedrock erhält diesen Dialog im Chat. Die Dialoggrafik benötigt die entsprechenden Ressourcenpaket-Dateien.

customRewards

Legt die Quest-Belohnungen fest.

Schlüssel	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

Benutzerdefinierte Quests erzeugen keine automatischen Belohnungseinträge. Ist customRewards leer, vergibt diese Tabelle weder Items noch Währung; separat konfigurierte Abschlussbefehle laufen trotzdem. Automatische Belohnungseinträge gelten für dynamische Quests.

Skalierbare Itembelohnungen verwenden das gewählte dynamische Dungeonlevel oder das aktuelle Kampflevel des Spielers, mit 10 % Wahrscheinlichkeit für ein zusätzliches Level. Feste und begrenzte Items behalten ihre Skalierungsregeln. questLevel bestimmt nicht das tatsächliche Itemlevel.

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.

Vorschau und Ausgabe würfeln getrennt. Eine angezeigte zufällige Belohnung oder ein Bonuslevel wird nicht für den Spieler reserviert.

---

questAcceptPermission

Verlangt vor Annahme einen EliteMobs-Abschlussmarker. Eine gewöhnliche Berechtigung mit demselben Namen erfüllt diese Prüfung nicht.

Schlüssel	Werte	Standard
questAcceptPermission	Zeichenkette	keine

Beispiel

questAcceptPermission: elitequest.my_permission

---

questAcceptPermissions

Verlangt alle aufgelisteten EliteMobs-Abschlussmarker. Ist zusätzlich questAcceptPermission gesetzt, muss auch dessen Marker vorliegen.

Schlüssel	Werte	Standard
questAcceptPermissions	String-Liste	keine

Beispiel

questAcceptPermissions: 
- elitequest.my_previous_quest_one.yml
- elitequest.my_previous_quest_two.yml

---

questLockoutPermission

Legt den Marker nach erfolgreichem Abschluss fest. Er kann Folgequests freischalten und verhindert bei questLockoutMinutes gleich null oder negativ eine Wiederholung. Ihn wegzulassen deaktiviert keine positive Zeitsperre.

Schlüssel	Werte	Standard
questLockoutPermission	Zeichenkette	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.

Schlüssel	Werte	Standard
questLockoutMinutes	Ganzzahl	-1 (Markerregel unten)

Es gibt zwei Sperrsysteme, und dieser Schlüssel entscheidet, welches davon verwendet wird:

• Jeder Wert über 0 nutzt 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, und questLockoutPermission wird für die Verfügbarkeitsprüfung ignoriert.
• 0 oder kleiner fällt auf den alten Marker questLockoutPermission zurück, der beim Abschluss dauerhaft vergeben wird. Ist auch kein questLockoutPermission gesetzt, bleibt die Quest wiederholbar.

Sind beide Felder gesetzt und die Dauer positiv, wird der Marker trotzdem vergeben, läuft aber nach dieser Dauer ab. Eine Folgequest, die ihn benötigt, muss vorher angenommen werden. Die Zeitsperre wird unter dem Quest-Dateinamen gespeichert und ist vom Voraussetzungsmarker getrennt.

Beispiel

questLockoutMinutes: 60

---

name

Legt den Quest-Namen fest. Unterstützt Farbcodes.

Schlüssel	Werte	Standard
name	Zeichenkette	leer

Beispiel

name: "&aMy Great Quest Name"

---

questLore

Legt die Lore der Quest fest, die im Ingame-Quest-Menü erscheint.

Schlüssel	Werte	Standard
questLore	String-Liste	keine

Beispiel

questLore:
- "Interesting lore sentence."
- "Yet another interesting lore sentence."

---

temporaryPermissions

Vergibt beim Annehmen echte Bukkit-Berechtigungen und wendet sie erneut an, wenn eine aktive Quest nach dem Anmelden wiederhergestellt wird. Abschluss oder Abbruch der Quest entfernt sie, und beim Abmelden werden sie bis zur nächsten Anmeldung freigegeben. Jede Quest vergibt ihre Knoten separat, sodass zwei aktive Quests einen Knoten teilen können: Endet eine davon, bleibt der von der anderen vergebene Knoten bestehen.

Setze für die normale Itemgenerierung die gleiche Berechtigung in der Itemdatei. Diese Prüfung erfasst nicht jede Ausgabeart.

Schlüssel	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.

Schlüssel	Werte	Standard
questAcceptDialog	String-Liste	keiner

Beispiel

questAcceptDialog:
- "My hero! You are so helpful!"
- "I wish you the best of luck!"

---

questCompleteMessage

Legt den Abgabedialog fest. Mit useQuestDialogueBossBars in Quests.yml kann er vor dem Öffnen des Abgabemenüs erscheinen; andernfalls erscheint er beim erfolgreichen Abschluss. Ein kürzlich gezeigter Abgabedialog wird beim Abschluss nicht wiederholt. Bedrock erhält Chattext. Den Dialog zu sehen beweist noch keine Belohnungsausgabe.

Schlüssel	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.

Schlüssel	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 für die Abgabe fest. Er darf vom Quest-Geber abweichen; ohne Angabe wird der ursprüngliche Geber verwendet. Ein separater Abgabe-NPC sollte interactionType: CUSTOM_QUEST_GIVER nutzen und darf eine leere Angebotsliste haben.

Schlüssel	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-Datei (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

Verwende auch für eine einzelne Quest eine YAML-Liste; der Einzelwert questFileName: my_quest.yml wird nicht als Angebotsliste geladen. Zum Öffnen wird interactionType: CUSTOM_QUEST_GIVER benötigt.

Weitere Informationen zur Konfiguration von NPCs findest du in der Dokumentation zur NPC-Erstellung.

---

trackable

Erlaubt manuelle und automatische Kompassverfolgung. false stoppt weder Zielfortschritt noch Belohnungen oder vorübergehende Fortschrittsanzeigen.

Schlüssel	Werte	Standard
trackable	Wahrheitswert	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.

Schlüssel	Werte	Standard
questLevel	Ganzzahl	0

Beispiel

questLevel: 10

---

questAcceptSound

Legt den Sound beim Annehmen fest. Minecraft-Sounds und Sounds aus einem Ressourcenpaket werden unterstützt. Ohne Angabe wird der globale Annahmesound aus SoundsConfig verwendet.

Schlüssel	Werte	Standard
questAcceptSound	Zeichenkette	keiner

Beispiel

questAcceptSound: entity.experience_orb.pickup

---

questCompleteSound

Legt den Sound beim Abschließen fest. Minecraft-Sounds und Sounds aus einem Ressourcenpaket werden unterstützt. Ohne Angabe wird der globale Abschlusssound aus SoundsConfig verwendet.

Schlüssel	Werte	Standard
questCompleteSound	Zeichenkette	keiner

Beispiel

questCompleteSound: entity.player.levelup

---

Übersetzungen

Die folgenden Felder unterstützen Lokalisierung für mehrsprachige Server:

• name
• questLore
• questAcceptDialog
• questCompleteMessage
• In jedem Eintrag von customObjectives: dialog, name, npcName, itemName und location

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 prüfen interne EliteMobs-Marker, keine gewöhnlichen Berechtigungen. Der Abschluss einer Quest mit passendem questLockoutPermission erzeugt den Marker. Eine gleichnamige LuckPerms-Berechtigung schaltet die Quest nicht frei. temporaryPermissions vergibt dagegen echte Berechtigungen, solange die Quest aktiv ist.

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

Quest 2 muss elitequest.quest_2.yml über ihr eigenes questLockoutPermission vergeben. Quest 3 verlangt diesen Marker dann über questAcceptPermission. Mit der standardmäßig nicht positiven Dauer vergibt Quest 3 beim Abschluss einen dauerhaften Marker und verhindert Wiederholungen. Eine bereits aktive Quest wird nicht allein dadurch zur zweiten unabhängigen Kopie, dass ein anderer NPC sie anbietet.

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

Damit die Quest-Annahme Zugang zur normalen Itemgenerierung gewährt, trage einen Knoten unter temporaryPermissions und denselben im Feld permission des Items ein.

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

Die Quest vergibt nun, solange sie aktiv ist, den bei der normalen Itemgenerierung geprüften Knoten und entfernt ihn bei Abschluss oder Abbruch.

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. Empfänger benötigen eine eigene passende aktive Quest und geladene Spielerdaten. Hat ihre Partie die Warte- oder Startphase verlassen, müssen sie zu deren ursprünglichen Teilnehmern gehören. Ihre Instanz wird nicht zusätzlich mit der Instanz des getöteten Gegners verglichen; Nähe in derselben Welt bleibt erforderlich.

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.

Funktionsweise

• Quest-Geber: Verwende interactionType: QUEST_GIVER. Die Angebote stammen aus dem dynamischen Pool, nicht aus questFileName.
• Stufe: Begrenze das Kampflevel auf 1–100, teile ganzzahlig durch fünf und begrenze die Stufe auf 1–20. Kampflevel 45 ergibt Stufe 9. Die Stufe steuert Vorlagen und Tötungsmenge; das Mindestlevel der Gegner verwendet das begrenzte Kampflevel des Spielers.
• Drei Vorlagen pro Stufe: Jede wählt einen Typ aus questEntityTypes in Quests.yml. Unbekannte Entitätstypen und Typen ohne EliteMobs-Mob-Eigenschaften werden mit einer Warnung übersprungen; eine Liste ohne verwendbare Einträge deaktiviert dynamische Quest-Angebote. Jede Vorlage wählt außerdem eine Menge zwischen tier + 1 und tier * 10, einschließlich beider Grenzen. Der passende Elite Mob muss mindestens das Ziellevel haben; gewöhnliche Minecraft-Mobs zählen nicht.
• Aktualisierung: Alle Vorlagen erneuern sich alle 1200 Ticks, etwa 60 Sekunden bei 20 TPS. Bestehende Quests und Fortschritt bleiben erhalten. Das Menü kombiniert sie mit den drei aktuellen Vorlagen und vermeidet doppelte Vorlagen-IDs; es enthält daher nicht zwingend drei Einträge.
• Dynamische Dungeons: Beim Betreten werden Mindestlevel der Gegner, angezeigtes Questlevel und Name bestehender dynamischer Quests an das gewählte, auf 1–100 begrenzte Level angepasst. Mengen und Fortschritt bleiben erhalten. Die Währungsbelohnung wird nicht neu berechnet.
• Belohnungen: Währung wird beim Erstellen des Angebots als floor(questLevel / 2 * targetKillCount) festgelegt. Das Item wird bei der Abgabe über das normale Beutesystem erzeugt, mit gewähltem dynamischem Dungeonlevel oder aktuellem Kampflevel, 10 % Chance auf ein Zusatzlevel und abschließender Begrenzung auf 1–100. Verfügbarkeit und Skalierungsregeln gelten weiterhin; die Vorschau würfelt separat.