totemo

The main changes are: You spawn in the end at a designated first-join location. From there, you can warp into the minigames area by clicking a sign, or just drop down to a water drop below. You join a team by typing /join. In principle, you don't have to join a team - you could spend the entire event in the minigames area in the end. Most of the power blocks now record which team placed them. They only confer positive effects on the team that placed them and negative effects on enemy teams. You can test a hostile power block (which would not normally affect you) by running /testblock which toggles a test mode. The exceptions are stained clay and quartz (because I use the colour/data value to keep track of which team placed the block) and ice, because I want a speed road built by one team to be usable by the enemy (but tell me if I'm wrong about that idea). Staff won't see both team's chat unless in ModMode. There's now a time limit on stealing a flag (currently set to 30 minutes). If you don't capture it within 30 minutes of stealing it, it returns automatically. Dropping and picking it up doesn't thwart this mechanism. Team buff captures are now scored as well. The test server is still "Red" (event.nerd.nu:35565) and the real CTF server is still event.nerd.nu (default port). The real CTF server is now set up with working warps, buffs and flags. But remember: that map will be used in the actual event, so be careful with the edits you make. The full changes in this CutePVP plugin, from my commit messages on github are: Don't make op exempt by default. Don't override bed spawn set in the end. Set bed spawn to default non-team spawn in The End when entering that dimension. Fix unintended rounding of saved general locations. Add first spawn point in the end. Set a subsequent spawn point in the end for people who never join a team. Joining a team is accomplished with /join. Staff don't see both teams chat unless in ModMode. /teams now lists staff too. Disable the reload command until it is known safe. Remove redundant log. Remove the helmet from the drops on player death, to prevent wool farming. Added an option to make floor buffs ("power blocks") specific to the team that placed them or enemies. Added /testblock command to toggle testing of hostile floor buff effects. Return flags that leave the overworld via a portal or teleport. Disable plugin mechanics in worlds other than the overworld to support minigames in The End. Fix regeneration power blocks being overpowered. Return flags that fall out of the world. Automatically add players to a team-specific region for protecting chests as a group. Automatically return flags that are held stolen for too long without being captured. Prevent spamming of buff claim notifications. Count buff captures towards the score. Extend night vision potions to prevent 'flashing'. Still yet to be done (tomorrow probably) before I will declare it finished: Store team state (flag locations, buffs, team membership) in a separate configuration file from the other configuration - for reasons of robustness. Periodically dump scores and team membership into the console log (for robustness). Automatically assign identical IP addresses to the same team.

Other tasks that I omitted before: The inner region of the bases should be protected as a region named after the team: 'red' or 'blue', respectively. This region will automatically have team members added to it and can be used for LWC r:region chest protection. Before I added the feature to automatically add players to this region, I would have said set build: allow as well, but now it shouldn't matter. I don't think this region should go too deep: it should be possible for the other team to burrow under the base and enter via a team's own tunnels if the fortifications are insufficient. The section of the bases between the outer and inner walls should be protected as a region that nobody can edit: red_no_mans_land<N>, blue_no_mans_land<N>. This region should be as deep as the inner base region. Two team buffs need to be built in the NE and SW corners, respectively; one in the nether area, the other in the volcano. It's not essential, but I think the claimable block should be a beacon, for the extra pizzazz. There should be some kind of obstacle course to reach the buff, like for example, floating safe-buckets water that you have to swim through or a parkour course with ice, ladders, iron bars etc to walk on. It has to be somewhat challenging, but not utterly inaccessible. The two teams will be vying to claim these and will probably attempt to shoot each other off the course with bows.

R.I.P. Fido. Maybe I need to add an extra half a block to the coordinate.

I was wondering why I couldn't find your screenshots and then I looked at the ban date. 17 months ago. Please read the rules (http://nerd.nu/rules) and reply below when you have done so. If your password is easily guessed, change it.

løl - I see it clearly in my head. One wrong letter... that's all. Just one wrong letter. Apparently not. You're gonna have to implement Queue<> using a fixed-sized array as the backing. Really not much code. Queue<> also has an offer() method that returns false when the Queue<> is full which is exactly what you want for a circular buffer.

