This really needs to stop.

Discussion in 'Plugin Development' started by Nijikokun, Aug 3, 2011.

Thread Status:
Not open for further replies.
  1. Offline

    Celtic Minstrel

    It's quite true that they were perhaps a bit too quick to imply that you need to switch to PermissionsBukkit in order to get the best out of the new permissions; I've told several people that there is no need to switch, but there's always another one asking. And I guess MultiVerse neglected to mention that it works with both permissions systems.

    I can think of one plugin that fits this category, and I think I agree with your basic sentiment on it.

    Funny, that; I wouldn't mind getting donations for General or SimpleSignEdit, of course, but they won't actually give me more time to work on them. I'll still be busy with school and life and so forth. Not that I need donations; I did this because I wanted to, not for money.

    I actually haven't noticed the prevalence of donations on the forum; I know there are some prominent developers that have donation buttons, but I hadn't noticed them appearing on a plurality of plugin pages.

    I believe that may have been me.

    Agreed. Even if you don't feel like documenting before you start coding, it's important to document before you release. I think there have been some plugins, even (I think) from fairly prominent developers, where I've had to ask how a poorly-documented feature works.

    Actually no; Permissions and some clones are not obsolete yet, unless they fail to update for Bukkit permissions. Remember that Bukkit permissions is an API only, not a permissions manager.

    Of course, no-one can force you to use Bukkit permissions, but if you choose not to you will alienate users who are relying on Bukkit permissions for all their permissions. For the other things you mention, this is not the case, though I do think that you should generally use what Bukkit gives you rather than trying to reinvent it.
  2. Offline


    I think it's a little premature to expect people to wow at a Spout plugin, especially one that requires it, along with one that has a very specific use.. Yah it seems like a cool feature, but I wouldn't want to run a radio plugin through bukkit/MC. So most likely your idea is very niche. That does not mean it's useless or uncool. Getting a radio station through bukkit is pretty cool!
  3. Offline


    I know a lot of people in this thread have shown a huge amount of frustration toward a lot of easily solvable problems with Bukkit problems. However, some people have begun..."creeping"...into the plugin request thread and other posts that should be in the plugin request forum. I would just like to say that quite frankly, 99% of those people really don't know any better. I remember when I was new to Bukkit in general and had absolutely no idea where to start! I had no idea that the plugin request forum even existed , I had no idea how to sift through the dozens of identical plugins, and honestly, I was one of those clueless users on the Permissions forum asking the same stupid question over and over again. If I didn't become a Bukkit programmer, I probably would have never learned most of these things. So before you go and rant about clueless people, just remember, Bukkit can be quite intimidating at first.

    As for repeat plugins, I would just like to say that the last 5 1/2 pages pretty much sums up the entire community's feelings (minus the people that "re-release" plugins). Perhaps instead of just ranting about it on this thread, we should do something about it! What if someone created a thread in one of the forums about changing the plugin submission guidelines rules. We could add @AllTheAdminsAndMods to the end of the post so that everyone who can change this actually finds out about the post. I for one would like to make the first rule: Under no circumstances whatsoever are any more of the following types of plugins allowed: Anti-TNT, anti-griefing, or invincibility/god-mode plugins. I would also like to make rule 2: "Sufficient" (To be determined by a mod or admin) documentation is required before any plugin goes under the actual plugins section (documentation must be completed while it is in the submissions thread)

    And for anyone wondering why I sound like a Bukkit programmer yet don't have a purple tag, it's simply because I have only completed 1 unoriginal plugin and had the COMMONSENSE not to release it on!
    Don Redhorse and Sleaker like this.
  4. Offline


    I like it. Though I know the bukkit staff seems to shy away from it because of the moderation duties it implies. Along with having to keep up on user levels.
  5. Offline


    Denying all highly repeated plugins would save the mods time, if anything. And requiring basic documentation is a quick glance at a link or two. Maybe its a relatively simple plugin and the docs are in a small spoiler in the thread. I didn't say that mods need to read the docs, just glance to make sure that they aren't non-existent.
  6. Offline


    *cough*GroupManager*cough*Permissions 3.1*cough*
  7. Offline


    *cough*Permissions 2.7*cough*SuperPerms*cough*AllPermissionPluginsThatWillBeDesignedOffOfSuperPerms*cough*
    Wow! I stopped breathing for a minute!
  8. Offline


    I agree 100%. As a server admin who has watched bukkit go on for a while, I can see how this problem is out of control. Stricter submission guidelines.
    And on the topic of SuperPerms, there needs to be an official warning simply stating that all plugins and Permission Managers need to upgrade within a week to ONLY SuperPerms, dropping support for all other api's. We need a single api to take control. Plugins should NOT have to support 5 different permissions API's, they should simply support 1, and with that supporting all the server admins who use any permissions manager that uses that API.
  9. Offline


    This attitude bothers me. I don't want superperms on my server, I don't want it to be forced, and I think it's obtuse for everyone to continually say "oh we should force plugin developers to support it." You don't go and force every plugin that wants to store data to use Bukkit Persistence do you? Stop forcing something that doesn't solve issues. If people want to support it I have no qualms with that, but I honestly get tired of people trying to say it *needs* to be the monopoly on permissions.
    Plugins don't have to support plugins that they don't want to, it's a developers choice. but now you're trying to tell every developer that they are required to use bukkitperms? where's the freedom in that?
  10. Offline


    Well, tbh, I have a feeling that with 1.8 Permissions 3 will break, and it looks like rcj will have to update permissions, and if he does he will likely use the Bukkitperms, or he wont update it and people will drop support for it. I personally hope for the second option, it will be great as the devs will simply realise they have to move on. I agree with you now, @Sleaker, people should choose. Hell, if it didnt break in 1.8, alot of plugins will simply keep supporting it, but I hope for the devs to slowly decide to drop support for non SuperPerms permissions plugins.
  11. Offline


    What if they decide to make it support PermissionsBukkit as well as their own permissions? As we all know, PermissionsBukkit is useless without an actual permissions plugin (SuperPerms is the 'official' plugin) but Permissions could replace that if the developers wanted to.
  12. Offline

    Celtic Minstrel

    @ichingpow – GroupManager is certainly obsolete, but it has been for some time. Still, someone could come along and revive it. Permissions 3.1 is not yet obsolete, but it will be if its developers don't implement support for superperms.

    You on 1000+? Too late, you already have superperms on your server.

    Even if it's not officially forced, developers will eventually be forced to choose between supporting it and becoming obsolete.

    Well, we shouldn't force plugin developers to support it, because some plugins have no need for permissions. However, it seems completely reasonable to me to insist that developers use superperms for their permissions. That said, there's no need to do so; I expect there'll be a trend of people just choosing superperms because it's simpler. We probably should at least insist that permission managers are compatible with superperms (though they can provide their own, more advanced, API if they like).

    Well, that's an entirely separate issue. For one thing, Bukkit Persistence may not be simpler than some of the alternatives (depending partly on what data the developer wants to store). Then there's the fact that persistence is not something for the server administrator to worry about, whereas superperms is.

    Funny you should say that, because forcing support of superperms would solve issues. It would solve issues of compatibility, of differing versions of permissions plugins, and other things like that.

    Forget about need; I think it's inevitable that it becomes the monopoly on permissions. Barring the lack of groups (which is not important for 90% of plugins), it's better and simpler than all the other permissions. It won't become the monopoly from any misguided policy but simply because it is better.

    Bukkit superperms is not a plugin. And we're not trying to tell every developer that they're required to use it. It's not necessary; most developers who need permissions will choose it because it's simpler. All they have to do is player.hasPermission. I have no qualms with a policy that it's required for developers needing permissions to do it through superperms, but I don't think it would change anything except perhaps forcing the few dissenters (all of which, notably, are older developers) to comply.

    I realize that there are some developers who stubbornly insist on boycotting superperms, but they seem to be an outspoken minority. I doubt a new developer, especially an inexperienced one, will choose to support Permissions over superperms.

    I also realize that you may disagree with some of the opinions that I have stated as fact (such as saying it's better and simpler). However, try thinking from the point of view of a new, inexperienced developer. Can you really deny that calling player.hasPermission is not simpler than checking that Permissions has loaded and then calling permissions.hasPermission?

    Um no. That's entirely false. Superperms is not a plugin. It's a core feature of Bukkit. Furthermore, PermissionsBukkit is not useless without "an actual permissions plugin"; it is a permissions plugin (or more precisely a group manager plugin).
    Don Redhorse likes this.
  13. Offline


    Taken from the permissions FAQ thread (Page 6)

    Taken from the permissions thread ORIGINAL POST

    Edit: Just realised I got two CORE words mixed up. In the post you've quoted SuperPerms should have been PermissionsBukkit, and PermissionsBukkit should have been SuperPerms

    But for SuperPerms to be used by the server they need a 'helper' plugin such as PermissionsBukkit.

    Edit: I'm not against SuperPerms by the way. I am for SuperPerms. Hopefully I can make a full transition to using only SuperPerms in my server when all the other plugins I use support it
  14. Offline


    Just to clear up a little bit of confusion, Bukkit 1k now comes with a built in permission system that is unusable by itself. By installing a SuperPerms permission manager, such as PermissionsBukkit or bPermissions, you can now use bukkit SuperPerms. This system is ideal because plugin developers can (easily) support just SuperPerms and server owners can pick between 2 or 3 permissions managers that are all going to be compatible with their plugins. It is only a matter of time before Permissions 2.7, 3.1, and GroupManager completely break due to a new release build. And when that happens, I highly doubt that GM or P2.7 will ever get upgraded. On top of this, I cannot imagine P3.1 staying on its proprietary permission system. Because of this, a "Breaking" release build would probably end the permissions architecture debate.
  15. Offline


    Considering permissions mostly don't touch bukkit - I don't see this happening.

    @Celtic Minstrel
    Also - just because I'm on cb1000 does NOT mean my server uses SuperPerms, it doesn't enable itself since the none of it is setup and it sees a blank file. It even spouts a message saying BukkitPermissions is not activated.
  16. Offline

    Don Redhorse

    well... best thing is that developers drop plugins... and another developer creates a new plugin... total different config, total different permissions... perhaps the same effect like the old plugin...

    so what do you do as a server admin? let the old plugin run till it dies? switch to the new plugin and just hope that this one also dies?

    there are a few plugins which come to mind which where great but got "lost"... some where taken over by another developer and keep going forward .... but a lot of them are just lost and you need to switch..
  17. Offline


    I am afraid it is a bit too late for this discussion

    Look at it! 37 pages of ~40 plugins each. 1400 is a rough estimate. I mean...I have seen some unique stuff like an animated sand worm out of blocks. Some are extensions of iConomy (I bet around 200) and a lot for permissions (500). 700 to go...which are? I'd say: do a refresh.
    Will this make people mad? Yup. Will this ease server admins? Yup.
    Don Redhorse likes this.
  18. Offline


    This is such a great idea, it has already been thought of! (This is a sticky in the Plugin Releases thread). Basically, when Bukkit becomes "official", all current plugins will be "removed" and only devs that actually move to the new fill system will have Bukkit plugins. The only problem is: What are the "official" submission guidelines/rules for the "Official" system? Will they be stricter as this thread wants them to be? Or will they be equally as wishy-washy as they are now. I for one think that we need to tell the Bukkit team what we are thinking so that when Bukkit becomes official, there will be strict rules set in place to make sure that only high-quality plugins are approved.
  19. Offline


    Well as I said before, more sub-categories. That is for one. For example, use a tree-node structure:
    For the rules. I'd has to be unique. What is unique? Unique is if this plugin does not yet exist.
    What about extensions? HERE COMES THE THING I HAVE NO YET HEARD :p
    - Plugins HAVE to support an API if possible. (static functions in a class)
    - If you want to extend a plugin, you reference this existent plugin and add your changes
    - The submission will be added in a sub-node next to the plugin
    - Total rewrites are NOT seen as submissions. If I were to make an 'iConomia' which only adds trading stalls (physical) and which basically does the same as iConomy (cloned) it is NOT submitted.

    To the logger stuff. It has to 'overrule' the predecessor. For example, we go back to the roots. Someone makes a logger plugin which notifies the console when someone places a TNT block. The next person makes the text displayed configurable. Old plugin removed, new plugin in. Person adds the ability to log the use and placement of ANY block. New plugin in, old plugin out if it supports text configuration. Someone makes another one that logs the use of flint and steel. Rejected: already in previous plugin(s). This is as long the change added is not possible by extending.

    If, for example, someone makes an API root plugin that logs everything with custom listeners, others can extend it by handling the events. Configurable can also mean static members in an API class.
  20. Offline


    Saying 'no you can't do that because it already exists' isn't exactly going to help the community
    NuclearW, Zeerix and Sleaker like this.
  21. Offline


    I'd say no to requiring API. It doesn't make sense for lots of things.
  22. Offline


    I am talking of the bukkit plugin list section, not the general release and submission forums. Those can be for plugin help/development/improvement requests. If your old plugin became obsolete you can always try to overrule the person that made the improvement (if you bother). Of course, if someone uses someone else's code for their improved version they have to add the persons name in the credits. (the list can become long, yes.)

    And why wouldn't it help the community? People can always develop plugins for their own server, release it and get replies. It will only be hidden in the general plugins list. Only problem I see are lightweight vs heavy plugins. This is where extensions kick in.


    @cholo71796 where possible. :)
  23. Offline


    Yeah, I know, but even still, it doesn't really make sense. I might suggest encouraging it, but forcing people to code a certain way is a little much

    And in regards to the plugin list, it would be nice if people could check off plugins that their plugin depends on, can hook into, is improved by and is incompatible with. I think that's more of a thing for the fabled Fill, though
  24. Offline


    This is a terrible idea. It basically limits user choices to the ones that some unknown governing group decides is the best choice. It makes any other options much more difficult to find. It also makes it much more difficult for any new plugins to get seen, even if they do everything much better.

    Not to mention the headache someone would have to go through, trying to decide which plugins should make the cut, which ones shouldn't, deal with the developers who didn't make the cut, etc. Sounds absolutely terrible.
  25. Offline


    In that case I'm out. :)
    No idea what should be allowed then, if also the easiest and most common plugins need to be allowed for the sake of the early developers.
  26. Offline


    I agree with this.

    I don't really agree with this- you can't make everyone happy, and horrible plugins shouldn't be released.
  27. Offline


    Although I agree with this statement, someone needs to draw the line with repeat plugins, and especially stolen ones. I honestly doubt that there is a single system for allowing and denying plugins that truely doesn't have any drawbacks.

    For instance, look at the current system. Any plugin that has a properly formatted post and is compatible with the latest release build gets approved. On one side, it's easy to moderate this and it keeps open source "open" to everyone. However, it causes the problems we have now with 10 anti-tnt plugins, blatant code copying (without recognition), and extreme confusion for server-owners, especially those new to Bukkit.

    Then there is the system that @bergerkiller is suggesting. This system makes plugin submissions highly moderated and controlled. On one side, the cons of the current system are removed (the opposites are basically the pros to this system), however this system has all of the opposite pros of the current system (heavy moderation and "closed" openness).

    Perhaps more COLLABORATIVE brainstorming is required in order to honestly come up with a good solution. We clearly have 2 complete opposite solutions (literally) that both have severe problems. Maybe everyone could work together and find common ground with this. I honestly doubt that a well thought out solution to a growing problem that is presented to all of the Admins and Mods of Bukkit would actually get turned down. However, short-sighted solutions (like our 2 opposites) will have a very hard time being put into effect (if it isn't already) and being accepted.
  28. Offline


    i just want to say that i think part (or even the majority) of this problem stems from a vast majority of people dont read enough. if you go into the request forum its full of people requesting plugins that exist already, or things that require client mods. there is a post at the top explaining what plugins are capable of, and what requires a client mod, but people dont read it. there is a search feature and an extensive plugin listing system with categories and a separate search feature. they are not hidden or hard to locate, but no one seems to use them. this leads to end users asking for repeat plugins, and rookie developers making them, or people asking for plugins to be made, virtually using the names and descriptions of plugins that exist already, and then raging when they dont get 'helped'.

    as an example, the other day someone asked for a 'x' plugin (i dont want to single them out so ill use 'x'). i searched 'x' and got one named 'x', with a feature list that read like it was copy/pasted from the request post. exactly what the person was requesting...yet the person is in the request forum, bumping their thread repeatedly saying 'no one can help me? :mad:'. i almost trolled them but figure people like that must live terrible lives rife with all kinds of similar 'problems' and a guy trolling them on a forum wouldnt help. but i didnt help them either...why should i when all the help they need is available in every direction they look? help your self ffs. it took that person longer to bump that thread than it took me to find and instal 'x' and test it out (it was cool btw). actually on a day to day basis i find it really hard to not troll people here and find myself ragequitting threads. (see chaircraft as an example of people missing the giant red warning, the 3 previous pages of other people missing it too, and then reporting the issue or simply demanding it gets fixed, often in abusive fashion).

    that, combined with the seeming lust for the purple tag leads to a lot of issues. there are often threads asking 'hao can i getz purple tag?' or 'where is mah tag?' followed by that person resurrecting an inactive plugin at random (sometimes not even changing it), or making another motd/tnt etc. i am old. i realize a lot of these people are quite young...but it still bothers me. at times this place reads like the 'special education' room in a highschool where they stick the kids with learning disabilities.

    unfortunately i cant think of anything short of extremely heavy handed moderation/shame/trolling/intentionally alienating people, that would fix these problems so i am contributing nothing and essentially just ranting.

    these issues are often balanced out by developers (of all ages) doing awesome work, offering support and help and generally being amazing people <3 so thanks. i would like to formally apologize for my end-user peers who are illiterate (but can somehow still write stupid forum posts), ignorant, unappreciative and demanding.
    Don Redhorse likes this.
  29. Offline


    Quite frankly, that paragraph basically sums up all REAL devs' problems. Perhaps this thread should really start working on the "common ground" plugin RULES. I would also like to add a suggestion that you need to have a certain caliber of a plugin in order to get the purple tag. I think a TON of developers do the absolute bare minimum to get that purple tag just because it is "cool", when in reality they are ruining the entire community. Although it might require a little bit of moderating, some easy rules could be established as a baseline for what deserves the purple tag and what doesn't. If that gets used, I definitely think that original plugins are an automatic yes, and complex plugins (that are not copies) should also be automatic yeses. Maybe more input could help make a better rule set (YES! I want your opinion!)
  30. Offline


    As stated earlier, the main issue does lie in the lust for the purple tag. People don't care about quality, hardly any of them care about coding, for that matter. They want to have status on the forum, to feel that they're special.

    Here's how I think it goes through their heads:
    Once they get the purple tag, suddenly they're part of an elite society where they're free to be douchebags and laugh at others because 'they're smarter'. They're "allowed" to troll others. People take their advice instead of others. Essentially, they're the kids that never got any attention, and feel that a tag on the internet will fix that.

    So how do we fix this? I've seen a lot of suggestions to simply cut down on releases, but people (such as @nisovin ) have made very good points about the consequences of doing such a thing. How do you get noticed, if you can never get started? What if your plugin is, in fact, better? Sometimes it's hard to determine whether the developer is some kid looking for a tag, instead of someone who genuinely cares about the product they produce.

    So we take a different route. Instead of restricting 'releases', we restrict 'the tag'. God help me, because this is going to sound extremely elitist...however, allow me to explain.

    We can all agree that 90% of the plugins that are 're-hashed pieces of garbage', are in fact the plugins from those who seek the tag...yes? Here's how we (presumably) stop this:
    • Unless you release something extraordinary right of the bat, you don't get a developer tag. If its a TNT-Notifier, a block logger, a god mode plugin, will be released. But you won't receive any special indication that sets you apart from the rest. As long as you consider yourself a developer, why should it matter?
    • What do I mean by extraordinary? Something unique. Something that would require more than a plugin template to go off of. It doesn't have to be complex, but it should be more than just displaying a message after placing a block...or spawning a cow off of a command.
    How does this accomplish anything?
    Simple. People can still get their plugins out in the open without having to worry about being controlled by 'the man'. If server owners are searching for quality, they will flock to the tags. But they'll still have their options, should they not find what they like.

    If they want to throw some PoS out into submissions just for the tag? They won't get it. Plain and simple.

    If they fork a plugin, just to fix one API change? No tag. Forks on inactive plugins shouldn't even be considered for a tag, unless they do something completely different with it. Most of the time, forking an inactive plugin is as easy as right-clicking a misspelled word and taking the auto-correction for it in Word.


    Don't restrict the release process, restrict the fancy purple tag that people seem to be mesmerized by.

    Of course, this will never happen. None of the suggestions in here will. When you get down to the base core of any of these, it requires quality control. Something that the moderators here are not willing to do. And I don't blame them, I wouldn't either. Its simply not plausible to 'judge' a plugin before releasing it. If its coded, and its functional...then it will be released.

    And life goes on.
    Sleaker likes this.
Thread Status:
Not open for further replies.

Share This Page