[MECH] WorldBorder v1.7.2 - feature-rich world size limiting plugin [BukkitDev]

Could it be because I'm using 1.5.2 while on R4? Or should that not matter?

1.5.2 uses CB 1.1-R4 as a lib, so no.

Released v1.5.3

• Fix for fill and trim commands not working on newer 1.2+ worlds due to new region file type.
• Fix for potential problems caused by player location changing while border checking task is referencing it.
• Update "new location" method to accept locations at Y positions higher than the old 128 limit; vertical limit is now based on Bukkit's reported World.getMaxHeight() value.
• Fix for chunk mapping method used by fill command not properly closing region files when finished with them, leading to leftover open file references.

Known caveat:
This is not a problem with WorldBorder, but CraftBukkit 1.2 dev builds might have some world generation problems which they've yet to address. Remember that if you're running a CraftBukkit 1.2 dev build, it's just that; it's not a stable recommended release build.

I have a Problem setting the WorldBorder to round.
I created an Border 10000 in radius to me .
When i jump to 10000 65 10000 the max x and y Coords are about 7000 ... That means in calculating the tangens of 45° multiplicated with 10000 it is still an square.

I use 1.5.3 WorldBorder, the latest Dev-Build MC 1.2.3 and dynmap also the newes Build.

Can you help me ?

I'm not sure what your question is. Are you indicating the round border doesn't seem correctly round to you? Please refer to the map images given in the first post for the Fill and Trim commands. Those commands use the same border calculations for generating/removing chunks, so you can see a visual example of the shape of round borders.

Does this work with 1.2.3?

Yes.

Unless I missed something or dumb, this has no option for a physical border? I am worried about someone unknowingly planning a building near a border and finding out there is a big invisible wall when they go to build a part of it.

P.S. I don't know a lot but would this work with a 1.2.3 minecraft server even though its an R6 craftbukkit build?

1. There isn't a physical border option. I plan to try to implement a simulated physical border when I have time for it, where the world itself isn't modified, but players nearing the border would be sent chunk updates indicating there is in fact a physical border.

2. Read the post right above yours.

I read it but I thought he was referring to 1.2.3 R1 of Cbukkit. Thank you.

And also, does it differ from mod to mod or, generally speaking, will most 1.1 R6 mods work with 1.2.3?

Generally so, yes. The main batch of breaking changes happened between 1.1-R4 and 1.1-R5.

Hi there!

I just want to congratulate the coder for this one.
I don't know how I missed this plugin before, but now it's a must have for my server!
Very mature plugin with no issues even with beta CB builds.

Regards,
John

Hey!
First, I'd like to compliment the awesome plugin! It's really useful, saves a lot of lag while I'm playing.

I've noticed that the fill command works great with default settings, it generates world very quickly and doesn't seem to impact people on the server.
However, I've noticed the trim command isn't as optimised - for the same amount of terrain it takes twice as long and disconnects all the players.

The java process goes down to 0% cpu (occasionally spiking at 0.1%) and writes at a constant 250kb per second.
For comparison, while Filling it uses 50% cpu and writes 5mb every few seconds, which doesn't impact players at all.

Is this an issue with the plugin or should I just turn down the rate at which it deletes?

That's quite strange, because the trim process should be an order of magnitude faster than the fill process. It's normally done in just a few seconds with no real impact to the server.
Is there anything strange going on in your server console/log during the process?

You can try specifying a lower frequency for the trim process, but it shouldn't be necessary.

just curious but how would this affect plugins like hawkeye and such monitoring block changes ?? when using trim/fill.
Also this couldnt be previewed on dynmap by any chance to get an overview of the area to be effected

I don't know for sure how it would interact with other plugins which I don't use. The fill process uses Bukkit's built-in methods, so I would expect it to work fine. The trim process however directly modifies the world's region files, so other plugins probably wouldn't see anything changing there if they were indeed somehow monitoring for something like that.

