1.8 support

[roblabla]

Current focus of the project is 1.8 support, dropping 1.7 off the list completely. This is a meta-bug that will be closed whenever 1.8 support is considered "finished", which should occur when all examples work properly.

[demipixel]

God damnit.

Backtrack about a year ago and I'm trying to get this thing to work. I see that it hasn't been updated in a year, and of course stuff is breaking every which way. I was (and still am) a coder and wanted to try and write bots for Minecraft. I gave up after searching for a week, and a few months ago I decided "why not dive into the protocol itself?". I got some stuff working which was nice, but since I had no idea what I was doing, I copied the mineflayer A* pathfinding because I was NOT going to write one myself. I important that, and I need the biome file. Okay, add that. Oh, and the biome list. Okay, added. Oh, and the block file, the block types, the block lists, etc etc etc GAAHH!

Anyway, I get everything imported and it (for the most part) worked. Manually making collisions was a fun time (bot kept getting kicked for flying on servers or what not). Haven't played Minecraft in a month or two (I go in phases between TF2 and Minecraft. It's been a long TF2 now) and I keep getting these emails about mineflayer. For the past month of getting these, I thought it was different project which was a "programmable bot" but it was in java as a mod. Just today I realized what it was.

And it's being updated for 1.8.3

You suck, now I have to get back into Minecraft.

Cheers, DemiPixel

P.S. "Create Minecraft bots with a powerful, stable, and high level JavaScript API. Note: This project is no longer maintained." Is that gonna change?

[roblabla]

We'll change that once we successfully update to 1.8 I guess. And thanks, it's cool to see people are interested in this project being updated :)

[demipixel]

Should we make a list of things that are needed? I'm interested in starting but I'm not sure exactly where (I have experience with the protocol so I'm aware how to use it).

Some ideas:

• Adding the blocks to enums (and biomes, recipes, etc)
• Updating and tidying up the Docs (would recommend adding at least a little text for every single one)
• Stuff on the roadmap like brewing stands, anvils, and physics (water, ladders, etc) (Would love to see new bounding boxes so we can go against fences, doors, bars etc correctly)
• Update examples to work... correctly...
• Loads of 1.8 stuff that I'm unaware of.

[rom1504]

@demipixel

• There's a list of examples to make work there #180
• it might be interesting to do some testing to figure out what work and doesn't (see #203 ).
• @deathcap is working on updating Burger in order to update the blocks and other enums (see https://github.com/mcdevs/Burger/pull/12)

Currently a lot of examples crashes will lead to seeing that lot of little (or big) parts of mineflayer need fixing. I think it's needed to at least fix the examples / basic functionnalities before working on new things in the Roadmap that were never done.

[rom1504]

What issue actually need solving before we release on npm ? There's the "Stable 2.0" milestone in the issues. Should we actually release the next version as 2.0 ? Anyway putting the issues that need to be solved before the next npm release into a milestone would be useful to know where we are at.

[roblabla]

well, did we make any changes to existing bots in order to make them work with 1.8 ? If the API is still the same, no need to do a major bump.

[rom1504]

Not a lot changed no (the recipe api changed a bit but not much else), so maybe it should be released as 1.2.0.

[rom1504]

So apparently 1.1.0 is not released on npm, nothing about it on doc/history.md. We probably should just delete the tag. And the new version will actually be 1.1.0 then.

[rom1504]

I updated the milestone, it's now "1.1.0" and I updated the issues in it, I think we can release when they are fixed (see https://github.com/andrewrk/mineflayer/milestones/1.1.0) (I also removed the useless 1.1.0 tag so we can release as 1.1.0)

[zuazo]

But if I a have a bot that uses mineflayer and currently works against 1.6 servers (the latest released version in npm) and I'm using it inside a complex production platform/application/architecture, updating to this new version that only supports 1.8 will probably break my application. And any breaking change should be released as a major bump.

This means that any protocol update change needs to be released as a major bump (being cautious). But there is nothing wrong about it. Everything would be different if mineflayer supports multiple protocols simultaneously, but it is not the case. It would also be different if mineflayer supports old versions of node-minecraft-protocol in package.json, but it is not the case.

Am I wrong?

[roblabla]

Yes and no. Your bot that currently work on 1.6 server will work on 1.8 server assuming you only use public APIs. If you want to support a specific minecraft server, you should pin an exact mineflayer version in the package.json, as that is an implementation detail. At least that's the way I see it.

[zuazo]

But the moment you drop 1.6 support, your library is not backwards compatible because you need to upgrade your minecraft server to keep it working. It is not transparent for the user. It is like dropping node 9 support or something similar. I'm seeing the minecraft server as a dependency here.

Perhaps the supported protocol version must be documented in the API, so if the supported protocol version changes, the API (documentation) also changes.

Anyway, IMHO if there is any possible backwards incompatible change, we must do a major bump just in case. But I also understand your point. I'm not entirely sure which is better :confused:

[rom1504]

Okay so the 1.1 milestone is now done (see https://github.com/andrewrk/mineflayer/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.1.0) I'm not exactly sure about what's absolutely better between 2.0 and 1.1. But I think 1.1 makes sense regarding the fact that you don't need to update many things in your bot using mineflayer (I actually found this to be true in rbot : very little change to make to update to current mineflayer from 1.0).

So I think we can go with 1.1.

If everybody is okay with that I'll publish to npm tonight ? (add stuff to history.md, bump the version number, and npm publish (do I have the rights to npm publish ?))

[roblabla]

I added you as a collaborator to the npm package, so you should be able to publish now.

Also, :+1: for release. As for the correct version number, IDK. I understand @zuazo 's point of view, but I don't know if it's worth bumping MAJOR each time we have a protocol upgrade.

[zuazo]

Yes, 1.1.0 it's OK for me too :+1: Let us make a major bump when we meet more clear compatibility issues.

[rom1504]

Done :) mineflayer supports 1.8

[zuazo]

Wonderful @rom1504! Everything is OK. Thanks! :beer: