Update needed for 1.7 about node-minecraft-protocol HOT 78 CLOSED

Is there anything new for it?

from node-minecraft-protocol.

Nothing to report. Anyone want to do a pull request?

from node-minecraft-protocol.

If what's needed is updating the packets, I could give it a whirl later today.

from node-minecraft-protocol.

The data on here is correct, correct? http://wiki.vg/Protocol
The wiki pages are nicely structured, Ima just regex the info and build the protocol from that :P
Should make updating packets easier in the future

from node-minecraft-protocol.

The wiki uses field ID's like 'Keep Alive ID' and 'Gamemode', where as the code uses 'keepAliveId' and 'gameMode'. The case and spacing is important correct? Is there a better source of server info than that site?

from node-minecraft-protocol.

I think 1.7 prefixes a length field to all packets, so now we can ignore any packets we don't understand.

from node-minecraft-protocol.

toClient: [
      { name: "message", type: "ustring" }

What exactly IS type? Is it the java type? Or the JS type? or a JSON type? How do I know if it's supposed to be ustring or string?

Anyways, here is where I am so far http://pastebin.com/rJj6de08
It was generated directly from the wiki page with this script http://pastebin.com/LmKQMFaF

from node-minecraft-protocol.

I usually review the protocol changes in the MCP project:

http://minecraft.gamepedia.com/Programs_and_editors/Minecraft_Coder_Pack
http://mcp.ocean-labs.de/download.php?list.2

Doing diffs for Packet*.java, Net*.java and Entity*Player*.java classes.

But there is still no version released for 1.7.2: http://mcp.ocean-labs.de/news.php?extend.10.1

IMHO, the changes in wiki.vg are not reliable. I've edited it a few times myself with the changes in the new versions. It usually takes a while to have all changes documented there. Although it is really helpful to check your changes.

toClient: [
{ name: "message", type: "ustring" }

What exactly IS type? Is it the java type? Or the JS type? or a JSON type? How do I know if it's supposed to be ustring or string?

See @roblabla's issue #60. I'm not sure if this still applies.

from node-minecraft-protocol.

This, according to wiki.vg, is STILL TRUE for 1.7.

ustring means "unlimited string". Every string sent over the wire are limited to 240 characters. Oh wait, did I say all ? We're talking about mojang here. I obviously meant "every string except the ones sent by the SERVER in chat packets". In packet 3 (chat packet), the server can send a string of a length up to 32767 characters. Hence the "ustring".

http://wiki.vg/index.php?title=Protocol#Chat_Message look at the note, says limited to 32767 chars.

from node-minecraft-protocol.

It looks like the MCP project has released a beta version of 1.7.2 available here:
https://twitter.com/SeargeDP/statuses/415515496503836672

I started to take a look, but as this is my first foray in to the world of Minecraft modding I haven't gotten very far thus far. Figured I would post it here in case anyone else wants to take a dive. =)

from node-minecraft-protocol.

Thanks @jazzdan. Glancing the code, a lot of variables are still obfuscated. It will be really difficult to update this library using this code as guide :-S

from node-minecraft-protocol.

I'm working my way from wiki.vg and the still-obfuscated source to at the very least have the building blocks of a 1.7 version of node-minecraft-protocol. The internal structure will need to change quite a little bit. Right now, my packet object have the following structure :

var packets = {
  "STATE": {
    "toClient": {
      0x00: [
       // the usual stuff
      ]
    }
    "toServer": {
      0x00: [
       ]
    }
  }
}

Also, anything depending on this library will obviously break, because the packets changed, the structure of the packets changed, pretty much everything protocol-wise changed.

More as I progress. I'll probably push to my branch whenever I have the packet dictionary done, and submit a PR when I have something working.

from node-minecraft-protocol.

I'm also thinking we might want to create a more "proper" support for arrays. The current "create a new type each time we need an array" is, to say the least, very dirty. I'm thinking we could do something like the following (statistic packet 0x37)

0x37: [
  { name: "count", type: "varint" },
  { name: "statistics", type: "array", length: "count", content: [
    { name: "statisticName", type: "string" },
    { name: "value", type: "varint" }
  ] }
}

Then the arrays reads "contents" "count" times. This would allow greater flexibility, would be much more future-proof, and suppress the bazillion array types we have right now. Thoughts ?

from node-minecraft-protocol.

Progress have been made, can be seen at https://github.com/roblabla/node-minecraft-protocol/tree/feature-mc1.7 . I am currently struggling with URSA to let node-mc-protocol run on my pc. God I hate that library, it's so goddamn overcomplicated to install. Why the hell can't it "just work", why do I have to uninstall my C++ 2010 runtimes to install a huge-ass SDK, then install Visual Studio 2010 (even though I have 2012), JUST FOR RSA CRYPTO BASED ON OPENSSL.

Anyhow, whenever I get that shit working, I'll be making some quick tests with a real server to make sure the update works/fix the tons of bugs that are likely to pop up, push, and move on to fixing the unit tests.

from node-minecraft-protocol.

@roblabla sorry that library is troublesome. It seems to be a much smoother install on linux. Regardless, if you find a different module that accomplishes the same purpose and is easier to install, I'd be happy to swap it out.

from node-minecraft-protocol.

@superjoe30 well that's the trouble, there's none as far as I can see. I have a branch that uses a pure-javascript implementation of RSA, it works, but it's noticeably slower. I managed to install it in the end, and am now struggling with other problems.

Right now, my problem is that doing client.once(packetId) isn't enough anymore, for there are different packets with such packetId.

The first way I figured to fix this was to add a call to client.emit([states.PLAY, packetId]) (with states an enum-like provided by protocol), but I'm afraid the EventEmitter doesn't like that syntax. Ideally, I think that's what it'd need to look like though. Feel free to tell me if you think I'm wrong though.

I'm trying to figure out what'd be the best way to tackle this problem while staying as compatible as possible. If you have any hints, it'd be cool.

from node-minecraft-protocol.

I think it's acceptable to break compatibility a little bit given that Minecraft completely rewrote their networking layer. In my opinion we should go for the best API possible given the new way that the protocol works, instead of trying to pretend that it works the same way it used to.

I'm not sure I understand the problem you're trying to solve. It sounds like you want to add some state to createClient which you should be able to do by adding some variables, right?

from node-minecraft-protocol.

Alright, let's go from bottom up :

I currently have a "states" object in protocol which is really just this :

var states = {
  "HANDSHAKING": "handshaking",
  "STATUS": "status",
  "LOGIN": "login",
  "PLAY": "play"
}

The idea is that people access the states via this object. Then, the packets object look like this :

var packets = {
  "handshaking": {...},
  "status": {...},
  "login": {...},
  "play": {...}
}

(Originally I wanted to do states.HANDSHAKING as the key, but well... javascript syntax didn't allow me to do that. Oh well.)

The client then has a state, which is initialized at states.HANDSHAKING on creation. Upon receiving a packet, the client currently emits the following events :

self.emit([self.state, packet.id], packet);
self.emit(packet.id, packet);
self.emit('packet', packet);

(I thought the first emit wouldn't work because of the array, but a quick check in the REPL reveals it actually does)
I kept the self.emit with packet.id for compatibility, but I don't know if it's useful.

I also implemented the new login procedure (Yggdrasil) and separated it into it's own module, as I felt it was less awkward that way.

I just pushed my current work to my branch so you can see it at https://github.com/roblabla/node-minecraft-protocol/tree/feature-mc1.7

Now right now, I'm trying to pull my head around a weird bug where the TCP connection is abrupty ended after my client sends the first two packets. I expect the server to be replying to me with an encryption request, but it doesn't happen. I'm investigating with WireShark, comparing the data streams of vanilla client and my client.

from node-minecraft-protocol.

The first argument to emit should be a string. If you give it a non-string, it will convert it to a string anyway.

from node-minecraft-protocol.

Welp, I just realized that they changed the way Strings are encoded. Now they are utf-8 prefixed with a varint. This explains why my code was failing.

from node-minecraft-protocol.

Alright good and bad news. The good news is, I made it work-ish. The bad news is, I only made it work-ish.

The thing can connect to an online-mode server, parsing the packets seemingly without problems, but soon drops out without error, seemingly timing out. As if it was stuck in an infinite loop. As soon as the server times the client out, it exits.

I'm too tired to look at it right now, so I'm going to push the code, and call it a day.

from node-minecraft-protocol.

You guys are way out of my league, but It's awesome to see progress being
made, keep up the good work

On Wed, Jan 1, 2014 at 4:46 PM, Robin Lambertz [email protected]:

Alright good and bad news. The good news is, I made it work-ish. The bad
news is, I only made it work-ish.

The thing can connect to an online-mode server, parsing the packets
seemingly without problems, but soon drops out without error, seemingly
timing out. As if it was stuck in an infinite loop. And I'm too tired to
look at it right now, so I'm going to push the code, and call it a day.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/66#issuecomment-31432040
.

from node-minecraft-protocol.

@Corgano that's the beauty of having a full day of free time. Progress is made 😄 .

On another note, i'm currently trying to fix the test cases. That'll hopefully help me find some of the underlying problems.

Stupid question : what does the benchmark do ? It's hella slow (around 30 seconds to complete the whole thing) and makes testing the tests (I know...) a bit of a pain.

from node-minecraft-protocol.

The benchmark is just because I'm a bit of a performance nut and I wanted
to ensure this library was as fast as possible. Sorry, I hadn't really
thought about how long it would take on every machine, I can make it a lot
quicker.
On Jan 2, 2014 1:31 AM, "Robin Lambertz" [email protected] wrote:

@Corgano https://github.com/Corgano that's the beauty of having a full
day of free time. Progress is made [image: 😄] .

On another note, i'm currently trying to fix the test cases. That'll
hopefully help me find some of the underlying problems.

Stupid question : what does the benchmark do ? It's hella slow (around 30
seconds to complete the whole thing) and makes testing the tests (I
know...) a bit of a pain.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/66#issuecomment-31443282
.

from node-minecraft-protocol.

Okay, good news. The goddamn thing finally works. I need to clean out some debug code, finish fixing up all the tests, and get some shit to work, but I'm able to successfully create a mini-chat client as the library is now.

from node-minecraft-protocol.

Also, since now no deserializer should return null (We know the buffer length beforehand, so we ensure all the deserializer have necessary data), returning null in a deserializer leads to throwing an error. This allows us to easily debug broken packets 😃 .

By the way, the JSON message formatting is beginning seriously out of hand. Vanilla minecraft sends the messages like this :

{ extra: [ '<roblabla> some text here'], text: '' }

I mean seriously... wtf...

from node-minecraft-protocol.

I figured if anything it would send { text: "", extra [ '' ] }
Although, when sending colored text it makes a lot more sense
{ text: "", extra: [ { text: "this is", color: "dark_red" } , { text: "a
color", color: "dark_green" } , { text: "message", color:"light_purple" } ]
}
When sending a colored message, it sends each color as it's own object in
the array. Instead of having it detect if the message has color and
changing the format, It just sends everything as in the same format

On Thu, Jan 2, 2014 at 8:01 AM, Robin Lambertz [email protected]:

Also, since now no deserializer should return null (We know the buffer
length beforehand, so we ensure all the deserializer have necessary data),
returning null in a deserializer leads to throwing an error. This allows us
to easily debug broken packets [image: 😃] .

By the way, the JSON message formatting is beginning seriously out of
hand. Vanilla minecraft sends the messages like this :

{ extra: [ ' some text here'], text: '' }

I mean seriously... wtf...

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/66#issuecomment-31457533
.

from node-minecraft-protocol.

Yeah... but { text: "", color: "yellow" } is also a possibility... https://gist.github.com/thinkofdeath/e882ce057ed83bac0a1c Makes for some ugly code to parse dat json.

from node-minecraft-protocol.

BTW, I just pushed my WIP code. It mostly works, just needs to fix the final few unit tests, then I'll squash all the commits into one, submit a PR, and hopefully it gets pulled upon peer review.

from node-minecraft-protocol.

Cool! If the examples still work I can start testing and looking for bugs

On Thu, Jan 2, 2014 at 9:39 AM, Robin Lambertz [email protected]:

BTW, I just pushed my WIP code. It mostly works, just needs to fix the
final few unit tests, then I'll squash all the commits into one, submit a
PR, and hopefully it gets pulled upon peer review.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/66#issuecomment-31464600
.

from node-minecraft-protocol.

I believe that color flags only change the text in the same objects, so {
text: "", color: "yellow" } would do absolutely nothing.... awkward. Has
the official server / client ever sent such packets? Children with text: ""
could probably be safely ignored

On Thu, Jan 2, 2014 at 11:07 AM, David St. G [email protected] wrote:

Cool! If the examples still work I can start testing and looking for bugs

On Thu, Jan 2, 2014 at 9:39 AM, Robin Lambertz [email protected]:

BTW, I just pushed my WIP code. It mostly works, just needs to fix the
final few unit tests, then I'll squash all the commits into one, submit a
PR, and hopefully it gets pulled upon peer review.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/66#issuecomment-31464600
.

from node-minecraft-protocol.

Sorry, I meant to say { text: "some text", color: "yellow" }. While I haven't observed that behavior in the very limited tests I did with vanilla minecraft, the client happily parsed such text, and so can't be ignored. We can also have something like { text: "hi ", color: "yellow", extra: [{text: "Alfred", bold: true}] }, which outputs hi, Alfred with hi in yellow. But is Alfred also in yellow ? I have no idea.

I'll play around with the chat json once I fix the server part of the protocol (I just realized I forgot to update its login procedure whistle). And the client examples do work. At least they do on my end, tested with an online mode server.

from node-minecraft-protocol.

I was under the assumption it was literally giving text with no text and a
color Lol

I read up on this a bit. That is correct, Alfred would also be in yellow.
Child objects inherit the characteristics of the parent text objects, unles
the child characteristic is defined. This applies to all styles and colors,
and mouse over and click events

A lovely tutorial and examples (with screenshots) is posted here
http://www.minecraftforum.net/topic/1975697-17-tellraw-formatting-examples/

This tool also generates 100% valid tellraw commands, and may help in your
understanding. Like the game, it also leaves the parent object's text blank
http://ezekielelin.com/minecraft/tellraw/

On Thu, Jan 2, 2014 at 11:57 AM, Robin Lambertz [email protected]:

Sorry, I meant to say { text: "some text", color: "yellow" }. While I
haven't observed that behavior in the very limited tests I did with vanilla
minecraft, the client happily parsed such text, and so can't be ignored. We
can also have something like { text: "hi ", color: "yellow", extra: [{text:
"Alfred", bold: true}] }, which outputs hi, Alfred with hi in yellow. But
is Alfred also in yellow ? I have no idea.

I'll play around with the chat json once I fix the server part of the
protocol (I just realized I forgot to update its login procedure whistle).
And the client examples do work. At least they do on my end, tested with an
online mode server.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/66#issuecomment-31474995
.

from node-minecraft-protocol.

@Corgano thank you very much for those, they're very helpful. That does leave me wonder if I could do something like

{
    text: "hi"
    extra: [
      {
         text: "hello"
         extra: [
           "ohi"
         ]
      }]
}

Yeah i know, useless, but still I can't help but wonder :3

EDIT : Nevermind, after going all the way through the link you posted, it is possible. That makes it really fun actually. All hail recursive algorithms.

from node-minecraft-protocol.

You can! It would read "hihelloohi" on the screen. Note, you need to fix
the brackets around the ohi

{
text: "hi"
extra: [
{
text: "hello"
extra: [
{

            text: "ohi"
     }]
  }]

}

On Thu, Jan 2, 2014 at 2:09 PM, Robin Lambertz [email protected]:

@Corgano https://github.com/Corgano thank you very much for those,
they're very helpful. That does leave me wonder if I could do something
like

{
text: "hi"
extra: [
{
text: "hello"
extra: [
"ohi"
]
}]}

Yeah i know, useless, but still I can't help but wonder :3

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/66#issuecomment-31484836
.

from node-minecraft-protocol.

this also means that
{
text: "hi"
color: yellow
extra: [
{
text: "hello"
underlined: true
extra: [
{
text: "ohi"
Ccolor: White
}]
}]
}
hi would be blue, hello would be blue and underlined, and ohi would be
white and underlined
hi_hello_ohi
Inherit parent attributes, apply self attributes, apply text

On Thu, Jan 2, 2014 at 2:28 PM, David St. G [email protected] wrote:

You can! It would read "hihelloohi" on the screen. Note, you need to fix
the brackets around the ohi

{
text: "hi"
extra: [
{
text: "hello"
extra: [
{

            text: "ohi"
     }]
  }]

}

On Thu, Jan 2, 2014 at 2:09 PM, Robin Lambertz [email protected]:

@Corgano https://github.com/Corgano thank you very much for those,
they're very helpful. That does leave me wonder if I could do something
like

{
text: "hi"
extra: [
{
text: "hello"
extra: [
"ohi"
]
}]}

Yeah i know, useless, but still I can't help but wonder :3

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/66#issuecomment-31484836
.

from node-minecraft-protocol.

I derped, change color: yellow to color: blue in the example

On Thu, Jan 2, 2014 at 2:36 PM, David St. G [email protected] wrote:

this also means that
{
text: "hi"
color: yellow
extra: [
{
text: "hello"
underlined: true
extra: [
{
text: "ohi"
Ccolor: White
}]
}]
}
hi would be blue, hello would be blue and underlined, and ohi would be
white and underlined
hi_hello_ohi
Inherit parent attributes, apply self attributes, apply text

On Thu, Jan 2, 2014 at 2:28 PM, David St. G [email protected] wrote:

You can! It would read "hihelloohi" on the screen. Note, you need to fix
the brackets around the ohi

{
text: "hi"
extra: [
{
text: "hello"
extra: [
{

            text: "ohi"
     }]
  }]

}

On Thu, Jan 2, 2014 at 2:09 PM, Robin Lambertz [email protected]:

@Corgano https://github.com/Corgano thank you very much for those,
they're very helpful. That does leave me wonder if I could do something
like

{
text: "hi"
extra: [
{
text: "hello"
extra: [
"ohi"
]
}]}

Yeah i know, useless, but still I can't help but wonder :3

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/66#issuecomment-31484836
.

from node-minecraft-protocol.

Ah, I'm affraid I went completely off-topic with this, but I made a beautiful colorized chat client. https://github.com/roblabla/node-minecraft-protocol/blob/feature-mc1.7/examples/client_chat.js . Only thing missing for it to truly parse all the things is the translation table. But well, it's not like it's used that much in the vanilla client anyway, it seems.

Tomorrow, I'll fix the server login. I think I'm almost done, but it requires testing against vanilla clients.

from node-minecraft-protocol.

I pushed a change that should make the benchmark 10x faster, hopefully that makes it a little less annoying.

from node-minecraft-protocol.

Anyone know a packet editor / sniffer that works with minecraft? I heard
RiPE is supposed to, but doesn't work with 64 bit java. My idea is if the
packets the library sends are the same as the vanilla client sends in the
same situations, it should be compliant.

On Thu, Jan 2, 2014 at 7:03 PM, Matt Bell [email protected] wrote:

I pushed a change that should make the benchmark 10x faster, hopefully
that makes it a little less annoying.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/66#issuecomment-31498757
.

from node-minecraft-protocol.

ok, for some reason the chat client you wrote does not show me anything
someone else says :/ Is there something I'm missing?

On Thu, Jan 2, 2014 at 7:25 PM, David St. G [email protected] wrote:

Anyone know a packet editor / sniffer that works with minecraft? I heard
RiPE is supposed to, but doesn't work with 64 bit java. My idea is if the
packets the library sends are the same as the vanilla client sends in the
same situations, it should be compliant.

On Thu, Jan 2, 2014 at 7:03 PM, Matt Bell [email protected]:

I pushed a change that should make the benchmark 10x faster, hopefully
that makes it a little less annoying.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/66#issuecomment-31498757
.

from node-minecraft-protocol.

@Corgano not an editor and not minecraft-specific, I use wireshark to look at the bytestream going on. One day I'll write a wireshark dissector for mc... one day...

As for the client, it was tested for hours on a 1.7 spigot server without major problems. Could you give me more insight into the problem you had, what server software you tested it with, and maybe the address of the server you used to test it ?

Also, you obviously you need to use my 1.7 branch for it to work. If you try it against 1.6 node-minecraft-protocol, it won't work (even against a 1.6 server).

from node-minecraft-protocol.

using your 1.7 branch, windows 7, via command prompt .bat file and in SciTE
server is 1.7.4 vanilla

adding a console.log on the packet does return nicely:
{ translate: 'chat.type.text',
with: [ { clickEvent: [Object], text: 'SerO3251' }, 'oh..' ] }
but the phrased text seems to return nothing

On Fri, Jan 3, 2014 at 12:27 AM, Robin Lambertz [email protected]:

@Corgano https://github.com/Corgano not an editor and not
minecraft-specific, I use wireshark to look at the bytestream going on. One
day I'll write a wireshark dissector for mc... one day...

As for the client, it was tested for hours on a 1.7 spigot server without
major problems. Could you give me more insight into the problem you had,
what server software you tested it with, and maybe the address of the
server you used to test it ?

Also, you obviously you need to use my 1.7 branch for it to work. If you
try it against 1.6 node-minecraft-protocol, it won't work (even against a
1.6 server).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/66#issuecomment-31507534
.

from node-minecraft-protocol.

more sciencing, it was writing colored text but not normal text.odd
using your example I was able to make somthing that could read the chat and
respond to the chat, but I cannot get anything else to work. using the info
in the protocol.js file, i;ve tried sending playerlook and playermove
packets, but I have had no success. I should be able to:
client.write(0x05, {yaw: 75, pitch: 90.00, onGround: true })
right?

Perhaps this is off topic, should I make a new issue to discuss this in?

On Fri, Jan 3, 2014 at 2:17 AM, David St. G [email protected] wrote:

using your 1.7 branch, windows 7, via command prompt .bat file and in SciTE
server is 1.7.4 vanilla

adding a console.log on the packet does return nicely:
{ translate: 'chat.type.text',
with: [ { clickEvent: [Object], text: 'SerO3251' }, 'oh..' ] }
but the phrased text seems to return nothing

On Fri, Jan 3, 2014 at 12:27 AM, Robin Lambertz [email protected]:

@Corgano https://github.com/Corgano not an editor and not
minecraft-specific, I use wireshark to look at the bytestream going on. One
day I'll write a wireshark dissector for mc... one day...

As for the client, it was tested for hours on a 1.7 spigot server without
major problems. Could you give me more insight into the problem you had,
what server software you tested it with, and maybe the address of the
server you used to test it ?

Also, you obviously you need to use my 1.7 branch for it to work. If you
try it against 1.6 node-minecraft-protocol, it won't work (even against a
1.6 server).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/66#issuecomment-31507534
.

from node-minecraft-protocol.

@Corgano oh, my client doesn't parse translate yet. I was too lazy to find the different keys of translate. After looking around a bit, I found them quite easily, but I must say I'm a bit lazy to add them all (It's a gigantic .lang file located in the .minecraft/assets). I added the main ones now though, so you can grab the latest push and run it. Maybe in a more full-fledged client, I'll add support for importing the .lang file, but it's outside the scope of a built-in example (I believe it's already too big for what it's supposed to be anyway...).

As for the playerlook and playermove, you should make sure the client is in PLAY state (client.state === states.PLAY) before sending the packet. If it was and is still failing, then we may have a problem.

I was wondering, would changing client.write to client.write([state, packetId], parameters) be good ? For one, it conveys more meaning as to the intent of the piece of code, since each packetId can lead to different packets now. Another advantage is that we could cache the packet if we aren't yet in the asked state, sending it as soon as we reach it.

However, this means adding a bit of bloat to the code that might not be directly obvious to the library's user. Another way to go with this is add a 'state' event that triggers as soon as the client's state is changed, and let the library's user take care of the caching and checking. In this case, client.write([state, packetId]) would return true/false depending on the success of the write ? Thoughts ?

from node-minecraft-protocol.

I've tried wrapping the code with a client.state==states.play if statement
with no effect. I have yet to find a working combination to make the client
do anything other than send chat packets, and do not know enough to narrow
down the issue. It might be me messing up the syntax of a packet that uses
multiple params (chat only uses one, and no example of a multi-param packet
existed so I extrapolated).

If someone has time, could you try to make a working example of a player
look / move packet?

On Fri, Jan 3, 2014 at 6:37 PM, Robin Lambertz [email protected]:

@Corgano https://github.com/Corgano oh, my client doesn't parse
translate yet. I was too lazy to find the different keys of translate.
After looking around a bit, I found them quite easily, but I must say I'm a
bit lazy to add them all (It's a gigantic .lang file located in the
.minecraft/assets). I added the main ones now though, so you can grab the
latest push and run it. Maybe in a more full-fledged client, I'll add
support for importing the .lang file, but it's outside the scope of a
built-in example (I believe it's already too big for what it's supposed to
be anyway...).

As for the playerlook and playermove, you should make sure the client is
in PLAY state (client.state === states.PLAY) before sending the packet. If
it was and is still failing, then we may have a problem.

I was wondering, would changing client.write to client.write([state,
packetId], parameters) be good ? For one, it conveys more meaning as to the
intent of the piece of code, since each packetId can lead to different
packets now. Another advantage is that we could cache the packet if we
aren't yet in the asked state, sending it as soon as we reach it.

However, this means adding a bit of bloat to the code that might not be
directly obvious to the library's user. Another way to go with this is add
a 'state' event that triggers as soon as the client's state is changed, and
let the library's user take care of the caching and checking. In this case,
client.write([state, packetId]) would return true/false depending on the
success of the write ? Thoughts ?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/66#issuecomment-31565879
.

from node-minecraft-protocol.

I just finished fixing up the server part of node-minecraft-protocol. Works wonderfully, now all the examples are 100% functional. Not too much left to do, just creating the new 'state' event that triggers when the client's state is changed, and fixing the last bunch of tests.

@Corgano I'm having a hard time myself moving my player around. I'll try to create a basic server with a ground of dirt to send the vanilla client on and look at how the packets are sent.

from node-minecraft-protocol.

I'd love to hear how you accomplish this. With wireshark I was able to see
the packets but forgot about the encryption :/

On Sat, Jan 4, 2014 at 7:13 AM, Robin Lambertz [email protected]:

I just finished fixing up the server part of node-minecraft-protocol.
Works wonderfully, now all the examples are 100% functional. Not too much
left to do, just creating the new 'state' event that triggers when the
client's state is changed, and fixing the last bunch of tests.

@Corgano https://github.com/Corgano I'm having a hard time myself
moving my player around. I'll try to create a basic server with a ground of
dirt to send the vanilla client on and look at how the packets are sent.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/66#issuecomment-31578101
.

from node-minecraft-protocol.

Derp, re-read that, makes sense - you can read from the console of the
server you're running :P

On Sat, Jan 4, 2014 at 8:59 AM, David St. G [email protected] wrote:

I'd love to hear how you accomplish this. With wireshark I was able to see
the packets but forgot about the encryption :/

On Sat, Jan 4, 2014 at 7:13 AM, Robin Lambertz [email protected]:

I just finished fixing up the server part of node-minecraft-protocol.
Works wonderfully, now all the examples are 100% functional. Not too much
left to do, just creating the new 'state' event that triggers when the
client's state is changed, and fixing the last bunch of tests.

@Corgano https://github.com/Corgano I'm having a hard time myself
moving my player around. I'll try to create a basic server with a ground of
dirt to send the vanilla client on and look at how the packets are sent.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/66#issuecomment-31578101
.

from node-minecraft-protocol.

@Corgano After a lot of fighting and headbanging, I finally have a minecraft server that creates a (very) basic floor, spawns the client on it, and console.logs the packets the client sends. You can find it at https://github.com/roblabla/node-minecraft-server . And I must say I hate, from the bottom of my heart, the thing they use to send chunks. And nodejs' zlib library.

Also, added the state event to the client. Tomorrow I clean everything up, squash everything into just a couple commits (One for the update to 1.7, one for the new example), and submit a PR.

from node-minecraft-protocol.

@Corgano from http://wiki.vg/How_to_Write_a_Client
"To test if moving around is working, watch your avatar move around from a notchian client.

If your avatar remains still despite your position update messages, then maybe you didn't apologize in response to the server correcting your position. Reconnect to give yourself another chance."

So according to what I understand by reading around, you need to send position changes VERY often (like around every 50ms) during the movement. The server will send a response if your movement was impossible, in which case YOU NEED to send a new movement packet with THE SAME data, otherwise server ignores any future movement packets. If your movement was correct, the server won't give any response it seems.

from node-minecraft-protocol.

So I would have to find where i am and want to go, calculate using my speed
how far I go every .05 seconds, loop through them, each time checking if I
receive a update packet from the server and if so moving to that position
instead?

x = 0
x2 = 10
speed = 1.3 *20 <- for speed per .05 seconds
speedperpacket = (x2-x)/speed

for x = 0 to 10 step speedperpacket
send 0x04 with new x
wait 50 ms
if received 0x08 then
send 0x04 with same data
wait 50 ms
continue or exit loop and return failure?
end if
end for

The packet the server responds / corrects with is 0x08 right?

I also just realized something. The wait is';t completely arbitrary, it is
20 times a second - exactly the same as a game tick! This means when you
hold forward the client sends a packet with a new position every tick for
the server to update, assumes it works, and moves you visually. Also
explains rubber banding - the client tries to move through a block the
server puts them back in place, causing a visual snap back to the correct
location. Explains a lot of alward things i've seen the client do :D

from node-minecraft-protocol.

Nice algorithm you've got there :) and that's pretty much it. The server should only try to replace you if you went somewhere you couldn't go to (E.G. go through walls).

from node-minecraft-protocol.

When the client first joins a server, it is sent a 0x08 packet, should I
have it respond with a move and look packet? What about sending player look
packets?

On Sun, Jan 5, 2014 at 12:05 PM, Robin Lambertz [email protected]:

Nice algorithm you've got there :) and that's pretty much it. The server
should only try to replace you if you went somewhere you couldn't go to
(E.G. go through walls).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/66#issuecomment-31610659
.

from node-minecraft-protocol.

@Corgano How about you join #mcdevs on freenode IRC ? This isn't specific to node-mc-proto, and the people over there will better be able to help you

from node-minecraft-protocol.

Pull request merged. The API is not finalized yet though.

@roblabla how do you feel about renaming 0x02 -> leftClick to mouse? I think a property rename makes sense since the value is now flipped; previously 0 would be right click and 1 would be left click; now 1 is right click and 0 is left click.

from node-minecraft-protocol.

Same with 0x2b: gameMode should be renamed to value.

from node-minecraft-protocol.

I added a checklist to this issue.

from node-minecraft-protocol.

@superjoe30 Good idea. I tried to avoid renaming the fields when I could, but I didn't notice their values changed ^^.

from node-minecraft-protocol.

Working container and array support. It's a bit very more messy than I had first anticipated, but at least it works. I'll try simplifying code more as I proceed. https://github.com/roblabla/node-minecraft-protocol/tree/feature-arraytype

from node-minecraft-protocol.

@superjoe30 Welp, just realized I had commit access to this repo (when did that happen ?_?) and accidentally made a commit through the github interface by editing your repo instead of mine... Sorry about that.

from node-minecraft-protocol.

I've been running the chat example, however every once in a while it will
crash form buffer.js with
throw new RangeError('Trying to access beyond buffer length')
Anyone know why? I assume it has to do with either na unrecognized packet
being sent (which the protocol should be able to safely ignore?) or because
a known packet is sent with too much or little data

On Fri, Jan 10, 2014 at 6:04 AM, Robin Lambertz [email protected]:

@superjoe30 https://github.com/superjoe30 Welp, just realized I had
commit access to this repo (when did that happen ?_?) and accidentally made
a commit through the github interface by editing your repo instead of
mine... Sorry about that.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/66#issuecomment-32022284
.

from node-minecraft-protocol.

@Corgano We need a full stack-trace to be able to trace it down. This happens because one of the decoders fail to decode the packets (most likely, the packet structure is wrong), and I didn't yet code in opportunistic and fail-proof parsing.

from node-minecraft-protocol.

@roblabla you have commit access because we trust you know what you're doing :-)

from node-minecraft-protocol.

well earned I say, great work from all of you!

Past chat bots, I'm not too useful at this level, more likely be writing
things with mine flayer. Although I did get a working chat bot with
!definitions stored in SQL, but not quite example quality

On Sun, Jan 12, 2014 at 11:53 PM, Andrew Kelley [email protected]:

@roblabla https://github.com/roblabla you have commit access because we
trust you know what you're doing :-)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/66#issuecomment-32146891
.

from node-minecraft-protocol.

Any update on this?

from node-minecraft-protocol.

@shadowjay1 I've been busy doing some work on other stuff, but I plan on finishing up with the few new things before 1.8 release. The current master is, however, 100% usable, albeit not having been pushed to NPM nor marked as a release.

Is there anything you feel is missing ?

from node-minecraft-protocol.

Oh, the readme wasn't updated and the issue wasn't closed so I assumed it wasn't compatible with 1.7 yet.

from node-minecraft-protocol.

And now the first protocol-breaking 1.7 update (1.7.6/1.7.7) is out and we still have no stable release 😄

The good news is, it's coming at a fast pace. I only have ONE, small bug to fix, and then some readme-fixing to do, and we're good to go. I will make two different releases for 1.7.2 and 1.7.6 protocols, so there's no problem there.

All 1.7.6 did was add the "data" field in Player Join, and change the way UUID is handled (it's a string now), so it will take very little time to fix it (as a matter of fact, it's already fixed here in local).

from node-minecraft-protocol.

Cool to see some progress. @roblabla tell me your npm username and I'll add you to the list of people who have publish access.

from node-minecraft-protocol.

@andrewrk NPM username is roblabla ^^.

from node-minecraft-protocol.

Done!

from node-minecraft-protocol.

@roblabla, just a line to say you're doing an amazing job. Currently I do not use this library, but I'm thinking on trying to use it soon seeing your great work. Thanks a lot for all your efforts in keeping it updated 👍

from node-minecraft-protocol.

Seconded. The work you have put into this project
@roblablahttps://github.com/roblabla is
greatly appreciated.

Because the two protocols are very similar, would it be possible to write a
single protocol that works for both?

On Thu, Apr 10, 2014 at 3:13 PM, Xabier de Zuazo
[email protected]:

@roblabla https://github.com/roblabla, just a line to say you're doing
an amazing job. Currently I do not use this library, but I'm thinking on
trying to use it soon seeing your great work. Thanks a lot for all your
efforts in keeping it updated [image: 👍]

Reply to this email directly or view it on GitHubhttps://github.com//issues/66#issuecomment-40132476
.

from node-minecraft-protocol.

@Corgano unfortunately, no. Protocol independence is unfortunately not possible given the current structure of the project.

I plan on creating a fix for #65 eventually (although release of current stable will come first), such that code working for one version of the protocol has a good chance of working with the others. Think of it as some sort of compatibility layer. The details will come when I get around to implement it, and it'll need careful development.

from node-minecraft-protocol.

5 months for one update. Hell yeah, we're awesome guys.

0.12.0 pushed to NPM

from node-minecraft-protocol.

We move at bukkit speeds :D

On Fri, Apr 11, 2014 at 12:52 PM, Robin Lambertz
[email protected]:

5 months for one update. Hell yeah, we're awesome guys.

0.12.0 pushed to NPM

Reply to this email directly or view it on GitHubhttps://github.com//issues/66#issuecomment-40233240
.

from node-minecraft-protocol.

LOL—
Sent from Mailbox for iPhone

On Fri, Apr 11, 2014 at 2:32 PM, Corgano [email protected] wrote:

We move at bukkit speeds :D
On Fri, Apr 11, 2014 at 12:52 PM, Robin Lambertz
[email protected]:

5 months for one update. Hell yeah, we're awesome guys.

0.12.0 pushed to NPM

Reply to this email directly or view it on GitHubhttps://github.com//issues/66#issuecomment-40233240
.

---

Reply to this email directly or view it on GitHub:
#66 (comment)

from node-minecraft-protocol.