I envisage that for the most part only admins will be interested in this command, but anyone with ModMode privilege or above can run it. /visit-chunks <period> <step> <max> [<command>] Teleport to a grid of locations <step> blocks apart between X/Z -<max> and +<max>, waiting <period> seconds between steps. The player's Y coordinate remains unchanged. At each step, run the optional <command> if specified. Without a <command>, just teleporting to a location and waiting a while will give water and lava a chance to flow, reducing lag when the map is opened to players. The <command> can be used to do things like clean up drops (a few revisions ago on P we had terrible lag due to dropped grass seeds etc as a result of WorldPainting). If we had had this command on P when we were seeding the map with horses during the 1.6 changeover we could have used it to run /omg-ponies. /visit-chunks runs indefinitely; until a restart or until you run '/visit-chunks stop'. The command remembers the last step index that it executed and picks up from the same index next time it runs. If the step size and maximum coordinate value are the same, then that will resume in the same location as before. If you leave it running for long enough it will eventually "wrap around" and start revisiting locations that it has visited before. The total number of steps on a single axis is 2 * (max / step) + 1 and the total number of steps for the whole map is that number squared. The total time taken to visit the whole map is therefore: (2 * (max / step) + 1) ^ 2 * period seconds There's also a /visit-chunks next <index> variant that allows you to explicitly set the next step index to visit. For a single player it's not much help, but multiple accounts can cooperate to visit different sections of the map using this. Example: /visit-chunks 180 100 2000 /remove items 200

Yup. It was quite a few ores. 30 diamond deposits. 145 diamond ore total. Xray bans are for one month. Please read the rules (http://nerd.nu/rules) and open a new appeal on the 30th of September, stating that you will abide by the rules from now on. Some of your edits:

Oh, I must have been really tired when I wrote that... I of course mean FIFO - First In First Out. The complete opposite of what I wrote - LIFO. In my head I knew what I meant, LOL. I confused the issue by writing LIFO. It's a single-ended queue. Essentially this: http://en.wikipedia.org/wiki/Circular_buffer The upper bound doesn't actually matter at all since you should only ever have to deal with the head of the queue (when rolling back an edit) or the tail of the queue (when adding another edit to be undone). You should never ever have to visit all the elements. Checks to see whether there is already an existing element are done with a hash which is essentially constant time. Whether you actually gain anything from using a thread here remains to be seen. You're going to have to add the edits to a temporary synchronised queue just to pass them from the main Bukkit thread to the work thread. It then has to remove the edits and add them properly to its data structures. And then you have to work out a way of removing those edits from those data structures on the rollback, which in the threaded version means essentially just sleeping until the the tick comes up and then using a synchronous task to add them blocks back using the main Bukkit thread anyway. I see extra complexity (and you essentially have to duplicate the Bukkit scheduler in your thread) but very little time saving. Anyway, it's up to you, lol. I'm just trying to help.

You know what, it's not often I get to say this, but I took a second look at your tunnels and realised I made a mistake. Please accept my sincere apologies. You're unbanned.

What's the difference between a duck?

I think the reasons for not enabling the GameSpy query protocol previously were technical (complicated connection relay setup). In any case, it's enabled. We're somewhat hampered by a bug in the Curse Network's Minecraft Servers listing site which prevents us from being able to reclaim our listing of those servers. They have acknowledged it and say they will fix it when they fix it. Not much more we can do about that other than check up on it periodically. As far as promoting ourselves goes, I think putting more content up on YouTube is the way to go. A quick search there for reddit, mcpublic or nerd yields about an even split of desirable content and grief team videos featuring our servers. But if you take a look around any of our servers lately there's a uniformly high quality of builds on all three that we should show off. P, in particular, is amazing.

Alright, thanks for putting that code up so that we can talk about it in concrete terms. I have a few thoughts on it: c45y suggested this idea weeks ago and I'm totally in favour of it in a general sense. If I hadn't been swamped I would have written it myself. The remainder of my remarks are about the implementation. Firstly, I understand why you're rolling back the edits in reverse order. I envisaged it being simply a Last In First Out (LIFO) queue of edits that get undone in the order they were made, but I now see why it's more complicated than that. Perhaps that scheme is still workable if the plugin indexes the edits with a hash value based on the coordinates, and then checks for a prior edit in the queue (or to be more specific, in a separate HashMap that references corresponding queue entries). Check out the SafeBuckets code for an implementation of the coordinate hashing. Since that prior edit will restore the original block when it is rolled back, subsequent edits don't need to be recorded. That mechanism could also be used to inform the base owner that a rollback is pending on the block, to prevent them from wasting materials trying to fix it. The way that the Regenerator is currently written, because you're only looking at the first (most recent) edit in the queue, that queue (well, actually it's a stack, isn't it) will grow in an unbounded manner as more edits are added. Edits can be kept alive indefinitely (until the restart) on that stack just by doing more edits, and can certainly persist way longer than the configured timeout. The time taken to record edits increases linearly with the number of edits currently in the queue because you're adding to the front of an ArrayList. You'll end up incurring the cost of some big memory copies. You might consider instead doing the LIFO rollback and using a preallocated (fixed size) circular buffer, computed to accomodate a configurable number of users editing for a reasonable fraction of the timeout period. Being pessimistic about it, 100 users (high for S) editing constantly for 300 seconds at the rate of 1 edit each per second would lead to an upper bound of 30,000 entries in the queue. We could probably get away with half that or less. We can afford the RAM, and by re-using the objects we avoid thrashing the garbage collector. If the circular buffer becomes full, roll back an edit prematurely to make room for the next to be added. The other advantage to LIFO processing is of course that you don't even need a thread. You can just synchonously roll back a few edits from the tail of the queue on each tick where they are due to be undone. At most, the number of edits so rolled back will always be the same number of edits actually performed by players in the corresponding tick 5 minutes ago. (At least until the restart. And we can look at persistence.) Ultimately, even with a thread, you are still going to have to access the Bukkit API synchronously. There is no way around that. You'll need to take into account attached blocks like torches, signs, signs on signs (on signs) etc.. I can see that you're moving in that direction with pistons too. I'm really not convinced of the necessity of making Timeless a generic type. Thanks for attacking this problem. Keep it up, please. :)

