Bukkit: The Next Chapter

Discussion in 'Bukkit News' started by EvilSeph, Feb 28, 2012.

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

    EvilSeph Retired Staff

    [​IMG]

    What follows is a written account of Bukkit's story. If you'd rather know what the big news is, skip to the bottom. However, we'd appreciate it if you read through our entire story as it gives us an opportunity to show appreciation and give thanks to the many people, groups and companies that helped us throughout our adventure.

    When we started up Bukkit in December of 2010, we decided we wanted to do things right. Right from the beginning we wanted to be sure we were bringing about a positive change to Minecraft, one that Mojang themselves would approve of. To that end, we set up a meeting with Mojang to get a feel for their opinions on our project and make sure we weren't doing anything they didn't like. The gist of the meeting was that Mojang "liked what we were doing" but not how we had to go about doing things. Unfortunately, we both knew that we had no alternatives, so we continued along - albeit now with the reassurance that our project would most likely not be shut down any time in the future. We decided to create Bukkit to provide the Minecraft community with better tools to manage and extend their server, but our ultimate goal has always been to give the Minecraft community what it needed and wanted to make our favourite game even more enjoyable and being able to do so in an official capacity is our dream.

    Shortly after the launch of Bukkit, after I had posted an innocent announcement to get developers interested in Bukkit, our project exploded with activity. While I had anticipated developer interest and had planned for such, the added interest from the community as a whole was simply overwhelming. So much so that it had begun to put a strain on my dedicated server and actually was pushing it to the point of hardware failure. Luckily, it was around this time that Curse approached us and offered to set-up a temporary Amazon EC2 instance while they purchased new servers for our use. Unfortunately, the Amazon EC2 instance also could not keep up with the demand and was proving to be too costly. So, we asked around for help and Multiplay's Steve Hartland put us on one of their boxes free of charge while we waited for new servers to be purchased and delivered.

    One of the goals of the Bukkit project, or maybe just my personal goal, was to solve what I felt was a big problem within the Minecraft community: it was largely impossible for someone new to Minecraft to discover the unlimited potential of Minecraft modding. Not only would they have to deal with unwieldy and clunky forums, but there was also no central place for sharing your work. In answer to this problem, we endeavoured to create a new service dubbed Fill which we hoped would address all the needs of the community but were unable to gain any ground. We were simply not experienced enough to run something of this magnitude nor did we have the resources to pull it off. One day we were discussing the idea of Fill and our desire to provide a central download solution for the modding community and the WoW players on the team brought up Curse and the success they've had with WoWAce. At that point it all came together, not only did Curse have the resources to pull off something as large as we were envisioning in Fill, but they had the success, experience and scalable software with WoWAce to do so. With that, it was clear to everyone that Curse was the best route to take and dev.bukkit.org was born.

    When news broke out about Mojang organising a Minecon, the entire community was alight with excitement and anticipation. Even today, I still find the sheer dedication from the fans unbelievable and overwhelming. Though we were also excited about Minecon, there was no way we would be able to go since Bukkit is an open source, free project. Much to our surprise, though, Curse had other plans in mind. They decided to fly us over, cover our tickets and accommodation, host us in their booth and setup a panel for us. I've never met a company that cares more about gaming than Curse: when the possibility of their supporting the Bukkit project first came up, we were all blown away. Curse wanted to throw themselves behind our project. They wanted to provide us with the support and resources we needed to continue functioning, no questions asked and their desire to send us to Minecon further reinforced this opinion we had of them. Thanks to their support, we were able to go to Minecon, have a great time and put together a panel filled with our fans, as well as sneak off to a secret meeting with Mojang.

    Back in December of last year, my team and I were invited to Stockholm, Sweden by Mojang to discuss the future of Minecraft - and most importantly the future of Minecraft modding and the official Minecraft modding API. Having just recently met in Minecon, we mostly knew what to expect but were blown away by Mojang's hospitality and the surreality of actually being in Stockholm with them. Not only were we able to visit the Mojang HQ but we were also given the opportunity to be part of the launch of Cobalt (which was simply fantastic) and got to meet the entire team of talented individuals at Mojang. We spent the majority of our time with Mojang shooting ideas back and forth and getting a taste of what was to come and how we might be able to become involved.

    Which leads me to today. Our meeting at Minecon was just the beginning and after having flown us out to Stockholm to get to know each other, it was clear that the potential to do truly great things together was there and we were eager to explore it. After all, we had already been given a direct line to the Minecraft team, the source code and were actively providing Mojang with (exploit) patches and improvements. The next logical step was to figure out the best way to continue working together, perhaps in a more official and intimate capacity. After careful and lengthy consideration, the best course of action became clear. My team and I had already achieved what we wanted to when we started the Bukkit project: provide server admins with the means to easily customise and run their server and provide developers with an easy to use, properly designed API to bring their insane and cool ideas to life. The next obvious step was to make it more official and with news breaking out that Mojang was interested in developing an official Minecraft API, we knew just how to do that.

    I am extremely pleased and proud to announce that, as of today, the Bukkit team has joined Mojang. When discussing the possibility of a modding API publicly, Mojang was concerned that they would be unable to provide the community with a suitable and powerful enough solution and we honestly feel that our experience building Bukkit will help them do so. Thanks to our work with Bukkit, we have a years worth of experience, failures and lessons to help us develop a proper modding API and intend to do whatever it takes to produce one that satisfies the needs of the community. Now that we have an opportunity to design the official Minecraft API, we intend to make it a suitable replacement for Bukkit, if not a significantly better one, while bukkit.org will remain a community for modders for the foreseeable future.

    Official announcement from Mojang with more information: http://mojang.com

    [​IMG]

    A big "thank you!" is due for the many sponsors we've had over the life of the project:
    [​IMG]
    Curse
    eXophase.com - for hosting the project at the beginning and helping us get off our feet
    Unimatrix
    Arcdigital
    Multiplay - especially Steve Hartland
    [​IMG]
    AllGamer - especially Clinton and Scott
    Our Staff who work tirelessly and thanklessly to keep everything in order
    and, of course, Mojang for giving us a chance, taking us seriously and supporting what we’re doing.

    And to you, our community and our family: thanks for sticking by us through thick and thin, we really would not be where we are today without you.
     
    jflory7, Acharige, iiHeroo and 88 others like this.
  2. Offline

    TnT Retired Staff

    Plugin devs need to maintain their plugins. If they stop maintaining them, you might be out of luck - unless they pass the project onto another dev - or another dev creates a similar plugin.
     
  3. Offline

    turikhay

    Oh my God!
    It's really good news!!!
    :)
     
  4. Offline

    TnT Retired Staff

    Support requests in this thread are deleted. Use the Bukkit Help forums. Thanks!
     
  5. Offline

    bergerkiller

    I spend a full afternoon scripting, but the lighting fixer for NoLagg finally works again. It will be a separate plugin (sort of add-on) with which you can fix all the bugged lighting in the world, which started to become worse after the 1.2 update. (something with the ability to 'auto fix' lighting as players move along)

    Though I wonder why such a thing is even needed, after taking a look at the final script it is fairly simple to fix all of this. Only problem is that it needs a global approach, since lighting is not in a single chunk alone...

    Maybe one day it won't be needed to manually fix lighting fails...like during the beta versions :(

    Anyway, wonder if the dev team has enough time fixing this themselves...I've seen the code so I wish them luck with all the abc functions :)
     
  6. Offline

    MachetePanda

    Thats fine but at the time Spout was working on Spout Server mod, Bukkit Spout plugin, and Spout Client. However that is all irreverent now with Minecraft API team being able to work on it all.
     
  7. Offline

    Celtic Minstrel

    Ah, right, I think I see what you mean; though I may have been thinking in terms of a dumber client to begin with.

    I doubt I'll have to completely re-code my plugins for the Minecraft API. They're going to make it as compatible as possible, from what I understand. In other words, changing from Bukkit to Minecraft API shouldn't be any harder than changing from 1.1-R4 to 1.1-R5, or any of the other times Bukkit introduced a lot of breaking changes.
     
  8. Offline

    Wilpan199

    Code:
    The people ho work's on Bukkit IS BEST!!!
    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: May 24, 2016
  9. Offline

    Smex

    Take of your helmet, the visor is breaking your view. ;)
     
  10. Offline

    Don Redhorse

    will that fit into my notebook?
     
    lukegb likes this.
  11. Offline

    Tanite

    It's the same cat and mouse game here (see: NoCheat), and the same one with virus/anti-virus, etc.. But I still think we can do more, should at least try.

    Those things are quite all excellent uses of time as well. I imagine they are already thinking toward those goals if they're doing a re-write of things.
     
  12. Offline

    lukegb Retired Staff

    You mean the equivalent of OnLive, but for Minecraft? :p
     
    Don Redhorse likes this.
  13. Offline

    Bone008

    Joining this conversation, I'd like to point out a few things:

    - If you won't be able to access the source of the new API (and I don't mean a bunch of interfaces, I mean the real code aka the server), it WILL limit the possibilities a plugin can do, whatever you say. You can't have API for everything for such a huge thing like the minecraft server. The 2 biggest things that allow gameplay-altering in bukkit's API are "do something when something happens" (events) and "do something when I tell you to" (commands). Then there is what ModLoader(MP) primarily does, some of that is also in bukkit and vice versa: Adding new recipes, blocks, items, entities, stuff. Okay fine, now let's say they would combine both main aspects in the official API, and add more stuff made possible by it being "official".
    But it will never reach a point where no one can come up and say: "I want to do this and that, but that's not possible with the current API". Some unique ideas just wouldn't be unique and new if there already was an API for it. I leave examples up to your imagination.
    Knowing Mojang, requests to add API for a specific need are very unlikely to be implemented quickly. In some situations, it would also create a huge performance overhead compared to accessing native classes.
    So now if one isn't able to access those native "core" classes, the variety of plugins is being narrowed to whatever the API provides. Yes, it already makes you vulnerable to updates within CraftBukkit, but right now you can easily see the source and parts of the code are deobfuscated and are unlikely to change - same with CB method/attribute names.
    bergerkiller said something in that direction somewhere here, but it is just not realistic that the API will cover EVERYTHING.
    And now don't tell me that Java is also an API and that it does cover "everything" without needing insights to its workings, because it doesn't. That's why we have the native keyword and thus the ability to execute native coding from within the Java program.

    What I am trying to say with that is: If stuff behind the API is covered, plugins will be highly limited in their functionality, and since Mojang is Mojang, there is a high probability that this is going to happen.


    - Another thing that came to my mind while reading this thread: Even though it would be naive to assume it will be like that, the server code could possibly become open-source. I mean, everyone can download the server (minecraft.net/download) without having bought minecraft and there is already mc-dev having published the code partially deobfuscated without problems. So technically, why not open up the server's code together with the API? That way, it would be approximately as easy to understand/change core functionality as it is right now with Bukkit.
    Again, I don't believe it will happen, but what's the problem with it?


    - Stop jumping to conclusions about what will or won't happen.


    - I'd really love to see a system like in TF2 (or does it apply to all source engine based multiplayer games? dunno ...) where required modifications are just automatically pushed to the connecting client, but don't affect any other servers.
    I also like the concept of singleplayer being nothing but a locally spawned server and yourself connected to it, like it was already suggested by ... Dinnerbone, I think (sorry if I remembered that incorrectly ...). I really hope it makes it through!


    Personally, I'll just wait what the future holds, and just stick to my small plugins until the end.

    (PS: If there are errors in this post, let there be cake, I don't feel like re-reading it ;).)
     
    Don Redhorse likes this.
  14. Offline

    mouring

    Why not? Cray is now selling $250,000 super computers--which I assure you is dirt cheap. I'm sure for a bit more you can get NVIDIA vector processing cards put it, and then you just need to rewrite the Minecraft server to be a parallelized graphics generation engine rendering out to streaming OGV (to keep the open source folks happy). Then the client just need to be a simple movie playback interface with the ability to send mouse/keystrokes to the server. =) Everyone loves the idea of D3 being online only play. I'm sure they'll love the idea of MC2 being online as well.

    Heck, I'm sure the Department of Energy and a few other Cray owners have Minecraft fans at their location that would be willing to run a few servers for the community to offset the cost of their machines. They'd be old stick in the muds if they did science and weather prediction all the time. =) Besides, what else is a few Petaflop of processing is good for, besides running FarCry 2.
     
    Inscrutable likes this.
  15. Offline

    Celtic Minstrel

    Wrong, in the sense that you've missed the point. The native keyword is irrelevant here. There's the standard API for the basic Java library, in the java.* and javax.* packages, and they're documented well enough that you don't need to care about the source code. Sure, you can see the source code if you really want to, but you don't need to look at the source to see how to do something. You might need additional libraries for some things, but that's also irrelevant.

    Incorrect. Or, more specifically, this is not "necessarily true", to use modal logic. It's possibly true, but not necessarily. In other words, the API might highly limit plugins, but it might not.

    Except Mojang is not just Mojang anymore. Mojang is now Mojang plus Bukkit combined.

    Again incorrect. It might take some work to get API for everything, and but it's not impossible.

    Technically, commands are a special case of events. (The channel API is also a special case of events.) So, this is just one of the biggest things components of Bukkit's API.

    And this is the second biggest component of Bukkit's API. Okay, sure, in Bukkit it's currently limited to recipes and some other little details, but there's no reason to believe that the official Minecraft API won't extend that to allow for new blocks, items, and entities. And even other stuff you haven't thought of.

    So the two biggest things are really "do something in response to something else" and "edit data the server uses to make decisions about things".
     
    Technius, LlmDl, TnT and 1 other person like this.
  16. Offline

    Technius

    You know, I really think we should be able to help those six making the new API... It would probably speed up the process a lot. What do you think?
     
  17. Offline

    Bone008

    The point of me bringing up the native keyword:
    --- The Java standard API provides X functionality, but if you need more, you can use "native" methods to do it your own way. An example would be the use of global hooks or direct hardware access in your Java program.
    --- The future minecraft server API will provide X functionality, but if you need more, you need to use "native" (in terms of: "of the core server") classes/methods to do it your own way.

    So regardless whether the API is well documented and self-explanatory or not, once you need to go behind it (I'll come to the "why" in a second), you need to have the possibility to do it.


    If the API turns out to be very good and with a lot of features, it might turn from "highly limited" to "limited to a certain level".

    An example where it is pretty impossible for an API to cover that: You want a custom Minecart entity that does everything a minecart does but behaves differently in some methods (I'm sure bergerkiller needs that a lot). To do that, when being able to access core classes, you can just extend EntityMinecart and override the necessary methods. If you don't have access, the API would have to make you able to control the custom behavior. But you have to be able to possibly control everything - so every single method in EntityMinecart needs either own "event listeners" or needs to somehow retrieve its behavior information from a (custom) API class/method/whatever. Every method, in every core class, does that sound realistic? While it could be technically possible, I don't think such a server would be able to run at all, when every method call needs to react to possible alteration.
    The API might be able to cover lots of useful stuff, but there will always be a scenario where you need access to the core. Like I said, making the API able to do everything would be complete madness.


    Sum it up to only one thing instead of two, doesn't make a difference.

    That was exactly what I was trying to say. The official API may very well combine the features of Bukkit and ModLoader(MP) and a lot more, but it still can't possibly cover everything (see above).
     
  18. Offline

    Celtic Minstrel

    I don't see why you couldn't do this with just the API. Presumably the API would include interfaces that you can implement and/or classes that you can extend, so all you'd have to do is extend EntityMinecart (or its interface) and implement or override methods. It wouldn't be too much work to make the API support something like this.

    The only downside I can see is that if you only want to tweak the behaviour a little, you might be forced to recode most of the physics of the normal minecart.
     
  19. Offline

    AlbertoTech96

    Happy for you guys but please please hurry on the new build please we need to update are server's
     
  20. Offline

    MachetePanda

    I'll qoute Dinnerbone "As I said in the FAQ, we will try to keep as much compatible as possible, but there are no guarantees" :/

    Hopefully your right... but I have hear all this before.
     
  21. Offline

    Bone008

    If EntityMinecart as the core class itself would be part of the API, that wouldn't be a problem. But that would also mean it couldn't be obfsucated - what kind of API makes you use obfuscated methods that change with every update? That defeats the purpose. So it would be an interface you could implement or a wrapper class that you can override. That's pretty much the same as org.bukkit.entity.Minecart (interface) and org.bukkit.craftbukkit.entity.CraftMinecart (wrapper class). And now try to alter minecart behavior by extending CraftMinecart. All it does is delegating its method calls to its internal EntityMinecart handle.
    In order for you to be able to change everything by extending the class, the functionality itself would have to be in that wrapper class, and thus the wrapper class would become the core class - including the functionality, but unobfuscated because it's an API.
    Then the original core class EntityMinecart would only delegate to the wrapper class, that would be pretty much the same as just opening up EntityMinecart for everyone (unobfuscated).

    Let's say EntityMinecart::vk() would be the obfuscated method "onTick". With that wrapper class that allows you to modify what happens onTick in your minecart, EntityMinecart would only do something like that:
    Code:
    public void vk(){
        getWrapperHandle().onTick();
    }
    "getWrapperHandle()" would return what currently is CraftMinecart - and CraftMinecart would contain all the actual math with position updating. Now you could override it with a class CustomCraftMinecart extends CraftMinecart. And now you are at the point where it is exactly the same as if EntityMinecart would just be unobfuscated and open for everyone, except that you now add another method call for everything in there.

    Or how would you "make the API support something like this" in a way that still leaves a point to an obfuscated EntityMinecart, but allows alteration of it without extending it?[/CODE]
     
  22. Offline

    Celtic Minstrel

    I think most likely it would be the interface, so it'd be like creating your own minecart by implementing org.bukkit.entity.Minecart. Except it wouldn't be, because org.bukkit.entity.Minecart doesn't have everything required to represent a minecart; methods like onTick are missing, which would presumably be present in this hypothetical interface.

    There are other ways of altering an entity's behaviour besides extending a class or implementing an interface, though. Perhaps the EntityMinecart class would delegate its behaviour to some external Behaviour class, and you could write your own implementation of that class and set a vanilla minecart's behaviour to your custom behaviour. This obviously requires quite a significant reworking of how EntityMinecart is laid out.
     
    Don Redhorse likes this.
  23. Offline

    Silvanarix

    I just want to say that I have just recently joined the community, having never worked with java before or modding. Bukkit made the learning process very easy and I am happy that they have been taken in by the creators of this wonderful game. I have no doubt that their collaboration will be a benefit to the entire community in a short period of time. Thanks bukkit for giving my friends and I a great server to play on! Look forward to seeing what you can do with Mojang!!

    Out of curiosity - is this going to stop a recommended build for 1.2 to be released in the near future? 1.2 looks amazing and I cant wait to play it!

    Additionally - Spout offers alot of great features that I cannot seem to find anywhere else. Are there any plans on creating features like spout within the server? From what I read on spouts site it seems they want to break away from bukkit altogether. Without them I fear for user friendly functionality - /commands are not the greatest way for non-technical users to fall in love with a game. If spout can be replaced, I will replace it, I personally stand by Bukkit in regards to which I enjoy more. But as I am sure it is with all servers there is always that person who doesn't work well with / commands and needs an explanation all the time. a GUI within the game where I can bind commands for these players would be fantastic.

    Regardless of where this ends up, I just want to let you guys know that Mojang has just gotten quite a bit stronger! Don't lose your communication skills to ego though!! Keep your loyal community informed!
     
  24. Offline

    ledhead900

    Read me please (open)

    I am Certified IT engineer, and I can tell you that your point while not moot when being said as general advice but it IS moot against my advice. I have Intel Quad 3.4ghz and a Nvidia 285GTX Overclocked at 720mhz on core and 1600 on sharers, 1400mhz on the ram, 8gig of system memory. Granted this rig is getting a little on the older side now for today's tech but it still run most things at highest - medium . I have plans to replace this later on this year with a new 2nd gen I7 and 590 or possible a 600 series when they are released.

    I have been playing MC with this rig since it MC existed I know for a fact that all the differences in FPS are are from bugs in the game as it has never ran as good as it did in 1.2 alpha (not the broken update but the patched one). That was running flawlessly at near over 1000FPS if I looked straight up with the gfx down. Even running it on high I was getting smooth 300 fps always.

    I honestly would not even bother trying to play games at all on an onbard GFX unless the it was dedicated onboard. as they nearly all struggle to play much past quake 2 let anything from today's selection. Also I'm sick of people blaming rigs for Minecrafts poor performance. If you can give me correct facts that can drive home a decent reason why Minecraft should perform WORSE compared to my 35-80 FPS in Battlefield 3 with most things on highest except the shadows and terrain decoration as they are on low to give a better tactical advantage less clutter easier to see you in the bush then do so I will listen (no Java is not an excuse I have seen many many games flog over 1000 fps made in java and have just the same detail if not more than Minecraft has).


    Anyway Minecraft on paper should run just fine at 50fps on a Single core Pentium D with onboard graphics sharing 2 gig of system memory in fact If you check the recommend system requirements for the game it should even run on lower!. But I can tell you it clearly wouldn't it would barely make 25fps on lowest settings and that is really sad. It is all in the poor code being so bug ridden and just over all not very well optimized (Note: that this does not make it not fun to play as clearly still is its just IMO, plain slack of them).

    Granted I give it some lee way as its running under Java an environment better suited for enterprise apps due to the fact it is quite limited in terms of memory management and network code optimization over something like C+.

    But there is NO EXCUSE to see that in the snapshots the game runs fine and dandy nice and smooth then when its built for release it runs like frigging crap. Its like right at the last min and for no reason break something and bug it, of course they probably haven't but it sure feels like they do as there is certainly something that happens between the dev version and the release that is clearly sapping huge FPS.

    FYI just in case you did not realize my GFX card would eat a 9800GT. I was using a 8800GT before I used this 285 1gb model. Ideally I would not mind an upgrade to a late 400 series as they super cheap now and would fix all my FPS issues in newer games but I can't justify buying a card to last four months when that money can just go towards a high end card when I'm ready to replace the entire rig.

    One other thing does my avatar look like a kid to you ?, I am 25 just clicking my portrait picture would tell you that, I know you probably did not direct that affordability stuff specifically at me however this was just to further drive home my point .

    I have been building rigs since I was 10 and I was networking computers before we even had 10mb switches just to play C&C Red Alert over serial Lan and Duke Nukem 3D.

    I don't mean to offend you in anyway I am just clearing up some things for you to better backup my statements. I have been arguing a lot about spout yes but with VERY good reasons I also argue about Minecraft in general and I am quite willing to make a comparison video of the snapshots vs release 1.2.x and the Spout vs standard 1.1 I almost feel as I need too at this point as people are just not getting the message and coming up with lame excuses just like Notch did when I called his bluff on some dodgy looking files in the game that shouldn't really exist if what he said about them was true.

    I'm hardly surprised though people including BIG company's have been using lame excuses about hardware and the user is at fault crap since gaming became big business. Let me just finish up as this is getting rather long that.

    I truly love this community, Minecraft might look boxy and pixilated but I love it all the same, I only argue things that I do in attempt to get things done that I literally am in no position to do myself.

    If you go through my other pretty long posts you would see that I am driving home relatively the same point every time but I am covering different aspects of my conclusions. I honestly would not wast my own time typing all of these posts if I felt things would just WORK out fine, I see an opportunity right now to improve the game as a whole and I'm going to make sure that this message becomes apparent and clear, none of us have a chance to fix anything but Bukkit sure do.

    Most of all I don't to be seen as a TROLL or Whiner or anything like that as I am not trying to kill off Bukkit I think I have made this clear many posts before but still I will say it again. Anyway you all have good day now or sleep, lets all help get our thoughts across so that we can make the most from Bukkits success as a community Bukkit started out as just a fan project but look at it now lets not waste a good thing that's all. Thanks for reading


    100% Agree tho I will not be coding as I don't know java, but I still agree as I have felt this way for a while now that the community should have been able to help a lot more with Bukkit as it is today, Maybe we would not be debating this move so much if we had that chance in the past.
     
  25. Offline

    Celtic Minstrel

    I quite agree, which is why I created SimpleSignEdit. (At the time, every existing sign edit plugin required the use of commands.) But it's not necessary to create fancy new GUIs in order to get rid of commands. You can repurpose the existing inventory GUIs, or use "magic" items, or "magic" signs, or a number of other things. (Though I don't much like "magic" signs, either.)
     
    Bone008, ledhead900 and Technius like this.
  26. Offline

    bergerkiller

    Bone008 summed it up pretty nicely.

    If you want COMPLETE functionality:
    - you can't have wrapper classes, an API with accessible unobfuscated core classes at most
    - you need to be able to switch from event-based to extending classes-based in some cases
    - no obfuscation at all
    - open source
    Either of those things not met, we will either end up with the same CraftBukkit annoyance or worse.
     
    Bone008 likes this.
  27. Offline

    ledhead900

    To sum that up nicely for Celtic Minstrel that is near never going to happen while the API is built into Vanilla at least the way it is now the entire thing would be obfuscated and re obfuscated every time they flush out changes to EVEN just BUKKIT API. Since Mojang would need as policy like they have done with the client obfuscate it upon release and I should not really need to tell you how this will effect an API being built into the client.

    IMO obfuscation for this game is complete waste of time it's only hurting the community it does little to protect Mojang's IP, as we already can de obfuscate it quite fast and its already been cracked.

    Mojang would already have or should already have IP copyrights signed up and drafted which would protect them in the event something was getting too familiar that could infringe on the copyright this on its own protects the IP, I recall Bethesda suing Mojang over the word SCROLLS as a game title. With this in mind you should have a firm grasp in your mind how obfuscation in this game, that like it or not lives and breaths due to its community, is a utter waste of time and only makes all of us very sad faced.

    EDIT:
    Might I just add other smarter indie games developers don't bother trying to hide the code all that much as they already know that modding only improves their annual sales figures, freedom of choice nearly all ways does.
     
  28. Offline

    samp20

    I see no reason why the method names of classes can't be left deobfuscated. You can still obfuscate the implementation of those methods. With the EntityMinecart example, the API might document the onTick() method, and what it's function is, but you don't know the code that performs that function. If you wanted to you could then create your own AwesomeMinecart which overrides the onTick() of the regular minecart to perform a custom action. To be able to get that minecart into the game you would then probably do something like
    Code:
    AwesomeMinecart minecart = world.spawnEntity(AwesomeMinecart.class, location);
     
  29. Offline

    bergerkiller

    samp20 yes, but usually you only want to disable parts of the minecart. For example, you want to disable the collisions. I had to ctrl+v the entire entity.move(dx. dy. dz) function and insert two lines of code, JUST to make that happen. If I don't get to see the source code, I'll end up using programs to hack myself in. But this rids the code of useful comments. This is why it is by far better if the source code is public.

    I guess the problem is, if you want a game to be moddable, you can't really hide the code. I'll take Battlefield 2 as an example, I've been modding it quite a lot. Why did everyone mod it?

    • Battlefield 2 was a game ENGINE
    • It used understandable text files (python or templates)
    • Everything was open source, except the game engine, which was a compiled C++ program
    • You could easily overwrite native Battlefield 2 objects - copy-pasta the files
    It still had copyright on most of the files, such as the geometries and textures. But the configuration files were all free to be edited and distributed. This way many unique mods came to be, such as NaW and Project Reality.

    Why doesn't this work for Minecraft? In minecraft, there are no models. There are no real textures. There is no hidden 'core' code to run the game. When you make the source public, everyone can see how the models are, how textures are loaded, and etc. He also used copyrighted materials IN his game, such as the ogg sound engine (Pauls code)

    So, first of all, the client will never be made open source. Will the server get this? I doubt, as all the physics coding is made by him. He doesn't want all this stuff to be stolen and put in a new game, I can imagine. So how do you resolve this?

    You make wrapper API classes to work with. The code behind it is obfuscated, but called by the wrapper. Does this allow new entity-extending features? No. Because the entity source code is obfuscated. Maybe a sort of empty entity which you can extend the wrapper of, but extending native entities is NOT possible. In craftbukkit this is still possible, though the source code is obfuscated.

    This is why I support Spout's development. They re-make everything from scratch, deobfuscated, so they have all rights to the source code, and make it even better. Because, let's be honest, we are not discussing obfuscation and closed source about Spout, do we now?
     
    Inscrutable and ledhead900 like this.
  30. Offline

    samp20

    bergerkiller I wouldn't have thought leaving entities deobfuscated would reveal too much code. You're not revealing anything about the entitie's textures since that's clientside only. Also for the physics that can be handled by the obfuscated engine. Entities would provide information about their shape to the engine, then the engine would handle the physics. For disabling collisions you could maybe override a method such as boolean canCollide(Entity other). There are ways of keeping what notch/jeb wants to hide obfuscated, whilst still allowing a lot of customisability. I admit it would probably require a big refactoring of the current code to get to that stage, although it's certainly feasible. I really hope mojang/bukkit are working on it as we speak.
     
  31. Offline

    bergerkiller

    samp20 Entities have a lot of fields, which are obfuscated. Once you reveal these fields, it is picture-clear what all the functions do. Obfuscating these members is key to confusion. Entities are not only a bunch of functions, they also have members. Putting members behind getters and setters won't do either, as that makes it very easy to find out what these members do.

    The point is, once you make a class 'public', you can no longer obfuscate it properly. You can hardly obfuscate the internals of functions, but that is the least important bit usually.

    And, say they would do as you say, add separate functions when people request them. Then performance will quickly drop, as functions will be added for pretty much every use case. Sometimes extending is the only way, and you need the original source. canCollide is possible, but what if I also demand:
    • Handling fall-physics for a 'moon' environment
    • Changing the path finding of a mob?
    • Changing what is spawned when a block is broken?
    And it can be extended some more. There are limits to what 'event based' functions can do, and don't forget that functions slow down java source code, as it has to update the internal stack trace for the thread.
     
    ledhead900 and Bone008 like this.
Thread Status:
Not open for further replies.

Share This Page