The EssentialsXSpawn API provides no means of determining where a player will respawn.

[gibsonpil]

Feature description

I propose that the logic used in EssentialsSpawnPlayerListener is moved to a method called getUserSpawn in the SpawnStorage class. Additionally, a method to access that method should be added to EssentialsSpawn and IEssentialsSpawn, similarly to what was done for getSpawn and setSpawn.

How the feature is useful

As of now, developers who want to work out where EssentialsXSpawn will respawn players are forced to replicate the logic in EssentialsSpawnPlayerListener. Having such a requirement makes EssentialsXSpawn harder to support for plugin developers and could result in compatibility issues should the logic EssentialsXSpawn uses ever changes.

I'm willing to implement this and submit it via pull request should this feature be accepted.

Edits

• I took a closer look at the Essentials source code and made a few modifications to my proposal. I think that using an Essentials User instead of a Bukkit Player would probably make more sense. Additionally, moving the logic for determining where a player will spawn to SpawnStorage would probably be more sensible than putting it in EssentialsSpawn.

[pop4959]

I don't necessarily hate the idea, but is there a reason why you don't just listen to the event after Essentials? I haven't taken a deep look, but what about it makes it impossible to support, and also what are you looking to use this for (your specific use case would be helpful to know).

[gibsonpil]

I don't necessarily hate the idea, but is there a reason why you don't just listen to the event after Essentials?

That's a good option for some plugins, but it only works if you're trying to infer spawn location after a player respawns.

I haven't taken a deep look, but what about it makes it impossible to support, and also what are you looking to use this for

Fair question. My main issue with the way such a thing would currently need to be done is that you'd have to clone the logic EssentialsX uses. However, since EssentialsX is a constantly updating project, this can change at times.

For instance, with 1.16 and the introduction of Respawn Anchors, an option was added to the configuration to allow EssentialsXSpawn users to toggle respawning at them. Had somebody, hypothetically, taken the approach of cloning EssentialsXSpawn's respawning logic prior to that update, their code would no longer work as intended, and worse still, the issue would be subtle and could potentially go unnoticed. In order to avoid such a thing developers would have to routinely monitor EssentialsSpawnPlayerListener for functional changes. I believe that adds unnecessary burden on developers, especially for something that could be remedied fairly cleanly on EssentialsX's end.

(your specific use case would be helpful to know).

Personally I've hit snags in two personal projects trying to add EssentialsXSpawn integration. One is a fork of Dynmap that I'm trying to add player spawn location markers to, and the other is a server moderation suite I'm writing from scratch that includes a /getspawn command.