22:27 <+SirCmpwn> it's hooked up to the same event as the dismiss button :P
22:27 < dx> lol
22:27 < TkTech> Well, this Wesley Wolfe guy will never work an office development job again.
22:27 <+SirCmpwn> https://github.com/KnightOS/z80e
22:28 < Jckf> Z80 <3
22:30 < dx> SirCmpwn: considered implementing a gdb server?
22:30 <+SirCmpwn> not really
22:31 <+SirCmpwn> the readline debugger is pretty good
22:31 <+SirCmpwn> we take pull requests
22:31 < dx> heh
22:31 < dx> SirCmpwn: btw, are you the one who started the project or just someone who is heavily involved with it?
22:32 <+SirCmpwn> z80e or KnightOS?
22:32 <+SirCmpwn> I started KnightOS and wrote probably like 95% of the code and worked on it solo for 3 years before more contributors started falling in
22:32 <+SirCmpwn> and the z80e subproject specifically, I wrote the z80 emulation and then most of the rest is other people
22:33 < dx> neat
22:47 < belak> SirCmpwn: how easy/hard is it to brick a calculator installing KnightOS?
22:48 <+SirCmpwn> impossible
22:48 <+SirCmpwn> you can only brick a calculator if you're trying to
22:49 < belak> I'm used to dealing with OpenWRT where they give a warning what seems like every other page
22:53 < dx> jesus christ these calculators are absurdly expensive here
22:57 < Not-f47f> [Glowstone] SpaceManiac pushed 3 commits [+0/-0/±9] http://git.io/cva9QA
22:57 < Not-f47f> [Glowstone] JeromSar b66684a - Added various command-line options.
22:57 < Not-f47f> [Glowstone] SpaceManiac ac22b74 - Fixed gradle manifest reference. Thanks @Grinch, @scooterboo, @lukespragg.
22:57 < Not-f47f> [Glowstone] SpaceManiac 28a179e - Changed wgen to treat 128 as world height in all cases (fixes #151).
22:58 < belak> What is Not-f47f?
22:59 < belak> Like, what service is being used for it?
22:59 <+SpaceManiac> Notifico, n.tkte.ch
23:30 < Not-f47f> [fNbt] fragmer pushed 2 commits to master [+0/-0/±14] http://git.io/mUeYHQ
23:30 < Not-f47f> [fNbt] fragmer 1c93d50 - Linked NbtConvert to DynamicConverter.
23:30 < Not-f47f> [fNbt] fragmer b876fef - NbtTag now implements ICloneable and provides copy constructors. In both cases, deep copies are made. Closes #10
--- Day changed ven. sept. 05 2014
00:52 < Drainedsoul> dx: Sure, it has a perfectly good Unicode code point, but those are mostly supplied -- afaik -- for legacy reasons.  Combining marks are a more general sol'n.
00:52 < Drainedsoul> dx
00:52 < Drainedsoul> NFD also has redeeming qualities.  It's less intensive to place a string in NFD than NFC, so if you want to compare two unnormalized strings, putting them in NFD will result in a faster comparison
00:52 < Drainedsoul> in fact, NFD isn't just arguably faster, it must be faster, since placing a string in NFD is part of transforming it to NFC
02:21 < vemacs> If a mob is attached to another
02:21 < vemacs> does the position of the passenger mob need to be updated?
02:32 < Not-f47f> [fNbt] fragmer pushed 1 commit to master [+0/-0/±1] http://git.io/Ca7zFg
02:32 < Not-f47f> [fNbt] fragmer ed11aaa - Purged the last remnants of SirCmpwn's serializer code. Those bits are being rewritten.
02:32 <+SirCmpwn> ;_;
02:33 < cindy_k> heh
02:33 <+SirCmpwn> I didn't even know that he had my serializer code in there
02:53 <+fragmer> You handed it to me like 2 years ago :P
03:36 < fysac> Hi SirCmpwn. I've seen you on OSDev
03:36 <+SirCmpwn> hello fysac
03:36 <+SirCmpwn> this is a weird place to mention it
03:37 < fysac> Why?
03:37 <+SirCmpwn> the sign on the door says mcdevs, it's a channel about minecraft
03:37 <+SirCmpwn> and I happen to be in #osdev, the official channel of osdev.org
03:38 < fysac> I see. I don't frequent #osdev, and since you were discussing KnightOS earlier, I figured you were fine talking about OS stuff here.
03:38 <+SirCmpwn> I am fine with it, just making an observation
03:39 <+SirCmpwn> I didn't realize you had been here, so far as I could tell it looked like you joined just now for the sole purpose of finding me and telling me you saw me on osdev
03:39 < fysac> Ah, no
03:43 <+SirCmpwn> that was productive
03:43  * SirCmpwn goes back to fixing emulation bugs
03:44 < woder> is there any case where the actual uncompressed length isn't what data length said? (I feel like there is a network issue, just want to confirm)
03:47 <+SpaceManiac> uhhh, I would consider that a protocol error
03:50 <+SirCmpwn> woder: it's very likely a problem with your protocol implementation
03:50 < woder> yeah, thats what I thought - whats weird is that everything works then it just stops
03:57 < Drainedsoul> woder: What do you mean "network issue"?
04:02 < woder> Drainedsoul: I mean that there would be a byte left over from the last packet or something (how ever thats the issue, since my parsing code works for all the packets before, I don't know why it would just stop there)
06:56 < Fenhl> so I just sent this http://senf.fenhl.net/fs/qp6AkEudLr.png to the author of http://dev.bukkit.org/bukkit-plugins/replay/
06:56 < Fenhl> this is going to be fun ^^;
08:13 < Not-f47f> [Glowstone] SpaceManiac pushed 2 commits [+0/-0/±2] http://git.io/YtiQYQ
08:13 < Not-f47f> [Glowstone] SpaceManiac 82f6b33 - Corrected when fallback commands are registered.
08:13 < Not-f47f> [Glowstone] SpaceManiac 0b483f2 - Added generateExtBlockSections support and handled generator errors better.
08:24 < Fenhl> > In this document, the axis names are the same as those used by Notch. Y points upwards, X points South, and Z points West. http://wiki.vg/Protocol#Other_definitions
08:25 < Fenhl> is that article still using old solar North?
08:25 < Fenhl> or is the coordinate system seriously turned 90 degrees from that displayed in F3
12:50 < Not-f47f> [node-minecraft-protocol] roblabla pushed 1 commit to master [+0/-0/±2] http://git.io/K0b8FQ
12:50 < Not-f47f> [node-minecraft-protocol] roblabla e76d274 - Patch UUID processing (Fixes #92)
13:17 < roblabla> So like, sinec 1.8, the protocol is compressed in addition to being encrypted ?
13:18 < cindy_k> I think its compressed when it reaches a certain size
13:18 < cindy_k> if I remember what Thinkofdeath said correctly
13:19 < roblabla> Yeah, it is, but will the server scream at me if I don't follow the threshold it sends me ?
13:19 < cindy_k> http://wiki.vg/Protocol#Post_compression
13:19 < cindy_k> I think this may decide that
13:20 < roblabla> But the threshold is clientbound
13:20 < roblabla> so client can't de-activate compression I guess
13:20 < roblabla> *sight*
13:20 < roblabla> I'll do some testing
13:21 < roblabla> Wait, is the compression method documented anywhere ?
13:23 < roblabla> AAAAAND my guess is it ain't.
13:25 < roblabla> I'm going to take a wild guess and say gzip. Time to decompile minecraft_server.jar
13:26 < woder> yeah its gzip
13:28 < roblabla> kk
13:46 < roblabla> So, stupid question, but I guess I already have my answer....
13:46 < roblabla> PacketID is compressed as well, right ?
13:47 < roblabla> Like, they didn't have the smart idea to leave it out of compression for those of us who only want chat data and want to ignore everything else...
13:50 < woder> roblabla: I don't actually think the chat packet will be compressed, its only when its too big it gets compressed
13:51 < roblabla> I still need to uncompress to figure out what packet type it is
13:51 < Thinkofdeath> Its deflate not gzip
13:51 < roblabla> And it can be compressed if the threshold is of, say, 1 byte or whatever. I doubt any server would do that, but you get the point.
13:51 < roblabla> Thinkofdeath: kk, thx
13:52 < roblabla> Thinkofdeath: do you know the default "threshold" value for vanilla servers ?
13:53 < Thinkofdeath> 256
13:53 < roblabla> thx
15:28 < justin97530> robabla: Your hotfix still isn't working and I'm getting the same error D:
15:29 < justin97530> Can anyone help me with NodeJS packets?
17:26 < roblabla> justin97530:hey I'm here
17:26 < roblabla> Sorry, had to be gone for a while ^^
17:26 < roblabla> I just tested everything on my end, and it works with 1.7.10 client
17:28 < roblabla> Oh.
17:28 < roblabla> justin97530:are you perhaps using node-minecraft-protocol from NPM ?
17:28 < roblabla> God, I don't even know what the latest release of that is
17:42 < roblabla> urg
18:23 < M4GNV5> is vubui here?
18:35 < dx> why would the """Chief Operating Officer""" be here
19:21 < Bibl> Oh my 
19:21 < Bibl> I just had an idea for a tool
19:21 < Bibl> Not sure why I didn't do this before
19:21 < Bibl> But have a program that can hotswap classes and load other programs
19:22 < Bibl> other java programs*
19:35 < Not-f47f> [Glowstone] SpaceManiac pushed 1 commit [+0/-0/±2] http://git.io/ZibFZA
19:35 < Not-f47f> [Glowstone] SpaceManiac 477ea51 - Revamped bulk sending to split chunks by how big they are.
--- Day changed sam. sept. 06 2014
00:45 < vemacs> attach
00:46 < vemacs> <vemacs> If a mob is attached to another
00:46 < vemacs> <vemacs> does the position of the passenger mob need to be updated?
01:18 < barneygale> anyone want to speculate as to what mojang's next move might be?
01:20 < dexter0> Minecraft 1.9 - The Mod API Is Here!
01:21 < Bibl> heard that one before
01:38 < barneygale> 2014 year of the minecraft desktop
01:50 <+SirCmpwn> today's entertainment has arrived in #craft.net if anyone is bored
05:29 < Not-f47f> [Glowstone] SpaceManiac pushed 2 commits [+0/-0/±5] http://git.io/Vc05HQ
05:29 < Not-f47f> [Glowstone] SpaceManiac 04626f6 - Fixed InteractEntityMessage decoding (fixes #163).
05:29 < Not-f47f> [Glowstone] SpaceManiac d8f6c6a - Fixed decoding of client brand, some PluginMessage tidying (fixes #161).
05:44 < ackpacket> I wrote a client for collecting gear at a farm, but it had three problems:  Noone could hit them, it wouldn't pick up items, and it didn't trigger spawners for some reason
05:45 < ackpacket> updating it's position every 50ms helped the item/punching issue... but spawners are still not activated by it.  What else should I be sending?
05:46 < expir3dcow> Hello, I had a look at Minecraft's handshake. 1.7 uses 0x00, does anyone know how to send packets in java?
05:59 < ackpacket> expir3dcow: you have to set up a TCP connection to the server
05:59 < ackpacket> expir3dcow: and then push data over that connection
06:00 < ackpacket> expir3dcow: there is a lot more work to logging in than that.  You have to manage encryption, authenticate to the mojang servers (twice), etc etc
06:00 < expir3dcow> ackpacket I want to test it on an offline local server for a start
06:01 < expir3dcow> so no username authentication worries for now
06:01 < Not-f47f> [Glowstone] SpaceManiac pushed 1 commit [+0/-0/±1] http://git.io/JdToMQ
06:01 < Not-f47f> [Glowstone] SpaceManiac 7919845 - Fixed sneaking and sprinting handling in PlayerActionHandler (fixes #165).
06:02 < ackpacket> expir3dcow: then you shouldn't have too much trouble.  Like I said, start a tcp connection, and connect to the server
06:02 < ackpacket> expir3dcow: you can use sockets if you like
06:02 < ackpacket> i don't know what java has
06:02 < expir3dcow> I know how to connect to a server using sockets 
06:03 < expir3dcow> How do I send packs?
06:03 < ackpacket> do you know how to connect to a server at all?
06:03 < expir3dcow> *packets
06:03 < expir3dcow> Socket socket = new socket("ip",port)
06:03 < ackpacket> sure?
06:03 < ackpacket> i'm no java expert
06:03 <+SpaceManiac> the wiki.vg/Protocol page is pretty descriptive
06:04 < ackpacket> SpaceManiac, got a sec?
06:04 < ackpacket> i'm scratching my head her
06:04 < ackpacket> *here
06:04 < expir3dcow> SpaceManiac I've read it. but don't know how to do it in java
06:04 < ackpacket> expir3dcow, you need to look up a networking tutorial first
06:04 < expir3dcow> I have
06:04 < ackpacket> it seems you have problems nonspecific to minecraft
06:04 < expir3dcow> Ok
06:04 <+SpaceManiac> write functions to convert packet structures to a series of bytes
06:04 < ackpacket> well packets are just bytes.  Let's say you want to send a respawn packet
06:05 < ackpacket> you would take this:  0x02F100
06:05 < ackpacket> and push it over the wire
06:05 < expir3dcow> what's the 0x00 for handshake then?
06:05 < expir3dcow> oh right
06:05 < ackpacket> actually it's F0
06:05 < ackpacket> er..
06:05 < expir3dcow> do I need to write any packets?
06:05 < ackpacket> 16 for respawn
06:05 < ackpacket> packets are just bytes...
06:05 < ackpacket> but yes
06:05 < expir3dcow> oh
06:05 <+SpaceManiac> what do you mean by "write any packets?" - of course you need to write something to the pipe
06:05 <+SpaceManiac> ackpacket: not surprised sending position updates helps, vanilla bases a weird amount of behavior on the player reminding it that they exist. don't know about the mob spawner thing
06:05 < expir3dcow> sigh
06:06 < ackpacket> expir3dcow: like I said, you have to learn about networking.  I can tell you're a far ways away from making a working client
06:06 <+SpaceManiac> Netty is pretty useful for these kinds of things.
06:06 < expir3dcow> What am I lacking of?
06:07 < ackpacket> experience?  I don't know
06:07 < expir3dcow> I've done a bit of server stuff
06:07 < Fenhl> btw, can anyone answer my question from yesterday?
06:07 < ackpacket> ok then, a packet is just a collection of bytes
06:07 < Fenhl> > In this document, the axis names are the same as those used by Notch. Y points upwards, X points South, and Z points West. http://wiki.vg/Protocol#Other_definitions
06:07 < ackpacket> so let's take for example your login packet
06:07 <+SpaceManiac> expir3dcow: you have some data you want to convey - e.g. handshake with these fields, and you need to condense it down to a series of bytes
06:07 < ackpacket> ok?
06:07 < ackpacket> what's the ID/fields on a login packet?
06:07 < Fenhl> is this accurate? or does it use the old solar North?
06:07 < expir3dcow> ackpacket: I'm a new programmer but have done a bit of java
06:08 < ackpacket> expir3dcow: yes I can tell you are new.  So let's start with yout login packet
06:08 <+SpaceManiac> Fenhl: I think that description is just outdated. Trust what the client F3 menu says with regards to what direction is which
06:08 < ackpacket> login has an Id of 0x00
06:08 < Fenhl> okay, I'll update it
06:08 < ackpacket> then it wants the servername, right?
06:08 < ackpacket> then your name?
06:08 < expir3dcow> yeah
06:08 < ackpacket> ok
06:08 < ackpacket> so let me show you what each field looks like
06:08 < dx> SpaceManiac: you might want to join #nextstep in esper
06:08 < ackpacket> packet Id will be 0x00
06:09 < ackpacket> understand that?
06:09 < expir3dcow> yeah
06:09 < dx> SpaceManiac: glowstone is in the topic as a potential option
06:09 < ackpacket> servername will be localhost
06:09 < ackpacket> so it will look like this
06:10 < ackpacket> 0x6c0x6f0x630x610x6c0x680x6f0x730x74
06:10 <+SpaceManiac> that's a pretty unhelpful way to describe bytes :P
06:10 < Fenhl> what the
06:10 < ackpacket> ok like this 0x6c 0x6f 0x63 0x61 0x6c 0x68 0x6f 0x73 0x74
06:10 < expir3dcow> better :)
06:10 < ackpacket> do you understand that much?
06:10 < ackpacket> that says "localhost"
06:10 < expir3dcow> yeah I do
06:11 < ackpacket> now, in minecraft, the String datatype is prepended with a length
06:11 < ackpacket> localhost has 9 bytes
06:11 < ackpacket> so the "server" field, will look like this: 0x09 0x6c 0x6f 0x63 0x61 0x6c 0x68 0x6f 0x73 0x74
06:11 < ackpacket> see the 0x09 I added?
06:11 < expir3dcow> yeah
06:11 < ackpacket> ok, now repeat the process for your name, which is....?
06:11 < jython234[2]> Harro
06:11 < expir3dcow> usaydee
06:12 < expir3dcow> that's my username
06:12 < Fenhl> wait. isn't the length a varint?
06:12 < ackpacket> yes
06:12 < jython234[2]> Yes
06:12 < ackpacket> but a varint less than 127 will be a single byte
06:12 < ackpacket> 127 or 128, i forget.  something around there
06:12 < jython234[2]> Varint is confusing
06:12 < Fenhl> okay, I should read up on how varints work
06:12 < jython234[2]> I think it's 127
06:13 < ackpacket> ok expired, so the username field looks like this: 0x7 0x75 0x73 0x61 0x79 0x64 0x65 0x65
06:13 < ackpacket> with me so far?
06:13 < expir3dcow> yeah
06:13 < ackpacket> ok so let's construct all of the data that goes into the packet
06:13 < expir3dcow> ok
06:13 < ackpacket> id + servername + username
06:14 < expir3dcow> ok
06:14 < ackpacket> 0x00 0x09 0x6c 0x6f 0x63 0x61 0x6c 0x68 0x6f 0x73 0x74 0x7 0x75 0x73 0x61 0x79 0x64 0x65 0x65
06:14 < ackpacket> ok?
06:14 < expir3dcow> ok
06:14 < ackpacket> now, you have to prepend the packet with it's length, encoded as a varint
06:14 < expir3dcow> prepend?
06:14 < ackpacket> yes
06:14 < PEMapModder_> Add before
06:14 < expir3dcow> oh
06:14 < PEMapModder_> Opposite of append
06:14 < expir3dcow> ty
06:15 < ackpacket> 0x13 0x00 0x09 0x6c 0x6f 0x63 0x61 0x6c 0x68 0x6f 0x73 0x74 0x7 0x75 0x73 0x61 0x79 0x64 0x65 0x65
06:15 < ackpacket> tha's your fully constructed login packet
06:15 < ackpacket> I could've sworn it wanted a port too...
06:15 < ackpacket> but you get the picture right?
06:15 < expir3dcow> yeah
06:15 < jython234[2]> expir3dcow: did you implement ping yet?
06:15 < ackpacket> no
06:15 < expir3dcow> how did you convert the username to hex?
06:15 < jython234[2]> Google
06:16 < Fenhl> UTF-8
06:16 < ackpacket> python
06:16 < expir3dcow> oh
06:16 < jython234[2]> All work
06:16 < ackpacket> yes but encode it using utf, not ascii, that's very important
06:16 < Fenhl> and not UTF-16 either
06:16 < ackpacket> SpaceManiac: Well, aside from constant position updates... what could the server be wanting from me?
06:16 <+SpaceManiac> in Java, you can get the byte[] for a string with .getBytes(StandardCharsets.UTF_8)
06:16 < jython234[2]> UTf 8
06:17 < expir3dcow> SpaceManiac ty
06:17 < PEMapModder_> If it is only alphanumeric, it is same
06:17 < ackpacket> which minecraft is not
06:17 < PEMapModder_> Not?
06:17 <+SpaceManiac> ackpacket: no idea. maybe try sending the "do nothing" packet? (it's right before position updates in the list)
06:17 < ackpacket> utf8 is all over the chat
06:18 < PEMapModder_> Oh. I thought you're talking about username
06:18 < ackpacket> i'm talking about the String datatype in the minecraft protocol
06:19 < ackpacket> SpaceManiac: hmm.... maybe i'm missing an essential packet for the login process, because it's as though my Respawn is also being ignored when my character dies.
06:19 < ackpacket> SpaceManiac: what packets have you found to be *absolutely* essential for a login?
06:19 < ackpacket> i'm not sending the client settings one
06:19 < Fenhl> not even usernames are alphanumeric
06:19 < Fenhl> but they're ASCII-compatible
06:20 < ackpacket> ^
06:20 < Fenhl> [A-Za-z0-9_]{1,16} in PCRE
06:20 <+SpaceManiac> usually I see client settings and MC|Brand but those are pretty minor I'd assume
06:20 <+SpaceManiac> maybe try sending them just in case
06:20 < ackpacket> ugh
06:20 < ackpacket> such a bother
06:20 < ackpacket> i'll start with the do nothing packet
06:21 < PEMapModder_> OK, alphanumeric + underscore
06:21 < PEMapModder_> Same
06:22 < ackpacket> SpaceManiac: is this do-nothing packet in 1.7?
06:22 < ackpacket> for now ;)
06:22 <+SpaceManiac> yes, it's play serverbound 0x03
06:27 < ackpacket> whoa
06:27 < ackpacket> that's weird
06:27 < ackpacket> I accidentally typed an incomplete packet and the server never choked on it
06:28 < ackpacket> scary
06:28 < jython234[2]> Lol
06:29 < ackpacket> lol
06:29 < ackpacket> you will not believe this
06:29 < ackpacket> I can tell you why the spawners aren't working
06:29 < ackpacket> *and why respawn wasn't working
06:30 < ackpacket> I msg'd the bot:  send \x02\x16\x00
06:30 < ackpacket> to get it to respawn
06:30 < ackpacket> and watched where it died
06:30 < ackpacket> should'be been watching spawn XD
06:30 < jython234[2]> Hey do you need to put the length of a packet before sending?
06:30 < ackpacket> yes
06:30 <+SpaceManiac> Yes (as a varint)
06:30 < jython234[2]> Ok thanks!
06:31 < ackpacket> space did you hear that XD
06:31 <+SpaceManiac> oh, silly :P
06:31 < ackpacket> well... that fixes the respawn
06:31 < ackpacket> we shall see about the spawners
06:32 < ackpacket> still no spawners
06:32 < ackpacket> fak
06:32 < ackpacket> i'm sending the do nothing packet along with every position update
06:34 < ackpacket> SpaceManiac: you don't think 0x13 has any use do you?  player abilities?
06:35 <+SpaceManiac> the client uses it to indicate when it is flying or not
06:35 <+SpaceManiac> any other information it contains is discarded by the server
06:35 < ackpacket> oooooh
06:35 < ackpacket> i just realized something
06:35 < ackpacket> if I never send the client's render distance, how does the server know what chunks to load
06:35 < ackpacket> that sounds reasonable
06:36 <+SpaceManiac> Oh, quite possible.
06:36 < ackpacket> if the client settings packet fixes the spawner issue...
06:36 <+SpaceManiac> speaking of, anyone know how a client's skinFlags are communicated to other clients?
06:37 < ackpacket> skinflags...
06:37 < ackpacket> what ver?
06:37 <+SpaceManiac> it's in Client Settings, supersedes show cape boolean
06:37 <+SpaceManiac> (1.8)
06:37 < ackpacket> ah.  Sorry I haven't bothered with 1.8 yet
06:38 < ackpacket> I suppose they're still hashing it out
06:38 <+SpaceManiac> I imagine it's the same mechanism as whether cape was enabled or not used to be conveyed, but I haven't figured it out yet
06:40 < ackpacket> I have a few ideas on how to find sometime
06:40 < ackpacket> what's an acceptable value for difficulty setting?
06:40 < ackpacket> I know it's probably disregarded but still
06:40 <+SpaceManiac> 0-3 or something like that
06:41 <+SpaceManiac> it's removed in 1.8
06:41 < ackpacket> i'm still in 1.7
06:42 <+SpaceManiac> mmhm
07:03 < Fenhl> 0 = peaceful, 3 = hard, no?
07:04 < ackpacket> Space...
07:04 < ackpacket> here's an interesting tidbit
07:05 < ackpacket> SpaceManiac: The spawners WERE working... they just don't light up -.-
07:05 <+SpaceManiac> hah
07:06 < ackpacket> Idk if that's the default behavior
07:06 < ackpacket> or if that's just the way the server is treating my client
07:06 < ackpacket> Maybe notchian clients can only see the spawners THEY light up
07:23 < ackpacket> SpaceManiac: If you give me a dump of a session with a server on 1.8, I might be able to help you with those skin flags
08:54 < cnlohr> *poke* is anyone around?  I'm here updating my server and ran into something that's sure to be a simple problem.
08:54 <+SpaceManiac> heya
08:54 < cnlohr> I am sending 0x23's all over the place
08:55 < cnlohr> It's odd, because I can see the outline of what I'd be clicking on change, but the block remains completely unchanged.
08:55 <+SpaceManiac> what do you mean by you can see the outline change?
08:55 < cnlohr> also, I'm bummed about the not-allowed-to-send-compressed-chunks anymore, since my AVR won't support compression.
08:58 < cnlohr> http://imgur.com/a/txDO2
08:58 < cnlohr> the gray box
08:58 < cnlohr> I am changing the meta (I've tried changing block IDs, too)
08:58 < cnlohr> but it just will not update on my display.
08:59 <+SpaceManiac> hmm, weird.
08:59 <+SpaceManiac> what value are you sending as the block type?
08:59 < cnlohr> 69 (a switch)
08:59 < cnlohr> And I set the meta starting at 0, sequentially going up.
08:59 <+SpaceManiac> the whole thing - including data
08:59 <+SpaceManiac> the encoded number
08:59 < cnlohr> The block automatically assume whatever the very first block they were set to.
09:00 < cnlohr> OH!
09:00 < cnlohr> The encoded number is: (let me dump)
09:00 < cnlohr> 	Svarint( (bt<<4) | meta ); //block type
09:01 <+SpaceManiac> mmhm, that looks right
09:02 < cnlohr> And, it is updating the outline of the thing I am changing
09:02 <+SpaceManiac> so you're sending something in the 1104..1119 range
09:02 < cnlohr> yep
09:02 <+SpaceManiac> sure it's encoding right?
09:03 < cnlohr> encoding the varint?
09:03 < cnlohr> also, it is displaying, it is the same code displaying in the end as in the beginning.
09:03 < cnlohr> It's just Minecraft isn't updating the display.
09:04 <+SpaceManiac> yeah, I'm just trying to determine if it could be something weird with the value you send
09:05 <+SpaceManiac> I'm not experiencing it myself
09:06 < cnlohr> hmm... It is really difficult for me to send the initial chunks properly... I wonder if specifying a bitmask and not following up is hurting it.
09:06 <+SpaceManiac> hm, it's possible
09:07 < cnlohr> Do you know if everyone else is actually sending full proper data with their 0x21's?
09:07 <+SpaceManiac> I certainly am
09:08 < cnlohr> hmm... I'll give this a wack on my x86 version
09:08 < cnlohr> if that's what's doing this, it could spell doom 
09:10 < cnlohr> those are some MASSIVE packets
09:10 < cnlohr> :( I can't even send them with the rest of my infrastructure
09:10 <+SpaceManiac> baw
09:10 <+SpaceManiac> maybe you could mask things to send only a very tiny amount of data
09:11 < cnlohr> isn't the mask one bit for each 16x16x16 chunk?
09:11 <+SpaceManiac> yeah... I take it even one of those is too big?
09:12 < cnlohr> yeah, looks like I can't send more than 128 bytes in any one message
09:12 < cnlohr> ooh weird... if  I break a block, it does do the update
09:12 <+SpaceManiac> phew, that's small
09:13 <+SpaceManiac> maybe sending a 100% empty chunk is somehow signalling to the client not to do updates - even if you set blocks
09:13 < cnlohr> and it updates all nearby blocks
09:13 < cnlohr> I know if I set the bitmask to all 0's it unloads the chunk and everything breaks
09:13 < cnlohr> werid, I wonder if there's any way of making the client think they broke a block
09:14 < cnlohr> in fact, breaking any block in the entire chunk causes the entire chunk to update.
09:15 < cnlohr> Are there any messages I can send the client that may kickstart that?
09:15 <+SpaceManiac> hmm, maybe experiment with setting things to air or maybe the block break animation packet
09:15 <+SpaceManiac> can't say for sure, though
09:16 < cnlohr> I'll give it a shot.
09:17 < cnlohr> gah, if I start out with air and put something there, air still shows
09:22 < cnlohr> If I try sending another empty bulk update, it just blanks everything :(
09:29 < Not-f47f> [Glowstone] SpaceManiac pushed 1 commit [+0/-0/±1] http://git.io/LxCONg
09:29 < Not-f47f> [Glowstone] SpaceManiac 346fae6 - Tidied error messages on unclean disconnects (fixed #110).
09:29 < cnlohr> nothing with multi-block change.  Not good.  Not good at all.
09:34 < cnlohr> Hmm, do you know if you can turn compression on and off?
09:34 < cnlohr> I.e. Could I just store the compressed "make this thing happy" packet in flash and just mindlessly give it to the client, it automatically switches back?
09:35 <+SpaceManiac> probably.
09:35 <+SpaceManiac> could sequence "enable compression; compressed chunk packet; disable compression"
09:38 < cnlohr> :( that would be a lot of work
09:38 < cnlohr> but I guess if it gets it to work, it'd be worth it
09:43 < cnlohr> uh oh... if I do that, then the client can send me compressed packets
09:44 <+SpaceManiac> not if you disable compression again pretty quick, and/or not if you set the threshold right
09:44 < cnlohr> hmm
09:44 < cnlohr> so the idea would be:
09:45 <+md_5> you cannot toggle compression during gameplay
09:45 < cnlohr> 0x46 -> varint( something relatively large)
09:45 < cnlohr> (compression header)
09:45 < cnlohr> COMPRESSED: 0x26 -> proper data)
09:45 < cnlohr> (compression header)
09:45 < cnlohr> 0x46 -> -1
09:45 <+md_5> it race conditions and you die
09:45 < cnlohr> ARE YOU SERIOUS?
09:45 <+SpaceManiac> how hard does it race condition?
09:45 <+SpaceManiac> I've experimented and it's mostly okay except in certain cases
09:45 <+md_5> unless they fixed it, a hell of a lot
09:46 < cnlohr> Well, I only need to do it once, on login.
09:46 < cnlohr> And, I am only loading one chunk
09:46 <+SpaceManiac> actually, yeah, I get what you mean
09:46 <+SpaceManiac> it's not a sustainable sane solution but it might get this job done
09:47 < cnlohr> so I should go for this, or should I keep trying to find a way of glitching the client into updating?
09:48 <+SpaceManiac> I say go for it
09:49 <+SpaceManiac> if you set the threshold right, the client won't be sending any messages high enough, and then you can discard messages where the packet id appears to be 0 (because they were sent when it thought compression was on)
09:49 < cnlohr> I'll just set it to 0xffff
09:49 < cnlohr> Not like I can receive anything from the client over 192 bytes anyway
09:54 < cnlohr> I'll mess with this in the morning.  Thanks for your help, everyone.  I hope this compression thing gets me fixed up.
09:54 <+SpaceManiac> good luck
09:54 < cnlohr> wait quick question
09:54 < cnlohr> when I send compressed packets
09:54 < cnlohr> normally I'd send
09:55 < cnlohr> varint( size of my packet )
09:55 < cnlohr> [packet data]
09:55 < cnlohr> (on wire)
09:55 <+SpaceManiac> mmhm
09:55 < cnlohr> do I now send, on wire:
09:55 < cnlohr> varint( size on wire of packet)
09:55 < cnlohr> varint( size of uncompressed data )
09:55 < cnlohr> (data)
09:56 < cnlohr> size of packet on wire = sizeof(data) + sizeof( varint saying how big the uncompressed data is)
09:56 <+SpaceManiac> yep, that's correct
09:56 < cnlohr> THEEEN inside data, I don't put on a varint header?
09:56 <+SpaceManiac> inside data, varint packet type. but no other header
09:56 < cnlohr> varint packet type???
09:56 < cnlohr> it's not a byte?
09:57 <+SpaceManiac> there aren't any defined packets that aren't in the subset of varints that look like bytes
09:57 <+SpaceManiac> but yes it's varint
09:57 < cnlohr> lol turns out there are no commands over 0x7f
09:57 < cnlohr> ugh... I guess I'll just leave my server the way it is for now
09:58 < cnlohr> Actually, another thought: I can send "turn compression on", send the compressed packet + the compressed packet saying turn compression off, all in the same TCP packet probably.
09:58 <+SpaceManiac> oh, good chance of it.
09:59 < cnlohr> Hmm there is one bummer.  Originally, I supported maps of up to 256x256... with this, there's no way that's coming back :(
10:01 < cnlohr> well, thanks for your help.  If you don't see me again, you'll know it was because you sent me on my way well.  I'll be sure to give you guys another callout in the next vid.
10:02 < cnlohr> (or try to remember)
10:02 <+SpaceManiac> heh, alrighty
18:21 < amlweems> hey, does anyone know if Plugin Message is used by the client / server?
18:21 < amlweems> it's listed in the protocol, but the reference post is two years old
18:27 < Jckf> amlweems: As far as I know, they are not used by vanilla at all
18:28 < Thinkofdeath> It is used
18:29 < Thinkofdeath> MCBrand, Anvils, Villager trades etc
18:29 < amlweems> hm...
18:29 < amlweems> the protocol spec doesn't specify a length on the array
18:30 < amlweems> how do you know the length of the byte array in Plugin Message?
18:30 < Thinkofdeath> its the remainder of the packet
18:30 < amlweems> ah, alright
18:31 < amlweems> it's a little annoying that some packets give array length and some don't
18:31 < amlweems> but, fair enough
18:32 < amlweems> saves a whole varint as well :D
18:33 < Jckf> Thinkofdeath: TIL :)
18:34 < Dhruv0> What were the breaking protocol changes for 1.8?
18:34 < amlweems> compression and some changes to packet format
18:35 < Dhruv0> I'm guessing they effected the maps massively?
18:35 < amlweems> not sure what you mean by that
18:36 < Dhruv0> SendMap and Block changes effected?
18:37 < amlweems> compression was removed from chunk data
18:37 < amlweems> but added to the packet overall (if size > threshold: compress)
18:37 < amlweems> that probably breaks things trying to parse chunk data
18:38 < Jckf> So chunks are no longer compressed?
18:39 < Jckf> Why would they do that? There are massive BW savings to be made on that
18:39 < amlweems> they compress the whole packet now
18:39 < amlweems> if the packet is larger than a threshold (determined by serveR)
18:39 < amlweems> it must be compressed
18:40 < Jckf> Ah, right
18:43 < Dhruv0> Isn't that harsh..
18:45 < cnlohr> hey anyone around?  Not sure how to encode a -1 in a varint.
18:46 < morfin> is not Minecraft using unsigned varints only?
18:46 < amlweems> I'd also like to know this
18:46 < amlweems> I assumed they were signed
18:46 < amlweems> but unsigned would make things easier
18:46 < cnlohr> No.
18:47 < cnlohr> "Compression can be disabled by sending a threshold of -1. "
18:47 < amlweems> ah
18:47 < amlweems> I think the varint type is based on protobufs
18:47 < amlweems> in which case: https://developers.google.com/protocol-buffers/docs/encoding#types
18:47 < amlweems> describes zigzag encoding of signed ints
18:47 < morfin> that's regular varint so you can check protobufs source to see how they encode that
18:47 < cnlohr> Already read it twice, doesn't make a lick of sense.
18:47 < amlweems> heh
18:48 < amlweems> time to read some protobufs
18:48 < morfin> yep
18:48 < Thinkofdeath> -1 = 0xFFFFFFFF
18:48 < morfin> hmm
18:48 < cnlohr> but how does it know the size
18:49 < cnlohr> what if I want to represent 4294967295?
18:50 < amlweems> ah, this is actually kind of cool
18:50 < amlweems> the formula given should be enough
18:50 < amlweems> (n << 1) ^ (n >> 31)
18:50 < cnlohr> o.O
18:50 < amlweems> and then proceed as normal with the varint business
18:50 < amlweems> although... I sort of doubt mc uses this
18:51 < cnlohr> But, that paticular syntax makes no sense to me.
18:52 < amlweems> "If you use int32 or int64 as the type for a negative number, the resulting varint is always ten bytes long – it is, effectively, treated like a very large unsigned integer."
18:53 < amlweems> Thinkofdeath is right
18:53 < amlweems> it's just normal two's complement
18:53 < cnlohr> so that would be ff ff ff ff ff ff ff ff 00?
18:54 < cnlohr> but it says it's encoded as a positive 1
18:54 < amlweems> ignore the bit about zigzag on that page
18:54 < amlweems> by default, varints are int32 which basically casts everything to an unsigned int and sends it
18:55 < amlweems> so, -1 is 0xFFFFFFFF
18:56 < cnlohr> so it is ff ff ff ff 00 ?
18:56 < cnlohr> wait
18:56 < cnlohr> no
18:56 < cnlohr>  ff ff ff ff 0f
18:58 < cnlohr> >.< Using Makefiles to make minecraft packets is frustrating
18:58 < amlweems> o.O
18:58 < cnlohr> Also, since it's a new bunch of people in here... I am having a problem updating blocks.
18:59 < cnlohr> I am on an embedded system so I can only send packets ~127 bytes long.
18:59 < amlweems> that's going to be an issue...
18:59 < cnlohr> And, so I am sending the map bulk chunk with no data, which Minecraft is A-okay with.  I can send block updates and everything's fine
18:59 < cnlohr> I can run around click things, etc.
18:59 < cnlohr> any time I place a block in a new location, it drops there just fine
19:00 < cnlohr> BUT if I change a block, the visual representation of the block does not update.
19:00 < cnlohr> The outline of the block updates, and if I break another block on the client in the area, it'll update all the blocks
19:00 < cnlohr> http://imgur.com/a/txDO2
19:01 < amlweems> so, one of the major outstanding bugs in 1.8 is block updates not rendering sometimes
19:01 < amlweems> you may just be running into that bug
19:01 < cnlohr> I changed the meta of that switch and it switched the gray block outline, but didn't update the visual
19:04 < cnlohr> Does anyone have any idea what can contribute to that bug?
19:06 < cnlohr> (I REALLY hope there's some work around :( )
19:08 < shoghicp> blame Minecraft D:
19:08 < shoghicp> did you try updating a block near it too?
19:08 < cnlohr> Yes, I am updating many many blocks, but until the client breaks a block, no dice.
19:09 < cnlohr> I've tried single and multi update
19:09 < cnlohr> and setting blocks to 0x00 and then back to a value, too
19:09 < amlweems> what protocol version?
19:09 < cnlohr> 47
19:10 < amlweems> what lib are you using?
19:10 < amlweems> assuming it's open source
19:10 < cnlohr> lib?
19:10 < amlweems> the thing you're using to send packets
19:10 < amlweems> or are you doing it yourself
19:10 < cnlohr> I have to keep the compiled code size to under ~3k 
19:10 < cnlohr> no libs.
19:11 < cnlohr> well, 5k after everything.
19:11 < cnlohr> I've only got 16kB for everything including the TCP/IP stack.
19:11 < amlweems> is your code open source?
19:11 < amlweems> I want to see your block update functions
19:11 < cnlohr> yep... I only have the 1.7 version up on github now, though.
19:12 < cnlohr> http://pastebin.com/r72At1xu
19:12 < cnlohr> And to re-iterate, this function totally does work when I go from no block to block.
19:13 < amlweems> hm
19:14 < cnlohr> The only thing I think might be confusing minecraft is the following:
19:14 < cnlohr> http://pastebin.com/E1tp9R8j
19:14 < cnlohr> I can make my bitmap anything and it has no effect.
19:15 < amlweems> just watched the youtube video in your github readme
19:15 < amlweems> that's fucking awesome
19:15 < cnlohr> If I send an incomplete (but yet non-zero) chunk everything gets royally hosed.
19:15 < cnlohr> OH! I am adapting it to work with a $5wifi chip and a similar processor.  I am going to put a minecraft server in one of those little plastic redstone blocks, and make it when you pull a lever or something light up.
19:16 < amlweems> :D
19:18 < cnlohr> Right now, I am trying to precompute the operation: Use packet compression; send some really boring properly formatted chunk; disable compression, and have the processor mindlessly send the data out...
19:18 < cnlohr>  BUT I REALLY WISH THERE WAS A WAY to just tell Minecraft "HEY UPDATE THIS JUNK"
19:19 < amlweems> that's the route I would take, disabling compression is the easiest way
19:19 < amlweems> ff ff ff ff 0f should be -1
19:19 < amlweems> I have no idea on the block updates though
19:20 < shoghicp> cnlohr: I saw that video a while ago, nice job!
19:20 < cnlohr> You guys are AWESOME FOR ALL THE SUPPORT YOU GIVE TOO!
19:20 < cnlohr> I can't imagine the dedication it takes
19:20 < cnlohr> and I appreciate it so much
19:21 < shoghicp> cnlohr: you are working on 1.8, right?
19:21 < cnlohr> I am trying :(
19:21 < shoghicp> do you have packet dumps of what you have done so far?
19:22 < cnlohr> sort of?  What did you want?
19:22 < woder> is there any way that packet 38 can have an uncompressed size of 543335?
19:22 < cnlohr> err rather I can generate them, via wireshark
19:23 < shoghicp> cnlohr: that works. I guess you could enable packet logging on the client
19:23 < shoghicp> if that option is still there
19:23 < amlweems> ooooh
19:23 < amlweems> I didn't know that was a thing
19:23 < cnlohr> I don't know?
19:24 < cnlohr> J/w if I send continuous ground-up, but only set one bit in the primary bit map, do I only need to send that one chunk?
19:25 < cnlohr> wait... I could be going about this all wrong
19:25 < cnlohr> to initialize blocks, I should be using 0x21
19:25 < cnlohr> what is 0x26 for?
19:26 < shoghicp> multiple chunks per packet
19:26 < shoghicp> like a 0x21 with more chunks
19:30 < cnlohr> got it, so I don't need to worry about that
19:34 < shoghicp> cnlohr: I'm updating my own project for 1.8 so I can test things :)
19:39 < cnlohr> cool
19:44 < morfin> bulk send?
19:45 < morfin> i saw it but in old versions it was uncompressed hmmm
19:46 < cnlohr> hnnggg Minecraft is unhappy
19:46 < cnlohr> "java.util.zip.DataFormatException: incorrect header check"
19:50 < cnlohr> OMG OMG OMG OMG OMGOMADFASDFASDFA YAYAYYYYYYYY
19:50 < cnlohr> WWOWOWOHOHHOOHHHHHOOO
19:50 < cnlohr> Ok, so turns out you do need to send valid 0x21's otherwise you get that graphical glich.  minecraft doesn't update blocks and doesn't warn you.
19:50 < cnlohr> It's like "yep, everything's fine" but it's lying.
19:52 < shoghicp> classic Minecraft :)
19:53 < cnlohr> I'm not limited to only one chunk, at 0,0 :( but I can deal with that limitation for everything I really need.
19:55 < cnlohr> Can you guys check something for me really quick?  My skylight looks all wrong...
19:55 < cnlohr> http://pastebin.com/Exwcued3
19:56 < cnlohr> I always have a hard time understanding what to put where with the SMP format :-/
19:56 < shoghicp> you mean, all dark with a spot of light?
19:56 < morfin> wait is not that using nibles?
19:58 < morfin> ow 
19:58 < morfin> that's different thing 
19:59 < cnlohr> o.O
20:01 < cnlohr> Osnap something's wrong, I am getting a weird banding
20:01 < cnlohr> how do I use nibbles?
20:01 < shoghicp> nibble = 4 bits
20:01 < shoghicp> so two nibbles per byte
20:03 < morfin> :D
20:03 < cnlohr> If I wanted to do this really terribly but enough to make it work... what would I put in mapdata to make a solid grass block with full skylight?
20:03 < cnlohr> cause this is not that; http://imgur.com/N7AYVX8
20:03 < morfin> you're writing server?
20:04 < shoghicp> set the byte to 255
20:04 < cnlohr> yep, for embedded systems ( <1kB of ram, 16kB flash)
20:04 < morfin> :O:O
20:04 < cnlohr> It's been working for a long time, but trying to update to 1.8 has been annoying
20:04 < cnlohr> and I've had to nix a few features
20:04 < cnlohr> byte to 255?
20:04 < morfin> looks like something strange happens
20:05 < cnlohr> how many nibbles-per-cell should there be if I'm sending packet 0x21?
20:06 < cnlohr> And, should it be interleved or not?
20:06 < shoghicp> you are sending 4 bits per block
20:07 < shoghicp> so it's blocks/2 bytes set to 255
20:07 < shoghicp> the client will recalculate light by itself *again* later :P
20:08 < cnlohr> right, but all the data?  Looking at it more closely, it looks like my old code sent: All of the block IDs, then ALL of then skylights, etc.
20:09 < morfin> hmm
20:14 < morfin> lol what?
20:14 < morfin> You can also set an animation to air! The animation will still be visible.
20:15 < cnlohr> does add or meta need to be anything nonzero
20:16 < cnlohr> this is what I'm trying now: http://pastebin.com/r2sURtw7
20:21 < cnlohr> can anyone tell me how many nibbles per block I should be adding up to?
20:23 < shoghicp> one nibble per block
20:24 < cnlohr> no I mean for the Whole sum of the 0x21 packet payload
20:27 < cnlohr> :'( http://imgur.com/3BfnEMK
20:27 < cnlohr> lol
20:33 < cnlohr> I clearly do not have any understanding of how this map stuff works
20:44 < cnlohr> anyone and who can tell me what my map chunks should look like?
20:44 < cnlohr> i.e. when it says "each chunk column" do they mean for the whole 16x16x16 chunk? I.e. all of the block types in a 4kB chunk, then all of the meta data in a 2k chuk?
20:47 <+Prf_Jakob> I think "each chunk column" is a series of vertical 16x16x16 chunks.
20:47 <+Prf_Jakob> I the past a chunk was 16x256x16.
20:48 <+Prf_Jakob> Then they split those into 16x16x16 * 16 chunks.
20:48 < cnlohr> ok, so it should be a contiguous block of "every block ID in here"
20:48 < cnlohr> (err in this 16x16x16 chunk)
20:49 <+Prf_Jakob> Sorry dunno.
20:52 <+Prf_Jakob> It was a long time ago I did anything minecraft related.
21:01 < cnlohr> Does anyone have an example uncompressed 0x21 they can give me?
21:05 < barneygale> I can get some for you cnlohr 
21:05 < barneygale> gimme a few
21:05 < cnlohr> thank you :)
21:05 < cnlohr> Based on the SMP data page I cannot figure out what the whole of the packet should look like
21:06 < cnlohr> like the general organization
21:06 < barneygale> 1.8?
21:06 < cnlohr> is there a server someone can link me ?
21:06 < cnlohr> and yep
21:06 < cnlohr> 1.8
21:06 < cindy_k> cnlohr sorry we can't
21:06 < cindy_k> we are under a DMCA request right now. :(
21:06 < cnlohr> o.o how?
21:06 < cindy_k> http://www.spigotmc.org/threads/our-dmca-response.28772/
21:07 < cindy_k> sorry cnlohr :) someone may have a different server
21:07 < cnlohr> :(
21:08 < cnlohr> that is ridiculous
21:09 < cnlohr> j/w is there an "add" bitmap in 0x21 anymore?
21:14 < cnlohr> I don't need a dump. I missed this in the protocol " Data value section removed  Extended id section removed  Block id section is now a unsigned short (little endian) per a block "
21:21 < cnlohr> eh, it's workin' good enough I guess
21:22 < woder> As a follow up to anyone who noticed my struggle in the last day or two; the trick is not to use DataInputStream.read() but rather DataInputStream.readfully() how I hate dumb mistakes
21:26 < MrARM> Yeah, I did same mistake 
22:03 < woder> is it written anywhere what "chunk data" looks like in 1.8?
22:14 < cnlohr> I don't think so... I eventually figured it out enough from a lot of trial and error, though :( Still don't think I'm right.
22:15 < cnlohr> also, I did get it working, and in my 5kB footprint.
22:22 < jython234[2]> Hello is anyone here?
22:23 < Scruff> Many are.
22:23 < Scruff> As you can see 167.
22:23 < jython234[2]> xD
22:23 < Scruff> whether or not they are active is another thing.
22:24 < jython234[2]> How does the client know that a server is bukkit, or spigot when it shows up outdated? Such as "craftbukkit 1.7.2"
22:30 < woder> jython234[2]: you mean when it kicks you for "outdated"
22:34 < woder> cnlohr: could I see what you have? (at least a starting point lol)
22:34 < cnlohr> Sure.  https://github.com/cnlohr/avrcraft/tree/master/dumbcraft/mkmk2
22:35 < cnlohr> It makes a bunch of grass blocks
22:35 < cnlohr> (0x02<<4) on line 54 of makemap.c
22:35 < dx> cnlohr: by the way, avrcraft was suggested at least once during the discussion of "what should we use after the death of bukkit"
22:36 < dx> cnlohr: but i'm afraid it might not be a serious suggestion, sorry
22:36 < cnlohr> X.X that sounds awful.
22:36 < dx> hahah
22:36 < cnlohr> I mean sure it'd probably handle 10,000 simultaneous users, but at what cost?
22:36 < cnlohr> :-p
22:41 < jython234[away]> woder: no, in the server list ping
22:44 < woder> oh well the server list ping has the protocol version in it
22:45 < jython234> yes but how does that differ between different servers? 
22:47 < jython234> also, i am trying to implement server list ping for my server but it dosent seem to be working: http://pastie.org/9532656
22:47 < Drainedsoul> jython234: That code needs some serious refactoring
22:48 < jython234> xD
22:48 < Drainedsoul> I'm serious.  Don't even bother thinking about the fact that it doesn't work.  Refactor it first.
22:49 < eddyb> dx: btw, I forgot to post an update. someone is toying with custom terraingen and I love how easy it is to just plug that into my renderer
22:50 < eddyb> http://www.reddit.com/r/rust/comments/2flwjl/world_generation_in_hematite_xpost_rrustgamedev/
22:50 < eddyb> more info in the /r/rust_gamedev post
22:50 < dx> eddyb: fun!
22:51 < jython234> well does anyone know whats wrong?
22:52 < Drainedsoul> jython234: Why are you thinking about that?  Refactor it, decouple it, separate concerns.  Unit test each component.  What's wrong will fall out on its own.
22:52 < jython234> the part that doesnt work is my reply to the StatusRequest packet
22:53 < jython234> i would look at bukkit or spigot code, but the repo's were taken down
22:53 < Drainedsoul> jython234: Why would you look at code?  http://wiki.vg/Protocol
22:54 < jython234> im not an idiot, i read that already
22:55 < jython234> oh wait i think i figured it out
22:59 < jython234> fixed
23:02 < MalekAlrwily> finally
23:02 < MalekAlrwily> minecraft channel and shoghicp is not op :)
23:03 < dx> welcome to the non-pocket edition minecraft world
23:03 < dx> here shoghicp is just that weird guy who doesn't hate php
23:03 < MalekAlrwily> :D
23:04 < Drainedsoul> how can you not hate PHP
23:04 < MalekAlrwily> I hate php
23:04 < dx> ok maybe shoghicp hates it a little
23:04 < MalekAlrwily> if he hates it, he will not use it
23:04 < dx> he has no choice at this point
23:05 < dx> that's like saying mojang can just stop using java if they want to
23:05 < MalekAlrwily> Lol
23:05 < MalekAlrwily> yeah
23:05 < MalekAlrwily> I love mcdevs!
23:07 < jython234> MalekAlrwily: YAY!
23:07 < jython234> dx: lol how can you not hate php
23:07 < MalekAlrwily> jython234: Lol you are here!
23:07 < jython234> yay lol
23:16 < shoghicp> dx: I hate it, but I still use it
23:18 < shoghicp> well, at least it's different from the typical PHP that I see around that makes me cringe
23:20 < shoghicp> MalekAlrwily: I hate Windows too and I've to use it for several things :S
23:21 < MalekAlrwily> Lol
23:22 < MalekAlrwily> I don't hate windows
23:22 < MalekAlrwily> I can't use any OS except windows
23:26 < shoghicp> this reminds me that I've to update the wiki with all the new protocol info and the secret fields that don't show up
23:26 < MalekAlrwily> how this reminds you? xD
23:27 < MalekAlrwily> maybe because windows = wiki xD
23:27 < shoghicp> nah, all the pings in #mcdevs :)
23:27 < shoghicp> I don't get pinged a lot here
23:27 < shoghicp> oh, and someone asked about wiki.vg over /r/admincraft
23:27 < MalekAlrwily> shoghicp: PING!!!
23:27 < MalekAlrwily> Lol, no NullFull here :)
23:28 < shoghicp> NullFull doesn't do that anymore :)
23:28 < MalekAlrwily> lasttime it does
23:28 < MalekAlrwily> I can do whatever I want here ;)
23:29 < MalekAlrwily> no bans
23:29 < MalekAlrwily> no kicks
23:29 < MalekAlrwily> jython234: ^
23:29 < shoghicp> well, do not spam here as the rules here are mostly the same
23:29 < shoghicp> but let's stom this cross-channel talk
23:29 < shoghicp> stop*
23:30 < MalekAlrwily> I haven't spam
23:30 < MalekAlrwily> I never spammed anyone
23:30 < jython234> huh
23:30 < MalekAlrwily> jython234: ?
23:31 < jython234> MalekAlrwily: lol
23:31 < MalekAlrwily> xD
23:31 < jython234> no kicks no bans yay
23:32 < MalekAlrwily> :D
23:32 < MalekAlrwily> Be right back
23:32 < jython234> k
23:39 < Drainedsoul> Does anyone know if there's a particularly good reason why the "Name Tag Visibility" field of the Play/Clientbound/Teams packet is a string, rather than some kind of numerical enumeration?  The documentation seems to suggest it only takes on one of four values...
--- Day changed dim. sept. 07 2014
03:02 < woder> how can you associate a name to a uuid? (considering that the spawn player packet doesn't have names anymore)
03:21 < Aaron1011> woder: Mojang has an API for that: http://wiki.vg/Mojang_API
03:27 < woder> thanks!
03:33 < SinZ> woder: whatcha working on
03:54 < woder> SinZ: torchbot! remember that? lol
03:54 < SinZ> Negative
03:54 < woder> its come a very long way
03:54 < woder> https://github.com/woder/TorchBot/
06:12 < bspkrs> o/
06:12 < SinZ> \o
09:13 < Fenhl> \o/
09:16 < shoghicp> /o\
09:18 < dx> \o\
09:25 < Fenhl> \oo//
09:28 < shoghicp> Fenhl: what is that o.O
09:30 < Fenhl> Zaphod Beeblebrox
09:37 < shoghicp> hmm
09:42 < dx> hmm
09:43 < shoghicp> 1.8: VarInt everywhere \o/
09:46 < Fenhl> heh
09:48 < Fenhl> I wonder if it would be possible to install some sort of software on a server to record the communication between it and Minecraft clients
09:48 < shoghicp> hmm, on 0x16 Entity Look there are two Y Axis fields
09:49 < dx> Fenhl: like a server mod? or a MITM proxy?
09:49 < Fenhl> dx: has to be the vanilla server software
09:50 < Fenhl> but I do have full root access to the server
09:50 < dx> and how far do you want to go with that root access?
09:51 < Fenhl> preferably it would be not too hackish
09:51 < Fenhl> but I don't know a lot about how UNIX handles this sort of networking stuff
09:52 < Fenhl> but maybe there's something that I can run which will run the server but intercept and log its communications
09:52 < Fenhl> like, the server is Java, so maybe a plugin to the jvm?
09:52 < shoghicp> if you can get the server private key (Minecraft)
09:53 < shoghicp> you can decrypt everything else :)
09:53 < dx> shoghicp: but how easy is that? it's non-trivial for SSL already
09:54 < Fenhl> well I'll worry about decrypting and making use of the data later
09:54 < Fenhl> have to actually get it stored first
09:55 < dx> lol no
09:55 < Fenhl> ?
09:55 < dx> if you worry about decrypting it later, you'll end up with something you can't decrypt
09:56 < Fenhl> I don't care about that right now, I'll add decryption capabilities later and record new data then. This is just for proof of concept
09:57 < dx> what do you want to do anyway
09:57 < Fenhl> ideally, http://dev.bukkit.org/bukkit-plugins/replay/ but for vanilla
09:58 < Fenhl> but there's other things that would be possible with that. Lots of new features for https://github.com/wurstmineberg/api.wurstmineberg.de
09:59 < shoghicp> dx: I mean, you have access to the code
09:59 < shoghicp> or use online-mode=false
10:00 < dx> shoghicp: i thought you meant decrypting sniffed packets
10:01 < Fenhl> our server is whitelisted, I don't think the admin would approve of offline mode
10:01 < dx> it would be offline mode with a proxy in front of it handling authentication
10:01 < dx> never direct offline mode
10:02 < shoghicp> ^
10:02 < Fenhl> ah
10:02 < shoghicp> you can put bungeecord in the front
10:02 < shoghicp> it works for the BigBrother plugin without modifications, so I guess it'll work for vanilla
10:04 < dx> totally original name
10:04 < dx> i thought you were talking about a bukkit plugin that i used three years ago in my first bukkit server
10:05 < shoghicp> nope
10:05 < shoghicp> I'm bad at naming things
10:06 < shoghicp> don't remind me! :'(
10:06 < dx> wait hold on
10:07 < dx> is this even a 1984 reference?
10:07 < shoghicp> no
10:07 < dx> that's terrible shoghicp
10:07 < shoghicp> I know
10:08 < Fenhl> okay so how would bungeecord help?
10:09 < shoghicp> it handles authentication
10:09 < dx> and is a proxy
10:09 < shoghicp> then, forwards packets to your server in offline mode
10:09 < shoghicp> that can bind to 127.0.0.1
10:09 < shoghicp> so it can't be joined without using bungeecord
10:09 < Fenhl> so I would put my logger between bungeecord and the server?
10:09 < dx> also bungeecord has plugins so i guess you could also implement something there
10:09 < shoghicp> that way you can record all the packets
10:10 < shoghicp> or maybe record everything using bungeecord
10:10 < shoghicp> but yeah, you have that channel open to record things
10:10 < Fenhl> the plugin thing is Java only so that's not very helpful
10:10 < dx> why not
10:10 < Fenhl> well I could write the logger in Java but I don't know a lot of Java
10:10 < dx> lolk
10:11 < dx> alternatively, if you want to keep your sanity and not mess with protocol dissection, http://wiki.vg/Debugging
10:11 < dx> write packet logs to a file, parse that
10:12 < dx> although tuning log4j2 might result in losing sanity
10:12 < dx> and performance, probably
10:12 < dx> writing to a pipe instead of a normal file might be better.. or not
10:13 < Fenhl> ooh neat
10:13 < Fenhl> I've done log4j2 tuning for the server log already, so that will be no problem
10:14 < dx> neat
10:15 < dx> just try not to end up with 500gb log files and slowing down the whole server due to massive disk IO
10:15 < Fenhl> :D
10:16 < Fenhl> yeah that might be problematic actually
10:16 < Fenhl> hm. what are those packet ids in the example?
10:16 < MrARM> maybe you can disable file output and instead read the out of the program? 
10:17 < Fenhl> I'll probably have it write to a socket or something
10:19 < shoghicp> hmm, the Position data type
10:19 < shoghicp> I see (x & 0x3FFFFFF)
10:19 < shoghicp> wouldn't that eat the +/- sign?
10:20 < shoghicp> or is there a different reference point now?
10:42 < Thinkofdeath> shoghicp: nope it keeps its sign
10:42 < Thinkofdeath> hence why the decoding needs to do two shifts to place it back
10:43 < Drainedsoul> you just have to backfill the sign bits when you widen it
10:44 < shoghicp> so the sign is placed on 0x2000000
10:45 < Drainedsoul> yes
10:46 < Drainedsoul> https://gist.github.com/RobertLeahy/e96f06553d82c365a132 idk how helpful that is
10:46 < shoghicp> okay, thanks :)
12:54 < Aragas> Hello again people
12:54 < Aragas> http://wiki.vg/Protocol#Entity_Look , the last field is incorrect
12:56 < Fenhl> Aragas: that table isn't even formatted correctly, lol
12:57 < Aragas> Fenhl: Yep. Dunno if there was anything or just formatting error
12:57 < Fenhl> do you happen to know what the correct form of the packet is?
12:58 < Aragas> Fenhl: Nope, just started to analyze how bad porting will be. I would say 15/10
12:59 < Rustywolf> I dont think it's supposed to be there
13:00 < Rustywolf> It's just a copy of the Pitch field
13:00 < Aragas> I'll check Thinkofdeath github repo
13:00 < Rustywolf> and spigot only writes out four fields
13:00 < Rustywolf> I just did
13:01 < Rustywolf> It's an accidental extra lione
13:01 < Aragas> Okay, nice
13:01 < Aragas> Thank u
13:02 < Fenhl> fixed the wiki article
13:03 < Fenhl> thanks Rustywolf
13:03 < Rustywolf> ni prob
13:03 < Fenhl> ni!
13:05 < Aragas> And i see some Entity ID are still int, not varInt. Is that correct?
13:09 < Aragas> Yep, correct. A bit strange
13:10 < roblabla> It's called mojang.
13:11 < Aragas> they said they would use only varInts, lol
13:12 < roblabla> for new packets, maybe
13:12 < roblabla> But I guess they must've skipped a few when they ported from int to varint
13:12 < Drainedsoul> Mojang can't even keep their data types straight within single packets, do you really expect it across the whole protocol?
13:12 < roblabla> Drainedsoul:+1
13:13 < SinZ> Just remember that height is whatever you want it to be
14:00 < woder> how does/in what class does the default minecraft client apply gravity?
14:01 < roblabla> My uneducated guess would be Entity or one of its generic subclasses
14:02 < woder> hmm, at least its a starting point, thanks
14:13 < SinZ> woder: what kind of gravity, the one that tells clients to fall, or the gravity that sand has
14:17 < woder> the one that makes the client fall
14:17 < woder> SinZ ^
15:05 < Aragas> Particle data in Particle packet depends on particle. But where is particle id list?
15:19 < Thinkofdeath> Aragas: https://github.com/thinkofdeath/mc-autodocs/blob/master/protocol/enums/Particle.java
15:20 < Aragas> Thinkofdeath: Thank you. Haven't noticed that.
16:50 < D4V1D1997> Hi Guys, i'm working on a minecraft server, my problem: I don't know how to handle the packets. Can someone help me maybe?
16:56 < Aragas> D4V1D1997: What language u use? There is a lot of code examples
16:57 < D4V1D1997> I use Java
16:57 < Aragas> http://wiki.vg/Server_List
17:01 < D4V1D1997> Yes, there is much code, but less code explanations...
17:07 < D4V1D1997> I want to understand the protocol but i don't find good examples for things like sending a packet.
17:14 < shoghicp> :S I had to split the position data on two 32-bit integers
17:14 < shoghicp> but it works \o/
17:32 < M4GNV5> if anybody hasnt heard of it already: https://bit.ly/1uqcoYC
19:13 < winny> https://github.com/github/dmca/blob/master/2014-09-05-CraftBukkit.md
19:28 < Dhruv0> How big is a Position?
19:28 < Dhruv0> and is it always a fixed size
19:29 < MrARM> hmmm... what are the properties in 0x38?
19:29 < Dhruv0> What?
19:30 < Dhruv0> a lot..
19:30 < MrARM> Are those listed anywhere? 
19:30 < Dhruv0> what do you mean
19:31 < Dhruv0> http://wiki.vg/Protocol#Player_List_Item
19:31 < MrARM> When the action is ADD_PLAYER,  there's a field called properties
19:31 < Dhruv0> Yes..
19:31 < MrARM> Is there a list of those? 
19:31 < Dhruv0> check my wiki.vg link
19:32 < MrARM> yes, I saw that
19:32 < Dhruv0> How long is Position?
19:32 < MrARM> I'll ignore those, I probably don't need those anyway 
19:33 < MrARM> I think 8
19:33 < Dhruv0> So its a fixed size?
19:33 < Dhruv0> Meaning whenever I need to read Position, i should do readPosition(8)
19:33 < MrARM> It's explained on the wiki.vg page with encoding and decoding example 
19:48 < Fenhl> I was wondering about that too. the example isn't too clear
19:50 < Dhruv0> Fenhl Position?
19:55 < Fenhl> Dhruv0: yes
20:03 < Fenhl> but I guess it's just 26 bits of x, 12 bits of y, and then 26 bits of z? and it supports integer positions only?
21:27 < Drainedsoul> Fenhl: Yes.
21:27 < Drainedsoul> https://gist.github.com/RobertLeahy/e96f06553d82c365a132 I don't know if this helps at all
21:41 < Dhruv0> Ok for Update Sign
21:42 < Dhruv0> What is the Chat data type?
21:43 < Dhruv0> Is it just a string?
21:43 < Dhruv0> Or does it want it as a JSON type?
21:46 < Drainedsoul> http://wiki.vg/Chat
22:10 < Dhruv0> Really Mojang?
22:10 < Dhruv0> an On Ground boolean for all Entity Movement packets
22:22 < Thinkofdeath> Dhruv0: its used for boats
22:22 < Thinkofdeath> if onGround = false the boat moves slower client-side
22:22 < Thinkofdeath> * true
22:22 < Dhruv0> O-O
22:22 < Dhruv0> Oh
22:37 < Dhruv0> SirCmpwn, How would I find out if a player if on the ground, e.g WhatPosVariable - whatInteger?
22:37 <+SirCmpwn> are they on the ground -> OnGround = true
22:37 <+SirCmpwn> how else do you explain it
22:37 <+SirCmpwn> just check if they're on the ground
22:37 < Dhruv0> No no, I meant how do i check if they're on the ground
22:38 < Dhruv0> I know I have to subtract Pos.y or Pos.z by 1.5 or 2
22:38 < Dhruv0> But I forgot which ones o-o
22:38 <+SirCmpwn> subtract their stance
22:38 <+SirCmpwn> from Y
22:38 <+SirCmpwn> and make it fuzzy, it's not perfect
22:39 < Dhruv0> Um, is there a variable for their stance?
22:39 < Dhruv0> I have no idea how premium works
22:39 <+SirCmpwn> I'll let you do the research yourself
22:39 < Dhruv0> Sure :)
22:40 <+SirCmpwn> I only answer questions that you can't answer yourself, I am busy
22:40 < Dhruv0> Ok, sorry
23:04 < expir3dcow> Did I do something wrong? http://pastebin.com/MdfSBbwP
23:06 < Dhruv0> Did they take AddBitMap out of the metadata?
--- Day changed lun. sept. 08 2014
00:31 < jython234[hw]> spam
00:31 < winny> fix yo internet ahf
00:31 < winny> ajf ^
00:32 < jython234[hw]> LOL
00:32 < winny> learning dvorak lol
00:34 < winny> ajf|: fix yo internet
00:36 < jython234[hw]> ajf: you must have connection problems
00:46 < Dhruv0> afj: Please
00:46 < jython234> spamming me
00:52 < jython234> stop!
00:53 < dx> oh no someone has bad internet
00:53 < dx> this is the end of the world
00:54 < dx> protip: they are probably away and not even aware of this
00:54 < dx> asking "stop" is silly
01:27 < winny> ajf|: 
01:27 < winny> ajf|: 
01:27 < winny> ajf|: 
01:27 < winny> ajf|: fix internet