Class DeathmatchDestination
Zentrix normally copies deathmatch_template into a fresh world for every deathmatch.
A scenario that wants the final fight somewhere else — the match's own End, its Nether, an arena
it built itself — answers the deathmatch-destination hook with one of these, and Zentrix runs its
entire ordinary deathmatch in that world instead: the teleport, the safe spawns, the freeze
countdown, the titles, the spectator transfer, the currency rewards, the border and its shrinkage,
block protection and decay, the game rules and the deathmatch loot pool.
The one thing that changes is ownership. A world Zentrix did not create is not Zentrix's to
delete, so manageWorldLifecycle() defaults to false and deathmatch cleanup leaves the
world to whoever does own it.
Example
context.override(GameplayHooks.DEATHMATCH_DESTINATION, request -> {
World end = context.world(GameWorldType.END).orElse(null);
if (end == null) {
return HookOutcome.pass(); // let Zentrix copy its template as usual
}
return HookOutcome.replace(DeathmatchDestination.builder(end)
.bounds(remap(request.borderCorner1()), remap(request.borderCorner2()))
.build());
});
- Since:
- 1.6.0
-
Nested Class Summary
Nested Classes -
Method Summary
Modifier and TypeMethodDescriptionbooleanWhether deathmatch block protection and block decay are active in this world.booleanWhether Zentrix resets this world's weather, clock and game rules the way it prepares a fresh deathmatch arena.@NotNull Optional<org.bukkit.Location> One corner of the deathmatch border, empty to keep the configured one.@NotNull Optional<org.bukkit.Location> The opposite corner of the deathmatch border, empty to keep the configured one.static @NotNull DeathmatchDestination.Builderbuilder(@NotNull org.bukkit.World world) booleanWhether both corners were supplied, which is what makes the remapped border usable.booleanWhether Zentrix owns this world and may unload and delete it when the deathmatch is cleaned up.@NotNull List<org.bukkit.Location> spawns()The exact places players are put, cycled through in order.toString()@NotNull org.bukkit.Worldworld()The world the deathmatch runs in.
-
Method Details
-
world
@NotNull public @NotNull org.bukkit.World world()The world the deathmatch runs in. -
spawns
The exact places players are put, cycled through in order.Empty hands the choice back to Zentrix, which then resolves spawns inside the declared bounds exactly as it does for a template arena — including its safe-location fallback for a position that turns out to be unusable.
-
borderCorner1
One corner of the deathmatch border, empty to keep the configured one. -
borderCorner2
The opposite corner of the deathmatch border, empty to keep the configured one. -
hasBounds
public boolean hasBounds()Whether both corners were supplied, which is what makes the remapped border usable. -
manageWorldLifecycle
public boolean manageWorldLifecycle()Whether Zentrix owns this world and may unload and delete it when the deathmatch is cleaned up. False for a world that belongs to something else — the match's End, for instance. -
applyWorldPreparation
public boolean applyWorldPreparation()Whether Zentrix resets this world's weather, clock and game rules the way it prepares a fresh deathmatch arena.On by default, because a deathmatch is expected to start clean and because scenarios that pin a world property are told about the preparation and re-apply themselves afterwards.
-
applyBlockMechanics
public boolean applyBlockMechanics()Whether deathmatch block protection and block decay are active in this world.On by default; switching it off leaves the world's blocks under whatever rules already governed them.
-
builder
@NotNull public static @NotNull DeathmatchDestination.Builder builder(@NotNull @NotNull org.bukkit.World world) -
toString
-