Reported world spawn point is incorrect

[SlimeDog]

Spigot 1.14.1 (Jenkins 2324) git-Spigot-03bd4b0-c45c0a9 (MC: 1.14.1) (Implementing API version 1.14.1-R0.1-SNAPSHOT) WorldBorder 1.9.10 (beta)

$ grep WorldBorder logs/latest.yml
[20:48:52] [Server thread/INFO]: [WorldBorder] [CONFIG] Using rectangular/square border, knockback of 3.0 blocks, and timer delay of 5.
[20:48:52] [Server thread/INFO]: [WorldBorder] [CONFIG] Border-checking timed task started.
[20:48:52] [Server thread/INFO]: [WorldBorder] For reference, the main world's spawn location is at X: -128.0 Y: 75.0 Z: 208.0

>mv info world
[20:53:11] [Server thread/INFO]: --- General Info ---
[20:53:11] [Server thread/INFO]: World Name: world
[20:53:11] [Server thread/INFO]: Game Mode: CREATIVE
[20:53:11] [Server thread/INFO]: Difficulty: NORMAL
[20:53:11] [Server thread/INFO]: Spawn Location: X: 0 Y: 64 Z: 0 P: 0 Y: 180 

Similarly, but differently, incorrect in Spigot 1.13.2 final WorldBorder 1.9.9 (beta)

[Brettflan]

That's a new one. Not sure what's going wrong on your server, though it's probably down to another plugin making changes related to worlds or spawn locations after WorldBorder is loaded.

Reference code: https://github.com/Brettflan/WorldBorder/blob/master/src/main/java/com/wimbli/WorldBorder/WorldBorder.java#L41

[SlimeDog]

Multiverse-Core changes world spawn points. It's a feature. On all of my test servers, it loads and enables after WorldBorder.

Perhaps WorldBorder should have soft dependencies for world management plugins like Multiverse-Core, MultiWorld, etc.

[Brettflan]

Just to have the main world spawn location be correct in the startup server log info? Meh, seems to minor to bother with.

I also wonder why those plugins can't just set the world spawn locations directly through Bukkit methods, rather than relying on changing them every time they load. I haven't looked into how that works, so I'm sure there's a reason they do it that way, but it does seem strange.

If someone else wants to try addressing that through soft dependencies and test it out to confirm it works, and submit a pull request, I'll accept it. I don't have time for that, though.

[SlimeDog]

WorldBorder should report (and use) the operator-defined spawn point, not the seed-generated spawn point.

By default, MV uses the standard spawn point, but the server operator may decide to locate the spawn point elsewhere. It could be many parsecs distant from the seed-generated spawn point. You should care because the reported spawn point is incorrect. And if it is used for any other purpose -- such as setting the center of a radius-defined area -- then it is likewise incorrect.

It isn't very difficult to add a soft dependency. In plugin.yml:

softdepend: [Multiverse-Core, MultiWorld]

but that doesn't solve the problem. While simply adding that to plugin.yml changes the load/enable order, it does not change the reported spawn point, so more would be required. :(

Fortunately,

wb [worldname] set <radiusX> [radiusZ] <x> <z>
or
wb [worldname] setcorners <x1> <z1> <x2> <z2>

can be used to set an appropriate border, based on the true spawn point.

[Brettflan]

You should care because the reported spawn point is incorrect.

It is correct at the time that it is reported, specifically at server start when this plugin finishes loading.

So does /setworldspawn not work any more? Or is there some reason not to use it? It used to work and used to be permanent, but maybe I missed something and that has changed.

Anyway, again, I don't have time for working on much at the moment, and certainly not a "fix" for a minor issue that stems from slightly odd behavior by another plugin.

[SlimeDog]

I would surmise that the worlds have not loaded at that point, so that the MV spawn is not known.

setworldspawn

works insofar as I am aware, at least for the main world defined in server.properties, but may not work in any other world.

If one uses Multiverse-Core, the world-specific command is

mv set spawn

in a target world.

I have no idea if the two commands are compatible. If I find some time to test the various propositions, I'll post the results.

[dcoshea]

Just to have the main world spawn location be correct in the startup server log info? Meh, seems to minor to bother with.

As shown in issues #115 and #178, sometimes the player gets teleported to spawn, so the spawn location is relevant for more than just the log. I'm using Multiverse-Core and have been hitting those sorts of issues and as a result of this issue I get teleported to the "wrong" (from my point of view as a user of Multiverse-Core) spawn. I plan to file a pull request to stop the teleporting to spawn (at least in the case I'm hitting) but it'd also be nice if this plugin and Multiverse-Core agreed on the spawn point.

[Brettflan]

Multiverse-Core would need to set the main world's actual official spawn location as recognized by CraftBukkit/Spigot, either permanently (so it is always correct) or at least early in server startup.

[SlimeDog]

That seems correct and adequate. That's what I did, a year ago -- and I see that I failed to report it here. Apologies.

I will file an issue on Multiverse-Core. Insofar as I am concerned, this issue may be closed, but I'll leave it for others to decide.

[dcoshea]

The issue I'm seeing isn't in the main world. The /setworldspawn command worked for me anyway, though, as far as I can tell. I don't know if it moved the main spawn for new players to the non-main world though.

[SlimeDog]

It is possible that /setworldspawn works in non-main worlds. I didn't test it, since WorldBorder doesn't report them.

I don't know if it moved the main spawn for new players to the non-main world though.

That sounds like something you would want to know.

[SlimeDog]

Closed due to disinterest. We no longer use this plugin.