--- Day changed lun. nov. 11 2013
00:25 < Drainedsoul> does the client not render line feeds properly anymore? :|
00:44 < skarlitz> Could someone run me through on usage of Authlib?
01:37 < Luqman> hmm, still can'tfigure out how to get my player visible again after a respawn
01:37 < clonejo> Luqman: are you going beyond chat now?
01:39 < Luqman> yea, i accomplished what i wanted with chats so i'm just playing around right now
01:39 < Luqman> maybe make a MUD style client :D
01:41 <+clonejo> I though of doing a server in Rust (I once did one in Erlang), but Rust has no replacement for Erlang's OTP (yet)
01:44 < Luqman> yea there are some pain points i can think of wrt writing a server in rust right now
01:44 <+clonejo> In Erlang you can send messages to a process through the task id/name alone, in Rust you might solve that by using clever routing.
01:45 <+clonejo> doing an rpc to another task has to be carefully planned in advance and can't be added later as easey
01:45 <+clonejo> *easy
01:45 < Luqman> oh between tasks you can just use chan/port
01:46 <+clonejo> well, only if you have a chan to the other task
01:47 <+clonejo> Think of a task managing which entity ids are free and which are currently in use. The client handling tasks will have to connect to the id task exactly two times.
01:50 <+clonejo> the id task shouldn't have to check a port for each client, so requests might be send using one shared port/chan
01:51 <+clonejo> Luqman: hm, can chans be sent?
01:52 < Luqman> shared chans do exist
01:52 < Luqman> yes
01:54 <+clonejo> then the client tasks can ask for an entity id using the shared chan and get the reply by sending another chan with the request
01:57 < Luqman> yea, i think that's probably how i'd do it
02:03 <+clonejo> I did some protocol code so far: https://gist.github.com/7406143
02:05 <+clonejo> I like the idea of selecting the correct reading function through the return type, but that doesn't work out that well for varint
02:06 < Luqman> i just had my varint reading/writing code give/take i32
02:06 <+clonejo> I like saving bytes :D
02:07 <+clonejo> but I wonder if I there is overhead from creating a struct for varint just to immediately unwrap it
02:21 < Drainedsoul> Can anyone help me with solving this (the "LF"): http://i.imgur.com/TeEeve0.png ?  Here's the JSON object that causes it: http://i.imgur.com/qxNipUN.png
02:27 <+clonejo> Drainedsoul: LF is a linux newline, are you sure you don't send that yourself?
02:27 <+clonejo> Luqman: but I wonder if I there is overhead from creating a struct for varint just to immediately unwrap it
02:30 < Drainedsoul> clonejo: I don't understand your question?  I clearly sent that myself -- it's in the JSON I linked.  I want a newline.
02:31 <+clonejo> Drainedsoul: I don't know how you do a newline within one chat packet, you might try sending CRLF or just sending another packet
02:32 < Drainedsoul> If you send another packet you get into race condition territory.
02:32 <+clonejo> that depends on how you lock
02:33 < Drainedsoul> locking to make sure two packets get sent right after one another, when all you really want to do is print a newline, seems like a really poor design choice.
02:34 < skarlitz> Hey, Drainedsoul, can you take a look at the query I sent?
02:35 < Luqman> Drainedsoul: huh? tcp is sequential. why would you get a race condition
02:35 < Drainedsoul> you'd get a race condition if something else wanted to send a packet between packet A and packet B
02:35 <+clonejo> Drainedsoul: not if you lock the tcp stream the whole time
02:35 <+clonejo> or have only one thread writing to it
02:36 < Drainedsoul> having one thread writing to it doesn't actually solve anything.  You'll still need to tell that thread what to write, and then you have a possibility of packet C getting enqueued between packet A and packet B
02:36 <+clonejo> Drainedsoul: that thread might himself decide to send two packets
02:37 <+clonejo> Drainedsoul: anyway, did you try sending CRLF?
02:37 < Drainedsoul> http://i.imgur.com/RTj8xMs.png it doesn't produce a useful result
02:37 < Drainedsoul> sending \n worked in 1.6.4
02:47 < skarlitz> Would anyone here be kind enough to guide me on authenciating with Yggdrasil? I understand there's an authlib I can look at and a page at wiki.vg But I can't make heads nor tails of it. I'd hope to use the authlib to make my authenciations but if so necessary I would be willing to write my own.
02:57 <+clonejo> skarlitz: I don't know any library for yggdrasil, at least it doesn't seem to be on the wiki.
02:58 <+clonejo> the api is documented on our wiki and it doesn't look that hard to implement, though
02:58 < skarlitz> clonejo: There's a library for it, it's in com/mojang/authlib or somewhere along there.
02:58 < skarlitz> clonejo: I'm a bit new to it so it's not that easy for me. I was hoping to use a library.
02:59 < skarlitz> clonejo: I'll implement it myself if need be, though.
02:59 <+clonejo> you can also decompile mojang's authlib to use that; but then you're on your own^^
03:01 < skarlitz> I did decompile it xD It's not even obfuscated (Drainedsoul actually suggested I do this in the first place) But enterprise programming uses styles beyond me. 
03:02 <+clonejo> I found Java one of the easiest languages to read
03:02 < skarlitz> It's a bit new to me.
03:02 <+clonejo> *to be
03:03 < skarlitz> ?
03:03 <+clonejo> skarlitz: If you're starting to program, you might start with a different language than Java. Other languages offer more possibilities and thus are more interesting in the long run.
03:03 < skarlitz> Oh no, I've already taken my fill of other languages.
03:04 < skarlitz> I've written in Delphi, VB.net, Python...
03:04 <+clonejo> okay
03:04 < skarlitz> I've taken to learning Java but it's by far the most difficult because of OO
03:04 <+clonejo> ever looked at something compiled to native binaries?
03:05 < skarlitz> like C?
03:05 <+clonejo> like C or C++, yes
03:06 < skarlitz> Well, there was Delphi. But I'm not interested in natively compiled languages because I want to use something that's write once, run anywhere. 
03:06 < skarlitz> And that is Java. 
03:07 <+clonejo> well, Java also tends to strips you off the extra possibilities each platform offers
03:07 <+clonejo> -s
03:07 < skarlitz> I don't need those possibilities, though.
03:08 < skarlitz> And if I did, I could write a library and use the JNI to use it. 
03:08 <+clonejo> sure
03:08 <+clonejo> Does Java still stop all threads for garbage collection?
03:09 < skarlitz> I don't know.
03:09 < nickelpro> clonejo: it's configurable
03:09 < nickelpro> stop the world GC is still default in the JVM though
03:09 <+clonejo> xD
03:09 < nickelpro> But few use it in production
03:10 <+clonejo> nickelpro: the default or the thread-wise gc?
03:12 < Drainedsoul> skarlitz: There are other factors other than "write once, run anywhere" to consider when choosing a language.  You're going to take a performance hit using a managed language, for instance.
03:13 < nickelpro> clonejo: Actually... not so sure how it works in a threaded environment
03:13 < skarlitz> Not always, it depends on how you write it. 
03:13 < nickelpro> never wrote threaded java
03:13 < nickelpro> skarlitz: there is always overhead for managed languages
03:14 < Drainedsoul> skarlitz: The fact that objects are default heap allocated in most managed languages means that unless you're just twiddling primitives, you're taking a performance hit
03:14 <+clonejo> skarlitz: if you want fast Java, never destruct objects :P
03:15 < dx> guys, he's a beginner
03:15 < skarlitz> Me?
03:15 < dx> yup
03:15 < nickelpro> Ya that was a bit of a pile on, sorry bro
03:15 < skarlitz> Can't argue with that.
03:15 < skarlitz> Well I don't need that kind of performance. :\ 
03:16 < dx> he has trouble understanding java's OO and you guys are talking to him about the downsides of heap allocation
03:16 <+clonejo> skarlitz: my apologies
03:16 < skarlitz> It's alright.
03:17 < dx> let's be practical here, java is a meh language but it will be okay if he learns it
03:17 < Drainedsoul> dx: That very strongly depends on your standards for "meh"
03:18 < skarlitz> But as I said, I generally want to write in Java for Minecraft-related things. I don't need the fine-tuned performance of a natively-compiled language. The fact that I can feasibly run Minecraft on my laptop is proof enough that Java is plenty good for what I'm trying to write.
03:18 < nickelpro> You'll never get me to abandon Python for clients, dat code density
03:20 < skarlitz> I was going to take baby steps and attempt to connect to a locally hosted MC server and say "Hello world"
03:20 < skarlitz> But I can't even get past authenciation. :I 
03:20 < nickelpro> Turn it off
03:21 < skarlitz> And if I ignore authenciation then what I'm trying to write will be useless given the fact that 99% of MC servers utilize it. 
03:21 < nickelpro> Don't worry about auth or encryption until you've got a barebones packet reader working, not worth it
03:21 < dx> yeah, i agree with nickelpro
03:21 < nickelpro> Once you've got the packet reader, _then_ worry about auth/encryption
03:21 < dx> dealing with encryption will be too much to start with
03:21 < skarlitz> Oh, okay.
03:22 < Drainedsoul> Parsing packets and dealing with networking should definitely be your first few steps, then worry about what you're going to do with those two things
03:22 < skarlitz> Aren't all packets encrypted?
03:23 < nickelpro> My first attempt at a client was a 50 line script that sent a hardcoded handshake packet (I actually wrote out the bytes by hand), read the response, and then died
03:23 < Drainedsoul> Only after the encryption handshake, if that occurs
03:23 <+clonejo> you can't skip encryption as a client, can you?
03:24 < Drainedsoul> if you've written a parser, and a networking layer, and you're looking for some way to test either of those, the status packets aren't encrypted
03:24 < Drainedsoul> I don't think you can -- I've never fiddled with it -- but you could certain test against a server with it disabled
03:25 < skarlitz> Are you able to turn off encryption for a server? I thought you could only throw the switch on auth?
03:25 < nickelpro> clonejo: Can't skip it, server won't send you a Login Success if you don't respond to it's Encryption Key Request
03:26 < dx> nickelpro: but what about offline mode servers?
03:26 < nickelpro> dx: offline mode doesn't send an Encryption Key Request, skips right to Login Request doesn't it?
03:26 < nickelpro> In the pre-release it did
03:26 < nickelpro> Login Success*
03:27 < dx> oh okay
03:28 < skarlitz> So uh...
03:28 < skarlitz> Just start up a server in offline mode and work from there?
03:29 < nickelpro> skarlitz: Yep, start by sending a handshake and trying to parse the response
03:30 < skarlitz> How do you log packets in the server? That might be useful
03:30 < skarlitz> I recall Drainedsoul having done that.
03:31 < Drainedsoul> I don't do anything with the vanilla server
03:31 < Drainedsoul> if you saw me posting packet logs, it was generated by my server
03:32 < skarlitz> Oohh
03:32 < skarlitz> How do you do that, then?
03:33 < skarlitz> Is there a plugin of some sort orr... ?
03:33 < Drainedsoul> I have no idea.  I wrote the server software from the ground up in C++.
03:33 < skarlitz> Oh.
03:34 < nickelpro> skarlitz: http://wiki.vg/Debugging it might be a bit beyond you. It's not really necessary since the only packets you'll be worrying about are the handshake and the response
03:34 < skarlitz> *and that stormy night, she trudged through the knee-deep waters of Minecraft packet protocols! But aided by wiki.vg and the support from #mcdevs, she holds her own!* 
03:34 < skarlitz> Oh, thank you
03:37 < skarlitz> So why did Minecraft get switched over to Netty?
03:40 < Drainedsoul> I don't know for sure.  But I think the Mojang networking code was awful.
03:40 < Drainedsoul> and Netty doesn't seem to be especially awful
03:42 < skarlitz> So how do you sift through these packet logs? There seems to be an awful lot of them...
03:42 < Drainedsoul> which?
03:42 <+Amaranth> MC networking before wasn't _that_ bad and netty is a big huge thing that I doubt anyone at Mojang can debug when it goes wrong
03:42 < skarlitz> packets. Just 
03:43 < Drainedsoul> Amaranth: What is your standard for "that bad"
03:43 < skarlitz> So many of them.
03:43 <+Amaranth> Drainedsoul: It worked and thread per connection is the right model for a game server
03:44 < skarlitz> And it doesn't have the huge mess of bugs it has now. :\ 
03:44 <+clonejo> skarlitz: for status requests you only need a few of them
03:44 <+Amaranth> skarlitz: That too :D
03:44 < Drainedsoul> This is 2013, how is thread per connection the right model for anything
03:44 < skarlitz> Also, I have a 5.7mb text file in my logs folder, containing all of the packet logs. 
03:44 < skarlitz> Halp. 
03:44 <+clonejo> skarlitz: grep?
03:45 < skarlitz> I don't know how to use regular expressions o:
03:45 <+clonejo> you can just throw keywords into grep
03:46 < skarlitz> Ah. 
03:46 < skarlitz> [21:42:45] [Netty IO #1/DEBUG]: OUT: [PLAY:22] gz[id=4821, yRot=2, xRot=0]
03:46 < skarlitz> "gz" What's that stand for?
03:47 <+clonejo> skarlitz: you can guess that from the parameters
03:47 < skarlitz> Yes, I know, but does it actually stand for anything?
03:47 <+Amaranth> You'd need to deobfuscate the jar to know the name
03:47 < skarlitz> Aaaah, I see. So they're class file names?
03:47 <+Amaranth> That's the obfuscated packet class name I'm guessing
03:48 < skarlitz> Yeah, other things seem to be... similarly named. 
03:48 < skarlitz> [21:39:48] [Netty IO #1/DEBUG]:  IN: [LOGIN:0] jk[]
03:48 < skarlitz> [21:39:48] [Netty IO #1/DEBUG]: OUT: [LOGIN:2] jg[]
03:48 <+Amaranth> Yeah good luck there
03:49 < skarlitz> I could probably just grab MCP
03:49 < Drainedsoul> there's no MCP for 1.7 afaik
03:49 < greymerk> soon
03:49 < nickelpro> skarlitz: The in is a 0x00 Login Start
03:49 < Drainedsoul> Amaranth: This is 2013, how is thread per connection the right model for anything?
03:49 < nickelpro> The out is a 0x02 Login Success
03:50 <+Amaranth> Drainedsoul: Because we aren't making a web server
03:50 < Drainedsoul> Amaranth: What does that have to do with anything?
03:51 < nickelpro> skarlitz: Note that there is no encryption steps between them since you're in offline mode
03:51 <+Amaranth> Drainedsoul: non-blocking IO has lower throughput and we don't need to scale to thousands of connections
03:51 < skarlitz> nickepro: So the "LOGIN:0"'s "0" is part of "0x00"? 
03:51 < Drainedsoul> Amaranth: How does non-blocking I/O have lower throughput?
03:52 <+Amaranth> Drainedsoul: I don't know, because it does
03:52 <+Amaranth> I'm not a kernel networking subsystem developer
03:52 < Drainedsoul> Amanarth: And that supposes that you're using non-blocking I/O.  Some operating systems have native asynchronous I/O.  It also ignores the overhead of context switching between threads and warming up their instruction cache.
03:53 < nickelpro> skarlitz: The first part ("IN") tells you direction, the second part ("LOGIN") tells you the protocol state
03:53 < skarlitz> nonblocking means it's put in a queue, right? 
03:53 <+Amaranth> Drainedsoul: No one runs servers on Windows or Solaris anymore though :)
03:53 < nickelpro> skarlitz: The third part ("0x00") tells you the packet ident. With this info you can figure out the exact packet you're dealing with
03:53 < skarlitz> So each thread could have a queue of stuff to processs.
03:54 < nickelpro> wiki.vg/Protocol
03:54 < skarlitz> I read about how Netty turned 1000 threads into 4 threads.
03:54 < skarlitz> Supposedly.
03:54 < Drainedsoul> Amaranth: And I'd be very interested to see a benchmark where epoll-/kqueue-driven non-blocking I/O loses to thread per connection in a realistic situation (i.e. under actual load)
03:54 < skarlitz> nickepro: Thanks :) 
03:54 < skarlitz> nickelpro: Thanks :) 
03:55 < nickelpro> skarlitz: Non-blocking I/O means that threads don't wait on sockets, with blocking I/O a single thread can only server a single connection. With non-blocking a single thread can serve thousands
03:56 < skarlitz> nickelpro: Yeah, that's what I mean! :D
03:57 <+Amaranth> Drainedsoul: Trouble is benchmarks are all in java :)
03:57 < nickelpro> And ya, realistically I don't see async I/O losing any fights to connection based I/O. The overhead from merely a couple hundred threads is probably enough for non-blocking to win
03:57 < skarlitz> nickelpro: I had a pretty cool idea about that. Queues and such. I want to implement pools of work for the bots. Basically like Darkbot on steroids. Plus it's a cool programming challenge, which is why I chose it.
03:58 < Drainedsoul> nickelpro: I mean if someone can concede that IOCP will win over connection per thread, then epoll/kqueue almost certain will, because IOCP is only a few percentage points faster than epoll, and kqueue is usually high performance than epoll.
03:58 <+Amaranth> I dunno, it makes sense to me that async IO would scale better for number of connections and have lower latency but would have lower throughput as well
03:59 <+Amaranth> By lower latency I mean for the initial connection setup and such
03:59 < skarlitz> Is 1.7.2 having problems with map saving?
04:00 < Drainedsoul> Amaranth: How does that logically follow?  With asynchronous/non-blocking I/O you use only a few threads -- usually a number equal to the number of cores in the system.  At peak there are little-to-no context switches.
04:00 < nickelpro> Amaranth: You can still have multiple threads for async I/O, say a thread for every 50 connections or so. You'll have less latency because the threads aren't constantly fighting for CPU
04:00 < nickelpro> Drainedsoul beat me to it :-\
04:01 < nickelpro> skarlitz: Not that I know of, why?
04:02 < skarlitz> I was on the GalacticaActual server not too long ago and its map-save times were around 30 seconds. The map isn't even that old. And a lot of people (I mean a lot) were being kicked. 
04:04 < nickelpro> skarlitz: Sounds like a plugin problem
04:04 <+Amaranth> Yeah I can't find any benchmarks that aren't Java
04:05 <+Amaranth> But of course Minecraft is in Java so that is still relevant for them
04:05 < skarlitz> There aren't any plugins as far as I can tell.
04:05 < skarlitz> Given Bukkit isn't even out for 1.7.2. Or MCP. 
04:06 < nickelpro> Spigot protocol hack is out isn't it?
04:06 < skarlitz> Or Forge.
04:06 < skarlitz> It is, but that's just changing a response on a 1.6.4 server.
04:06 < skarlitz> GalacticaActual is on actual 1.7.2
04:06 < nickelpro> huh, dunno
04:06 <+Amaranth> http://paultyma.blogspot.com/2008/03/writing-java-multithreaded-servers.html is the main one for Java
04:08 < Drainedsoul> the link to the PDF is dead
04:08 < nickelpro> Not to mention 2008
04:08 <+Amaranth> http://www.slideshare.net/e456/tyma-paulmultithreaded1
04:08 <+Amaranth> That's the slides
04:09 < nickelpro> Not that I don't think you could be right, I honestly don't know enough about threading in Java
04:09 <+Amaranth> nickelpro: What revolution in writing networking code has happened since 2008 that would invalidate this?
04:09 <+Amaranth> For the most part work on this stuff stopped once the c10k problem was sorted
04:10 < skarlitz> I personally think that forking your work and distributing it across threads is reasonable, but not one thread per task, unless that task is very long. 
04:10 <+Amaranth> It has been about optimization of existing techniques and directly polling the network card and doing TCP in userspace
04:10 < skarlitz> Since Minecraft packet operations are very rapid, it'd make more sense to handle them in batches, such of batches of 30 per thread, having a queue of operations for each one. 
04:10 <+Amaranth> Yes Google apparently does actually do that
04:10 < skarlitz> It'll rapidly execute them as they keep piling in. 
04:11 < nickelpro> skarlitz: Nah, since you'll have tens  of tens of thousands of CPU cycles between each packet. You're I/O limited, not worth batching
04:12 < nickelpro> Not for clients at least
04:12 < skarlitz> Servers are perfect for this.
04:13 < nickelpro> skarlitz: Yes but then you introduce latency while waiting for your batch, "the accursed lag". It's a fine model for something like a high load mail server where latency doesn't bother anyone, bad for games
04:13 < Drainedsoul> "Make better use of multi-core machines" how does anyone figure that blocking I/O makes better use of multi-core machines
04:14 < Drainedsoul> the fact that he's talking about "select" in here makes me nervous
04:14 < skarlitz> It shouldn't introduce much latency if the operations are carrying through enough and are distributed across enough threads, right?
04:15 < Drainedsoul> skarlitz: Why would you handle packets in batches?
04:15 < nickelpro> skarlitz: Sure but then you've basically created the threaded I/O model. Don't let me tell you anything though, get your packet reader working and take a whack at it yourself
04:16 < skarlitz> Oh, aha, sure.
04:16 < skarlitz> Drainedsoul: I don't understand why not. Batches of ten maybe? Since packet ops execute so quickly I would figure that handling them in batches would prevent overloading the system with threads whilst maintaining speed.
04:17 < Drainedsoul> skarlitz: Why would that have anything to do with threads?
04:17 < skarlitz> Isn't there a limit to how many threads that can be created? 
04:18 < skarlitz> I'm learning, but just putting my two cents in.
04:18 < nickelpro> skarlitz: No, they just start headbutting around the ~1000 threads mark depending on how many cores you're working with
04:18 < skarlitz> nickelpro: Ah, I see. 
04:19 < skarlitz> Okay then, forget I said anything. xP
04:22 < skarlitz> So is Bukkit and Forge dependent on MCP? 
04:22 < skarlitz> As in, do they have to wait for the next release of MCP to resume work?
04:24 < greymerk> yeah, which is to say that they require MCP to update to the new version of minecraft
04:24 < nickelpro> Made it through the presentation, really curious where that 25% overhead for NIO is coming from
04:25 < nickelpro> That seems to be the crux of the issue in Java
04:26 < skarlitz> That's horrible. That basically means there's a huge array of projects that are all centered around MCP 
04:27 < skarlitz> The moment MCP isn't available, the entire chain fails. 
04:28 < Drainedsoul> nickelpro: I think that really raises the question of how NIO is implemented in Java on the platforms tested
04:28 <+AndrewPH> skarlitz: vs every project using its own system and having to update it themselves
04:29 < skarlitz> Yeah, each path has its puddle. 
04:29 < nickelpro> skarlitz: If you're modifying vanilla Minecraft, you need a tool chain, makes sense that we all contribute to a single one rather than duplicating effort all over the place
04:29 < skarlitz> nicklepro: Yeah, I know that. 
04:29 < nickelpro> Drainedsoul: My thoughts exactly
04:29 < skarlitz> I just hate to see how it's all waiting on MCP.
04:30 < nickelpro> None of the fun projects are (third-party ftw)
04:30 < Drainedsoul> ^
04:30 < skarlitz> When is the mod API thought to come?
04:30 < nickelpro> ha
04:30 <+AndrewPH> in 400 years
04:30 < skarlitz> Aha, that's about like it.
04:31 < skarlitz> I heard Searge is getting hired grumpily by Mojang to work on the API, aha.
04:33 <+Amaranth> skarlitz: Bukkit doesn't actually use MCP
04:34 < skarlitz> Amaranth: It doesn't? 
04:34 < skarlitz> Amaranth: What does it use?
04:34 <+Amaranth> I would hope by now they've finished their deobfuscation and are working on updating the actual mod
04:34 <+Amaranth> skarlitz: They have their own tools
04:34 <+Amaranth> They also don't name everything, only classes, enums, and things they actually use
04:35 <+Amaranth> If they don't call a method or field they leave it with the obfuscated name so they don't have as much to update
04:35 < dx> Amaranth: i thought you were one of the bukkit core devs
04:35 <+Amaranth> dx: I'm on hiatus/left/whatever
04:35 < dx> oh okay
04:35 <+Amaranth> I don't see myself working on it in the future but I'm still around to answer questions, help troubleshoot, etc
04:36 < skarlitz> It's funny, everyone was crazed over the 1.7.2 update and now everyone's crazed over the 1.7.2 Bukkit update.
04:36 < skarlitz> and I haven't checked yet but I'm pretty sure MC forge is the same, judging by Bukkit's predicament
04:37 <+Amaranth> Yeah people are anxiously waiting for Forge to update too
04:37 <+Amaranth> But Forge is nothing, after that you have to wait for your mods
04:37  * dx still has a forge server in 1.4.7
04:37 < skarlitz> Ahahaa, yeah. But I'd imagine devs would be pretty anxious. 
04:38 < skarlitz> I personally don't see the rush in updating to the newest thing each time. I still like 1.2.5
04:38 < skarlitz> A lot of good mods were made that were never updated :<
04:39 <+Amaranth> But yeah, that's one thing people don't seem to realize. Updating CraftBukkit and Bukkit for a new release is like updating MCP (sort of), Forge, and at least one of the largest mods that uses Forge
04:40 <+Amaranth> It's like 2MB of diff to on top of the vanilla server
04:41 <+Amaranth> Everyone is more or less accepting of waiting months before they upgrade their FTB server but if Bukkit takes more than 2 days people lose their shit
04:41 < dx> s/months/the rest of eternity/
04:42 < dx> my players were like "no redpower for 1.5? oh okay let's just stay with this."
04:43 < skarlitz> Oh, how I loved redpower. Shame it never got updated.
04:43 < skarlitz> That was one of my favorite mods. 
04:43 < dx> the developer's attitude was the opposite of what the open source culture encourages
04:44 < skarlitz> Yeah. :\
04:44 < skarlitz> A replacement is being devved right now, I forget by who.
04:44 < skarlitz> I think it's either made by chickenbones or immibis
04:45 <+Amaranth> Redpower was also a buggy inefficient piece of garbage
04:45 < Drainedsoul> so you mean it was exactly like vanilla Minecraft?
04:45 < skarlitz> Noone seemed to mind when they were using it. :P
04:45 <+Amaranth> But it did things nothing else did and the developer was hostile about people improving it so we were stuck with it
04:46 < dx> skarlitz: oh i do mind, as a server admin
04:46 <+Amaranth> Now that the developer has gone people have a reason to rewrite it that overcomes laziness and hopefully something better will come from it
04:46 < skarlitz> Oh, aha. 
04:46 <+Amaranth> Basically every block redpower added was a microblock
04:46 <+Amaranth> Err, was a tile entity rather
04:46 <+Amaranth> Even the microblocks
04:46 < skarlitz> Oh, by the way, Redlogic is developed by immibis
04:47 <+Amaranth> And all of the machines were broken in some way and a few were known for killing servers by burning CPU
04:48 < nickelpro> Oh lord we're talking about Red Power? The maintainer was something else
04:48 < skarlitz> Yeah, so I've heard.
04:48 < skarlitz> I never understood keeping your source under lock and key when your product is written in Java.
04:49 <+Amaranth> And when it is a mod for a game you had to decompile to mod
04:49 < skarlitz> Sure, you can obfuscate it and make it difficult but it's still easier than natives to decompile and deobfuscate.
04:50 <+Amaranth> Like, the people who would be interested in working on it are also the kind of people who could just decompile it and do so anyway because they had to do that in order to do any modding
04:51 < dx> http://ix.io/8Zk
04:51 < dx> Amaranth wasn't kidding
04:52 < dx> those files are the output of git format-patch over https://github.com/Bukkit/mc-dev
04:53 <+Amaranth> mc-dev is the decompiled server code, no craftbukkit additions
04:54 < skarlitz> By the way, can you still silkpick spawners?
04:54 < dx> Amaranth: ...oh derp, i just diffed what mojang did? :D
04:54 <+Amaranth> I think you're thinking of a mod/plugin
04:54 <+Amaranth> dx: Yeah
04:54 <+Amaranth> skarlitz: Or you're thinking of a bug that only existed in beta 1.9 which never really released
04:55 < skarlitz> Oh. 
04:55 < skarlitz> Well that shot my hopes down.
04:56 < dx> okay let's hope the bukkit devs use consistent commit logs
04:56 <+Amaranth> Just taking into account the modifications to Mojang's files (so not counting entirely new files) the diff is 965K
04:56 <+Amaranth> dx: You have to clone mc-dev and CraftBukkit and generated a diff on top of mc-dev to get the numbers
04:57 < dx> Amaranth: fun!
04:57 <+Amaranth> If I toss the org.bukkit.craftbukkit package in there too the diff from vanilla is 1.8M
04:59 <+Amaranth> diff stat makes it look less scary: 485 files changed, 33033 insertions(+), 1483 deletions(-)
05:04 < dx> Amaranth: how about this http://ix.io/8Zm
05:05 < dx> i decided to take all the craftbukkit commits... since the commit logs weren't consistent, except the ones where evilseph updates pomf.xml
05:05 < dx> *pom
05:05 <+Amaranth> You're not measuring the right thing there
05:05 <+Amaranth> You're measuring diff from one version of CraftBukkit to another instead of measuring current vanilla->CraftBukkit diff
05:06 <+Amaranth> The only way you can do that is like I said and that's what I did
05:06 < dx> oh, i wasn't trying to measure that
05:06 <+Amaranth> Oh, you're trying to measure the code churn involved in doing a CraftBukkit update?
05:06 < dx> yup
05:07 < dx> which i just realized it's because i misinterpreted what you said before!
05:07 < dx> yay.
05:07 <+Amaranth> Hey look the top 3 are the ones I mostly did myself and were some of the fastest updates on record :D
05:08 < dx> :D
05:08 <+Amaranth> Although they all ended up with some delay due to my starting late
05:08 < skarlitz> Well imma go.
05:08 < skarlitz> Cya.
05:10 < dx> i like how it just takes 2.6 seconds to dump all the diffs of the whole repository
05:10 <+Amaranth> git is cool like that
05:10 <+Amaranth> It doesn't track renames and can be a PITA to use but holy shit is it fast
05:11 < dx> :D
05:14 < skarlitz> I actually had one last question. Anyone know how arrow arcing is calculated?
05:14 < skarlitz> arrow drop, I mean?
05:15 < dx> it has something to do with physics right
05:15 < dx> i studied that two years ago and successfully managed to forget everything about it
05:24 < skarlitz> Dern
05:24 < skarlitz> That seems to be a rather unexplored topic.
05:32 < skarlitz> Would the 1.2.5 deobfuscation be more thorough than the 1.6.4 deobfuscation?
05:33 < dx> MCP's? it's all the same
05:36 < skarlitz> Ah. I was thinking of poking around with the code and looking for the arrow's drop code
05:40 <+Amaranth> 1.6.4 is probably better for old stuff
05:43 < skarlitz> Do arrows just fire in a simple parabola? I'm not sure  what the formula would be
05:44 < skarlitz> It could be crazy simple or crazy complicated >.<
05:48 < Not-003> [MCPP] RobertLeahy pushed 10 commits to 1_7_protocol [+0/-1/±14] http://git.io/5N6RKA
05:48 < Not-003> [MCPP] RobertLeahy b4b7acf - RSA Public Key Handling Fix
05:48 < Not-003> [MCPP] RobertLeahy 5d1d7ec - Players Update
05:48 < Not-003> [MCPP] RobertLeahy b877758 - Authentication Update
05:48 < Not-003> [MCPP] RobertLeahy 63257fa - Command Line Front-End - Argument Parsing
05:48 < Not-003> [MCPP] RobertLeahy bb2e525 - Keep Alive Rewrite
05:48 < Not-003> [MCPP] RobertLeahy ee37177 - Chat Update
05:48 < Not-003> [MCPP] RobertLeahy 4acea33 - JSON Debug Display Change
05:48 < Not-003> [MCPP] RobertLeahy b68163e - Chat Fix
05:48 < Not-003> [MCPP] RobertLeahy 4a3bfc2 - Add Packets
05:48 < Not-003> [MCPP] RobertLeahy ee605f5 - Command Line Argument Parsing Fix
06:02 < Luqman> ah good old openssl with it's not confusing interface
06:03 < Drainedsoul> which part of its interface?
06:05 < Drainedsoul> Luqman: I have example code implementing every part of Minecraft encryption with OpenSSL, if you would like
06:06 < Luqman> Drainedsoul: i was referencing the changes above in "b4b7acf - RSA Public Key Handling Fix"
06:06 < Luqman> i2d_RSAPublicKey vs i2d_RSA_PUBKEY :P
06:07 < Drainedsoul> Luqman: Yeah it's pretty brutal.  There's a whole page of "documentation" on this functions that basically lists them, and then says "oh yeah they're like these other functions" ._.
06:07 < Drainedsoul> at least there's something built in to handle the SubjectPublicKeyInfo structure.  My impression from people talking in this channel is that getting public keys into/out of that structure in other languages requires a bit of a marathon
06:08 < Luqman> yea, i haven't gotten around to implmenting that yet
06:09 < Luqman> sounds like a fun can of worms :P
06:09 < Drainedsoul> It's a royal headache.  The worst part is that the wrappers I wrote for the OpenSSL functions are maybe 300-500 lines of code.  But it took days of chasing documentation to get it written.
06:10 < Drainedsoul> That's when you know your library has documentation issues.  When it takes days of sifting through the docs/googling to write 300-500 lines of code around it.
06:28 < lianj> Drainedsoul: for the basics the docs are ok though
07:46 <+Amaranth> OpenSSL matches every other crypto library people trust
07:46 <+Amaranth> The API is a mess, the documentation is a joke, and the code gives you nightmares
07:47 <+Amaranth> NSS documentation still talks about Netscape
11:35 < Not-003> [MCPP] RobertLeahy pushed 1 commit to 1_7_protocol [+0/-0/±1] http://git.io/GjeIFw
11:35 < Not-003> [MCPP] RobertLeahy c7fa99b - Column Serialization Fix
14:53 < WizardCM> damn ubuntu on openvz with its broken packages and inability to install python2.7-dev, meaning i can't try out mark2 :(
23:10 < skarlitz> So I was thinking of adding multiple protocol support to my program, and I was thinking, do you guys think that representing the versions in json files would work well? Here's an example of what I mean (And what I have in progress): http://pastebin.com/JD4T6Hr4
23:15 < iBotPeaches> wat.
23:15 < iBotPeaches> the protocol changed massively between 1.6 and 1.7
23:15 < iBotPeaches> trying to balance those at same time in full support, would be a waste of time
23:15 < skarlitz> I know that, but that has nothing to do with what I'm doing.
23:15 < iBotPeaches> Unless you need just ping support for a server-list
23:16 < skarlitz> No, I've seen Darkbot do it.
23:16 < skarlitz> Supports multiple protocols, so I'm working on that.
23:17 < iBotPeaches> Don't know about Darkbot, will have to google it
23:18 < skarlitz> https://github.com/DarkStorm652/DarkBot
23:19 < iBotPeaches> I dont see any 1.7.x in darkbot github
23:19 < skarlitz> It hasn't been implemented yet, the author's been busy.
23:19 < iBotPeaches> He will be maintaining both pre 1.7 and not :) (in my opinion, feel free to prove me wrong)
23:20 < skarlitz> Hm?
23:21 < skarlitz> Oh, yeah.
23:23 < skarlitz> I mean, I want to brainstorm a way to update in the easiest way possible
23:23 < Drainedsoul> Supporting old protocols seems like a waste of time
23:23 < skarlitz> Yes, but many operators keep 1.4.7. 1.5.2 1.6.4 servers, in addition to the already 1.7.2 server.
23:24 < Drainedsoul> that sounds like their problem
23:24 < skarlitz> No, it's my problem.
23:24 <+sadimusi> why?
23:24 < skarlitz> If I want to use my program on their servers, then it's a no go.
23:24 < skarlitz> Unless I do multi protocol.
23:24 < iBotPeaches> You just said they supported the newest
23:24 < skarlitz> I did? 
23:24 <+sadimusi> what does your program do?
23:24 < skarlitz> Sorry. 
23:25 < skarlitz> I just want to do multiprotocol. That's it. 
23:25 < skarlitz> It would be loads easier than just updating the entire program each time. 
23:26 <+sadimusi> I do multi-protocol in mc4p but plan to drop old versions when I finally update to 1.7
23:26 <+sadimusi> https://github.com/sadimusi/mc4p/blob/master/mc4p/messages.py
23:26 < Drainedsoul> well have fun with that.  It's going to be more complicated than just implementing a new packet parsing/seralizing stack.  Fields change around, so you're probably going to have to change the way the packets are actually used
23:27 < skarlitz> mc4p?  What's that?
23:27 <+sadimusi> Drainedsoul: that largely depends on what he uses the packets for
23:27 < skarlitz> And you could include a parsing stack with the protocol file.
23:27 < Drainedsoul> it says in the comments at the top of the file he linked
23:27 <+sadimusi> skarlitz: a proxy
23:28 < skarlitz> Darkbot's model of operation inspired my own, and so I plan to add multi protocol support, so that the program can support multiple protocols dynamically. 
23:29 < skarlitz> For my convenience.
23:29 <+sadimusi> you still haven't told us what you're actually building
23:29 <+sadimusi> or did I miss it?
23:29 < dx> sadimusi: he was here yesterday
23:29 < skarlitz> Oh, I might not have said. My own bot. 
23:32 < dx> skarlitz: if you really want to have multi protocol support, first implement 1.7, confirm that it works, then 1.6, have fun implementing the parser for every packet ever, confirm that it works, and then, at *that* point, think about making the 1.6 implementation more abstract
23:32 < skarlitz> Or I guess I did.
23:32 < skarlitz> Yeah, that'd be a good idea...
23:34 <+sadimusi> yeah, you definitely need two separate packet parsers and also handle field changes somehow
23:34 <+sadimusi> but it is certainly possible
23:35 < skarlitz> Well, you could include a new parser with each version. Then it could call methods from the parser?
23:36 <+sadimusi> there's really no need for that, you won't need a new parser for a few years
23:36 <+sadimusi> (probably)
23:36 < dx> (hopefully)
23:37 < iBotPeaches> (mc 2.0)
23:37 < dx> minecraft 2.0 does use a completely different protocol than 1.7
23:39 < skarlitz> Lol.
--- Day changed mar. nov. 12 2013
00:03 < skarlitz> So suppose I'm sending a Player Block Placement packet. How do I format this packet? It needs several different data types, so how do I put together these packets?
00:10 < Drainedsoul> skarlitz: What do you mean?
00:12 < skarlitz> A player block placement packet requires two ints, 1 unsigned byte, four bytes, and... a slot? Anyways, how do you format this and send it to the server?
00:13 < Drainedsoul> you just concatenate the encodings of those types
00:13 <+clonejo> and watch out for endianess
00:13 < Drainedsoul> also that
00:13 <+clonejo> slot is documented on the wiki
00:13 < Drainedsoul> network byte order is big endian
00:14 < skarlitz> What...
00:14 < skarlitz> Examples in Java? 
00:14 < Drainedsoul> endianness is the sub-word byte ordering.  An integer has 4 bytes, endianness is the order in which those bytes are sent.  Most significant first or least significant first.
00:16 < Luqman> but varints are little endian no?
00:17 < dx> it doesn't make sense to talk about endianness in varints
00:17 < Drainedsoul> ^
00:17 < dx> they are encoded byte by byte
00:18 < Luqman> sure, but you i mean in terms of which side you start from
00:18 < skarlitz> Uh..
00:18 < Drainedsoul> you don't encode varints by just copying bytes, so it doesn't make sense to talk about endianness.
00:18 < skarlitz> So like I said, how do you encode?
00:19 < skarlitz> Do you just get the byte values of each or...?
00:19 < Thinkofdeath> skarlitz: For java look at DataInput/Output
00:19 < Drainedsoul> http://wiki.vg/Data_types
00:20 < skarlitz> What makes a byte significant?
00:21 < Drainedsoul> http://en.wikipedia.org/wiki/Endianness
01:35 < skarlitz> Can somebody explain Endianness to me? Without referring me to Wikipedia? I don't get it.
01:36 < skarlitz> I read the article and I can't make sense of it.. er..
01:36 < Eviltechie> It's basically if the number is forward or backwards
01:37 < nickelpro> ^
01:37 < nickelpro> If the MSByte is first, it's Big-Endian
01:37 <+sadimusi> that's a bit oversimplified :D
01:37 < nickelpro> If the LSByte is first, it's Little-Endian
01:38 < nickelpro> Big Endian is "Forward" you can read it like you would numbers written out on a page
01:38 < nickelpro> Little Endian is "Backwards" the smallest numbers are stored first
01:39 < nickelpro> Java is big endian, so I don't think any of this really affects you
01:40 < skarlitz> Okay, thank you so much. 
01:40 < Drainedsoul> When a data type is larger than one byte, you have to pick some order to store the bytes in.  That's endianness.  If the bytes that come first (i.e. that have a lower address) are the most significant (i.e. have the largest numerical value) then it's little endian, otherwise it's big endian.
01:41 < skarlitz> There's been a lot of overcomplication. So basically just writing it in order normally? 
01:42 < skarlitz> Wait, what's an address? 
01:43 < skarlitz> " (i.e. that have a lower address)"
01:43 < Drainedsoul> an address, a location in memory
01:43 < nickelpro> Simplified: A memory address is where in you RAM your value is stored
01:44 < nickelpro> It's a number, just like your street address is a number
01:53 < skarlitz> Ah.
01:57 < skarlitz> Thanks.
02:01 < iBotPeaches> what goes up, never stops, and never goes backwards?
02:02 < nickelpro> iBotPeaches: Can boats fly now?
02:03 < iBotPeaches> nickelpro: next guess
02:04 < Eviltechie> helium
02:04 < iBotPeaches> your age :p
02:05 < Eviltechie> what if age is an integer
06:55 < Luqman> can i enable encryption on the vanilla minecraft server but disable authentication?
07:11 < Drainedsoul> Why would you want to do that
07:11 < Drainedsoul> (I'm pretty sure you can't)
07:12 < nickelpro> Luqman: Not with a normal server
07:13 < Drainedsoul> poor Luqman, no one answers for 16 minutes, then two answers within 2 minutes ._.
07:13 < Drainedsoul> funny how that works
07:15 < Luqman> Drainedsoul: well mostly cause i want to implement the encryption stuff bu don't want to have to deal with auth right now :P
07:15 < Drainedsoul> sounds like you should implement them in the opposite order
07:15 < Drainedsoul> what language are you using?
07:16 < Luqman> rust
07:16 < Drainedsoul> sounds like you're on your own when it comes to implementing that stuff.
07:23 < nickelpro> Just pushed the first stage of my 1.7 update, 1,685 additions 1,273 deletions
07:24 < nickelpro> I hated this update, let's not do it again
07:28 < Eviltechie> somebody was saying that 1.8 and 1.9 would be much worse
07:28 < nickelpro> Ah well, my implementation a hell of a lot more generalized now, probably for the better
07:29 < nickelpro> Still, I'll miss globally unique packet ids
07:34 < Drainedsoul> who was saying 1.8 and 1.9 would be worse?
07:35 < Eviltechie> I think it was Amaranth
07:35 < Drainedsoul> what was he basing that on?
07:36 < Eviltechie> Let me see if I can dig out the logs
07:38 < Eviltechie> Drainedsoul: http://sbnc.khobbits.co.uk/log/logs/old/spigot_%5B2013-11-03%5D.htm
07:38 < Eviltechie> ctrl +f [22:02:35]
07:40 < Drainedsoul> I think I saw him seeing something almost identical to that in here yesterday or the day before
07:40 < Drainedsoul> I assumed he was talking about the "development" that's basically just piling crap ontop of the Mojang code base
07:42 < dexter0> if there will not be an MCP 1.8, then MC 1.8 better be the API Update.
07:43 < Drainedsoul> I'd be more concerned about the fact that no MCP 1.8 would mean that you're stuck with the shoddy vanilla server
07:45 < nickelpro> For authentication with sessionserver, when the wiki says <selectedProfile> does it mean the dictionary with the profile ident and the profile name or just the profile ident on its own? http://wiki.vg/Protocol_Encryption#Client
07:56 <+Amaranth> Drainedsoul: There was a comment at the future of minecraft panel saying 1.7 had a lot of code churn and 1.8 and 1.9 would continue that trend
07:57 < nickelpro> For the Encryption Response, does 1.7 no longer use symmetric AES? why is the client sending a public key instead of a shared secret? http://wiki.vg/Protocol#Encryption_Response
08:00 < Drainedsoul> that packet is mislabeled
08:00 < Drainedsoul> nickelpro: ^
08:01 < nickelpro> Drainedsoul: Ah, thanks, was frightened for a moment
08:01 < nickelpro> I'll fix it
08:03 < Drainedsoul> Amaranth: I guess that depends where the code churn is.
08:03 <+Amaranth> Drainedsoul: Not for MCP
08:04 <+Amaranth> For third party implementations and modding in general where matters but MCP has to get all the names right
08:05 < Drainedsoul> Amaranth: I was just confused because Evilt*chie made a broad statement about 1.8/.9 being "worse".  I don't particularly care about MCP, or development based on the Mojang code at all.
08:08 < Not-003> [MCPP] RobertLeahy pushed 2 commits to 1_7_protocol [+0/-0/±3] http://git.io/vjalDA
08:08 < Not-003> [MCPP] RobertLeahy 08c02ad - Yggdrasil Update
08:08 < Not-003> [MCPP] RobertLeahy ef3533f - Vanilla Authentication Update
17:09 < Luqman> hmm, i'm getting a seemingly empty server id in the encryption request packet
17:15 < Thinkofdeath> Luqman: That would be correct
17:15 < Thinkofdeath> It is always empty now
17:16 < barneygale> really?
17:16 < barneygale> isn't that a security hole?
17:17 < Thinkofdeath> Don't think so
18:05 < Luqman> Thinkofdeath: what key strength and cipher mode does minecraft use with aes?
18:06 < Thinkofdeath> cfb8-aes, not sure about the key strength
18:07 < Luqman> seems like it's 128 from some googling
18:09 < Thinkofdeath> The private key is 1024bit, the shared key is 256 (i think)
18:10 < Luqman> isn't the shared secret 16bytes ?
18:11 < Thinkofdeath> Oops yeah
18:13 < Thinkofdeath> Doesn't look like there is a limit for it though
19:23 < Drainedsoul> Luqman: AES 128 CFB 8, so 128 bit shared secret.  1024 bit RSA for the public/private key encryption
19:32 < Luqman> Drainedsoul: sweet, thanks.
20:49 < Luqman> Drainedsoul: do you know if it's PKCS padding?
20:50 < barneygale> Luqman: it is
20:52 < Luqman> barneygale: thanks
21:36 < Luqman> hmm did barneygale mean PKCS for the rsa key?
21:36 < Luqman> because i was asking about aes and it seems like minecraft wants AES/CFB8/NoPadding
21:38 <+clonejo> Luqman: the AES/CFB stream doesn't have any padding
21:39 <+clonejo> each byte is encrypted individually
21:39 < Luqman> clonejo: yea, finally realized what cfb8 meant :P
21:40 < Luqman> and that makes my life much easier
--- Day changed mer. nov. 13 2013
00:43 < Luqman> sweet, made some nice rsa and aes wrappers in rust https://gist.github.com/luqmana/8a93b7ea349b732cbda0
00:52 <+clonejo> nice
00:53 <+clonejo> What's your thought on putting a proper license on that?
00:55 < greymerk> Drainedsoul says everything should be unlicensed
00:56 < iBotPeaches> Drainedsoul: LOL
00:56 < Luqman> clonejo: the bindings/wrappers?
00:56 <+clonejo> greymerk: As everyone loves reiventing the wheel.
00:56 < greymerk> if the wheel didn't get reinvented it'd still be a log
00:56 < iBotPeaches> greymerk: it'd be a square :)
00:57 < Luqman> well in my defense, there wasn't any preexisting stuff in rust :P
00:57 <+clonejo> Luqman: yes, but you're going to use it in your chat client anyway, aren't you?
00:58 < Luqman> well it's pretty standalone. you can just drop crypto.rs in and use it
00:59 <+clonejo> I somehow thought mcchat had an oss license, sry
00:59 < Luqman> haha well it probably will if i ever come around to licensing it
01:00 <+clonejo> I'll bug you when I want to use it for my server :D
01:03 < Luqman> feel free to :D
01:08 <+clonejo> okay
02:08 < Luqman> hmm does the server always make the key and iv the same (i.e the shared secret) ?
02:08 <+clonejo> iirc, yes
02:09 < Luqman> isn't that against best practices?
02:11 <+clonejo> it might be better to send different key and iv at encryption initialization
02:15 <+clonejo> 2^128 combinations still seem pretty hard to brute-force
02:16 <+sadimusi> clonejo: that's not really the point
02:17 <+sadimusi> but all it does is reduce the number of aes rounds for the first byte to 8 (iirc)
02:18 <+sadimusi> which isn't such a big deal
02:20 < Luqman> i thought that in certain situations the iv can be leaked
02:20 < Luqman> and hence if you have your key == iv then you're screwed
02:21 <+sadimusi> I can'r think of a situation where the iv is leaked
02:21 <+sadimusi> but then again, I'm not a crypto expert
06:19 < Luqman> hmmm, which is accurate? http://wiki.vg/Authentication or http://wiki.vg/Protocol_Encryption
06:41 < Drainedsoul> Luqman: Accurate in which regard?
07:07 <+pdelvo> @Luqman both are correct. the Authentication page is about the client talking to mojang servers on loging in to the game. Protocol Encryption is about logging in to a server
09:07 < Luqman> the accessToken i send to https://sessionserver.mojang.com/session/minecraft/join should be the one i receive from /authenticate right?
09:12 < Luqman> well that's a sucky error, turns out selectedProfile should be the uuid not the username
10:21 < Luqman> so close..
10:24 < Luqman> i don't seem to be getting Login Success after sending the encrpytion response
10:47 < Luqman> Drainedsoul: any idea?
10:57 < Thinkofdeath> Luqman: What are you getting instead?
11:00 < Luqman> Thinkofdeath: nothing consistent
11:02 < Thinkofdeath> Login sucess/disconnect will be encrypted at that point
11:02 < Thinkofdeath> Maybe your encryption code is wrong?
11:02 < Thinkofdeath> Luqman: ^
11:02 < Luqman> "Similarly, the client will also enable encryption upon receipt of Login Success."
11:02 < Luqman> that seems to suggest otherwise
11:02 < Luqman> but i can try decrypting first
11:03 < Thinkofdeath> Where does it say that?
11:03 < Thinkofdeath> http://wiki.vg/Protocol#Login is more up to date on the process
11:04 < Luqman> it says that at http://wiki.vg/Protocol_Encryption#Symmetric_Encryption
11:05 < Thinkofdeath> http://wiki.vg/index.php?title=Protocol_Encryption&diff=5183&oldid=5170 Fixed
11:11 < Luqman> yay, i get further now :D
11:12 < Thinkofdeath> \o/
11:15 < Luqman> hm, but now it fails when i try to respond to keep alives..
11:16 < Thinkofdeath> Are you sending back the same number you received?
11:17 < Luqman> problem seems to be with encryption
11:18 < Luqman> how does the vanilla server do the encryption/decryption? does it the same context for the whole session?
11:19 < Thinkofdeath> The encryption side isn't really my strong point, maybe someone else can help
11:22 < Luqman> fixed it :)
11:23 < Thinkofdeath> Nice :)
11:24 < Luqman> just needed a few calls to EVP_EncryptFinal_ex
11:26 < Luqman> well since i've now got encryption working i guess i should do the auth better
11:27 < Luqman> calling the curl binary is the best way to do things :P
11:27 < zutto> its not hard to do it completly yourself ;l
11:28 < zutto> http protocol is very simple
11:29 < Luqman> yea, i just wanted something that worked so i could test my encryption stuff
12:05 < Luqman> so now i've got a branch that also works with online-mode=true, i think it's time for bed
18:34 < TheUnnamedDude> Is there any changes for the datatype slot in 1.7 ?
18:34 < TheUnnamedDude> Thats not on the wiki
18:37 < TheUnnamedDude> Pardon for being stupid, Entity metadata *
18:37 < Thinkofdeath> The string is utf8 instead of utf16 (like the rest of the protocol now)
18:39 < Thinkofdeath> I think that is all that changed
18:39 < TheUnnamedDude> :/
18:43 < TheUnnamedDude> Its an unsigned byte, that would explain my problem :/
18:43 < TheUnnamedDude> Thanks
18:43 < TheUnnamedDude> the "item" value
18:43 < Thinkofdeath> :)
21:17 < nickelpro> What name is used for the Login Start "Name" string? The profile name or the actual username used to login?
21:19 < Luqman> seems like profile name
21:20 < nickelpro> Ya that makes sense
23:24 < Drainedsoul> zutto: Calling libcurl is definitely easier and more consistent than rolling your own HTTP, I don't know why you would suggest rolling your own HTTP.
23:24 < Drainedsoul> zutto: Do you really think that programming your own implementation, including handling Location headers et cetera, is easier and less error prone than just reading the libcurl documentation?
23:24 < zutto> own is always your own
23:25 < zutto> and it might be just my bad habit, but i tend to write almost everything i use myself
23:25 < zutto> from http servers to http crawlers
23:26 < SinZ> if everyone reinvents the wheel, the wheel would still be square
23:26 < iBotPeaches> if you were going to use a database, would you make your own or use one?
23:26 < zutto> depends whats the purpose of that database
23:27 < Cabraca> wrong answer ... there are plenty of db implementations out there ... just pick one that fits your needs
23:27 < zutto> if i am doing it for client, i wont be using my own database, but most likely if i'm doing some hobby project just for fun theres very good chances i'd be using my own database
23:27 < zutto> yes, theres all kinds of flavors of that
23:27 < zutto> i just tend to follow the suckless philosophy when i am doing something, and i havent found single database that would be within those rules
23:27 < iBotPeaches> I watched a lot of videos on RethinkDB yesterday
23:27 < zutto> except plain old file system hierachies
23:28 < zutto> can i go now?
23:28 < zutto> or do you have more fancy arguments to throw against me?
23:28 < iBotPeaches> lol
23:29 < SinZ> do you by chance, do everything on your own OS?
23:29 < zutto> thats one thing i havent done :P
23:29 < zutto> i'm stuck with linux, but i do quite alot developement on p9
23:29 < zutto> just cause acme is awesome
23:29 < zutto> and limbo is fun times
23:30 < zutto> you guys should take a look on plan9 too, its good platform to scale minecraft server without spending too much effort :P
23:30 < zutto> anyhow
23:30 < zutto> i'm off ->
23:37 < Luqman> Drainedsoul: i did use libcurl, i literally called out to /usr/bin/curl :P
23:37 < Luqman> didn't*
23:43 < Drainedsoul> Luqman: Wtf
23:43 < Luqman> details details :P
23:44 < Luqman> but first i need to write something to better handle json
23:44 < Luqman> and perhaps libcurl bindings
--- Day changed jeu. nov. 14 2013
00:28 < Drainedsoul> Luqman: Needs libcurl bindings, just calling /usr/bin/curl isn't enough.  What happens if it isn't present?
00:29 <+AndrewPH> cry
00:29 < Luqman> hehe well i'm pretty much the only person running this and i can install curl if i need to :P
00:30 <+AndrewPH> it's the only options
00:30 < iBotPeaches> give up or cry are the only ones i see
00:31 < bb_> is my chat broken or is noone talking?
00:31 < bb_> hello?
00:31 < bb_> echo
00:31 < bb_> MARCO
00:32 < bb_> no response. ok.
00:33 <+sadimusi> bb_: pong
00:33 < bb_> ping! =)
00:36 < nickelpro> Yay! My client fully support 1.7! And all it took was a complete rewrite of my packet decoder...
00:38 < Drainedsoul> nickelpro: Rewriting stuff is always fun.
00:39 < nickelpro> It's actually a lot better for it, I had been piggy backing off of Barney Gale's protocol implementation for a long time
00:42 < Drainedsoul> nickelpro: Yeah, I've been rewriting a lot of things lately that weren't up to snuff (imo).  Feels good.
00:45 < Drainedsoul> So, if during the login/authentication process, you don't send the user a disconnect, you just close their socket, the client sits there forever at "Logging in..."?
00:46 < iBotPeaches> Drainedsoul: The client has a timeout, doesn't it??
00:46 < Drainedsoul> I'll test again
00:50 < Drainedsoul> it's been two minutes and it's still sitting there
00:50 < Drainedsoul> TcpView.exe confirms that there's no open connection between the client and server, it's definitely dead
00:58 < nickelpro> bug?
00:58 < nickelpro> If the client tries to connect to a server and the server dies, client would stall
01:04 < Drainedsoul> client is still stalled.  Has been 16 minutes now.
01:04 < Drainedsoul> server didn't even die.  Server actually shutdown and then closed the socket.
01:37 < Not-003> [MCPP] RobertLeahy pushed 7 commits to 1_7_protocol [+2/-1/±15] http://git.io/VRjClQ
01:37 < Not-003> [MCPP] RobertLeahy f53761d - Command Overhaul
01:37 < Not-003> [MCPP] RobertLeahy c966a3b - Information Update
01:37 < Not-003> [MCPP] RobertLeahy eed461e - Information Providers Update
01:37 < Not-003> [MCPP] RobertLeahy 5931d96 - HTTP Handler Cleanup
01:37 < Not-003> [MCPP] RobertLeahy 98c4314 - HTTP Handler - Max Redirects
01:37 < Not-003> [MCPP] RobertLeahy d5e3ea4 - HTTP Handler Error Message Capture
01:37 < Not-003> [MCPP] RobertLeahy f92f64c - Authentication Module Debugging Update
01:41 < Drainedsoul> what's the format of the JSON data that's sent in the clientbound login disconnect packet?
02:16 < lsdev> nickelpro, i was looking at your bot framework called "spock" and needed some help setting it up
02:17 < nickelpro> lsdev: sure, what's up?
02:18 < lsdev> I was trying to run the demo script but i kept getting an error about "ImportError: No module named plugins.defaults"
02:18 < lsdev> I have used python abit but not a crazy amount
02:18 < lsdev> I am using python 3.1
02:19 < nickelpro> lsdev: Sorry I just finished the 1.7.2 update, probably broke the demo, brb
02:19 < lsdev> ah ok :)
02:19 < lsdev> That was the main thing i was interested in (1.7.2 client)
02:19 < lsdev> I noticed the commit an hour ago so I figured some stuff would be broke :P
02:27 < nickelpro> lsdev: pull the latest commit, demo should work now
02:27 < lsdev> thanks
02:27 < nickelpro> Sorry, I don't use the demo personally so much :-P
02:28 < lsdev> yea i figured
02:28 < lsdev> now does this support session auth?
02:28 < lsdev> or only offline mode
02:28 < nickelpro> lsdev: Both, the demo assumes online mode actually
02:29 < lsdev> thats perfect for what i need
02:29 < lsdev> thanks again
02:29 < nickelpro> lsdev: No problem, Spock'
02:29 < nickelpro> s pretty rough though
02:30 < nickelpro> feel free to ask about anything
02:31 < lsdev> argh
02:31 < lsdev> now i am getting another error when i try to build it
02:31 < lsdev> error: package directory 'spock/net/plugins' does not exist
02:31 < lsdev> Guessing i should just mkdir that?
02:42 < Drainedsoul> I guess it doesn't particularly matter what kind of JSON you send in the disconnect packet during login.  Either it's right and the client stops logging in and does something, or it's wrong and the client stops logging in.  Either way it works around Mojang's bug under the specific circumstance where the server disconnects the client
08:36 < Thinkofdeath> Drainedsoul: It should be the same as used in chat messages
08:40 < Drainedsoul> Thinkofdeath: THanks I'll try that
18:39 < AlJaMa> does anyone know why it would be that on 1.7.2, when I spawn a player, regardless of where I set the spawn point and the first SetPos packet, the player still spawns at 0,0,0?
18:40 <+clonejo> AlJaMa: the player's position is changed using http://wiki.vg/Protocol#Entity_Teleport
18:41 < AlJaMa> clonejo: Thank you, I was unaware that I should use that even with the current player
18:41 < AlJaMa> (thought it was only for other entities in the world)
18:42 <+clonejo> The spawn point merely changes the direction compasses point at.
18:44 < AlJaMa> clonejo: oh yes, though I was trying to send PlayerLookAndPos
18:44 < AlJaMa> because you have to send that anyways to spawn the client.
18:53 < AlJaMa> clonejo: interesting, now that I send that teleport packet, the player shows up in the right spot, but the block they are looking at is wrong. (IE: when i try to dig, it digs the block straight below me)
18:54 <+clonejo> AlJaMa: there's a block selection bug when you spawn exactly at (0,y,0)
18:54 <+clonejo> that might be the problem
18:54 < AlJaMa> hmm is there a tracker number on that?
18:55 < AlJaMa> (something I can look up?)
18:55 < Thinkofdeath> Entity teleport shouldn't be used to move the client (didn't realised it even worked)
18:55 <+clonejo> AlJaMa: idk, could be that bug has been fixed
18:56 < AlJaMa> Thinkofdeath: ya, it seems to have very weird effects, though it will work.
18:56 < Thinkofdeath> http://wiki.vg/Protocol#Player_Position_And_Look <- That is what should be used
18:56 < AlJaMa> for whatever reason setPos is not working for my client (vanilla) upon first logging in.
18:56 <+clonejo> hm, maybe I mixed both up
18:57 < AlJaMa> it works after that, but I send chunks,  then I sent player_pos_and_look to spawn the player, and regardless of values, it will always spawn at 0,0,0
18:57 < Thinkofdeath> https://github.com/NetherrackDev/netherrack/blob/master/entity/player/player.go#L145 works for me
19:09 < AlJaMa> hmmm perhaps it's something with the endian-ness of my floats...
20:29 < AlJaMa> Thinkofdeath: you're byte flipping your floats correct?
20:29 < Thinkofdeath> same int32s
20:30 < AlJaMa> ya so you're flipping int64/double and int32/float
20:30 < AlJaMa> ok... I'm not crazy :P
21:44 < marmot21> test
21:46 < marmot21> hey, anyone an expert on mc protocols?
21:46 < marmot21> trying to figure out what the proper value for setting experience is
21:47 < Thinkofdeath> marmot21: http://wiki.vg/Protocol#Set_Experience using this?
21:49 < marmot21_> grr, it seems to sign me out or something when I change tabs...
21:50 < marmot21_> anyway, yeah I'm looking at that
21:50 < Thinkofdeath> Which part is the bit your having an issue with?
21:52 < marmot21_> in the revision history it has 0x2B and it doesn't say when the value changed
21:53 < marmot21_> I'm writing for the c++ MC server and implementing that function, in 1.2 0x1F is something completely different...
21:54 < Thinkofdeath> You mean the packet id?
21:54 < Thinkofdeath> in 1.7 all the ids changed
21:54 < marmot21_> yeah yeah
21:54 < marmot21_> ah ok
21:55 < marmot21_> so prior to that it was 0x2B, ok thats easy
21:55 < Thinkofdeath> A lot changed in 1.7
21:56 < Thinkofdeath> Packets got a length prefix, packet id isn't a byte anymore etc
21:57 < marmot21_> the actual field names don't get transmitted though right? is it the order they are in the packet
22:00 < Thinkofdeath> marmot21_: yes
22:01 < marmot21_> ok sweet, thanks for yr help :)
22:02 < Thinkofdeath> np
22:10 < TheUnnamedDude> Hi Guest28360 
--- Day changed ven. nov. 15 2013
02:46 < jj2baile> Sabriel: Luqman: Hey there sailors
02:46 < Sabriel> woah
02:46 < Sabriel> hi
02:47 < Sabriel> this was an old haunt of mine
02:47 < jj2baile> =P And ever lurking are you
02:51 < Luqman> jj2baile: hi
02:51 < Luqman> why does the name Sabriel seem so familiar
02:52 < Sabriel> Luqman: I'm sharvey
02:52 < jj2baile> Because you know who it is dumbdumb :p
02:52 < Luqman> oh!
02:53 < jj2baile> hmm so trying to make my bot move by manually typing in the bytes was both painstaking and ineffective
02:53 < Sabriel> oh you got a client working?
02:53 < jj2baile> :P well it was "working" for a while/
02:53 < Sabriel> haha
02:54 < jj2baile> but chat messages werent working. AFter a while I realized instead of keep alive, I was just sending the random int
02:54 < jj2baile> thanks to accidentally the wrong function call
02:54 < jj2baile> But for the most part despite this my bot would stay properly connected for hours, doing no more than this almost keepalive
02:56 < Sabriel> hahaha
02:56 < Sabriel> sweet
02:56 < Sabriel> jj2baile: what is your client written in?
02:56 < Luqman> haskell
02:56 < Sabriel> haha
02:58 < jj2baile> awww, I was gonna try to make her guess
02:58 < jj2baile> Luqman: what a jerk
02:59 < jj2baile> But yeah, I apparently decided I would tackle learning haskell. It at least keeps my interest more than python
02:59 < jj2baile> well really, it was a coin flip between haskell and rust.
03:01 < jj2baile> clearly I should have followed the traditional motif and done it in arm assembly or something.
07:19 < Not-003> [MCPP] RobertLeahy pushed 2 commits to 1_7_protocol [+6/-0/±4] http://git.io/g-oCZw
07:19 < Not-003> [MCPP] RobertLeahy 3c42960 - Formatting Fix
07:19 < Not-003> [MCPP] RobertLeahy b17911e - Permissions
08:05 < Drainedsoul> the payloads for the REGISTER and UNREGISTER plugin messages, UTF-16 or UTF-8 now?
08:16 < SinZ> all strings in 1.7 are UTF-8
08:31 < Drainedsoul> SinZ: Thanks
08:31 < Drainedsoul> What's the client's reaction when it gets sent a plugin message it's not registered for?
08:32 < Thinkofdeath> Drainedsoul: Ignores it
08:33 < Drainedsoul> Thinkofdeath: Are you serious?  It doesn't just crash?
08:33 < Thinkofdeath> Yep
08:33 < Drainedsoul> This is a big step forward for Mojang.
08:33 < Thinkofdeath> Most users of that channel don't even register it
08:33 < Thinkofdeath> *that packet don't even register the channel
08:34 < SinZ> there is a reason why people suggest to use plugin channels rather than just random packet ID's
--- Day changed sam. nov. 16 2013
03:28 < dividuum> how does the minecraft client decide if the helmet part of the skin is transparent when the image is RGB (as opposed to RGBA)?
03:29 <+AndrewPH> I think it's the top right hand corner's color becomes transparent in the head layer (have not tested, probably shouldn't listen to me)
03:30 < dividuum> hm. ok :}
03:30 < dividuum> i'll test that. thanks
03:32 <+AndrewPH> If it's not that, then it might just ignore the head layer if there are no transparent pixels
03:35 < dividuum> that's sound like a saner way to do this actually
03:35 < dividuum> *sounds
18:53 < dividuum> looks like the s3 servers are still overloaded from the music update %)
22:45 <+md_5> dividuum its f*** annoyin
22:48 < dividuum> hu?
22:48 < dividuum> oh. you mean the music not updating?
--- Day changed dim. nov. 17 2013
01:15 < iBotPeaches> sadimusi: unless you really like loosing 8lbs, your twitter is spamming again
15:37 <+sadimusi> iBotPeaches: I noticed :/ guess I have to consider that password compromised
21:09 < umby24> SirCmpwn: Do Craft.net servers really hold the entire world in memory?
21:09 <+SirCmpwn> please contact me in #craft.net, I have a +q here (though it's obviously ineffective)
21:09 < umby24> ok.
21:13 < Krenair> huh, why does he have +q?
23:22 < Not-003> [Craft.Net] SirCmpwn pushed 1 commit to 1.7.x [+0/-0/±3] http://git.io/Q5LXlg
23:22 < Not-003> [Craft.Net] SirCmpwn eefc358 - Move packet IDs out of packet structs and modify ID logic
23:31 <+pdelvo> SirCmpwn are you aware that your varint implementation doesnt work for negative values?
23:31 <+SirCmpwn> please contact me in #craft.net, I have a +q here (though it's obviously ineffective)
--- Day changed lun. nov. 18 2013
00:30 < Not-003> [Craft.Net] SirCmpwn pushed 1 commit to 1.7.x [+0/-0/±4] http://git.io/0QsShQ
00:30 < Not-003> [Craft.Net] SirCmpwn 681d75f - varints are actually up to 28 bits long
02:15 < Eviltechie> Which packet deals with itemstacks, specifically lore
02:15 < Eviltechie> For both 1.6.4 and 1.7.2
02:23 < redstonehelper> Eviltechie: this could help: http://wiki.vg/Slot_Data and http://minecraft.gamepedia.com/Player.dat
02:26 < Eviltechie> Yes, yes those could.
02:26 < Eviltechie> Thanks
08:00 < TkTech> Momentary downtime on the wiki coming up.
08:09 < TkTech> Upgrade done, wiki back up.
16:34 < TheUnnamedDude> https://gist.github.com/thinkofdeath/6927216
16:35 < TheUnnamedDude> How is multiline motd's sent?
16:35 < Dinnerbone> For the record, "description": {"text":"Hello world"} is the same as "description": "Hello world"
16:36  * Dinnerbone nitpicks
16:37 < TheUnnamedDude> Well, that would make it more clean
16:45 < TheUnnamedDude> Just tested a bit, normal newlines, right?
18:26 < mathuin> So I'm trying to get Bravo to work with the latest protocol.  I wrote a fake client to prod the vanilla server to collect some information about the protocol changes, and made some good progress.  I've had some limited success moving that knowledge over to Bravo.  My current puzzle: right now, Bravo sends the client the chunk on which it stands, the player-position-and-look packet, and four surrounding chunks before the client disconnects.  I'm not sure
18:26 < mathuin>  how many of those packets the client has received and considers valid.  I went to the Protocol FAQ to make sure I understand how the login sequence works, and saw that it was out of date for 1.7.  Can someone who understands the login process for 1.7 help me understand what's going on?
18:36 <+clonejo> Anyone up for 30C3? Ticket sale just started.
18:40 < mathuin> Bah, the -Dlog4j.configurationFile=fullpathtoconfigfile.xml trick apparently no longer works on the client.
18:50 < Thinkofdeath> mathuin: Works fine here
18:51 < mathuin> Do you use MagicLauncher, or the stock launcher?
18:51 < Thinkofdeath> stock
18:52 < Thinkofdeath> Dinnerbone: I put "description": {"text":"Hello world"} there to show that it worked like chat (json style colouring) instead of having to use the old color codes
18:53 < Thinkofdeath> Saddly most still use the color codes
18:57 < mathuin> Thinkofdeath: on Ubuntu I used the example configuration file in "/home/jmt/debugconfigfile.xml" and ran the launcher via "java -jar Downloads/Minecraft.jar -Dlog4j.configurationFile=/home/jmt/debugconfigfile.xml".  is there something I'm not understanding?
18:57 < Thinkofdeath> mathuin: http://wiki.vg/images/e/e1/ClientDebugging.png
18:57 < Thinkofdeath> In the jvm arguments part
18:58 < mathuin> Oh, okay!
22:03 <+sadimusi> some servers only answer to ping requests if I use the correct protocol version :/
22:05 < barneygale> sadimusi: I think md_5 said spigot would do that, but vanilla doesn't care
22:05 < barneygale> it doesn't make much sense to me though
22:05 <+sadimusi> it makes none to me
22:06 <+sadimusi> there's absolutely no way to reliably ping such a server
22:07 <+sadimusi> lets just hope it changes before another public update is released
--- Day changed mar. nov. 19 2013
15:37 < ellisvlad> Am I the only one who always screws up their code forgetting Z is not the verticle axis :P
15:46 < JonasOSDever> Nope, you aren't :p
15:47 < Flemmard`> think we all went through that
16:00 <+Prf_Jakob> heh some people grew up on OpenGL so its not that hard.
16:00 <+Prf_Jakob> Tho the Z+ being forward fucks me up.
16:00 <+Prf_Jakob> Compared to Z-
16:02 < ellisvlad> :P
16:03 < ellisvlad> "Fix stairs placement" has been on my todo list forever! Finally got around to it :D http://puu.sh/5n41l.jpg ... had the y and z the wrong way in code :P
16:05 < ellisvlad> ...may aswell do slabs, torches, fencegates, etc. now
16:51 < Flemmard`> ellisvlad: basically everything so .. :P
--- Day changed mer. nov. 20 2013
02:58 < Not-002> [node-minecraft-protocol] zuazo pushed 2 commits to master [+0/-0/±16] http://git.io/ybypSg
02:58 < Not-002> [node-minecraft-protocol] Darthfett 9b274df - Cleanup: terminate all statements with semicolons, remove unnecessary semicolons, remove unused variables, add hasOwnProperty checks in 'for x in y' loops.
02:58 < Not-002> [node-minecraft-protocol] zuazo 63dea28 - Merge pull request #68 from Darthfett/master Cleanup code
04:01 < skarlitz> Would using a queue to handle packets to be sent be efficient? 
04:03 <+clonejo> skarlitz: You might utilise the io buffering your OS does.
04:04 < skarlitz> Okay, thanks. So... Like, a bufferedstream?
04:04 <+clonejo> no, I meant using flush() in sensible locations
04:05 < skarlitz> Ah.
04:06 < skarlitz> But what I mean, is like this? http://docs.oracle.com/javase/tutorial/essential/io/buffers.html
04:07 <+clonejo> nope
04:07 < skarlitz> Oh, what do you mean? Please point me to something.
04:07 <+clonejo> anytime you write to a file or a network stream, your operating system puts in into a buffer
04:09 <+clonejo> It does that in order to merge (for tcp) many small packets into a few big packets.
04:10 <+clonejo> Afaik io buffers are usually some kB in size.
04:12 <+clonejo> So the OS under a MC client might stack up seconds of player movement packets until the buffer finally fills up and they're all sent off in a big tcp packet.
04:12 < skarlitz> For now I've taken to looking at other projects and seeing it did it. Darkbot used Queues (as in, from Collections framework) to handle constructed packets and send them.
04:12 < skarlitz> Oh, I see.
04:12 < skarlitz> So it just stacks.
04:14 <+clonejo> I'm not sure about this, but you might want to send of each (MC) packet to the OS in one call, to reduce context switches.
04:14 <+clonejo> but that's a detail design question and can be changed later on
04:15 < skarlitz> Yup. So anyways, my idea for packet stacks. 
04:15 <+clonejo> ?
04:15 < skarlitz> Okay so, as I said before, I wanted to have multi protocol support. So what I was thinking, is that each packet stack could expose a basic API for world interactions, etc. 
04:16 < skarlitz> Like, break(x,y,x), all that. It would leave all networking to the packet handler, so you could switch between them as you please.
04:17 <+clonejo> You might want to split the protocol features into several interfaces.
04:17 < skarlitz> What do you mean?
04:18 <+clonejo> Every version of the protocol implementes different features.
04:19 <+clonejo> If a minimal interface is what you want, go ahead.
04:21 < skarlitz> True enough, but in its core, Minecraft has basic interactions, like turning, walking, opening an inventory, hitting an entity, etc. These things are never removed from the game. While their packets might be changed, the actual thing you're doing doesn't change. So just have an API of sorts for each protocol handler, handling the most basic interactions, and leave packets and such to the protocol handler. You could hot-swap protocol handlers as you go to 
04:21 < skarlitz> different servers. 
04:22 <+clonejo> Sure, that's what I meant by "minimal interface".
04:23 < skarlitz> Yeah! It'd work great. 
04:23 < skarlitz> Well, so I hypothesize. 
04:23 <+clonejo> xD
04:23 < skarlitz> Yeah, that's the problem with "Easier said than done"
04:23 < skarlitz> xD
04:24 <+clonejo> You will have to translate block ids (and their metadata)
04:25 < skarlitz> Not particularly, at least, for a bot. The only blocks you might be interested in are the main ores, wood, chests, lava, and water.
04:25 < skarlitz> Those don't change much,afaik
04:26 < skarlitz> By the way, I understand that wiki.vg has earlier protocols documented and such, but it only shows changes between protocols. Is there a full documentation I can access for each protocol version that's all on one page? I tried using the Wayback machine but I'm afraid it doesn't take many snapshots of wiki.vg.
04:26 <+clonejo> There is Burger Vitrine: http://b.wiki.vg/
04:27 <+clonejo> It's not (yet) up-to-date with 1.7, though.
04:29 < skarlitz> Any changes between 1.6.2 and 1.6.4?
04:30 <+clonejo> idk
04:30 < skarlitz> Well see, I wanted all the packets laid out before me like it does on wiki.vg/Protocol . However, it only lays out the packets for the most recent release, but I want the packets laid out before me in previous releases as well, in the same format.  
04:31 < skarlitz> All I would need is an archived copy of the Protocol page back when it was 1.6.4
04:31 < skarlitz> Along with other protocols. 
04:32 <+clonejo> there is a protocol history page listing dates, version numbers and changed packets
04:33 <+clonejo> you could combine that with old revisions of the protocol page
04:34 < skarlitz> The "view history" button might do some good.
04:35 < skarlitz> http://wiki.vg/index.php?title=Protocol&oldid=4899
04:35 < skarlitz> Aha, found it.
04:36 <+clonejo> I'm off for some sleep, have a good night! (or day, wherever you are)
04:37 < skarlitz> Goodnight!
08:31 < Drainedsoul> skarlitz: With respect to using a queue for packets, you'd have to tell us more about your hypothetical scheme for it to be decided whether it's a good approach or not
--- Day changed jeu. nov. 21 2013
10:31 < Not-002> [MCPP] RobertLeahy pushed 6 commits to 1_7_protocol [+5/-0/±8] http://git.io/uNmjSw
10:31 < Not-002> [MCPP] RobertLeahy 97cfb70 - Chat Fix
10:31 < Not-002> [MCPP] RobertLeahy a8b48c1 - Permissions Command Improvements
10:31 < Not-002> [MCPP] RobertLeahy 4877f29 - Serializer
10:31 < Not-002> [MCPP] RobertLeahy 1a96393 - Save Manager
10:31 < Not-002> [MCPP] RobertLeahy 9c775cd - Permissions Update
10:31 < Not-002> [MCPP] RobertLeahy 7268f12 - Packet Update
10:45 < Not-002> [MCPP] RobertLeahy pushed 1 commit to 1_7_protocol [+0/-0/±1] http://git.io/osfuYA
10:45 < Not-002> [MCPP] RobertLeahy 0b5108d - Forgotten #pragma once
17:39 < iBotPeaches> new snapshot :o
19:22 < Thinkofdeath> http://wiki.vg/Pre-release_protocol#13w47c No protocol changes 
19:29 <+sadimusi> phew, I feared the protocol version would change
19:31 <+ammar2> https://twitter.com/Dinnerbone/statuses/403542720079495168
19:33 < Thinkofdeath> I guess that makes 13w47c the 1.7.3 prerelease 
19:48 < Thinkofdeath> Grum: Don't suppose you would know why this happens in the snapshot? https://gist.github.com/thinkofdeath/26f2bd8eb9369185aa59 
19:48 < Thinkofdeath> Happens after closing the game
19:55 <+ammar2> Stack: [0x000000000e8c0000,0x000000000e9c0000], sp=0x000000000e9bf160, free space=1020k
19:55 <+ammar2> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
19:55 <+ammar2> C [twitchsdk.dll+0x45d9a]
--- Day changed ven. nov. 22 2013
03:43 < mappum> is there any demand for a service that stress-tests servers? (to estimate how many players your server can handle)
03:46 < Fenhl> mappum: that would be handy, pretty sure
04:02 < Eviltechie> mappum: pycraft
08:41 < AlJaMa> Hey guys, I've been trying to set the block type from server to client with 0x23 following the protocol http://wiki.vg/Protocol#Block_Change. Unfortunately no luck. I can verify that the packet is sent, but the block is not changed :(. For testing I am simply setting all fields = zero and trying to change a previously transmitted block to air. 
08:41 < AlJaMa> am I missing something?
08:42 < AlJaMa> perhaps I must send a "Block Break Animation" first? (though that wouldn't make much sense....?
09:42 < AlJaMa> please ignore previous question :) my endian-ness was wrong on my fields 
21:07 < nickelpro> "The server does not send skylight information for nether-chunks, it's up to the client to know if the player is currently in the nether. You can also infer this information from the primary bitmask and the amount of uncompressed bytes sent. "
21:07 < nickelpro> Can someone explain how I might infer that?
21:08 < Thinkofdeath> nickelpro: I think dav1d added that part, ask him if he is around
21:10 < nickelpro> I think I get it, multiply the size of a chunk by the number of chunks sent, if its less than the uncompressed data, skylight has been sent
21:10 < nickelpro> Just want to make sure I get the size/math right
21:12 < dav1d> correct
21:13 < nickelpro> dav1d: thanks, any chance you know off the top of your head the size of a chunk in bytes?
21:14 < nickelpro> 16*16*16 for block ids + 16*16 for block meta + 16*16 for block add right?
21:14 < nickelpro> 16*16*8 for the last two
21:15 < nickelpro> ah forgot the block light array
22:24 < WinstonTheCat> Does anyone know what would be causing this error (bungee)? http://icap.me/i/aN3berLrfz.php
22:25 < Thinkofdeath> winny: #md_5 on esper may be able to help
22:26 < WinstonTheCat> esper?
22:26 < Thinkofdeath> different irc network
22:27 < Thinkofdeath> http://www.esper.net/
22:45 <+md_5> why would someone get bungee help here
22:45 < Eviltechie> md_5: omg it's md5 he can halp with bungee
22:57 <+md_5> Eviltechie how he even knows this channel; exists
22:59 < Eviltechie> My guess is that he was asking around, and he made it sound like he was a dev and not an end user
23:02 < Thinkofdeath> Hes been here before asking for help with the protocol
23:02 < Thinkofdeath> Guessing he is doing something plugin related
23:53 < SevereOverfl0w> Thinkofdeath: :o I was just abou tto see if you were here.