Type of bug

Compatibility issue, Other unexpected behaviour

/ess dump all output

https://essentialsx.net/dump.html?id=34a7d48f203b4eeaa7d319b24a2a3520

Error log (if applicable)

No response

Bug description

EssentialsX does not recognise alternate biomes, specifically with /tpr biome exclusion but most likely any world function. TPR .yml
Using Terra to generate secondary biomes to vanilla, with the correct names attached in config. I have tried adding terra: next to the overworld/overworld biomes too, TO NO AVAIL.

Steps to reproduce

1. Place EssentialsX and a world generator such as Terra on your server.
2. F3 to check Terra ocean biome names (or other plugin) and place them in your tpr yml to exclude from teleporting you into structures/biomes such as oceans
3. Reload essentials or restart
4. Run /tpr a few times and observe ocean teleports.

Expected behaviour

/tpr should NOT send you into third party generator's oceans, even in the .yml.

Actual behaviour

/tpr does not exclude such biomes, and does so anyway.

Just pushed a PR which may support this, using the method @imDaniX mentioned. Test build here for any interested.

This should work in the latest dev build. The biome exclusion list must contain the full namespaced ID for custom biomes.

Only works on Paper 1.19.4+ for now.

This is a limitation with spigots API, there's no support for custom biomes

How is this an API limitation? Can't this be remedied with an attempted console log to at least see what Essentials is detecting the biome as, and be patched depending on a result?

if I'm reading this issue correctly, maybe I'm not, you're saying that biomes added by an external thing are not supported, which is generally kinda expected given that the spigot API doesn't expose anything bar the built in mojang biomes

If you're implying the Spigot API does not support anything external to Mojang biomes that is fine, but when talking in a Java context, there is bound to be some form of debug string that will allow us to grab the biome that /tpr decides to send a player to. Of course, this must be doable, given excluded biomes is a feature.

I request someone logs the biome reached, with Terra installed, after running /tpr. That will at least help us to see if the biome will return as null or something that we didn't realise can be worked with.
I could probably manage this, but only with someone who has experience working with Essentials. I'd need to be shown how the debugging works before sending up a PR.

If you're implying the Spigot API does not support anything external to Mojang biomes that is fine, but when talking in a Java context, there is bound to be some form of debug string that will allow us to grab the biome that /tpr decides to send a player to. Of course, this must be doable, given excluded biomes is a feature.

I request someone logs the biome reached, with Terra installed, after running /tpr. That will at least help us to see if the biome will return as null or something that we didn't realise can be worked with. I could probably manage this, but only with someone who has experience working with Essentials. I'd need to be shown how the debugging works before sending up a PR.

The biome API does not currently pass along any information that can be used to identify custom biomes, so as far as I can tell it is infeasible to fix this at the moment without upstream changes.

You are welcome to help test. See here for information on how to do so.

The biome API does not currently pass along any information that can be used to identify custom biomes, so as far as I can tell it is infeasible to fix this at the moment without upstream changes.
You are welcome to help test. See here for information on how to do so.

Surely there is a set value that informs us of a vanilla biome. Is it not possible to check what that value returns as with a custom biome generator installed?

The implementation upstream currently returns the key minecraft:custom for all custom biomes regardless of the actual key in vanilla, mapping from the CUSTOM enum value. So if you want to, you can block out all custom biomes in /tpr by adding custom to the list, but that's as good as it gets right now in terms of supporting this.

The biome API does not currently pass along any information that can be used to identify custom biomes, so as far as I can tell it is infeasible to fix this at the moment without upstream changes.

You are welcome to help test. See here for information on how to do so.

Surely there is a set value that informs us of a vanilla biome. Is it not possible to check what that value returns as with a custom biome generator installed?

Would this best be combatted with Terra implementation then? Any suggestion? Surely we can make this work

Would this best be combatted with Terra implementation then? Any suggestion? Surely we can make this work

No, it is of no fault of Terra. This is a nuanced issue which is quite frankly unlikely to be resolved quickly, as it has already been discussed in various other contexts in great detail. "Surely we can make this work" and other paraphrasings thereof are not contributing to this being solved. We are at the mercy of upstream projects (Bukkit primarily) which we are relying on as API providers to provide a solution before anything can be done in Essentials.

We would much prefer that Bukkit actually exposed custom biomes properly. However, that currently isn't the case, and is unlikely to happen before Minecraft 1.20 is released (nor guaranteed after that).

This could, in theory, be solved with a third-party abstraction layer outside of Bukkit (similar to Vault), but I'm not aware of one existing right now. I would prefer we didn't rely on this sort of solution either, because it will lead to more fragmentation and confusion for end users in the future when a Bukkit/Paper level solution is found.

Until a platform-level solution exists for getting custom biomes, there's not much we can do here.

I guess it's now somewhat possible with Paper's UnsafeValues#getBiomeKey, but I'm unsure if Ess wants to use such a "fragile" API.