[Useful Snippets] A full list of my recent contributions!

Discussion in 'Resources' started by bigteddy98, May 4, 2014.

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


    This resource is no longer availabe.
  2. Offline


    I should make a Useful Snippet about the best coders on Bukkit.

    Anyways, couldn't you just put all this in your signature? I have never realized you have accomplished all of this, and not everyone will look at this resource; but everyone can see your signature.

    Also, where did you learn so much about NMS and OBC? You might as well just call this Making Mods.
  3. Offline


    That's a pretty awesome idea, will start on it in a moment :D.
    I really like the way mojang handles many things in NMS. When I have a problem I just take a look in here and check out how mojang handles these things. On that git you can find some pretty awesome things.

    Finished it pretty big list haha


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


    Wow. I thought you and the other developers had some secret website... I guess it is just the source. Thank you so much!
  5. Offline


    Not to rain on anyone's parade, but I want to provide a little perspective. All I see here is a list of ways to make brittle plugins that may or may not break on Minecraft updates (impossible to know until the actual update hits), regardless of whether the Bukkit API changes or not. At the very least, you should make people aware of the consequences of messing around in nms, instead of making it sound like it's the end all, be all of plugin development. I would call these "dirty hacks" moreso than "useful snippets", because that's what they are. Depending on an everchanging implementation instead of a stable API is walking a fine line between brave and stupid. In the real world, these kinds of approaches will raise a lot of eyebrows at best, and in the worst case, you may get laid off for writing unreasonably high-maintenance code. And I just want to stress that I'm not trying to be a party pooper; I think the overall initiative is great, but the content needs a disclaimer, because it's got "bad practice" written all over it.

    "But the dirty hacks are necessary to do these things!"

    Yes, they are. The Bukkit API is quite lackluster from certain angles - especially anything that deals with "custom entities" - or anything "custom" related to entities, really. I've got the feeling the promised transition to string-based identifiers will open up a lot more possibilities w.r.t. entities and items, but even if it doesn't, it could just very well be that some of these features never get implemented because people don't actually contribute. I honestly think that a lot of the things people fool around in nms for could exist as part of the Bukkit API by now if they would just take the time to think of low-maintenance implementations and make some pull requests.

    And just to once again stress that I'm not trying to make this out to be "all bad"; I think it's important that people explore the implementation, because that's what makes way for the progress of the project (as long as people also eventually contribute). I just think that celebrating bad practices is a bit out of place, especially considering the abundance of beginners in this community. People need to be aware that these methods are dirty (and why), so they know to only use them as a last resort.
    Assist, TnT, mbaxter and 1 other person like this.
  6. Offline


  7. Offline


    Many people, even beginners, are fully aware that NMS may or may not break on every update. That is why Bukkit implemented the v1_7_3R etc. stuff in every update, so people are aware that this kind of stuff is deprecated. People still use reflection to work around all of that to make some awesome things. I think you should be praising him, not raining on his parade, because he has created some really awesome things. I know you are just trying to admonish beginners, but the stuff about DANGER: DON'T USE NMS is prevalent.
  8. Offline


    Thank you, sir! :)
  9. Offline


    I'm not sure your biased interpretation of the versioned packages is healthy for the credibility of your point. They were implemented with the server owners in mind - the people truly affected by careless actions of developers. The idea was to get developers to either depend solely on the Bukkit API (as they should), or force them to recompile and verify their plugins on every update [1] - not to make it harder because they didn't like it. The dirty reflection hacks you see now and then are a direct circumvention of the whole idea, and it brings the server owners at risk yet again.

    There are two points to be made here:
    • Server owners are the end users, and the Bukkit team has to do what they can to protect them from incompetent, careless, and/or reckless developers. By circumventing the measures the Bukkit team takes to try to help the end users, developers are making themselves "bad guys", while ignorantly blaming it on the Bukkit team for "making things difficult", thinking there's nothing wrong with what they're doing. Don't underestimate the arrogance and ignorance of people - especially not software developers, who seem to be some of the most sensitive craftsmen.
    • Dirty hacks are called "dirty" for a reason. It's not because they're "good" and make a project shine, it's because they are "bad" and make a project brittle and high-maintenance. You say that "many people are fully aware", but you have nothing to back up that claim, and considering the lack of actual disclaimers in these kinds of guides, the truth may very well be that most people who use these hacks think of them solely as "1337 skills", when in fact, they are just very bad software design practice. Just because you know doesn't mean everyone else does. Poke a hole in your Bukkit-bubble, and you'll see just how poorly the celebration of these kinds of hacks translates to the real world.
    And like I said in my first post, I am not raining on anyone's parade. I am providing some much needed perspective. I see no point in encouraging something that is widely understood by seasoned software developers in all fields as bad practice [2] [3]. But like I also said, I like the initiative, and I've praised bigteddy98 for his spunk. I just think that his energy could be better spent on something that will actually help the Bukkit project progress, but more importantly, something that won't result in a flurry of brittle plugins that will eventually hurt the end users.

    [1] http://forums.bukkit.org/threads/sa...cked-and-potentially-damaging-plugins.116749/
    [2] Design Patterns: Elements of Reusable Object-Oriented Software, Gamma et al., 1994
    [3] http://stackoverflow.com/questions/383947/what-does-it-mean-to-program-to-an-interface
    TnT, mbaxter, MCForger and 1 other person like this.
  10. Offline


    Damn, the first picture is awesome.
    Marry me, bigteddy98
  11. Offline


    Most people that use NMS, understands that it can be dangerous and has the potential to break servers. A lot of server owners that I've come across know that there are plugins that use this magical thing that isn't directly supported by bukkit that can be dangerous to their servers however these plugins can do things that you just can't do with just the bukkit API so in certain cases it's completely worth it especially if you know that the plugin developer that is making a certain plugin is competent and will try as hard as they can to not break your server. This being said, it is a terrible way to circumvent the protection to server owners brought about by the dynamic package name changes to dynamically access the packages yourself through dynamic calls. However, I do think it's fine how bigteddy98 is doing it, from a quick glance here, as he is actually making completely new classes for each version of bukkit specifically so that it does the correct things in accordance to the correct versions.

    I am completely confused as to what you are trying to refer to with your [2] and [3] as those are completely viable practices that I've used by myself and along side people that program for a living. It sounds like you are trying to say that they are bad.

    Anyways, most of the things that bigteddy98 has done here (I only took a quick glance at most of them) are completely viable and safe and won't break any servers assuming he keeps them up to date correctly.
    bigteddy98 and DevRosemberg like this.
  12. Offline


    As much as I hate to break people's posts up into little bits that could be taken out of context, I'll do it here to target specific points. I'm sorry if I've broken some context in the process.

    Reiterating what Bungee said doesn't change the fact that it's an unbacked claim, and even though it's only speculation, you're still not confident enough to say "all" instead of "most". Considering the amount of "nms pushers" in the Plugin Development subforum (which is full of beginners) that never mention the ramifications, I think it's fair to assume that a lot of people don't understand. Again, I'm just providing perspective.

    The final if in this statement is what breaks its otherwise somewhat reassuring message. How many plugins that use nms openly state it and warn the server owners? None that I've seen. And of course they don't. They want people to use their plugins, not scare them away. And how are server owners supposed to gauge the competence and devotion of a plugin developer? By the release rate of builds? Some plugins don't need updating very often (especially if they are in a stable state and only depend on Bukkit), but that doesn't mean the developer isn't confident or devoted. You're expecting too much of people if you think everyone who ever made a plugin is a seasoned developer who knows what they're doing, and if you think that server owners will engage in long conversations with plugin developers to figure out if they trust their work. I'm exaggerating, but I hope you get my point.

    The only thing he accomplishes in that example is moving the reflection turd into a semi-nice wrapper. It's still a turd, and it will still break on updates - the only difference is that it will be guaranteed to break for unsupported versions, whereas the other reflection turds may or may not break depending on whether or not the implementation changed. I guess in that respect, it is an improvement, because it forces the developer to take action when new versions come out. The biggest issue is probably the vast amount of code duplication that will accumulate inside the project (the example classes are small, but it's ignorant to think that that'll be the case for all cases) - something that doesn't happen when you depend on Bukkit and let the changing implementation stay inside of the different Craftbukkit versions.

    I wanted to use the references to widely accepted "good practices" to back up my claim about the bad practices displayed here. I can see how it would be a bit confusing, sorry about that. So no, [2] is considered by quite a lot of people much smarter than myself as the "object-oriented programming Bible", and [3] is an example of members of a (hopefully) well-known community explaining the "program to an interface"-principle.
    TnT, mbaxter and MCForger like this.
  13. Offline


    If you don't trust us then take your own poll, I know that from experience and helping people out with NMS. I also make sure almost always to reiterate to them the dangers of using NMS. And about these beginners. If you're talking about beginners to bukkit and to programming, I know of none that can use NMS the slightest bit successfully. If you're talking about beginners to NMS, they need A LOT of help before they are able to make anything work, by the time they are able to actually do anything they know that it can be dangerous if used incorrectly.

    Why should plugin creators warn people about something that isn't going to happen? What I mean by that is that if you use NMS correctly, it won't break anything. And you can easily judge the ability and competence of plugin developers by how they interact with their users.

    From what I saw, what he's doing is ensuring that previous versions of bukkit work fine however once a new version of bukkit comes along he has to create a new package and class to support that. It causes his plugins to not be able to work at all with any new version of bukkit until he updates it, however it will continue to work with multiple old versions of bukkit. When I said dynamically multiple time I meant people doing some thing like this:
    1. Class.forName("net.minecraft.server." + getCurrentBukkitDenotionHere() + ".EntityCow");

    Doing that will still allow your plugin to run across many versions of bukkit but once that one a() method changes to b(), it will crash the server. I do agree that the above code should never be used as it is a terrible work around by lazy devs.

    And if you're scared of incompetent people making plugin that use NMS and crash servers with it, it's just as likely that they will crash servers without any help from NMS. I myself have crashed loads of server for reasons that have had nothing to do with NMS and have never once released a plugin to the public that uses NMS that has crashed a server because of the NMS. No one has ever brought up a problem to me that could anything to do with my NMS code that is potentially game breaking. And I use A LOT of NMS in some of my plugins.
  14. Offline


    Jogy34 garbagemule
    Basically to sum up this conversation: Awesome libraries, Use NMS, Detrimental to Server Owners Unless They Are Fully Aware That They Have To Update Every Time.

    Lesson of the Day: Don't use NMS unless you want your server to be really unique and are dedicated enough to update the plugin on every server update.

    I think bigteddy98 is directing his audience to developers who are making private plugins. It seems that these utilities are more fit for custom minigames to set one network apart from the other, as a strategy to get more players.
  15. Offline


    Trust is a strong word. I'm just pointing out that (very limited) empirical data cannot constitute a rule. The times I've seen people help others by suggesting nms, I haven't seen any warnings, and there is no indication of whether or not the OP understands the consequences. Again, I am just providing perspective. "Proof by contradiction" works for me because the claim you're backing reduces to "for all" - your experience cannot constitute a rule of "for all" when my experience contradicts it with "there exists".

    You keep breaking your own arguments with your "ifs" - breakage will happen, and it has happened, many times. Why do you think the versioned packages were introduced in the first place? Your second point lacks striking power because it's too vague, but no, you can't gauge a developer's competence by how they interact with their users. There are reasons (beyond "sounds cool") why "customer service" and "lead developer" are completely different people in many software companies. One is better at dealing with customers (or users), while the other is better at developing software. Personally, I'm only polite, friendly, and responsive towards my users when they show me the same courtesy, and quite a lot of my "user interactions" revolve around unenthusiastically linking Wiki pages. But I guess I'm just a terrible developer. Good thing I'm not using nms, eh?

    That is exactly what I said. Sorry if I wasn't clear.

    In summary, you're a terrible Bukkit developer, but you're alright at making dirty hacks? ;) Playful banter aside, you're absolutely right. It's very likely that an inexperienced developer will bring doom to the servers that run their plugins (I've had a lot of rants about heavy PlayerMoveEvent handlers in the past), but that does not excuse opening up an additional minefield. If you have ever worked in C++ (which is, always has, and always will be an expert language that is easy to learn, but impossible to master), you'll know just how unfriendly a programming environment can be when you're given 99 ways to shoot yourself in the foot, but only one way to avoid it.

    I'd like to point out, once again, that I am just providing perspective. My point is not "don't do this", but rather "if you do this, know what you're doing, and if you teach this, teach it from both sides of the coin". There are issues with these hacks, so please stop trying to hide them. And my point still stands about contributing instead of circumventing. Why write a guide about dirty hacks when you can make a pull request and write a guide about doing the same thing with the API? :)
    MCForger likes this.
  16. Offline


    I'm using a statistical null hypothesis that μ = 0.7 where you are trying to prove an alternative hypothesis that μ < 0.7 (I'm saying a majority (at least 70% here) you're saying not a majority). And since neither of us are ever going to actually take a sample of bukkit developers who use NMS and know the potential dangers of it, and do the calculations, were going to have to disagree on this as neither of us are ever going to convince the other without proof as our experiences contradict each other.

    I wasn't saying that breakages won't happen at all. I'm saying that when you know that what you code isn't going to break anything there's no reason to warn people about it. That's like saying, "Hey, you might get poisoned and die from that apple that you just bought from the supermarket." It just causes useless worry.

    I'm not saying that competent developers talk nice and pretty to their users, if you get someone repeatedly asking stupid meaningless questions or making absurd accusations, almost anyone here would ridicule them. When it comes to fixing things and helping your users, the competent developers are going to do it right. If someone comes to you with a bug (assuming you actually are competent) you'll probably either know exactly where to look in code for it and how to fix it right away or you'll work through it with them and find some way to repeat it then work at fixing it for the next update. Developers that aren't competent will just brush it off like it's not their fault or make the problem worse in the next update from not knowing what to do.

    I'm still saying that the way bigteddy98 does it is perfectly fine.

    I know exactly what you're talking about with C++ but there are always multiple ways to stop it. There are also so many more and much better, as you call them, "dirty hacks" that you can do in C++ that you can't in java, for instance, just not having a foot.

    I'm not saying there aren't issues with NMS techniques if they are used wrong. I started arguing against you because you told a hard working developer who's trying to help bring exiting features to other people's plugins that all the work he did was a complete waste of time. And bukkit will never be able to implement everything into the API that we want to do and can do using NMS.
  17. Offline


    I never said anything about "not a majority" - it doesn't matter how big the majority is and whether or not that majority uses nms knowing the potential dangers. What matters is that there are people (majority or not) who use it without knowing the potential dangers. There are also people who don't use it and don't know of the potential dangers, and they are the people who can be accounted for by telling both sides of the tale (which isn't happening right now). Please don't twist my words.

    But you don't know if your code is going to break (due to the very nature of the obfuscation algorithm, but also due to possible internal refactoring in Craftbukkit), unless you either do what bigteddy98 does with his polished reflection turd, or use nms directly. At that point you know that it is going to break on updates due to the way Java's class loaders work. We may be talking about different kinds of breaking, but surely you'll agree that your plugin will (assuming direct referencing or bigteddy98's wrapper) throw NoClassDefFoundErrors (whether they are caught or not) as soon as the server owners update their Craftbukkit version? Thus, plugin breaks on updates. Is that not something server owners should know about when they download the plugin? Since I can't apply the apple-from-the-supermarket analogy very well here, I'll stray a little: isn't "if you use this particular apple in your salad, the salad will be poisonous, but if you wait a little, I will give you an apple that will work just fine" better than staying silent about it and have people die from food poisoning because you thought everything was gonna be fine (what a morbid analogy this turned out to be)? I really don't understand how you can advocate dodging responsibility, because that's what it is.

    And what about those in between who decline tickets because they require the use of nms, like myself? Which camp do I belong in? Am I "incompetent" because I don't want to make my project brittle and high-maintenance? Am I "neglectful" because I don't answer every feature request with "Right away!" due to impractical requirements? The backwards-compatibility (old plugins, new Craftbukkit) allows me to only update my project when absolutely necessary. Unless I need features introduced in later builds, I can keep targetting the same "old" build, and still be compatible with all the newest builds (until something breaks in the API, which is true for both hacky and non-hacky plugins). Comments like "it's so nice that it doesn't break and just works" really just mean "you're incompetent and I hate you". I hope the sarcasm is obvious :p

    And I'm still saying it's better than the naïve reflection because it allows for a wider range of supported builds, but it still breaks on new builds, and server owners should be informed, and they can only be informed if the developer is informed and takes responsibility. Again, the end users are the server owners, and they are the ones we should be catering to. Being lazy, prideful, irresponsible, and/or reckless about these things would be a bigger sign of a lack of competence or devotion to me, if I was a server owner, but that's just me.

    I think it's completely uncalled for of you to twist my words like that. Not once have I said anything about his work being a complete waste of time (I quote myself below for easy reference). Some of these things could very well be part of Bukkit, but you're right that some of them can't (because of the "vanilla with a twist" principle). For those that can, however, who would be better suited for making the necessary pull requests?

    Wingzzz, TnT, mbaxter and 1 other person like this.
  18. Offline


    You never seem to not impress me in your responses to flawed questions/answers

    Thank you for doing the sky factory. I thought about doing that a while ago but then decided I did not really have a need for that feature, but now that you made that class, I might have to think of some plugin ideas.
    bigteddy98 and garbagemule like this.
  19. Offline


    I never said that all people that use NMS know the potential dangers or that all people that use NMS know how to use it properly. Don't twist my words (from your post before my last one).

    I don't think I ever actually made myself clear on this, when I kept referring to breaking someone's server I meant only the server. ANY plugin that uses ANY NMS code should break with every new bukkit version that introduces even slightly changed NMS code. The whole reason for this and behind the dynamic package names, as you know, is because of the obfuscation that Mojang uses which causes a lot of the methods to be switched around and their names changed with every recompile. So if you keep using the same methods and variables version after version you will break the server your plugin is running on. And when I said, "when you know that what you code isn't going to break anything", I was referring to breaking the server (crashing a server, corrupting things, etc...) for the specific version of bukkit that you made your plugin for.

    What??? I was never referring to using NMS there at all. This part had nothing to do with NMS. I was talking about general bugs in your code which everyone has for any slightly complicated plugin that get's continuously updated.

    Again, plugins that use NMS should break on new bukkit builds that contain changed NMS code. It's the job of the plugin developer to get their plugin working as soon as they can for new bukkit builds. Even though you weren't really saying anything about this, in my experiance, server owners would typically also rather have plugins with more and better features but break on every bukkit release and take time to update on every bukkit release than not. This I actually have a bit of backup for.

    This is what I saw, and still see, as you saying that all the work he did was a waste of time:

    When I think of the 'Bukkit Project' I think of everything that is a result of bukkit, so the API, the plugins, the developers, the users, the entire community. So what I got from you saying that all of his tutorials, he techniques, everything he did, was just a complete wast of time in your own opinion. Sorry if I misinterpreted what you meant, but that is how I read it and thus the entire reason that I'm arguing against you.

    Not to mention that you keep referring to his backwards compatible version system as "reflection turd";
  20. Offline


    And my point still stands. As much as you want me to be an adversary, I'm still just providing missing perspective with nothing but the best of intentions :)

    In which case, we agree.

    Replace "using nms" with anything else that has a similar effect of making the project brittle or high-maintenance, such as "dependency hell" (how would you like to write "support" for 150 random plugins?) or "configuration hell" (how about making every feature request an optional, config-activatable, per-something setting?), or perhaps implementing features that you know will cause a significant performance hit. How about plugin conflicts that can't be resolved by you? You can't gauge competence and devotion based on such a simplistic metric, and even if you believe you can, other people might not be able to.

    As much as I'd love to compliment you on backing up your claim, it's just way too small of a sample out of way too small of a portion of server owners, not to mention the user domain being pretty specific, and the comment insinuating that some people have been complaining about slow updates (of course, this could just as well be the same people who update to unsupported versions of Craftbukkit before an actual Craftbukkit build is out, just to see their entire server crash because they were too impatient). As busy as I am, though, I often have trouble making time for even a small update (you probably know just how much time goes into testing stuff when unit testing is unavailable/infeasible), so I'm pretty sure my channel and ticket system would be flooded with "pls updaet soon bcuz i ned it FAST" if I had to push new updates for every new Craftbukkit build.

    I've seen a lot of great potential in nms hacks over the years, especially w.r.t. entities. No one would be happier to see some more advanced and finer-grained entity control than me, since that's all my plugin really is about. If some of these hacks could be turned into actual, supported features in the Bukkit API, more people could benefit from them without having to worry about breakage. A lot of nms hacks, especially the really simple ones, could very well be part of (Craft)Bukkit, so keeping them as nms hacks and advising people to use them instead of just contributing by making a pull request is clearly spreading the brittle pieces out on to many plugins that will all have to individually update their copy of the hack on updates.

    Like I said in my first reply to you, his hack moves the reflection turd into a semi-nice wrapper. I've already acknowledged the benefits, but it's still a dirty hack for the reasons previously mentioned, even if it appears to be "perfectly fine" at first glance.
  21. Offline


    What exactly is the point you want to make here? I understand that you're trying to say that using NMS code can and probably will brake once or more times. But what exactly is your point? The most cool features of minecraft simpely can't be used without using, as you call them, "dirty hacks".
  22. Offline


    - Rains on everyone's parade.

    NMS good, but also bad, but also good. While I agree that a lot of the simple changes could be made into pull requests and shared, I really don't see the big deal if most of these changes are going to be affecting a minority of plugins. I really don't see why you feel the need to comment on things that anyone writing NMS plugins, already know.
  23. Offline


    garbagemule Jogy34
    Please. Just stop. Let's just all agree that NMS is AMAZING for real experienced developers and server owners, and it is bad for the less experienced. If I missed something, don't yell at me because I do not have time to read all of that :p
    ArthurMaker likes this.
  24. Offline


    I understand how you would get confused in the walls of text that seem to have sidetracked quite a bit (assuming you went through them), but my point is to provide the missing perspective of "but it doesn't come without issues" - issues that you (and quite a few others) forget about or brush off as "unimportant", even though you are not the ones who will suffer the potential consequences. Let's not forget that you provide these resources for other developers (assuming your intention is to help and teach), who may or may not know the consequences. Your post is full of "look how amazing this is!", and it should be, but it leaves out the inherent issues, so I call attention to them for completeness. My input is provided solely as "additional info", not "this is shit" - again, not raining on anyone's parade, just helping out. People have a tendency of taking things a bit too personally, though. I hope you don't, because you shouldn't.

    Feel free to read through the walls of text for my arguments refuting this exact claim. Besides, and like I've said above (and before), I'm just providing missing perspective. I see no "nms plugin developers club members only" in the opening post, so I strongly assume these resources are meant for anyone who wants to use them - even someone who doesn't normally write nms plugins. I find it extremely surprising just how easily you guys seem to take a defensive stance of "OMG JUST LEAVE BRIT... BIGTEDDY98 ALOOOONE". I am not doing or saying anything to hurt him in any way at all. I am just providing additional information for completeness, for developers who don't know that information already. If you already know this information, you are not the target audience, and thus it doesn't concern you unless it's downright wrong, in which case the right thing to do is correct me. All you seem to be saying is "shut up, nms is amazing, but it breaks and so what, it's still amazing", which is ridiculous - your defensive stance is unnecessary.

    BINGO! But outside of my post, you see nothing but "nms is amazing". If there was any "for seasoned developers who are willing to update their plugins on every update and inform server owners of the (potential) breakages, but should probably not be used by inexperienced developers, or developers who prefer a better guarantee of stability for future builds", I would probably not have posted anything (I would perhaps have posted about breaking the "program to an interface"-principle, though). Again, and hopefully for the last time: just providing missing information.
    TnT and ampayne2 like this.
  25. Offline


    I really shouldn't need to do this especially as I have seen, along with BungeeTheCookie pointing it out, that our arguing back and forth with neither of us actually pointing to any actual proof behind anything we're saying is just a complete wast of time and is especially annoying to anyone who has come to this thread to see all of the things that bigteddy98 has done, as that is the point of this thread. Because of this I am going to withhold myself from making any more comments against you here after I have said my final piece.

    You claim that you are trying to spread awareness about the potential dangers of NMS to developers that don't know about these dangers. I am still going to say that the vast majority of developers that use NMS know of these dangers. The one's that you keep referring to will harm maybe one in every hundred servers (which is being very generous) typically to the point where the server owner just has to start up the server again losing maybe 5 hours of unsaved progress (again being generous here) and potentially having to remove the plugin that caused it with maybe one in every thousand of those resulting in slightly corrupt data that may be somewhat harmful to game play and possibly only ever once in a blue moon possibly causing a complete server reset where everyone looses everything. This still leaves 99 out of every hundred server crashes that are caused by non NMS related things. Why are you not petitioning correct practices of coding and bukkit API use for those? Why are you not, yourself, finding game breaking bugs with the bukkit API? Instead you say you are trying to tell people about potential dangers of something that the vast majority of plugins and plugin developers don't use in a single thread whose actual original purpose was just to showcase a developers hard work which you then proceeded to try to shut down.

    That is the last I'm going to say here as, again, it isn't a thread for this and I should really have stopped myself sooner. If you would like to continue arguing then go right ahead and make a thread for it instead of using someone else's.
  26. Offline


    The "honorable retreat" or "agree to disagree" only works if you do it without further argument. Most people would consider this act childish and disrespectful, but then again, I guess bad manners aren't surprising from an advocate of bad practice ;)

    You really shouldn't have felt the need to comment in the first place, because your "crusade" has been completely out of place from the very start. I would blame it on bad communication skills from my side, but despite my lengthy explanations and constantly repeating myself in various ways, you still fail to see that there was never anything for you to get defensive and upset about.

    Oh, and bigteddy98's stuff is all the way at the top for everyone to see, and there are no warnings or disclaimers or important information anywhere, and considering how extremely sensitive the "nms club" is to constructive feedback, it'll probably never happen. All is well. You can put down your hatchet, because no one wants to fight you.

    I still have absolutely no clue how you progress from the first sentence of this paragraph to the rest. Yes, I'm trying to spread awareness. How is that not a positive thing? I'm not raining on anyone's parade, and I'm not saying bigteddy98's work is bad. You have no reason to be upset, and your quest to remove safety labels is ridiculous, because the potential dangers are not obvious to newbies. They need to learn from somewhere, and the most natural place to learn is from the source. Take a step back, wipe the angry froth from your mouth, take a deep breath, and then ask yourself whether or not it would actually hurt to inform people about the inherent issues (hint: it won't).

    You clearly haven't seen my contributions to the Plugin Development subforum (I don't blame you, I'm just as big of a nobody as you are, and I've never seen you before either). I try to teach best practices as often as I can. Anything from "program to an interface" and "compositional design over inheritance" to "follow Java's naming conventions" and "indent your code properly for maximum readability". I've had several rants about the use of PlayerMoveEvent, and I often comment on other people's answers to try to help improve them - call it peer review, if you will. I have nothing but good intentions with my posts. Your inability to process that is what's lead you on this rampage.

    You're absolutely right.

    I'll continue to try to help the community by explaining my point about providing unbiased information where it's due, such as right here in this thread. Would you rather I started a new thread, tagged OPs of other threads in it and told them "I think it would be great if you added this bit of information back in your thread"? What kind of strange forum structure is that?
    Wingzzz likes this.
  27. Offline


  28. Offline


    And you just tagged him again by quoting a post in which he was tagged! Take coverrrrrrr!
  29. Offline


    Yea, I'm good at these kind of things.
  30. Offline


    Personally, I find these to be cool snippets. I 100% agree with garbagemule and have no idea as to why there was even the need for a discussion/dispute against his initial post as if you read it- well I don't even know what to say... If you read it and still had something to say about the post being bad/improper- well like I said... I don't even know what to say.

    For those who claim NMS used by "experienced" devs blah blah blah it's not bad etc etc... I'm sorry you're being naive. It's bad to use as it's high maintenance and can easily break things. That being said, I love NMS and use it a great deal and for those who also love to use it I'd recommend looking into supporting multiple NMS versions. You can learn how to do this from bigteddy98 's OP or from mbaxter 's post.

    Discussions are great, they can lead to people learning a thing or two and to me having a few laughs. Please don't make enemies of people who are trying to state information in order to spread awareness for developers. You make yourself look snobby, and your fighting against something that is.. actually... good? :eek: Anyways, there was some good information shared so for those who skimmed by garbagemule's posts- unless you're knowledgeable about the caveats that comes with the use of NMS (even with reflection)... I'd strongly recommend reading through them in order to better get a grasp about why people love it, but also why it can cause a headache and a half, as well as why it can make some server admins cry and bug the author of the code.

    Awesome thread, very fun snippets/resources/tutorials etc :) Love to see what people can come up! Bukkit has really come a long way eh?
    garbagemule likes this.
Thread Status:
Not open for further replies.

Share This Page