1.12.2 SF/SV: Sponge ignores the server.properties worldborder size

[theboomer]

Spotted while creating a new fresh server setup: After launching the server, fixing the eula.txt, and editing the server.properties file to have a worldborder size of 1000, then relaunching.... ... both spongevanilla and spongeforge ignore that file setting, and have the worldborder set at 60million

---

Since the server grabs all the other initial settings that may be set in the server.properties file, one would expect it would, override the internal default

I am currently running...

• SpongeForge version: spongeforge-1.12.2-2486-7.0.0-BETA-2665
• SpongeVanilla version: spongevanilla-1.12.2-7.0.0-BETA-337

I know that I observed this behavior many moons ago and thought it had been reported but I see no open issues for any of the implimentations or common. If this is a duplicate of something, I apologize in advance for not spotting it.

[theboomer]

Hmm, follow up work shows that the mojang server jar all by itself also fails to read the border setting from the properties file, so that takes the pressure off.

Unless that is something that Sponge can step in and clean up a spill mojang made... :)

[ryantheleach]

What setting are you expecting to control the world border.

max-world-size This sets the maximum possible size in blocks, expressed as a radius, that the world border can obtain. Setting the world border bigger causes the commands to complete successfully but the actual border will not move past this block limit. Setting the max-world-size higher than the default doesn't appear to do anything. Examples:

Setting max-world-size to 1000 will allow you to have a 2000x2000 world border. Setting max-world-size to 4000 will give you an 8000 x 8000 world border.

https://minecraft.gamepedia.com/Server.properties

[theboomer]

aah my misunderstanding :)

[theboomer]

well actually... no maybe not. Yes ( a quck check confirms physically that vanilla mojang does have an unsurvivable area beyond the 2x distance, sure..

I think what tended to alert and surprise me is that the /worldborder get command should display the border size.... it displays 60mil

And I think - and will make something shortly to test this - that sponge gets its worldborder size from the same spot that the vanilla setting is from, and though there may be a physical barrier constructed at the 2000 mark, the /worldborder being 60M hands that information to the chunk pregenerating code as well (which would explain some tests before running for eons and only getting 0% done...)

The game seems to require using the /worldborder command in order to 'synchronize' the data stored in two different places.

== Added: Yes, mojang game will have a physical barrier where expected, but the /worldborder get command will be 60mil Same on a fresh new sponge server. And a sponge server also has an Empty result for the Worldborder of the world that the player is in - be it testing player.getWorld().getWorldborder() or player.getWorldborder() , and worldborder

So the base game has some wires crossed, and while it does physically put the worldborder where it is expected, mojang command still reports 60M and as such, Sponge is getting the information from that same location, and determining that there "Is no border set" for the world, hence the optional.

If I then use /worldborder 3000 to force a change, the physical border jumps to where expected, and NOW the /worldborder get command says 3000, as well, sponge has a nonempty worldborder object, that has a size of 3000 blocks wide...

So blame mojang for knowing the true border size to render and limit, even if they they say "uh, 60million.." when asked. Clearly sponge taps that.

So, yeah, sponge can fix this by getting the size from wherever else it is stored...

[theboomer]

Did a bit more digging, both mojang by itself and spongevanilla behave the same way (due to core obviously) Whatever the setting is in the server properties, that radius gets used for the border, but that value is not written into the NBT of level.dat file at all, which holds the default 60M value, until the /worldborder command gets used to set it, then the dat file is updated. It need not be fresh-new server - failing to set the worldborder by command (or presumedly, programmaticaly in sponge), the value in the properties file is used for the barrier, but not the worldborder ever...

This would definitely explain a lot of some of the trial issues and problems folks have had pregenerating worlds in the past, if they fail to set the border diameter by command first, or within whichever plugin takes it as an argument (but most do not require that entry, and use 'the default' settings to call the pregenerator). For those of us who set the value in the properties file when setting up servers, and see that the boundary is right where its expected to be, we wouldn't need to specify a radius /diameter for whatever plugin is going to pregenerate, hence it sometimes taking many many hours and not really getting anywhere..it actually was, getting there and beyond.

Until this gets fixed up, it would probabably be good for any authors who offer world pregen to specify the diameter be manditory entry...

[ryantheleach]

@theboomer I'm no longer able to replicate this on vanilla Minecraft.

I set server.properties to max-world-size 100, created a world and logged in, rather small world border was observed.

Restarted with max-world-size set to 8, died due to impossibly small world border on log in.

@theboomer (or anyone else with time)

The next step is to attempt to replicate with SpongeVanilla and SpongeForge.

I'm kinda in 2 minds about this, either we can keep vanilla compat, and apply the server setting to all dimensions / worlds, or we can intentionally break and not care, or we can try to separate this out into configuration settings.

I do wonder though if anyone uses this as anti-abuse for server hosts, to try to limit the world sizes due to disk space concerns.