Safeguarding Against Unchecked and Potentially Damaging Plugins

Discussion in 'Bukkit News' started by EvilSeph, Dec 19, 2012.

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


    As Mojang continue to work towards the Minecraft Plugin API (cleaning up and rewriting the code), the code within Minecraft and CraftBukkit will undoubtedly shift. Fortunately, as the majority of the plugins available have been developed using only the Bukkit API (which was designed to be resilient and mostly update proof), this code shifting should not affect most of your servers.

    If, however, you happen to be running a plugin that uses code outside of the Bukkit API (like Minecraft or CraftBukkit code), those plugins are highly likely to break and bring down your servers with them - often without any advanced warning - whenever a Minecraft update is released. In response to this very real problem, we've had to make the difficult decision of forcing plugin developers that use Minecraft and/or CraftBukkit code within their plugins to re-evaluate their work with the release of every Minecraft update to ensure they are still functioning as intended.

    It is important to note that even if a plugin you have been using has been working fine across Minecraft updates until now, there is simply no way to guarantee that this will always be the case. Making the assumption that it will work with every update is like playing Russian roulette with your server.

    The problem:
    With the extensive work being done to Minecraft to accommodate the Minecraft Plugin API, the Minecraft code is now more unpredictable and volatile than ever before. These changes have made it clear that allowing plugins to run unchecked across Minecraft updates is a big mistake that puts your servers at significant risk of being silently damaged. Neither Bukkit nor plugin developers have any control over the Minecraft (and, as it is built upon Minecraft itself, CraftBukkit) code. Therefore, if a plugin uses code outside of the Bukkit API and it has not been verified to work on the Minecraft version your server is running, using it can only lead to unpredictable problems.

    What makes matters worse and more confusing is that there is no easy way for you, as a server admin, to tell if the plugins you are using utilise only the Bukkit API or unsupported code within Minecraft and/or CraftBukkit itself. As plugin developers have no incentive to do so, they have not been putting up a notice informing server admins that their plugins use more than just the Bukkit API and thus server admins are left in the dark. Without this important knowledge, server admins have been blindly running plugins that are not ensured to function as intended across Minecraft versions, potentially and unknowingly putting their servers at risk.

    Up until this safeguard was introduced, plugin developers were not required to verify that their plugins continued to function as they intended whenever a Minecraft update came out. As a result, potentially unstable plugins have been running unchecked on your server with no indication that they could damage your server at any time without any advanced warning. The fact of the matter is: plugins that depend on Minecraft or CraftBukkit code need to have their code verified whenever a Minecraft update is released before it can be said with absolute certainty that a plugin is safe to run on your server.

    In summary:
    - Mojang is cleaning up and rewriting the Minecraft code in anticipation for the Minecraft Plugin API.
    - Plugins that use Minecraft or CraftBukkit code will break in unpredictable ways.
    - You aren't told that a plugin is using unsupported and volatile code, so you likely aren't aware that plugins you are using could be silently breaking your servers.

    The solution:
    To address this problem, we've made the difficult decision of including a safeguard directly into CraftBukkit. This safeguard serves many purposes but the major ones are: it will help protect your server against unchecked plugins, it will make determining which plugins are breaking with every Minecraft updates and it will force plugin developers to take responsibility for what their plugins do to your server.

    With this safeguard in place, a potentially damaging plugin will not be able to run until it has been updated with a version that has been checked by the plugin developer. Granted, plugin developers have the option of completely bypassing this safeguard and putting your server at risk. However, if they choose to do this it will be very clear who was responsible for any damage done to your server and you'll know to avoid that developer's work in the future.

    Note: this safeguard is not intended to stop the use of code outside of the Bukkit API, but rather to promote more responsible use of it if a plugin developer decides to do so.

    So what does this safeguard mean for you?
    Server Admins:
    If you are a server admin that only uses plugins developed against the Bukkit API, this safeguard doesn't affect you at all. If you are a server admin that uses plugins which use Minecraft or CraftBukkit code (which we do not support or recommend using) then this safeguard means that those plugins will need to be updated with every Minecraft update.

    It is important to note that while this safeguard does force plugin developers to take some sort of action to get their plugins built against Minecraft or CraftBukkit working on a new Minecraft version, plugin developers have the option of bypassing it. They can blindly update a few lines in their code to mark it as working with a new Minecraft update or utilise a bypass to trick the safeguard into letting the plugin run. As such, we recommend that server admins be wary of plugin developers who decide to work around this, as they are willingly putting your server at risk.

    Plugin Developers:
    If you are a plugin developer that purely uses the Bukkit API this safeguard does not affect you in any way.

    If, however, you depend on the extremely volatile and unsupported CraftBukkit OR Minecraft code, you will now have to re-evaluate your plugins with every Minecraft update release. As this is what you should have been doing anyway as a responsible developer, this should not affect your update process in any way.

    We are not trying to make utilising Minecraft or CraftBukkit code within your plugins more difficult, we are simply trying to promote using it more responsibly if you have a need to do so within your plugins. If there is no way for you to avoid using the volatile and unsupported internals of Minecraft or CraftBukkit, we recommend trying to work with us to design an addition to the Bukkit API that removes this need.

    What if I'd rather take the risk?
    Server Admins:
    If you'd rather put your server at risk by running unchecked code, you are free to bypass this safeguard, however you will no longer receive support from us as a result. If you'd still like to bypass or disable this safeguard, you have the option of running an unofficial build or a tool to update the plugins you use. Unfortunately, since providing support for code we did not write is next to impossible, we still do not allow the discussion and distribution of unofficial builds within our community.

    Plugin Developers:
    Plugin developers bypassing this safeguard are willingly putting servers at risk with their unpredictable and unchecked code. If you as a plugin developer choose to bypass this safeguard bear in mind that you are taking full responsibility for anything your plugin does to a server and that this decision can affect your reputation as a developer.

    There are several ways to bypass this safeguard that I'm sure many of you will be discussing on these forums, however, we would like to make it clear that plugins using any bypass that includes dynamic code generation will be denied from BukkitDev without hesitation due to the inherent security risks it poses for servers.

    Whether you are a server admin or a plugin developer, you are free to discuss ways to get around this safeguard provided it does not involve an unofficial build. The issue with unofficial builds is that regardless of where people get them from, we almost inevitably end up having to provide support for them.

    We know that this safeguard might cause a few of you some headaches, however we feel that choosing to let servers burn in the coming weeks is not a viable option. Thank you for your continued support, cooperation and understanding in this matter. This was a difficult decision for us to make, but preventing unchecked plugins from silently destroying servers was a big incentive for us.
    Archarin, AlexMl, DanManB and 16 others like this.
  2. Offline


    Only if they don't update - which most do so not an issue. If you use NMS you take on a responsibility to use NMS wisely. This includes staying ontop of updates.

    The obvious bypasses will be stopped at submission stage. But yeah - people who bypass 'maliciously' will not make NoClassDefFoundError errors. They'll waste everyone's time and eventually fingers will be pointed, same as it is now.

    No one said the was a "100% solution". Instead it will make sure that plugin devs have a defined action to take to say "this is 1.4.5 compatable" . No more no less. Whether the plugin DOES work is as always the dev's responsibility, but they have to, in a roundabout way, declare clearly this is checked.

    I can see your point here - it would be an improvement on this feature if there was a way to scan plugins on load for all imports and stop them then if they use the wrong NMS classes. Personally I'll be putting in a version check myself, but it'd be useful to stop ALL functionality of a plugin IF it was going to loose part of it.
    I'll suspect this is impractical tho? Can anyone with a better understanding of java than me confirm/deny this?
  3. 1. The case for plugins not ever updating poses one of the easiest to see and probably biggest gains of this approach, so i am curious about numbers. Though that is a thing that goes for version comparison mechanisms in general.

    2. Bypasses might also be applied from outside, but basically this is a big uncertain thing on that side. My point is that those cases with bypasses or simple or erroneous updating pose the same threat to the whole system as before this change.

    3. The version check at startup makes 100% sense, though the Bukkit API does not support it yet, despite pure-API plugins also having use for it :) - one has to guess it from the unspecified Server.getVersion() output or indirectly do it with trying to set up fast-fail things in the constructors of your MC-version dependent modules, for instance (that is what i am doing).
  4. Offline


    It is really easy to find out whether a plugin accesses NMS. I practically did the same to bypass these changes in the past, although it then includes also renaming such uses. Doing this is very easily and not at all harms performance of the plugin.

    So right now I mostly here the following arguments, so I will try to give my reasoning for/against them too.

    It is the plugin developer's responsibility to update their plugins when MC changes
    Not really, it is up to the server admins to be aware that a plugin can start failing on new CraftBukkit builds, especially when the plugin developer clearly states that this is bound to happen. It is a possible 'choice' for a plugin developer to update his plugin, because he can also decide to send his plugin through a remapper to be done with it, or use reflection to get around compatibility problems.
    Plugin developers also have a life besides Bukkit, mind you. It is not like they spend an eternity in front of a computer screen; they have to educate themselves, become part of the working force of their country, and essentially develop themselves to go beyond what they are currently doing. You can not blindly expect all plugin developers to keep their plugins updated when MC changes.
    For example, if a plugin author uses one line of NMS code to do something unique, and the plugin is very simple yet essential for servers, he may decide to step out of it at some point. Before, these plugins would keep on working for ages, now they will forcefully stop working. Neither fun for the server admin, neither for the plugin developer.
    These changes will force plugin developers to keep their plugins updated, for an eternity. Even if they depend on a library managed by another team to deal with code obfuscation, he still has to update the plugins.

    People bypassing these changes are evil people and should be shunned
    Now you are just repeating what Bukkit tells you. No, these people simply do not have the time at hand to keep their plugins updated, and thus they will try to ease their life and abstract things out, so it can be bypassed. I did the same in BKCommonLib, because honestly, updating 8 plugins is too much for someone that has other things on his mind, too.
    People bypassing these changes are smart programmers. They know why they want to bypass it, they have their own reasons, and are not at all evil people. Evil people are people stealing plugin projects and deleting or reporting comments they do not agree with. But clearly, Bukkit's policy is to deny any of such workarounds and come up with banned plugin lists instead. I already know I am on the list of people they rather ignore, especially after they ignored my PR to fix problems in Bukkit after which another person just copied it and pushed it himself.

    These changes are amazing and will totally prevent ... what exactly?
    What do you think these changes will prevent? They will prevent server admins from running outdated plugins? Not really, as they are forced to bypass these changes using a modified CraftBukkit build. Some servers have unique plugins that were written months ago, that are now going to break. They have no hope of it returning, because the author already left. Consider the many paid plugin requests on these all this money now spent for nothing? Obviously server admins want to keep all the plugins they PAID FOR running on the server, even if it means doing something dangerous.
    Will it force plugin developers to update? Again, no, because they will try to bypass these changes, too. After updating the same plugin, without changes, 3x in a row, any sane person would consider making that piece of code dynamic. This can be done through reflection, modified server builds, or bypassing it in the plugin itself (disallowing it to be published on dev-bukkit)

    You are all just whining, it isn't that much work!
    Are you programming in NMS? Do you work with a lot of NMS code? Let me present to you, HOW MUCH work it is to keep my plugins updated for the last ->R1.0 changes. These changes include a lot of unneeded changes done by Bukkit developers, even though 'they do not support it'. Reading the changes you will understand why I decided to leave Bukkit development, and understand the principle 'updating the plugin to keep it barely alive':

    BKCommonLib: [1]
    NoLagg: [1]
    TrainCarts: [1] [2] [3] [4]
    All other plugins, luckily, primarily use BKCommonLib to interact with native code. Changes in SignLink, MyWorlds, Redstone Mania and Stream Remover are very minimal, but of course, they all have to wait for the massive amount of changes in BKCommonLib before I can even start to work on those. Note that the above changes exclude the 2 days I spent on debugging every single feature to see if I didn't forget to rename a reflection reference somewhere. At least before I could directly go to this step, knowing that it WAS working, this is no longer possible and I can now start debugging with the assumption that everything can be broken.

    Anyway, I can understand that many of you that do not 'run' in NMS code think these changes are not a big of deal, but for someone that 100% depends on all it's code, like me, it is useless to even continue development. In my case, bypassing it all using reflection is nearly impossible, and using classloader hacks is not possible because of dev-bukkit approval. Hence, I fix it up one time, and then I'll see who wants to do the above every 2 weeks again.

    Btw: Notice how this posted message will be ignored from now on. There you have another reason to leave this place, folks.

    Oh and before you ask: I merely write these paragraphs so I can get rid of any thoughts that are still remaining about Bukkit. It's good to write down something to prevent it echoing in your head for a week.
    Tsaukpaetra and EvilJackCarver like this.
  5. Offline


    @bergerkiller I think part of the issue here is that you are not a typical Bukkit developer.

    Your projects are a scale above the "typical" plugin. TBH with that much NMS code your not making Bukkit Plugins, you're making server mods.

    This time you've done alot of changes to move to your own utils classes instead of using nms ones, looks like future updates for this would be 90% changing imports and 10% finding NMS code changes after the work you just did.

    Looks like you had to do a fair amount more this time and have already made steps to make this easier for 1.4.6? I bet your 1.4.6 commit is much smaller.
    Also I can see from your commits you have had to release an update every MC version change.
    This is a bit childish. Every one of your previous posts has been acknowledged.

    In fact your above post was a well written counter argument - whether I agree with it all or not. You didn't need those last 2 sentences.
    Tsaukpaetra and HappyPikachu like this.
  6. Offline


    Your posts are so deconstructive and don't make sense. You are attacking great developers with your speech, feel bad.
  7. Offline


    Actually I just complimented this safeguards main critic on a well written rebuttal. And also commented that his plugins are an order of magnitude above the "typical" Bukkit plugin. ;)
  8. Offline


    If that was true, I wouldn't be posting that. During the discussions on GitHub there were no acknowledgements, only insults or poorly argumented reasoning that twist around the things I am saying. You are right about the last two lines, but for me, they are too much of the truth to not say them.

    You are correct, I am using a lot of direct server code. Let me quote something from my leaving text:
    There ya go. CraftBukkit WAS just as stable as Bukkit, hence people started using it in their code. Only since Minecraft started pushing out versions at an increasing rate did CraftBukkit become a problematic thing to depend on. This change adds up to the many changes in the past, worst of all, this change is forced and not an 'accidental obfuscation problem'.

    And unfortunately, no. Plugins using BKCommonLib contain imports to nms classes because they pass those from and to the methods in BKCommonLib. Some things can not be hidden inside a library. In TrainCarts and NoLagg this is the case everywhere, that this is happening in BKCommonLib is obvious.

    Please do not misunderstand my intentions here. I made BKCommonLib BECAUSE of the MC changes. It was meant to help me deal with the many MC changes. But now, with the package versioning changes, this entire intended feature is flushed down the Bukkit toilet, and I can just go and update all of my other plugins regardless. I have spent a lot of time to make everything safer and more stable, and instead of the Bukkit staff encouraging this or helping me improve this security, they are throwing insults, deleting posts, locking threads and forcing changes without discussion.

    They even dare to come up with an argument that BKCommonLib accesses too much NMS and that is why they do these changes. BKCommonLib was made specifically to overcome the problems described in the OP. But now, it serves no purpose any more. I could've just left everything in the plugins itself, I have to update those anyway. And since it is now effectively impossible to provide a safe framework for my other plugins without requiring my plugins to be updated every new MC (just updating BKCommonLib would be needed otherwise), I see no purpose in continuing plugin development.

    Oh and to those sticking to the argument:
    Nope. All I've been doing is, when I found an incompatibility in a plugin, I put this unsafe code in BKCommonLib. This includes obfuscated method renaming, base classes, changing logic or other things. For example:
    EntityRef (one of many)

    The work you see in there is the result of months of separation. It allowed the changelog between MC versions for other plugins to be nearly zero. The main goal was that only BKCommonLib would have to be updated, at some point. But all this work is now in vain, unfortunately. So why continue development if you know you'll be spending more time on compatibility than fixing bugs or adding new features?
    Tsaukpaetra likes this.
  9. Offline


    What do you even want to say with this? "Every plugin aka server-mod that is above the normal or uses NMS is automatically bad and shouldn't be allowed to use?" wot?

    As many NMS developers already said on commit comments: Most interesting plugins use native NMS code to even be able doing such interesting things. No one would use NMS if those functions would be available in the BukkitAPI but they aren't so there is no other way around using NMS.

    To list some: WorldEdit, WorldGuard, AntiCheat, NoCheatPlus, Chestshop, DisguiseCraft, ...
    vgmddg likes this.
  10. Offline


    Sorry - you misinterpreted my intentions there. I should have been more clear.
    The plugins bergerkiller made and listed above - are incredibly complex and, well, very good! I meant above - as in far better made and far more involved and complex that the "typical" bukkit plugin.

    I wasn't implying that NMS is bad or wrong - or using it is bad (I do myself in alot of custom plugins).

    TBH Iwas actually paying a compliment. And acknowledging that yes bergerkiller HAS been hit hard by this change as his plugins are DEEP in the territory of the worst affected.

    I don't agree with his points - but I can certainly understand why and how he feels the way he does.
  11. Offline


    the pig originally had 7 hearts.
  12. Offline


    You must be living in some type of fantasy land if you think anything you just said is even remotely true.
  13. Offline


    Would you like to make any rebuttal against what I have said, or would you like to simply insult me? For people who criticize the team for not keeping the community's best interest in mind or listening to their suggestions, you certainly don't provide much incentive for taking your opinions seriously with that sort of behavior.
  14. Offline


    It seems you understand our reasoning behind this commit, even though you want to ignore exactly what you just stated. The code, even though it may have seemed stable, cannot be relied upon as being stable. People, such as yourself, have came to think its stable just because it may not have changed recently. That, good sir, is just the illusion of stability, and this commit protects against that.

    Glad you agree with this commit then. Unless a server administrator is knowledgeable in Java, he would never know. This commit provides that information.

    I'm sorry, but you don't need to know how to read a single line of Java code to run a Bukkit server. If that is a requirement of running a Bukkit server then many servers simply would not exist today.

    See my quote above, which you seem to actually agree with.

    No one is holding a gun to their head. No one is forced to run a plugin that is outdated. Sure, admins can do that, but then again these admins now fully understand what is going to happen to them. Knowledge, as they say, is power.

    So, in essence, there is no different due to this commit, as my first quote from you stated, and you agree with, Minecraft internal code is now more volatile than ever. Those plugins very likely required an update anyway, with or without this commit.

    We do not allow monetary offers on these forums. If you are an admin and have paid for a plugin, but haven't had a contractual agreement with a legal entity for plugin development and maintenance of said plugin, that's the administrators fault. We realize most developers do not own their own companies, and likely do not enter into support agreements. Ever wonder why we kill, on site, every single monetary offer that hits these forums? Now you know. There is no way for us to protect any individual against monetary transactions gone wrong.

    You said above that Minecraft code is more volatile than ever before and you still feel its a good idea to bypass this change? I do not understand.

    Yet the code they rely on it volatile. Why would any sane person ignore that fact and dynamically work around it? If your only argument is because it takes work, I am afraid I do not agree with that argument.
    bergerkiller likes this.
  15. Offline


    Why can't we just get something like a plugin-white-list where we can add plugins which shouldn't be checked. I have my own server and all the plugins are only programmed for it (so many things are hardcoded). Should i really put them on bukkitdev only that i can use them ? (also i don't want to release them to the public)

    Does anyone have a simmilar problem?
  16. Offline


    Thank you for finally given a humane reply, I really needed one. I agree with almost all that you are saying, but I do think you should start looking into other 'big' plugins that use NMS. Many of them actually did do changes to use reflection as opposed to direct method calls to bypass these changes. You should also start looking into possible server forks that allow older package paths in plugins to be redirected, switching to such a server fork isn't at all difficult for an admin to do.

    And in my experience with server admins thus far I know that many do use plugins that were made on payment, or made by a friend at a small fee. I am aware that the plugin requests section no longer allows payment to be a criteria, but off-site payment still happens.

    Simple: To prevent having to re-upload the plugin, to prevent forcing all server admins to update their plugin too often, or to safeguard the future use of the plugin. Like I said, people develop plugins in their spare time, if updating it as often as MC changes is impossible to do, they will try to seek one final alternative that will prevent having to update too often. Another reason to bypass it is because he is getting a lot of issue tickets related to NoClassDefFound, of which he thought it was a 'bug that needed fixing'. A plugin developer can decide to bypass it if it stops the (possibly) endless stream of issue tickets relating to that error. Again, not all server admins are aware that the error has to do with an outdated plugin, and many will report it as an error instead of updating the plugin. Printing a warning message, or not enabling, like many said, is a better solution at all times. And finally, bypassing it to allow backwards compatibility of the plugin. Very often do people ask for a version compatible with 1.2.5 because Tekkit still uses it, and if your plugin allows to work on multiple versions, it will avoid this question being asked as much as it does.
    Tsaukpaetra likes this.
  17. Offline


    Easy isn't always right. Those admins get shut out of being able to provide bug reports, getting help, or anything else this community has to offer. Its easy to say "I'll just develop off of this other CraftBukkit build" or "I'll just run this unsupported build here", but when they run into problems they are on their own. Only the most experienced in both development and administration can handle that.

    That's their choice. They know what they are getting themselves into, or at least, should know. Perhaps I take years of IT experience for granted, but I've never paid for software without paying for support.

    Yet it doesn't provide any safeguard, at all. Only the illusion of such.

    I will guarantee you have received more money for your plugins through donations that I have, ever, received through what I do with Bukkit. Last update someone tossed me a $5 donation toward my server. That brings the grand total of money I have received to: $5. I put in hours each day into this project. No one is doing anything I do not do myself. It is, afterall, a hobby project. I take the good with the bad. This commit alone has caused me hours of time spent helping writing announcements, and responding to posts. You forget, we do this all for free, for the community we love, because we love doing it. Every update I respond to countless PM's about "When will it be updated" and deal with countless posts about "This build is buggy as hell, because <insert NMS using plugin here> has broke my server". I will argue that with a full time job, a wife, a server to run, and a slowly dying social life I have no more time than anyone else. I ask no more of you than what I do myself.

    That's a reason to update, not to bypass.

    I am sorry you get tickets. I have jokingly stated many times we should just shut down the forums until we get updates out for Minecraft, but where is the fun in that?

    This commit is brand sparkling new. They will learn. Give us administrators a little credit.

    mbaxter showed a great way to provide backward compatibility without bypassing this plugin.

    Point them to the old version that supports MC 1.2.5. You can't properly provide backward compatibility if the code you tie into has changed from 1.2.5 to 1.4.6. I'm willing to bed some of that NMS in 1.4.6 has changed since 1.2.5.
    bergerkiller and coldandtired like this.
  18. Offline


    Will the Minecraft API make Bukkit irrelevant? :(
  19. Offline


    I can now understand where you're coming from, at least it's a better reply than that of mbaxter that ended up insulting me and my plugin instead of answering...which ended up in a flamewar you had to end. Very happy at least one person is sane over there...

    I thought there were quite some donations going on for Bukkit? Am I mistaken? Surely some server admins over here like Bukkit enough that they give some donations...?

    I guess only time can tell then how severe the issues of this change will be, nothing is certain at this point. But please, do be aware of the changes taking place everywhere. Don't be surprised when suddenly server admins are reporting issues of CraftBukkit that were caused on a fork of CraftBukkit, because class remapping for plugins on the server is undetectable in the stack traces. (well, in some cases). These changes could potentially unleash a new abstraction layer caused by plugins making issue solving even harder, and you may have to jump in before it runs out of hand.

    I think I can understand why you do these changes, but you should try and keep track of the negatives of it too. There are quite some problems that can arise out of nowhere, and saying that it won't happen or that the issues don't exist will make matters far worse. (Apple 'virus-free', worse)
  20. Offline


    Donations to Bukkit go strictly to the upkeep of our services, and don't benefit any of us. None of has received a dime from doing this. I've gotten donations twice or three times for AntiCheat work, but nothing for just staff stuff, and I don't want to get any either.
  21. Offline


    TnT h31ix Wow, wait. You mean my Total of $35 in plugin donations is above average?
  22. Offline

    Devil Boy

    You shouldn't have to worry about DisguiseCraft and those other big plugins.
    We tend to get our plugins working for each recommended build pretty quickly.

    Unless of course, you're one of the many people who use CraftBukkit dev builds to keep your server up to date with Minecraft versions. In this case, you have to wait for us all to update for even minor changes.
    But don't fret! At least your dev-build-running server is protected from "silent damaging" :D
  23. Offline


    Oke? Makes sense but now?
    How do i find out right know what plugins are good, and which need replacement?
    Cause if that update shows me 10 plugins need changing before/on that changing point? thats gonna be one hellish week!
    vgmddg likes this.
  24. Offline


    Run a test server. See which plugins break. Seek out replacements. Once you're comfortable your server has the necessary plugins, update your live server and plugins.

    I regularly run without one or two plugins for the first while after a new build, as there are always plugins that need updating - regardless of this commit.
  25. Offline


    It's probably been said before, but there is API for lore on items. I was playing around yesterday trying to figure out how to create fireworks and the itemstack metadata has a lore collection.
  26. Offline


    Yep, Ammar Askar pointed it out to me. There's also an API for coloring armor, and other stuff for books etc. Don't know how I missed that commit actually.
  27. Offline


    Hm to be honest, i still don't get it. Updating to the *recommended* build rendered almost all of my installed plugins non-working. After updating *some* of the plugins (which were updated by their maintainers in the meantime), the server still won't run because of some of the most important plugins still won't work (prominent plugins like citizens, multiverse, voxelsniper and terraincontrol being some examples). So currently i'm sitting in front of a wrecked server and will have to restore a backup to get it working again.

    Does all this mean i'll have to throw away my server and restart from scratch, leaving away some of the most interesting plugins?

    So why do you call this build 'recommended' when almost nothing works? I work for a software company. If we did something like this to our customers we'd have the house full of their lawyers, sitting in our necks and forcing us to restore the previous version's behavior.

    Really awful idea, to actually force admins to disable plugins which weren't updated (though they actually could work, if the new class naming weren't there).

    Don't get me wrong, i understand the reasons behind the change involved, but it's totally unfriendly to server admins, and in that respect, badly thought out.

    Sadly restoring today morning's backup
    vgmddg and poiNt_3D like this.
  28. Offline


    Multiverse works just fine :)

    I found any plugins of mine that needed updating already had an update available within hours of the CB dev build being released.

    Your server would have been damaged without this commit.
  29. Offline


    It's never a fun time when an update breaks major plugins. That's why I always create a test server using a recent backup, then update CraftBukkit, see what plugins break, see if those plugins have updates or development builds, and based on that, make a decision as far as whether or not I want to push the update live or wait until more plugins have updated. Servers need some level of version control as well, it's rarely a good idea to start tossing updates into a production server.
    No, it means you'll need to wait for your essential plugins to be updated, or seek alternatives if the developer has become inactive.
    Because CraftBukkit itself works, has been tested, and is considered stable and API-complete enough to be recommended for production servers. If plugins don't work with a Recommended build, it doesn't mean that the CraftBukkit build itself should not be considered Recommended.
    From what I understand, the plugins that broke due to the new class naming would have broken anyway due to changes made in the volitile code that they rely on outside the Bukkit API. They would have just broken in different, potentially silent and/or deadly ways, rather than providing an error clearly indicating that there's a version problem.
    As a server admin, I certainly don't find it unfriendly. A brief anecdote:

    A few months back, I loaded up a test server and updated CraftBukkit without updating any plugins, as previously mentioned, to see what would break. Everything seemed okay, until I noticed that there were random chunks throughout the world that were missing stone. So on the surface, it would be grass, dirt, trees, no issues, but under that, nothing but ore, air, and bedrock. After a few hours of troubleshooting and reading what few other reports there were on the topic, I found it was an issue with one of my plugins, which notoriously relied on code outside the Bukkit API. And because that code changed and the plugin had not been updated to reflect those changes, there was no error or any indication of any sort of problem.

    I believe that's the sort of situation that we're trying to avoid here.
    Glad to hear you had a backup :)

    EDIT: TnT beat me to it :p
  30. That's not entirely accurate. It may go for some plugins for some cases, especially those using obfuscated methods, but some other plugins might have had absolutely nothing to update, except to copy and paste their old modules due to the package renaming both for 1.4.5-RB and also for 1.4.6 so far. The change from 1.4.5-beta to 1.4.5-RB and then to 1.4.6 would have left many plugins 100% operable. Despite the risk of potentially arbitrary changes being always there in principle, the probability for quite some of the methods and classes of NMS/OBC changing (Edit: in a nasty way) is not that high, unless Bukkit followed a policy of deliberately making things more complicated than necessary. No question this can't be said of all plugins / "potential fields of interest" concerning NMS/OBC, some may be very prone to such subtle changes, still it is not the general case that plugins would break, especially not silently.

    In fact it would be interesting to analyze the potential breakages of one or another kind. Could be done automatically for a part, given the history of CB builds. Then of course one would have to find out, what methods are/were used most by plugins, also by what kind of plugins, so one can get a more profound impression of how things change.
    drtshock likes this.
  31. Offline


    You obviously don't know life... that's life every developer based company or project has things that need to be done to make this more stable and flow better, whether or not Plugin devs can bypass this or not that's moot, You are obviously just a troll trying to get as much views and attention as you possibly can. You obviously don't hang out with programmers like I do or code period for that matter. I may not know how to code real languages and I can only really do HTML/CSS but I hang around programmers enough to know what bukkit implements is life. this project was a mess at first but it have most definitely come along way they are trying to keep and make GOOD STRONG CODING STANDARDS! and anyone that thinks making standards for people to follow is stupid then you need to get off the computer because THEY HAVE STANDARDS THEY NEED TO FOLLOW FOR THE HARDWARE TO FUNCTION AND FIT IN THERE.


    HTML CSS all follow standards if you use Google Chrome or Firefox you can see how clean websites can look and then you do to IE and they don't follow standards and then you start seeing websites break apart and fail and then there are the noobs that write there websites to work with Internet Exploderror and they lose lots of business because people that have a brain and use logic KNOW to avoid IE at all costs so they lose that traffic of the none IE users.

    Albeit USB and HTML CSS etc they follow standards and are able to be backwards compatible Bukkit rarely is backwards compatible with the clients and a lot of problems occur that they cannot prevent because they did not write nore have proper access to the source of the OFFICIAL MINECRAFT SERVER OR CLIENT! so there for they CAN NOT PROMISE OR GIVE THERE WORD that any updates THAT MOJANG BRINGS OUT will allow plugins to function it's not Bukkits fault Mojang sucks and didn't do it right from the beginning.

    Bukkit just wants to make standards for there developers and plugin developers to follow to help make it smoother with updates whether it takes longer for the updates to be released or not seriously I'd rather it be proper then pushed out with out proper checks.

    People like you need to stop making Bukkits forums like a Tuesday on the WoW Forums but daily.


    I did not want to double post

    ANYTHING CAN BE CRACKED AND HACKED TO MAKE IT WORK IMPROPERLY! (key word there IMPROPERLY) where there is a will there is a hacker(coder) willing to do it for them.
Thread Status:
Not open for further replies.

Share This Page