Jump to content

Synergetrick

Members
 View Profile  See their activity

  • Posts

    43

  • Joined

  • Last visited

 Content Type 

Posts posted by Synergetrick

  2. Grief bait

    in Minecraft General

    Posted

    Part of the challenge in building a base in survival is to make it secure. That's a key gameplay feature. Some people use layers of obsidian, lava, crafting tables etc to make a roof for example. You go through all this work to make your base secure. Making a piston entrance with different kinds of blocks to slow down or deter people from entering is part of the strategy. So this is part of the gameplay, it **is** normal gameplay and should not be banned.

     

    Now, why are ores currently banned for defense? Just to give some history on how we arrived to our current policy: the original reason blocks like lapis or redstone ores were banned for use as defense or in piston doors was because it could be theoretically impossible for a player to get a silk touch pick (this was in the days of lvl50 and/or no xp plump). So it was theoretically impossible for the player to fix the grief.

     

    Nowadays it's extremely easy to get silk touch with enchantism, it's not longer a matter of luck.

     

    Now, even with enchantism, perhaps one could still argue that to make pvp more accessible, a pvper should have an easier time to enter bases, and silk touch pick shouldn't be required. I can see that kind of argument being made, though my personal opinion is that with enchantism, there is no excuse. Everyone can and should have a silk pick and use it IF they wanna break into a base. PVP is serious business, if you are lazy and don't get silk touch, then that's your fault.

     

    Having said that, suppose that ores remain banned, which is something we've been accustomed for a while. Should bookshelves and glowstone be banned? I say absolutely no. Why ban them? You can get glowstone in nether and you can craft bookshelves back easily. Again, the lazy argument applies.

     

    Here's my opinion on the blocks:

     

    • Glass: not grief bait, even though the block is destroyed and the player cant pick up any drop, it can easily obtained and replaced.
    • Smoothstone: not grief bait, cook cobble which is the most popular block and replace, easy.
    • Bookshelves: not grief bait, bookshelves can be crafted back easily.
    • Glowstone: not grief bait, everyone has glowstone, if you pvp you have potions that require glowstone, so even though you get less drops when you destroy, just have spare glowstone in your enderchest to replace. OR use silk pick. Up to you. Don't be lazy.
    • Leaves: not grief bait, anyone can get shears
    • Blocks that can be obtained only with silk touch (ice, ores, mushroom, etc): this may or may not be grief bait, up for debate. This is very tricky, with enchantism, it could be argued everyone has silk touch and so if they choose to break into a base, they can do so easily.

     

    The bottom line for me is: securing a base is exclusive to survival, you don't do this on p or c. Using blocks that slow down or deter PVPers from getting to you is part of the strategy. If you are a PVPer and you are too lazy to replace, then don't grief, find another way to get to your opponent.

     

    Reality check: most of the regular PVPers tend to avoid breaking stuff to enter a base. And if they break into a base they use a hidden entrance, or pearling.

     

    Knock knock.

  3. [Free] IRC Bouncer (24/7 Persistent Relay Connection)

    in General Discussion

    Posted

    I, for one, would enjoy this service. I've been trying (with little success) to set up a ZNC box and connect it to GameSurge. If you've managed to get it working, that's awesome.

     

    Do you support push notifications to Colloquy Mobile? There's a nifty ZNC plugin for that. It sends a push whenever a highlight or username mention occurs.

    I don't have the module loaded because I use AndChat which sort of supports it in itself, but I can load it for those who require it.

    • Upvote 2

  4. [Free] IRC Bouncer (24/7 Persistent Relay Connection)

    in General Discussion

    Posted

    I wanted to pop into this topic to say thank you for offering this service to people it is clear that you have put a lot of time into having this set up and questions mostly answered before offering. I love the innovative solutions you're bringing forward for people to take advantage of, which is what I hope people do, take advantage of what you're offering.

     

    Thanks Barlimore!

    Just waiting on the DDoS-mitigation protected IP still. It should be at some time this week. The server itself is ready to go.

    • Upvote 2

  6. [Free] IRC Bouncer (24/7 Persistent Relay Connection)

    in General Discussion

    Posted

    I am sorry, and I hate to be a bother here but, just a few questions.  1: Who are you? I have seen you on S once or twice, you're not on nerd.nu/staff unless you're an alt, or the rumor that you're an mod who was banned who is returning (kind of an odd rumor.)  2: You're asking for alot of people to put ALOT of trust into you by asking for everyone to basically switch to your personal system of IRC.  Personally I am not comfortable with that.  

     

    Edit: Just personal opinions, no need to downvote, please convince me otherwise.

     

    The downvoting wasn't me, I've just been working out how to respond to this, so here's your answers:

     

    1. I've been around essentially forever under one account name or another. Any account I had on the servers was realistically just an alt of this one, which was my first. I've never previously been a staff member for NerdNu, however I have supported in a technical capacity for quite some time (e.g., I'm responsible for dispensers working with water/lava buckets, working on anti-grief / new killstreak plugins for S).

     

    2. That's up to you. You're not paying me anything, so I'm hardly going to go out of my way to convince you to use this, it's merely a free service offered to those that require it. If you don't want to use it, that's fine. I will refer you to the fifth heading in the OP, however.

    • Upvote 4

  10. [Free] IRC Bouncer (24/7 Persistent Relay Connection)

    in General Discussion

    Posted · Edited by ElliotSpeck

    I think I missed the part where the current IRC system is broken?

    Either you don't understand what a bouncer's for, or you're referring to my general dislike for GameSurge. Assuming it's the latter, I'll throw in a few reasons why I (and many others) dislike it:

     

    A) AuthServ (in general). Primarily, it's account based and not nickname based. This is really quite silly. If someone nicks your name, you can't get it back. There's no killswitch:

    [01:18] <Speck> Test nickname, please ignore.

    [01:18] *** You are now known as Draykhar.
    [01:19] *** You are now known as Speck.
    [01:19] <Speck> Test initiative complete.

    I can hold this until he asks me nicely and I agree. Otherwise? Too bad yo.

     

    B) The netsplits.

     

    C) The downright strange method of hostmasking (in particular, the lack thereof given the community that GameSurge hosts), but that's a bit of a tangential topic.

     

    D) They don't give out group associations anymore, which are still a big thing for communities. I'm pretty sure the majority of GameSurge staff are simply permanently AFK.

     

    E) They don't even support SSL. SSL setup (including certification) has been a step in the compilation wizard for UnrealIRCd for a while now. Even before it wasn't difficult at all.

    • Upvote 3

  11. [Free] IRC Bouncer (24/7 Persistent Relay Connection)

    in General Discussion

    Posted · Edited by ElliotSpeck

    Hi there,
     
    You might remember me from threads such as "Fixing the 'oh you broke into my base to kill me? Modreq for grief!' problem", and you'll probably see me in my hilarious upcoming AMA entitled "[redacted]".
     
    In all seriousness, I'm here to promote IRC usage. In fact, I'm here to offer you guys free things (related to IRC) - bouncer services. Use IRC or want to get started (particularly you mods - you should all be on IRC)? Read on.
     
    tl;dr: I'm offering IRC bouncer services shortly. Have a forum account, an IRC account, and host cloaking enabled, then PM me on the forums.
     
    Ask me questions IN THIS THREAD.
    Request a bouncer VIA PM.

    UNAVAILABLE UNTIL I GET THE DDOS-PROTECTED SERVER (SOON™). YOUR CALL IS VERY IMPORTANT TO US, PLEASE HOLD AND AN OPERATOR WILL BE WITH YOU SHORTLY.

    Obligatory: What is IRC (tl;dr)?
    Anything I say here will essentially be indirectly quoting Wikipedia or going far too in to depth, so I'll just quote it directly:
     

    Internet Relay Chat (IRC) is a protocol for live interactive Internet text messaging (chat) or synchronous conferencing. It is mainly designed for group communication in discussion forums, called channels, but also allows one-to-one communication via private message as well as chat and data transfer, including file sharing.
     
    IRC was created in 1988. Client software is available for every major operating system that supports Internet access. As of April 2011, the top 100 IRC networks served more than half a million users at a time, with hundreds of thousands of channels operating on a total of roughly 1,500 servers out of roughly 3,200 servers worldwide.


    It might be old, but it's anything but dying. Anyone can start up an IRC network, but maintaining it may be a bit of a challenge. NerdNu is currently on GameSurge (but I'm trying to convince jcll to move us to a better network - they don't even support SSL for crying out loud), which is located at irc.gamesurge.net.

    So, what's a bouncer (tl;dr)?
    When you connect to IRC via server: You connect to a leaf server of a large cluster of servers. When you disconnect, your presence vanishes.

    When you connect to IRC via bouncer: You connect to this bouncer server, which is connected to the leaf. When you disconnect, your presence is maintained by the bouncer. When you reconnect, your last x messages are relayed to you; called "scrollback".
     
    Being me, I'll probably be looking at coding my own variant of it at some point in the near future to offer extended features. Until then, we're using ZNC.

    "Server"? Servers cost money!
    They do, but I work at an incredible hosting company (a few people here can vouch for its greatness). As part of my employment, my services are free. These same servers host part of NetChat - my own IRC network, alongside my personal and own company's website.

    So what about DDoS?
    DDoS won't be a problem. Shortly we're launching DDoS-protected IPs in Seattle, which is where I'll base this server when they go live. You won't have a problem with external abuse.

    What about "internal abuse"?
    That's a good point - I own the server (and have direct access to the network it's sitting on). So other than common-sense reasons such as "I have a correctly calibrated moral compass", why should you trust me?
     - I run my own IRC network, which has withstood hacking attempts, nonstop DDoS, and user impersonation. I know what it's like on all fronts for victims of any of this.
     - I don't care to read your private channels. Right now I consistently have forty-five IRC tabs open and not one of those is "general stuff". I don't want any more information.
     - I understand the value of private information. I don't want to know about the super-secret launch date of the next revision unless you're willing to tell me directly.
     - I can't see your password even if I cared to. It's encrypted using what appears to be Blowfish.

     

    Any terms and/or conditions?

     - This is a privately offered service. I reserve the right to deny, suspend or terminate anyone's access to the bouncer service at any time, for any reason. Realistically, I probably won't unless you do something impressively stupid (such as getting permabanned from the servers or impersonating someone to defame them). I will not be one bit sorry.

     - This service is strictly for players, staff or otherwise, of NerdNu.

     - Any attempt to access another user's account on the bouncer will be met with a lovely termination of your access and an entry into iptables against your IP. Logs of the incident will also be forwarded to the head admins so they can take action as they see fit. Just to clarify, my account isn't on this server anyway.

     - Don't share your bouncer account. This is more for your own protection than mine, but it's a condition of usage anyway.

     

    This sounds like effort, why should I use this?
     - More people need to use IRC. It's a great communication medium and you have 24/7 access to harrass talk to the tex mix. This is an especially prominent point if you are a staff member.
     - GameSurge is bad enough with connections without factoring in user dis/connection. Why not have a semi-permanent presence that only drops when (not if) your node netsplits?
     - You have a constant presence on IRC. That means PMs reach you at any time of the day, you'll receive them when you log on.
     - Even if my server disconnects from IRC for any reason, you'll still get your scrollback when you connect. It's one great feature of the software I use.

     - This works from any IRC client. Many times I've started a conversation on my desktop, then continued it on my phone thanks to scrollback. It acts just like an IRC server, you don't need any special client.
     
    So how will I get this?

    UNAVAILABLE UNTIL I GET THE DDOS-PROTECTED SERVER (SOON™). YOUR CALL IS VERY IMPORTANT TO US, PLEASE HOLD AND AN OPERATOR WILL BE WITH YOU SHORTLY.
     
    IRC Prerequisites: An IRC client (HexChat, KVIrc, Irssi, Colloquy, Pidgin, it doesn't matter), an IRC name registered ("/msg authserv help register"), and IRC host masking enabled (I believe you have to do this on the GameSurge website).

    Firstly, you need an account on the forums, and you need to PM me your in-game name name here. There's no other way to obtain an account for this and there never will be. I'm not putting up anyone outside of NerdNu.

    Secondly, you need to have a pre-existing IRC account, and have host cloaking enabled. While my server can withstand DDoS attacks, prevention is better than a cure. and host cloaking helps.

    Thirdly, I'll reply with the server address, a username and password. You can change that password when you connect to it by PMing a bot on the bouncer called "*controlpanel", which I'll detail in the private message.

    Finally, log into the server, change your password, and go wild. Your channels will be saved, you can message "*nickserv" to save your nickserv password and make it auto-authenticate when the server connects just in case the bouncer is dropped from the network.
     
    Use this thread to discuss it, I'll answer any questions in here. Do not PM me with questions please, there are other capable people who can answer your questions. Anything particularly good will be added to this OP.
     
    On an unrelated point, I really don't like BBCode. Markdown, anyone?

    • Upvote 8

  12. Anachronos - Automatic Rollback

    in Minecraft General

    Posted

    Also a question considering the policy of using this, what about farms?

    Would farms also have the possibility of being protected even though most people do replant?

     

    I've implemented a whitelist for blocks that will not be automatically rolled back and will drop. Things like carrots, potatoes and wheat can go on this list.

    • Upvote 1

  13. Anachronos - Automatic Rollback

    in Minecraft General

    Posted

    To move beyond the tech talk and to push towards 'on server' discussion with this thread, I'd like to voice my thoughts on this plugin and how it would affect game play on Survival, and encourage others to do the same.

     

    Simplifying the tech lingo, Anachronos works against time and rolls back edits done to regions. A player on a region list would edit their region as normal, placing and destroying blocks without noticing any difference. However, a player not on the region and breaking blocks within it - whether it be in attempt to murder the Steve inside or merely grief - would find no drops to be had, and the blocks would roll back after a set amount of time.

     

    Play wise, it eliminates much of the fear of not replacing blocks after breaking in to other peoples bases. It disallows for the permanent editing (griefing) of other peoples bases, be it block spam or destruction. It allows for more cohesive land borders (as your claim would be a region proper) and therefore less land claim disputes. 

     

    Moderation-wise, it increases requests on one front and decreases them on two. There would obviously be a substantial increase in regions requests that would need to be filled, and we'd likely have to train much of S's moderation on how to do so. However, it would cut out a large number of 'grief' requests, as well as the much more complicated field of land claim disputes. A plugin like this represents a huge shift in 'grief' and how we can better handle it.

     

    Personally speaking, I think it has a lot of potential.

     

    Thank you for this.

  15. Anachronos - Automatic Rollback

    in Minecraft General

    Posted

    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.

     
    [06:50] <Speck> Dammit totemo.
[06:50] <Speck> I thought you knew better than me and you threw it away.

    :(

     

    Does Java have a simple implementation of this that isn't `Queue`?

     

    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.

     

    Perhaps you're right here, actually. I'll remove the threading on the next push and see how that fares on my test box.

    • Upvote 1

  16. Anachronos - Automatic Rollback

    in Minecraft General

    Posted

    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. :)

     

    1. c45y suggested it months ago if not nearly a year ago now to me (or publicly in a channel that I was present/active in, I forget which), and he's where the idea came from. I have various pieces of PoC code from both him and myself that I'm using to work on this.

     

    2. I never really liked the SafeBuckets method of hashing (and in fact I wrote my own version of SafeBuckets which is used on the Junction servers). I can and will look into alternatives to the method I'm using now, which is specifically in the direction edk mentioned:

     

    LinkedHashSet of Timelesses would solve this problem neatly, if Timeless had a useful hashcode.

     

    I'll talk to you or him more about this as my Java is a little rusty, it's been several months since I've written anything in a language other than Python or PHP. It was weird enough writing the Timeless class and not having the plugin complain that I'd done something spacey.

     

    3. This is an issue I'm aware of and, while the debugging code isn't in the release on Github, is very prevalent even in three or four block changes solely because it pushes them over the <x>.00 seconds mark. It's something that I do need to fix and is on a to-do list that for some reason I didn't put in the README.md.

     

    4. You're talking about what is essentially a deque of objects right?

     

    5. I'm uncomfortable with the idea of leaving it off a thread solely because I don't want it compounding any existing problem or delay that might arise from other plugins or players doing sketchy things. Especially for something like this (a loop of actions with a potential upper bound of 30k), it seems like a better idea to leave it on a separate thread.

     

    6. Draykhar noted this when he and I ran a private plugin test. I believe a BlockPhysicsEvent is called when torches are broken indirectly, I'll have to check.

     

    7. #2.

     

    Please ask for clarification on anything here, it's 6am here and I couldn't sleep so I came and wrote text.

  18. Anachronos - Automatic Rollback

    in Minecraft General

    Posted · Edited by ElliotSpeck

    This is a quick 3am post before I finally go to sleep, so I apologise for any spelling or grammatical errors.

     

    This is something I happened to mention to one of the S admins the other day, and they took a liking to the idea and told me to post it on the forums, so I spent some of my redditing time coding up a plugin that, after a pre-configured amount of time, automatically rolls back "grief". This can be used to clear up forced-base entry, trap escapes, and the like. The code is now on Github: Anachronos

     

    This requires WorldGuard, but you can enable global passthrough so that regions aren't protected. Of course this means that moderators would have to handle region requests too, so it looks like you're going to need to get some more S moderators on board. ;)

     

    Using WorldGuard regions will also allow use of Glacier's primary functions (when I update it), which a number of players showed interest in when I mentioned it on Mumble last Friday (namely, you can place your own flowing water / lava in your regions).

     

    A short fact-sheet:

    • Anyone who isn't in a region's member list has their edits added to a queue, after a configured amount of time (default is five minutes after the action), the action is rolled back.
      • This also works with water and lava placement.
    • Blocks broken do not drop their item, blocks placed are not returned (your fault! Use disposable blocks!)
      • There's a configurable list of blocks to allow drops for, so that people can still nab crops from others' farms.
    • Block "damage values" are stored, so your wool isn't going to turn white and your stairs aren't going to be weirdly placed after rollback.
    • Right now, the rollback action does not hook into LogBlock. It's something I'm looking into along with a complete rewrite of LogBlock.
    • It doesn't persist over server restarts, it simply rolls back all in queue prior to disabling.
    • It rolls back in reverse-action order, so if you break a block and replace it, the queue will run through removing that block and replacing the old one.

     

    tl;dr I got bored and wrote a plugin that automatically rolls back basic base grief after a preset amount of time. I was told to post it on the forums at the mercy of any and all S players, and so I have.

     

    Discuss usage on S.

    • Upvote 5
×
×
  • Create New...