I allow all players on my server to use the popular plugin WorldEdit yet I always run into the same problem. With allowing all the players to set up to 4000 blocks is no problem, I have installed certain plugins to make sure that commands are allowed to be used every 3 seconds. The main problem is I had 150 players on this weekend and if lets say 5 people issue //set stone at the same time that's up to 20,000 that need to be changed. This can stack up to 15 players at once which is 60,000 blocks that need to be changed... This may seem to not be a problem on smaller servers but holding 150 players can limit the abilities of what I can afford. Plugin category: I don't care Suggested name: ASDFworldEdit What I want: Make all WorldEdit operations like this Blocks The block property determines how many blocks are placed in each run. The default value is 1000. If this value is higher all the drawing will by done faster. But if this value is to high you can experience TPS drop and server lag. This is due to the fact that the server main thread is locked by the renderer (you can experience a similar effect when editing large areas with WorldEdit). The only downside of lowering this value is that the drawing will take longer. Example For example one operation requires 1300 blocks. Using the default settings it takes 1s to render it. If you lower the blocks value to 100 it will take 12s. This will eliminate all the server side lags but as you can see drastically increases the time needed to draw a statue. A good value for blocks is in range of 500 - 1000. I strongly discourage you to lower the interval property. Although lowering the value of interval and blocks can lower server lag and keep the drawing time short it causes more chunk updates. When interval was set to 5 and blocks to 100 it almost always caused the client to crash (the server had no lag). In all examples I assumed that only one player is drawing statues. If more players use the plugin at the same time the time needed to draw statues increases proportionally to the number of players. Also, skim-reading is much easier with paragraphs! Ideas for commands: No commands needed for this plugin. Ideas for permissions: pluginname.worldeditlimit - modify the worldedit limit for player
Really need this *time for a bump also I can host any resources need to make this like a Jenkins thingy
Giving out worldedit is a terrible idea no matter what the block change limit is. Users can corrupt chunks, I have done it before. Certain things that drop or cant be placed on top of each other normally like saplings or pressure plates will cause a server crash, then each time someone logs in it will crash the server again when it tries to load the chunks, and the only way to fix it is to delete the chunk the player is in. Which is almost impossible to figure out. Also, if someone sets 4000 end portals, anyone in that area would be caught in a client lag death trap.
Agreeing with Gunnerrrr... but still its a huge plugin written by one of the best Bukkit coders... it'd be hard for most of us to make it any better, and even if we could you are asking for us to write a plugin.. that won't lag... but you are making WorldEdit lag by giving massive amounts of power to tons of people... just no...
No use. Don't request a plugin if it's already done, just because it's "laggy". World Edit is a VERY efficient plugin, your server probably just can't handle it. I have NONE of the problems you all just mentioned.
I'd love to see someone be able to make a plugin which can change 100 k + blocks into something else with absolutly no lag at all >.>
This is already being done with WorldEdit. WorldEdit is being rewritten so that it will not lag servers.
Well.. I have my plugin asyncworldedit no thanks to any of you who just want to shoot me down. And also you can block certain items from being placed in the config so there is no errors... Also awe has a max que limit so it enables me to give out /br to everyone To finalise I have my own dedicated server that has been running for almost a year now and I have gone to every extent to make it the best it can be. It is now the ONLY server that gives out WorldEdit directly on join and with a 20,000 block limit. Beat that!
You're any idiot if you have worldedit run block editing asynchronously. Have fun with corrupted chunks.
You know what's funny... I have been running an average 101 players acc. mcdigr and have never seen such an error
You must not know what asynchronously is, or you didn't edit worldedit well enough... If you worked for a company, you would get torn apart for running physical edits asynchronously. Im not going to argue with you beyond this point, you obviously believe you're superior by adding a feature that can corrupt chunks very easily. Have you even taken time to think why sk89q didn't make it run asynchronously? Please, for the love of god, learn the difference between asynchronously and synchronously.
Not once did I lack the definition of asynchronously yet you think I know nothing at all... You are acting very immature for who you may act to be. And also why do you believe in this corrupted chunks conspiracy when I truely believe you have never ACTUALLY tested it.
Sigh... Go ask any professional developer like md_5 or mbaxter. Most devs here will even know what i'm talking about.
Well while you are lagging out servers and clients I will be standing with 20 tps looking down upon a person whom refused to take a step forward
Yet another person that thinks they know how to write a plugin properly, and ends up doing one of the worst Java faux pas. That is, allowing the same set of data to be modified by two separate threads. You may not know it yet, but you'll end up corrupting a file, or worse: an entire world.
Have you read his code? I just cloned it, and it's done perfectly correctly. It uses an asynchronous handler to allow many clients to use a single BlockPlacer worker thread to managed edits requested through multiple logical sessions by maintaining a block-placement queue for each logical session in its queue manager. There's no uncontrolled file I/O going on: you're just thinking about "asynchronous" at a lower (I/O-stream) level. Basic structure is replacing WE's EditSessionFactory instance with a subclass that hands out AsyncEditSession objects (subclass of EditSession) instead. An AsyncEditSession does NOT write block edits asynchronously to the level files, it passes them to the BlockPlacer, which puts them in the requesting client's queue, or rejects them with a message if their queue is over the configured soft limit already (which allows single large edits that exceed the soft limit to be entered without having to do them piecemeal). Each AsyncEditSession wraps an EditSession to be used for entering the actual block placements when scheduled. The BlockPlacer systematically goes through the queues and performs edits by placing the blocks using the wrapped EditSession contained in the requesting AsyncEditSession. No I/O routines are modified, or even implemented. No WorldEdit code is modified. The plugin simply places a shim between the interface notifying the session of a placement event and the resolution of that placement event, using the WorldEdit API as designed. tl;dr: Before you diss someone's code because the only way YOU can think of to do something is wrong, read their code and see if they thought of a better way than you did. That way you won't look like an idiot when someone DOES clone the repo and spend ten minutes glancing through the code to see how it's done. By the way RulingKyle1496, I have some ideas for streamlining queue management for ultralarge edits that are permitted under the soft limit, but I'm out of town right now and away from my dev box. I may send a pull request your way for you to look at in the next couple weeks, though. I love the design!
Done it with an infinate amount, only problem was it changed the blocks layer by layer, if you making something 150 blocks high i can take a while (15-20 seconds).
Hi all. Actually I'm the author of the AsyncWorldEdit plugin . Everything that sergut42 stated is correct (btw. thx for the code review). AWE does not implement a "classic" and full asynchronous mode to WorldEdit. It only edits the blocks in small packages instead of editing them all at once. Thanks to that the main bukkit thread does not spend to much time placing blocks and there's little to non TPS drop. The aim of this plugin was to eliminate as much lag as possible when WE commands ware running. @sergut42: once more more time thx for the review. If you have suggestions for the plugin contact me on dev.bukkit I check there regularly.
Ahh, will do! I should've looked at the bukkit dev sidebar more closely. I see that now. No problem. I'm planning on putting this on my server, and it's an elegant implementation. (Also, kudos on writing such a conceptually intricate plugin that I could understand in a ten-minute reading . . . I wish the legacy code I work with at the office were as straightforward . . .)
Probably, I did not check the WorldEdit 6 and I don't know how does it work. If its true then my plugin will become obsolete. But for now its a nice hack to make WE async
