05:36 < cnlohr> this is an 8bit microcontroller... it's not doing encryption :)
05:36 < nickelpro> I think you have to now
05:36 < dx> > http://www.youtube.com/watch?v=EZRLOanNQ_w
05:36 < dx> yeah okay this is nuts
05:37 < nickelpro> holy shit
05:37 < nickelpro> Hoooooolllllyyyy shit that's cool
05:38 < dx> indeed
05:38 < dx> but also insane
05:38 < cnlohr> so... if you're up for helping me...
05:38 < nickelpro> Ok
05:38 < cnlohr> hmm, actually I think I should print a lot more and start selling them for cheap...
05:38 < cnlohr> but that aside
05:38 < cnlohr> I have to make it acutally... go with the new protocol
05:38 < cnlohr> so
05:38 < cnlohr> hmm
05:39 < cnlohr> when the client requests mode 2...
05:39 < nickelpro> Client send 0x00 with 'Next State' set to 0x02, then it sends 0x00 Login start
05:39 < nickelpro> http://wiki.vg/Protocol#Login_Start
05:40 < cnlohr> right... I think I'm there now... I get a really cryptic message when it actually tries to send the login, but it could be because of the backwards way I am trying to load out the login response
05:40 < nickelpro> dx: is there anyway around encryption in 1.7?
05:40 < dx> no idea!
05:40 < dx> don't ask me, i haven't had time to mess with 1.7 yet
05:40 < cnlohr> hmm, what is the UUID?
05:40 < nickelpro> Used to be you could just feed the client chunks and then spawn them
05:41 < cnlohr> according to the other page, you are allowed to just hand it the login success packet.
05:41 < cnlohr> or better yet... what does a UUID look like and any idea what it's used for?
05:42 < nickelpro> uuid comes from sessionserver.mojang.com when the server authenticates the user
05:42 < nickelpro> Probably can just be random in an offline server
05:42 < nickelpro> Haven't played with 1.7 much myself :-\
05:42 < cnlohr> ok, I'll give that a whirl once I get the packets loading into this strange buffer thing.
05:43 < cnlohr> As good as the new protocol is I'm still frustrated that it's such a departure from the old protocol just because of how much rework it is :(
05:43 < cnlohr> I guess I have to just pay attention to the long run.
05:43 < nickelpro> cnlohr: You're far from the only one
05:43 < cnlohr> That's a good point.  I probably implement less than 1/4 the protocol.
05:43 < nickelpro> On the other hand packet prefixing is mad useful
05:44 < cnlohr> yall are nuts
05:44 < cnlohr> I realllylyyyy wish it was a fixed size, like a short
05:44 < cnlohr> because then I could write the packet into the send buffer on the NIC and write the size in later
05:44 < nickelpro> Ya, christ, and the fact that it's a signed value is annoying
05:44 < cnlohr> but because size of packet could be one or two bytes it's... like... why?
05:45 < nickelpro> Because Dinnerbone hates us
05:45 < dx> don't ping them
05:45 < cnlohr> ping?
05:45 < dx> mentioning their names
05:45 < nickelpro> sry, didn't realize
05:45 < nickelpro> I thought it only pinged if it was the start of a msg
05:46 < dx> that depends on the irc client, but it's safer to assume that just mentioning the name will ping
05:46 < cnlohr> uuggh "found 18 bytes extra whilst reading packet 2"
05:47 < nickelpro> I usually just start dumping hex and reading the packets manually
05:47 < nickelpro> Figure out where I went wrong
05:48 < cnlohr> I am not really set up to do that very well, but I am making a lot of progress, like I forgot to rewrite the "Sstring" function
05:49 < cnlohr> ok
05:49 < cnlohr> hey nickelpro, thanks for everything so far!  I am at least moving again
05:50 < nickelpro> cnlohr: not a problem, your stuff is way cooler than mine anyway
05:51 < nickelpro> I'd love to see some code if you do ever get around to publishing it
05:51 < dx> nickelpro: https://github.com/cnlohr/avrcraft
05:51 < nickelpro> sweet
05:52 < cnlohr> thanks
05:52 < cnlohr> and thanks for posting
05:52 < cnlohr> I have a bunch of updates to the underlying TCP/IP stack I am hoping to get in there, too.
05:53 < nickelpro> I know that feeling, I rewrote my plugin framework a couple times and I never want to push it until it's "just right"
05:57 < cnlohr> good grief, everything is just a little different
05:58 < cnlohr> OOH!!! UUID is used for the player
05:58 < cnlohr>  I could just make it the key I use internally for tracking the player...
06:00 < nickelpro> All dat packet ID reuse, that's going to be a problem
06:00 < nickelpro> For Spock and Mineflayer at least
06:00 < cnlohr> all packet ID reuse?
06:00 < cnlohr> what do you mean?
06:01 < nickelpro> Packet ID's are reused in different contexts
06:01 < nickelpro> 0x00 can be a handshake, a keepalive, a disconnect, or a login start depending on the context
06:01 < nickelpro> A lot of custom clients assume packet IDs are universally unique
06:03 < cnlohr> oh yeah, that would have been really helpful
06:04 < nickelpro> We're going to need some sort of context state now "We're moving from login to play, lookup packet IDs in this table instead of that table"
06:05 < nickelpro> Not too bad, annoying maintenance though
06:13 < SinZ> quite a few servers had it split already though, having seperate packet handlers
06:14 < nickelpro> SinZ: Meaning they prepped for 1.7 or they had it split during 1.6?
06:14 < SinZ> had it split during beta
06:14 < SinZ> good way of doing things
06:14 < SinZ> easy way to make sure new clients don't send packets they arn't meant to send
06:15 < nickelpro> Ah, makes sense
06:17 < cnlohr> I wonder if all these places with entity ID, they mean entity UUID
06:18 < dexter0> no
06:18 < dexter0> any mob in the simulation has an entity id, only players have a uuid in addition to an entity id.
06:20 < cnlohr> entity ids are sent as int's right?
06:20 < nickelpro> ya
06:21 < nickelpro> well, sometimes
06:27 < cnlohr> So...
06:27 < cnlohr> I still don't think I have anything sucessfully going into the client
06:27 < cnlohr> if I send:
06:28 < cnlohr> 0d 02 04 55 55 49 44 06 43 4e 4c 6f 68 72 
06:28 < cnlohr> for command 0x02, is that right?
06:29 < cnlohr> it says "found 22 bytes extra whilst reading packet 2"
06:32 < cnlohr> I think I'm doing this string thing wrong or something...
06:32 < cnlohr> If I put trash at the end of the packet it is much happier
06:33 < nickelpro> You sure your varint encoder is good?
06:33 < cnlohr> well, that's what I'm asking... I think
06:33 < nickelpro> 0d02 doesn't look right
06:33 < cnlohr> 0x0d indicates a varint of "I will be sending 13 bytes" 0x02 is the code
06:34 < nickelpro> I'm just being stupid
06:35 < nickelpro> weird
06:35 < nickelpro> Looks good to me
06:35 < nickelpro> varint, id, length, string, length string
06:35 < nickelpro> maybe it expects the UUID to be a specific length?
06:35 < cnlohr> I tried that 
06:35 < cnlohr> no dice
06:37 < cnlohr> 2d 02 24 35 35 30 65 38 34 30 30 2d 65 32 39 62 2d 34 31 64 34 2d 61 37 31 36 2d 34 34 36 36 35 35 34 34 30 30 30 30 06 43 4e 4c 6f 68 72  still yeilds the same: "packet was larger than I expected, found 22 bytes extra whilst reading packet 2"
06:37 < nickelpro> Sure your not sending anything other than the packet?
06:37 < cnlohr> not sure at all
06:37 < cnlohr> I guess I can try wireshark to verify
06:38 < nickelpro> Sounds like some other 22 bytes is sitting in the clients input buffer
06:38 < nickelpro> It expects nothing else to come down the wire
06:39 < cnlohr> well, after I send that I proceed sending the rest of the stuff to do logging on ,etc... but that's very different packets later on
06:40 < cnlohr> hmm
06:40 < cnlohr> interesting
06:40 < cnlohr> now it says 7 bytes extra and nothing else is there
06:41 < cnlohr> it's like 0d 02 04 75... is not enough data to constitute a packet
06:42 < cnlohr> am I missing something?
06:42 < nickelpro> Not that I see, maybe check in tomorrow when the guys who have actually written 1.7 code are on
06:44 < cnlohr> :-/
06:45 < nickelpro> sorry :( I don't see anything obviously wrong
06:45 < cnlohr> *nod*
06:45 < nickelpro> Client is choking on something but I don't actually think it's your packet
06:46 < cnlohr> so, just checking here...
06:47 < cnlohr> GP(0): SIZE:14 -> CMD:0
06:47 < cnlohr>  Client switched mode to: 2
06:47 < cnlohr> GP(2): SIZE:7 -> CMD:0
06:47 < cnlohr> Sending login.
06:47 < cnlohr> CNLohr
06:47 < cnlohr> SEND: 14
06:47 < cnlohr> Sending: 20
06:47 < cnlohr> 02 04 75 75 69 64 06 43 4e 4c 6f 68 72 ff ff ff ff 00 00 00 
06:47 < cnlohr> that makes sense, right?
06:47 < cnlohr> like client should say "switch to mode 2"
06:47 < cnlohr> then send me cmd0
06:47 < nickelpro> Yep
06:47 < nickelpro> Client goes to login mode, then sends a 0x00 handshake
06:48 < cnlohr> to which I reply with a packet size, 0x02 and two strings
06:48 < nickelpro> Yep
06:48 < nickelpro> Well
06:49 < nickelpro> You should wait for client to send a Login Start, also 0x00 containing a string
06:50 < cnlohr> I am waiting for the client to send me a 0x00
06:50 < nickelpro> http://wiki.vg/Protocol#Login_Start That's the packet you actually respond to
06:50 < nickelpro> Handshake is just to let you know the client exists
06:51 < cnlohr> yurp, that's how I'm getting my username from the client
06:51 < nickelpro> alrighty, then ya I'm stumped
06:52 < cnlohr> is there any kind of terminator  I need to put on packets?
06:53 < nickelpro> Nope
06:53 < cnlohr> hmm, if I slap an extra 0x00 on the end it says AAHA you have an extra byte here!  If I don't, it slaps the next packet on
06:53 < cnlohr> this is quite strange
06:55 < nickelpro> Unfortunately I have work tomorrow and have to go, good luck cnlohr
06:55 < cnlohr> cya, thanks
06:55 < cnlohr> you have been very helpful so far
07:07 < cnlohr> for anyone who may want to know, it looks like it was a problem with an unrelated command.  Do not trust those error messages.
07:25 < cnlohr> that error listed before can even be sent when you send messages that are unrecognized.  I was sending 0x82, though it no longer exists.
07:43 < cnlohr> hmm... updates to map cells don't seem to be working, but that may be a problem for tomorrow
10:00 < Valin> Grum: uh
10:01 < Valin> in 1.7.2 you can't take a screenshot with F2 while chat is open
10:01 < Valin> is that intentional or a bug?
10:03 < JonasOSDever> It's a bug https://mojang.atlassian.net/browse/MC-29469
10:28 < cnlohr> You know... YOU GUYS ARE AWESOME.  THANK YOU SO MUCH
11:11 < sprenger120> Does anybody know how Minecraft recognized structures before the update? I'm kinda confused right now
11:32 < JonasOSDever> sprenger120: I'm not sure about this, but so far I know it simply generated the structures (or at least their positions) in memory, every time the chunk was loaded. Nether fortresses generated before the update introducing wither skeletons, for example, only spawned them, if their positions were the same af if they have been generated after that update. So I think it was done like this. But I cannot gurantee my thoughts are co
11:32 < JonasOSDever> rrect
11:34 < sprenger120> Interesting. So they weren't actually part of the saved map right?
11:36 < Thinkofdeath> sprenger120: Not before, 1.6.4+ does
11:36 < sprenger120> ah ok thanks
11:52 < SinZ> well, 1.6.3+
14:45 < tehme> yo
14:46 < tehme> i know i'm banned and gonna go away, but FUCK YEAH PACKET LENGTH
14:50 < Thinkofdeath> ^ That was odd
14:51 < SinZ> agreed
17:37 < Thinkofdeath> There isn't an easy way of debugging lighting is there?
18:27 < woder> quick question, how are chunk coordinates rounded?
18:29 < Thinkofdeath> blockX/16
18:29 < woder> yes but how is that rounded
18:30 < Thinkofdeath> floor(blockX/16)
18:30 < Thinkofdeath> or blockX>>4
18:31 < woder> ah, its the floor, awesome thanks
21:09 < Thinkofdeath> http://198.199.127.128/lighting.gif Not the best way to test lighting but it works
23:14 < Not-001> [Craft.Net] SirCmpwn pushed 2 commits to 1.7.x [+2/-1/±10] http://git.io/GevPEw
23:14 < Not-001> [Craft.Net] SirCmpwn 8e96b19 - Switch to UTF-8 strings
23:14 < Not-001> [Craft.Net] SirCmpwn eaf1129 - PacketReader -> NetworkManager
23:16 < WinstonTheCat> Hello?
23:16 < Thinkofdeath> Hey
23:19 < iBotPeaches> hhi
23:30 < nickelpro> sup
23:41 < WinstonTheCat> Is there a way to automate a login for a 1.7 server?
23:48 < Not-001> [Craft.Net] SirCmpwn pushed 1 commit to 1.7.x [+1/-0/±3] http://git.io/j2IYBw
23:48 < Not-001> [Craft.Net] SirCmpwn 85c8ac2 - Implement status protocol mode
--- Day changed dim. oct. 27 2013
00:14 < barneygale> Hm, there's quite a few different ways to write a server list pinger. I wonder how correct I should be vs. how noobie-friendly I want to keep Server_List_ping
00:18 < Thinkofdeath> barneygale: Keep that page noobie-friendly, anyone doing more complex stuff (e.g. a full server) can work it out from http://wiki.vg/Protocol#Status
00:18 < Not-001> [Craft.Net] SirCmpwn pushed 2 commits to 1.7.x [+0/-0/±3] http://git.io/j2t_LA
00:18 < Not-001> [Craft.Net] SirCmpwn c1ae5b4 - Altered stream handling in NetworkManager
00:19 < Not-001> [Craft.Net] SirCmpwn 0df3b8a - Implement login protocol mode
00:27 < barneygale> Thinkofdeath: 1) should I bother listing how to correctly send protocol version, hostname and port, if they're only required for things like bungee?
00:28 < Thinkofdeath> Hostname and port yes, protocol version not so much
00:28 < barneygale> alright
00:28 < Thinkofdeath> Virtualhosting uses the hostname and port if I remember right
00:29 < barneygale> 2) Should I describe varints? You can get away with no needing to pack them as long as your hostname isn't >100 characters or so
00:29 < Thinkofdeath> Don't know if anyone ever uses for for that
00:29 < barneygale> yeah bungee uses it
00:29 < Thinkofdeath> You need to be able to read them, don't you?
00:30 < barneygale> kind of
00:30 < Dinnerbone> Protocol version is important.
00:30 < barneygale> you can hack around it by saying "read a byte at a time til you've read 3 bytes without their MSB set, then read a JSON string!"
00:30 < Thinkofdeath> Dinnerbone: Even for just pinging?
00:30 < Dinnerbone> I would not recommend dumming down the protocol to the point of being wrong
00:31 < barneygale> In my testing I've sent protocol version 0 and it's worked just fine
00:31 < barneygale> oh, i see what you mean
00:31 < Dinnerbone> Yes Thinkofdeath. If we were to change it based on protocol, these people would be kinda screwed.
00:31 < Dinnerbone> If we added a flag to the request packet, for example
00:31 < Thinkofdeath> Didn't think of that
00:31 < Dinnerbone> The behaviour would change based on if your protocol version supported it
00:31 < Dinnerbone> Or how we respond to packets
00:31 < Dinnerbone> Etc
00:32 < Thinkofdeath> barneygale: Looks like you need to fully explain it then
00:32 < barneygale> The issue with that is having to update it every time the protocol version changes, even if the change didn't affect ping
00:34 < Thinkofdeath> As long as they don't lag too far behind it should be fine, if it changes the server will support the old style for a bit anyway
00:35 < barneygale> OK. What about varints? Not necessary to write unless your hostname is long, not necessary to read (you can stream json)
00:35 < barneygale> but not every library does afaik.
00:36 < Dinnerbone> Uh
00:36 < Dinnerbone> You do need to read it?
00:36 < Dinnerbone> Is the reply not: varint length, json?
00:37 < barneygale> aye, but you don't know where the json ends unless you understand json
00:37 < Dinnerbone> Huh?
00:37 < Dinnerbone> You know where it ends when you hit the length you were given
00:37 < Dinnerbone> And you know where it starts only when you finished reading that length
00:37 < barneygale> Oh, I misread your question, thought you were asking the opposite :P
00:38 < barneygale> json.load() will load a json object from a stream, which means you can ignore the length and just trust the json library to find the correct ending
00:39 < Thinkofdeath> But you don't know where it begins either unless you can read varints
00:39 < Dinnerbone> A decent library should be telling you: this is wrong json, error here.
00:39 < barneygale> You can do something a bit simpler, which is to read a byte at a time til you've seen three without MSB set
00:39 < Dinnerbone> I really don't think you should be teaching people the wrong ways of implementing the protocol
00:40 < Thinkofdeath> At that point you might as well explain varints
00:40 < barneygale> Yeah, point taken
00:40 < barneygale> Thanks
00:40 < Drainedsoul> if someone can't understand varints, they really have no business implementing code that works with networking
00:41 < barneygale> It's true, but people do cut their teeth on minecraft, despite everyone telling them not to
00:42 < Drainedsoul> I don't really think that's relevant.  If they're going to do networking, they're going to need to understand things like host order/network order, which is more complicated than bit twiddling to figure out if the MSB is set, imo
00:42 < barneygale> oh btw, does my varint implementation look ok? this is unsigned only: https://gist.github.com/barneygale/7b04d45d25dacab37f63
00:43 < barneygale> that's an excerpt ofc
00:44 < Thinkofdeath> if d > 0 else 0   ? 
00:44 < Drainedsoul> that code doesn't seem to cap the size of a varint
00:45 < Thinkofdeath> If its only positive then that shouldn't be needed
00:45 < Drainedsoul> how long are you going to keep parsing/storing garbage with the MSB set before you fail out and kick the client
00:46 < Thinkofdeath> 5 bytes is mc's max
00:47 < barneygale> Drainedsoul: good point
00:47 < barneygale> the d>0 thing I prefer because it's more explicit
00:48 < Thinkofdeath> Oh I think I understand "if d > 0 else 0" now, it looks odd 
00:48 < barneygale> ah yeah, python syntax thing
00:49 < barneygale> if(d>0) { 0x80 } else { 0 }
00:49 < Thinkofdeath> Yeah, might want to explain incase they are using a different language
00:49 < barneygale> I'll probably pseudocode it
00:51 < Drainedsoul> https://github.com/RobertLeahy/MCPP/blob/1_7_protocol/include/packet.hpp#L885 this also implements signed
00:51 < barneygale> actually idk
00:52 < Thinkofdeath> Drainedsoul: Signed varints aren't used anymore
00:53 < Drainedsoul> yeah that's fine
00:53 < Drainedsoul> that's what templates and the compiler are for
00:53 < Drainedsoul> :P
00:53 < Thinkofdeath> c++ still confuses me
00:53 < Drainedsoul> in what way lol
00:54 < Thinkofdeath>  b&=~static_cast<Byte>(128); and union { ....
00:54 < Thinkofdeath> Thoses parts mainly
00:54 < Drainedsoul> b=b&128, where 128 is explicitly of type Byte
00:55 < Drainedsoul> the union basically means that the two variables inside it exist one ontop of each other
00:55 < Drainedsoul> i.e. it maps the raw bits of a signed integer over to the raw bits of an unsigned integer
00:55 < Drainedsoul> *b=b&~128
00:55 < Drainedsoul> sorry
00:55 < Thinkofdeath> Ah
00:56 < Drainedsoul> T is the raw inner type of the VarInt -- can be any integer type -- and type is: typedef typename std::make_unsigned<T>::type type;
00:56 < Drainedsoul> which means that no matter what T is, "type" is the same thing, except not signed
00:58 < Thinkofdeath> Ok then, I think I get it
00:59 < Drainedsoul> it's convenient because if in the future Mojang decides to use all sorts of different integer types inside varints, I don't have to write any more code
00:59 < Drainedsoul> I can just use Serializer<VarInt<UInt128>> or Serializer<VarInt<Int64>> and the compiler will write the appropriate code for me for those new types
00:59 < Thinkofdeath> Go just decodes it into a uint64
01:00 < Thinkofdeath> http://golang.org/src/pkg/encoding/binary/varint.go?s=3253:3302#L96
01:00 < Drainedsoul> it decodes it into whatever the underlying type of the VarInt is, so for a VarInt<UInt32> it decodes into a UInt32, but for a VarInt<Int64> it'd decode into an Int64
01:00 < Drainedsoul> return x, overflow <= what does this mean
01:01 < Thinkofdeath> var overflow = errors.New("binary: varint overflows a 64-bit integer")
01:01 < Thinkofdeath> Go has multiple return values
01:01 < Thinkofdeath> In this case its (uint64, error)
01:02 < TkTech> barneygale: For people that want to "cut their teeth" on minecraft, I usually point them to fragmer's fcraft and classic.
01:02 < TkTech> Which is absurdly simple to write a basic server for. I think there's even a book.
01:04 < Drainedsoul> so in Go you can return like a tuple?
01:05 < Thinkofdeath> yeah: num, err := binary.ReadUvarint(r)
01:06 < Drainedsoul> that's cool
01:06 < Drainedsoul> out parameters only go so far, and you can only do so much with them before it becomes kludge :P
01:08 < Thinkofdeath> Well it supports pointers so you could do both :)
01:19 < Drainedsoul> does it support references?
01:19 < Thinkofdeath> http://play.golang.org/p/AhUfwKCQLt
01:45 < barneygale> So I wrote some pseudocode, it turns out quite explicit though: https://gist.github.com/barneygale/e932b6a11cd350262edb
01:46 < Drainedsoul> where does the 4 on line 5 come from
01:53 < barneygale> This is just doing unsigned, which is 4 bytes max right?
01:55 < barneygale> slightly updated
01:59 < Drainedsoul> 32 divided by 7 is greater than 4
02:03 <+fragmer> TkTech, if you want to point to a simple Classic server, point to my FemtoCraft instead
02:03 <+fragmer> fCraft has grown rather bloated over the years (pushing 70k LoC now)
02:04 <+fragmer> FemtoCraft is a stripped-down version (just Classic with stability/usability/security improvements)
02:04 <+fragmer> http://femto.fcraft.net/
02:04 <+fragmer> 1/20th the size of fCraft's codebase
02:11 < barneygale> Drainedsoul: oh, good point
02:12 < Not-001> [FemtoCraft] fragmer * r132 2 files : Fixed a typo in "physics-snow" help entry on the site
02:13 < barneygale> well
02:13 < barneygale> :/ idk
02:17 < Drainedsoul> you'll need to do same fancy bit twiddling for the last byte too, to make sure it doesn't overflow
02:17 < Drainedsoul> that's handled in the C++ example I linked earlier
02:18 < barneygale> code is updated btw
02:18 < barneygale> where do I need to bit twiddle?
02:19 < Drainedsoul> well let's say that you decode the fifth byte and it's 0b01111111
02:19 < Drainedsoul> that's an overflow
02:19 < Drainedsoul> that would represent an integer bigger than 2^32-1
02:19 < Drainedsoul> so the client sent you garbage
02:20 < Drainedsoul> so you need to check to make sure bits higher than the 32nd aren't set
02:22 < Drainedsoul> https://github.com/RobertLeahy/MCPP/blob/1_7_protocol/include/packet.hpp#L844 <== this gets a mask for an arbitrarily-sized varint.  get_final_mask()&final_byte==0 or the final byte is garbage
02:22 < barneygale> I think that's unnecessary for the Server_List_Ping page
02:22 < barneygale> it's meant for beginners
02:22 < barneygale> I'll stick it in as a note maybe but it doesn't need to be in the pseudocode
02:23 < Drainedsoul> Note to self: Validation of bytes sent on wire "unnnecessary"
02:23 < Thinkofdeath> In this case should be fine
02:24 <+sadimusi> md_5: is the legacy ping still working in bungee? I've had some complaints
02:31 < Not-001> [FemtoCraft] fragmer * r133 5 files : Got rid of some code redundancies in Server.Message, Util.JoinToString, and DATMapConverter/LvlMapConverter.
02:56 < iBotPeaches> When the state changes from 0 -> something else, is that change for both server -> client / client -> server?
02:57 < Not-001> [FemtoCraft] fragmer * r134 13 files : Code cleanup and annotation improvements
02:58 < barneygale> iBotPeaches: yeah
02:59 < iBotPeaches> barneygale: that probably will fix my problems up then :p
02:05 < barneygale> updated again to have: a 5 byte limit.
02:07 < barneygale> oh and there's a stupid mistake
02:10 < Not-001> [FemtoCraft] fragmer * r135 3 files : Release 1.35. Updated assembly versions and license file.
02:11 < Not-001> [FemtoCraft] fragmer * r136 2 files : Updated the website with new release information.
02:11 <+md_5> sadimusi it should be 
02:11 <+md_5> works for me
02:11 <+md_5> nb: server lists may not work unless they are using 1.5/6 style pings
02:11 <+md_5> some server lists are still on 1.4
02:11 <+sadimusi> one of the server complaining is play.vcserver.org
02:12 <+sadimusi> it's showing 117 players for me, the vanilla client is showing 452
02:12 <+sadimusi> and I'm using 1.6 style ping http://minecraftservers.org/server/41160
02:13 <+sadimusi> the problem might be with their DNS setup though, to me it looks like the domain is managed by cloudflare
02:13 <+sadimusi> md_5: ^
02:43 <+md_5> doesnt look like a bungee issue
04:44 < nickelpro> Are varints still signed values, ie is 0xFF 127 or -1?
04:45 < nickelpro> 0xFF FF FF FF FF rather
04:58 < Drainedsoul> when would 0xFF ever be 127?
05:00 < dx> sounds like he meant 255
05:05 < Drainedsoul> if his question was: Do Mojang's VarInt's use two's complement for signed numbers?  The answer is yes.  If the question is: Are signed numbers currently relevant to the protocol?  The answer is no.
05:11 < dx> Drainedsoul: what's the representation of -1 as a mojang varint then?
05:14 < Drainedsoul> FF FF FF FF 0F if my quick manual binary is at all accurate
05:15 < dx> 0F or 7F?
05:15 < Drainedsoul> 32%7 = 4, so the last byte would have the four low bits set, which is 0x0F
05:16 < Drainedsoul> otherwise they'd be 35 bit integers
05:16 < dx> oh derp
05:16 < dx> thanks
06:26 < Not-001> [fCraft] fragmer * r2248 40 files : Reorganized fCraftGUI project, and imported /DrawImage code from 800craft (not hooked up yet).
07:54 < Not-001> [fCraft] fragmer * r2249 2 files : Fixed ServerGUI ungracefully handling startup crashes in fCraft.dll
07:55 < Not-001> [fCraft] fragmer * r2250 2 files : Added LoadGDIPlus config key, to avoid loading libgdiplus-dependent features on crappy Mono setups.
07:56 < Not-001> [fCraft] fragmer * r2251 5 files : Finished /DrawImage integration.
08:16 < Not-001> [fCraft] fragmer * r2252 2 files : Switched from using dyndns's to fcraft.net's service for fetching server's external IP
08:23 < Not-001> [fCraft] fragmer * r2253 2 files : Fixed incorrect formatting of log entries (missing space between timestamp and type prefix)
08:24 < Not-001> [fCraft] fragmer * r2254 2 files : Fixed an occasional crash in Map.ResetSpawn if called before Blocks array was set
11:53 < Not-001> [fCraft] fragmer * r2255 2 files : Fixed /DrawImage incorrectly rendering images with transparency.
12:03 < Not-001> [fCraft] fragmer * r2256 3 files : cleaned up formatting in DrawImageCommand and ImageDrawOperation, as well as comments in EnumUtil (explaining why I don't just use Enum.TryParse)
12:37 < Not-001> [fCraft] fragmer * r2257 4 files : Added preliminary support for exporting to ClassicWorld (CW) file format.
14:28 < dav1d> Brottweiler: ping
14:29 < dav1d> nvm
14:30 < dav1d> found a translation 
14:30 < dav1d> ty anyways :P
15:00 < Brottweiler> dav1d: pong
15:06 < WinstonTheCat> hey
15:10 < dav1d> Brottweiler: thanks, but I found a translation. You were not needed!
15:12 < WinstonTheCat> Could someone help me?
15:21 < WinstonTheCat> Hello?
15:26 < WilliBean> hey
15:26 < WinstonTheCat> hey
15:28 < WilliBean> is anyone knowing how i can pack the varint?
15:28 < WinstonTheCat> I'm trying to figure out the varint as well
15:29 < iBotPeaches> Then why didn't you just ask instead of saying Hi for 20 minutes
15:29 < WilliBean> i have already found a easy way to read, but i have no idea how to pack it
15:29 < iBotPeaches> https://gist.github.com/thinkofdeath/e975ddee04e9c87faf22
15:29 < iBotPeaches> encode / decode
15:30 < WilliBean> thx
15:30 < WinstonTheCat> Wasn't sure what I was exactly looking to ask at first, sorry.
18:14 < Trojaner> hey, i have a question, based on this: http://wiki.vg/Server_List_Ping
18:14 < Trojaner> "6. XX XX - length of the rest of the data, as a short. Compute as 7 + 2*len(hostname)"
18:14 < Trojaner> what does "len" mean?
18:14 < Thinkofdeath> Length
18:14 < Trojaner> okay, thanks
18:15 < Thinkofdeath> That page is out of date for 1.7 though
18:28 < Trojaner> i made this code:
18:28 < Trojaner> http://hastebin.com/nufitebinu.avrasm
18:28 < Trojaner> but i dont get a response
18:28 < Trojaner> its throwing an exception, which says that the connection was resetted
18:29 < Trojaner> can anyone help me?
18:31 < WilliBean> line 21 remove the 2*
18:31 < WilliBean>  short restLength = (short) (7 + hostname.getBytes(ENCODING).length);
18:32 < Trojaner> okay
18:34 < Trojaner> WilliBean: didnt work, its still resetting the connection
18:35 < Trojaner> the exception occurs on these lines:
18:35 < Trojaner>             byte[] b = new byte[0xFF];
18:35 < Trojaner>             int len = in.read(b);
18:35 < Trojaner> (in is the inputstream)
18:42 < umby24> so uhh. Both keep alive and handshake have packet ID of 0?
18:43 < iBotPeaches> There are different states now, 4 of them to be exact. Keep track of the state and you'll know which packet to use
18:43 < iBotPeaches> starts at handshake (0), the handshake packet will set the next state (1 or 2) based on status/login. If you succesfully login state goes to 3 (play packets)
18:45 < umby24> odd. but alright.
18:45 < Dinnerbone> It's odd to reverse IDs for things that do not even exist in a given context ;)
18:46 < umby24> meh :P just another thing to complicate parsing
18:46 < iBotPeaches> I don't know if play is actually 3, but if its not 0,1,2. I just assume play (3)
19:44 < iBotPeaches> how come y, in the x,y,z isn't an Int like the rest?
19:45 < WilliBean> the highest position you can place a block is 255, so you don't need an int
19:45 < iBotPeaches> d'oh thanks :p
19:51 < superjoe> so I heard the networking was completely rewritten in the latest release
19:52 < Thinkofdeath> superjoe: Uses netty now
19:52 < Thinkofdeath> + packet length prefixes
19:53 < superjoe> about fucking time
19:53 < Thinkofdeath> http://wiki.vg/Protocol#Packet_format
19:53 < superjoe> this is great news for mcdevs
20:26 < barneygale> what does hasJoined return if auth fails?
20:27 < Thinkofdeath> Nothing
20:27 < barneygale> 200 with no response body?
20:27 < Thinkofdeath> can't remember
20:28 < barneygale> alright, I'll test a bit then
21:55 < Not-001> [netherrack] thinkofdeath pushed 3 commits to master [+1/-0/±10] http://git.io/QI9g_g
21:55 < Not-001> [netherrack] thinkofdeath 76752f5 - blocks: add StainedGlassPane
21:55 < Not-001> [netherrack] thinkofdeath 26f5589 - format/msgpack: fix unsafe string decoding
21:55 < Not-001> [netherrack] thinkofdeath c73688f - world: Basic block lighting support all: 1.7.2 update
22:27 < barneygale> I'm having a bit of trouble with AES encryption: the client is erroring out complaining about an invalid packet ID when I send something after turning on encryption. Code is here: https://github.com/barneygale/authserver/tree/1.7
23:19 < ellisvlad> Finally working as intended :D http://puu.sh/51lQ8.jpg
23:19 < ellisvlad> {My C++ server btw}
23:20 < Cubix> lol, i was scared that you're updating nodus xD
23:20 < ellisvlad> 1.7 forced me to properly structure packets into classes.. Before, I was just pushing random bits of data to the client's stream :P
23:21 < ellisvlad> haha no :P Just using Nodus to work on blocking flying and nuker etc. :P
--- Day changed lun. oct. 28 2013
02:57 < Tux> So I'm trying to write a native server list ping library for 1.7 and I'm getting nowhere at all. This is my current progress: https://gist.github.com/minecrafter/7190300
02:58  * sadimusi can't find the code between all those getters and setters :P
02:59 < Tux> https://gist.github.com/minecrafter/7190300#file-serverlistping17-java-L120
02:59 <+sadimusi> what happens when you execute it?
03:00 < Tux> I get my debug output, then silence as I get -1 bytes from the server
03:00 < Tux> I'm going to make a few changes
03:00 <+sadimusi> you're sure the first packet isn't bigger than 127 bytes?
03:01 < Tux> It is not
03:01 <+sadimusi> but your port is a byte instead of a short
03:02 < Tux> hm.
03:02 < Tux> Writing the port as a short has no effect
03:03 <+sadimusi> what does the server say?
03:03 < Tux> Nothing
03:03 < Tux> I get -1 from the read call, and the server (vanilla) says nothing
03:04 <+sadimusi> I meant in the console
03:04 < Tux> It says nothing in the console
03:06 <+sadimusi> where does that UTF-16BE come from?
03:06 <+sadimusi> never mind, you're not using the reader
03:07 < Tux> this is actually an old-ish java SLP class I found and I'm modifying it to use 1.7's protocol
03:07 <+sadimusi> to be honest, the code looks horrible
03:07 < Tux> it is
03:08 < Tux> I am trying to clean it up
03:08 < Tux> I have debug scattered around generously ;)
03:11 < Tux> I have to go
04:19 < zh32> Tux, i couldn't sleep :D https://gist.github.com/zh32/7190955
04:33 < Drainedsoul> that looks like a mess still
04:36 < zh32> i know :P
05:13 < umby24> Trying to update my bot for 1.7, something doesn't seem right. I send the handshake packet, then the loginStart packet, and the server drops the connection
05:14 < umby24> friend of mine is having the same issue
05:14 <+AndrewPH> umby24: 1.7 has a completely new protocol
05:15 < umby24> i know, im working on it right now
05:15 < umby24> and again, getting nothing back.
05:15 < woder> server just drops the connection :c
05:18 <+AndrewPH> (little did they know, I'm really just a fact bot that spouts out random facts to people)
05:19 < umby24> suure :P
05:58 < Drainedsoul> umby24: What are you actually sending?  Raw bytes etc.
05:59 < umby24> was my derp it appears, once i found the correct protocol version (and actually started sending the protocol version) i wasn't getting dropped
05:59 < umby24> thank you though
10:51 < Not-001> [MCPP] RobertLeahy pushed 2 commits to 1_7_protocol [+26/-3/±5] http://git.io/PHIJew
10:51 < Not-001> [MCPP] RobertLeahy 31a5fde - Network Stack Rewrite
10:51 < Not-001> [MCPP] RobertLeahy ff4de1b - 1.7.2
13:19 < Trojaner> Hey, when I send a Server Ping Packet with this: http://hastebin.com/peqiyanola.avrasm, the answer from the server is wrong
13:19 < Trojaner> Its: 0: §1, 1: 78, 2: 1.6.4, 3: §2�
13:20 < Trojaner> its not like this: http://wiki.vg/Server_List_Ping#Server_-.3E_Client
13:33 < Thinkofdeath> Trojaner: That looks right
13:37 < Trojaner> but its not sending the max /current players and the motd
13:37 < Thinkofdeath> Where is your reading code
13:37 < Trojaner> wait
13:43 < Trojaner> Thinkofdeath: http://hastebin.com/qayuwuguyu.avrasm
13:44 < barneygale> Trojaner: is hostname.length() returning the length in characters or bytes?
13:44 < Trojaner> characters
13:44 < barneygale> It looks fine to me
13:46 < barneygale> Oh hold on, I think bungee had this issue. Does it work with 1.6 servers, but not 1.7?
13:46 < Trojaner> i didnt test it on 1.7
13:46 < Trojaner> only on 1.6.4
13:46 < barneygale> hm, idk then
13:46 < Thinkofdeath> Your reading code looks odd
13:46 < Trojaner> hm
13:46 < Thinkofdeath> byte[] b = new byte[' '];
13:46 < Thinkofdeath> ^ Thats weird
13:46 < Trojaner> :D
13:47 < Trojaner> what should it be?
13:48 < Trojaner> 0x00 ?
13:49 < Thinkofdeath> Wrap it with a DataInputStream,   readByte() //Packet ID 0xFF
13:50 < Thinkofdeath> readShort() //String length
13:50 < Thinkofdeath> etc
13:50 < Trojaner> okay
13:50 < Trojaner> thanks, i will try that
13:53 < iBotPeaches> Finally finished my 1.7 protocol, took the entire weekend
13:54 < Thinkofdeath> iBotPeaches: \o/
13:54 < iBotPeaches> On 0x15 and 0x17. It was reporting wrong bytes so I swapped the direction implementations I had and it worked, so I don't know if I copied off wiki incorrectly, but will look after classes
13:54 < Thinkofdeath> Welcome to the nicer side of the protocol
16:05 <+sadimusi> barneygale: I finally for around to implementing a varint packer http://d.pr/n/v9WM
16:05 <+sadimusi> barneygale: I'll have to check if yours is faster
16:06 < barneygale> hah nice
16:08 <+sadimusi> as expected yours is a bit faster
16:21  * eddyb struggles to guess the language
16:21 < eddyb> wait, that's python?
16:21 <+sadimusi> yes
16:21 <+sadimusi> the colon should give it away
16:22 <+sadimusi> and of course the inline generator
19:01 < Not-001> [fCraft] fragmer * r2258 2 files : Implemented loading from ClassicWorld file format.
19:04 < Not-001> [fCraft] fragmer * r2259 2 files : Added CPE CustomBlocks level 1
19:07 < Not-001> [fCraft] fragmer * r2260 2 files : Fixed IsoCat not rendering properly, due to CPE-related changes.
20:23 < umby24> is http://wiki.vg/Protocol_Encryption#Authentication  current? Session server keeps giving me 400's
20:25 < Thinkofdeath> umby24: Client or Server?
20:25 < umby24> client
20:28 < Thinkofdeath> Are you sending the data as a post request?
20:28 < umby24> yes
20:28 < Thinkofdeath> Content-type: application/json ?
20:28 < umby24> yup
20:29 < Thinkofdeath> oh I think serverID should be serverId
20:29 < Thinkofdeath> Made a typo on the page
20:30 < umby24> alright, don't seem to be getting 400's anymore. just the server complaining that i failed :P
20:31 < Thinkofdeath> Progress!
20:31 < umby24> indeed!
20:31 < umby24> Thank you for the help
20:31 < Thinkofdeath> np
20:41 < Tux> zh32, thank you very much :3
20:46 < Not-001> [fCraft] fragmer * r2261 2 files : Prevented ConfigGUI from sometimes prompting to save changes if no changes have been made (related to ListView firing unexpected ItemChanged events). This also reduced ConfigGUI startup time a bit.
21:09 <+sadimusi> md_5: ping
21:25 <+md_5> hi
21:40 <+sadimusi> md_5: I noticed that a lot of the big servers running bungee report different player counts for the old and new style ping
21:41 <+sadimusi> md_5: any chance that might be bungee's fault?
21:50 < woder> is the serverid from packet 1 state 2 suppose to be a null char?
21:50 < Thinkofdeath> woder: Nope
21:51 < woder> Thinkofdeath: I guess my reading code is off, how do you read utf 8 off an input stream?
21:52 < Thinkofdeath> VarInt Length + bytes[length]
23:37 < Yukiiro> hello?
23:43 < Yukiiro> I'm trying to write a client to send chat to a server. I don't quite understand how to send a packet in the format expressed om the wiki. I'm writing in java, a working example would be wonderful.
23:46 < ellisvlad> The new packet format is fairly simple. It's a VarInt following packet's size, then the packetID as a byte (0x02 for chat), and then another VarInt with the following string's size, then a string.
23:47 < Yukiiro> yes, but do i send that using a socket?
23:47 <+sadimusi> Yukiiro: my advice: use an existing library
23:47 <+sadimusi> Yukiiro: getting the protocol and the encryption working will take you days
23:47 <+sadimusi> *weeks
23:47 < Yukiiro> i'm fine with that =D
23:48 < Yukiiro> are there libraries out for 1.7?
23:48 <+sadimusi> not sure
23:51 < Yukiiro> is there anywhere i can find a working example?
23:53 < zh32> bungee's source could be helpful
23:53 <+sadimusi> bungee's encryption is only client side
23:53 < Yukiiro> i'm only interested in the client side for now.
23:54 <+sadimusi> maybe have a look at iBotPeaches's code
23:54 < Yukiiro> <=I i have no idea who these people are or where i can find their code..
23:54 <+sadimusi> it's just a proxy, so you still have to figure out which packets to send on your own
23:54 <+sadimusi> https://github.com/SimpleServer/SimpleServer/
23:55 <+sadimusi> looks like we still have the huge switch block
23:55 < Yukiiro> thank you.
23:55 <+sadimusi> so maybe don't take it as an example
23:56 < Yukiiro> i just need something to show me what sending a packet looks like.
23:56 <+sadimusi> oops, looks like he has his own fork
23:57 <+sadimusi> might not be of much help to you https://github.com/iBotPeaches/SimpleServer/blob/protocol/src/simpleserver/stream/StreamTunnel.java
23:57 <+sadimusi> I would suggest you first try to get the server status
23:57 <+sadimusi> there is no encryption involved
23:59 <+sadimusi> there are probably even some java examples around
23:59 <+sadimusi> my code in python looks like this: http://d.pr/n/JyCP
23:59 < Yukiiro> i've been looking pretty hard, but apparently i've just been lookin in the wrong spot.
--- Day changed mar. oct. 29 2013
00:03 < zh32> Yukiiro, a messy java example https://gist.github.com/zh32/7190955
00:04 < Yukiiro> thank you
00:17 < dividuum> does the order of entity metadata matter? From the protocol description it looks like i can sent them in any order
00:23 < Not-001> [Craft.Net] SirCmpwn pushed 2 commits to 1.7.x [+0/-0/±4] http://git.io/ZQfwjg
00:23 < Not-001> [Craft.Net] SirCmpwn d925e90 - Fix NetworkStream string implementation
00:23 < Not-001> [Craft.Net] SirCmpwn 4a93110 - Implement 0x00-0x0B play mode packets
00:52 < WinstonTheCat> zh32, testing out the link you sent earlier, for some reason when attempting uberminecraft.com on 25565 I get a socketimeout on "int k = in.readByte();" when reading the varint (readVarInt)
00:56 < wow4201> I need help with server ping. In 1.6 I did something like writeByte(254)  writeByte(1)  Then if  readByte() = 255 
00:56 < wow4201> To get server ping information
00:57 < wow4201> But now when I send 255 and 1 I get no response
00:57 <+sadimusi> if you did the 1.6 ping correctly you will still get a response
00:58 < wow4201> On a server running in 1.7?
00:58 <+sadimusi> yes
00:59 <+sadimusi> I haven't updated my ping yet and it works mostly fine
00:59 <+sadimusi> I'm updating it now because bungee servers are reporting wrong player counts
00:59 < WinstonTheCat> wow4201, your server is uberminecraft?
00:59 < wow4201> hmm, because I have some running in 1.6 and they ping correctly. But the ones in 1.7 don't
00:59 < wow4201> Yeah
01:00 < WinstonTheCat> Pretty sure you fixed it but a while back I found that 25501 was open on your server and could login as basically anyone.
01:00 < wow4201> Yeah lol very bad mistake
01:01 <+sadimusi> wow4201: why do you need to ping if you run the server?
01:01 < WinstonTheCat> Did you finally figure out how to fix it the right way? Before it seems you knew about it but fixed it by resetting the entire hub server
01:01 <+sadimusi> WinstonTheCat: running a server list?
01:02 < WinstonTheCat> ?
01:02 <+sadimusi> WinstonTheCat: what do you need the ping script for?
01:03 < zh32> WinstonTheCat, works for me, but i get inavlid packetid on the ping response
01:03 < wow4201> I need ping script to monitor my 100 server instances
01:03 < wow4201> It's nice just looking at that rather then checking each 1 by 1
01:05 <+sadimusi> there are probably easier ways to do that, but that's your choice
01:06 < wow4201> Looking at some scripts online
01:06 < wow4201> s.send('\xfe\x01')   <---254 & 1
01:06 < wow4201> https://github.com/williammck/MCStatusBot/blob/master/bot.py
01:07 <+sadimusi> that looks pretty old
01:07 < wow4201> Below was recently released by someone on reddit minecraftadmin
01:07 < wow4201> https://gist.github.com/barneygale/1209061
01:07 < wow4201> s.send(pack_data("\x00\x00" + pack_data(host.encode('utf8')) + pack_port(port) + "\x01"))
01:07 < wow4201> s.send(pack_data("\x00"))
01:07 <+sadimusi> barneygale is in here as well
01:07 < Not-001> [Craft.Net] SirCmpwn pushed 1 commit to 1.7.x [+0/-0/±2] http://git.io/MrWy-g
01:07 < Not-001> [Craft.Net] SirCmpwn a2783f4 - Fix problems with length handling in NetworkManager
01:07 <+sadimusi> didn't see his script yet though
01:08 <+sadimusi> mine is pretty similar http://d.pr/n/JyCP
01:09 < wow4201> Do you have to handshake before status request?
01:10 <+sadimusi> yes
01:10 < wow4201> \xfe\x01 is pretty clear 254 & 1
01:10 < wow4201> \x00
01:11 < wow4201> What is that byte 0?
01:11 <+sadimusi> where is that code from?
01:11 < wow4201>  s.send('\xfe\x01')   <---254 & 1
01:11 < wow4201> 1.6
01:12 <+sadimusi> you're lookin at mcstatusbot?
01:12 <+sadimusi> *looking
01:12 <+sadimusi> I can't se a 0 byte being sent there
01:13 <+sadimusi> and it doesn't send the host either, that's probably why it doesn't work with 1.7
01:13 < wow4201> Your code  http://d.pr/n/JyCP, The handshake/protocol/port/state
01:13 < wow4201> Is that all in one packet?
01:14 < wow4201> I'm not familar with python so it's a bit hard to understand
01:14 <+sadimusi> yes that is all one packet
01:14 <+sadimusi> there are only two packets being sent
01:15 <+sadimusi> the second one is just "\x01\x00"
01:15 < wow4201> "\x01\x00"
01:15 <+sadimusi> 01 being the length and 00 the packet id
01:15 < wow4201> ok thank you
01:16 <+sadimusi> wow4201: interesting player count :D http://d.pr/i/2pvq
01:16 < wow4201> lol yeah
01:17 < Tux> zh32, it doesn't work
01:17 < Tux> https://gist.github.com/minecrafter/0966804c8d75e8ca44cb
01:18 < zh32> Tux, what kind of server is this?
01:19 < Tux> 1.7.2 spigot hack
01:19 < zh32> it's not answering the pingrequest (second packet which is send)
01:19 < Tux> ah
01:19 < zh32> *third
01:20 < Tux> i'm going to check a vanilla server real quick
01:20 < Tux> vanilla works
01:21 < Tux> I'm going to simply short-circuit around that code for now
01:22 < Not-001> [fCraft] fragmer * r2262 2 files : Added missing license notice to JetBrains.Annotations.cs
01:29 < Tux> Welp, that didn't work either.
01:30 < zh32> just use 1.6 ping (fe, 00, fa .....)
01:31 < Tux> I want to be prepared though
01:32 < wow4201> What conclusion did you guys come to here
01:32 < wow4201> pinging a spigot server....doesn't react like pinging a vanilla server?
01:32 < wow4201> just use 1.6 ping (fe, 00, fa .....) on what vanilla or spigot?
01:33 <+sadimusi> just don't use the old ping
01:33 < wow4201> old ping works on vanilla 1.7 but not spigot
01:33 < wow4201> correct?
01:33 <+sadimusi> it does work, but it might return wrong results
01:34 <+sadimusi> try minetime for example
01:35 <+sadimusi> there are 1.1k players online but the old ping only returns 231 http://minecraftservers.org/server/16770
02:13 < Tux> Side note: Spigot hack only accepts protocol version 0x04
02:13 < Tux> So make sure to use that.
02:13 <+sadimusi> o.O
02:14 <+sadimusi> that doesn't make any sense
02:14 <+sadimusi> what exactly is spigot hack anyway?
02:17 < Eviltechie> just a version of 1.6.4 spigot with 1.7.2 protocol
02:17 < Tux> ^
02:21 < Eviltechie> As you can imagine, it's not terribly stable. Minecraft is serious buisness though and mega servers will do whatever it takes to bring the players in.
02:22 <+sadimusi> so maybe the source of my problems is not bungee but spigot
02:23 <+sadimusi> I don't think I've ever seen a new major version of minecraft being adopted this fast
02:23 <+sadimusi> 21% on my list are already running 1.7
02:24 < Eviltechie> When I ran a tf2 server, it was always empty except for when updates came out
02:24 < Eviltechie> Then it filled up within minutes
02:24 <+sadimusi> player counts seem to be lower than usual, but I can probably attribute that to the bungee/spigot bug
02:42 < Not-001> [fCraft] fragmer * r2263 5 files : Got rid of "popular IRC networks" list, which was hopelessly out of date. Improved ConfigGUI startup time some more.
02:44 < Not-001> [fCraft] fragmer * r2264 2 files : Fixed RealisticMapGenGui not responding to changes in map dimensions correctly.
02:45 < Not-001> [fCraft] fragmer * r2265 3 files : Got rid of unused "Version" property of IMapGeneratorGuiProvider interface.
02:45 < Not-001> [fCraft] fragmer * r2266 20 files : Assorted commenting, cleanup, and typo-fixing throughout the codebase.
03:06 < Not-001> [fCraft] fragmer * r2267 10 files : More typo fixes in comments and string literals.
05:03 < Not-001> [bravo] MostAwesomeDude pushed 2 commits to master [+0/-0/±2] http://git.io/C6l37w
05:03 < Not-001> [bravo] Jack Twilley a0aa6d7 - Added support for relative config locations. According to the documentation, the bravo.ini config file can be located in one of several places and the Twisted plugin should find it on startup. This pull request fixes that issue.
05:03 < Not-001> [bravo] Corbin Simpson 5545873 - Merge pull request #445 from mathuin/master Added support for relative config locations.
12:18 < Ghoul_> I see some servers that redirect people to different IP servers
12:18 < Ghoul_> it appears to be on the client side not a proxy throuhg a central server
12:18 < Ghoul_> how is this done?
12:20 < dx> why do you think it's not a proxy?
12:20 < dx> rather, what makes you reach that conclusion?
12:21 < Ghoul_> well, its not logical
12:21 < Ghoul_> the ping would be pretty terrible, and it does not seem that bad.
12:22 < Ghoul_> is it actually just a proxy?
12:22 <+Amaranth> It's always a proxy
12:22 < Ghoul_> gah
12:22 < Ghoul_> and here I was getitng all excited that we could finally write distributed servers
12:24 < dx> the ping would only be terrible if they had the proxy and the minecraft server in different continents
12:24 < dx> it's more common to put them on the same service provider / network or even same physical server.
18:39 < Not-001> [fCraft] fragmer * r2268 2 files : Fixed a rare race condition that may cause issues when multiple clients with same credentials are connecting simultaneously.
18:40 < Not-001> [fCraft] fragmer * r2269 2 files : Also fixed Player, BlockDB, and LineWrapper not implementing IDisposable properly (CA1001 and CA1063).
20:15 < benbaptist> hmm, does anyone know of a good way to parse varints in python? I'm a bit stumped
20:15 < TkTech> sadimusi: ^
20:15 < benbaptist> here's my super awful code if you want to see. :P http://pad.benbaptist.com/#3747650580480
20:18 < benbaptist> it doesn't seem elegant, and it doesn't even work anyways
20:19 < Thinkofdeath> benbaptist: https://github.com/barneygale/authserver/blob/master/authserver.py#L59
20:20 < benbaptist> Thinkofdeath, Woah, that's awesome looking! What if the varint requires over 5 bytes to define though? Probably would never happen, though. :P
20:20 < Thinkofdeath> Thats barneygale's code 
20:20 < Thinkofdeath> Also minecraft is limited to int32
20:21 < Thinkofdeath> So it would never be more than 5 bytes
20:22 < benbaptist> ah, okay
20:25 < benbaptist> Also, after the length and packet ID, can I just socket.recv() with the length parameter's return?
20:26 < umby24> length includes packet id
20:26 < Thinkofdeath> length includes the packet id
20:26 < Thinkofdeath> umby24: :)
20:26 < umby24> :D
20:26 < umby24> Thinkofdeath: I think your authserver might help me debug my client xD just got to setup the python dependencies
20:27 < benbaptist> Ohh, okay. 
20:27 < Thinkofdeath> umby24: Not mine
20:27 < umby24> o
20:27 < umby24> well you linked it anyways
20:27 < Thinkofdeath> <Thinkofdeath> Thats barneygale's code 
20:27 < benbaptist> Well, that's going to be weird then.
20:33 < Thinkofdeath> umby24: Btw this may help debug your client, http://wiki.vg/Debugging
20:35 < umby24> ..
20:36 < umby24> where was this when i was looking for it xD
20:36 < Thinkofdeath> On the main page :)
20:36 < umby24> damnit lol
20:40 < umby24> packets don't get printed :(
20:40 < Thinkofdeath> How are you starting the server?
20:41 < umby24> via batch file
20:41 < umby24> java -Xmx1024M -Xms1024M -jar minecraft_server.1.7.2.jar nogui -Dlog4j.configurationFile=D:\Documents\Apps\MC\log4j2.xml
20:43 < Thinkofdeath> java -Xmx1024M -Xms1024M -Dlog4j.configurationFile=D:\Documents\Apps\MC\log4j2.xml -jar minecraft_server.1.7.2.jar nogui
20:44 < Thinkofdeath> umby24: ^ that should work
20:44 < umby24> that worked, thank you
20:44 < Thinkofdeath> np
20:47 < umby24> Should server Id still be '-' when you are required to authenticate with minecraft.net?
20:47 < Thinkofdeath> '-' = no authentication
20:48 < umby24> ok, so as I am currently doing, \0 is authentication then.
20:49 < Thinkofdeath> \0 for the serverID?
20:51 < umby24> yeah..
20:51 < Thinkofdeath> Should be a random hex string last time I checked
20:52 < umby24> http://umby.d3s.co/scr/201329101383076303.png
20:52 < umby24> (hadn't read pkeylength at this point yet)
20:53 < barneygale> I see I've been pinged
20:54 < Thinkofdeath> barneygale: Someone needed help with varints and python so I linked them your code :)
20:54 < barneygale> oh right
20:54 < barneygale> I might work on a protocol library today
20:56 < umby24> eh fuck
20:56 < umby24> i think im reading var ints wrong
20:58 < umby24> hm. and now its ""
20:58 < Cubix>  
20:59 < Cubix> is anyone using staminus?
20:59 < Thinkofdeath> umby24: That may be right
20:59 < umby24> and that worked
20:59 < umby24> cool
20:59 < Thinkofdeath> Looking at the code now
21:00 < Thinkofdeath> Yeah, it seems to always be blank
21:01 < umby24> even when not authing?
21:01 < Thinkofdeath> If your not authing then it skips encryption
21:02 < umby24> well then. Col
21:02 < umby24> cool*
21:44 < WinstonTheCat> With the login process, when sending the Login Start, is the name referring to your username?
21:44 < umby24> WinstonTheCat: yes
21:45 < WinstonTheCat> Thanks
21:52 < benbaptist> Thinkofdeath, Woah, I just saw your message bout the debugger, that looks awesome. 
21:52 < benbaptist> I need to figure out what's going on with my proxy. I am probably making a really stupid mistake right now - http://pad.benbaptist.com/#4155099228955 Any ideas?
21:59 < Thinkofdeath> benbaptist: If i'm reading this right, you read 1024 bytes and try to parse all the packets contained in it and for each packet you forward it on
21:59 < Thinkofdeath> But self.server.socket.send(untouched) will send the full 1024 bytes read not just the packet
21:59 < benbaptist> yup. I also just tried setting it to a larger number just to see if it was cutting it off
22:00 < benbaptist> Ohhh!
22:00 < Thinkofdeath> Then you send the 1024 - (lastpacketsize) again
22:01 < benbaptist> Yup, that was the problem man!
22:01 < benbaptist> I knew it would be a stupid problem. Thanks Thinkofdeath 
22:01 < Thinkofdeath> np
22:01 < benbaptist> oh weird, now it's being thrown out of wack. But at least i can connect to the server for a few moments before it times out.
22:01 < benbaptist> s>c packet ID: 10442977968 :P
22:02 < Thinkofdeath> I'm guessing reading 1024 bytes will cut packets in half meaning the next read is wrong
22:05 < Thinkofdeath> so if you have a packet that is 16 bytes long and you only have 5 left in the buffer your program will send the 5 bytes and treat the last 11 as a new packet
22:09 < umby24> http://wiki.vg/Object_Data  <-- do we have the IDs for the object metadata types of projectile, splash potion, and minecart?
22:10 < benbaptist> Thinkofdeath, yeah, that might be the case. I increased it to 10,000 though and it still seems to be erroring out.
22:10 < Thinkofdeath> umby24: I'll look
22:10 < umby24> kthx
22:10 < benbaptist> also, this crazy out-of-body experience just happened somehow. I reconnected a few times after it kicked me off http://benbaptist.com/s/2013-10-29_17.08.38.png
22:21 < Thinkofdeath> umby24: http://wiki.vg/Object_Data
22:21 < umby24> tank you
22:21 < benbaptist> Thinkofdeath, I think it would require a lot of packets in succession for that to happen though. Basically, if I don't .recv() rapidly, the packets will pile up probably and they'll hit the 1024 max and start to cut off.
22:22 < Thinkofdeath> benbaptist: Chunk packets might help reach that
22:22 < benbaptist> Oh, true! That's probably why it fails so early on 
22:22 < benbaptist> let me massively increase the buffer
22:22 < benbaptist> or maybe I'm just doing this in a stupid way
22:23 < benbaptist> normally I don't buffer packets at all, and I just .recv() as I go, but how the length packet works has confused me a bit.
22:23 < Thinkofdeath> Maybe barneygale could help? (My python skills are limited)
22:34 < umby24> Minecarts (id 10)
22:34 < umby24> The int value itself specifies the minecart's functionality:
22:34 < umby24> so read an additional value, or has the id for minecarts changed for 1.7?
22:35 < Thinkofdeath> id = 'Type' 
22:35 < Thinkofdeath> So if type = 10 then the object data int is the type of minecart
22:36 < umby24> hm ok, so 15 for example would be hopper minecart
22:37 < Thinkofdeath> Nope
22:37 < Thinkofdeath> http://wiki.vg/Protocol#Spawn_Object <- Type | Byte 
22:38 < Thinkofdeath> Data | Int 3Shorts
22:38 < Thinkofdeath> If type = 10 and data = 1 its a chest minecart
22:39 < umby24> ah.
22:59 < umby24> " If a number other than zero is provided (for all entities), the following data is appended to the end of the object data:"
22:59 < umby24> so empty minecarts lack the ability to have speed?
23:00 < ellisvlad> ... 0.0 I didn't know http://wiki.vg/Debugging was a thing!
23:06 < Thinkofdeath> ellisvlad: 1.7 feature!
23:07 < ellisvlad> Woo!
23:16 < woder> Thinkofdeath: is there any special case where your code to read a var int could break?
23:16 < woder> (https://gist.github.com/thinkofdeath/e975ddee04e9c87faf22)
23:19 < WinstonTheCat> I've had a socketexception with readvarint at line "int k = readByte();" but mainly because I wasn't sending the packet correctly before reading
23:20 < woder> im getting weird problems but only after I receive login success
23:20 < woder> the varint is too big or it comes out at like 9923415516
23:20 < woder> (for string length)
23:38 < WinstonTheCat> Does anyone know why I'm getting an EOFException when trying this? http://puu.sh/53eZe.txt
23:41 < Ellis2> EOFException means that the stream has no more data to give, make sure there is data in the stream
23:43 < WinstonTheCat> I am sending the packets for the login correctly? I would think it should return something.
23:46 < woder> if its giving EOF your most likely sending the packet wrong
23:58 < LaxWasHere> What page is the server ping protocol thingy located, can't find it.
--- Day changed mer. oct. 30 2013
00:13 < WinstonTheCat> This https://gist.github.com/zh32/7190955 ?
00:21 < Thinkofdeath> woder: That code is from minecraft, if it has a bug its also in minecraft
00:21 < woder> hmm, ok
00:21 < Thinkofdeath> LaxWasHere: http://wiki.vg/Protocol#Status
00:49 < Ronald_Reagan> Using pymclevel (at the most recent revision) How would I get the biome at position (chunk local pos) with chunk.Biomes?
01:31 < WinstonTheCat_> Does anyone have the way to use the server json/take out the values? Trying with google's gson but it is giving me SyntaxExceptions
01:38 < iBotPeaches> Just make a class that matches the incoming JSON, then use gson
01:39 < iBotPeaches>       messagePacket = gson.fromJson(msg, MessagePacket.class);
01:56 < WinstonTheCat_> That's what I'm trying; would version and players be a specific type? This is what I have
01:56 < WinstonTheCat_> http://puu.sh/53mk6.txt
02:01 < zh32> you need to create classes for it like this http://hastebin.com/yomanurima.m
02:25 < WinstonTheCat_> Thanks that worked; all I had to do afterwards was remove the favicon from the json string.
03:58 < WinstonTheCat> What character is in the 1.7 motd that can make it go to a new line? I've tried .replace("\n","")
04:17 < Drainedsoul> have you tried search for all characters that have the Unicode line break property?
04:17 < Drainedsoul> that'd be \r, \n, and anything that has the property Zp or Zl
04:17 < Drainedsoul> maybe \v too
05:02 < Ronald_Reagan> I am generating a world in pymclevel. When I try to read biome data from that world, all of the biomes are "255". Is there any way I can work around this (supposed) bug?
12:18 < ellisvlad> Casually adding support for windows to my whole linux minecraft server :P
13:00 < redstonehelper> http://www.reddit.com/r/Minecraft/comments/1pi0hq/our_server_voted_85_in_favour_of_not_resetting/cd2ohdt
13:00 < redstonehelper> can someone remove and blacklist that? I gotta go
13:00 < redstonehelper> I'll do it later if nobody did
13:00 < redstonehelper> damn it, wrong channel. nevermind.
13:01 < SinZ> lol
13:02 < ellisvlad> Woo! That was easier than I thought it would be! http://puu.sh/53I32.jpg
13:02 < SinZ> just a shame you have numbers on the side
13:03 < ellisvlad> On the scoreboard?
13:03 < ellisvlad> I didn't know those could be removed? Can they?
13:04 < SinZ> not sure, but it is still a shame either way
13:04 < ellisvlad> :P I think they have to stay
13:04 < ellisvlad> :(
13:06 < SinZ> nice use of boss health bar though
13:09 < tyteen4a03> ellisvlad, interesting
13:10 < ellisvlad> The boss bar text changes every few seconds
17:49 < dividuum> any idea why the vanilla 1.7.2 server only lets me join a game once when using my client? I get "Failed to verify username" unless i restart the server
17:50 < dividuum> [17:49:22] [User Authenticator #9/INFO]: Disconnecting /127.0.0.1:47161: Failed to verify username!
17:50 < dividuum> Exception in thread "User Authenticator #9" java.lang.NullPointerException
17:50 < dividuum>         at ne.run(SourceFile:150)
17:51 < dividuum> i tried renewing the access token, getting new ones. No success so far
18:24 <+Prf_Jakob> TkTech: http://www.youtube.com/watch?v=hNT3ftchV-Q
18:32 < TkTech> couple o' snoipers
18:42 < dividuum> ok. i'm stupid. i was doing the session join http request *after* sending the EncryptionResponse. *sigh*. Works perfect now
22:35 < barneygale> How does the vanilla server handle a client with a wrong protocol version?
--- Day changed jeu. oct. 31 2013
01:07 < MonsieurApple> Dinnerbone: who do we petition to have the minecon capes redone?
01:11 < dividuum> why? that cape looks awesome
01:17 <+Amaranth> First thought: "Is that a face?" Second thought: "Oh, a piston!" Third thought: "Green was a bad choice for the backing color"
01:59 < barneygale> ahahaha
04:58 < wow4201> Does anyone know how to get a minecraft servers status using winsock
04:58 < wow4201> I researched lots about the packet structure, saw example in python/php 
04:59 < wow4201> but I have no idea how to structure a packet in winsock only send one type at a time example
05:00 < wow4201> Send(Protocol) Send(IP) Send(Port) Send(Type)
05:00 < wow4201> Send only accepts one parameter and thats bytes
05:00 < wow4201> so how would I mash all those Protocol,IP,Port,Type into bytes and send it. 
05:00 < wow4201> It makes no sense to me
05:00 < wow4201> That winsock doesn't allow you to structure a packet together and send it
05:01 < wow4201> like you can do in pretty much every other language
05:02 < wow4201> If anyone can put together anything in C#/VB to get a server status I will pay lots.
05:08 < iBotPeaches> wow4201: https://github.com/SirCmpwn/Craft.Net
05:09 <+SirCmpwn> TkTech: I just noticed that you have me set with +Vv in chanserv and thus your +q does not have any effect
05:36 < Drainedsoul> wow4201: Winsock isn't a language, so saying you can't do something in winsock "like you can in pretty much every other language" is meaningless
05:36 < wow4201> Yeah I know lol
05:36 < Drainedsoul> also: Winsock absolutely does let you send many types at a time, from a contiguous buffer
05:36 < wow4201> I realized that was a dumb statement
05:36 < wow4201> I was using winsock from vb so it's probably much more limited using the functions
05:37 < Drainedsoul> http://msdn.microsoft.com/en-us/library/windows/desktop/ms741542(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/ms742203(v=vs.85).aspx in fact, unlike Berkeley Sockets, WinSock allows you to send not just multiple bytes, but multiple buffers at the same time
05:37 < wow4201> I just don't have a lot of expierence with networking/packets.
05:37 < wow4201> It was fine just sending single bytes which is all I had to do before
05:38 < wow4201> now it requires a structured packet with lots of data 
05:38 < wow4201> and have no idea how to achieve this using VB
05:38 < Drainedsoul> this has nothing to do with winsock
05:38 < wow4201> I know it's just not very friendly
05:39 < Drainedsoul> but you have to understand, what you are using is not WinSock per se, it's a wrapper around some socket layer, which may or may not be WinSock depending on what platform you're running on (assuming VB.NET)
05:40 < Drainedsoul> that said, also assuming you're using .NET, you can either use the BitConverter class to get the byte representation of certain types, or you can use a NetworkStream
05:43 < wow4201> Hopefully after reviewing Craft.net I'll have a better understanding
05:43 < wow4201> The problem I don't understand with converting to bytes is
05:43 < wow4201> When thers like 4 different values in the packet how you would define this
05:44 < wow4201> or structure the packet
05:44 < wow4201> when all i can do is Send(Byte Value)
05:45 < wow4201> Confusing stuff I need to go read a book or something
05:45 < Drainedsoul> to "structure the packet", you just send all its bytes sequentially.  The calls to Send are not informative to the receiving end, all the receiving end sees is a sequence of bytes
05:45 < Drainedsoul> whether you build that sequence in memory, and send it all at once, or send it incrementally, as long as nothing is sent in between, it will arrive and be processed in order and as if it were contiguous
05:45 < wow4201> so your saying you can can do something like
05:46 < wow4201>         s.Send(BitConverter.GetBytes(IPLength), 3, 0)
05:46 < wow4201>         s.Send(BitConverter.GetBytes(0), 1, 0)
05:46 < wow4201>         s.Send(BytesProcotol, BytesProcotol.Length, 0)
05:46 < wow4201>         s.Send(BytesServerIP, BytesServerIP.Length, 0)
05:46 < wow4201>         s.Send(BytesPort, BytesPort.Length, 0)
05:46 < wow4201>         s.Send(BytesState, BytesState.Length, 0)
05:46 < wow4201> You don't have to put all those together in one Send statment
05:46 < Drainedsoul> no, you don't.  the Send statement is between you and the stream.  The other end of the stream has no idea where one call to send began and another ended
05:47 < Drainedsoul> TCP/IP is processed as a stream, which means that it's continuous, despite the fact you send it incrementally
05:47 < Drainedsoul> the only idea of "messages" is that which a protocol imposes on it
05:51 < wow4201> Thanks for your help Drainedsoul
05:51 < wow4201> I think the problem from here is understanding the sequence of bytes to send
05:52 < wow4201> Because using the scripts I've seen in Php & Python that's the best I could come up with
09:18 < AlJaMa> Hey everyone. Does anyone know exactly what packets the MC Client wants to see before it releases you from the "downloading terrain" screen? 
09:18 < AlJaMa> (1.7.2)
09:19 < AlJaMa> from the start I'm sending (Join Game), (SPAWN Position), (Player Abilities), and (HELD ITEM CHANGE)
09:20 < AlJaMa> Then I begin getting back lots of Player Position packets but I'm stuck at the downloading terrain screen.
09:20 < AlJaMa> (Oh yes, and I forgot, I am sending chunks of air)
09:23 < Thinkofdeath> AlJaMa: Player Position and Look (i think)
09:24 < AlJaMa> Thinkofdeath: I'll give it a try. Thanks :) (also... are you talking the (player position  and look) packet or the two separate ones hahaha... such a strange split)
09:25 < Thinkofdeath> AlJaMa: http://wiki.vg/Protocol#Player_Position_And_Look
09:25 < AlJaMa> got it, thanks
09:36 < AlJaMa> Thinkofdeath: worked like a charm. Thanks
09:36 < Thinkofdeath> np
11:09 < wow4201> Anyone have expierence with https://github.com/SirCmpwn/Craft.Net
11:10 < SinZ> one of the best C# Libraries for MC around
11:10 < wow4201> There nothing inside the externals/fNbt folder therefore won't compile
11:10 < wow4201> and theres no documentation on this
11:10 < SinZ> you didn't clone with recursive enabled
11:10 < SinZ> s/clone/pull
11:17 < wow4201> Thank you SinZ
11:18 < wow4201> The kindness of people on here is great :)
11:22 < wow4201> Hmm problem with compiling 1.7 though
11:22 < wow4201> Master Compiled fine
11:27 < ellisvlad> Took forever, but AStar in 2D is done! Woo! http://puu.sh/54Cii.jpg
11:39 < wow4201> Do Craft.Net DLL's work with VB?
11:39 < SinZ> don't see why it wouldn't work, but why VB
11:40 < SinZ> VB DLL's work fine in C#
11:41 < wow4201> I programmed a server status program in VB to monitor 100+ server instances
11:41 < wow4201> I could probably redo it in C# but it would be much easier to merge these new functions into it then to write a new program from scratch
11:43 < wow4201> Nevermind it works with VB
11:43 < wow4201> Just doesn't seem to work with 2010
11:43 < wow4201> But it does with 2012
12:10 < wow4201> Can anyone assist me using Craft.net functions
21:34 < WinstonTheCat> Does anyone know why when joining some 1.7 servers I get the error "ClassCastException: bit cannot be cast to fm"?
21:37 < AlphaBlend> because those servers are bad
21:38 < AlphaBlend> those aren't legit 1.7 servers, they are protocol modified servers allowint 1.6.4 clients onto 1.7 servers
21:38 < AlphaBlend> i would assume anyway
21:39 < WinstonTheCat> So that means you would need to join the server with a 1.6.4 client?
21:41 <+md_5> WinstonTheCat its a client bug
21:41 <+md_5> happens in single player
21:41 <+md_5> search the mojang issue tracker if you dont believe
21:41 < WinstonTheCat> Alright
21:51 < WinstonTheCat> I see now; one other thing, what causes this error sometimes when joining a server? http://puu.sh/5513v.png
--- Day changed ven. nov. 01 2013
00:10 < dividuum> are web links in chat generally not working in 1.7.2?
00:12 < Thinkofdeath> dividuum: I think you can recreate them server side using json but yes they don't work automaticly anymore
00:12 < dividuum> recreate on the server side?
00:13 < dividuum> i'm fine with modifying whatever it takes :-)
00:13 < Thinkofdeath> {"text":"http://google.co.uk","clickEvent":{"action":"open_url","value":"http://google.co.uk"}}
00:13 < dividuum> so the link has to be in its own chat line?
00:14 < Thinkofdeath> Nope
00:14 < dividuum> where is that json documented. so i can stop asking you? :)
00:14 < Thinkofdeath> {"text":"hello ", "extra":[{"text":"http://google.co.uk","clickEvent":{"action":"open_url","value":"http://google.co.uk"}}]}
00:14 < Thinkofdeath> and https://gist.github.com/thinkofdeath/e882ce057ed83bac0a1c
00:15 < dividuum> oh. wow. i guess i'll have to take a close look. thanks!
00:16 < Thinkofdeath> np
00:20 < dividuum> do i understand that correct that all the elements in the toplevel object can be repeated in the "extra" array?
00:21 < dividuum> i guess i'll just play around with it
00:24 < Drainedsoul> dividuum: that is the way it has worked in my experience
00:45 < dividuum> awesome. works. thanks again to both of you
00:53 < WinstonTheCat> Does anyone know what could cause this error when joining a server? http://puu.sh/5513v.png
01:16 < dividuum> when do you get this?
01:33 < barneygale> WinstonTheCat: a vanilla server?
01:38 < WinstonTheCat> I think it may be a bungee server but I'm not sure
02:05 < barneygale> wait, when /joining/ a server?
02:06 < barneygale> hmmm
02:06 < barneygale> is it a 1.6.4 server with hacked 1.7 protocol support?
02:06 < barneygale> WinstonTheCat: ^
02:47 < WinstonTheCat> It might be but I don't think so.
05:04 < Drainedsoul> Little annoyance: The fact that Berkeley socket functions take struct sockaddr pointers, not void pointers.  It's not like the actual type of the struct is meaningful to the function. -_-
05:43 < nickelpro>  Drainedsoul: The same could be said of almost any C func that takes a pointer as a parameter
05:54 < Drainedsoul> nickelpro: What I mean specifically in this case, is that I've never passed a struct sockaddr to that function, so taking a void * would make it far more usable
05:55 < Drainedsoul> you almost are always passing struct sockaddr_in or struct sockaddr_in6 or -- even better -- struct sockaddr_storage to it
05:56 < nickelpro> Ya, it's just a leftover from a bygone era of network programming
05:57 < nickelpro> Pointer types are always more like suggestions in C anyway, no sufficiently complex program sticks with them and doesn't cast about
05:58 < nickelpro> I rarely interface directly with sockets now anyway, mostly program angainst libuv or libev
06:04 < Drainedsoul> if I wanted to drag another dependency into this project I'd do that, but I don't :\
16:08 < Not-002> [netherrack] thinkofdeath pushed 1 commit to master [+0/-0/±1] http://git.io/l3rmCw
16:08 < Not-002> [netherrack] thinkofdeath c08ca0f - format/msgpack: Fix building on 32bit
16:28 < Not-002> [netherrack] thinkofdeath pushed 1 commit to master [+0/-0/±1] http://git.io/dDLqhQ
16:28 < Not-002> [netherrack] thinkofdeath 9bfe219 - world: fix possible deadlock
18:45 < Not-002> [fCraft] fragmer * r2276 2 files : Fixed ClientName defaulting to null instead of "Unknown" for non-CPE clients. Also fixed a very rare case where SessionDisconnected event could be raised without a null IP and no matching SessionConnected event, in case a network connection is aborted under Mono before the IP is obtained. Thanks Mono.
18:50 < Not-002> [fCraft] fragmer * r2277 4 files : Fixed year in README, made assorted documentation improvements
21:41 < Not-002> [netherrack] thinkofdeath pushed 1 commit to master [+0/-0/±7] http://git.io/E3HcJw
21:41 < Not-002> [netherrack] thinkofdeath 50e9496 - /,blocks: documentation improvements
21:49 < barneygale> Am I right in thinking that when implementing a yggdasil client, I need to store my clientToken and my accessToken between sessions?
21:50 < nickelpro> yes
21:50 < nickelpro> or at least
21:50 < nickelpro> That's what mine does
21:51 < barneygale> OK, thanks
21:57 < barneygale> The wiki.vg/Authentication page says "Whenever a Mojang service requires a session ID, you can simply combine a valid accessToken with the corresponding profile identifier", yet it doesn't seem to list any examples of this
21:58 < barneygale> i.e. no examples of things that require a session ID