I don't know if the individual staff roles are explained anywhere on our public sites, but it strikes me that WickedCoolSteve's explanation of them was pretty good and that that information deserves to be explained publicly somewhere if it is not already.

The NCP configuration has been made even more lenient for survivalfly and fastclick warnings. Let's see how that goes.

Some plugin issues are resolved. Some still to do. I will set up another round of testing in probably 24 hours. In the mean time, there are action items for event preparation here: https://nerd.nu/forum/index.php?/topic/472-moving-forward-preparations-for-ctf-take-2/page-2#entry5521

Latest changes and items requiring action: Items in red can be done by any admin or moderator. event.nerd.nu kitcatbar's most recent World Painter'd map is installed here. This is the actual map we will use for the event. Any edits you do to this map are 'official' and will be experienced by players. The lobby spheres build has been pasted into the end. /tppos world_the_end 0 64 0Requires manual checking of water flows and redstone devices to make sure I haven't broken anything. It had to be pasted in piecemeal. Plugin data files reset: LogBlock logs, SafeBuckets, LWC database, WorldEdit region database. A basic protection made in the end dimension to prevent PvP, block editing and mob spawning. Requires additional regions to be created with higher priority to allow PvP where required for minigames. May require additional flags if you can think of them. ​KOTH PvP allow region. Spleef floor build allow region. Some plugin configurations done by editing modifying copies of Survival plugin configurations: KitchenSink LogBlock LWC ModMode - configuration reset WorldBorder - border at +/-600 overworld +/-300 end WorldGuard config.yml and blacklist for 'world'. Other plugin configurations still need to be checked. The configuration will be based heavily on that of survival. PlumpXP and Enchantism will be included. Other action items: A first-join lobby must be created in the overworld as the initial player spawn must be in that dimension. This area should contain rules signs. Players will join the event and be assigned to teams by entering the /join command (still to be written). A first-join book explaining the game mechanics and rules of CTF must be written. Team bases must be constructed from schematic pieces at about -,- 500 (NW) and +,+500 (SE). Use //schem list. A few additional dungeons to be added under bases. However, the map does include dungeons. Netherwart to be hand-planted in volcanic and nether areas of the overworld - NE and SW corners. Warp signs to and from the end dimension need to be created in team bases. Status of the plugin: Some items from the previous round of testing fixed. Some issues to do with managing staff and team assignment still to do. I will probably set up another round of plugin testing in about 24 hours.

