Configurable Per-World Void Damage Height Offset & Amount

[Axionize]

No description provided.

[lynxplay]

Welcome to paper 🎉
Thank you for your first PR.

Left a couple of comments that need addressing before something like this can be merged.

[Axionize]

I've fixed all the issues you've shown me and changed the PR to be an offset from minBuildHeight() as you said you wanted.

[lynxplay]

Do you have a specific use-case for adding API getters/setters?
We'd rather hold off on adding more methods until we have a strong API specific usecase, given this seems rather admin specific with the config values.

The API should already be able to deal void damage via the damage cause API if needed and these methods add to the general clutter that is the World interface already.

[lynxplay]

Beyond that, we can combine enabled and damage into a FloatOr.Disabled (needs to be created)

[Axionize]

Do you have a specific use-case for adding API getters/setters?
We'd rather hold off on adding more methods until we have a strong API specific use-case, given this seems rather admin specific with the config values.

Yes, dynamically loading/building worlds with WorldCreator from region files on disk, mainly for minigames.

Currently you can generate a custom world at runtime with a custom generator, biomeProvider, etc... but obviously void kill height can not be set when creating the world, much less when the world is loaded.

An alternative may be to modify WorldCreator.java to support passing in a custom world.yaml config settings (and potentially reloading those settings at runtime in World.java), but this is obviously much simpler and I would very much enjoy not having to take on such a task.

The API should already be able to deal void damage via the damage cause API if needed and these methods add to the general clutter that is the World interface already.

Yes but as far as I'm aware there is no way to change the actual damage delt by being in the void for an entity vs a plugin applying damage and setting the DamageCause as Void, for example by some RPG plugins.

You would have to check if damage cause is void, check if the player's y level is below the y-level of whatever the void damage height is, and if the damage was within a certain epsilon of 4.0F and then change the amount of damage applied to the player, to achieve the same result reliably.

[lynxplay]

Eh sounds fair, I guess.
I'll chat it over with the rest of the team.

You can deal void damage perfectly fine via https://jd.papermc.io/paper/1.21.1/org/bukkit/entity/Damageable.html#damage(double,org.bukkit.damage.DamageSource) and https://jd.papermc.io/paper/1.21.1/org/bukkit/damage/DamageType.html#OUT_OF_WORLD respectively tho.

Maybe it is worth consolidating the void damage configuration into a single interface type, e.g.

World#getVoidDamageConfiguration()
World#setVoidDamageConfiguration(WorldVoidDamageConfiguration)

interface WorldVoidDamageConfiguration {

boolean isVoidDamageEnabled();
double getVoidDamagePerTick();
float getMinWorldHeightOffset();

static WorldVoidDamageConfiguration vanilla() { }
static WorldVoidDamageConfiguration enabled(double damage, float minWorldHeightOffset) { }
static WorldVoidDamageConfiguration disabled() { }
}

but I'll get back to concrete next steps once we have more team input on this.
For now, could you please address machines comment regarding the "threshold".
It cannot be a constant y-value, it should be expressed as an offset from the min build height, as the default world configuration otherwise breaks custom height worlds.

[Axionize]

I've made it an offset from the build height as requested, defaulting to -64 blocks from the minBuildHeight.