Bukkit + Minecraft 1.8

Discussion in 'Bukkit Discussion' started by Mike1022, Aug 18, 2014.

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



    So I've been following the development of Minecraft 1.8 from the first snapshot. It has become apparent that 1.8 will be the largest update ever release for Minecraft, espcially with all the internal rewrites they've done. So that brings one question: How difficult will it be for Bukkit to update?

    I am not asking for an ETA, but I am going to say that I think it's going to take awhile, with the system they use now. So what can be done? (Feature request)

    1. A few of the Bukkit devs can start looking over the snapshots and start working on a development build for it. This has been suggested many times, but has been set aside because the code "could change". In reality though, if they did this from the start of snapshot release for any update, when the update is released, they would have a head start on developement.

    2. Update Github! When an update comes out, we want to see the progress on it. This is the perfect way to satisfy that need. So when your done coding, please just take a few extra minutes and upload what you worked on to Github.

    3. Try to explain your progress. In a post, you should try to expain what needs to be done to update Bukkit. This will help people understand why it's taking so long to update. If not possible, I get it though.
  2. Offline


    But snapshots code CAN and DO change for the official release. After all they are snapshots and not the final product.
  3. Offline


  4. Offline


    Zettelkasten prerelease is not actual release for a reason. Plus deobsufocation is still necessary for each new version, which alone takes a while.
  5. Offline


    I came here to comment on reverse engineering snapshots and chew bubble gum. And I'm all out of bubble gum...

    The first item on your list makes perfect sense. Getting some practice with the snapshot would speed things up.

    I've experimented with customizing the snapshots. As proof you can see a customized build of last week's snapshot (14w33c) at

    Here's my analysis:

    There is definitely a lot that's changed. One obvious example that appears all around the code; places that used to have x, y, z, there's a class container for it that's used instead. There are new network packet related classes (looks like 11 in a quick eyeball comparison of 1.7.8 to 1.8). Not to mention new entities and blocks. Also, there still seem to be problems with the new optimizations they added (where chunks don't refresh after teleporting). Players will most likely need to become friends with F3+A (reload chunks feature) for a while until that's sorted out.

    Anyways, that said it takes a good day just to get things compiling. Then it doesn't work right away, I noticed a few places where the commonly used reverse engineering tools don't get it right (one that tripped me up initially was in one of the file i/o classes). Those have to be identified and fixed. And minor things like project dependencies figured out (I had to use commons-lang3-3.3.2.jar vs commons-lang3-3.1.jar in the past), include a yggdrasil certificate, and Log4Net configuration, etc.

    Assuming someone is experienced with the process and an expert code monkey, this would only take a day though (custom build working but no customizations). Meanwhile the forums would surely be filled with "Why haven't we updated, what's the ETA" when you've only just started. I am not involved on the Bukkit team but would imagine this is done by just 1 person initially as I don't see how you would gain by splitting that work up.

    Deobfuscating would be another day. If you're unfamiliar with this, Mojang scrambles their build so it's hard for people to reverse engineer their work. Everything is named "a, b, c, d" instead of "ChatColor, Creeper, GrassBlock", etc. For me (not surfacing an API), I can just use my own made-up names. However the Bukkit team would need to be consistent to match past names (and decide on some new class names). I'd imagine though a majority of this could be done in a day then tweaked/improved over the next day (and ongoing). Here you still haven't gotten anywhere meaningful in terms of a usable release and the requestors are asking ETAs. You really can't answer at this point.

    Then comes some of the harder stuff. Bukkit has to insert all the event hooks in the right places and make sure they have consistent behavior with past expectation and behave right when cancelled. Each of these not only have to be coded but you have to run a build, see if it works, and many times going back to adjust, re-build test. There are new entities and features that will need APIs (example: Armor stand control). Those new APIs though I imagine could wait until after an initial release since they wouldn't affect existing plugins.

    This last part would be very hard to estimate where you are, especially to an audience that includes a lot of non-coders. That's probably why Bukkit staff just says "We're working on it." Also, all time spent explaining things just takes away from time/focus on the work.

    On top of all this:
    - While you're hard at work. Nothing stops Mojang from saying "Oh, nevermind that last build. Here's an update!" right in the middle which is really annoying, especially with the recent snapshots which have had 'b' 'c' and 'd' releases in the same week. :)
    - You're not getting paid for this work (that I know of) and it requires expert coding skills. Bukkit staff could be off building their own game or commercial software, but presumably putting so much time on this for love of Minecraft.
    - If you're like me, you have a day job and a life too so it's not like you can focus 100% on it all day every day.

    With this said, I'd say you shouldn't expect a Bukkit build in the first week after release. If there is, it's only from some heroic super-hacker effort (or possibly inside help from Mojang). With multiple devs involved (requiring coordination) and goal of releasing a quality release as opposed to unstable ones, I'd guess at least 2 weeks as 'best case' scenario. A more reasonable expectation would be to add another week or two on that.

    I'm not a member of the Bukkit team so would be interesting to hear one of them comment on anything I've said or left out since I'm not involved with their actual process.
  6. Offline


    In case you anyone forgot, it took more than a more for Bukkit to update to 1.7. So with 1.8, I can't imagine how long it might take. I'm just thinking that there might be SOMETHING they can do to prepare for 1.8 so it will take less time.

    Also, is there a problem with updating Github so plugin devs (or anyone that can read code) can see your progress?
  7. Offline


    Mike1022 again, at the expense of updating the current version.
  8. Offline


    I think we can all agree that there's no way we're going to see a recommended build for 1.7
  9. Offline


    Mike1022 so you'd rather see no beta as well?
    What if mojang starts on 1.9 snapshots as 1.8 gets released? You'd just have a buggy version of 1.8?

    This was discussed before a lot of times. The cost of deobsufocating every single snapshot weekly is way too high considering there is also work needed to be done on current version.
  10. Offline


    First of all, if 1.8 is going to be released next week, then it's likely we'll never see a beta build for 1.7.10. Regardless, there is already a working beta for 1.7.9 that works fine with 1.7.10.

    Next, let's not distract ourselves with hypothetical situations. It's highly unlikely that Mojang is going to release new snapshot for 1.9 the week after 1.8 is finished. Now, with the problem of deobsufocation, you could add a few people to the Bukkit team to work on snapshots and pre-releases. Then, when the updates are released, that team sends their progress to the people that update Bukkit for Minecraft releases. Obviously it would be too late to try this for 1.8, but surely you could have 1 or 2 existing team members check it out.
  11. Offline


    Mike1022 work for 1.8 has started as soon as 1.7 went out, and before 1.7.6-1.7.10 were even released. This is now the way mojang works.

    And where you are going to fabricate these new team members from?

    If you suggest that bukkit team splits it self to 2, one that deobsufocates every single new snapshot, and one that works on current release, how are you going to merge the 2 versions? You can't just dump the new version over existing changes. The result would be a lot of work into 2 different versions, then the work of both to make one release version, for the same result as it is now, but with much more time wasted on snapshot development stuff. Even now, in snapshots, you have current added features being rewritten.
  12. Offline


    If they wanted to split the team in two, I'm sure they'd come up with something. Also, I do believe it was AT LEAST 3 weeks before 1.7.6 came out.
  13. Offline


    Come up with what?
    Also, im not sure how your second statement goes against my argument.
  14. Offline


    I wish mojang gave bukkit code that isn't obfuscated.
    I understand that they do it on the releases, there's already so many clones of Minecraft, we don't need to make their jobs easier.
  15. Offline


    I wish it were way too. Unfortunately, if Mojang did that for Bukkit, they'd have to do it for every project. Then we would have people breaking the copyright. That wouldn't be good, now would it?

    Necrodoom - Let me spell it out for you.

    If the Bukkit team wanted to add members to work with snapshots and pre-releases, I'm sure they'd find a way for it to work.

    As for my second statement, my point was that it took a little while before an update was released to fix 1.7. Also, if you had to start from scratch for every update, I'm sure we would be getting our first working 1.7 build right about now.
  16. Offline


    Mike1022 differences between snapshots are much bigger than between release patches.. Snapshots are weekly as well. There's also to mention that bukkit usually waits for the first bugfixes releases to end before starting to work on the release build.

    And you are still suggesting that bukkit team will fabricate new team members out of thin air.
  17. Offline



    I'm sure everything in life can be solved by throwing some words at it.
  18. Offline


  19. Offline


    Heh, it seems with the latest developments this morning, Bukkit for 1.8 might be out faster than expected since Dinnerbone has picked up the project again, with what looks like help from Grum, Searge and possibly Jeb. And since they already work for mojang, I'm guessing there's gonna be no need for them to deobfuscate code that they objuscated (I'm think?.)
  20. Offline


    Well, nevermind then. It seems as if this project is going to die after Dinnerbone updates it to 1.8. I'm sad. ;(
  21. Offline


    The repository has a list of 106 contributors. I don't think it's going to die that easily.
  22. Offline


    ShadyPotato Active contributors is what matters, though. A simple typo or bug fix from a person and nothing else helps, but does not contribute much to its life factor.
  23. Offline


    I understand that a good deal of the contributors are the result of a one-time commit, but my point is, since it's open-source, there will certainly be someone to step up even if the lead is gone.
  24. Offline


    ShadyPotato As it stands, it appears mojang took over, at least for 1.8. Afterward its not known what will become of bukkit or if the updates will be made open source.
  25. Offline


    Damnit Necrodoom let me cling to my optimism
    Tanchist and Mike1022 like this.
  26. Offline


    I do agree with Necrodoom. It is still uncertain if the project will remain open-source or not. I even tweeted Dinnerbone about it. We'll see if he replies.

    I think the best we can do now it take advantage of the fact that it is still open-source. By that I mean get some skilled plugin developers and some of those contributors. Then download source for the project as it is now. After that, we continue the project under a different name. We should also slowly change the code so that it's not breaking copyright.

    One question though...

    How was Bukkit breaking the Minecraft EULA?
  27. Offline


    Well, in EvilSeph's goodbye post, he said it was the "you must not distribute anything we've made" clause.

    However since Mojang owns Bukkit that doesn't apply. Jeb also tweeted "Bukkit always had a special relationship in regards to things such as the EULA."

    So to answer question, they aren't breaking the EULA (i.e. they can redistribute since it's Mojang).

    Dinnerbone's tweet about "Mojang owns Bukkit" but he's going to _personally_ update Bukkit himself, indicates some sort of distinction between Mojang and Bukkit though which is curious. I guess it's that Mojang isn't sponsoring the support of Bukkit and he's going to just 'help out' since he has background/passion around it.

    This is all a fluid situation, but if I were to guess I'd say Mojang temporarily manages Bukkit and accelerates work on an official mod API. If there were an official API you could retire Bukkit and that makes more sense from a business perspective instead of throwing time/resources at two separate things. But I'm just shooting at the dark based on latest developments. :)

    All very interesting stuff.
    asofold and BossEndorphin like this.
Thread Status:
Not open for further replies.

Share This Page