https://github.com/ElliotSpeck/Anachronos Sauce please. Moar sauce.

Ah, yeah. Sorry to take so long. We hold you responsible for the actions performed by your account. We don't really care who's driving because we usually can't prove it either way. Please remember to always replant crops of any kind. And if you are breaking into a base, the edits should be minimal and repaired immediately. Please take the time to read the rules (http://nerd.nu/rules) and reply below when you have done so.

I've been meaning to submit a patch to the MCBouncer plugin to give the option of showing time-stamps on notes and bans in game. But, you know... busy. As far as I'm aware, all of that information is accessible through the MCBouncer API. It should be made accessible in-game. Web interfaces give me the heebie-jeebies. Be very careful with this, LadyCailin.

I like silly ideas like that. The CTF testing is temporarily down while the P admins take a look at a map they're making. It will be back up in a day or two with new features in the plugin and some issues resolved.

Well, it bothered a number of other staff who looked at it too. I've been too busy working on keeping the servers running to even see an enchanted book in game for a couple of months. I owe you no such apology and it is never ok to disclose an exploit that gives you free items. Take it to the staff next time.

I've had a chance to read the Enchantism source code in order to verify that the book is indeed inert. If you had mentioned that in the first place, you might have saved both of us some stress and inconvenience. Upon hearing of an exploit which, prima facie appears to give players free enchanted books or other valuable items, I'm obligated to put a stop to it as soon as possible. I'm certainly not going to allow you to play the game while I investigate the impact of a bug like that. Please take note: The server admins reserve the right to determine the exact circumstances under which an item can be obtained within the game. Disseminating information about methods of obtaining items by exploiting software bugs is likely to earn you a ban, regardless of the item. The item in question certainly looks like something that could be sold to an unsuspecting player in-game. It therefore has some value. The Enchantism plugin will stay disabled until the issue is resolved. I reiterate my comment from the subreddit post: "That's not how you report an exploit.". You dumped us in it with zero warning, no time to evaluate the severity other than by that screenshot - which looks very severe - and put us into damage control. I don't appreciate that. It's taken up valuable time today that I had planned to use on much more worthwhile activities. I accept that your intent may have been only naive and not malicious. I'm unbanning your accounts.

Ah, so it's actually just one of those "shouting FIRE in a crowded movie theatre" type moments. I see. That makes it much more amusing. Thanks for explaining all that now. I'll be sure to let you know how your ban appeal is going when I've had time to verify that.

roastnewt is banned for posting a disclosure of an exploit in the Enchantism plugin on the subreddit that allows players to obtain items from the Enchantism GUI. In the screenshot that you posted you were invisible, so it's not clear whether you were using FatherSouth or roastnewt as your account at the time. However, the book depicted in the post ended up in a chest owned by FatherSouth who is a known alt of roastnewt. You could have just come to us and told us about the exploit, in which case we would have thanked you, taken the book away and then did what was necessary to prevent it being used by players (disabled the plugin until it was fixed). Instead, you decided to disseminate the information to as many of our players as you could, maximising the damage that could be caused. The ban reason was rule #1, but in reality this behaviour would also be covered by our hacking rule "No use of bugs or exploits to gain an advantage over other players (eg: item duping)." and it most closely resembles an item duplication exploit in that free items are illegitimately obtained. It may also be covered by "No sharing of illegal content.". I have not yet determined an appropriate ban duration. You will be informed when I have done so.

Ban for darkeststryke on c.nerd.nu for xray on pve nerd.nu/appeal by totemo on 2013-08-23 03:46:14 (no more bans, no notes) Well, your account definitely did xray. You broke fewer than 10 stone for every diamond you found over a total of 63 diamond ore. Tunnels are direct to diamond or other ores. Xray bans are for one month. Please read the rules (http://nerd.nu/rules) and open a new appeal on the 23rd of September stating that you will abide by the rules from now on. Your edits.