This really needs to stop.

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

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


    I "can't" enhance the API to do what it needs to do. The bukkit team has specifically said they don't want data nodes for Permissions. So that discussion is over, and because of that I'll just end up mostly ignoring bukkit perms. This is the other reason why I think telling people they need to use all 'official' api methods for plugins to get a special 'supported' category is silly.
  2. Offline

    Don Redhorse

    well let's talk in the [Enhancement] Permissions API thread than... I know that using a permission to data node mapping is cumbersome sometimes... I think it always boils down to how you use it... and a lot of the stuff comming from the old permissions doesn't has anything to do with permissions itself... see datanodes..
  3. Offline


    Can you link to when they said that? I'm trying to figure out the rationale behind that decision.
  4. Offline


    I'm pretty certain I saw it in the Permissions FAQ Thread...have fun reading through that :/
  5. Offline

    Celtic Minstrel

    It's not so much an issue of too many plugins doing the same thing. It's an issue of too many badly-written plugins doing the same thing

    I don't think this is really a significant issue

    In at least 50% of cases, generic commands like this are better. Who wants to have to remember which plugin every command belongs to in order to be able to use it?

    Doing multiple functions isn't in itself a bad thing, but I think if your plugin belongs to more than three or so categories you might want to re-evaluate whether it is doing too much. I think there can be an exception for "general" plugins that do little more than emulate basic vanilla commands, though.

    What do you mean by this?

    This is not (always) good command syntax. In general it's better to have simpler commands than more complicated ones, and in particular you should want to avoid requiring a prefix for all commands belonging to a single plugin.

    What do you mean?

    Probably silly to force this, but it should at least be highly recommended. Do one thing well, rather than doing one hundred things badly. You might counter that doing one hundred things well is better still, but then… what if I only need/want five of those one hundred things? By doing too many things you not only make it harder to maintain but also give the users less choice in what features they are installing on their server. Yes, this is mitigable in various ways, but that's more confusing than just installing a separate plugin for each desired feature. (Interestingly, I'll note that the majority of client mods I've looked at — which, granted, is barely more than ten — have fallen into the exact same trap of too many features.)

    Sadly, there will still be those who like the convenience of installing just one plugin for all their needs.

    For e) at least, this is not so. There are many (pseudo-)standards around, after all. The most used one that you didn't mention is probably Economy, but there are others too.

    Both Essentials and DefaultCommands are horribly bloated in my opinion and should probably die. DefaultCommands isn't quite as bad as Essentials, at least, since it does manage to still stick to having commands only.

    Responded to Sleaker's post there.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: May 18, 2016
  6. Offline


    I believe that complicated commands means /<command> <arg1> [arg 2] [arg3] <arg 4|5>. I am not exactly sure that this is a problem or that I believe it should be dealt with, however this is what (I believe) he is referring to).
  7. Offline


    I wouldn't say it's a problem as long as it's well documented in the plugin thread AND/OR there are very helpful help messages displayed to the user in-game if a command is typed wrong or wrong parameters are passed etc.

    Edit: There's nothing worse than having to come out of fullscreen, open your internet browser, go to bukkit, search the plugins list and then search through the post to find the one command you're after
  8. Offline

    Don Redhorse

    Well yes and no... /help is ofcourse better than /pluginnamehelp or /pluginname help if it is a generic help, a problem arises if somebody uses the same command in another plugin too... let me think about a better example than /help... hmmm /expand for example.

    Now we have a problem: which /expand command do we have? /plugin1expand or /plugin2 expand. Do I need as an admin to open up the jar and remove the registration of the /expand command by myself? Do I need to change the name of the plugin so that the plugin is loaded first of the /expand command I want to use?

    Forcing a default naming and command standard like /plugin2 command and an alias api would make that problem mostly go away imho.

    I really like DefaultCommands.. but I would like it to be more modular... like essential was some time ago.

    But I agree that this isn't per se a bad thing, it should perhaps be frowned upon though. If the admin would have full control on which plugin function can use which command (which is possible with DefaultCommands Alias Function) it would be a problem most of the time.
    Plugins having no command structure at all, for example the myp plugin (doesn't exist don't search for it ;-) :
    /myp super

    it should either be /myp command or /mypcommand but not the stuff above.
    Agree, but see alias api.
    Well a lot of people in this thread suggested that we have a lot of plugins doing the same thing because people don't like the original developer or are missing a feature.

    I personally hate the request for: does it support X if it doesn't make sense, but if people request a feature which does make sense a developer should look into that matter and see if it can be accomplished.

    I know that a lot of developers program for fun or for their own server mainly... but if they only do it for fun or their own server why publish the plugin? As soon as you publish the plugin you get a userbase and you need to support it. There are a lot of examples where features which where in old versions or valid requests are put down because the "developer" doesn't need it himself. Which comes back to the developer tag I think.. if you don't want to support your plugin openly don't release it, if you support it you should look as "customer feedback".

    And like I said, I don't talk about... yeah but I need mysql support etc for a plugin which stores 3 lines of text or econonmy support for all economies out there because people think spawning a minecart, putting the player in and giving a shove is a perk..

    I think most people know which developers are open to feedback and which are not. Not that I think that developers who program for themself mainly are bad, they just shouldn't have an approved plugin if they can't support "big" customer demands and there are other plugins around which do. (sorry not a native speaker probably doesn't really make to much sense if you read it quickly.)

    I know but I don't talk about pseudo standards, I talk about the bukkit supplied api's. I don't care if a developer supports stuff on top of the bukkit api's but supporting them should be a must. See my suggestions for help and alias api, which are similar like the permissions api a must for a server system. Of course there is a problem with requiring support of an api... if the api isn't working correctly people don't like it.. so there need to be an open feedback about the api, some brainstorming on what is needed and than when it is implemented a constant review process. If people still don't like it they can add to it via plugins, but at least a common core functionality should be there. I know that there is a thread about an economic api, I haven't looked into it though recently. But I don't know why economic was looked at first when bukkit still is / was missing a permission, help and alias api.

    Most of the problems with permissions and superperms atm come from the fact that there was never really a roadmap or featureset described officially on how permissions will work in bukkit. Now it is there, handling only permissions and people don't like it because they are used to "permissions" incl. node data, info etc..

    hmm help message display for commands.. I forgot that when I started "rambling" about the help api..

    nice idea

    btw: see I'm learning..

    But this is about plugins, developer tags, release rules etc...

    short: people are used to old permissions which did a lot of stuff having nothing to do with permissions itself and they find that easier, also because a lot of plugins didn't make the change yet to superperms as that isn't a requirement.

    more in here.. and you and sleaker already responded there.. thanks!

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: May 18, 2016
  9. Offline


    I think this also has to stop ;) That is all utopist. What we (at least myself) want is just a little more strict plugin submission system. This in itself can be done quickly, make a team of reviewers and that's it.

    We don't have to loose focus that the bukkit team are humans :) I mean, they spend time to give us a nice forum, a nice API to build plugins. Yet we complain on futile things.

    So before asking more, just wait till the submission system is reformed (if it is). This will resolve a lot of issues. We won't have 42 plugins that do the same anymore after a month. Like a lot of wise people said, basic plugins that are "copies" of others won't have the same support as others and thus will be declared as inactive. Also servers admins aren't all brain-damaged fools, between 15 plugins they will go to the plugin that has the more views/comments. And if a new plugin is really better, it will spread by itself.

    After that, what we also need is documentation. Yep, we do need a better wiki to respond to simple questions. And this is the community's duty. Speaking ill of this is a nonsense. If you don't like the way it is, just ask to make an article in the wiki. I'm sure nobody will go against :)

    To summarize the main idea:
    1.- stricter submission
    2.- make wiki pages
    Supersam654 likes this.
  10. Offline


    @Don Redhorse although these ideas are really great, they lack one consideration: time. I completely agree with @adreide about adding the "Plugin Reviewer" group and move on with it (for now). Things like a better help API can be dealt with later seeing as Help/AutoHelp offer a decent workaround to the problem. As far asSuperPerms is concerned, I really don't have any problems with it. If people stopped demanding superfluous (read: non-essential and extra) features from the system, everything revolving around SuperPerms would be fine. Come to think of it, this problem seems EXTREMELY similar to the "overstretched" plugin problem which causes overlapping commands. I find it very interesting that when a plugin overstretches itself, it is frowned upon. However, when an API stays within its proper limits, people start freaking out because it can't replace an over-extended plugin (cough*Permissions*cough).

    And on that same note, if you really need to know a NON-PERMISSION "object" related to a player, then you/a bukkit dev needs to implement an API for a uniform PLAYER DATA STORAGE system, not a permission system that holds non-permissions. In fact, you should/could probably call it Bukkit SuperData
  11. Offline

    Don Redhorse

    well you can always have a 2 step approach, different rules and a new forum structure would help and have quick fix on the problems discussed in here.

    You mean tkelly's help? Tkelly is gone afaik and the program did have issues... I use it myself.. I'm already thinking about using another help or mcdocs to do it... but why should "I" do it if there would be a solution for everybody when there is an api? But this discussion should go into the Help Api thread not here.
    NICE :D

    Well Persistance could do that already but you would need to define a schema, and that should be done by the bukkit team.
  12. Offline

    Celtic Minstrel

    Well, all this is what the alias stuff is for, and I don't think forcing a command standard like CommandHandler (used by MultiVerse 2) does is worthwhile. For some plugins, it makes sense. For others, it just muddies the water.

    For example, suppose you have the following hypothetical plugins (as with your example earlier, they don't exist):
    • SimpleGive - provides /simplegive and /simplekit
    • EasyTeleport – provides /ettp, /etsummon, /etcoords, and others
    • TimeLord – provides /tlforward, /tlrewind, /tlset, /tlsee
    Is that really a good naming convention? If I want to teleport, I need to remember that the prefix et is applied to all commands, and what if I decide I don't like EasyTeleport and want to move to some other plugin instead? If I want items, I need to remember the simple prefix, but what if I decide I don't like SimpleGive? This can be somewhat alleviated by providing aliases, though; for example, /ettp could have /tp as an alias.
  13. Offline


    This made me think.
    Is there a tutorial on 'how to fork' somewhere? Because, well, I do have GitHub, but I really don't quite know how to use it besides pulling and pushing (and even that goes wrong sometimes!).

    I do agree however, there are too many plugins that do the same thing.
    Hmm, how am I going to choose between Permissions, BananaPermissions, Groupmanager (which died), and the new BukkitPermissions? Ah well.
  14. Offline

    Don Redhorse

    THIS... but like we discussed in the alias api thread not in the way it works now.

    I was more thinking about developers using /simplegive and /kitsimple as commands.. no coherence (?)

    BTW: How do I know which name is being used for pluginname:command is it always the pluginname?

    you forgot pex..

    and I think people will choose as all of them work differently, bPermissions for example doesn't support false permission nodes atm.

    I think it would be cool if somebody made a comparision chart or pros / cons of the different permission managers.
  15. Offline


    @Don Redhorse so true, I forgot that one.
    Imma just gonna go without Permissions, I think that's much easier.
    Even better, i'll just go with vanilla MC, without any plugins at all :p
  16. Offline

    Celtic Minstrel

    It's the plugin name as registered in the plugin.yml; if you're not sure what it is, then you just need to type /plugins and find the plugin you want.
  17. Offline

    Don Redhorse

    sigh.. so the plugin file name can be different than the registered plugin name... so that should be in the release template too.

    btw: atm a lot of plugins become inactive because the developer doesn't update the thread correctly at the top... afk / vacation / gone for god..

    Perhaps it would make sense to remove the strict requirement in a way that plugins can still be active as long as users post that it is working for a higher RB than in the subject and that moderators would edit the subject and the OP?

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: May 18, 2016
  18. Offline


    Nijikokun, I agree with your entire post. However, there are some even more glaring issues which need to be resolved which make this more complicated.

    Bukkit is GPL, which under the terms of the license, requires anything which links to it, to be compatible with the GPL. I know EvilSeph has come out and said he's not going to actually enforce this restriction, however, I feel this is a huge mistake. I honestly am waiting for the day somebody contributes to the Bukkit project and starts DMCAing plugin authors for GPL violations. The number of GPL violations are astounding.

    Because of SO many projects which are not open source, or of a non-GPL compatible license, anybody who wants to fork half of the projects on this forum are walking into a legal landmine.

    Here is one for example:

    There are a LOT of plugins released under this license. It's open source, maybe, but there are some problems.

    1) It's not compatible with the GPL. This is a legal landmine. See above.
    2) You can't fork it without violating their licence.

    It's open source in the sense that you can see the source, but forking the project without getting permission first is asking for trouble.

    Honestly, ALL plugins should be required to license their plugins under the GPL or a GPL compatible license. Period. This resolve half the problems I see on these forums. Besides, they should be anyways, since they're already violating Bukkit's license. So let's start by enforcing that.
  19. Offline

    Celtic Minstrel

    I recall hearing that their reason for not enforcing it is because they want to switch to a different license. I'm actually not certain that they're even within their rights to declare CraftBukkit to be LGPL, which may be part of the reason for not enforcing the GPL. I haven't heard a lot on this topic though, so I may be mistaken; take what I've said here as little more than rumour.
  20. Offline


    The problem is it's probably too late at this point. Enough people have contributed patches to the project, that they would need to either get wavers from everybody who signed agreeing with the source change, or have already have copyright assignment signed from everybody who contributed.

    Honestly, all it would take is one contributor with a spine and some legal background to take down half the plugins on this site. Their code is licensed under the GPL, which gives them legal authority to ask people to stop violating the license which then own partial copyrights to, even if it's just one line of code.

    Bukkit itself is GPL, and there is no legal reason why it can't be. CraftBukkit is questionable.
  21. Offline


    I build all of my plugins against CraftBukkit for this very reason, good luck enforcing the GPL/LGPL against that, considering CraftBukkit is, for a large majority, Minecraft source.
  22. Offline


  23. Offline

    Celtic Minstrel

    That may be why they've done nothing yet; I imagine it's also why they did a "contributor freeze" awhile back. Anyway, I'm not really sure of their reasoning at this point; I'm just making semi-wild guesses.

    Also, it's "waiver". :p

    If I'm not mistaken, CraftBukkit isn't just questionable; I suspect you could make a legal argument saying that CraftBukkit cannot be built against Bukkit.

    Right, that was basically my point
  24. Offline


    That may be true, which I agree, is probably the case. However, that doesn't invalidate the fact that building against Bukkit still requires you to adhere to their license.

    Your argument (as an analogy), is because Person A (CraftBukkit) kills (violates license) Person B (Minecraft), it's okay for Person C (Your Plugin) to kill (violate license) Person A.
  25. Offline


    I thought this thread was about 'too many of the same plugins' not licensing laws?
  26. Offline


    It may use bukkit interfaces, but it is technically linked against Craftbukkit, not Bukkit. When I build I do not link against bukkit.jar, I strictly link against CraftBukkit.jar. Now you could TRY to legally take my plugin down for this, but at the same time you would need to take Craftbukkit down too. this is the issue with how CraftBukkit is licensed.
  27. Offline


    No, are highly mistaken. Because the .jar is called CraftBukkit.jar doesn't mean anything. CraftBukkit.jar contains both Bukkit and CraftBukkit source.

    For instance, JavaPlugin class is part of the Bukkit project, not CraftBukkit. Calling any instance of JavaPlugin in your plugin would require you to follow the terms of the GPL.

    If you wanted to write your own GPL free implementation, here is what you would need to do:

    1) Write your own Minecraft interface. Call it "MyOwnBukkit". License it under any terms you want.
    2) Rewrite CraftBukkit to use MyOwnBukkit instead of Bukkit (MyOwnCraftBukkit)
    3) Release your own plugin against MyOwnCraftBukkit and MyOwnBukkit.

    Notice if you do this, you're basically making your plugin incompatible with every other plugin out there. If you want to make it compatible, you would need to do clean room implementation (look it up).

    It's possible, but just because CraftBukkit is LGPL doesn't mean that the source in the current form allows you to embed it in your own propriatary plugins. It doesn't. You'd need to remove the GPL cruft first, leaving you with only LGPL code. The compiled compilation of CraftBukkit effectively needs to be treated as GPL software for the purposes of writing plugins.

    But if still don't believe me, I would advise you to talk to a lawyer. It's confusing, and I assure you, you're wrong.
  28. Offline


    @phrstbrn Again, good luck trying to take my plugin down without taking CraftBukkit with it. The vast majority of the code in CraftBukkit can't be licensed under either the GPL or the LGPL, as it is not the Bukkit devs code to license.
    You may very well be right in that I'm linking against Bukkit even though I link against the CraftBukkit binary, but even so, CraftBukkit in itself is breaking the GPL by linking against Bukkit.
  29. Offline


    It's okay for LGPL software to link against GPL. Those two licenses are compatible. It's also okay for GPL to link to LGPL. Those two licenses are compatible.

    However, when you mix GPL and LGPL projects together, you get this binary blob which can't be interpreted anything other than GPL as far as linking goes. If you want to take the LGPL project, fork it, and remove the GPL code, then embed it into your application without releasing your source code (as the LGPL permits), you are completely free to do so.

    You're can't just say "CraftBukkit is LGPL therefore I can link to it". It's more complicated than that. You can link to CraftBukkit, but you can't link to Bukkit, however the ONLY way to link to CraftBukkit without modifying the source first, is to link to Bukkit. Catch 22. Again, it would be POSSIBLE for a developer to remove the dependancy of Bukkit, however, you'd have to effectively fork CraftBukkit completely.

    Whether or not Minecraft source can be GPL/LGPL or whatever, is completely irrelevant for the purposes of YOUR plugin linking to Bukkit. Bukkit can be in violation of Minecraft source code agreement, but that still doesn't mean you can violate Bukkit's.
  30. Offline


    Something about this rant reminds me of craftbook and falsebook...
Thread Status:
Not open for further replies.

Share This Page