Das EventHandling ähnelt dem bekannten System von Bukkit sehr stark. Zusätzlich bietet es Listener-Registrierung auf verschiedenen Ebenen, welche erst durch das Design von Atlas möglich werden. Standardmäßig sind alle Listener als globale Listener registriert, die auf jedes Event unabhängig von seiner Quelle hören. Einige Events werden bspw. nur von Servern verwendet. Für diese Events können die Listener direkt für Server oder ServerGruppen registriert werden, sodass sie unnötige Aufrufe nicht erhalten. Für Custom-Events lässt sich eine entsprechende Unterteilung auf gleichem Weg einfach realisieren.
AtlasEvents (alle Events welche von der Node ausgelöst werden)
- Global (alle Node Events)
ProxyEvents (alle Events welche von einer Proxy ausgelöst werden)
- Global (alle Proxy Events)
- Proxy (alle Events einer bestimmten Proxy)
ServerEvents (alle Events welche von einem Server ausgelöst werden)
- Global (alle Server Events)
- ServerGroup (alle Events einer bestimmten ServerGruppe)
- Server (alle Events eines bestimmten Servers)
CustomEventGroups
*- Global
*- CustomSubGroup
WICHTIG Events werden meist synchron zur Quelle bearbeitet. D.h., ein Global-Listener für z.B. ein ServerEvent, kann aus unterschiedlichen ServerThreads aufgerufen werden. Deshalb sollte beachtet werden, dass Daten synchronisiert werden müssen, bevor sie genutzt werden um Inkonsistenz zu vermeiden.
Neu sind Listener auf Basis von "Functional Interfaces". Beispiel:
new FunctionalListenerExecutor(SomeEvent.class, (event)->{
// your listener code here
}, ignoreCancelled, EventPriority.NORMAL);
Atlas.getPluginManager().registerFunctionListener(MY_PLUGIN, SomeEvent.class, (event) -> {
// your listener code here
}, ignoreCancelled, EventPriority.NORMAL);Es wurde zusätzlich eine Änderung an der EventPriority vorgenommen. Neu ist EventPriority.PRE_MONITOR. Die Bedeutung von EventPriority.MONITOR wurde verändert. PRE_MONITOR ersetzt nun die Bukkit EventPriority.MONITOR. Handler mit EventPriority.MONITOR werden jetzt nach der Verarbeitung des Event-Ergebnisses durch das System aufgerufen. Dies dient dazu, Änderungen vorzunehmen, welche aus Gründen der Konsistenz meist einen Tick nach Aufruf des Events durchgeführt werden - wie Inventar Änderungen. Weiterhin gilt: PRE_MONITOR und MONITOR sollten keine Veränderungen mehr am Event vornehmen und nur auf Basis des Ergebnisses handeln.
Vielen Dank für Eure Zeit und Euer Interesse an AtlasMC! Nächste Woche gibt es wieder einen neuen DevLog, seid gespannt!
Ihr habt Fragen, Anmerkungen, Wünsche oder Anderes? Dann registriert Euch gerne bei uns im Forum, besucht uns auf Discord oder schaut auf GitHub vorbei.
