Multiverse-Inventories

Bukkit Plugins
878k Downloads

Bizarre respawning issue when a player has a bed spawn set.

CDWimmer opened this issue ยท 1 comments

commented

Information

Details

I was not able to reproduce my issue on a freshly setup and up-to-date server with the latest version of Multiverse plugins with no other plugins and with no kinds of other server or client mods.

Description
Worlds, for context: Lobby, set in server.properties and MV's firstspawnworld. a survival world (with acompanying _nether and _the_end), UpIsNotJumpLandia (another survival along with its own _nether and _the_end). creative, a normal world without a nether or end, and flatroom, a flat staff-only world, again with no dimensions.

Observations:

  • When I die in the lobby, I respawn at the spawn point of the lobby, regardless of having a bed set (not really an issue given players wont be able to build here anyway)
  • When I die in survival_nether or survival_the_end I respawn at the worldspawn point of survival, regardless of having a bed placed in survival.
  • When I die in survival itself, I respawn at survival's spawn point, unless I have a bed set, in which case I get kicked back to Lobby's world respawn point.
  • Same effect in UpIsNotJumpLandia and its dimensions.
  • creative and flatroom suffer the safe affects as the other overworlds.

To summarise, when there is a bed spawn point set, I respawn in the wrong place. Either the wrong location in the right world in the case of sub-dimensions, or the wrong world entirely, when dying in the overworld.

Secondary, probably related issue:

Bed spawn location is not correctly validated under all circumstances. Somehow.
As far as I can tell, Spigot/Paper's getBedSpawnLocation() method should always validate a bed is still valid when it is called upon to get a player's bed spawn location, unless a player has its SpawnForced value set to true (it's false by default and I've verifed it is still false now, though maybe something is altering it briefly?) in which case it will return the last bed location anyway, even if the bed was destroyed. However in some circumstances this doesn't seem to work and it just returns a location anyway when the bed is missing.

Doing some testing, I've determined that so long as a player has a bed spawn location in a world at all, even if it's actually invalid, even if SpawnForced is false, MV flips out and dumps me back into the Lobby anyway. That is to say, regardless of whether this second bug is in effect, the issue of respawning in the wrong place sill happens. I have no idea if this is actually connected or a totally seperate bug.

To actually cause this second situation see below section. Please note I couldn't reproduce it on a vanilla single player world nor on a Paper server with no plugins. Can't currently test a fresh server with only MV installed.

Steps to reproduce

Bukkit/spigot's validation doesn't seem to kick in correctly if I 1) place a bed and make it my spawn, 2) switch world by any method. 3) return to the first world, destroy the bed, 4) then do anything that checks my bed location (e.g. /essentials:home bed, querying with denizenscript <player.bed_spawn>, [both call the same Spigot API mentioned above, of which should do the validation])

The validation works fine if I don't leave the world. E.g. 1) Place a bed and make it my spawn, 2) break the bed, 3) check bed location as above, or die -> I am correctly told that I don't have a bed, denizen <player.bed_spawn> is null, etc.

Expected behavior
Fairly obviously, I'd like to respawn at my relevant bed when I die in a world, not back to the overworld spawn point (or the wrong world entirely).

Last note: I am fairly certain it's MV doing this, somewhere... EssentialsX just grabs bed spawn from the spigot API, and it works even with multiple overworlds created by MV, meanwhile the spigot API nominally doesn't understand having multiple worlds - like vanilla, you just have a bed home - so somewhere in MV (or something else?) that piece of API is being toyed with to create the illusion of multiple bed homes, and it's breaking somewhere. (My theory, anyway)

Should also clarify that EssentialsX has been configured such that the respawn listener priority is "lowest" (giving MV control, allegedly)

commented

As far as I can tell, deleting EssentialsXSpawn fixed whatever was going on here. Pending me re-reading my notes her eand doing further testing. I'll close if it seems all good.