RegenBlock
Part of the Minds of Chimera Project (dev)
CodeBlocks | MOCPlaytimeTracker | MOCDBLib | RegenBlock | MOCGoodEats | MOC3DImporter | ImageImport | MOCKiosk | MOCRater | MOCFizziks | GravitySheep | MOCChemistry | MOCRegistry
RegenBlock allows a creation of regions within Minecraft worlds that have a certain re-spawn timer assigned to them. Once a block in the region is destroyed by a player or a new block is placed it will regenerate to the old state after the timer is up.
Example uses
Regeneration of natural resources in certain areas, resetting of region to an earlier state - in a tutorial area on my server, there is a broken bridge that has to be repaired by the player, but after the player does so the bridge would normally remain fixed for the next player that does the tutorial, with RegenBlock I am able to "regenerate" old broken bridge. Can be possibly used as anti-griefing to some degree, but it will only check events associated with played placing or destroying blocks, not tnt, lava fire etc.
Permissions
regenblock.self - all or nothing permission for the use of any commands
Commands
(all at op level)
- Selection
- /rb select (ex,ey,ez) - Starts/stops player's selection mode. ex/ey/ez will expand selection in that direction. Y is vertical.
- /rb listselection - Lists player's current selection points.
- Editor
- /rb edit - Puts you into editor mode that allows you to change blocks in a region without triggering the re-spawn.
- Info
- /rb info - Print out information about the region in front of the character
- /rb list - lists all regions
- Global Blacklist
- /rb blacklist add/remove (id id id ...) - adds/removes supplied block IDs. Blacklisted blocks will be ignored by the plugin and not regenerated.
- Reload
- /rb reload - Reloads the configuration file. Use this if you updated regions through config.yml and have to reload it.
- Region management
- /rb create (name) [re-spawn time] - Creates a region based on your selection from /rb select
- /rb remove (name) - removes region from the list
- /rb type [typeId] - sets region type, 0 for normal, 1 for mine. Mine will regenerate only upwards and with random blocks that you specify with /rb spawnblock
- /rb sync [0/1/2/3] - sets region to regenerate all at once or not, 0 - normal operation, 1 - all blocks re-spawn at once based on first block broken, 2 - same as 1, but based on last block broken, 3 - blocks re-spawn in normal order, but shifted in time based on last block broken.
- /rb modify (name) [re-spawn time] - modify existing region
- /rb modify time (name) (re-spawn time) - modify existing region's re-spawn time
- /rb alarm time/message/radius (name) (value)- changes the region's alarm settings. Alarm will go off before blocks are due for re-pop to warn players.
- /rb rblacklist (name) add/remove (id id id ...) - adds/removes supplied block IDs for region. Blacklist blocks for a specific region.
- /rb feedback (name) (type) - sets feedback type for the region. 0 - none, 1 - on place, 2 - on place/remove
- /rb feedback set (string) - sets string sent to player during region feedback. Use TIME to show re-spawn time.
- /rb spawnblock (name) - lists region's spawn blocks.
- /rb spawnblock add (name) [id chance id chance...] - adds new blocks with spawn chance. Chances do not need to add up to 100.
- /rb spawnblock remove (name) [id id id...] - removes blocks.
- /rb repop (name) - Re-spawns all blocks in a given region
API
Method available directly from RegenBlock class.
public void regenBlock(Location location, Material material, byte data, Player player, Boolean isBreakEvent) location - block's location material - what material block should be set to once restored data - data value for the restored block player - player that broke/placed the block isBreakEvent - test if this is a BlockBreak of BlockPlace event.
very nice plugin :) - might it be possible to extend this plugin to regenerate a whole world? I want to regenerate the world_the_end, but with the selection mode it is to hard to select the whole world...
@Gurman8r
Not too sure, but I think you got a wrong impression about what this plugin does.
In general it attempts to restore region that you set up to it's initial state after a certain re-spawn time has passed. In case of a mine option it will restore same block locations, but with randomly generated blocks from re-spawn blocks you specify.
So in your case, you would have to go and mine that block you've created and after whatever re-spawn time you've set new blocks will come back as something random.
I'm having a bit of trouble figuring out how to use this plugin. What I'm doing is creating a large stone cube with world edit and then setting that block as a RB mine region. I set the spawn blocks and then from there I don't know whats supposed to happen. Is it supposed to generate ore that i set by itself or what?
Going to give this a go for regenerating player mines. I'll report any issues in a couple hours :D
Been running server on my laptop for 18 hours so far. CPU usage at 0% most of the time, free memory seems about the same.
Of course server isn't doing much, I just logged on few times to destroy a few blocks and see if they regen, but still it's something i suppose.
@drumming102
Shrug, don't use the plugin then :)
@Raidendex
I call shenanigans as Logblock can rollback 10k blocks at once on my server with 0 drop in tps.....
@OriginalMadman
Ok cool. At least I guess whatever happens, happens in the queue thread.
How does memory look?
The only thing that queue really does that could cause issues is create bunch of variables, which should be cleaned up by Java for the most part.
One of the variables created is a new custom event which signals thread on the server to re-spawn a block. Perhaps these never get cleaned up by bukkit or something?
Anyways, will also upload newer version as well that uses tiny bit less cpu by using Thread.sleep in the queue.
@drumming102
well lag would be expected in such cases. Bukkit doesn't like more than a few k of blocks to be changed at once, but in most cases should recover with some lag depending on the size.
Sync might not be a good option for your case. Maybe try to split the region in few smaller ones. so the total amount per sync re-spawn in not as big.
Seems like I get CPU creep but no lag inside mc now. But it went all the way until the box couldn't take it anymore and I hade to kill -9 craftbukkit (took about 20-22 hrs - similar to earlier cpu creep by regenblock - the difference is now I can't see any of it with nolagg examine - the separate thread?)...
I still think there is something in this plugin OR CB that goes way out of line with CPU and that it is triggered by RegenBlock somehow. And it is a problem I really did not have for months with the plugin on 1.2.5 so I kinda doubt it is RegenBlock itself that does it, rather that it is the trigger. There is no errors in the log though...
I'm going completely off the plugin just to see how that goes until tomorrow.
@Raidendex
yes at once and alot of blocks. We have an area of a big chunks of ore for our greylisters to dig out and build with while they wait for trusted status.
@drumming102
do you have region re-spawn at once, was there a lot of blocks that needed to be re-spawned when it did etc. More info
yea i LOVE this plugin but it created a MASSIVE lag spike on regenning.
MASSIVE. But then my tps go right back up but that lag spike is just too much.
@OriginalMadman
possibly, though I wouldn't know where to begin to try to figure it out. But I don't do anything too weird that CB shouldn't support so shrug heh
Ok trying it out. Will let you know if it still lags the server with time...
Actually I did not have these problems before 1.3 with RegenBlock...
Might it be something within CB that triggers it?
@OriginalMadman
Hard for me to say, if bukkit and java are both doing their jobs right, I don't think there should be any leaks... specially since java suppose to be so good at memory clean up :P
One possible location for a memory leak would be - every time block in the region is queued up for regeneration, an object is created for it, once that block is up to re-spawn object is removed from the array and not referenced anywhere anymore, so java should kill it -.- Though this should just grow memory not so much slow down any computations I don't think.
Other than that, it's just going through an array of these blocks once a second and checking if re-spawn time is ready or alarm time is ready. Now it's doing this in a separate thread. ... thought of something new to do, to make it a bit less heavy while typing, but will be in another version. Atm i check time vs system time if I should do another queue... smarter thing would've been to just sleep that thread lol, but anyways..
ok will check it... hasnt gone through yet.
I can confirm the 3.8 version gets worse over time the server has been up. It lags the server down to 2-4 TPS after about 20 hours every time it seems... 24000ms over 500 ticks is not ok...
Are you sure it is not something that stacks up (leaks)?
Uploaded 4.0 version.
Queue of blocks is checked in a separate thread now. As far as I can tell everything is still working the same way, but I haven't done too much testing so try it out and see how it works for you. It is possible there might be some thread safety issues still, but I think I got them all.
Performance wise, it should be better on at least not lagging the server when checking long queues, although the separate queue thread will be spinning wheels all the time checking the queue (kind of have to), so the load on the computer in general should be about same as before, but at least server thread won't be lagged as much by the plugin I hope.
@OriginalMadman
Ok.
Yeah I'm trying to move all the checking to a separate thread atm, will see how it affects the performance.
@Raidendex
Sounds good to me.
Well, many things now in 1.3.1 seems to lag the server. When I notice sub 20 TPS, I use nolagg examine to see if plugins are causing it. Regenblock has been using way more time than it should need and often many times more than any other plugin (and I have lots of those). I do think that sometimes it does lag down the server.
But it is quite possible its the usual suspects chunk-gen and dynmap, however in these cases - regenblock has been using more time (even when no regeneration is happening, and you saw how small my area is).
Looking forward to the update. Thanks for your hard work! Let me know if there is something more I can do to help with it.