And that's why we have a infractions system. You are given 1 warning for this mistake and the second time it's a permanent ban
Let other people choose what they want to code. When more update comes, more stuff will come out. Bukkit is freedom, and allow you to code whatever you want. I bet there is few plugins like (censored) by far.
We're not telling them to not code repetetive plugins... We're telling them to keep them out of Releases, just so they can get a purple tag. Making simple plugins is a great way to learn, but just because you managed to display a message to someone after throwing an egg, doesn't mean I should see this 2 mins later: [FUN/RANDOM/LOLROFL] NOTEGGFICATION v0.1 - BE NOTIFIED WHEN AN EGG IS THROWN, DUDE! [1000] "I CAN HAZ TAG NAO, N BEE SPESHUL?"
@DrBoweNur You are correct, sir. I'm sure there is a few plugins type like mines out there. This one might be better.
Signed, redundant plugins are so tilting, especially when there's many plugins that are abandoned and for which no good alternative exists :/
I wouldn't ban anybody, but I would remove the plugin. If it has exactly the same features, it should not be here.
Just a side note to the guy who said I wanted all permission plugins to die, I don't want them all to die, just the ones relating to alternative permission systems. SuperPerms should be the only one existing as it's the internal one, better or not, it can be worked on and features can be added via github. All the plugins that manage them... well... it should be built into the system itself. not a plugin.
So because bukkit has built-in persistence everyone should stop using their own persistence and use only bukkit persistence, or since bukkit has a bultin configuration class no one should use their own properties for saving data. or because Bukkit has built-in services that means people should only use services to tell if other plugins have been loaded/registered. and because Bukkit has a built-in scheduler no one should be programming their own threads but instead should always use sync/async task schedules. I'm sorry @Nijikokun but your logic is flawed. Just because bukkit has something built-in does not make it any better, or mean that it should be used in all situations. BukkitPerms is no different than any of the other listed internals. Like you said this is and open source community - and if people find that the built-in features of bukkit are lacking then they definitely can and will keep their own features separate. Telling them that they need to conform to something that they already don't want is not what open source community is about.
Good point, but point out how twenty systems are better than one internal system that we can all build on.
There weren't really twenty APIs, there was one, the Permissions API, all other plugins were built with a compatibility layer. This meant all plugins built against Permissions and server admins could choose their own Permissions plugin. This is exactly how it is now, one API (The Bukkit SuperPerms) and then a bunch of plugins built on top of it for managing permissions.
Pretty sure my source has more than 20 comments I added them mainly for myself because it's easier to find a certain line of code or look back at an area of code that I haven't looked at for a while and forgotten what does what.
Yes, and once we get the dev and user communities on board (slight detail), we can all move forward. Until then, I'm back on one of the other permissions plugins because I, like many others who tried to adopt early, got burned by devs' refusals to adopt. Now I see at least one dev actually removing support for that system, and others haven't stopped balking or are just steadfastly refusing to add support. That's no way forward. I wanted to believe in that system badly because I'm also tired of the redundancy but it seems like the community at large did not get the memo. What a mess. @SephraelX - Me too.
Actually, wouldn't the basic idea of open source then be to improve the built-in feature until it can do what one want instead of developing an alternative? Seems to me like one of the most important concepts of open source TBH. IMO generally a distinction has to be made between plugins that are as basic so that multiple other plugins depend on them and those other plugins. Those on which many plugins depend shoud be much more strictly observed as those are mainly the ones that will generate problems once there are multiple and support for each is not available anymore.
That is the general idea for open source projects, but the devs on this project have a hard time accepting anything that isn't 100% like they want it implemented.
That's what the concept of open source's supposed to be. But 90% of the plugin developers then get lazy and blatantly rip the existing plugin thanks to said OS.
I'm not sure that it would change bad habits, but Bukkit could loudly endorse the use of public GitHub repositories and submitting pull requests.
We're talking about directly copying source code and doing it poorly. The instances of this on the site are not comparable. Direct copies are identical, and duplicates are usually poorly done. I have no problem with someone creating a plugin that serves its purpose in a significantly different manner or plainly does it better. This, though, is rarely the case.
When start to release my plugins, its always a good idea to search the plugin list for whether or not there is related plugins before I distribute any of mine.
Whoops, yeah, thats what I meant Well, if I found a similar plugin, I would altar mine to make it something different instead of a ripoff.
I agree in some cases pull requests are better then entirely new plugins, but I would like to point out there's also a growing problem of plugins getting bloated. One Plugin to rule them all, One Plugin to find them. One Plugin to bring them all and in the Essentials Bind Them. In the Site of Bukkit where the Developers lie.
If you don't have any active plugins, you shouldn't be a plugin developer. Granted this is difficult to track in a forum setting, I'm sure the rules will be cleaned up a bit if/when Fill is completed. Speaking of re-inventing the wheel, I'm liking BukGet, Niji I do get your point though. Another Warp or Death Notification plugin isn't really necessary. Fork and Pull Request, people! You're supposed to contribute!
I just learned of MoreSnow when reading this plugin. That's an awesome idea! Also, WildPlant is awesome, too! These are the kidns of things that need to be created as plugins. I'd run both of those! I don't need another TP plugin! (I've even ditched my original port of QuickPort because everyone runs WorldEdit and it does it better!) I have some awesome ideas for WildPlant, I'm gonna PM you
Yeah, I feel like plugins should be split up by function, not just "hey, this one does everything." If plugins only aspire to accomplish one main goal and allow the community to contribute, it's fine to have just one or two of the,
So before I get flamed for adding a new plugin submission... Does this plugin already exist - a plugin that loads item IDs from a configuration file and then prevents the use of any of the loaded item IDs by using a PlayerInteractEvent? Original thread here Edit: I'm asking because I'm pretty convinced that I saw a plugin that did this but I can't find it now
I had thrown a poorly made version of something similar to that by request- I used permissions instead of configuration. However, I never released it. I can't find a released version of that, I'd go ahead and submit
What I don't understand is the weight everyone puts on the Plugin Developer tag. Who gives a flying fuck whether they have some purple pixels under their name or not? It all comes down to the quality of their plugin(s) and how they interact with people having issues with them. That being said, I am not the best plugin dev here, or anywhere close.
