It sounds like you’re really listening to the community and if you get this done like you want, it WILL be awesome.
I certainly agree with some of the above, WG for server, op use. GP for game play, players to use.
I mentioned in another post that a single combined plugin with all the features would be good but ultimately it’s probably nicer to have both separated for more specific use.
Also note that it’s somewhat simple to extend GP to include features you want, given the API implemented so far.
I agree with this and would like to further say if it was divided up into different plug-ins much like how essentials was divided up it would be great.
Edit: To further expand let’s say instead of different developers we have one main developer to help gracefully integrate all of the other functions of grief prevention together.
It’s important to realize not every server will need the same level of protection.
Also one thing to note is how much server performance will be affected. If you pack to much all in one then it could impact the performance of the server greatly with no benefits to the operator who really didn’t need “all the bells and whistles”.
I agree if I don’t want it It shouldn’t really be there, like if I don’t want chat protection then why do I want something with bell’s and whistles?
I’m very interested in your boot time with the latest version (I uploaded yesterday)?
Software can’t fix DDoS in general. GP does some mitigation at the Minecraft login level, which works for many cases where the group running the attack doesn’t have enough juice to completely overload the lower end of the network stack. Real DDoS attacks kill the server by overloading it with very low level connections - way below the level GP, CraftBukkit, Sponge, or even the OS can really police. The only effective solution to DDoS is very specialized (and very expensive) hardware, often beyond that which datacenters make available.
Take the specific example of several connection attempts from the same IP in a small interval. Yes GP could do that and it would help for small groups of “bots” run by the same player, assuming they all connect close together. But if the griefer is running a really big bot net, the hardware will be too overloaded to even get that information up to GP for processing.
Anyway, I think you’ll agree that a DoS is rather a low-power grief. Sure the server is unavailable for a while, but when the bot resources are reallocated to something else or when the attacker gets bored and moves on, the server comes back online and it’s exactly the way it was before it went offline - unlike a grief that happens in-game and leaves a permanent mark (like stealing from a chest or breaking down a build).
GP already does two things here - first, a single account can’t log in more than once per 2 minutes. That’s enough to shut down even a large bot net pretty quick. Second, GP will prevent join/leave messages from appearing in the chat too frequently, so players can continue to use the chat even when players are rapidly logging in and out. Put the two together, and login/logout spam is a minor problem that disappears after a moment.
Of course, if the traffic is so high that your hardware can’t handle it, everybody loses connection to the server and you’re out of service until the traffic slows down again. For that hardware level attack, there’s nothing any software (GP included) can do.
Yes, for the occasional server which wants to say, allow spam or theft, that is true. But I think it’s better to ask the rare cases to edit a config file than to require the common cases to download additional plugins. What you say about performance and bells and whistles is true in principle, but in the case of GP, the balance is very well implemented. I’m happy to discuss it further with you if you disagree, but you’ll have to get into specifics about GP to make a case.
We pretty much came to the same conclusion in the thread I linked XD
Does GP handle successive connection attempts with different usernames differently from this? I tend to have players with weak connections that get disconnected frequently, so I’d rather not prevent their login entirely, but just mask their login/leave messages. I’d only care to block connections that appear to be part of an level 7 DoS attack. Although I’m not sure how hard it would be to differentiate those two events reliably.
Let me clarify - the rule is two minutes between consecutive log INs. If the player can maintain a connection for at least two minutes, then he will never run into this problem. If a player’s connection is so sketchy that this is a problem for him, I’d argue that he’s not having any fun anyway, since he’s losing his connection more than once per two minutes.
The only case where I’ve seen legit players encounter this is after a login, they suddenly realize they forgot to swap texture packs, and log right back out. Since swapping packs takes less than 2 mins, they hit this message and have to wait.
I figured that’s how it’d work, and true enough XD Although I have some users that try anyways. Especially if they’re trying to use MCChat or a mobile platform (some of my moderators may do that as well to keep an eye on chat). I don’t really recall, but is there an option for this 2 minute limit? I think personally I’d drop it to a few seconds if it’s configurable. Maybe an option for hiding the messages as well I’d keep about 1-2 minutes.
Nice that you can change resource packs in game now as well XD
It’s in the config file. I think soon I will change it to seconds, and default to 60. I think a few seconds isn’t enough - a botter could just leave his bots active and if he has enough, then every few seconds there would be a splash of logins. That might be enough to interrupt normal chat to the point of player complaints.
Well, guess they’ll complain either way, honestly. It seems without treating different and same username connection attempts separately, there’s ins’t a value for the cooldown I’d be entirely satisfied with. I guess seconds would be better though, if it seems at some point letting users login freely is more worth it given that DoS attacks are fairly rare on my server.
Or I suppose I could just add something to my plugin if I’m too bothered by it XD
They’re treated separately. All log-ins by frequency is a factor, just not configurable because I think it’s a complicated number to figure out, and giving server owners the option to change it will just result in feet full of bullets. Same-player log-ins is configurable (currently in minutes).
Correct me if I’m wrong - what I understand from this is that you want to be able to switch protection plugins without having to recreate cuboids?
On the surface it sounds like a good idea, but I don’t think there’s very much commonality amongst the plugins. For example, GP recognizes five roles - owner, manager, build trust, container trust, access trust. Suppose someone was using GP and it was backed by this API, then tried to switch to another protection plugin - unless that other plugin also recognizes the same five roles, much would be lost in the transition, even when both plugins use the API.
I can also see how it would be attractive for developers of new plugins, so they could skip the effort of defining cuboids and persisting them across server boots. But convincing owners of the more popular protection plugins to take on a new dependency and update their code just to make it easier for their users to stop using their plugin is a very difficult sell.
I agree, make things difficult unless that API could be able to translate the info to other plugins.
Hey everybody, the UUID migration work seems to have landed, and lately I’ve been doing lots of work to improve performance both during play time and during boot. If you’re running a server with GP and you haven’t updated within the last couple of weeks, now is a great time to come grab a new build and get all the goodness.
Also, if any of you are running Spigot, timings reports are solid gold to me right now while I’m working on performance!
http://dev.bukkit.org/bukkit-plugins/grief-prevention/
Had an idea last night. I doubt it’s worth the performance hit if there’d be much of one, but one of my mods was telling me she accidentally mined through someone’s claim (the stone under it, but it was still claimed) unknowingly because she was ignoring claims. It brought up the idea that it may be nice to have timely warnings if it looks like a user is mining and is going through someone’s claim (at least if /ic is enabled), maybe just if the user breaks blocks at all in a claim they don’t have permission to otherwise.
Also, do you know if the UUID conversions that BC’s version converted would be compatible with these new versions? I doubt I still have a pre-UUID-conversion set of files sitting around, and they’d be considerably out-dated by now I’d guess.
I guess I could put a timer on it, have it revert back to respecting claims mode after 10 minutes?
The current versions are back compat with those beta builds BC released. He didn’t actually do any UUID conversion work - he just replaced claim IDs with what looked like UUID’s. It had nothing to do with actual player UUID’s.
I am SO happy to see GriefPrevention is moving forward - it’s the foundation for anti-grief and the peace keeper for my server.
I absolutely love the plugin and recommend it to everyone! If you’re switching to Sponge, then the smartest thing for me to do is prepare for the move as well. I see a bright future ahead for Minecraft and those who adopt to the changes using Sponge. Exciting times ahead!
The timer may be nice, maybe more annoying for some servers. Couldn’t say XD Would it not be better to have a warning message, similar to building outside claims, but rather for building in claims that aren’t yours (or trusted in)? I suspect this may conflict a bit with the way it’s setup currently though.
And I’m running your most recent GP version. Looks like it worked fine, short of two claims that were converted to admin, which I could just transfer back easily enough. On the note of admin claims, I quite liked the way BC had visualized them with emerald blocks instead, was a nice visual delimiter from normal claims, would be nice to see that re-implemented.
@GeekyServers I hafta agree, although a warning, mods may see that as an advertisement, which was recently prohibited in the new rules, afaik.
Also, I’m using the most recent build, the gold shovel doesn’t really seem to do anything when right clicking quartz blocks. I think this is something that was fixed in BCs version, but I guess that was reverted. I’m assuming there’s going to be a few blocks that the shovel won’t work on.