Bosse erstellen
Benutzerdefinierte Bosse erstellen
Bevor du beginnst
Wohin kommen Boss-Dateien?
Boss-Dateien kommen in den Konfigurationsordner ~/plugins/EliteMobs/custombosses.
Es ist möglich, Unterordner zu erstellen, wie ~/plugins/EliteMobs/custombosses/mybosses. Dies wird empfohlen, um die Dinge organisiert zu halten.
Eine Datei definiert einen Boss, obwohl es möglich ist, denselben Boss mehrmals zu spawnen und sogar mehrere Spawn-Orte für dieselbe Boss-Datei festzulegen.
Verwende Nightbreak Forge, um Konfigurationen für benutzerdefinierte Bosse zu erstellen.
Kleinstmögliche Konfiguration
Die kleinstmögliche Konfigurationsdatei für einen benutzerdefinierten Boss ist:
Beachte, dass dies nur eine leere Datei ist. Dies spawnt trotzdem einen Zombie-Boss mit einem benutzerdefinierten Namen, da dies die Standardwerte sind. Alles auf dieser Seite ist optional!
Eine andere Boss-Datei wiederverwenden
Eine Boss-Datei kann mit extends auf einer anderen Boss-Datei aufbauen und dann nur das ändern, was sich unterscheidet:
extends: my_base_boss.yml
name: '&cEnraged Copy'
healthMultiplier: 3
Die Datei erbt jeden Wert von der Basis und überschreibt die Schlüssel, die sie selbst setzt. Verschachtelte Abschnitte wie patrol werden Schlüssel für Schlüssel zusammengeführt; eine Liste wie uniqueLootList ersetzt die Liste der Basis vollständig. Gib die Basis nur mit ihrem Dateinamen an, ohne Ordnerpfad. Sie muss eine andere Datei in custombosses sein, auch in einem Unterordner, und kann ihrerseits eine weitere Basis erweitern.
isEnabled, spawnLocation, spawnLocations, leashRadius, powers und eliteScript werden nie geerbt; setze sie daher in jeder Datei, die sie benötigt. Eine Basis mit isEnabled: false dient als Vorlage: Sie kann nicht selbst spawnen, aber Dateien, die sie erweitern, werden trotzdem geladen. EliteMobs schreibt keine Standardwerte in eine Datei, die extends verwendet, sodass sie so kurz bleibt, wie du sie geschrieben hast. Eine fehlende Basis, ein Pfad in extends oder eine Schleife aus extends-Verweisen deaktiviert die Datei mit einer Warnung in der Konsole.
Beispiel-Boss
Werfen wir einen Blick auf ein Beispiel dafür, wie eine Boss-Datei aussieht.
Beispiel
isEnabled: true
entityType: ZOMBIE
name: '&eTest boss'
level: dynamic
timeout: 10
isPersistent: false
healthMultiplier: 2.0
damageMultiplier: 0.5
helmet: GOLDEN_HELMET
chestplate: IRON_CHESTPLATE
leggings: LEATHER_LEGGINGS
boots: CHAINMAIL_BOOTS
mainHand: GOLDEN_AXE
offHand: SHIELD
isBaby: false
powers:
- invulnerability_knockback.lua
spawnMessage: A test boss has been spawned!
deathMessage: A test boss has been slain by $players!
escapeMessage: A test boss entity has escaped!
locationMessage: 'Test entity: $location'
uniqueLootList:
- magmaguys_toothpick.yml:1
dropsEliteMobsLoot: true
dropsVanillaLoot: true
trails:
- BARRIER
onDamageMessages:
- "I've hit you!"
onDamagedMessages:
- "I've been hit!"
Grundeinstellungen
isEnabled
Legt fest, ob der Boss aktiviert ist.
| Key | Werte | Standard |
|---|---|---|
isEnabled | true / false | true |
Beispiel
isEnabled: true
entityType
Legt den Entitätstyp des Bosses fest.
| Key | Werte | Standard |
|---|---|---|
entityType | Eine spawnbare Kreatur aus EntityType mit registrierten EliteMobs-Mob-Eigenschaften. Nicht unterstützte Typen deaktivieren die Boss-Konfiguration. | ZOMBIE |
Magma Cubes und Slimes
Da diese Entitätstypen Spieler nicht direkt angreifen, sondern durch Berührung Schaden verursachen, kann dies zu großen Schadensspitzen in kurzer Zeit führen. Aus diesem Grund empfehlen wir generell nicht, sie häufig als Elite-Mobs zu verwenden. Wenn du sie dennoch verwenden möchtest, empfehlen wir, damageMultiplier auf etwa 0.1 zu setzen.
Wir empfehlen außerdem, das folgende EliteScript zu verwenden, um zu verhindern, dass Magma Cubes oder Slimes Spieler dauerhaft betäuben:
eliteScript:
NerfDamage:
Events:
- ZoneEnterEvent
- ZoneLeaveEvent
Zone:
shape: SPHERE
radius: 1
Target:
targetType: SELF
Actions:
- action: SET_MOB_AI
Target:
targetType: SELF
bValue: false
duration: 10
Beispiel
entityType: ZOMBIE
name
Legt den Namen des Bosses fest.
| Key | Werte | Standard |
|---|---|---|
name | String, akzeptiert color codes und die unten aufgeführten Platzhalter | "Default Name" |
Beispiel
name: "$normalLevel &cCool boss!"
Wenn du das Boss-Level im Namensfeld einbinden möchtest, verwende einfach einen der folgenden Platzhalter.
| Platzhalter | Beschreibung | Beispiel | Ausgabe (für einen Boss der Stufe 10) |
|---|---|---|---|
$level | Wird durch das Level ersetzt | "$level Cool boss" | 10 Cool boss |
$normalLevel | Wird durch das Level ersetzt, für normale Mobs gedacht | "$normalLevel Cool boss" | [10] Cool boss |
$minibossLevel | Wird durch das Level ersetzt, für Minibosse gedacht | "$minibossLevel Cool boss" | 〖10〗 Cool boss |
$bossLevel | Wird durch das Level ersetzt, für Bosse gedacht | "$bossLevel Cool boss" | 『10』 Cool boss |
$reinforcementLevel | Wird durch das Level ersetzt, für Verstärkungen gedacht | "$reinforcementLevel Cool boss" | 〔10〕 Cool Boss |
$eventBossLevel | Wird durch das Level ersetzt, für Event-Bosse gedacht | "$eventBossLevel Cool boss" | 「10」 Cool boss |
Beispiel
name: "$normalLevel &cCool boss!"
level
Legt das Level des Bosses fest.
| Key | Werte | Standard |
|---|---|---|
level | Positive Integer-Zahlen oder dynamic | dynamic |
dynamic beginnt mit dem höchsten berechneten natürlichen Spawn-Level der Spieler derselben Welt innerhalb von 16 * (Server-Sichtweite + 2) Blöcken, mindestens aber 1. Registrierte dynamische Bosse werden alle 5 Sekunden neu bewertet; ihr Level kann sich nach dem Spawn ändern. Ein explizites Spawn-Level überschreibt dieses Verhalten. Verwende für regionale Begegnungen mit fester Schwierigkeit ein festes Level.
Beispiel
level: 1
scale
Legt die Skalierung (Größe) des Bosses fest.
| Key | Werte | Standard |
|---|---|---|
scale | Multiplier | 1.0 |
Bei der Skalierung steht 1.0 für die Standardgröße. Um die Entität größer zu machen, erhöhe den Wert (z. B. 1.2). Um die Entität kleiner zu machen, verringere den Wert (z. B. 0.8).
Beispiel
scale: 1.2
bossType
Klassifiziert den Boss für Systeme wie automatische Klassenbeute. Lebensanzeigen verwenden healthMultiplier und die Einstellungen in MobCombatSettings.yml statt dieser Bezeichnung.
| Key | Werte | Standard |
|---|---|---|
bossType | NORMAL, MINIBOSS, BOSS, REINFORCEMENT, EVENT | NORMAL |
Für automatische Klassenbeute wählt MINIBOSS den Miniboss-Rang, BOSS und EVENT den Boss-Rang und ein gewöhnlicher Boss den Rang eines normalen Gegners, sofern classLootRank dies nicht überschreibt.
REINFORCEMENT ist eine konfigurierte Klassifikation und wird nicht jeder Beschwörung automatisch zugewiesen. Die Laufzeitverwaltung beschworener Verstärkungen und Reittiere kontrolliert deren Belohnungsberechtigung separat.
Beispiel
bossType: MINIBOSS
silent
Legt fest, ob die Geräusche des Bosses stummgeschaltet werden sollen.
| Key | Werte | Standard |
|---|---|---|
silent | Boolean | false |
Bei true verstummen die nativen Minecraft-Geräusche der Entität. Separat abgespielte Skriptgeräusche und Bossmusik werden dadurch nicht gesteuert.
Beispiel
silent: true
healthMultiplier
Multipliziert die Lebenspunkte des Bosses. Lebensanzeigen berücksichtigen diesen Wert ebenfalls: Ein separater Bossbalken erfordert displayBossBarForHighMultiplier und einen Multiplikator über bossBarHealthMultiplierThreshold in MobCombatSettings.yml.
| Key | Werte | Standard |
|---|---|---|
healthMultiplier | Multiplier | 1.0 |
Die exponentiellen Basis-Lebenspunkte werden zuerst auf das Serverlimit begrenzt. Danach wendet EliteMobs healthMultiplier an, setzt ein Minimum von 1 LP und begrenzt das Ergebnis erneut auf settings.attribute.maxHealth.max aus spigot.yml. EliteMobs erhöht diesen Wert beim Start auf 2048, falls er niedriger ist, aber niemals darüber hinaus. Auf einem Standardserver sind 2048 daher die effektive Obergrenze.
Diese Grenzen beschreiben die Basisberechnung. Instanzbosse wenden anschließend bei mindestens zwei Teilnehmern den Gruppenmultiplikator 0.75 * playerCount an, ohne erneute Begrenzung durch das Plugin. Die folgende Tabelle garantiert daher weder die endgültigen Lebenspunkte in einer Instanz noch, dass der Server Werte oberhalb seiner Attributgrenze akzeptiert.
Die Basis-Lebenspunkte folgen der Formel 2.1875 × 2^(level / 5), verdoppeln sich also alle 5 Level. In Kombination mit der Begrenzung gibt es für jeden healthMultiplier ein Level, ab dem der Boss überhaupt keine Lebenspunkte mehr dazugewinnt, während sein Schaden weiter skaliert:
healthMultiplier | Lebenspunkte wachsen nicht mehr ab Level |
|---|---|
1.0 | 50 |
2.0 | 45 |
5.0 | 38 |
7.0 | 36 |
10.0 | 33 |
20.0 | 28 |
40.0 | 23 |
Oberhalb dieses Levels erhöht ein höheres konfiguriertes Level die tatsächlichen maximalen Lebenspunkte nicht mehr. Schaden hängt weiterhin vom Kampfsystem, relativen Fertigkeiten, Waffenwerten und Multiplikatoren ab; das Limit garantiert in keiner Richtung eine feste Trefferzahl. EliteMobs warnt, wenn die multiplizierten Lebenspunkte das Limit überschreiten, aber die vorherige Begrenzung der Basis-Lebenspunkte bleibt ohne Warnung. Ein Multiplikator unter 1 wird auf die bereits begrenzte Basis angewendet.
Wenn du wirklich mehr als 2048 LP benötigst, erhöhe settings.attribute.maxHealth.max in der spigot.yml selbst; die Begrenzung liest den aktuellen Wert des Servers aus und keine fest einprogrammierte Konstante.
Beispiel
healthMultiplier: 1.5
damageMultiplier
Legt den Schadensmultiplikator des Bosses fest.
| Key | Werte | Standard |
|---|---|---|
damageMultiplier | Multiplier | 1.0 |
Beispiel
damageMultiplier: 1.5
isBaby
Legt fest, ob der Boss die Baby-Variante des Mobs verwendet. Kann nur auf Mobs angewendet werden, die Baby-Varianten besitzen. Wenn du den Boss verkleiden möchtest, er aber auch in der Verkleidung ein Baby bleiben soll (stelle sicher, dass die Verkleidungs-Entität ebenfalls die Baby-Variante unterstützt), kannst du diese Einstellung verwenden:
disguise: HOGLIN:baby
| Key | Werte | Standard |
|---|---|---|
isBaby | true / false | false |
Beispiel
isBaby: true
helmet/chestplate/leggings/boots/mainHand/offHand
Legt Rüstung und gehaltene Gegenstände fest. Einige Entitätstypen und benutzerdefinierte Modelle können diese Plätze nicht anzeigen. Ausgerüstete Rüstung liefert im gewöhnlichen EliteMobs-Kampf keine Rüstungspunkte; gehaltene Gegenstände können aber native Angriffe beeinflussen, etwa wenn ein Skelett einen Bogen benutzt.
| Key | Werte | Standard |
|---|---|---|
helmet | Material, UUID | keiner |
chestplate | Material | keiner |
leggings | Material | keiner |
boots | Material | keiner |
mainHand | Material | keiner |
offHand | Material | keiner |
Verwende Materialnamen in Großbuchstaben. Diese Felder erzeugen Ausrüstung aus Materialien; sie laden keine .yml-Dateien benutzerdefinierter Gegenstände. Bei Gegenständen außer Leder kannst du einen ganzzahligen Custom-Model-Data-Wert als ITEM_MATERIAL:ID anhängen. DIAMOND_SWORD:1 wählt beispielsweise Custom Model Data 1 aus deinem Ressourcenpaket.
Hinweis 2: Dieses Feld erlaubt dir außerdem, benutzerdefinierte Lederfarben im Format ITEM_MATERIAL:CODE festzulegen, wobei der Code die hexadezimale Darstellung der Farbe ist. Beispiel: LEATHER_LEGGINGS:ffa500 würde eine orangefarbene Hose erzeugen. Du kannst Hex-Codes verwenden, entferne dazu einfach das # aus dem Hex-Code. Hex-Codes bekommst du hier.
Hinweis 3: Eine Spieler-UUID in Kleinbuchstaben mit Bindestrichen erzeugt einen Spielerkopf über Bukkits Offline-Profilabfrage. Der Spieler muss nicht online sein; das angezeigte Aussehen hängt davon ab, ob der Server das Profil auflösen kann.
Beispiel
helmet: 198c4123-cafc-45df-ba79-02a421eb8ce7
chestplate: DIAMOND_CHESTPLATE:1
leggings: LEATHER_LEGGINGS:ffa500
boots: NETHERITE_BOOTS
mainHand: DIAMOND_SWORD
offHand: SHIELD
powers
Legt die Kräfte fest, die der Boss besitzt.
| Key | Werte | Standard |
|---|---|---|
powers | Siehe die Liste unten | keiner |
Beispiel
powers:
- hyper_loot.lua
- attack_arrow.lua
- mycoolpower.lua
Hinweis: Auf dieser Seite findest du eine Liste der vorgefertigten Kräfte, die du verwenden kannst.
Hinweis: Kräfte können .yml-Dateien (EliteScript) oder .lua-Dateien (Lua-Skripte) sein. Beide Typen werden unterstützt und können in der powers-Liste beliebig gemischt werden. Fast alle vorgefertigten Kräfte sind inzwischen .lua.
.yml-Kraftnamen funktionieren weiterhinWenn eine .lua-Kraft mit demselben Basisnamen geladen ist, leitet EliteMobs eine .yml- oder .yaml-Anfrage automatisch dorthin. Beispielsweise wählt attack_arrow.yml die geladene attack_arrow.lua. Eine Datei auf dem Datenträger allein reicht nicht aus. Neue Konfigurationen sollten die .lua-Datei direkt benennen.
Fortgeschrittene Konfiguration: Verstärkungen spawnen
Verstärkungen gehören ebenfalls in die Kategorie powers und verwenden die folgenden Einstellungen:
Hinweis: Verstärkungen werden innerhalb des Abschnitts powers deiner Boss-Konfigurationsdatei konfiguriert, nicht als eigener Abschnitt.
Verstärkungs-Einstellungen
| Key | Beschreibung | Werte | Standard |
|---|---|---|---|
summonType | Was das Spawnen der Verstärkung auslöst. Pflichtfeld. | Siehe die Liste unten | keiner |
filename | Datei des zu beschwörenden Bosses. Außer bei Kristallen erforderlich. | String | keiner |
chance | Wahrscheinlichkeit einer gewöhnlichen Beschwörungsgruppe. Von GLOBAL und Kristallen ignoriert. Optional. | Double | 1.0 |
amount | Legt die Anzahl der zu spawnenden Verstärkungen fest. Optional. | Integer | 1 |
inheritAggro | Sorgt dafür, dass die Verstärkung die Aggro des Bosses übernimmt. Optional. | true / false | false |
spawnNearby | Spawnt Verstärkungen in einem Bereich von 30x30 Blöcken, ±15 auf X und Z, um den Spawnpunkt. Optional. | true / false | false |
inheritLevel | Sorgt dafür, dass die Verstärkung das Level des Bosses übernimmt. Optional | true / false | false |
customSpawn | Sorgt dafür, dass die Verstärkung über das System für benutzerdefinierte Spawns spawnt. Wird nur für summonType: GLOBAL verwendet | Dateiname eines benutzerdefinierten Spawns | keiner |
location | Relativer Spawnversatz. Optional. | x,y,z, immer relativ zum Boss. Bei regionalen Bossen relativ zu ihrem Spawnpunkt. | keiner |
lightningRod | Einstellung für summonType: ON_COMBAT_ENTER_PLACE_CRYSTAL. Die Enderkristalle erzeugen Blitze um sich herum. Optional. | true / false | false |
difficultyID | Beschränkt den Eintrag auf bestimmte Schwierigkeiten instanzierter Dungeons. Optional. | String oder Liste von Zeichenketten | keiner |
Summon-Typen legen die Bedingungen für das Spawnen der Verstärkungen fest. Es folgt eine Liste der gültigen Summon-Typen:
Summon-Typen
| Wert | Beschreibung |
|---|---|
ONCE | Versucht eine Beschwörungsgruppe bei gültigem Spielerschaden, bis ein Versuch als beschworen markiert wird. Nach einem fehlgeschlagenen Wahrscheinlichkeitswurf kann ein späterer Treffer erneut versuchen. |
ON_HIT | Versucht eine Beschwörungsgruppe, wenn ein Spieler den Boss verletzt. Erfordert aktive KI, ein nicht abgebrochenes Ereignis und mindestens 3 Schaden. |
ON_COMBAT_ENTER | Spawnt die Verstärkungen, wenn der Boss in den Kampf eintritt. |
ON_DEATH | Spawnt Verstärkungen, wenn der Boss stirbt. |
GLOBAL | Plant amount Beschwörungen über customSpawn direkt nach dem Boss-Spawn und alle 10 Sekunden, auch außerhalb des Kampfes. Fügt keine Beschwörungen mehr hinzu, sobald die registrierte Zahl 30 * Spieler in der Spawnwelt erreicht. Erfordert einen gültigen benutzerdefinierten Spawn. |
ON_COMBAT_ENTER_PLACE_CRYSTAL | Platziert beim Kampfeintritt einen Enderkristall am konfigurierten Versatz. Ignoriert amount und chance; für benutzerdefinierte Drachenkämpfe vorgesehen. |
ONCE erfordert dieselbe aktive KI und mindestens 3 Schaden wie ON_HIT. GLOBAL verwendet seine Spawn-Konfiguration statt der gewöhnlichen Felder location, spawnNearby, inheritLevel und inheritAggro. Das vollständige Verhalten steht unter Verstärkungen.
Beachte, dass es auch möglich ist, Verstärkungen über Elite Scripts zu spawnen, es gibt also noch weitere, stärker anpassbare Wege, Verstärkungen zu spawnen.
Beispiel
powers:
- summonType: ON_COMBAT_ENTER
filename: test_boss.yml
chance: 0.5
amount: 5
inheritAggro: true
spawnNearby: true
inheritLevel: true
location: 10,20,30
lightningRod: false
Experten-Konfiguration: Eigene Kräfte erstellen
Es ist möglich, eigene Kräfte zu erstellen, entweder in der Boss-Datei selbst oder als neue Konfigurationsdatei im Ordner powers. Mehr dazu erfährst du hier.
Hinweis: Du kannst Boss-Verhalten auch direkt in der Boss-Konfigurationsdatei über das Feld eliteScript definieren. Die vollständige Dokumentation zur Verwendung von Elite Scripts findest du im Kräfte-Leitfaden.
Als Alternative zu EliteScript kannst du Kräfte auch mit Lua-Skripten schreiben. Lua-Kräfte werden mit der Dateiendung .lua im Ordner powers abgelegt und in der powers-Liste über ihren Dateinamen referenziert. Weitere Informationen findest du im Leitfaden Lua Getting Started.
Kräfte anhand der Schwierigkeit instanzierter Dungeons einschränken
Instanzierte Dungeons können Schwierigkeitseinstellungen haben, und es ist möglich, eine bestimmte Kraft nur für bestimmte Schwierigkeitsgrade zu aktivieren.
Optionen zum Einschränken von Kräften
| Key | Beschreibung | Werte | Standard |
|---|---|---|---|
filename | Dateiname der Kraft. | String | keiner |
difficultyID | Eine Schwierigkeits-ID oder Liste, nach der numerischen oder benannten Konvention des Dungeons aufgelöst. | Zeichenkette, Zahl oder Liste | keiner |
Dies gilt nur für instanzierte Bosse: Bosse in instanzierten Dungeons sowie instanzierte Bosse, die ein anderes Plugin über die EliteMobs-API mit einer Schwierigkeit spawnt.
Beispiel
powers:
- filename: movement_speed.lua
difficultyID:
- myDifficultyName1
- myDifficultyName2
- myDifficultyName3
spawnMessage
Legt die Nachricht fest, die gesendet wird, wenn der Boss spawnt. Erfordert das Einrichten von announcementPriority.
| Key | Werte | Standard |
|---|---|---|
spawnMessage | Strings und color codes | keiner |
Beispiel
announcementPriority: 3
spawnMessage: I rise once more!
deathMessages
Legt die Nachrichten beim Tod des Bosses fest, sofern Angreifer registriert sind. doCustomEliteMobsDeathMessages in MobCombatSettings.yml (Standard true) muss aktiviert sein. Priorität 0 sendet sie privat an die Angreifer; positive Prioritäten verbreiten sie öffentlich.
| Key | Werte | Standard |
|---|---|---|
deathMessages | Strings, color codes und die Platzhalter unten | keiner |
Beispiel
announcementPriority: 3
deathMessages:
- '&e&l---------------------------------------------'
- '&4The Test Boss has been killed!'
- '&c&l 1st Damager: $damager1name &cwith $damager1damage damage!'
- '&6&l 2nd Damager: $damager2name &6with $damager2damage damage!'
- '&e&l 3rd Damager: $damager3name &ewith $damager3damage damage!'
- '&4Slayers: $players'
- '&e&l---------------------------------------------'
Todesnachrichten verwenden die folgenden Platzhalter:
Platzhalter
| Wert | Beschreibung |
|---|---|
$damager1name | Anzeigename des Spielers mit dem meisten Schaden |
$damager1Name | Benutzername des Spielers mit dem meisten Schaden |
$damager2name | Anzeigename des Spielers mit dem zweitmeisten Schaden |
$damager2Name | Benutzername des Spielers mit dem zweitmeisten Schaden |
$damager3name | Anzeigename des Spielers mit dem drittmeisten Schaden |
$damager3Name | Benutzername des Spielers mit dem drittmeisten Schaden |
$damager1damage | Die Schadensmenge des Spielers mit dem meisten Schaden |
$damager2damage | Die Schadensmenge des Spielers mit dem zweitmeisten Schaden |
$damager3damage | Die Schadensmenge des Spielers mit dem drittmeisten Schaden |
$players | Listet alle Angreifer nach Anzeigenamen auf |
$playersName | Listet alle Angreifer nach Benutzernamen auf |
deathMessage
Legt eine einzelne Todesnachricht fest. Sie wird bei leerem deathMessages verwendet und unterliegt denselben globalen Einstellungen und Prioritätsregeln. Die einzelne Nachricht unterstützt $players und $playersName, aber keine Platzhalter einzelner Angreifer.
| Key | Werte | Standard |
|---|---|---|
deathMessage | String, color codes, $players und $playersName | keiner |
Beispiel
announcementPriority: 3
deathMessage: '&4The Test Boss has been killed by $players!'
onKillMessage
Legt die Todesnachricht eines vom Boss getöteten Spielers fest. Sie verwendet die Verarbeitung des Spielertodes und erfordert kein announcementPriority.
| Key | Werte | Standard |
|---|---|---|
onKillMessage | Strings und color codes | keiner |
Platzhalter:
| Wert | Beschreibung |
|---|---|
$player | Der Anzeigename des getöteten Spielers |
$playerName | Der Benutzername des getöteten Spielers |
$entity | Name des Bosses |
Beispiel
announcementPriority: 3
onKillMessage: I win, you lose!
slimeSize
Legt die Größe des Slime-Bosses fest, funktioniert aber nur für Slimes und Magma Cubes.
| Key | Werte | Standard |
|---|---|---|
slimeSize | Integer | 4 |
Beispiel
slimeSize: 5
neutral
Verhindert, dass EliteMobs neutrale Entitätstypen wie Wölfe oder Eisengolems zum Anvisieren von Spielern zwingt. Verhindert auch den Start eines Mind-Verhaltensprogramms. Das native Verhalten gilt weiterhin; feindliche Entitätstypen werden dadurch nicht passiv.
| Key | Werte | Standard |
|---|---|---|
neutral | Boolean | false |
Beispiel
neutral: true
Erweiterte Einstellungen
timeout
Legt die Zeit in Minuten bis zum Despawn des benutzerdefinierten Bosses fest. 0 deaktiviert dieses Zeitlimit.
| Key | Werte | Standard |
|---|---|---|
timeout | Zeit (in Minuten) Integer | 0 |
Beispiel
timeout: 20
Legt fest, dass der Boss nach 20 Minuten entkommt.
isPersistent
Bewahrt den logischen Zustand des Bosses, um ihn beim erneuten Laden seines Chunks wiederherzustellen. Gewöhnliche Körper werden entfernt und neu gespawnt; ein persistenter nativer Mind-Körper kann stattdessen innerhalb derselben Serversitzung pausiert und wieder angebunden werden. Die Einstellung hält keine Chunks geladen und bewahrt nicht beliebige per Befehl gespawnte Bosse über Neustarts. Regionale Platzierungen und Respawnfristen werden separat gespeichert.
| Key | Werte | Standard |
|---|---|---|
isPersistent | true / false | false |
Beispiel
Beispiel:
isPersistent: true
damageModifiers
Legt Schadensmultiplikatoren nach dem Bukkit-Material der angreifenden Waffe fest. Registrierte Projektile verwenden das gespeicherte Material ihres Schützen. Benutzerdefinierter Schaden, der die gewöhnlichen Prüfungen umgeht, verwendet diesen Waffenmaterial-Modifikator nicht.
| Key | Werte | Standard |
|---|---|---|
damageModifiers | Material | keiner |
Beispiel
damageModifiers:
- material:DIAMOND_SWORD,multiplier:0.8
- material:TRIDENT,multiplier:2.0
In diesem Beispiel nehmen Bosse von Diamantschwertern nur 80 % Schaden (also 20 % weniger), von Dreizacken aber 200 % Schaden (also das 2-Fache).
normalizedCombat
Wählt den normalisierten Kampf und dessen Einstellungen normalizedDamageToEliteMultiplier / normalizedDamageToPlayerMultiplier. Aktuelle Formeln für Lebenspunkte und fertigkeitenbasierten Schaden stehen im Schadenssystem. normalizeRegionalBosses in MobCombatSettings.yml erzwingt die Normalisierung regionaler und instanzierter Bosse auch bei false in diesem Feld. Begegnungen mit Phasen übernehmen die Einstellung aus Phase 1.
| Key | Werte | Standard |
|---|---|---|
normalizedCombat | true / false | false |
Beispiel
Beispiel:
normalizedCombat: true
scaledCombat
Wählt den skalierten Kampf, der Schaden anhand des effektiven Fortschrittslevels des angreifenden oder verteidigenden Spielers berechnet und Spielerschaden auf die tatsächlichen Lebenspunkte des Bosses umrechnet. Der Boss behält gemeinsame Lebenspunkte und sein gespeichertes Level. Belohnungslevel und Beuteberechtigung werden separat geprüft; die Einstellung garantiert weder identische Schwierigkeit noch uneingeschränkte Beute für alle Spieler.
Skalierter Kampf ist in erster Linie für Event-Bosse in der Oberwelt und für benutzerdefinierte Bosse gedacht, die für Spieler jeden Levels zugänglich sein sollen. Für Dungeon-Inhalte mit fest vorgesehener Schwierigkeit verwende stattdessen normalizedCombat.
Wenn scaledCombat: true gesetzt ist, hat dies Vorrang, selbst wenn der Boss andernfalls normalisierten Kampf verwenden würde. Natürlich gespawnte Elite-Mobs verwenden standardmäßig skalierten Kampf (gesteuert über die Konfiguration useScaledCombatForNaturalElites in MobCombatSettings.yml).
Alle Details dazu, wie skalierter Kampf funktioniert, findest du auf der Seite Schadenssystem.
| Key | Werte | Standard |
|---|---|---|
scaledCombat | true / false | false |
Beispiel
scaledCombat: true
escapeMessage
Legt die Nachricht fest, die an die Spieler gesendet wird, wenn der Boss über den timeout-Mechanismus entkommt. Erfordert, dass announcementPriority konfiguriert ist.
| Key | Werte | Standard |
|---|---|---|
escapeMessage | String | keiner |
Beispiel
announcementPriority: 3
timeout: 60
escapeMessage: "Sayonara!"
locationMessage
Legt die Ortsnachricht der Verfolgungsleiste fest. Die Verfolgung erfordert announcementPriority von mindestens 1 und aktiviertes showCustomBossLocation in MobCombatSettings.yml. Die Nachricht ist optional: Fehlt sie oder ist sie leer, wird $name: $distance blocks away! verwendet.
| Key | Werte | Standard |
|---|---|---|
locationMessage | String, Color codes und die unten aufgeführten Platzhalter | $name: $distance blocks away!, wenn fehlend oder leer |
Platzhalter:
| Wert | Beschreibung |
|---|---|
$name | Anzeigename des benutzerdefinierten Bosses |
$distance | Wird durch die Entfernung des Spielers zum benutzerdefinierten Boss ersetzt. Dies ist die zu bevorzugende Option. |
$location | Wird durch die x-y-z-Koordinaten des benutzerdefinierten Bosses ersetzt |
Beispiel
announcementPriority: 3
locationMessage: "&4Cool boss: At $location only $distance blocks away!"
Dies würde etwa so aussehen: Cool boss: At 414,55,347 only 10 blocks away!
uniqueLootList
Legt die benutzerdefinierten Gegenstände fest, die der Boss fallen lässt.
| Key | Werte | Standard |
|---|---|---|
uniqueLootList | Liste | keiner |
Beute-Einträge in der benutzerdefinierten Beute folgen dem Format der Beutetabellen. Informationen dazu findest du hier! Beachte, dass einige ältere Dateien noch veraltete Beutetabellen verwenden könnten, die anders aussehen als im Beispiel.
Beispiel
uniqueLootList:
- filename: magmaguys_toothpick.yml
chance: 0.02
- minecraft:type=DIAMOND:amount=1:chance=0.9
- magmaguys_toothpick.yml:0.5:elitemobs.*
dropsEliteMobsLoot
Legt fest, ob der Boss EliteMobs-Beute fallen lässt, ausgenommen die Gegenstände in uniqueLootList. Beinhaltet Münzen.
| Key | Werte | Standard |
|---|---|---|
dropsEliteMobsLoot | true / false | true |
Für Verstärkungs-Mobs wird empfohlen, dies auf false zu setzen.
Beispiel
dropsEliteMobsLoot: true
dropsVanillaLoot
Legt fest, ob der benutzerdefinierte Boss die Vanilla-Beute fallen lässt, die üblicherweise mit seinem Vanilla-Mob-Typ verbunden ist.
| Key | Werte | Standard |
|---|---|---|
dropsVanillaLoot | true / false | true |
Beispiel
dropsVanillaLoot: true
dropsRandomLoot
Legt fest, ob der benutzerdefinierte Boss prozedural generierte Beute von EliteMobs fallen lässt. Elite-Münzen sind davon ausgenommen.
| Key | Werte | Standard |
|---|---|---|
dropsRandomLoot | true / false | true |
Beispiel
dropsRandomLoot: true
dropsSkillXP
Legt fest, ob der Boss beim Tod Skill-XP gewährt. Diese steigert Waffen- und Rüstungsfertigkeiten sowie ihre Boni. Die XP-Verarbeitung schließt Verstärkungen und Reittiere auch dann aus, wenn diese Einstellung true ist.
| Key | Werte | Standard |
|---|---|---|
dropsSkillXP | true / false | true |
Für Verstärkungs-Mobs oder Bosse, die nicht zum Skill-Fortschritt beitragen sollen, wird empfohlen, dies auf false zu setzen.
Beispiel
dropsSkillXP: false
Automatische Klassenbeute
classLoot aktiviert einen separaten Wurf für grundlegende Ausrüstung. Standardmäßig ist er aktiv, außer bei bossType: REINFORCEMENT. classLootDifficulty akzeptiert AUTO, NORMAL, HARD oder MYTHIC; classLootRank akzeptiert AUTO, TRASH, MINIBOSS oder BOSS. Beide verwenden standardmäßig AUTO. Ungültige Werte erzeugen eine Warnung und fallen auf AUTO zurück.
Definiere Klassenausrüstung als gewöhnliche Gegenstände mit itemType: CLASS_LOOT und referenziere sie in uniqueLootList. Sie nehmen an der Klassenauswahl statt an unabhängigen Würfen für einzigartige Beute teil. Das alte Boss-Feld classLootItems wird nicht gelesen. Die automatische Klassenbeute beschreibt Berechtigung, Limits, Familien, Profile und Schwierigkeitsauflösung.
trails
Legt die Spur fest, die der Boss beim Bewegen hinterlässt.
| Key | Werte | Standard |
|---|---|---|
trails | Partikel oder Gegenstands-Materialien | keiner |
Als Boss-Spuren funktionieren nur Partikel ohne zusätzliche Daten, also die einfachen Partikel der Liste der gültigen Partikel. Partikel mit Datenbedarf wie DUST und ITEM werden übersprungen. BLOCK und LAVA beenden die Verarbeitung der restlichen Liste; vermeide diese Einträge. Materialnamen erzeugen eine animierte Gegenstandsspur. Spuren laufen, solange der Boss gültig ist, auch im Stillstand.
Beispiel
trails:
- CLOUD
onDamageMessages
Wählt eine zufällige Zeile, die den Bossnamen vorübergehend ersetzt, wenn der Boss einem Spieler Schaden zufügt. Nach 80 Ticks wird der Name wiederhergestellt. Überlappende Treffer können die Zeile ersetzen oder den Namen früher wiederherstellen, als der Timer der letzten Zeile vorsieht.
| Key | Werte | Standard |
|---|---|---|
onDamageMessages | Liste | keiner |
Beispiel
onDamageMessages:
- "I hit you!"
- "Haha I hit you!"
onDamagedMessages
Wählt eine zufällige Zeile, die bei einem EliteMobs-Schadensereignis vorübergehend den Bossnamen ersetzt. Dies ist nicht auf Spielerschaden beschränkt. Nach 80 Ticks wird der Name wiederhergestellt. Überlappende Ereignisse können die Zeile ersetzen oder den Namen früher wiederherstellen, als der Timer der letzten Zeile vorsieht.
| Key | Werte | Standard |
|---|---|---|
onDamagedMessages | Liste | keiner |
Beispiel
onDamagedMessages:
- "You hit me!"
- "I've been hit!"
mountedEntity
Legt die Entität fest, die der Boss besteigt und reitet.
| Key | Werte | Standard |
|---|---|---|
mountedEntity | Dateiname des zu reitenden Bosses oder Entitätstyp | keiner |
Versuche nicht, den Boss sich selbst reiten zu lassen.
Beispiel
mountedEntity: wild_wolf.yml
Hinweis: Regionale Bosse teilen sich ihre Leine mit der Entität, die sie reiten – beide werden also zum Spawn-Ort zurückgezogen, wenn sie die von ihrer Leine erlaubte Entfernung überschreiten.
announcementPriority
Legt die Prioritätsstufe für Ankündigungen fest. Niedrigere Prioritäten bedeuten, dass keine Ankündigungen gemacht werden; höhere Prioritäten können nicht nur im Chat, sondern bei entsprechender Konfiguration auch auf Discord ankündigen.
| Key | Werte | Standard |
|---|---|---|
announcementPriority | Integer | 0 |
Hinweis: Fehlt der Schlüssel in einer Boss-Datei mit Ankündigungstext, also locationMessage, spawnMessage, deathMessage, escapeMessage oder einer nicht leeren Liste deathMessages, schreibt EliteMobs beim Laden announcementPriority: 0 in die Datei. Damit ist die Einstellung sichtbar und leicht anzuheben. Der Boss bleibt bei Priorität 0, bis du sie änderst.
Hier ist eine Liste dessen, was die Prioritäten bewirken:
| Wert | Beschreibung |
|---|---|
0 | Standard. Keine Spawn- oder Fluchtankündigungen und keine Verfolgung; konfigurierter Todestext kann weiterhin privat an Angreifer gesendet werden. |
1 | Erlaubt konfigurierte Spawn-, Todes- und Fluchtnachrichten im Chat. Verfolgung über /em ist bei aktiviertem showCustomBossLocation verfügbar; locationMessage ist optional. |
2 | Identisch mit 1 für benutzerdefinierte Bosse — es gibt keinen eigenen Code-Pfad für Priorität 2. (Benutzerdefinierte Events behandeln 2 hingegen anders; siehe Announcement Priority System.) |
3 | Zusätzlich zu den Dingen aus 1 werden Broadcast-Nachrichten bei entsprechender Konfiguration auf Discord gespiegelt. Informationen zur Discord-Konfiguration findest du hier. |
Hier ist ein Beispiel für einen Boss, der verfolgbar ist und Spawn-/Todes-/Fluchtnachrichten im Chat und auf Discord senden kann:
Beispiel
announcementPriority: 3
Hinweis: Konfiguriere spawnMessage, deathMessage/deathMessages und escapeMessage für die jeweiligen Chat- und Discord-Ankündigungen. Die Verfolgung hat eine Standard-Ortsnachricht; setze locationMessage nur zur Anpassung.
followDistance
Legt die Entfernung fest, ab der Bosse Aggro aufbauen und in den Kampf eintreten. Gemessen vom Mob selbst aus.
| Key | Werte | Standard |
|---|---|---|
followDistance | Integer | 0 |
Eine positive followDistance überschreibt das native Attribut für die Verfolgungsreichweite; 0 lässt es unverändert.
Hinweis 1: Nicht wachsame regionale Bosse teilen ihre aktuelle Reichweite durch 3, wenn sie beim Spawn oder beim Kampfende verlangsamt werden. Beim Kampfeintritt wird die gespeicherte Reichweite wiederhergestellt. Das verhindert zu frühe Aggro aus großer Entfernung und Probleme mit der Leine.
Hinweis 2: Je höher die followDistance, desto stärker belastet der Boss die CPU des Servers. Verwende dies vorsichtig und verantwortungsvoll!
Beispiel
followDistance: 30
Legt einen Bereich von 30 Blöcken fest: Kommt ein Spieler dem Boss auf diese Entfernung nahe, beginnt dieser, den Spieler zu verfolgen bzw. anzugreifen.
onDeathCommands
Legt die Liste der Befehle fest, die beim Tod des benutzerdefinierten Bosses ausgeführt werden.
| Key | Werte | Standard |
|---|---|---|
onDeathCommands | Liste | keiner |
Die Befehle laufen über die Konsole. Ein Befehl mit $chance=x$ und $players würfelt für jeden Angreifer separat. Die Liste unterstützt diese Platzhalter:
| Wert | Beschreibung |
|---|---|
$level | Platzhalter für das Boss-Level. |
$name | Platzhalter für den Boss-Namen. |
$chance=x$ | Sorgt dafür, dass ein Befehl nur mit einer gewissen Wahrscheinlichkeit ausgeführt wird. |
$players | Sorgt dafür, dass der Befehl einmal für jeden Spieler in der Schadensliste ausgeführt wird, und wird jedes Mal durch den Benutzernamen eines anderen Spielers aus dieser Liste ersetzt. |
$locationWorldName | Weltname zum Todeszeitpunkt. |
$locationX | X-Koordinate des Bosses zum Zeitpunkt des Todes. |
$locationY | Y-Koordinate des Bosses zum Zeitpunkt des Todes. |
$locationZ | Z-Koordinate des Bosses zum Zeitpunkt des Todes. |
$damager1name | Benutzername des Spielers mit dem meisten Schaden |
$damager2name | Benutzername des Spielers mit dem zweitmeisten Schaden |
$damager3name | Benutzername des Spielers mit dem drittmeisten Schaden |
Sieh dir das Beispiel unten an, um besser zu verstehen, wie diese funktionieren.
Beispiel
onDeathCommands:
- "say $players has killed $name! That was level $level!"
- "$chance=0.5$ say What a kill!"
Wenn Player1, Player2 und Player3 dem Boss alle Schaden zugefügt haben, bevor er getötet wurde, sieht die Befehlsausgabe in der Konsole so aus:
say Player1 has killed CustomBossName! That was level X!
say Player2 has killed CustomBossName! That was level X!
say Player3 has killed CustomBossName! That was level X!
Zusätzlich besteht eine Chance von 50 %, dass auch Folgendes ausgegeben wird:
say What a kill!
onSpawnCommands
Legt die Liste der Befehle fest, die beim Spawnen des Bosses ausgeführt werden.
| Key | Werte | Standard |
|---|---|---|
onSpawnCommands | Liste | keiner |
Die Befehle laufen über die Konsole und unterstützen $chance=x$. Dieses Ereignis liefert keine Boss-, Orts- oder Spielerplatzhalter aus onDeathCommands.
Beispiel
onSpawnCommands:
- say Boss has spawned!
onCombatEnterCommands
Legt die Liste der Befehle fest, die ausgeführt werden, wenn der Boss in den Kampf eintritt.
| Key | Werte | Standard |
|---|---|---|
onCombatEnterCommands | Liste | keiner |
Die Befehle laufen über die Konsole und unterstützen $chance=x$. Dieses Ereignis liefert keine Boss-, Orts- oder Spielerplatzhalter aus onDeathCommands.
Beispiel
onCombatEnterCommands:
- say Boss has entered combat!
onCombatLeaveCommands
Legt die Liste der Befehle fest, die ausgeführt werden, wenn der Boss den Kampf verlässt.
| Key | Werte | Standard |
|---|---|---|
onCombatLeaveCommands | Liste | keiner |
Die Befehle laufen über die Konsole und unterstützen $chance=x$. Dieses Ereignis liefert keine Boss-, Orts- oder Spielerplatzhalter aus onDeathCommands.
Beispiel
onCombatLeaveCommands:
- say Boss has left combat!
disguise
Legt die LibsDisguises-Verkleidung fest, sofern dieses Plugin aktiviert ist. Mehr Infos hier.
| Key | Werte | Standard |
|---|---|---|
disguise | String | keiner |
customDisguiseData | String | keiner |
Beispiel-Verkleidung
disguise: CHICKEN
Beispiel für eine benutzerdefinierte Verkleidung
disguise: custom:the_beast_sanctuary_beast
customDisguiseData: player the_beast_sanctuary_beast setskin {"id":"44e6d42b-bd8d-4e48-873b-fae7afed36e4","name":"Unknown","properties":[{"name":"textures","value":"ewogICJ0aW1lc3RhbXAiIDogMTY2NjcwNjYwODA1MCwKICAicHJvZmlsZUlkIiA6ICI3MmY5MTdjNWQyNDU0OTk0YjlmYzQ1YjVhM2YyMjIzMCIsCiAgInByb2ZpbGVOYW1lIiA6ICJUaGF0X0d1eV9Jc19NZSIsCiAgInNpZ25hdHVyZVJlcXVpcmVkIiA6IHRydWUsCiAgInRleHR1cmVzIiA6IHsKICAgICJTS0lOIiA6IHsKICAgICAgInVybCIgOiAiaHR0cDovL3RleHR1cmVzLm1pbmVjcmFmdC5uZXQvdGV4dHVyZS82YmYyMTY4NmM1MGQ1ODhmZmExMDZhZDdjNmViZTk1ZWZiMjE2NDU5ODRjZDFjZWYwODkzNDc4NzMzNmI2YTI3IiwKICAgICAgIm1ldGFkYXRhIiA6IHsKICAgICAgICAibW9kZWwiIDogInNsaW0iCiAgICAgIH0KICAgIH0KICB9Cn0=","signature":"jSsQvpUeWVtyqjtnydPadormkrZLVihetiX4dFQb3+BF/1x6wOgsNKRnnwj6J1mfu2im79LYEJbL+fQ9p1SJIW1uZ6hV7vPSAGUopyXGHNibNXorfV/dGjM77S0t86Jls50XWgJAnLn5RdhQcHahDAHHZ8to6K0HW5gvKKSalR5X/myaiV0E5ujJ+LUFWIiuDmtsmyxTX1zsohyYrVMo/4sD0DpBN+as95wO476gLb5fDTDV569QwExlDOt60W8qSzPw6ncYsOKJIiRE3EddspUm3/NrfDiKApUh8UbzVtwu1XlVAxWNgYN3PkqhWKuE4kvORQuoSJzOgSHkiqdXsQOED2HXfOKdfsnpZUwjepIU5A+/mu0gc3mPQPToKSss2bC1nXn//0bOZZSuQRgTS6PkKDHIQ1nClSZQZlJIsiLmaaN2k1tIHTIlDquKN6G1Ta9c3t6G5kugjqRo78ebbt7l3e0Z3BcdOkuO2WbvBjIg5Uiqyf+cYDZedJ+OEOqL/U6VVlsmbw0rd5deHrbnPn9cRzmWGjrXnxIlAszl+0Uqabj/BrkWcbBCwZJEPaV1hHpC4nJX1m5xvKZHB2Bw0AYWaQ3f3tRBbCA/xqwCS0Px1QohzV0nvtiMbjB38ziT1M5DgLtAVLcHPio7THZMxXAi4IjEIMac9ODbh5OxthA="}],"legacy":false}
Legt eine benutzerdefinierte Verkleidung von Skindex fest. Auf dieser Seite erfährst du, wie du diese Daten korrekt formatierst.
customModel
Legt das zu verwendende benutzerdefinierte Modell fest, sofern du ein benutzerdefiniertes Modell und die Plugins FreeMinecraftModels oder ModelEngine hast. Mehr Infos zum Erstellen und Verwenden benutzerdefinierter Modelle findest du hier.
| Key | Werte | Standard |
|---|---|---|
customModel | String | keiner |
Beispiel
customModel: your_model
customModelMountPointID
Legt die Mount-Point-ID für benutzerdefinierte Modelle fest, wenn der Boss eine andere Entität reitet oder von ihr geritten wird.
| Key | Werte | Standard |
|---|---|---|
customModelMountPointID | String | keiner |
Beispiel
customModelMountPointID: your_mount_point_id
frozen
Setzt das Bewegungsgeschwindigkeitsattribut auf null und löscht die Geschwindigkeit sofort sowie einen Tick nach einem EliteMobs-Schadensereignis. Eingefrorene Bosse behalten ihre KI und können angreifen. Die Einstellung stoppt weder Skripte noch Teleports noch jede entitätsspezifische Bewegungsmechanik.
| Key | Werte | Standard |
|---|---|---|
frozen | true / false | false |
Beispiel
frozen: true
ai
Legt fest, ob der Boss KI aktiviert hat. Wenn dies auf false gesetzt ist, bewegt sich der Boss nicht von selbst und greift nicht von selbst an. Das ist nützlich für Bosse, die vollständig über Elite Scripts gesteuert werden.
| Key | Werte | Standard |
|---|---|---|
ai | true / false | true |
Beispiel
ai: false
behavior
behavior wählt ein wiederverwendbares Lua-Mind-Programm aus plugins/EliteMobs/behaviors/. Beispiel:
entityType: ZOMBIE
ai: true
behavior: basic_melee.lua
Das mitgelieferte basic_melee.lua kombiniert Module für Zielwahl, Verfolgung, Nahkampf und Umherwandern aus behaviors/modules/. Bearbeite oder kopiere dort ein Verhaltensprogramm. Es ist keine Kraftdatei und gehört nicht nach powers/.
Ohne behavior verwendet ein benutzerdefinierter Boss die Mob-Einstellung seines Entitätstyps. behavior: native wählt explizit die native KI. ai: false und neutrale Bosse starten kein Verhaltensprogramm. Der gewöhnliche Boss-Lader verwaltet weiterhin Spawn, Ausrüstung, Kräfte, Persistenz und Aufräumen.
Programme erfordern den nativen Mind-Dienst auf einer unterstützten Serverversion. Eine unbekannte oder ungültige Datei ist ein Konfigurationsfehler und kein Auftrag, stillschweigend eine andere KI zu wählen. Programm-IDs müssen den Namensraum elitemobs: verwenden; Unterordnerreferenzen nutzen Schrägstriche /. Die API steht in der Mind-Kontextreferenz.
alwaysShowName
Hält den Bossnamen außerhalb des Kampfes sichtbar. Die globale Einstellung alwaysShowEliteMobNameTags kann dies ebenfalls aktivieren. Aktuelles FreeMinecraftModels verwendet einen vorhandenen tag_-Knochen wie tag_head zur Namensplatzierung und setzt den Namen sonst über die Modell-Hitbox. Ältere FMM-Versionen können einen definierten Anker benötigen. Details stehen unter benutzerdefinierte Modelle.
| Key | Werte | Standard |
|---|---|---|
alwaysShowName | true / false | false |
Beispiel
alwaysShowName: true
reinforcement
Markiert die Bossdefinition als Verstärkung. Dadurch entfallen die Initialisierung gewöhnlicher regionaler Platzierungen und automatische Klassenbeute. Instanzierte Platzierungen haben eine eigene Registrierung. Die Einstellung beschwört keinen Boss und weist keinen Beschwörer zu; die Laufzeitverwaltung von Verstärkungen und Reittieren kontrolliert weitere Belohnungsausschlüsse separat.
| Key | Werte | Standard |
|---|---|---|
reinforcement | true / false | false |
Beispiel
reinforcement: true
song
Legt die Musik fest, die der Boss Spielern in seiner Nähe nach dem Spawn anbietet. Das Ressourcenpaket muss den Soundschlüssel und dessen .ogg-Audio definieren.
| Key | Werte | Standard |
|---|---|---|
song | String | keiner |
Setze eine positive followDistance für die Startreichweite. Alle 10 Ticks prüft der Boss Spieler seiner Welt innerhalb dieser konfigurierten Entfernung. Die Musik läuft anschließend weiter, solange der Spieler online, in derselben Welt und innerhalb des 1,5-Fachen der gespeicherten Laufzeit-Verfolgungsreichweite des Bosses ist. Das Entfernen des Bosses stoppt sie. Bossmusik hat Vorrang vor Dungeon-Ambiente; ein Spieler hört jeweils nur einen verwalteten Titel.
Verwende name=SOUND_KEY length=MILLISECONDS mit einem Leerzeichen zwischen den Feldern. Die Dauer ist eine ganze Zahl in Millisekunden, wird abgerundet in Ticks umgerechnet und mit mindestens einem Tick Verzögerung geplant. Die Wiedergabe nutzt die Kategorie MUSIC mit Lautstärke 1 und Tonhöhe 1.
Beispiel
Es gibt zwei Wege, Musikstücke einzurichten. Hier ist der erste:
song: name=elitemobs:ice_queen.idle length=76370
Dies spielt das Musikstück ice_queen.idle 76370 Millisekunden lang ab und wiederholt es dann in einer Schleife. Beachte, dass der Speicherort des Musikstücks vom Ressourcenpaket bestimmt wird.
Hier ist der zweite Weg, Musikstücke einzurichten:
song: name=elitemobs:ice_queen.end_transition length=14328->name=elitemobs:ice_queen.end_loop length=28657
Dies spielt das Musikstück ice_queen.end_transition 14328 Millisekunden lang ab, wechselt dann für 28657 Millisekunden zu ice_queen.end_loop und wiederholt end_loop in einer Schleife.
Dadurch können Bosse ein „Intro“- oder „Übergangs“-Stück und danach einen sich wiederholenden Haupttitel haben.
cullReinforcements
Steuert, ob registrierte Verstärkungen einschließlich GLOBAL beim Entfernen des Bosses beseitigt werden. Kampfende und vollständige Heilung entfernen gewöhnliche registrierte Verstärkungen separat. false garantiert daher nicht, dass alle Beschwörungen erhalten bleiben.
| Key | Werte | Standard |
|---|---|---|
cullReinforcements | true / false | true |
Beispiel
cullReinforcements: true
movementSpeedAttribute
Legt die Bewegungsgeschwindigkeit des Bosses fest.
Hinweis: Alles über 0.36 ist möglicherweise zu schnell.
| Key | Werte | Standard |
|---|---|---|
movementSpeedAttribute | Double | keiner |
Beispiel
movementSpeedAttribute: 0.3
patrol
Fügt dem Custom Boss eine native, automatisch berechnete Route hinzu. Knoten sind Versätze vom festgelegten Spawnpunkt des Bosses oder, mit patrol.relative: false, exakte Koordinaten in seiner Welt. Mit patrol.startNodeWaitSeconds rastet der Boss einmal pro Runde am ersten Knoten. Lange Segmente werden ohne erzwungenes Chunk-Laden geteilt; im Kampf pausiert die Patrouille. Der Boss benötigt ai: true, positive Bewegungsgeschwindigkeit und darf kein Passagier sein. NPC- und Boss-Patrouillen beschreibt Schema, Editor, Persistenz und Lua-Steuerung.
Boss-Phasen
Bosse können Phasen haben, die wechseln, wenn der Boss einen bestimmten Prozentsatz an Lebenspunkten erreicht. Wenn das passiert, beginnt der Boss, eine andere Konfigurationsdatei zu verwenden – das heißt, alles am Boss kann sich ändern, einschließlich Dingen wie dem Entitätstyp.
Um mehr über Boss-Phasen zu erfahren, klicke hier.
| Key | Beschreibung | Werte | Standard |
|---|---|---|---|
phases | Legt die Phasen fest, die der Boss haben wird. Pflichtfeld | Liste | keiner |
phaseSpawnLocation | Legt fest, wo der Phasen-Boss spawnt. Optional | String | keiner |
Beispiel
Für dieses Beispiel zeigen wir drei verschiedene Konfigurationsdateien.
Erste Boss-Konfigurationsdatei: phase_1_boss.yml
name: "Phase 1"
entityType: ZOMBIE
phases:
- phase_2_boss.yml:0.60
- phase_3_boss.yml:0.30
Zweite Boss-Konfigurationsdatei: phase_2_boss.yml
name: "Phase 2"
entityType: SKELETON
Dritte Boss-Konfigurationsdatei: phase_3_boss.yml
name: "Phase 3"
phaseSpawnLocation: same_as_boss,10,64,100,0,0
entityType: RAVAGER
Dieser Boss würde bei 60 % Lebenspunkten zur Konfigurationsdatei phase_2_boss.yml wechseln und bei 30 % Lebenspunkten zur Konfigurationsdatei phase_3_boss.yml, und zwar in derselben Welt wie Phase 2 und an den Koordinaten x=10, y=64 und z=100. Entitätstyp und Name des Bosses würden sich ebenfalls ändern.
Das Format für einen Eintrag ist filename:healthPercentage, wobei der Prozentsatz ein Anteil von mindestens 0 und kleiner als 1 ist. Ein Eintrag mit anderem Format, ein Anteil außerhalb dieses Bereichs oder eine fehlende Boss-Datei verhindert das Spawnen des Bosses.
phaseSpawnLocation ist optional; wenn es nicht gesetzt ist, wechselt der Boss die Phase dort, wo er gerade steht.
Beim Entwerfen eines Phasen-Bosses ist es wichtig, Folgendes zu wissen:
- Die Konfigurationsdatei der ersten Phase legt alle Phasen des Bosses fest.
- Bedrohung / gezählter Schaden bleibt für Spieler über die Phasen hinweg erhalten.
- Der Treffer, der den Schwellenwert überschreitet, wird abgebrochen. Die nächste Phase startet mit dem konfigurierten Gesundheitsprozentsatz.
healthMultiplierverändert die absoluten LP an dieser Schwelle. Überschüssiger Schaden wird nicht in die nächste Form übertragen. - Nicht instanzierte Phasenbosse kehren bei vollständiger Heilung zu Phase 1 zurück, auch durch konfigurierte Regeneration nach dem Kampf. Instanzierte Bosse überspringen diese Rücksetzung.
- Phasen-Bosse, die zugleich regionale Bosse sind, teilen sich über alle Phasen hinweg denselben Leinenradius und denselben Timeout-Mechanismus und respawnen nach Ablauf des Timers als Boss der Phase 1.
- Die Konfigurationsdatei der letzten Phase legt die Beute des Bosses fest.
- Phasen können nicht übersprungen werden – überschüssiger Schaden lässt den Boss trotzdem bei dem festgelegten Prozentsatz die Phase wechseln.
- Ein Phasenwechsel entfernt das vorherige Reittier. Die neue Phase kann ein eigenes definieren.
- Phasenwechsel und Rücksetzungen bei vollständiger Heilung verwenden einen stillen Spawn und senden keine gewöhnliche Spawn-Ankündigung.
Regionale Bosse
Regionale Bosse sind ein besonderer Typ benutzerdefinierter Bosse, die an einem konkret konfigurierten Ort spawnen und dort nach einer Verzögerung wieder respawnen können. Zusätzlich können sie Leinen haben, die dafür sorgen, dass sie in einem bestimmten Bereich bleiben, sowie weitere Funktionen.
Diese werden für sämtliche Dungeon-Inhalte verwendet. Um mehr über regionale Bosse zu erfahren, klicke hier.
| Key | Beschreibung | Werte | Standard |
|---|---|---|---|
isRegionalBoss | Legt fest, ob der Boss regional ist. Sollte true sein, wenn du einen regionalen Boss möchtest. | true / false | false |
spawnLocations | Legt die Spawn-Orte des Bosses fest. | Füge diese über den Befehl /em place boss [filename.yml] hinzu! | keiner |
spawnCooldown | Legt die Respawn-Abklingzeit des Bosses in Minuten fest. | Integer | 0 |
leashRadius | Legt die Entfernung fest, die der Boss von seinem Spawn-Punkt zurücklegen kann, bevor er zurückgezogen wird. Gemessen vom Spawn aus. | Double | keiner |
onSpawnBlockStates | Legt die Blöcke fest, die der Boss beim Spawnen verändert. | Siehe die Befehle unten | keiner |
onRemoveBlockStates | Setzt gespeicherte Blöcke beim Tod, Töten per Befehl oder Phasenfortschritt; nicht bei Zeitablauf, vollständiger Heilung mit Rücksetzung, Reload oder Shutdown. | Siehe die Befehle unten | keiner |
Wie angegeben, können regionale Bosse onSpawnBlockStates und onRemoveBlockStates haben.
Dies ist eine sehr nützliche Funktion, um Kampfarenen während des Kampfes zu verändern, besonders in Kombination mit Phasenwechseln, da es dadurch möglich wird, Kampfarenen über wechselnde Blockzustände zu öffnen und zu schließen.
Das Format dafür ist zu komplex, um es von Hand zu schreiben, daher gibt es einige Befehle, die dir beim Einrichten helfen:
| Befehl | Beschreibung |
|---|---|
| /em transitiveBlocks register [regional_boss_file.yml] [ON_SPAWN/ON_REMOVE] | Beginnt mit dem Registrieren manueller Blockauswahlen für die Blockzustände beim Spawnen oder Entfernen. |
| /em transitiveBlocks edit [regional_boss_file.yml] [ON_SPAWN/ON_REMOVE] | Bearbeitet die Blockzustände beim Spawnen oder Entfernen. |
| /em transitiveBlocks registerArea [regional_boss_file.yml] [ON_SPAWN/ON_REMOVE] | Erlaubt Admins, große Blockbereiche auszuwählen, um sie als Zustände zu speichern. |
| /em transitiveBlocks editArea [regional_boss_file.yml] [ON_SPAWN/ON_REMOVE] | Erlaubt Admins, große Blockbereiche zu bearbeiten, um sie als Zustände zu speichern. |
Beispielanwendung:
Angenommen, du möchtest einen Kampf gestalten, bei dem ein Boss in einer Arena mit einer offenen Tür spawnt, und du möchtest, dass sich die Tür beim Kampfbeginn schließt und nach Kampfende wieder öffnet.
Dafür brauchst du zwei Boss-Phasen und musst drei verschiedene Sätze von Blockzuständen registrieren. Für dieses Beispiel nenne ich diese Phasen phase_1_boss.yml und phase_2_boss.yml.
- Verwende
/em transitiveBlocks register phase_1_boss.yml ON_SPAWNoder/em transitiveBlocks edit phase_1_boss.yml ON_SPAWN, um die Türblöcke in ihrem geöffneten Zustand zu registrieren.
Das bedeutet, die Luftblöcke zu registrieren. Hier wird die Bereichsauswahl empfohlen.
Dies ist nötig, damit die Tür beim Spawnen des Bosses offen ist und Spieler garantiert einen Weg hinein haben.
- Verwende
/em transitiveBlocks register phase_2_boss.yml ON_SPAWNoder/em transitiveBlocks edit phase_2_boss.yml ON_SPAWN, um die Türblöcke in ihrem geschlossenen Zustand zu registrieren.
Das bedeutet, die massiven Blöcke der Tür zu registrieren, die den Spieler am Verlassen hindern würden.
Dies ist nötig, damit die Tür massiv wird, wenn der Boss in Phase 2 eintritt, und Spieler nicht mehr hinausgehen können.
- Verwende
/em transitiveBlocks register phase_2_boss.yml ON_REMOVEoder/em transitiveBlocks edit phase_2_boss.yml ON_REMOVE, um die Türblöcke in ihrem geöffneten Zustand zu registrieren.
Das bedeutet, dieselben Blöcke wie im ersten Schritt erneut zu registrieren (die Luftblöcke).
Dies ist nötig, damit sich die Tür öffnet, wenn der Boss stirbt, und Spieler die Arena verlassen können.
alert
Legt fest, ob der Boss wachsam ist. Standardmäßig sind regionale Bosse außerhalb des Kampfes verlangsamt und haben eine geringere Aggro-Reichweite. Diese Einstellung verhindert, dass regionale Bosse außerhalb des Kampfes verlangsamt werden und eine geringere Aggro-Reichweite haben, sodass sie sich innerhalb und außerhalb des Kampfes immer gleich verhalten.
| Key | Werte | Standard |
|---|---|---|
alert | Boolean | false |
Beispiel
alert: true
removeAfterDeath
Entfernt diese regionale Platzierung nach Tod oder Zeitablauf dauerhaft. Das wird für einmalige Begegnungen wie BetterStructures-Schreine verwendet. Die gemeinsame Bossdefinition kann weiterhin andere Platzierungen haben.
| Key | Werte | Standard |
|---|---|---|
removeAfterDeath | Boolean | false |
Beispiel
removeAfterDeath: true
Instanzierte Bosse
Instanzierte Bosse sind ein Untertyp regionaler Bosse, der in instanzierten Dungeons verwendet wird.
| Key | Beschreibung | Werte | Standard |
|---|---|---|---|
instanced | Macht den benutzerdefinierten Boss instanziert. Pflichtfeld. | true / false | false |
Bosse als instanziert zu setzen ist zwingend erforderlich, damit instanzierte Dungeons korrekt funktionieren. Wir empfehlen außerdem, für alle instanzierten Bosse die Leinen zu entfernen.
Beispiel
instanced: true