02:06 < javaprophet> Hmm?
02:07 < Meeeh> http://imgur.com/gAwhFow chickens
02:07 < javaprophet> :D
02:08 < javaprophet> Those chunks in the background though....
02:08 < Meeeh> just client trying to render
02:08 < Meeeh> blame Mojang
02:10 < Gjum> :D
05:28 < Keba_> hi
05:28 < Keba_> Someone here?
05:32 < Keba_> md_5?
05:32 < javaprophet> Hello
05:32 < Keba_> hi
05:33 < Keba_> do you know about protocol?
05:33 < Keba_> got some questions :c
05:33 < javaprophet> Yes.
05:34 < Keba_> Cool...
05:34 < Keba_> it is complex
05:35 < Keba_> Overall: I want to break a block infront of the player...
05:35 < javaprophet> Spit it out.
05:35 < Keba_> I can allready get the serverchuncks but I don´t know how to get the block infront on the player
05:35 < Keba_> (It is only terminal no screen)
05:36 < javaprophet> http://wiki.vg/
05:36 < javaprophet> Look up SMP Map Format
05:37 < EqDev> hey javaprophet  you know packet compression right?
05:37 < javaprophet> Yes.
05:38 < EqDev> Packet Length : Length of Data Length + compressed length of (Packet ID + Data)
05:38 < EqDev> Is the Id and data compressed?
05:38 < EqDev> or just the lenth
05:38 < EqDev> length*
05:39 < javaprophet> ID & Data are compressed.
05:39 < EqDev> But data length is not
05:39 < EqDev> in the first field
05:39 < Keba_> But how do I know where the player is?
05:40 < javaprophet> Correct.
05:40 < javaprophet> Player position packets.
05:40 < javaprophet> Lookup protocol on wiki.vg
05:41 < Keba_> Thanks but how to i force the server to send this packet
05:41 < javaprophet> It sends your position every tick, record it.
05:42 < Keba_> ok thxi thinlk that helped a lot
05:42 < EqDev> javaprophet if compression is enabled, but it is under the threshold, do we send it as compressed or not compressed?
05:43 < javaprophet> Compressed, with the second length  == 0
05:43 < EqDev> oh the second field, data length
05:43 < EqDev> is 0, gotcha
05:49 < EqDev> how do we compress the int and the data?
05:49 < EqDev> Inflater?
05:50 < javaprophet> Yes.
05:50 < javaprophet> Deflater for compressing.
05:50 < javaprophet> Inflater for decompressing.
05:52 < EqDev> deflator takes in #deflate(byte[]). Should I create a ByteBuf and write the id as a varint then use the bytes[] as the parameter for the deflate method?
05:52 < javaprophet> I dunno, I don't use bytebufs.
05:52 < EqDev> How do you convert the int to a byte[]
05:53 < javaprophet> Serialize it?
05:53 < javaprophet> Read the protocol specs on wiki.vg, It will explain it all.
05:55 < EqDev> I am reading the compression section
06:05 < Keba_> javaprophet?
06:05 < javaprophet> Hmm?
06:06 < Keba_> ServerEntityPositionRotationPacket?
06:06 < Keba_> Is that correct?
06:06 < javaprophet> Sure.
06:06 < Keba_> Thanks :)
06:08 < Keba_> Could I send a ClientPlayerRotationPacket to change the rotation or schould that be a ServerEntityPositionRotationPacket too?
06:10 < Keba_> ?
06:10 < javaprophet> Yes.
06:11 < Keba_> ClientPlayerRotationPacket or ServerEntityPositionRotationPacket which one do I have to send to move the player
06:11 < javaprophet> ClientPlayerRotationPacket
06:11 < Keba_> ok
06:11 < Keba_> thx
06:12 < Keba_> I tried but he dosn´t move at all
06:13 < Keba_> Any Ideas what I could have done wrong? Do I have to register anything
06:16 < Keba_> ?
06:16 < javaprophet> You have to read the protocol. And implement it too.
06:16 < javaprophet> Debug your code perhaps.
07:19 < Keba_> hi
07:20 < Keba_> Is there a way to read the Playerinventory? Protocol?
08:42 < nickelpro> Keba_: read the wiki.vg protocol page, it answers all your questions
18:52 < EqDev> hey javaprophet. about the compression we talked about yesterday. When we set the packet id to 0 when the packet is uncompressed in the compression state, then how do we get the real packet id? Like if I send a chat packet and it is under the compression threshold, how will the client know its a chat packet when id is 0
18:52 < javaprophet> The data length will be 0, and the next varint is the packet id.
18:58 < Gjum> > Sent by the server before it disconnects a client. The server assumes that the sender has already closed the connection by the time the packet arrives.
18:58 < Gjum> isn't that a contradiction?
18:59 < Gjum> shouldn't that read "The client assumes that the server(/sender) has already closed ..."
18:59 < javaprophet> Probably, yes.
18:59 < javaprophet> I think sender and server got mixed.
18:59 < Gjum> mediawiki misses the blame feature :/
18:59 < javaprophet> Perhaps, "Sent by the server before it disconnects a client. The client assumes that the server has already closed the connection by the time the packet arrives."
19:00 < EqDev> thats contradiction
19:02 < nickelpro> Back in the day disconnect was a two way packet and well behaved clients sent it to the server in order to inform the server that nothing had gone wrong and it was disconnecting on user request
19:02 < nickelpro> Thus, "the server would assume the sender has already closed the socket"
19:03 < javaprophet> Aah, makes sense.
19:03 < nickelpro> That line clearly needs to be fixed, since Disconnects are exclusively Clientbound now
19:03 < Gjum> well that description is on the clientbound packet...
19:03 < Gjum> yeah
19:05 < nickelpro> I'm unclear on how we stop the server from saying the client errored out. I think I solved it in SpockBot by politely shutting down the socket before disconnecting
19:19 < EqDev> "compressed length of (Packet ID + Data)". So that is Packet ID compressed + Data compressed or. (Packet ID+Data) compressed
19:26 < EqDev> right javaprophet 
19:33 < ecx_> wow
19:33 < ecx_> with javaprophet in the channel
19:34 < ecx_> its almost like theres actually people
19:34 < ecx_> also wtf is up with my nick
19:35 < javaprophet> Your packet length is the compressed data, data length, and packet ID, data. Your data length is 0 for non compressed, and it it's self is never compressed.
19:35 < javaprophet> Packet Length is the length of everything but it's self.
19:35 < javaprophet> Data length, if compressed, is the size of the uncompressed packet.
19:35 < javaprophet> (incl packet id)
19:46 < EqDev> oh
19:46 < EqDev> hmm
19:48 < javaprophet> http://scr.javaprophet.com/105046.jpg
19:48 < EqDev> i thought you could only compress a byte[]
19:48 < ecx86> autofarm??
19:49 < javaprophet> A varInt can be turned into a byte[], you serialize it.
19:49 < javaprophet> Yes, I've had him run overnight, quite a lot of potatoes.
19:49 < ecx86> v o u c h 
19:49 < ecx86> lmao, serializing a varint. when ints are really just 4 bytes.
19:49 < ecx86> classic 
19:49 < javaprophet> Right now, I'm working on item value based on supply and demand, and a base-level inventory management model.
19:50 < ecx86> supply and demand?
19:50 < javaprophet> IE, this AI really wants food, this AI can provide food given farm, which needs a seed.
19:50 < javaprophet> So if the bots are hungry, then they will farm, and the value of food and seeds goes up.
19:50 < ecx86> okay
19:50 < ecx86> that is neat
19:51 < javaprophet> Yeah, I'm just having fun with AI :P
19:51 < ecx86> i am now super interested in ur project
19:51 < Gjum> rom1504, rom15043: ^
19:51 < EqDev> so javaprophet this serialization will work: https://gyazo.com/33c1fb20d4e263656b91cbd6bb99bf9d
19:52 < ecx86> or just this
19:52 < ecx86> byte asdf[4]
19:52 < javaprophet> No! Please read the protocol EqDev!
19:52 < ecx86> wait, what endian is it
19:52 < javaprophet> An int is not a varint!
19:53 < EqDev> https://gyazo.com/f56a78b1ea43cb064c110652f888eb1c
19:53 < EqDev> there
19:53 < EqDev> Ill just use bytebug
19:53 < EqDev> bytebuf*
19:54 < ecx86> i just realized something
19:54 < ecx86> ur using a special method to serialize an int
19:54 < javaprophet> Hmm?
19:54 < ecx86> which is literally 4 bytes. lol mojang
19:54 < javaprophet> I know, it's ridiculous.
19:54 < EqDev> wat
19:55 < EqDev> Do you guys serialize with a dataoutputstream?
19:57 < EqDev> javaprophet hows this: https://gyazo.com/14fe562253abd4207564680c848384e6
19:58 < rom1504> ecx86: there are many kind of "int"
19:58 < ecx86> ?
19:58 < rom1504> http://wiki.vg/Protocol#Data_types most of those are ints
20:00 < rom1504> Gjum: yeah it's cool but it's all closed source apparently so well...
20:07 < javaprophet> Closed source and a pay-to-use project. :)
20:09 < Gjum> closed source doesn't prevent leaking state :)
20:10 < javaprophet> Of course not :)
20:50 < EqDev> javaprophet you said data length is compressed in the first field 
20:50 < javaprophet> It is not.
20:52 < EqDev> javaprophet after we convert the packet id to a byte[] and compress it, we just use .length and add it to the other lengths
20:52 < EqDev> righto?
20:52 < javaprophet> Maybe
20:57 < EqDev> so javaprophet a compressed packet would look something like this
20:57 < EqDev> https://gyazo.com/fb404f6143b4fda6c57da4527b02d512
21:13 < rom1504> how is that for a failed anvil saving http://download.rom1504.fr/stuff/mc-saving-gold-fail.png :D ?
21:14 < rom1504> replicate *all* the gold
21:17 < Gjum> sell that as a mod to all the rich kids
22:22 < EqDev> anyone know of any source code of compressing/decompressing packets out there? Having a difficult time with it
22:22 < javaprophet> Take a look at SpockBot, it's a prominent open source implementation.
22:24 < EqDev> For decoding compression, there are three cases: Enabled compression with the packet being under threshold. Enabled compression with the packet being over the threshold. And no compression
22:24 < EqDev> I dont get the enabled compression with packet being under the threshold
22:24 < EqDev> Looking at wiki vg atm
22:24 < rom1504> EqDev: what language ?
22:25 < EqDev> java
22:28 < rom1504> https://github.com/Steveice10/PacketLib/blob/885d03759dce99d1d0a4b49b156d447c0d97b70e/src/main/java/org/spacehq/packetlib/tcp/TcpPacketCompression.java
22:30 < rom1504> of course if you were using a library (MCProtocolLib in java) you wouldn't have to wrote inferior code to handle network
22:31 < rom1504> (MCProtocolLib uses PacketLib)
22:36 < EqDev> yeah I read up on it
22:45 < EqDev> do we handle the decode of a compression packet normally if it is under threshold or over
22:45 < EqDev> over isnt it
22:46 < rom1504> over the threshold it's compressed
22:46 < rom1504> (to make it smaller)
22:50 < EqDev> if it is not compressed we still handle it like a packet with compression tho
22:50 < EqDev> since it is after the set compression packet
22:52 < EqDev> or do we handle it with a without compression format
22:52 < EqDev> rom1504
22:54 < rom1504> you handle it with the compression format yeah
22:54 < rom1504> (but it's not compressed)
22:55 < EqDev> so the order is basically different with a new field added
22:55 < EqDev> other than that they are the same rom1504?
22:58 < rom1504> yes
22:58 < rom1504> http://wiki.vg/Protocol#Packet_format
22:58 < EqDev> yep reading as we were speaking
22:58 < gamingrobot> EqDev: if you want the python version in spockbot here it is https://github.com/SpockBotMC/SpockBot/blob/master/spockbot/mcp/mcpacket.py#L77
23:02 < EqDev> have any of you guys used ByteBuf's before?
23:04 < Meeeh> EqDev, ?
23:05 < EqDev> Meeeh bytebuf.array() will return the bytebufs data as a byte[] properly correct?
23:05 < EqDev> java docs show some differential between it and readBytes with the index reader
23:20 < Not-d54a> [SpockBot] Gjum pushed 5 commits to master [+0/-0/±10] https://github.com/SpockBotMC/SpockBot/compare/2afae44f4114...14c673af3120
23:20 < Not-d54a> [SpockBot] Gjum 8380ff6 - Reflow comment text in basic example
23:20 < Not-d54a> [SpockBot] Gjum b8c1941 - Fix very nasty bug with the Item subclass attributes always being tuples
23:20 < Not-d54a> [SpockBot] Gjum 38b27bd - There is no max_amount, only stack_size
23:20 < Not-d54a> [SpockBot] ... and 2 more commits.
23:21 < Meeeh> EqDev, ugh, sorry, about ByteBuf, not all bufs works this same with .array
23:22 < Meeeh> it will only work for ByteBuf-s that are created on top of byte array as far as I remember. (we are talking about netty ByteBuf?)
23:24 < EqDev> yup
23:24 < EqDev> I think bytebuf.readBytes(byte[] ) would work Meeeh 
23:25 < EqDev> im trying to inflat a varint atm, no luck
23:25 < EqDev> i serialized it and decompressing it is taking a while
23:27 < EqDev> any other ways Meeeh ?
23:28 < EqDev> or rom1504 
23:28 < Meeeh> nah, I don't have time today, but look into NMS (in spigot maybe, so it will be a bit more readable) and thier PacketDataSerializer
23:31 < EqDev> found nothing there
23:31 < EqDev> pretty much the same methods as bytebuf
23:33 < Meeeh> it is warpper, so it contains all methods from bytebuf + few own ones, like for varints etc
23:34 < Meeeh> and NMS use it to wrap Unpooled.buffer() into it.
23:34 < Meeeh> EqDev, ^
23:35 < EqDev> yeah same
23:35 < EqDev> I use it for a new bytebuf
23:35 < EqDev> ByteBuf compressedClone = buf; whatever edits I make to buf will not occur to compressedClone right
23:36 < EqDev> 10/10 for java rememberence
23:47 < EqDev> is it normal to have packet id length and data length of 2147483385
23:54 < nickelpro> ecx86, javaprophet, rom1504: If you're interested in AI and Minecraft, consider taking a look at the work the OpenCog guys are doing on embodiment w/ Minecraft http://wiki.opencog.org/wikihome/index.php/Minecraft_Bot_Development_Roadmap https://github.com/opencog/opencog-to-minecraft
23:56 < ecx86> far cry
23:56 < ecx86> 3
23:57 < javaprophet> My bot is already better than theirs...
23:59 < nickelpro> javaprophet: Code or example video at least?
--- Day changed lun. janv. 04 2016
00:00 < ecx86> https://www.youtube.com/watch?v=8U2GxEXceGI
00:00 < ecx86> it is proprietary
00:00 < javaprophet> https://www.youtube.com/watch?v=DNpuaC3SFUo
00:01 < javaprophet> http://scr.javaprophet.com/084054.jpg
00:02 < javaprophet> The donglord has come.
00:02 < javaprophet> ^^^
00:03 < ecx86> the dong comes
00:03 < ecx86> THE DONG TOLLS FOR THEE
00:03 < ecx86> HE IS TONY THE PONY HE COMES
00:04 < ecx86> ok ill stop
00:06 < nickelpro> It's pretty impressive pathfinding, but the same thing can be done with command blocks https://www.youtube.com/watch?v=J2RdAillu9U, that's not AI
00:08 < javaprophet> That's fairly impressive for command blocks, but that's not AI, or even code.
00:08 < nickelpro> No, of course it isn't. But it's equivalent to your video
00:08 < Gjum> /z/z
00:09 < ecx86> maybe u havent seen a combat demo
00:09 < nickelpro> Force field combat is half a dozen LoC forge mod
00:10 < ecx86> its no cheat plus bypassed lmao
00:10 < ecx86> with target selection
00:10 < ecx86> and strategizing
00:10 < ecx86> i think, javaprophet played on a kitpvp server with his bots earlier this week
00:14 < Not-d54a> [SpockBot] nickelpro pushed 1 commit to master [+0/-0/±2] http://git.io/vu33j
00:14 < Not-d54a> [SpockBot] nickelpro d29e98a - Lay groundwork for auth token use
00:15 < ecx86> i can link u some copypaste sources if u want'
00:15 < ecx86> for account login with user/pass
00:15 < ecx86> its from my old alt manager
00:19 < nickelpro> ecx86: We already have a full Yggdrasil implementation https://github.com/SpockBotMC/SpockBot/blob/master/spockbot/mcp/yggdrasil.py, our auth plugin just doesn't offer any API other than user/pass atm
00:19 < ecx86> ok nice
00:59 < EqDev> I get a java.util.zip.DataFormatException: incorrect header check
00:59 < EqDev> When I try to inflate the compressed bytes of packet id and data
01:02 < nickelpro> EqDev: http://wiki.vg/Protocol#Packet_format
01:03 < nickelpro> If Data Length is 0 then the packet id and following data are uncompressed. That's a pretty common cause of your error
01:03 < EqDev> nickelpro I did look at that
01:03 < EqDev> yeah I checked for htat
01:03 < EqDev> ill double check
01:04 < EqDev> yeah my data length isnt 0
01:06 < nickelpro> Are you sure you're using Deflate and not gzip or something? I'm like 80% Deflate doesn't have any headers except for 3-bit block headers which don't event have an invalid state
01:08 < EqDev> okay now I get java heap space
01:08 < EqDev> out of memory wtf
01:09 < EqDev> the readable bytes left of packet id and data is 2147483385
01:09 < EqDev> is that normal nickelpro 
01:10 < nickelpro> lol no
01:10 < nickelpro> You're varint decoder is broken
01:10 < nickelpro> s/You're/Your/g
01:11 < EqDev> it worked for packets before compresion
01:11 < EqDev> if i rewrite the readable bytes to another bytebuf, i get 256 bytes
01:12 < EqDev> when I use that I get the header error
01:12 < nickelpro> EqDev: Unlikely you experience a larger than 2 byte varint before compression is enabled. Try turning off compression on the server and see if it all works peachy
01:13 < EqDev> how could I turn off compression on server
01:13 < EqDev> send compression packet to the server with -1 right?
01:13 < nickelpro> http://minecraft.gamepedia.com/Server.properties
01:13 < EqDev> derp
01:14 < nickelpro> Now for the standard mcdevs disclaimer: If you're using Java and working with the protocol, use ProtocolLib. It avoids all these issues and helps the community
01:16 < EqDev> yep nickelpro it works fine without compression. i get login packets successful
01:17 < nickelpro> EqDev: Fantastic, code link?
01:18 < EqDev> for decoding ?
01:18 < EqDev> yeah decoding
01:19 < EqDev> nickelpro heres the decoder
01:19 < EqDev> http://pastebin.com/NkLT734e
01:21 < nickelpro> You're reading the wrong field to check for compression and your compression check is wrong besides
01:22 < nickelpro> Ignore me
01:22 < nickelpro> I can't read Java sometimes
01:22 < EqDev> lel
01:23 < EqDev> so nothing wrong nickelpro ?
01:24 < nickelpro> You're compression check is wrong though. You shouldn't be checking if the data is under the threshold or not when you're recieving. If the uncompressed data length is 0, the following fields are uncompressed. If != 0, the following fields are compressed. Regardless of the compression threshold
01:25 < nickelpro> No idea if that would cause your bug, probably not
01:25 < nickelpro> Worth fixing either way
01:26 < nickelpro> Actually, the would probably cause your bug
01:26 < nickelpro> I dunno, fix and see
01:28 < EqDev> nope
01:28 < EqDev> buf is sitll too many bytes
01:28 < EqDev> nickelpro
01:29 < nickelpro> Then there is nothing wrong with the code you pasted
01:30 < EqDev> weird
01:31 < nickelpro> Just means the bug is somewhere else. I once struggled with packet decoding for a few hours because some orphan bytes were getting left in read buffers. I was looking for a problem in packet decoding when the bug was in my network code. These things happen
01:32 < EqDev> okay
01:32 < EqDev> ill do some more testing
01:36 < EqDev> are you 100% that code is fine nickelpro 
01:38 < nickelpro> No, I can't Java for the life of me. Semantically it's correct, I know nothing about the internals of anything though
01:41 < EqDev> this is really weird. when I find the index of the bytebuf of the packet before reading the bytes, it returns 626
01:41 < EqDev> 262*
01:48 < rom1504> nickelpro: http://wiki.opencog.org/wikihome/index.php/Minecraft_Bot_Development_Roadmap are cool objectives but really they are not much different from the ones we had with mineflayer and spockbot for years. Any clue what they are going to do differently to do all this in a year ?
01:49 < rom1504> and some of these objectives are so specific, sounds like they don't know much about mc
01:49 < rom1504> like "Ability to navigate terrain looking for trees or food."
01:49 < rom1504> that's so specific
01:49 < rom1504> why "trees or food"
01:50 < rom1504> why not "some block X", and "some entity Y"
01:52 < gamingrobot> rom1504: because they are basing stuff off the unity version they had of a voxel engine
01:52 < rom1504> https://github.com/opencog/opencog-to-minecraft/blob/master/minecraft_bot/src/mcdata/mcidmap_blocks.py : duh, are they using spockbot or not
01:53 < rom1504> the atomspace thingy is probably interesting though
01:56 < gamingrobot> rom1504: yea they are it looks like they have updated since I last looked at the code
01:56 < gamingrobot> Not sure why the overlap for mcdata
01:57 < gamingrobot> That code may have existed before we got the new mcdata setup in spockbot
01:59 < rom1504> yeah sure probably
02:01 < rom1504> I'm interested in the open "AGI" thingies though. I mean I think it's a good objective to build something general like that. But it seems to me that they (say opencog and nars) are currently big semi-theoritical things that don't actually do anything
02:02 < nickelpro> They totally are, I think AI is mostly intellectual masturbation. But other people brought the subject up and OpenCog is one of the real OSS projects doing much work on hard AI
02:03 < ecx86> Cool
02:03 < ecx86> I'll look into that
02:06 < Not-d54a> [SpockBot] nickelpro pushed 1 commit to master [+0/-0/±1] http://git.io/vu32x
02:06 < Not-d54a> [SpockBot] nickelpro 4ba75c9 - online_mode defaults to True, AuthCore bitches loudly about credentials
02:08 < gamingrobot> Opencog was the original reason I started working on spockbot
06:04 < Xerxes> How do you set a player entity's name title color?
12:16 < rom1504> Xerxes: I bet by settings the displayName field to something with colors
12:17 < rom1504> http://wiki.vg/Protocol#Player_List_Item
12:17 < rom1504> "Display Name" take a "chat format"
12:17 < rom1504> you can put colors in that http://wiki.vg/Chat
12:53 <+SinZ> does anyone know what the Wii-U version is like compared to PC or the other consoles?
12:55 < rom1504> apparently it's MCPE
12:56 <+SinZ> I cant find any info on the wii-u edition
13:01 < rom1504> http://www.mcpestuffs.com/2015/12/minecraft-wii-u-edition-out-now/
13:03 <+SinZ> so its the most expensive version of minecraft, with pretty much the worst feature list
13:09 < rom1504> expensive in what regards ?
13:10 < rom1504> I doubt it's slow
13:10 < rom1504> it's not expensive in term of money either
13:10 < rom1504> and its protocol is better
13:10 < rom1504> now, there is little to no documentation about it
13:22 < jast> I guess "not expensive" is a different thing from "most expensive" :)
13:25 < rom1504> ohh they're selling it at 30$
13:25 < rom1504> I was talking about mcpe
13:25 < rom1504> which is 5$
13:25 < rom1504> interesting to sell the same thing with 2 different prices
13:25 < rom1504> much marketing
13:34 < jast> target audience
13:34 < jast> console players are used to paying $$$ for games
13:34 < jast> probably some fees go to nintendo, too
13:36 < rom1504> yeah, it's like apple apps, you can make them pay more
13:36 < rom1504> since they're here to pay to begin with by buying a more expensive device anyway
15:30 < barneygale> is the place to replace the Java version with something based on MCPE eventually?
15:31 < rom1504> they're saying they won't, but yeah I think so
15:31 < rom1504> once mcpe is feature complete and used by enough people
15:32 < rom1504> and maybe that plugin maker are okay with doing plugins not in java
16:35 < nickelpro> PE is the better protocol if you overlook the RakNet code
16:39 < rom1504> I don't know raknet at all, just as I don't know netty. The protocol is independant of that
16:40 < rom1504> well, some conception decision might be a consequence of the chosen implementation
16:40 < rom1504> but in the end if you compare the protocol of mcpe and mcpc, mcpe is much simpler
16:40 < rom1504> I'm not sure if the reason is because features are still missing, hopefully not
17:06 <+SinZ> is the pocket edition infinite terrain?
17:15 <+Thinkofname> nickelpro: from what i've heard the inventory handling (protocol wise) for PE is horrible though
17:16 < nickelpro> Thinkofname: >Implying inventory handling in Notchian is any better
17:17 <+Thinkofname> at least you can tell what the client was doing on the desktop version :P apparently PE just tells you 'I now have X in slot Y' or something
17:30 < rom1504> that sounds like a good thing to me
17:31 < rom1504> why should the server care about clicks ?
17:31 < rom1504> (/know)
17:31 <+Thinkofname> rom1504: It doesn't tell you where it came from though
17:31 <+Thinkofname> so they could (I guess) just spawn something in
17:32 < rom1504> it doesn't say "I have now 1 gold in slot 10" and "I have 0 gold in slot 9" ?
17:33 <+Thinkofname> in two seperate packets, you'll have to put the move back together yourself
17:33 <+Thinkofname> no idea how raknet works but its udp too which can't make that fun
17:33 < rom1504> yeah I see your point, it would be better to have a item_moved packet
17:34 < rom1504> (I don't know mcpe that much, just quickly looked at it at one point)
17:34 < rom1504> *mcpe protocol
17:35 <+Thinkofname> same :P I've just had two different people complain about the same issue with me
17:50 < nickelpro> There should be a "Move item from x to y" for serverbound inventory. But the click system in vanilla is terribad
18:35 <+ammar2> Thinkofname: rak has a relability layer
18:35 <+ammar2> a very thorough one actually
20:15 < Gjum> rom1504: https://www.reddit.com/r/Minecraft/comments/3xpwq6/google_now_shows_minecraft_block_information/
20:21 < rom1504> yeah I saw that a while ago
20:22 < rom1504> I think they parse all mediawikis
20:23 < Gjum> wasn't there an error in some data sheet? doors or such? could check if google has it too
20:26 < rom1504> https://github.com/PrismarineJS/minecraft-data/commit/9348158fb08afdb65c22479b242dd4dd1281c06b
20:26 < rom1504> but minecraft jungle door doesn't give anything in google here
20:26 < rom1504> which makes sense
20:27 < rom1504> because they parse the infoboxes
20:27 < rom1504> nothing else
20:27 < rom1504> and the different doors are not in the infobox
20:27 < Gjum> right
20:33 < rom1504> http://download.rom1504.fr/stuff/mc-successful-saving.png flying-squid finally has a persistent world :D
20:47 < rom1504> hmm
20:47 < rom1504> where does the vanilla server store the seed ?
20:48 < rom1504> it's not in the region files
20:53 < rom1504> ah http://minecraft.gamepedia.com/Level_format
20:55 < rom1504> more stuff to parse
20:55 < rom1504> ah well it's just an nbt file, that's easy
21:51 < toqueteos> congrats rom1504! I had a lot of fighting with mca files until I got them working properly :D
21:59 < rom1504> :)
23:47 < EqDev> do you guys receive packets that sometimes have too many bytes for a varint in the packet header? jnoah 
23:48 <+ammar2> no, you're probably out of sync in the stream
23:50 < EqDev> i dont believe that is the case ammar2. I have all the bytes come to me in one piece via netty handler adapter
23:50 < EqDev> Is there a possibility its something else
23:51 <+ammar2> well what I mean is you're probably reading a byte as if its the varint but actually you're still in the middle of a packet or somewhere else
23:51 <+ammar2> not that you're actually out of sync in the TCP stream
23:52 <+ammar2> are you sure you're handling the normal packet header vs compressed packet header fine, I think a lot of people miss that and it causes a lot of grief
23:52 < EqDev> well I try to check the data length, but it throws the error on that
23:52 < EqDev> this is after the compression state
23:53 <+ammar2> could you show your packet parsing code please
23:55 < EqDev> http://pastebin.com/zccaVyR1 ammar2 
23:56 < EqDev> line 20 is where the error is thrown with my decoding method (decoding method works perfectly)
23:59 < EqDev> Even if the packet is by chance without compression, it shouldnt error since the second field is a varint for both uncompressed and compressed
--- Day changed mar. janv. 05 2016
00:00 < EqDev> I ran it couple times more and error also occurs at line 9 ammar2 
00:01 <+ammar2> EqDev: you don't actually use the packetLength you read huh
00:01 <+ammar2> does buf.readableBytes() just read everything it can from the stream
00:01 <+ammar2> because if so that's undesirable
00:03 < EqDev> I believe it reads all the bytes at that index ammar2 
00:03 < EqDev> but I also need packetlength to be read so it goes to the next index
00:04 <+ammar2> after you get packetLength from the tcp stream
00:04 <+ammar2> you should read packetLength number of bytes exactly
00:04 <+ammar2> and I'm not sure if your code is doing that right now
00:04 <+ammar2> not really that familiar with netty to say
00:05 < EqDev> ammar2: so you want me to read packetlength after declaring it?
00:05 <+ammar2> I want you to read n bytes from the tcp stream
00:05 <+ammar2> where n = packetLength
00:06 < EqDev> doesnt .readableBytes() only work for byte[]'s
00:07 <+ammar2> no idea, you'll have to consult netty documentation :<
00:07 <+ammar2> https://github.com/ammaraskar/pyCraft/blob/master/minecraft/networking/connection.py#L212-L215
00:07 <+ammar2> but essentially in a conventional networking library it looks like this
00:07 <+ammar2> stream.read(length) <-- that being the key part
00:08 < EqDev> the method readVarInt32 does infact read the bytes
00:10 < EqDev> ammar2: Im sure the decoding works. I get that error every 10-20 packets
00:11 < EqDev> is it a 64 var int ?
00:11 < EqDev> nope it isnt
00:11 <+ammar2> what do you mean by 64 or 32 varint btw
00:12 < EqDev> 64 is actually a long
00:12 < EqDev> so nevermind on that
00:13 <+ammar2> wat
00:13 < EqDev> I fully disabled compression and get the error couple of times
00:13 < rom1504> "readVarInt32" doesn't make sense
00:13 <+ammar2> yeah
00:13 <+ammar2> varints don't really have a fixed size
00:13 < EqDev> 64 and 32 bit varints
00:14 <+ammar2> https://developers.google.com/protocol-buffers/docs/encoding?hl=en#varints
00:21 < EqDev> still get the error
00:21 < EqDev> even from using packetlib's util ammar2 
00:22 <+Thinkofname> ammar2: in minecraft they kinda do \o/
00:22 <+Thinkofname> varint and varlong
00:23 <+ammar2> EqDev: ok so you said that readVarInt32 or whatever actually reads the varint, let's call it n, and then reads n bytes from the stream?
00:24 < EqDev> thanks Thinkofname 
00:25 < EqDev> well
00:25 < EqDev> it reads the first byte
00:25 < EqDev> then it continues so yeah
00:26 < EqDev> the reading of int is correct
00:27 <+ammar2> wait but after reading the int
00:27 < EqDev> I get compression packet, login success, etc..
00:27 <+ammar2> does it actually consume the packets from the stream
00:27 <+ammar2> yeah those will work fine because they come in sequence
00:27 <+ammar2> your thing will only ever start failing when readableBytes() isn't the same as the length of the packet
00:27 < EqDev> btw you do know its the first varint that is causing the error
00:27 < EqDev> int packetLength = Codec.readVarInt32(buf);
00:28 <+ammar2> yeah that's the one I'm talking about too
00:30 < EqDev> yes im sure it consumes the butes
00:30 < EqDev> bytes*
00:33 < EqDev> no more ideas huh ammar2 
00:34 <+ammar2> yeah I'm all out :{
00:34 <+ammar2> I was looking up how bungee does it
00:34 <+ammar2> https://github.com/SpigotMC/BungeeCord/blob/013320fd9ec7e088a61634c28a3a39c5baab302d/proxy/src/main/java/net/md_5/bungee/netty/HandlerBoss.java#L63
00:36 < EqDev> https://github.com/SpigotMC/BungeeCord/blob/master/protocol/src/main/java/net/md_5/bungee/protocol/MinecraftDecoder.java
00:36 < EqDev> ammar2 ^
00:38 < EqDev> even with that decoder as var int, I still get the error every 50 packets or so
00:39 < EqDev> ammar2: is it possible to have a whole packet with a length of 27740
00:39 < EqDev> or 48091
00:40 <+ammar2> that's fairly big, I think usually only the Chunk Data packets get that big
00:40 < EqDev> whole packet size including all fields*
00:40 < Not-d54a> [flying-squid] rom1504 pushed 1 commit to master [+1/-0/±3] http://git.io/vuWO2
00:40 < Not-d54a> [flying-squid] rom1504 48defee - use prismarine-world 0.4.0 to implement loading/saving, use nmp 0.16.6 to fix a small latency bug
00:41 < EqDev> the id for big ones are sometimes 0
00:41 < EqDev> were not supposed to get packets with ids of 0 during PLAY every second are we
00:42 < EqDev> besides keep alive which is every 30 or something
00:43 <+ammar2> oh yeah that's unusual
00:43 <+ammar2> 0 packet id should be absolutely tiny
00:43 < EqDev> https://gyazo.com/ac3e2e0472a4bb66a2dec3eed1fe3b00
00:44 < EqDev> RB = reablebytes
00:46 < EqDev> something is weird. All I do is listen to incomming packets, it should be no different
00:46 < EqDev> than others
00:46 < EqDev> ofc I send handshake and login
00:46 < EqDev> thats all
00:47 <+ammar2> uhh, encryption?
00:47 < EqDev> nope
00:47 < EqDev> testing this offline and no compression
00:47 < EqDev> and localhost
00:48 < EqDev> wait. hold up. we dont need encyption for localhost offline mode do we
00:51 < EqDev> nope we dot
00:52 < EqDev> ammar2 if I dont handle the error will anything happen?
00:52 < EqDev> if I just skip that packet
00:52 < EqDev> or bytes
01:00 < dav1d> usually you get 0 packet ids if you parse incorrectly at least that happened to me, I got flooded with invalid packet ids, mostly 0x00
01:06 < EqDev> dav1d: how did you fix it
01:06 < EqDev> were you using netty as well?
01:09 < dav1d> nope
01:09 < dav1d> I fixed the packet parsing
01:10 < EqDev> how
01:31 < nickelpro> EqDev: there is something very wrong with your packet parsing. I suspect ammar2 was on to something with readableBytes, but unless you're prepared to share all your code its hard to debug
01:32 < EqDev> sure I dont mind
01:33 < EqDev> nickelpro ammar2 What I think is wrong is some of the bytes may be lost in transit. http://netty.io/wiki/user-guide-for-4.x.html
01:33 <+ammar2> >some of the bytes may be lost in transit
01:33 <+ammar2> not really possible with tcp
01:33 < EqDev> It states some bytes may be lost and sent later, not all at once
01:37 < EqDev> its interesting because the packet id's that are 0 start piling up right before the error triggers
02:16 < Not-d54a> [flying-squid] rom1504 pushed 1 commit to master [+0/-0/±1] http://git.io/vuWi8
02:16 < Not-d54a> [flying-squid] rom1504 e7fe4d5 - disable loading/saving in tests
03:24 < EqDev> ammar2 nickelpro I fixed it :D
03:25 < EqDev> I was apparently reading the bytes to the integer wrong which left some bytes out of sequence
10:14 < bobby> hello !
10:16 < bobby> i'm reading the documentation of the Pre_release protocol, and found that in each entity packet (spawn mob, spawn objetc, etc.), an UUID and an EID are sent. Isn't that weird ?
10:16 < bobby> do we really need both ?
10:50 < rom15043> If you want to communicate with the client or the server you do yes. Now does it make sense ? There is probably a reason mojang added the uuid, and they probably didn't remove the eid because it's easier to not remove things
15:43 < Not-5d64> [mineflayer] rom1504 pushed 7 commits to master [+3/-0/±8] http://git.io/vu4AG
15:43 < Not-5d64> [mineflayer] jakibaki 764b6bb - Added Scoreboard functionality Now in the right location
15:43 < Not-5d64> [mineflayer] jakibaki a924340 - Cleaned code up
15:43 < Not-5d64> [mineflayer] jakibaki 21c082d - Cleaned code even further and added emits
15:44 < Not-5d64> [mineflayer] ... and 4 more commits.
17:45 < Not-d54a> [SpockBot] nickelpro pushed 1 commit to master [+0/-0/±2] http://git.io/vuByo
17:45 < Not-d54a> [SpockBot] nickelpro b1ddef4 - Suspend physics on vehicle mounting
21:01 < Not-d54a> [SpockBot] nickelpro pushed 1 commit to master [+0/-0/±1] http://git.io/vu0fh
21:01 < Not-d54a> [SpockBot] nickelpro 7f0c6c6 - API-ified my code
21:03 < Not-d54a> [minecraft-data] rom1504 pushed 3 commits to master [+0/-0/±4] http://git.io/vu0JM
21:03 < Not-d54a> [minecraft-data] Gjum e0a44b5 - Add minecraft:container as sent by Bukkit plugins See also PrismarineJS/mineflayer#293 and SpockBotMC/SpockBot#209
21:03 < Not-d54a> [minecraft-data] Gjum 25b103c - Add minecraft:container as sent by Bukkit plugins See also PrismarineJS/mineflayer#293 and SpockBotMC/SpockBot#209
21:03 < Not-d54a> [minecraft-data] rom1504 7918bd6 - Merge pull request #87 from Gjum/patch-1 Add minecraft:container as sent by Bukkit plugins
21:15 < Not-d54a> [minecraft-data] rom1504 pushed 2 commits to master [+0/-0/±2] http://git.io/vu0Li
21:15 < Not-d54a> [minecraft-data] oldmanmike 1e30c49 - Clean up protocol.json formatting a bit Some minor formatting inconsistencies I noticed while using protocol.json as a reference.
21:15 < Not-d54a> [minecraft-data] rom1504 43c625e - Merge pull request #88 from oldmanmike/formatting Clean up protocol.json formatting a bit
21:23 < Bruqaj> Can somebody explain me what for Clientbound (0x42) Combat Event is used for?
21:24 < Gjum> some say battle music was planned, other than that there seems to be no use
21:25 < Bruqaj> Would be cool if they would make a builtin anti combat log timer using the combat event or something
21:25 < rom1504> "anti combat log timer" ?
21:26 < Bruqaj> So people can't log out while being in combat
21:26 < Gjum> sounds like some timer indicator could be a clientside mod
21:26 < Bruqaj> Player A is below 3 health -> Logs out -> spawns back at spawn
21:26 < Gjum> anyway, you/sb should check the source if it's used anywhere
21:27 < Gjum> some combat plugins make you lose if you log out during combat
21:54 < rom1504> ah yeah it could make you lose
21:54 < rom1504> "can't log out" that's impossible though :p
21:56 < rom1504> except if you put players in an unescapable VR like in SAO but that seems a bit radical :d
22:09 < Bruqaj> SAO?
22:09 < rom1504> https://en.wikipedia.org/wiki/Sword_Art_Online
22:10 < rom1504> players trapped in a virtual world, if people remove their VR headset, they die
22:44 < Not-d54a> [SpockBot] nickelpro pushed 1 commit to master [+0/-0/±1] http://git.io/vu0Pa
22:44 < Not-d54a> [SpockBot] nickelpro 8c1470f - Update setup.py
--- Day changed mer. janv. 06 2016
01:03 < EqDev> Does the client need to send a compressed keep alive packet?
01:03 < EqDev> Or any packet that goes over the threshold?
01:03 < javaprophet> If the size of the packet is > than the compression threshold.
01:03 < EqDev> Gotcha. My packet decoding works great now
01:03 < javaprophet> So, probably not keep alives, unless the comp threshold is very low.
01:03 < javaprophet> Good to hear.
01:07 < EqDev> One thing that is weird is I get an error for decoding a LoginSuccess packet on every login after the very first login 
01:07 < EqDev> The first login when the server restarts has no decoding issues
01:07 < javaprophet> That is weird, probably a bug somewhere in your code?
01:08 < javaprophet> I would debug through and see where something is different.
01:09 < EqDev> Its not the actual packet header decode, it is reading one of the fields that throws the error of a wrong index
01:10 < EqDev_> Just did some debugging
01:10 < EqDev_> Looks like the chat packet was deocoded as the login packet
01:11 < EqDev_> It probably makes sense. During the login stage, the client may receive a chat message which will be read as a login packet since they have the same id
01:20 < EqDev_> Is it even possible to recieve chat messages before login success?
01:21 < javaprophet> No.
01:21 < javaprophet> You probably updated your state to early.
01:21 < javaprophet> You set your state to play AFTER you receive login success.
01:21 < EqDev_> I set the state to play after login success
01:22 < EqDev_> yeah
01:22 < javaprophet> Check how you determine packet type.
01:22 < EqDev_> I check the state and get a list of packets according to that state
01:22 < EqDev_> and chat msg is in fact in play
01:23 < javaprophet> Well, debug your code.
01:23 < javaprophet> If you are in login state, and receive a chat message.
01:23 < javaprophet> You messed up somewhere in there.
01:25 < EqDev_> It receives the PacketLogin correctly
01:25 < EqDev_> Except when I do .readString it returns chat msg
01:38 < EqDev_> I receive login success after set compression, normal right?
02:11 < javaprophet> Yes.
02:23 < EqDev_> javaprophet this is really weird, cannot figure it out.
02:23 < EqDev_> It works flawlessly on first login
04:36 < javaprophet> How does the server update gamemode without a Respawn packet?
04:36 < javaprophet> I tried using Player ListItem/update gamemode and it did not seem to work.
04:37 < javaprophet> Never mind, I was using CTRL+F gamemode on the wiki, what I needed had a space. :P
05:02 < EqDev> javaprophet finally fixed it!
05:02 < javaprophet> good
05:02 < EqDev> packets get decoded nicely with and without compression
05:02 < EqDev> except 1 tho
05:02 < EqDev> KeepAlive packet
05:03 < EqDev> Its varint is 5 bytes 
05:03 < EqDev> not 4
05:03 < javaprophet> I don't think it's a varint.
05:03 < javaprophet> It's a regular int.
05:03 < EqDev> wiki says varint
05:04 < javaprophet> Your right.
05:05 < EqDev> Without compression, I read and wrote it as var64 (long) and it worked
05:05 < EqDev> now with compression none work
05:05 < EqDev> and decoding isnt the issue cause it works with chat msgs and login success
05:06 < javaprophet> What error does minecraft give?
05:06 < javaprophet> In the server, you should see some kind of decoder exception.
05:06 < EqDev> minecraft? the client you mean?
05:06 < EqDev> Im writing the client
05:07 < EqDev> The client errors too many bytes for var int
05:07 < javaprophet> Yes, and your connecting to the server, yes?
05:07 < EqDev> mhm
05:07 < javaprophet> Then look at the server console.
05:07 < javaprophet> It will have a decoder exception.
05:07 < EqDev> server doesnt error anything, just times out
05:07 < javaprophet> Then you may not be sending it at all.
05:08 < EqDev> yeah I dont, cause it errors trying to read it 
05:08 < EqDev> lol
05:08 < javaprophet> Oh, I see.
05:08 < EqDev> it cant be decoded by the client
05:08 < EqDev> > The client errors too many bytes for var int
05:08 < javaprophet> Perhaps as a work around, see if you can just read the rest of the packet from the length of the data, and compare.
05:09 < javaprophet> Maybe you forgot an index somewhere and it pre/appends a byte.
05:11 < EqDev> ill investigate
12:21 < Meeeh> hyym, this http://wiki.vg/Pre-release_protocol#Entity_Metadata location entry seems to not use block location send as long like in prev versions
12:25 < Meeeh> or maybe descreption od ender crystal is wrong o.O
12:26 < Meeeh> description of*
12:43 < Meeeh> ugh, no, types seems to be valid, so why this one entry want to crash my client ;/
12:53 < Meeeh> ok, found my issue, but I still see one problem, that boolean Show Bottom, don't change anything 
13:00 < Meeeh> oh, and now it works, weird
15:30 < Meeeh> http://imgur.com/a/eudqq lel
15:32 < rom1504> oO
15:32 < rom1504> is that a metadata property ?
15:33 < barneygale> ^ wow what's that about?
15:36 < Meeeh> yes, I added it to wiki
15:36 < Meeeh> 0x40 in that byte
15:37 < Meeeh> for glowing effect
15:37 < Meeeh> http://wiki.vg/Pre-release_protocol#Entity_Metadata
15:42 < Meeeh> nah, Crouched flag just change color of name for non-player entites :<
15:45 < Meeeh> rom1504, that glowing works a bit weird, with that hidding all other glowing effects o.O but maybe someone will find some interesting usage for that
15:45 < Meeeh> I must test area entity effect with that xD
15:54 < Meeeh> nah, don't work :<
15:55 < Meeeh> LOL
15:56 < Meeeh> http://imgur.com/a/AVQqz rom1504 look at that :D
15:57 < rom1504> fun
15:57 < Gjum> interesting
15:58 < Gjum> is that a custom server or ingame commands?
15:58 < rom1504> he's building a custom server afaik
15:59 < Meeeh> http://imgur.com/4ppPpKu this looks nice
16:01 < Meeeh> http://imgur.com/ZDxSqtb transparent text, nice
16:01 < Meeeh> Gjum, custom server, playing around entity metadata
16:02 < Gjum> ok
16:03 < barneygale> really cool stuff Meeeh 
16:03 < Meeeh> oh, you can color that text too, even invissible one, o.O
16:08 < Meeeh> http://imgur.com/a/s9D8I I hope that there will be a way to calculate position of player to get good looking text :D
16:11 < ScruffyRules> Meeeh, first one is cool
16:16 < Meeeh> ScruffyRules, yeach, but there is one bad thing about that text :<
16:17 < Meeeh> it only looks good if you are very close to it
16:17 < ScruffyRules> Darn
16:19 < Meeeh> ScruffyRules, http://imgur.com/wRe0KZ3 and I'm only around 3, maybe 4 blocks from it
16:19 < Meeeh> after like 5 blocks, you can't even read it
16:19 < Meeeh> http://imgur.com/a/GESwS
16:20 < ScruffyRules> That's what I hate about the glow
16:20 < ScruffyRules> Makes mobs look so bad from >10blocks
16:22 < Meeeh> yeach, this glowing effect is more and more visible with distance
16:23 < Meeeh> it should stay this same, like around 3 blocks from mob
16:23 < Meeeh> but this cool names as far as I see works only on one type of entity
16:25 < Meeeh> or not :D I will try check few more
16:30 < Meeeh> I think it will work for all object entites
16:39 < Meeeh> nah, not for all, and for some of them it don't looks this same or you need to be even closer o.O (and it don't work for armor stands :<)
16:47 < Meeeh> never spawn fake firerocket without removing it when it should explode... :D 0fps
18:08 < Meeeh> Can be SpectralArrow critical?
22:30 < Guest99297> Hello, i was reading the mc protocol a bit and i have ran into a thing i don't understand. In the SMP Map Format (http://puu.sh/mm553/c46189b000.png) when a packet is received it has an 'Array of Blocktypes and metadata' (http://puu.sh/mm553/c46189b000.png), so im wondering how do you know what size the array is?
22:44 < rom1504> Guest99297: it's length-prefixed
22:45 < Gjum> Guest99297: in the Chunk Data packet, each 16x16x16 chunk array has the same size, and there's a bitmask indicating which chunks are sent
22:46 < rom1504> http://wiki.vg/Protocol#Chunk_Data
22:46 < rom1504> (there's a varint to indicate the whole size of the bytearray)
22:46 < rom1504> but yeah then you need to use the bit mask to know which section go where
22:51 < OnlyQubes> Im sorry my internet disappeared but did anybody answer the question: Hello, i was reading the mc protocol a bit and i have ran into a thing i don't understand. In the SMP Map Format (http://puu.sh/mm553/c46189b000.png) when a packet is received it has an 'Array of Blocktypes and metadata' (http://puu.sh/mm553/c46189b000.png), so im wondering how do you know what size the array is? (sorry : < )
22:52 < rom1504> 22:44 < rom1504> Guest99297: it's length-prefixed
22:52 < rom1504> 22:45 < Gjum> Guest99297: in the Chunk Data packet, each 16x16x16 chunk array has the same size, and there's a bitmask indicating which chunks are sent
22:52 < rom1504> 22:46 < rom1504> http://wiki.vg/Protocol#Chunk_Data
22:52 < rom1504> 22:46 < rom1504> (there's a varint to indicate the whole size of the bytearray)
22:52 < rom1504> 22:46 < rom1504> but yeah then you need to use the bit mask to know which section go where
22:52 < OnlyQubes> Oh okay, thanks :P
23:55 < OnlyQubes> I think i understood how to loop trough the bytes (getting chunk bytes http://wiki.vg/SMP_Map_Format#Data), but im not sure how to read them. I have this code http://pastebin.com/nAiYX8Qe (C#). I think im reading it a bit wrong, any pointers to how to actually read the blocks?
23:57 < OnlyQubes> Oh just noticed that im not reading the metada, but are blockids intigers/bytes/shorts? :? (http://puu.sh/mmb64/a201756e53.png from http://wiki.vg/SMP_Map_Format#Data)
--- Day changed jeu. janv. 07 2016
00:00 < Not-d54a> [SpockBot] nickelpro pushed 1 commit to master [+0/-0/±1] http://git.io/vuwUF
00:00 < Not-d54a> [SpockBot] nickelpro 1f6fb0e - Fix double mounting vehicle entities
00:01 < rom1504> OnlyQubes: blockids are 2 bytes
00:01 < rom1504> https://github.com/PrismarineJS/prismarine-chunk/blob/master/src/chunk.js#L68
00:02 < OnlyQubes> oh, didn't know that. Thank you very much :P
00:02 < OnlyQubes> and metadata is the same im guessing right? :?
00:03 < rom1504> it's the same 2 bytes yes
00:03 < rom1504> once you got these 2 bytes, you can do  >> 4 on it to get the blockid, and & 15 to get the metadata
00:04 < rom1504> I think that link I gave up there ^ (in js) is pretty simple to read if you need more clarification
00:05 < OnlyQubes> yeah, thank you very much man
00:15 < OnlyQubes> @rom1504 im still having trouble, i think im doing it correctly, can you check the code its like 5 lines here is the link: http://pastebin.com/NffZA3jL . Also is chunk data using a custom encryption or compression that i need to decode/decompress before reading the blocks? :?
00:25 < rom1504> OnlyQubes: it's <16 not <15
00:25 < rom1504> compression is the same as the rest of the protocol
00:25 < rom1504> and yes you need to handle it, that packet will most likely be compressed
00:28 < OnlyQubes> Hmm, but do you mean the whole packet is compressed or is this Chunk part has another compression?
00:29 < rom1504> the whole packet
00:29 < rom1504> as in http://wiki.vg/Protocol#With_compression
00:29 < rom1504> the chunk has no specific compression
00:29 < OnlyQubes> Oh yeah, i think the bad was that i was doing 15 instead of 16. Ill check
00:34 < OnlyQubes> Damn, still not working for some reason. And yeah im doing the compression it works for all of the other packets.
00:35 < OnlyQubes> The array even runs out of bytes to read while doing the 16x16x16 loop
00:35 < OnlyQubes> the block and the metadata are supposed to read separate bytes right?
00:37 < OnlyQubes> And the block ids that it gets is 0 or values like 800
00:38 < rom1504> "it works for all of the other packets." how did you test that ?
00:38 < rom1504> you need to decrease the compression threshold to test it
00:38 < rom1504> because if you don't it's likely that only the chunks packet are compressed
00:38 < rom1504> (they are the only ones big enough)
00:39 < OnlyQubes> Well it gets other entities names positions correctly. Also it decompresses the packet well because it gets this packets chunkX, chunkZ, isGroundUp, primaryBitMask and  size as it is supposed to P:
00:39 < rom1504> "the block and the metadata are supposed to read separate bytes right?" <- no, it's the same 2 bytes
00:39 < OnlyQubes> ohh
00:40 < rom1504> OnlyQubes: yeah that shows decompressing works indeed
01:01 < OnlyQubes> Darn rom1504 i might be retarded, but its still not working, sorry D:. I think the code now is trully working ( http://pastebin.com/q8SPqCae ), i guess it might be somewhere else 
01:03 < OnlyQubes> The values with the code above im getting are 0's or 512's
01:04 < OnlyQubes> also the try catch is just for testing, it doesn't actually catch an exception
01:04 < rom1504> OnlyQubes: well why are you still doing 2 BReader.ReadNextShort ?
01:04 < rom1504> you need to do 1
01:05 < OnlyQubes> wait could i do something like int test = BReader.ReadNextShort(ref bytes); and after that blockid =  test  << 4; metadata = & 15; (im pretty bad with this << & stuff)
01:05 < rom1504> yes
01:06 < rom1504> well test >> 4 , not test <<4
01:07 < OnlyQubes> yeah i mean that sorry. okay ill try that. but it shouldn't be anything different, because before that i was just taking the bytes out before and doing a read on those new bytes and a read on the old bytes witch are the same as the new bytes. But ill test it now P:
01:11 < OnlyQubes> darn results are the same, this is so strange
01:12 < OnlyQubes> sorry to be bothering you with my problems D:
01:12 < rom1504> can you pastebin your bytes ?
01:13 < EqDev> anybody know any good 3rd party applications to intercept packets from client to server vice versa and read its contents?
01:13 < EqDev> I looked at a couple on wiki vg
01:14 < rom1504> https://github.com/PrismarineJS/node-minecraft-protocol/blob/master/examples/proxy/proxy.js works well (just got to install node though ;))
01:16 < OnlyQubes> yeah i can, 1 sec rom1504. Do you want the chunk block part or the whole packet with chunkX, chunkZ? :?
01:17 < rom1504> chunk block part
01:17 < rom1504> assuming you split it from the rest correctly ofc
01:18 < OnlyQubes> This is the whole: http://pastebin.com/DZKruGnZ, ill do the block part in 1 sec P:
01:19 < EqDev> where is the protocol.json
01:19 < OnlyQubes> and this is the block part: http://pastebin.com/PuKfW9Bn 
01:21 < rom1504> EqDev: there https://github.com/PrismarineJS/minecraft-data/blob/master/data/1.8/protocol.json
01:21 < Gjum> rom1504: it asys version, shouldnt that be playername? https://github.com/PrismarineJS/node-minecraft-protocol/blob/master/examples/proxy/proxy.js#L5
01:21 < Gjum> *says
01:23 < OnlyQubes> rom1504 this is what is left after it reads the blocks http://pastebin.com/gdR3ymGC (4096 bytes)
01:23 < EqDev> nope Gjum works fine with version
01:24 < rom1504> Gjum: no, we switched to a offline-online proxy
01:24 < EqDev> rom1504 I cant join 25566
01:24 < EqDev> EPERM
01:25 < rom1504> it used to be online-online, but it basically only worked for one user (and you had to give that user/passwd to the proxy)
01:25 < rom1504> and yeah there's a version arg now because it supports both 1.8 and 1.9
01:25 < rom1504> (well 15w40b of 1.9)
01:25 < EqDev> i get disconnected with error ^
01:25 < Gjum> well the examples show a player name there
01:26 < rom1504> ah indeed, will fix the examples
01:26 < EqDev> yeah rom1504 I get disconnected
01:27 < rom1504> EqDev: how did you start it ?
01:27 < rom1504> and on what server ?
01:27 < rom1504> (what version ?)
01:27 < EqDev> node proxy.js --dump keep_alive dir
01:27 < EqDev> 1.8
01:27 < EqDev> dir 1.8 *
01:28 < rom1504> what is "dir" ?
01:28 < EqDev> 1.8.9 as well which is the client verison. not sure if that matters
01:28 < EqDev> directory
01:28 < EqDev> with spigot.jar
01:28 < rom1504> just do node proxy.js localhost
01:28 < rom1504> and you do need to start spigot.jar independently
01:29 < rom1504> it's a proxy not a wrapper
01:29 < EqDev> on what poirt
01:29 < rom1504> 25565
01:30 < EqDev> node proxy.js localhost needs args
01:31 < rom1504> hmm yeah 
01:31 < rom1504> do node proxy.js localhost 1.8
01:31 < EqDev> not working
01:31 < EqDev> EACCESS error
01:31 < EqDev> EACCES*
01:31 < rom1504> did you npm install ?
01:31 < OnlyQubes> Does anybody know what "In half-byte arrays, two values are packed into each byte. Even-indexed items are packed into the high bits, odd-indexed into the low bits." means? :?
01:31 < EqDev> yep rom1504 
01:32 < rom1504> OnlyQubes: yes skylight and all are in half bytes
01:32 < OnlyQubes> but blocks and their metadatas aren't? :?
01:32 < nickelpro> OnlyQubes: it means that the top 4 bits are an even indexed block, and the bottom 4 bits are an odd indexed block
01:33 < nickelpro> OnlyQubes: Block Ids + metadata needs 16 bits, skylight only needs 4
01:33 < OnlyQubes> ahh okay, thanks
01:33 < rom1504> OnlyQubes: see Nibble4 at http://minecraft.gamepedia.com/Chunk_format#Block_format
01:33 < EqDev> rom1504 looks like it works now
01:34 < EqDev> where is the dump located rom1504 
01:34 < rom1504> EqDev: on the console
01:34 < rom1504> by default it dumps nothing though
01:34 < EqDev> --dump keep_alive
01:34 < Gjum> ph boy, how do I node
01:35 < rom1504> EqDev: yeah
01:35 < rom1504> EqDev: you can --dump-all too
01:35 < Gjum> rom1504: I did npm install minecraft-data, so how do I use the proxy? just cd examples/proxy;node proxy.js throws a stacktrace
01:35 < rom1504> and add some -x to exclude big packets (chunk packets)
01:36 < rom1504> (see http://prismarinejs.github.io/minecraft-data/?d=protocol for packet names)
01:36 < rom1504> Gjum: 1. git clone nmp 2. cd nmp 3. npm install 4. cd examples/proxy;node proxy.js
01:37 < rom1504> (npm install installs all the necessary deps)
01:37 < EqDev> it works nicely
01:37 < rom1504> OnlyQubes: all these 255 look weirds, are you sure you're splitting the packet properly ?
01:37 < OnlyQubes> @rom1504 & @nickelpro thank you for your help guys,  the problem was i was using BigEndian bit convertion and chunks are littleendian
01:37 < EqDev> I still have a issue with my custom bot tho
01:38 < OnlyQubes> it works well now :P
01:38 < EqDev> I can decode every other packet flawlessly but keep alive doesnt decode right
01:38 < OnlyQubes> Thank you very much guys
01:38 < EqDev> in keep alive, the varint is 5 bytes instead of 4
01:39 < EqDev> anyidea whats going on? if I read and send it as a long without compression it works fine, but with compression it does not.
01:39 < rom1504> (maybe we should npm release that proxy so people can npm install -g mcproxy && mcproxy localhost 1.8, idk)
01:39 < EqDev> anyone had this experience ^ nickelpro rom1504 
01:40 < rom1504> well
01:40 < rom1504> I know spockbot and node-minecraft-protocol don't assume the size of varint
01:40 < Gjum> rom1504: npm install gets me npm WARN deprecated lodash@1.0.2: lodash@<2.0.0 is no longer maintained. Upgrade to lodash@^3.0.0
01:41 < EqDev> rom1504 I just was reading the bytes
01:41 < rom1504> apparently you can assume it sometimes in minecraft because minecraft is weird, but really you shouldn't be able to assume varint size
01:41 < EqDev> I was just debugging the size
01:41 < EqDev> varints must be less than 5 no
01:41 < rom1504> Gjum: just a warning, we should fix it, but that won't be a pb
01:43 < Gjum> well after that warn I also get npm ERR! Cannot read property 'target' of null
01:44 < rom1504> Gjum: what npm/node version ?
01:44 < rom1504> EqDev: ah yeah I guess
01:44 < rom1504> EqDev: keep alive does have the packet id and all though, isn't that the problem ?
01:46 < EqDev> rom1504 really
01:47 < rom1504> well it has a packet id of 0
01:47 < rom1504> but it's still there
01:47 < rom1504> it's a normal packet
01:48 < EqDev> wait
01:48 < EqDev> gold up
01:48 < EqDev> hold*
01:48 < EqDev> isnt the max varint 6 rom1504 
01:48 < Gjum> 3.5.2/5.3.1
01:49 < EqDev> yep I fixed it
01:49 < EqDev> rom1504 it appears its less than OR equal to 5
01:51 < rom1504> Gjum: can you pastebin your whole npm install log ?
01:51 < Gjum> sure
01:51 < rom1504> it's weird it's failing though, it should work fine with node5
01:51 < rom1504> (it does here)
01:55 < nickelpro> EqDev: A minecraft varint is a 32-bit signed integer packed into a Google protobuf varint. So encoded as a varint its maximum size is 5-bytes that decodes to a maximum of 4 bytes
01:56 < Gjum> ah sorry, I did npm install nmp and then run npm install in the node_modules/nmp - cloning and then npm install worked, thanks
01:56 < nickelpro> 32-bits of data + the 4 sign bits, 36 bits are required to encode a full 32 bit varint which keep alives tend to be
02:15 < Gjum> rom1504: works like a charm, thanks a lot. I noticed your play.craft_progress_bar packet is actually a "window property", which only in one case is the craft progress
02:27 < rom1504> ah yeah it's even called that in mcprotocollib https://github.com/Steveice10/MCProtocolLib/blob/master/src/main/java/org/spacehq/mc/protocol/MinecraftProtocol.java#L361
02:27 < rom1504> guess we have some packet name changing to do at some point
02:55 < Not-d54a> [minecraft-data] rom1504 pushed 3 commits to master [+0/-0/±4] http://git.io/vuwHf
02:55 < Not-d54a> [minecraft-data] Gjum 4f1437c - Fix furnace window properties
02:55 < Not-d54a> [minecraft-data] Gjum e92eb05 - Fix furnace window properties pretty sure it's unchanged in 1.9, but should be verified
02:55 < Not-d54a> [minecraft-data] rom1504 059efb8 - Merge pull request #89 from Gjum/patch-1 Fix furnace window properties
03:06 < EqDev> rom1504 do you know java?
03:06 < EqDev> And bytebufs?
03:06 < rom1504> I know java, but not bytebufs no
03:07 < EqDev> I am having trouble sending non compressed packets in a compression state
03:08 < rom1504> do you send them with this format http://wiki.vg/Protocol#With_compression ?
03:08 < EqDev> yep except its not compressed
03:08 < EqDev> since its under threshold
03:08 < rom1504> yeah
03:08 < EqDev> I write the size of packet id length+packet data length then 0 as a varint, the the uncompressed packet id then data
03:09 < EqDev> https://gyazo.com/9746589f8e2967f5f3cb79492fd76c24
03:09 < rom1504> "size of packet id length+packet data length" you are missing the "Length of Data Length"
03:10 < rom1504> (it's "Length of Data Length + compressed length of (Packet ID + Data)")
03:10 < EqDev> Codec.writeVarInt32(out, 0);
03:10 < EqDev> That will work for data length right
03:11 < rom1504> yes
03:11 < rom1504> but that's not what I meant
03:11 < rom1504> I meant you need to include the length of that 0 in the rest of the length
03:11 < EqDev> yeah I know
03:11 < EqDev> I just fixed it
03:11 < EqDev> thanks!
04:45 < ecx86> minecraft is so turing complete at this point its crazy
05:20 < Fenhl> can anyone explain javaprophet's changes to the articles [[Protocol]], [[Object Data]] and [[Data types]]?
05:21 < Fenhl> rom1504 rom15043: I don't want to read the entire backlog but you were talking to them when they made the change, do any of their changes make any sense to you?
05:22 < Fenhl> I'd clean it up but I don't get what they are trying to say at all. Is it a functional change that was only discovered now or were they just trying to restructure things?
05:24 < Fenhl> if it is the latter I'd like to revert the changes entirely unless anyone objects, since the current version is barely coherent and definitely describes a different protocol from what we had before
05:32 < Fenhl> also is http://wiki.vg/Template:Packet a blank page for anyone else?
05:42 <+ammar2> error 500 forme
06:52 < nickelpro> Revert plz
06:53 < nickelpro> Fenhl: ^ I had noticed something weird about object data in data types but I was distracted by something more pressing
07:06 < Fenhl> nickelpro: I still don't quite get which field can be zero or not and when the speed fields are included
07:13 < nickelpro> Fenhl: Object data is an integer followed by three optional floats. If the integer is non-zero, the floats are sent. If the integer is zero, the floats are not sent. The meaning of the integer is context dependent
07:14 < nickelpro> Is that clear?
07:18 < Fenhl> nickelpro: so for minecarts, the floats are omitted if it's a rideable minecart?
07:22 < nickelpro> Fenhl: Correction, three shorts, not three floats. And I'm pretty sure everything else on that page is wrong. Object data is a weird poorly documented thing that rarely ever makes an appearance
07:23 < nickelpro> But ya, I'm 100% on non-zero ids being followed by 3 shorts
07:23 < Fenhl> wait what
07:23 < nickelpro> I have no idea if any of those ids on the object data page and their contexts being correct
07:23 < Fenhl> nonzero ids?
07:24 < nickelpro> Sorry, in SpockBot's code that object data integer is called the object data id
07:24 < nickelpro> s/id/integer/g
07:26 < Fenhl> that's still really weird
07:26 < Fenhl> I guess that explains why it's changed in 1.9 :D
07:32 < nickelpro> Object data was a weird piece of the protocol that no one really ever needed and its documentation reflects that
10:34 < rom15043> The change was made to clarify what object data and velocity were supposed to go
10:35 < rom15043> Since object data is always an int followed by 3 position number if that int is not null
10:35 < rom15043> Only the interpretation of that int changes
10:37 < rom15043> No functional difference with the previous thing
10:38 < rom15043> Ah you reverted already
10:38 < rom15043> Well I don't really care either way, but javaprophet found it clearer that way
10:40 < rom15043> (And the vanilla code has no "object data" concept apparently)
10:45 < rom15043> (Here is yet an other way to present the spawn object packet http://prismarinejs.github.io/minecraft-data/?d=protocol#toClient_spawn_entity )
11:01 < Pobway> can anyone help with some recommendations where to get started with coding minecraft mods? my only coding experience is with triggers in star craft brood war map editor
11:01 < Pobway> lol
11:14 < Pobway> i am good with textures, ive made my own custom packs and stuff, so i am interested in making mobs which will spawn in certain biomes, and also maybe some special items
11:15 < Pobway> but mostly i would like to create mobs that will spawn under certain conditions. if this is possible, like for example 'chunk has 5 of block A, has a 50% chance to spawn 1 -new mob-' something like that
11:16 < Pobway> then i could work with existing mobs that i have set in my server, to make the server spawn for example 'giant bees' around bee hives regardless of biome
11:16 < rom1504> Pobway: try in #spigot maybe
11:17 < Pobway> if any1 has any recommendations in this direction itd be well appreciated
11:17 < rom1504> (people here are mostly working on custom clients/servers afaik)
12:28 < Not-5d64> [mineflayer] rom1504 pushed 2 commits to master [+0/-0/±2] http://git.io/vuoPQ
12:28 < Not-5d64> [mineflayer] deathcap a179683 - Update links in readme for repository move
12:28 < Not-5d64> [mineflayer] rom1504 84408bb - Merge pull request #352 from deathcap/patch-1 Update links in readme for repository move
12:29 < Not-5d64> [mineflayer] rom1504 pushed 1 commit to master [+0/-0/±1] http://git.io/vuoXC
12:29 < Not-5d64> [mineflayer] rom1504 4fecddd - update repository url in package.json
13:53 < Bruqaj> What packet does the client sent when he isn't moving?
13:54 < rom1504> the client send position packet 20 time per second
13:54 < rom1504> regardless of if he's moving or not
13:56 < Bruqaj> And the client has to decide using the map if he is OnGround?
13:59 < rom1504> yes
13:59 < Bruqaj> Thanks rom1504 :)
15:48 < barneygale> vanilla behaviour is "player" once per tick, "player position" once per 20 ticks iirc
19:50 < nickelpro> barneygale: Player sends a position update every tick at 20tps. Notchian uses the smallest packet possible, so if nothing has changed only the Player packet is sent. If only look has changed then a Player Look is sent, etc.
19:51 < Gjum> does notchian send more than one of these per tick in sone cases?
19:58 < barneygale> nickelpro, I tested in 1.8 and found the vanilla client sends Player Position every 20 ticks even if it hasn't moved
20:12 < nickelpro> barneygale: I stand corrected
20:16 < Meeeh> Gjum, should not, but you may recive "more" packets per tick due to server/network lag
20:17 < nickelpro> ^^^
20:17 < Gjum> ok
--- Log closed jeu. janv. 07 20:37:40 2016
--- Log opened jeu. janv. 07 20:43:52 2016
20:43 -!- Irssi: #mcdevs: Total of 140 nicks [1 ops, 0 halfops, 15 voices, 124 normal]
20:43 !holmes.freenode.net [freenode-info] channel flooding and no channel staff around to help? Please check with freenode support: http://freenode.net/faq.shtml#gettinghelp
20:47 -!- Irssi: Join to #mcdevs was synced in 242 secs
21:01 < OnlyQubes> Hello, maybe could somebody explain what the '| data' is? :? ( http://puu.sh/mnb7P/9085bac535.png )
21:02 < Gjum> OnlyQubes: a binary OR operator
21:03 < Gjum> as in "shift the id by 4 bits to the left and add/OR the data"
21:04 < OnlyQubes> Ahh so '|' means or ? :?
21:04 < Gjum> binary OR, not logic OR (which is || in most languages), but most of the time | does the same as +
21:05 <+Amaranth> https://en.wikipedia.org/wiki/Bitwise_operation#OR
21:06 < OnlyQubes> okay so now for the second part, what is 'data' in that part?
21:06 <+Amaranth> Uh, do you know what block data is?
21:07 <+Amaranth> The second half of 15:6
21:07 <+Amaranth> 15 is the id, 6 is the data
21:07 < Gjum> data,metadata,meta,blockdata - many names for the same thing
21:07 < OnlyQubes> Oh okay https://en.wikipedia.org/wiki/Bitwise_operation#OR this link is very understandable, thanks :P
21:08 <+Amaranth> That link also shows an example where it's not the same as adding :)
21:11 < OnlyQubes> wait im not quite sure if i understand how to differ XOR and OR
21:12 < OnlyQubes> is '|' both or for XOR there is something else? :?
21:12 < Gjum> 1 or 1 == 1, 1 xor 1 == 0
21:12 < OnlyQubes> yeah, but how would XOR and OR look in code? P:
21:12 < Gjum> xor sometimes is ^
21:12 < OnlyQubes> OR = '|' right? :?
21:13 < rom1504> Gjum: you're missing "damage value" in your name list
21:13 < Gjum> and the logical equivalent to XOR is != or <> or =/=
21:13 < OnlyQubes> okay, now i get it :D. thanks :P
21:13 < Gjum> rom1504: and variant
21:26  * XorBoole impales Gjum 
21:32 < Fenhl> this should probably be “damage” in the wiki since “data” could be pretty much anything
21:37 < rom1504> well yeah but really "pretty much anything" describes well what goes into metadata
21:38 < rom1504> unlike "damage" that sounds like it's some kind of combat property
21:45 < Gjum> Fenhl: for block items, the "damage" is really not damage, but rather the block's "variant"
21:46 < Gjum> damage is just related to tool usage
21:46 < Fenhl> the NBT calls it damage for all items, including blocks
21:51 < Gjum> I know. It's about deciding to name it to be compatible to notchian, or to be clear about its meaning.
21:54 < rom1504> http://wiki.vg/SMP_Map_Format calls it block data, so does the mcwiki (for example)
21:55 < rom1504> http://minecraft.gamepedia.com/Chunk_format
21:55 < rom1504> the chunk format has the actual "Data" string, coming straight from mojang
21:56 < Fenhl> data is just such a meaningless word in this context
21:56 < ecx86> .
22:00 < Gjum> for doors and gates etc., it stores rotation data, so it kinda makes sense
22:04 < rom1504> data correctly describe what it is
22:04 < rom1504> i.e. some additional data to define a block
22:05 < rom1504> it's nothing more precise than that
22:05 < rom1504> what it really is depends on blocks
22:37 < OnlyQubes> Heyy im having a hard time understanding bit shifting and stuff, can somebody explain how to get the first 4 bits of a byte? :? (language is c#)
22:38 < Gjum> either x >> 4 or x & 0xf, depending on what you man by "first"
22:41 < OnlyQubes> yup, you are right. Sorry for bothering you so much, but i'm having a hard time understanding this D:
22:43 < Gjum> does anyone know the exact player eye height? (the height from which the reaching distance starts)
22:44 < Gjum> measuring ingame by counting block pixels gives 1.625 or 1 + 10/16
23:09 < rom1504> OnlyQubes: if you're using this for skylight, Nibble4 in http://minecraft.gamepedia.com/Chunk_format#Block_format is what you want
23:09 < rom1504> byte Nibble4(byte[] arr, int index){ return index%2 == 0 ? arr[index/2]&0x0F : (arr[index/2]>>4)&0x0F; }
23:14 < OnlyQubes> rom1504: i was using this for the Multi Block Change packet (http://puu.sh/mnl83/b30b1dad80.png), but i will need this aswell, so thanks :P
23:18 < rom1504> ah yeah
23:18 <+ammar2> OnlyQubes: you're having trouble understanding bit shifting? think about it this way. In a byte, the two 4-bit pairs will be like this xxxxyyyy. To get the x part you can do number >> 4, which will cause it to become 0000xxxx
23:19 <+ammar2> and for the y part, like Gjum said you & it with 0xf, 0xf=00001111
23:19 < rom1504> yeah I found displaying the bit representation useful to understand what's happening
23:19 <+ammar2> so it drops the left part after you and it
23:19 <+ammar2> since anything anded with 0 is 0
23:20 < OnlyQubes> ohh i get it now, thank you :P
23:20 < OnlyQubes> thanks guys :P
23:28 < nickelpro> Gjum: 1.6m has always worked for me
23:32 < Gjum> nickelpro: that would suggest I am 0.4 block pixels off, which is a lot
23:34 < Gjum> forums say 1.62, which is inside my error tolerance, using that http://www.minecraftforum.net/forums/minecraft-discussion/discussion/114653-player-height-size
23:34 < nickelpro> Gjum: 1.625 - 1.6 = 0.025 does it not?
23:34 < javaprophet> 1.62 is the eyeheight. 1.8 is the total height of a player.
23:34 < javaprophet> You can verify this in vanilla's models, or just by flying up until you hit your head, you are at (anything).2, suggesting 1.8 tall.
23:35 < javaprophet> Raytraces and the player crosshair is from 1.62 height.
23:35 < Gjum> nickelpro: 1 block = 1m = 1/16 pixels
23:35 < Gjum> javaprophet: thanks for verifying. I was after the eye height, not player height.
23:49 < OnlyQubes> Can the Varint of bits of data per block (http://puu.sh/mnnCp/68abc0a245.png) block be 0. (http://wiki.vg/SMP_Map_Format#Data)
23:50 < rom1504> well yes ?
23:50 < rom1504> air is 0
23:50 < rom1504> block light = 0 means no light
23:51 < rom1504> and biome = 0 is ocean
23:51 < rom1504> so they all can be 0
23:51 < OnlyQubes> but it says 4 - is for light array, 8 - for both array. Then what would 0 mean, or am i reading this wrong? :D
23:52 < javaprophet> It will always have block light data I believe, so 4 or 8 for light.
23:53 < OnlyQubes> i think im too stupid for this D:
23:53 < rom1504> I don't understand what they mean by "both array"
23:53 < OnlyQubes> i was thinking about the 2 arrays after (http://puu.sh/mnnV3/3d9a175024.png)
23:54 < rom1504> hmm idk
23:55 < rom1504> anyway it's 2 array of 4bit element
23:55 < OnlyQubes> Its just weird that im getting a 0 in the "	8 for both arrays, 4 for just block light, 16 for all with biome" part. I think i might be reading the bytes wrong again
23:58 < rom1504> I don't understand what you mean by the [...] part
23:58 < rom1504> there's no such part