You will soon be able to see your border in DynMap. Once DynMap 0.36 is released so that circular markers are fixed (they're added in 0.35 but broken), I'll then be releasing an update of WorldBorder to add that feature.

thanks for answer and great on the dynmap, just installed this, dont really need hawkeye, so ill turn it of for now.
got backups and snapshot working with worldedit anyway

yan I use the worldborder 1.1 version to generate 1.2 chunks?

update plz

WorldBorder is compatible with 1.2.3 and uses Bukkit's generation methods, so your question is off-base.

Have you actually tested it in 1.2.4 or are you just immediately posting "update plz" without testing? It should work fine in 1.2.4, though I haven't tested it.

EDIT: also:
Apologies all, but I'm currently unable to spend much time at my computer so I'm probably not going to be answering many questions at all for the next few days at least.

Not working fully on 1.2.4 R 01 - appears the region files are being saved as .mca
Previously they were saved as .mcr

Running Win 7 64bit as a local server.

The radius works, however the fill command does not (and I assume any other command that looks for the .mcr files?

Sounds like you're using an older version of WorldBorder and need to update it.

Ah DERP!
So I am!

1.5.2

Updating now.


EDIT:
All working

Released v1.5.4

• Added integration with DynMap to display borders. It's enabled by default if you have DynMap installed, but note that you'll need DynMap v0.36 or newer for it to work. Borders will be displayed correctly as round or square and should be very accurate, based on a Y height of 64 on isometric maps. Any changes you make to your borders should almost immediately be reflected in DynMap (border radius or shape change, removal, new border set, etc.). Thanks to mikeprimm for adding a couple of requested features to DynMap which made this feature possible.
• Fix for error on border crossing if player is riding on something which is not classifiable as a Vehicle. This only occurs when using another plugin which does something like making wolves or dragons ride-able and similar.
• Also, a slight improvement to how boolean values are determined from command input; it accepts "y", "yes", "true" instead of just "on".

New commands:
/wb dynmap <on/off> - turn DynMap border display on or off.
/wb dynmapmsg <text> - DynMap border labels will show this.

New permissions:
worldborder.dynmap (Op): Can enable/disable DynMap border display integration
worldborder.dynmapmsg (Op): Can set the label text for borders shown in DynMap

Is there a way to change the color or width of the Dynmap border? It's just a tad wide/bright. Similar request here.

I'll consider it when I have time.

Thanks for your continues support for this plugin. I've been using this for a long long time, and I appreciate its stability.

I have some problems with worldborder - can't trim unneeded world part.

Code:

>wb mrnikel3 trim
21:58:14 [INFO] World trimming task is ready for world "mrnikel3", trimming the map past 208 blocks beyond the border (default 208), and the task will try to process up to 5000 chunks per second (default 5000) and blah-blah.
 
>wb trim confirm
21:58:17 [INFO] WorldBorder map trimming task started.
21:58:22 [INFO] [WorldBorder] [Trim] 0 entire region(s) and 8997 individual chunk(s) trimmed so far (100,0% done)
21:58:22 [INFO] [WorldBorder] [Trim] task successfully completed!
 
>wb mrnikel3 trim
21:58:14 [INFO] World trimming task is ready for world "mrnikel3", trimming the map past 208 blocks beyond the border (default 208), and the task will try to process up to 5000 chunks per second (default 5000) and blah-blah.
 
>wb trim confirm
21:58:17 [INFO] WorldBorder map trimming task started.
21:58:22 [INFO] [WorldBorder] [Trim] 0 entire region(s) and 8997 individual chunk(s) trimmed so far (100,0% done)
21:58:22 [INFO] [WorldBorder] [Trim] task successfully completed!

WHY it shows "8997 individual chunk(s)" in second time instead of 0 ?!
It should delete these chunks after first trim command, doesn't it?

After that, I deleted all Dynmap files, copied new "dynmap" folder without any data and run

Code:

dynmap mrnikel3 fullrender

and get this:

1. It's indicating all of the chunks in existing regions as being trimmed whether they existed or not, because it doesn't actually check first. I should probably make it check first so that the indicated number would be absolutely correct, though that will slow the process down a little bit.
2. I'll quote the relevant part of the first post:

There's otherwise no way I know of to get dynmap to detect that all of the chunks are gone. I even tried adding in code to make dynmap re-render those specific areas but it did no good.

But these chunks really exist? Of course I've done all the things: stopped server (not just 'reload' command), wiped dynmap folder, re-rendered all map. I ever tried like that:

wb mrnikel3 set 1500 100 100
wb mrnikel trim
wb trim confirm
wb mrnikel3 set 1400 100 100
wb mrnikel trim
wb trim confirm
...
wb mrnikel3 set 400 100 100
wb mrnikel trim
wb trim confirm

this isn't working either (