Bukkit: The Next Chapter

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

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

    EvilSeph

    [​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

    Celtic Minstrel

    This is probably true if the Minecraft internals don't change much, but I think they could be changed in a way so as to make it not true.
     
  3. Offline

    troed

    http://en.wikipedia.org/wiki/Non_sequitur_(logic)

    I'm so tired of all the Spout talk in this thread that I've made a decision never to support it for any existing or future plugin I make. Please go on - over at the Spout forums.
     
  4. Offline

    bergerkiller

    troed Well the spout talk is 1% of the talk TBH, mainly to compare the two projects, as they are separate right now. And, feel free to never support it, as Spout will probably make Bukkit-compatibility plugins anyway.

    Also, do you have any arguments other than falsifying other's arguments? As a plugin developer, you surely know how this situation works, right? But since you like to keep it directed at one person, so will I.

    What do you do when you find a request in 'plugin requests' which is not possible to do through the API or through the Bukkit API? Will you ignore it? Will you look at alternative ways? Or will you just say 'not possible, requires client mod'? For example, the following request:

    My 'development route':
    1. I'll just make a separate class holding the minecart, sharing the velocity as they go.
    2. Darn, the yaw is a real issue.
    3. It is vibrating quite a bit..probably because I handle the velocity changes too late
    4. All is failing, I'll mess around with native entities
    5. Still vibrating...ow there is an entity tracker? Explains...
    6. Ah no not another update?!..well here we go again
    Yes, TrainCarts could be made using solely Bukkit, but it would be:
    • Laggy
    • Glitchy
    • Having sync issues
    • Lack features such as changing what is dropped on destruction
    • Require huge accessor wrapper classes around a single minecart
    • Uses up a lot of CPU power, since it requires multiple scheduled tasks
    Maybe you don't understand yet why I use CraftBukkit instead of Bukkit. Maybe you do understand it once you find out you have to use it at all. Every API has it's limitations.

    Also, I demand an answer longer than 400 words or I will no longer respond to you, I suspect a troll.

    <add>

    You are right about that argument, though you don't seem to answer it. I'll make the argument complete.
     
    ledhead900 and Bone008 like this.
  5. Offline

    samp20

    bergerkiller I'm not talking about event based functions, but rather extending existing classes, so the canCollide would be a function of all entities. You can then extend the entity, and implement your own version of the method. Surely that wouldn't be costly at all?

    With the comparison of closed vs open source, even an open source server has it's problems. If you want to modify something that's not designed into the API then you have to use reflection to be able to modify it. Using reflection on open source code is probably more stable than using it on closed source, however it is very bad practice for both. The API for both open and closed source projects should still be designed to be as flexible as possible. Techniques such as overriding classes are feasible for both scenarios.
     
  6. Offline

    bergerkiller

    samp20 Yes, but the problem is obfuscation. What you are describing is what is done in CraftBukkit; a wrapper Entity class around the native Entity class. You can give it functions all you want, but the fact remains that it interacts with the entity below. This is a bad idea performance-wise.

    Therefore, the team decided to make ONE Entity which is in the top-level, so no wrappers. (I believe?) If they do, then the Entity function and member names can not be obfuscated, as that defeats it's purpose. Since pretty much all members are used in functions directly (motX, locX, isMoving, passenger) it is almost impossible to obfuscate the internals of the functions.

    Actually, let's just drop the 'open source' argument. Any java plugin is open source in some way. Just open up your decompiler and fire away.

    So therefore, having unobfuscated source files is of importance to make a successful API. But, this conflicts with the fact that the client is obfuscated.

    So, what I expect to happen (or HOPE will happen):
    • The server is unobfuscated and also controls SinglePlayer
    • The server contains all the logic of Minecraft itself
    • The client contains all the logic to render and run Minecraft
    • The client is obfuscated and closed source most of the time
    • The client gets an API interacting with the key requirements in the client (basically SpoutCraft)
    • The client is controlled by the server software, also in SinglePlayer
    • The server software is open source and can be freely altered by both mods
    Right now, there is a 'client mod' part (Zombe, Optifine) and a 'server mod' part (TrainCarts). I believe they decided to merge the two into one 'modding API'. This makes sense in some way. But, following these points, it is impossible for the API to be obfuscated in any way. The server software is like the game itself. You could basically run a completely different voxel game then. I vote for this system, AS LONG as the server is not restricted by the 'core'.

    Simply put: Minecraft entities are 100% the same as any other entity. There is no 'Entity enumeration' or 'Block material enumeration'. Blocks are registered, Entities are registered and all others are up to the developers to implement. There is no annoying obfuscation and there is no 'native and API' segregation. The API basically covers the entire server, from entity trackers to how chunks are stored on the disk.
     
    Bone008 likes this.
  7. Offline

    jaruca

    Congrats!
     
  8. Offline

    troed

    I look at alternative ways to do it, still through the offical API, and if that's not possible I write up an enhancement request on Bukkit. So far that's worked pretty well.

    Then again, I'm a professional Software Engineer with many years of development experience in making software platforms used by hundreds of millions of people (yes, really). I know better than to create dirty hacks and then complain to the people writing the API I just bypassed.

    How cute.

    You don't know as much about "open source" as you seem to believe. That simply depends upon the chosen license (and the license of the acquired software). Open Source and copyright aren't eachothers opposites (on the contrary, actually. The GPL requires copyright to even exist).

    The need or want for obfuscation has nothing to do with whether something's copyrighted or not.

    Btw, on the topic of trolling - posting "Bukkit can't blablabla but Spout can" would kind of fulfill the textbook definition of it.
     
  9. Offline

    samp20

    bergerkiller I think we're both thinking the same thing, although there are a few parts of the server which mojang could get away with obfuscating without hindering too much. I.e. the majority of the server is open source, but with a few of the more complicated details closed source.
    These are things which pretty much nobody cares about how they're implemented. For example we don't care how collisions are detected/calculated, just when they occur. Another example is we don't care about the code that loads plugins, as long as we know what it's doing. Android is a good example of that. It's completley closed source, however it documents how apps are initialized with the methods onCreate, onStart, onStop, onDestroy, and what order those are called in (don't quote me on the method names).
     
  10. Offline

    troed

  11. Offline

    bergerkiller

    Back to Bukkit. As far as I can tell, Minecraft is 'all rights reserved'. As far as my decompiler or MCP goes, he used pauls code. It is not freely available, not downloadable. Thus Notch (?) must have asked him for help and/or asked him for permission. Once you found (or I found) the actual license, we'll continue on this. But I am pretty sure you can't copy 80% of minecrafts' source code and get away with it.

    Java source code can be retrieved. The only way to make it 100% closed source (no one can see the source) is to obfuscate it; make it hard to read. But, of course, if it's copyrighted it doesn't mean the software has to be closed source. You win at that point. Though, with a modding API where people will extend entities and copy-paste code, a copyright can be hard to enforce.
     
  12. Offline

    samp20

    Oh, well forget I said that. That still doesn't invalidate my argument though that small parts of the code can be obfuscated. Even personally I'd like it all deobfuscated, although I would be happy with what I explained above.
     
  13. Offline

    Celtic Minstrel

    Minecarts actually trigger an event on destruction... I hope that's still true with your plugin? In any case, you could use that to change what they drop.

    This doesn't affect the rest of your argument.
     
  14. Offline

    bergerkiller

    Celtic Minstrel the problem is that the actual destruction has to be cancelled as well. There is no option to cancel 'just the drops' caused by this destruction. So I'd probably end up monitoring the event being the last plugin to access it, cancel it although people don't like that, and copy+paste the remainder of the function under this event:
    Code:
        @Override
        public boolean damageEntity(DamageSource damagesource, int i) {
            if (!this.world.isStatic && !this.dead) {
                // CraftBukkit start
                Vehicle vehicle = (Vehicle) this.getBukkitEntity();
                org.bukkit.entity.Entity passenger = (damagesource.getEntity() == null) ? null : damagesource.getEntity().getBukkitEntity();
     
                VehicleDamageEvent event = new VehicleDamageEvent(vehicle, passenger, i);
                this.world.getServer().getPluginManager().callEvent(event);
     
                if (event.isCancelled()) {
                    return true;
                }
     
                i = event.getDamage();
                // CraftBukkit end
             
                this.e(-n());
                this.d(10);
                this.aV();
                this.setDamage(this.getDamage() + i * 10);
                if (this.getDamage() > 40) {
                    if (this.passenger != null) {
                        this.passenger.mount(this);
                    }
     
                    // CraftBukkit start
                    VehicleDestroyEvent destroyEvent = new VehicleDestroyEvent(vehicle, passenger);
                    this.world.getServer().getPluginManager().callEvent(destroyEvent);
     
                    if (destroyEvent.isCancelled()) {
                        this.setDamage(40); // Maximize damage so this doesn't get triggered again right away
                        return true;
                    }
                    // CraftBukkit end
     
                    this.die();
                    if (TrainCarts.breakCombinedCarts || this.type == 0) {
                        if (TrainCarts.spawnItemDrops) this.a(Item.MINECART.id, 1, 0.0F);
                    }
                    if (this.type == 1) {
                        EntityMinecart entityminecart = this;
     
                        for (int j = 0; j < entityminecart.getSize(); ++j) {
                            ItemStack itemstack = entityminecart.getItem(j);
     
                            if (itemstack != null) {
                                float f = this.random.nextFloat() * 0.8F + 0.1F;
                                float f1 = this.random.nextFloat() * 0.8F + 0.1F;
                                float f2 = this.random.nextFloat() * 0.8F + 0.1F;
     
                                while (itemstack.count > 0) {
                                    int k = this.random.nextInt(21) + 10;
     
                                    if (k > itemstack.count) {
                                        k = itemstack.count;
                                    }
     
                                    itemstack.count -= k;
                                    EntityItem entityitem = new EntityItem(this.world, this.locX + (double) f, this.locY + (double) f1, this.locZ + (double) f2, new ItemStack(itemstack.id, k, itemstack.getData()));
                                    float f3 = 0.05F;
     
                                    entityitem.motX = (double) ((float) this.random.nextGaussian() * f3);
                                    entityitem.motY = (double) ((float) this.random.nextGaussian() * f3 + 0.2F);
                                    entityitem.motZ = (double) ((float) this.random.nextGaussian() * f3);
                                    this.world.addEntity(entityitem);
                                }
                            }
                        }
                        if (TrainCarts.breakCombinedCarts) {
                            if (TrainCarts.spawnItemDrops) this.a(Block.CHEST.id, 1, 0.0F);
                        } else {
                            if (TrainCarts.spawnItemDrops) this.a(Material.STORAGE_MINECART.getId(), 1, 0.0F);
                        }
                    } else if (this.type == 2) {
                        if (TrainCarts.breakCombinedCarts) {
                            if (TrainCarts.spawnItemDrops) this.a(Block.FURNACE.id, 1, 0.0F);
                        } else {
                            if (TrainCarts.spawnItemDrops) this.a(Material.POWERED_MINECART.getId(), 1, 0.0F);
                        }
                    }
                }
     
                return true;
            } else {
                return true;
            }
        }
    But yes, I agree, I could have done that there. In my case though, I'd have to go against the rules of the events :)
    (there is no 'handle' priority coming after MONITOR)
    Also note that it returns a boolean if correctly handled, from within the event I am unable to change the returned value.

    Also, as far as Pauls code goes, this is in the license on his website (his 3D sound library is used in Minecraft)
    ANY derivative work from this must abide this license. It needs to be stated somewhere, though it doesn't harm open-source or anything. So as far as that goes, I guess there is no real issue so far. Though, it does need a very good license and an agreement modders have to agree with before they start using this API or start using any of the open source code if that is done.

    So yeah, no matter what will be in this API, I am pretty sure you will have to agree with a lot of terms as far as re-using the source code goes. Another subject to talk about I guess...what can be considered copyrighted in Minecraft/server/API?

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: May 24, 2016
  15. Offline

    max0704

    ok sorry
     
  16. Offline

    troed

    http://www.paulscode.com/forum/index.php?topic=34.0

    Just relax. Creating and maintaining open source software is something a lot of people have done successfully over many years. Most of the questions I see people bring up are because they confuse open source either with specific licenses or somehow mistake it for setting limits on copyright or other unrelated things.

    Everything :) Mojang being Swedish actually prevents them from giving up copyright ("public domain" only exists in some countries, the rest would have to use a license like Creative Commons Zero if they want to give away rights).

    Btw, this is why we should love Mojang have hired Bukkit developers:

    https://bukkit.atlassian.net/browse/BUKKIT-988

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: May 24, 2016
  17. Offline

    bergerkiller

    troed that clears up some more then yes. But how do you think the copyright rules will be for the API?

    Since they technically have copyright of all source code, this means that copy-pasting functions from the API into your plugin is not allowed...which makes it kinda of impossible to extend entities and change parts of a function. (other than using super to redirect the function to the bottom layer)

    Although my current Minecart member entity physics function is no where as similar as the one in the current server, it wasn't that way before...then it was the physics function split in two separate functions (preUpdate and postUpdate)
     
  18. Offline

    troed

    While I can speculate, that's something left to Mojang and so far it doesn't seem to have been decided. However, the fact that the API code is copyrighted doesn't say anything about what a license can allow you to do or not. They can have an API license of their choice that allows you to freely use and modify the code in the API implementation (while still, if they want, close off other internals).
     
  19. Offline

    Celtic Minstrel

    Indeed; I had a pull request to fix this, but it never got accepted and is now so outdated that I'm putting off updating it...
     
  20. Offline

    NuclearW

    troed bergerkiller

    As interesting as it may be, I'm going to have to ask you to take your "Who is a better 'professional' software developer" argument to a private conversation, as this certainly isn't the thread for it.
     
  21. Offline

    Don Redhorse

    no we don't.. this has been an issue since more than a year now.. .wait for the RB and it will be ready when it is ready. If you can't instruct your players to stick to an older version run vanilla or a non recommended build. But don't ask developers or the team to speed things up and add additional hours.
     
  22. Offline

    bergerkiller

    NuclearW Don't worry, we've already sorted it out through PM. Forgot to remove the spoiler, will do now.

    Don Redhorse ah well as long as the server is 'runnable' I don't really mind. It has gotten better past build 2002 and I managed to update all of my plugins quite well. For real server admins I can understand it is a bit annoying, as they constantly have to check if the server is still online...
     
  23. Offline

    AlbertoTech96

    i guess your right. they should take there time so the build will be way better than the last. But glad they got the beta out out thanks... :p p.s sorry
     
  24. Offline

    Don Redhorse

    hey, nothing to sorry about... EvilSeph got a lot of bad mails because he released R7, something which is understandable if you keep in mind we live in the NOW GENERATION.. on the other side he will get a lot of bad mails when he doesn't do anything about it.

    I still think that they approach the team envisioned month ago... having RB's as a stable platform to run the server on, stop development when they know that a new release comes and preparing for it, than pushing out dev builds was a quite good idea... unfortunalty they didn't stick with it..

    they are doing a tremendous job trying to fulfill the call of the NOW GENERATION... but those will be the first to look for greener turfs.

    In the end bukkit is nothing without plugins and plugins are nothing without admins and admins are nothing without players and players need to play vanilla without bukkit. A circle... and in that circle are mature people and not to mature... and I think the bukkit team needs to choose which part of the communtiy is their target audience... and also the target audience of mojang.
     
    ledhead900 likes this.
  25. Offline

    AlbertoTech96

    i understand i agree. but that's f't up that they do that if the team quit do you know how bad that would be they really should stop i guess i was a little to press to get the new build but it is true what you are saying btw do you have a server am so bored and no one is going on my because i haven't put it up on P.M.
     
  26. Offline

    ledhead900

    That is just like what I was saying before, If he has all of his IP copyrighted then the only real reason he would have to hide everything is that he has LOTS of borrowed code that IS NOT his the game that is also copyrighted as clearly this is going against what large side of his games community are after.

    I actually have a question for bergerkiller I know you use Craftbukkit as the Bukkit API lacks but I wonder what would it take to merge it so it was one API or if Craftbukkit could be used as a standalone jar on the sever end that wraps the API on client ?, tho I fear that would defeat the purpose of the Mojang merg. I also just wish to say I think its funny that I have literally NO experience with code of any sort for java but I am able to follow and predict what people are asking reasonably alright my only conclusion for the rest of the people who have nothing valid to argue back with is that have no clue what your talking about and therefor should just stay out of the debate.

    In my favor I have experience with bukkit and talking to developers like you and that alone let me peace together a few things and facts about what goes on around here for plugin development.


    <add>
    Everyone
    I think that maybe you all are missing the point us in favor of spout are making, I have only seen you argue against SPOUT for what I can see as it goes against what Bukkit intend to do, It appears NONE of you have done any research for your selves in the alternative nor are any of you really willing to read between the lines of what spout offers that differs so much from Bukkits logic and what they currently offer, when if you bothered to give even a bit of thought and testing. You see for yourself that it covers everything the people debating why we need Craftbukkit and native code.

    I can see the real reason why Burger loves spout its the same reason I love spout, They listen to the developers and cater for it, Any of us PRO spout could have a word with its lead developer today and likely get a response in eaither later today or the following day.


    How many pages are we up to here ?, and where is EvilSeph with any details that can counter our fears and arguements ?, Until he comes on here and tells us all right from the horses mouth what the go is and what EXACTLY will happen in terms of development and so on. There really is NO counter argument.

    You are ALL just talking out your own ends at this point when you try and argue against SPOUT with 'What If's' there has been no new infromation regading the future of Bukkit other then its a merg with Mojang you have no more FACT to tell us. There for we if we want to argue what SPOUT already DOES we can.

    But I have already expressed over and over again that we are not arguing against Bukkit we still enjoy Bukkit I'm pretty sure @Burgerkiller still enjoys his server even tho it runs on Bukkit, I still enjoy Bukkit.

    We are doing nothing more then expressing what we need as a community to develop unique and entertaining mods that go beyond what the Bukkit API would other wise allow. If you think back to Hmod how many plugins did amazing things like modify entity behavior for example ?. Not many and why ? ... because the API did not have support for it and there was no method to write our own extensions.


    Its as simple as this Spout as it stands now lets us extend anything we want and do anything we want, Bukkit so far has no comment.


    To conclude SPOUT is just an example to help backup our claims and wants stop treating us like we are out to kill Bukkit. We are arguing that right now we can extend things fine but only with craftbukkit, but this new news aka this whole thread is sending ringing to our heads about its future based on what we do know about the client and Mojang.

    Which is exactly why SPOUT looks better at this point as given Mojangs past history is pretty doubtful that even HALF of that will get added as it would require MASSIVE code re design and to be frank they are not the most known for optimizations and re writing code to improve anything so even it did get added how much of it would be completely stable and bug free ?
     
  27. Offline

    Celtic Minstrel

    That one's easy. He's busily working at getting a recommended build ready for 1.2, just like the rest of the team is.
     
  28. Offline

    Afforess

    *yawns*

    Did you need something?

    *turns pillow over*
     
    Inscrutable and ledhead900 like this.
  29. Offline

    ledhead900

    Understandable enough. I'm sort of just chilling out over here until Reco, as some stuff I need is not updated yet.

    Actually I should go check what the latest beta is, and if they fixed the entity interaction.
    For the record I like EvilSeph, I'm not against this move it sure would likely result in a client improvement, I'm just more worried about who we would lose from the community as a result so I argue some points around.
     
  30. Offline

    bergerkiller

    ledhead900 -what it would take to merge CraftBukkit and the API into one.
    Well, I am pretty sure everything in the Bukkit library will be taken over. So it is basically listing the differences in Bukkit over CraftBukkit. Why I need to use CraftBukkit still?
    • CraftBukkit allows you to change entity trackers (network synchronizers)
    • CraftBukkit allows spawning custom entities
    • CraftBukkit allows native editing (item max stack size, block states, tile entities)
    • CraftBukkit has faster routines to obtain chunks, entities, players and worlds
    • CraftBukkit chunks allow quick-editing of blocks, while bukkit always requires a lighting update
    • CraftBukkit allows things like lighting editing, packet creation, virtual stuff seen by certain clients
    • CraftBukkit does not create wasteful lists (getNearbyEntities in Bukkit does this, it's slow)
    • CraftBukkit allows changing the network handler (still required by most plugins)
    • CraftBukkit allows changing the chunk sending queue by another object (NoLaggChunks)
    • CraftBukkit has pretty much everything editable, as there are not too many hidden variables
    I guess that is pretty much it. I bet there are more developers that have something to add.
     
    ledhead900 likes this.
  31. Offline

    Don Redhorse

    I have a small one... running R4 still as I didn't have time to update.. but my users don't mind... it is a semi open server.. you can come and visit but you can't build really... we do it for fun, sometimes the server is emtpy, sometimes we have 10 people, in average it is perhaps 3 players. We don't get any additional donations (we are part of a community) and we are mainly just friendly people who know each other for years. Survival and Creative at the same time... people choose... no PVP, no RolePlay.

    When my player update MC they have a backup, so after the get bored seeing the new stuff they come back and keep on building on their stuff... they want stability, our old map was 9 month old, we scrapped it with 1.0.. but at that time we had several worlds so new biomes would only show up in new maps (as the maps where pre "chunked").

    Now we only have one for playing and a hub world, because the changes are too quick... I have to rethink the setup, we still have a spleef and speedball arena but didn't had the time to put the plugin back in and make it work because of all the updates :(

    Perhaps it is only me, but I want stability OVER features and my players too... new features are fine as long as they don't require a new world generator, everything which breaks the current world is a nuisance for people who put a lot of work into their stuff...

    Take a look at Voxelbox, HeroCraft and others... they either have a lot of admins or even own developers and / or they stay with older versions... and their players too..

    my 2 cents...
     
Thread Status:
Not open for further replies.

Share This Page