02:19 < Bibl> 			}
02:19 < Bibl> 		}).start();
02:19 < Bibl> And it respawned the local player
02:19 <+SpaceManiac> pastebin would be nice
02:19 < benbaptist> you should use pastebin or gists instead of pasting code directly into IRC
02:19 < Bibl> Now it sends health updates but before I was receiving nothing of the sort
02:19 < Bibl> o
02:19 < benbaptist> or pasteben ;D http://pasteben.benbaptist.com/
02:19 < Bibl> ^_^
02:22 < Bibl> Still only receive health updates after force respawning
02:22 < benbaptist> are you logging in already dead?
02:23 <+SpaceManiac> I'd expect you get one good health update after logging in that indicates you're dead
02:23 < benbaptist> yeah
02:23 < benbaptist> you probably don't get them rapidly, but only when your health actually updates.
02:23 < benbaptist> so if you're not relogging after implementing, that's your issue.
02:33 < Bibl> I'm hitting the player and still receive no health updates.
02:48 < Commander_> Hellp i Have a Problem: http://www.spigotmc.org/threads/stress-testing-servers.175/page-10#post-310271
03:50 < Jumla> BarneyGale once posted about a 1.8 protocol update somewhere. Does anyone know if that's still a thing?
03:50 < dx> protocol update of what specifically?
03:50 < dx> a library? or the docs?
03:51 < dx> docs here http://wiki.vg/Pre-release_protocol
03:51 < Jumla> http://www.reddit.com/r/mccoders/comments/2dshmq/working_on_a_foss_18_client_17_server_proxy/
03:52 < dx> oh fun
03:52 < dx> quarry is definitely still a thing
03:55 < Jumla> F
04:13 < dx> f.
06:56 < AgentK> LOL
06:56 < AgentK> that moment
06:56 < AgentK> when you're confused about ArrayIndexOutOfBoundsException's coming from the Map Chunk Bulk reader
06:56 < AgentK> and you realize that you forgot to send the data array
15:44 < Bibl> What am I doing wrong?
15:44 < Bibl> http://pastebin.com/ykBXKF95
16:59 < eddyb> dx: mfw Rust gets patented by Microsoft http://www.freepatentsonline.com/y2014/0196015.html
17:00 < eddyb> I wonder where can this be submitted to EFF's stupid patent of the month
17:04 < dx> eddyb: that's not a rust patent, i want my money back
17:05 < eddyb> dx: lifetimes are a big part in Rust's safety model
17:08 < eddyb> Cyclone (or whatever it's called) was the prototype, while Rust has the first (AFAIK) large ecosystem built atop those kinds of safety guarantees
18:03 < vsg1990> Anyone in here familiar with using EntityFallingBlock w/ Minecraft Forge?
18:05 <+SpaceManiac> You might have more luck in Forge's IRC channel, #minecraftforge on Esper
18:06 < vsg1990> Ah, didn't know that had that.  Thank you.
18:06 < vsg1990> they*
18:16 < Drainedsoul> eddyb: The abstract seems like it's pretty much describing RAII
18:17 < eddyb> Drainedsoul: RAII doesn't imply explicit lifetimes
18:17 < eddyb> I'm hearing this could be for M#. I wonder if that will end up as a half-assed Rust clone
18:18 < Drainedsoul> eddyb: Uhh, how does RAII not imply explicit lifetimes?
18:19 < eddyb> ugh
18:19 < eddyb> Drainedsoul: it's a bit hard to explain what lifetimes is referring to in the patent, but it's not RAII
18:20 < eddyb> Drainedsoul: it's about *references*, like T& in C++
18:20 < eddyb> imagine T& carrying around constraints that made accessing it always valid
18:21 < eddyb> (you do require suspension of disbelief because it's hard to impossible to make C++ safe at the type level like that)
18:21 < Drainedsoul> I think it's called std::shared_ptr
18:21 < eddyb> I guess that's not unlike what Cyclone did, on top of C
18:21 < eddyb> Drainedsoul: no, that's ref-counting
18:21 < Drainedsoul> and the pointer remains valid.
18:22 < eddyb> we're talking relative time interval typing
18:22 < eddyb> with 0 runtime cost
18:23 < eddyb> there are only two languages that I know of that do this, and one of them is barely a prototype
18:24 < Drainedsoul> "[...] the lifetime references a particular scope in a manner that the compiler generates computer-executable instructions that enforce the lifetime of the reference to be a function of (e.g., no longer than) the lifetime of the particular scope."  I can't see what this insinuates that RAII doesn't.
18:24 < eddyb> that's borrow checking, I think
18:26 < eddyb> Drainedsoul: well, it may be harder to see through the web is they don't use it for safety
18:26 < eddyb> because that's where it really wins
18:26 < Drainedsoul> "[...] advances safety in system programming [...]" umm...
18:27 < eddyb> oh they do? not clear from the abstract
18:27 < Drainedsoul> ...it literally says that in the abstract
18:27 < Drainedsoul> that's a quote from the first sentence of the abstract
18:27 < eddyb> Drainedsoul: I just need someone who can into legalese
18:28 < eddyb> hang on, their examples aren't interesting
18:28 < eddyb> Drainedsoul: ah, "language extension" - that's why it smells like RAII at first, I think
18:28 < eddyb> they are mixing up concepts though
18:29 < eddyb> "computer storage media includes RAM, ROM, EEPROM, CD-ROM" NOPE NOPE
18:30 < eddyb> I don't have the patience to find out whether they include the definition of a Turing machine
18:31 < eddyb> Drainedsoul: [0034]
18:31 < eddyb> for some reason I can't copy from the PDF
18:32 < eddyb> "This allows a reference to be scoped to a particular object instance. The resulting reference can live no longer than the object to which it is related."
18:32 < Drainedsoul> what's your point?
18:33 < eddyb> this can be done in Rust, with no runtime overhead. in C++ you get a compiler warning if you screw up, but only if you're really lucky (and you're not using T*)
18:33 < Drainedsoul> if you use raw pointers that's your problem
18:33 < Drainedsoul> std::unique_ptr / std::shared_ptr
18:33 < eddyb> shared_ptr is runtime refcounting
18:34 < eddyb> you won't use that to pass around a reference to a field in a larger object, that's just silly
18:34 < Drainedsoul> okay?  If you have multiple things pointing at one thing, and you want the lifetime of the pointee to be the length of the longest of those, you have runtime overhead
18:34 < eddyb> no you don't
18:34 < Drainedsoul> such is the raison d'etre of std::unique_ptr
18:34 < eddyb> the lifetime of the pointee is defined by your everyday RAII rules
18:35 < eddyb> the references to it have to obey that lifetime
18:35 < Drainedsoul> what's your point?  This is why you store the std::unique_ptr / std::shared_ptr rather than a T &
18:35 < eddyb> "The resulting reference can live no longer" - it doesn't extend the lifetime of what is it pointing to
18:35 < eddyb> Drainedsoul: that's just slightly better than a GC
18:35 < Drainedsoul> by using T & / T * you're taking manual control of lifetimes
18:35 < eddyb> sure, this isn't C++
18:36 < eddyb> C++ has no real safety whatsoever
18:36 < Drainedsoul> lol
18:36 < eddyb> Rust can enforce this lifetime thing with no runtime overhead
18:36 < Drainedsoul> so can C++
18:37 < eddyb> C++ doesn't have lifetime typing
18:37 < Drainedsoul> it has RAII
18:37 < eddyb> unless we're talking about C++2z
18:37 < eddyb> yess, but RAII is not enough
18:37 < eddyb> RAII is local
18:37 < Drainedsoul> how
18:37 < Drainedsoul> take a unique_ptr, std::move it somewhere else
18:37 < eddyb> RAII merely defines the lifetime of a variable on the stack
18:38 < Drainedsoul> no
18:38 < eddyb> Drainedsoul: by moving you re-root it
18:38 < Drainedsoul> RAII can control the lifetime of objects within other objects, allocated on the heap
18:38 < eddyb> and what holds references to those heap objects?
18:38 < Drainedsoul> std::unique_ptr / std::shared_ptr / some other RAII wrapper
18:38 < eddyb> I mean, we're excluding globals because nobody should put their shit in globals
18:38 < eddyb> Drainedsoul: yupp, and those live in other objects, or, ultimately, on the stack
18:38 < Drainedsoul> sure, what's your point?
18:39 < eddyb> RAII is rooted on the stack
18:39 < eddyb> that defines your lifetimes
18:39 < Drainedsoul> and?  So is your program execution
18:40 < eddyb> C++ has no way of cheaply enforcing that lifetimes are respected
18:41 < eddyb> s/cheaply/at zero cost
18:41 < eddyb> shared_ptr can't enforce that no handle outlives the main one
18:42 < eddyb> unless they're all weak_ptr's... which would work but then that has an even greater overhead
18:42 < eddyb> you end up with something that half the time is worse than a GC
18:43 < eddyb> Drainedsoul: now, Rust allows you to write a perfectly safe function that takes an objects and returns a reference to one of its fields with 0 runtime overhead and no potential for misuse
18:44 < eddyb> fn ref_x<'a, T>(v: &'a Vec3<T>) -> &'a T { &v.x } - which more recently can be written as: fn ref_x<T>(v: &Vec3<T>) -> &T { &v.x }
18:45 < eddyb> the 'a is lifetime notation - the function is defined to return a reference *with the same lifetime* as the reference it received
18:46 < eddyb> Drainedsoul: a type system feature like that is what's being patented
18:48 < dx> eddyb: is that perl?
18:50 < eddyb> dx: do you think your question deserves a serious answer?
18:50 < dx> eddyb: i don't
18:51  * eddyb has resisted feeding the troll for 3 minutes. new personal record \o/
18:52 < dx> if only we had an english compiler that allowed us to mark questions that don't expect a return value without hanging the whole process for 3 minutes
18:53 < eddyb> dx: that would be -> ! in Rust
18:54  * eddyb shows himself out
18:54 < dx> lol
18:54 < dx> eddyb: so, is that perl? -> !
18:55 < eddyb> ! is the "bottom" type, i.e. a type without a value. a function returning ! has no possible return values, and as such can never possibly return - it's used in lieu of a noreturn attribute
18:55 < eddyb> dx: no, the -> precedes the return type of a function, while ! is the return type itself
18:55 < dx> dammit eddyb
18:56 < dx> you're correcting my made up syntax
19:16 < eddyb> dx, Drainedsoul: oh I found the source: http://www.reddit.com/r/rust/comments/2elval/post_ms_scoped_keyword_brings_raii_to_c/ (with more details inside)
20:13 < Bibl> This is really wierd
20:13 < Bibl> I don't receive health packets unless I die and force respawn
20:14 < Bibl> What is happening D:
20:55 < Bibl> Wow
20:55 < Bibl> I'm receiving health updates as entity metadata
21:17 <+SirCmpwn> it wouldn't be minecraft if there weren't three ways to do the same thing and they were all in use
22:25 < vaskrate> Hi, I'm writing server and i have problem when client ping server he send 0x0F packet then i send confirm transcation packet. After that client should send mi 0x00 but sending me 0x01 what's wrong?
22:26 <+SpaceManiac> What version is this, and what are you referring to by the confirm transaction packet?
22:28 < vaskrate> SpaceManiac: version 1.7.10, protocol id 5, i think so(0x32, action_number, accepted)
22:30 <+SpaceManiac> that transaction packet is a response to a window click, the client then responds with its own (the 0x0F) *if* you denied the transaction
22:31 <+SpaceManiac> C->S 0x00 is keep alive, C->S 0x01 is chat message, not sure what you're expecting to have happen
22:31 < vaskrate> after 0x0F, client send me 0x01 not 0x00
22:32 <+SpaceManiac> 0x01 is chat message, maybe its contents will reveal why it is being sent?
22:33 < vaskrate> i want to receive 0x00 to get next_state
22:34 <+SpaceManiac> you're sending all the wrong packets then
22:34 <+SpaceManiac> the client sends one Handshake/0x00 packet when it connects
22:35 <+SpaceManiac> (before you send anything)
22:37 < vaskrate> on start i get '\x0f\x00\x05\tlocalhostc\xdd\x01' 
22:37 < vaskrate> but i using struct so i waiting for unsigned int packet
22:37 <+SpaceManiac> 0x0f is length of packet, not packet id
22:38 < vaskrate> http://wiki.vg/Protocol#Confirm_Transaction_2
22:38 <+SpaceManiac> yes there is a packet (in the PLAY state from client) which has ID 0x0F
22:38 <+SpaceManiac> packets are also length-prefixed, which is what the 0x0f in your example is
22:39 <+SpaceManiac> (the protocol is in Handshake state, not Play state, so that'd be an invalid packet id at the time)
22:40 <+SpaceManiac> 0x0f -> length, 0x00 -> packet id, 0x05 -> protocol version, '\tlocalhost' is the server address, 'c\xdd' is the port, '\x01' is the next state
22:41 < vaskrate> so i must split this, yes?
22:42 <+SpaceManiac> yes
22:43 < vaskrate> ok, i try this. Thanks for your help :)
--- Day changed mer. août 27 2014
00:04 < vaskrate> SpaceManiac: i tried many ways.  '\x0f\x00\x05\tlocalhostc\xdd\x01' is handshake then is request '\x01\x00' on request i tried to send json with motd etc but this doesn't working
00:35 < portalBlock> pop
02:39 < Bibl_> hmm
02:39 < Bibl_> bot doesnt seem to move
02:45 < Bibl_> i can even send head y and not get kicked
02:46 <+SpaceManiac> maybe you have foot/head Y backwards?
02:46 <+SpaceManiac> (is your head Y 1.62 above feet?)
02:47 < Bibl_> [x=0.5031747265602462, feetY=50.62000000476837, headY=52.24000000953674, z=1.857978036549281, yaw=-0.60001, pitch=0.60001874, onGround=false, pos=true, rot=true]
02:48 < Bibl_> hmm
02:48 < Bibl_> after further debugging
02:49 < Bibl_> sometimes the client sends x=0 y=0 z=0 and other times it sends the real info
02:49 <+SpaceManiac> is that before the server has sent it its position?
02:51 < Bibl_> :o
02:51 < Bibl_> its after
04:57 < Mathuin> Anyone know if there's a way with mcedit to add biomes to a world that doesn't have them?
05:03 < redstonehelper> sethbling made a filter for that
14:28 < vaskrate> Hi, when i unpack varint protocol version i get 15 instead of 5
15:03 < bgale> vaskrate, show us yr code
15:11 < vaskrate> ok, one second
15:14 < vaskrate> http://pastebin.com/xRZtJ00B - it's python
15:28 < edlothiol> vaskrate: you know that struct.unpack doesn't change the string, right? you're always reading from the beginning of the packet
15:32 < vaskrate> omg, i'm stupid! Thanks!
15:44 < TkTech> vaskrate: Python Yo, all strings are immutable.
16:14 < ellisvlad> Hi guys, making a C++ MC Server, question about 1.8 logins.My public key is being rejected by the client with "Public key reconstitute failed!". In 1.7.10 I had no problem with this. I'm using http://wiki.vg/Pre-release_protocol#Clientbound_6 but my public key seems to be rejected?
16:22 <+SpaceManiac> ellisvlad: what format are you sending the public key in?
16:29 < vaskrate> Hi again, I unpack almost the whole packet but when unpack varint with protocol version i get 0 instead of 5
16:31 <+SpaceManiac> are you sure you're unpacking the varint from the right place?
16:31 < vaskrate> yes
16:32 <+SpaceManiac> code and input example?
16:35 < ellisvlad> wtf.. Sorry.. I don't know how, or when this happened.. but it was completely my mistake.. I was sending the private key instead of the public one ;)
16:36 <+SpaceManiac> Ah, silly... at least it was something easy
16:36 < vaskrate> '\x00\x05\tlocalhostc\xdd\x01 -> when i unpack this handshake i got error unsgined short requires a string of length 2 but when i unpack this packet -> '\x0f\x00\x05\tlocalhostc\xdd\x01' protocol_version = 0 and the rest is good
16:37 <+SpaceManiac> only one of those could actually be correct input to your parsing since one has a length prefix and the other doesn't
16:37 <+SpaceManiac> what does your unpacking function look like?
16:38 < vaskrate> http://pastebin.com/1BDC9TNb
16:41 <+SpaceManiac> vaskrate: self.getBuffer(length * 2) in string() is wrong (outdated?) - the length is how many bytes to read
16:41 <+SpaceManiac> also varints may be more than one byte so you may need to take that into account
16:43 < vaskrate> i get protocol version 0 because in string() length means protocol version uhh ;d
16:43 <+SpaceManiac> what order are you calling these methods in to parse the handshake?
16:44 < vaskrate> packet_id, protocol_version, address, port, next_state
16:45 <+SpaceManiac> okay, so you handle the length prefix elsewhere, meaning you want to unpack the '\x00..' version
16:46 < vaskrate> but how get string length?
16:46 <+SpaceManiac> it's a varint
16:46 <+SpaceManiac> you .getBuffer(length * 2) - don't multiply by 2
16:47 < vaskrate> when i don't multiply by 2 i get address: '\loca'
16:47 <+SpaceManiac> you are reading in the wrong order or something, then
16:47 <+SpaceManiac> make sure your input matches what your code is doing to it
16:48 <+SpaceManiac> I have to dash, but good luck
16:48 < vaskrate> ok, thanks for your help
16:50 < vaskrate> I was able to do it !;
16:50 < vaskrate> ;d
17:10 < Mathuin> redstonehelper: couldn't figure out how to apply the filter. :-(
17:13 < vaskrate> Why when i send json response to client, nothing happened?
17:30 < vaskrate> how to length packet id?
17:31 <+SirCmpwn> vaskrate: rephrase your answer in the form of a trout
17:32 < vaskrate> ok :P How to count packet_id?
17:32 <+SirCmpwn> vaskrate: rephrase your answer in the form of a trout
17:33 <+SirCmpwn> I have no idea what you're asking but you might gain some insight from reading this: https://github.com/SirCmpwn/Craft.Net/blob/master/source/Craft.Net.Networking/NetworkManager.cs
17:33 < vaskrate> i want to send packet to client but packet have field length (length of packet data + length of packet id). How to get length of packet ID?
17:42 < bgale> vaskrate, packet id is a varint. You determine its length by unpacking it
17:42 < bgale> https://developers.google.com/protocol-buffers/docs/encoding#varints
18:10 < SinZ> how many bytes did it take to fit the packetID in the varint
18:10 < SinZ> that is your length
18:57 < vaskrate> Why when i pack varint 84 i get 'T' ?
18:58 < Mathuin> I never really appreciated the Go Playground until recently.  It's so nice to say "Show me your code" in a runnable environment.
18:58 < Mathuin> vaskrate: you would probably find it easiest to use someone else's already-written varint library.
18:59 < vaskrate> at the moment i'm using someone varint library.. ;/
19:00 < Mathuin> Do they have tests and examples?
19:02 < Drainedsoul> vaskrate: Why does that seem unusual?
19:03 < Drainedsoul> 'T' is U+0054, which means that it has a decimal value of 84
19:05 < Drainedsoul> Always nice when people ask questions and then vanish.
19:07 < morfin> hello
19:08 < morfin> did anybody profile vanilla server of Minecraft?
19:08 < Drainedsoul> morfin: Wut.
19:10 < vaskrate> http://repl.it/Xeg
19:11 < Mathuin> Okay, so what's the surprise?
19:12 < Drainedsoul> [10:00] <Drainedsoul> 'T' is U+0054, which means that it has a decimal value of 84
19:13 < vaskrate> 'z\x00z{"players": {"max": 10, "online": 0}, "version": {"protocol": 5, "name": "1.7.10"}, "description": {"text": "blah, blah"}}' this is good packet?
19:13 < morfin> i mean profiling server to find out bottlenecks
19:13 < morfin> except IO of course
19:14 < Drainedsoul> vaskrate: Why are you trying to express binary data as ASCII?
19:14 < Drainedsoul> Do you expect us to consult an ASCII table to figure out what the value of 'z' is?
19:16 < morfin> hm?
19:17 < morfin> just another code to write varints
19:41 < Drainedsoul> New metadata type, 7, 12 bytes(3 floats?), used on armor stand <= is there any kind of name/purpose for this?
19:41 < Drainedsoul> i.e. is there any way at this point to give that type a more sensible name than std::tuple<float,float,float>?
19:41 <+SpaceManiac> If I had to guess, it's the orientation of the arms or something
19:42 <+SpaceManiac> But I haven't verified anything yet
19:44 < Drainedsoul> :(
21:37 < eddyb> dx: http://www.reddit.com/r/rust/comments/2er136/hematite_vs_minecraft_2/
21:39 < dx> eddyb: niiiice
21:51 < eddyb> dx: and it just got merged https://github.com/PistonDevelopers/hematite/pull/72
21:52 < dx> :D
22:02 < deltab> no need for a table: it's 60 + 10 + A = 7A = 80 - 6, in decimal 128 - 6 = 122
22:08 < dx> wot
22:09 < dx> eddyb: also lol "bvssvni changed the title from Basic Minecraft chunk rendering for 1.8-pre2. to Awesome Minecraft chunk rendering for 1.8-pre2. 22 minutes ago"
22:09 < eddyb> dx: yupp
22:09 < dx> it really is awesome
--- Day changed jeu. août 28 2014
05:18 < morfin> so nobody profiled Minecraft server?
05:20 < zml_> morfin: most people in here tend to work on custom servers/clients rather than dealing with the mojang codebase.
05:22 < Drainedsoul> Dealing with the Mojang codebase seems like a losing bet.  Or, at least, a very painful one.
12:00 < ellisvlad> Hi guys, with 1.8 NBT not having a length prefix anymore. How is an empty NBT sent? Just a 0x00 ?
12:01 < ellisvlad> ..Yup it is, Just tried it :P
13:07 < ellisvlad> Grr.. Now a question about naming the enderdragon... Whatever I try, the name at the top of the screen doesn't change in 1.8..
13:09 < ellisvlad> http://pastebin.com/q89eEVXf is my code
15:01 < ellisvlad> The full packet being sent is: http://pastebin.com/xnJvdKA6
15:01 < ellisvlad> Any ideas?
16:44 < Bibl> Do I actually need to wait the correct amount of time when digging?
16:45 < Bibl> Because I'm testing and waiting 2 seconds after sending the start digging packet before sending the finish digging packet
16:45 < Bibl> And it doesn't actually dig the block.
17:27 < morfin> 2 seconds?
17:27 < Mathuin> Wait, 1.8 includes changes to NBT?!  Why!?!
17:28 < morfin> what changes?
17:28 < Mathuin> ellisvlad asserts that NBT will no longer have a length prefix.
17:28 < morfin> what
17:29 < morfin> that sounds bad for me
17:29 < Mathuin> I agree entirely, thus my plaintive wail to the deities.
17:31 < morfin> still wondering did anybody even profile Minecraft server?
17:31 <+Amaranth> I guess that means you need to work a streaming deserializer into packet reading
17:32 < morfin> streaming deserializer?
17:32 < Mathuin> Amaranth: I think that's crazytalk.  Sigh.
17:32 < morfin> like with varints?
17:32 < morfin> *like as - read until something reached
17:32 < morfin> into ByteArray or something like that
17:32 <+Amaranth> Like parse NBT as you read so you know when to stop
17:33 < morfin> bullshit
17:33 < morfin> you'll have to parse whole thing on-fly
17:33 < morfin> would not that slow down perfomance?
17:37 < Thinkofdeath_> Minecraft always parses it anyway, so no
17:37 < bgale> that's annoying
17:37 < bgale> guessing the length prefix was removed because it's not uncompressed?
17:37 < Mathuin> This is all presupposition based on what ellisvlad said, I haven't seen it documented anywhere.
17:37 < bgale> err
17:37 < bgale> s/not/now
17:38 < Mathuin> Holy crap, 1.8 comes with plenty of extra tags.
17:47 < Bibl> My analyser will probably break because of 1.8 >.<
17:47 < Bibl> Also broke from 1.6 to 1.7
17:49 < Mathuin> such is the nature of upgrades.
17:49 < Mathuin> ... especially with Mojang. :-)
17:50 < Bibl> Not with Runescape
17:51 < Bibl> Updater lasted mostly unbroken from about 200-400
17:51 < Bibl> 200 revisions with barely any breaks
18:27 < Drainedsoul> Amaranth: Why would you need to do that?  Aren't NBT fields the last field in their respective packets?  You have a length prefix.
18:27 < Drainedsoul> (for the overall packet, that is)
18:29 < Thinkofdeath_> Drainedsoul: slot data
18:33 < Drainedsoul> isn't slot data always at the end of the associated packet?  And the NBT is at the end of the slot data structure?
18:34 < Mathuin> NBT is also used in files.
18:34 < Thinkofdeath_> Drainedsoul: http://wiki.vg/Pre-release_protocol#Player_Block_Placement
18:34 < Thinkofdeath_> Drainedsoul: and http://wiki.vg/Protocol#Window_Items
18:38 < Drainedsoul> does Player Block Placement use the Position type/serialization method or not?  The change log says it does, the packet itself says it doesn't @_@
18:38 < Drainedsoul> or does it only use it for X/Y/Z, not Cursor X/Y/Z?
18:38 < Thinkofdeath_> Only for X/Y/Z
18:39 < Drainedsoul> Ah, of course, Mojang "consistency"
18:39 < Thinkofdeath_> if it was used for cursor the packet would be larger :)
18:39 < Drainedsoul> sounds like premature optimization to me
18:43 < Drainedsoul> at least this streaming NBT thing is an easy fix
19:11 < Bibl> Does the server check if the wait time between the digging start and digging finish is right?
19:12 < Bibl> For example if I'm trying to break a block with my current tool and I should wait 750 ms before sending the finish packet and I send it after 1000 ms will the server discount it?
21:27 < morfin> hm
21:27 < morfin> Bukkit really died?
21:28 <+SpaceManiac> depends on your definition of "really"
21:29 < morfin> seems like Bukkit was bought
21:30 < morfin> i hope Minecraft would not become propietary protocol crap
21:30 < L3viathan> Bukkit was bought years ago
21:31 < morfin> but that http://forums.bukkit.org/threads/bukkit-its-time-to-say.305106/ was last nain
21:31 < morfin> *nail
21:32 < morfin> but Bukkit was added into original Minecraft code
21:33 <+SpaceManiac> source on this?
21:35 < morfin> Bukkit is just huge addon
21:35 < morfin> *mod
21:35 < morfin> adding hooks,callbacks and other stuff
21:37 < L3viathan> I don't get what you're saying
21:38 < morfin> i mean Bukkit is based on Minecraft server sources
21:38 < L3viathan> sort-of. so?
21:39 < morfin> and that can be a trouble because of license
21:40 < L3viathan> well, yes, it could be, if Mojang wanted to sue them, potentially.
21:40 < L3viathan> But they bought them
21:41 < shoghicp> is more like a wrapper around Mojang code, but a bit modified
21:41 < greymerk> "From the get go we were plagued with issues and obstacles we needed to overcome, one of which we were sadly unable to tackle despite our best efforts: the legal barrier of licensing and permission."
21:41 < greymerk> oops wrong window
22:29 < eddyb> Thinkofdeath_: did you see this? http://www.reddit.com/r/rust/comments/2er136/hematite_vs_minecraft_2/
22:29 < Thinkofdeath_> yep :)
22:30 < Thinkofdeath_> Beats mine completely :P
22:30 < eddyb> Thinkofdeath_: it feels simple
22:30 < eddyb> the code might not be as readable as it could be
22:30 < eddyb> but there is no smart logic
22:30 < eddyb> maybe a couple heuristics here and there
22:31 < Thinkofdeath_> Next up transparent blocks
22:33 < eddyb> you mean translucent
22:33 < Thinkofdeath_> oops, yeah 
22:33 < eddyb> I know how to do old style translucent
22:33 < eddyb> explained in a comment in that reddit post
22:33 < eddyb> new style... I really don't want to sort all the faces each frame
22:34 < Mathuin> So what is the real definitive status of Bukkit?  Are they giving up?  Will someone else be generating a Bukkit-like product?  Will Mojang be turning out something closer to Bukkit?
22:34 < eddyb> Mathuin: what?
22:34 < eddyb> wasn't the Bukkit drama closed shut?
22:34 < Thinkofdeath_> eddyb: Amaranth had a link to a paper on weighted blending which can work without sorting
22:34 < eddyb> Thinkofdeath_: I know about that kind of blending and I don't see how it can work at all
22:34 < Thinkofdeath_> I couldn't get it working at a decent speed in webgl and went back to manual sorting
22:35 < eddyb> would it even produce the same results as minecraft?
22:35 < Thinkofdeath_> It was pretty close
22:35 < eddyb> eh
22:35 < Mathuin> eddyb: I do not know, that is why I am asking.
22:35 < eddyb> Thinkofdeath_: I am shooting for pixel-perfect
22:35 < eddyb> Mathuin: Bukkit is fine
22:35 < Thinkofdeath_> Mathuin: mojang is taking over, most of the bukkit team left
22:36 < eddyb> Thinkofdeath_: the sorting is probably cheap, but computing the projected Z values on the CPU seems expensive as heck
22:36 < eddyb> Thinkofdeath_: if I could feed the vertex shader with a bunch of values and grab the output in a buffer, that would work nicely
22:36 < eddyb> Thinkofdeath_: someone suggested pre-sorting
22:36 < Mathuin> Thinkofdeath_: I had expectd the Bukkit team to hang on until Mojang released a server with a decent API rendering Bukkit irrelevant.
22:37 < Thinkofdeath_> I'm lazy and just sorted per block instead of per a vertex, works pretty well bar stained glass panes
22:37 < eddyb> most chunks fit in one of 8 categories
22:37 < Thinkofdeath_> Mathuin: Updating bukkit was getting harder for them and mojang wasn't helping
22:38 < eddyb> basically  ±x, ±y, ±z
22:38 < eddyb> the rest of the chunks cross x = 0 or y = 0 on the screen
22:38 < Mathuin> *nod*  Well, I like running a server which can have mods added to it, and I hope that magically comes out of Mojang soon if Bukkit's not following 1.8.
22:38 < eddyb> and as such, they are affected by perspective
22:38 < eddyb> so you have to sort them manually
22:40 < Thinkofdeath_> Mathuin: For now we wait for more info, no use in just guessing
22:40 < eddyb> Thinkofdeath_: have you thought of what I've said?
22:41  * Thinkofdeath_ isn't good at this kinda stuff
22:41 < eddyb> you'd store 8 index buffers for each chunk's translucent faces
22:41 < eddyb> which correspond to the orthogonal common cases
22:42 < eddyb> each of them only needs to have half the faces, you can do backface culling
22:43 < Thinkofdeath> hmm, could work
22:44 < Mathuin> Thinkofdeath: *nodnod*  Thanks.
22:54 < eddyb> Thinkofdeath: the number of chunks that would need sorting of translucent faces varies between 25% and 100% - but maybe I need to redo the estimation using absolute numbers, because 100% out of 5 is less than 25% out of 100 :)
22:54 < eddyb> Thinkofdeath: 25% is when looking into the horizon, so that's half the work, at the cost of those 8 index buffers per chunk
22:54 < eddyb> sorry, a quarter
--- Log closed ven. août 29 12:51:14 2014
--- Log opened ven. août 29 12:57:27 2014
12:57 -!- Irssi: #mcdevs: Total of 165 nicks [1 ops, 0 halfops, 10 voices, 154 normal]
--- Log closed ven. août 29 13:02:45 2014
--- Log opened ven. août 29 13:02:53 2014
13:02 -!- Irssi: #mcdevs: Total of 168 nicks [1 ops, 0 halfops, 11 voices, 156 normal]
13:05 -!- Irssi: Join to #mcdevs was synced in 156 secs
14:20 < ellisvlad> Hmm, anyone got some info on the way chunks are sent now? i.e. new packet format for 0x21 in 1.8?
14:24 < ellisvlad> Well, I get the packet format, that's not really changed. It's the Data field I'm confused with?
18:02 <+SpaceManiac> ellisvlad: the only change was in the type and metadata sections (the rest is the same)
18:03 <+SpaceManiac> instead of 16^3 bytes of type and 16^3 nibbles of metadata, it's 16^3 shorts of ((type << 4) | metadata)
18:03 <+SpaceManiac> (and the extended/additional type bit is gone completely)
18:04 < Mathuin> How exciting.
18:04 < Mathuin> Did blocklight and skylight get "fixed" as well?
18:05 <+SpaceManiac> no changes there
21:35 < ackpacket> Why is it that sometimes a server rejects my login with "not authenticated with minecraft.net..."??  My client follows the same login process every time, and uses a selected profile copied directly from mojangs authenticate response.  I also get a 204 from my request to mojang for me to join the server.  What could be going on here?
21:38 < ackpacket> Other times it successfully joins with zero problems
21:38 < barneygale_> are you logging in immediately before joining the server?
21:38 < ackpacket> Yes
21:39 < barneygale_> idk, make sure you've read the entire HTTP response before joining?
21:39 < ackpacket> Yup.  It's always blank, code 204
21:39 < ackpacket> 204 = "success, but server returning no content", so that looks kosher
21:41 < ackpacket> I think maybe mojang is doing some rate limiting or something similar
21:41 < ackpacket> Because I for now I have the client retrieving a new access token every time
21:42 < barneygale_> that seems pretty weird
21:43 < ackpacket> The error, or my client
21:45 < ackpacket> It connects to the server with complete success roughly 1/4 times
21:45 < ackpacket> the others, the server returns a not authenticated error
--- Day changed sam. août 30 2014
01:26 < ackpacket> Anyone have an idea why sometimes my client is rejected from the server with "Not authenticated with minecraft.net", and other times it logs in successfully, DESPITE always getting a 204 response from mojang when posting to minecraft/join
01:26 < ackpacket> every time
02:37 < SlasherXT> Hey guys, could anyone possibly help me with NBT real quick?
02:38 < redstonehelper> just ask your question
02:39 < SlasherXT> Why would (NBT).getValue throw an NPE?
03:05 < ackpacket> What is NBT wrt minecraft?
03:05 < ackpacket> Ah.  Is that how the encrytion key comes down?
03:18 <+AndrewPH> ackpacket: its a format that notch made that used to be used in minecraft
03:18 <+AndrewPH> idk if it's used at all now
03:19 < ackpacket> Why would someone ask about NBT.getValue and not specify what language/library they were using...
03:20 < ackpacket> Andrew, while I have you here, any idea about this problem i've been having?  Sometimes my client is rejected by a server with "not authenticated with minecraft.net".  It happens about 3/4 times.  Other times, following the same process, it logs in successfully
03:20 <+AndrewPH> Nope, I've got no idea
03:20 < ackpacket> alrighty
05:10 < Fenhl> AndrewPH, ackpacket: NBT is still used, yes. See http://minecraft.gamepedia.com/NBT
05:13 < ackpacket> I saw that Fenhl , ty
05:13 < ackpacket> Fenhl: care to weigh in on my mysterious problem?
05:14 < Fenhl> ackpacket: I find auth very confusing myself. No idea, sorry
05:15 < ackpacket> Fenhl: well, I have a semi-working implementation if you're ever interested.  It's very reliable if you make sure to check the server doesn't respond to you with a string containing 'Not authenticated'
05:15 < ackpacket> it's in python though.  But anyway let me know
13:17 < Kavukamari> hmm why cant scoreboard players test just act like execute that would make it so powerful D:
14:24 < ellisvlad> Still trying to work out how chunk data is sent in the pre-release. Anyone got some working code they wouldn't mind showing?
14:27 < ellisvlad> Was using this in 1.7: http://pastebin.com/TJwgbGbP
14:27 < ellisvlad> Tried converting to 1.8, to no avail.. http://pastebin.com/PC0wviyG
14:27 < Thinkofdeath> ellisvlad: the sky/block light is sent as before, the block ids and data are combined into (id << 4) | data and encoded as a (little endian?) short
14:27 < Thinkofdeath> oh and the addition nibble doesn't exist anymore
18:12 < iHax> 1.7.4 as i know did not change protocol much
20:49 <+SpaceManiac> ellisvlad: https://github.com/SpaceManiac/Glowstone/blob/mc-1.8/src/main/java/net/glowstone/GlowChunk.java#L606
20:50 <+SpaceManiac> (the more relevant bits further down at L659)
21:05 < Drainedsoul> that method looks like it could use some refactoring
21:20 <+SpaceManiac> there's not really a lot to refactor there, even if it is a little verbose
22:00 < ellisvlad> SpaceManiac: Thank you! I'll take a look in a bit :D
--- Day changed dim. août 31 2014
17:22 < MrARM> hello.
17:22 < MrARM> I'm trying to ping an MC server
17:23 < MrARM> I have got it to working mostly, but when I'm trying to ping an big server, it gets out of sync
17:25 < MrARM> nvm, I found what I did wrong. 
17:25 < MrARM> I've forgot to change .read to .readFully
18:14 < nickelpro> In C doing operation on a data buffer, should I keep track of an offset and add it to a pointer, or just increment the pointer? The cautious part of me wants to say the former, but the code looks cleaner with the later. Pretty sure it won't matter either way once the compiler optimizes it
18:15 < Flemmard> if you increment the pointer, you need to keep track of the original pointer, to be able to free it .. that's basically the only need to pay attention
18:16 < Flemmard> for the rest, it doesnt matter afaik
18:18 < nickelpro> I'm going to stick with the offset for now, it's useful for checking against the buffer length to make sure we don't overflow. Might try the increment version and see if the code comes out significantly cleaner.
18:18 < nickelpro> Thanks
18:19 < Flemmard> i'd prefer the offset method, helps keep track of the thing, even in your head when you do the code lol
18:20 < nickelpro> Ya, but even knowing the compiler optimizes it away and that it wouldn't make a lick of difference on modern computers, seeing "buf + len" everywhere just irks some deep far-too-early optimization part of me
18:21 < Flemmard> yeah it maybe needs to some some moreo perations, get ptr addr, get len, add them, put them and read to this addr ..
18:21 < Flemmard> but meh
18:21 < Flemmard> i dont think you'll notice any difference then lol
19:19 < Drainedsoul> nickelpro: I'd be inclined to increment the pointer, and save the original, sort of like how std::vector is implemented in C++.
19:19 < Drainedsoul> nickelpro: The concept of an "iterator" is valuable even in C, imo.
--- Day changed lun. sept. 01 2014
03:51 < Drainedsoul> Keep alive IDs, are they currently any integer, or only non-negative?
03:53 <+SpaceManiac> I can't speak for vanilla server behavior, but I send any integer and the client echoes it back fine
03:56 < Drainedsoul> SpaceManiac: Thanks, trying to figure out what integer type to stuff it in after deserializing it.
04:17 < nickelpro> Drainedsoul: I use signed, more or less doesn't matter
05:04 < Drainedsoul> nickelpro: Hmm?
05:04 < Drainedsoul> I don't understand what you mean by "more or less doesn't matter"
05:05 <+SpaceManiac> doesn't matter if you consider it signed or unsigned, as long as it's the right number of bits
05:06 < Drainedsoul> oh, sure, yeah.  My VarInt serializer actually blocks "unsigned" values outside the positive range of a signed int, though, so it does matter in this circumstance
05:07 <+SpaceManiac> Ah right, I'd forgot it's a varint now
09:57 < Drainedsoul> What happens for slot data with no associated NBT data now?
10:04 < Thinkofdeath> Drainedsoul: Just a NBT_Tag end (0 byte)
10:18 < Drainedsoul> wait >:|
10:18 < Drainedsoul> just a TAG_End, or an empty TAG_Compound with no name
10:18 < Drainedsoul> i.e. is it just 0, or 10 0 0 0 ?
10:18 < Thinkofdeath> just the end tag
10:19 < Drainedsoul> omfg
10:19 < Drainedsoul> r u serious
10:19 < Drainedsoul> I really need to start compiling "all the ways the Minecraft protocol and associated data types are poorly designed/conceived"
10:19 < Drainedsoul> there's some seriously good material here
10:19 < Thinkofdeath> https://github.com/thinkofdeath/mc-autodocs/blob/master/protocol/PacketByteBuf.java#L154-L163
10:20 < Thinkofdeath> it reads the first byte and resets if its not zero
10:20 < Thinkofdeath> different way of thinking about it :)
10:20 < Drainedsoul> yeah I can conceive of how to parse it
10:20 < Drainedsoul> it's just not valid NBT at all
10:25 < Drainedsoul> thanks though :)
10:26 < Thinkofdeath> np :)
10:29 < Drainedsoul> What's up with the function names in that code btw
10:30 < Drainedsoul> is it calling obfuscated functions or something
10:30 < Thinkofdeath> its directly from minecraft
10:30 < Thinkofdeath> with a few renames
10:30 < Drainedsoul> ah okay
10:40 < Dinnerbone> Drainedsoul: it's intentionally not valid nbt... otherwise, it's valid nbt...
10:40 < Dinnerbone> You don't ever represent the lack of a value by picking one of the possible values and reserving it as magic.
10:49 < Drainedsoul> I more more interested in whether or not "no NBT data" was still a valid state
11:12 < Dinnerbone> It is, and it is represented by sending 0 instead of an nbt structure.
11:22 < Drainedsoul> Yes I'd gathered that
11:31 < Dinnerbone> So how would sending valid nbt to represent the lack of nbt be less "poorly designed/conceived"?
11:45 < Drainedsoul> it was less that and more the just arbitrary invention of ways to signal a missing value, rather than something standard and consistent which can be implemented once and reused
12:06 < expir3dcowPC> hello
12:15 < Drainedsoul> hi
12:15 < expir3dcowPC> can you help me please?
12:16 < expir3dcowPC> I want to make an app that connects to my local sercer and say Hi from android
12:16 < expir3dcowPC> (Java)
12:18 < Drainedsoul> http://wiki.vg/Protocol http://wiki.vg/Protocol_Encryption
12:19 < expir3dcowPC> Thanks
12:34 < shoghicp> expir3dcowPC: https://github.com/DarkStorm652/DarkBot
12:34 < shoghicp> well, check http://wiki.vg/Client_List
12:34 < shoghicp> or http://wiki.vg/Library_List
12:36 < expir3dcowPC> Thanks shoghicip
20:28 < Drainedsoul> with the new position type, does Minecraft regard the Y bits as signed or unsigned?
20:29 <+SpaceManiac> I want to say unsigned, but it's a bit tricky
20:29 < Drainedsoul> hmm?
20:31 <+SpaceManiac> Depends on how exactly the parsing code goes about unpacking the value
20:34 <+SpaceManiac> In Glowstone, I treat it as unsigned, but I don't know for sure if Vanilla does
21:24 < Drainedsoul> https://gist.github.com/RobertLeahy/e96f06553d82c365a132 <= does bounds checking also, idk if there's any pull for that though
21:29 < Fysac> Sorry, what is the "new position type"?
21:30 < Drainedsoul> X/Y/Z packed into a 64 bit integer
21:30 < Drainedsoul> http://wiki.vg/Pre-release_protocol#Position
21:33 < Fysac> Oh, wow
21:36 <+SpaceManiac> Drainedsoul: why own bitwise_cast (making use of what I think is UB) instead of reinterpret_cast?
21:39 < Drainedsoul> how would that be UB?  The standard strictly allows types that vary only by signedness to alias each other: "[...] other than one of the following types [...] a type that is the signed or unsigned type corresponding to the dynamic type of the object [...]" §3.10 [basic.lval]
21:39 <+SpaceManiac> ah, my bad then
21:42 < Drainedsoul> SpaceManiac: As for why, rather than reinterpret_cast, it's habit I guess.  I just naturally use anonymous unions for bit fiddling (I find they're more expressive).
21:42 < Drainedsoul> http://git.rleahy.ca/MCPP/blob/master/include/mcpp/endianness.hpp#L65 this code, for example, would be a lot less expressive if it used reinterpret_cast
21:43 < Drainedsoul> (the same section of the standard also exempts "a char or unsigned char type" from the strict aliasing rule)
21:44 <+SpaceManiac> mm, that's fair, I suppose
--- Day changed mar. sept. 02 2014
11:23 < Thinkofdeath> Hopefully the wiki is updated with the 1.8 info now, let me know if I missed something :)
14:17 < cindy_k> Thank you Thinkofdeath  :)
15:07 <+sadimusi> who is responsible for mcdevs.org? TkTech?
15:19 < SinZ> sadimusi: yes, it has a github repo on the mcdevs org though
15:20 < SinZ> or not, it must of moved
15:20 <+sadimusi> well, it seems to be down http://d.pr/i/a1UQ
15:21 < SinZ> I think it shutdown, the repo is missing
15:47 < TkTech> sadimusi: Yeah, domain was allowed to expire; wiki.vg was renewed again (expiry was the 5th of this month)
15:47 < TkTech> I mentioned awhile ago that I was going to let it lapse, it just pointed to a page on wiki.vg
15:48 < TkTech> Looks like it instantly got bought by a domain squater bot
16:21 -!- TkTech changed the topic of #mcdevs to: A haunt for developers working on projects related to Minecraft | Website & Rules: http://wiki.vg/MCDevs/rules | Wiki: http://wiki.vg | Channel is publicly logged as of Feb.25/13
16:55 <+Amaranth> Every domain instantly gets bought by a domain squater bot
18:37 < Not-f47f> [Glowstone] SpaceManiac pushed 25 commits [+20/-2/±192] http://git.io/uAy-uQ
18:37 < Not-f47f> [Glowstone] SpaceManiac c28dec1 - Some minor cleanup in the net package.
18:37 < Not-f47f> [Glowstone] SpaceManiac 6bc1b91 - Updated version number for 1.8.
19:06 < MrARM> What algorithm does MC 1.8 use for packets? 
19:07 <+SpaceManiac> Deflate
19:09 < MrARM> ok, thanks. 
19:28 < MrARM> Plugin Message's data seems to be prefixed with a VarInt instead of a short now.
19:29 <+SpaceManiac> It's not prefixed at all now, I believe
19:29 < MrARM> It actually seems to be
19:30 <+SpaceManiac> the varint prefixes the channel name as part of the string type, then the payload is unprefixed
19:30 < MrARM> it looks like there's a VarInt and that's the size of "vanilla" which is the next thing I get
19:30 <+SpaceManiac> full packet bytes?
19:31 < Not-f47f> [Glowstone] SpaceManiac pushed 1 commit [+0/-0/±1] http://git.io/QPBUVw
19:31 < Not-f47f> [Glowstone] SpaceManiac 40d9363 - Fixed readBlockPosition in negative coordinates.
19:36 < MrARM_> 00 3f 08 4d 43 7c 42 72 61 6e 64 07 76 61 6e 69 6c 6c 61
19:36 < MrARM_> SpaceManiac ^
19:40 < MrARM_> I mean that "07" here which prefixes "vanilla"
19:42 <+SpaceManiac> hmm, you may be right
19:42 <+SpaceManiac> Ah! No, I see.
19:43 < MrARM_> So what's that 07?
19:43 <+SpaceManiac> the packet does not length-prefix the remaining data
19:43 <+SpaceManiac> the *contents* contain a length-prefixed string
19:43 < MrARM_> ah, anyway it wasn't like that in 1.7.
19:43 <+SpaceManiac> working with books (which use plugin message) there is no length-prefix
19:44 <+SpaceManiac> yes
19:44 < MrARM_> but how can a client know the size when working in uncompressed mode?
19:45 <+SpaceManiac> length-prefix to packet as a whole
19:45 <+SpaceManiac> then read remaining bytes of the current packet
19:46 < MrARM_> oh yeah, nvm.
19:48 < MrARM_> applied the changes to my code, thanks.
21:11 < Aaron1011> Does the Entity ID in the block break packet refer to the entity doing the breaking?
21:11 < Aaron1011> http://wiki.vg/Protocol#Block_Break_Animation
21:41 < Bibl> Hello there
21:41 < Bibl> I am here to collect your mappings
21:41 < Bibl> Please form an orderly queue.
21:51 <+SpaceManiac> Aaron1011: it is an entity ID to represent the animation itself (needs to be unique from other animations at least, not sure about other entities)
21:51 < Aaron1011> SpaceManiac: Thanks!
22:12 < zml> has anyone tested to see if the mojang API ratelimit for name->uuid is 600reqs/10min or 600users/10min? (so would bulk requests make a difference)?
22:14 < Thinkofdeath> zml: its 600req/10min (that info was from mojang)
22:14 < Thinkofdeath> batching will allow for more users and is recommended
22:15 < zml> ok, so 100 users/req + 600req/10min == 60k users/10min
22:15 < Thinkofdeath> yep
22:15 < zml> good
22:16 < zml> thanks
22:17 < zml> now to find a maven repo for AccountsClient :/
22:19 < Thinkofdeath> Don't think it has one
--- Day changed mer. sept. 03 2014
03:09 < Bibl> What's the point of even obfuscating Minecraft?
03:10 < Bibl> It doesn't prevent anything and wastes my time by making me rewrite my updater
04:15 < fysac> b
04:17 < fysac> Bibl: agreed so much. I really see zero value for Mojang to do that
04:18 < fysac> also, side question: how does MCP work? what's the deal with their deobfuscation? why does Mojang allow it?
04:22 < Not-f47f> [fNbt] fragmer pushed 1 commit to master [+1/-2/±6] http://git.io/_qCAvg
04:22 < Not-f47f> [fNbt] fragmer bce3c7e - Resuming work on fNbt.Serialization. Instead of caching NbtSerializers directly, we now cache TypeMetadata. NbtSerializers can now be constructed with any SerializerOptions, for maximum flexibility. Nothing works yet, but everything compiles.
04:59 < Bibl> Sorry I went away for a bit
04:59 < Bibl> I'm not sure about MCP but I was analysing class struction and bytecode patterns in the game.
05:00 < Bibl> A lot broke when 1.7 came out
05:00 < Bibl> And after a lot of fixing all 1.7-1.7.10 worked
05:00 < Bibl> Then 1.8 broke everything
05:01 < Bibl> So we're debating on whether to setup a neural network to analyse class files and find similarities between them to come up with better heuristic based detection schemes
05:01 < Bibl> Which we can then plug in and find fields, methods and classes without breaks
05:25 < Fysac> Bah, I wish they would just open source everything :(
05:38 < dx> Bibl: sounds like fun
12:12 < Aaron1011> I think MCP is allowed because the owner, Searge, works at mojang
12:22 < l4mRh4X0r> I think MCP is technically legal in most countries.
12:34 < jast> technically legal, the funnest kind of legal
12:36 < Grum> Aaron1011: that is not how it works though
12:37 < Grum> just because he works here doesn't just whitelist MCP from any infringement
12:40 < Aaron1011> Grum: Oh, okay
12:50 < Spurlex> Grum do you know if the boss bar not showing when you arent looking directly at the dragon is intended?
12:52 < Dinnerbone> It is not and will be fixed.
12:53 < Spurlex> Yay <3 
12:53 < Spurlex> Same with the beacon beam?
16:47 < SinZ> Dinnerbone, Grum: care to clarify this? http://dl.bukkit.org/downloads/craftbukkit/
16:53 < Thinkofdeath> SinZ: http://dl.bukkit.org/dmca/notification.txt
16:53 < MrARM> ugh
16:55 < SinZ> wait what
16:55 < MrARM> It's not that person for sure
16:56 < SinZ> so Multiplay DMCA'd CraftBukkit and told Mojang, Mojang said that CraftBukkit didn't get permissions, even though they own bukkit?
16:57 < Thinkofdeath> Wolvereness ((Craft)Bukkit dev) DMCA'd the servers hosting the downloads
16:57 < MrARM> That's being a strange thing now...
16:57 < Thinkofdeath> Due to the GPL breakage
17:02 < Bibl> What are the packet protcol changes?
17:21 < Drainedsoul> Bibl: http://wiki.vg/Protocol_History ?
17:22 < Bibl> How would I intercept packets after the game has started?
17:23 < Bibl> Would the only way to be listening before the packets are sent?
17:41 < barneygale> if the server's in offline mode you could conceivably use some kind of network-level packet munging
17:42 < barneygale> but really you need to do a proper proxy
--- Log closed mer. sept. 03 18:08:52 2014
--- Log opened mer. sept. 03 18:09:02 2014
18:09 -!- Irssi: #mcdevs: Total of 157 nicks [1 ops, 0 halfops, 12 voices, 144 normal]
18:11 -!- Irssi: Join to #mcdevs was synced in 150 secs
18:14 < redstonehelpe> does the display name sent with the player list affect the nametag above a player in the world?
18:17 < Thinkofdeath> redstonehelpe: no
18:17 < redstonehelpe> thanks
19:22 < Bibl> Hmm
19:23 < Bibl> If I xbootclasspath my own DataOutputStream or w/e the client uses to send packets think I could extract data?
19:23 <+SpaceManiac> Spurlex: take a look at the player list header/footer and the addition to the chat packet for alternatives to the boss bar thing
20:03 < morfin> hello
20:03 < morfin> does Minecraft protocol include error handling?
20:03 <+SpaceManiac> in what respect?
20:04 < morfin> sometimes i saw messages like "bad packet id 163" in client so i think stream just became out of sync 
20:06 < morfin> not sure how that happens(maybe when sending 10 bytes when expected 20 or sending 30 when expected 10)
20:06 <+SpaceManiac> yeah, basically just means the server has sent some wrongly formatted data in some way or another
20:09 < morfin> i am thinking about validating packet before handling(on server-side) but... i have no idea how to detect next packet
20:09 <+SpaceManiac> packets are length-prefixed
20:10 < morfin> incorrect length can be sent)
20:10 < barneygale> Not AFAIK
20:10 <+SpaceManiac> you are basically doomed at that point
20:10 < barneygale> Oh, I see
20:10 < barneygale> yeah
20:10 < barneygale> the mojang client/server should never send an incorrect length
20:10 < morfin> stream out of sync -> nothing can be done
20:10 < morfin> he-he
20:14 < morfin> btw i can try to use some euristics to fix mess
20:14 < morfin> but that would be probably too slow
21:22 <+AndrewPH> >tfw more bukkit drama crap
21:24 < shoghicp> morfin: I guess you can still send data, like a ping packet
21:24 < shoghicp> then wait for the pong packet and resync
21:25 < shoghicp> (with the custom value you set)
21:25 <+SpaceManiac> not helpful if the ping packet is embedded in the middle of some partial packet
21:26 < shoghicp> well, if the server sends all the packets right :S
21:26 < Aaron1011> Hopefully, we'll get official word from Mojang on the (Craft)Bukkit DMCA at some point
21:35 < barneygale> Aaron1011: I expect we'll see a bunch of brash tweets
21:35 < barneygale> :D
21:35 < Aaron1011> Yeah, like with the whole (almost) shutdown of Bukkit
21:36 < Aaron1011> I wonder if Dinnerbone will even be able to update CraftBukkit to 1.8
21:36 < Aaron1011> At least, in something that resembles it's current form
21:36 < Aaron1011> Glowstone is looking so good right now :)
21:36 < barneygale> If the DMCA request is sound then he won't be able to without licensing NMS as something GPL-compatible
21:37 < barneygale> And yeah glowstone is looking good lol
21:37 <+SpaceManiac> It's got 1.8!
21:37 < dx> or relicensing all the gpl contributions
21:37 < Aaron1011> Or rewriting it from scratch
21:37 < Aaron1011> Which I find doubtful
21:38 < Aaron1011> I was surprised that Dinnerbone said he'd rewrite it - since he stated that it wasn't going to be the official API
21:38 < Aaron1011> I guess the Plugin API won't come out this decade :)
21:38 < dx> rewrite what?
21:38 < dx> he said that where?
21:38 < Aaron1011> CraftBukkit
21:38 < dx> [citation needed]
21:38 < Aaron1011> https://twitter.com/Dinnerbone/status/502381093731831808
21:38 <+SpaceManiac> do you mean "perform the 1.8 update", not "rewrite"?
21:38 < dx> ^
21:38 < dx> that's not a rewrite
21:39 < Aaron1011> Well, if it turns out they can't get all of the code licensed, they'll have to remove some parts
21:39 < Aaron1011> And with the proprietary Mojang code
21:39 < barneygale> They'll have to remove huge amounts AFAIK
21:39 < Aaron1011> Also - https://twitter.com/Dinnerbone/status/502389963606867968
21:39 <+SpaceManiac> yeah, very large portions of CB are community contributions
21:40 < Aaron1011> barneygale: Especially considering how much wolverness wrote
21:40 < barneygale> and everyone else, right? They'd need to ask permission from everyone who contributed code
21:40 < Aaron1011> Right
21:40 < Aaron1011> But, some people only have a few commits
21:40 < Aaron1011> Where as others have hundreds
21:41 < Aaron1011> This gives some perspective: https://github.com/Bukkit/CraftBukkit/graphs/contributors
21:41 < barneygale> How much code is owned by the Bukkit organisation, and how much is owned by the original authors?
21:41 < barneygale> Does it all belong to original authors?
21:41 < Aaron1011> I believe so
21:41 < Aaron1011> I *think* that everyone who contributed has the rights to their code, licensed under the GPL
21:42 < Aaron1011> The problem is that Mojang's code is included in CraftBukkit, which is not under the GPL
21:42 <+Prf_Jakob> Its difficult to judge, because if you just change a line or two you don't own that code.
21:44 < Aaron1011> Out of curiosity, who actually removed the DMCA's jars? Wolverness?
21:44 < Aaron1011> From the Bukkit website^^
21:44 < dx> wolvereness is the one who sent it, asking the hosting provider to remove them
21:46 < Aaron1011> Oh, I guess I assumed Bukkit hosted the site themselves
21:46 < Aaron1011> I never actually thought about it that much :)
21:46 < dx> "bukkit", whoever that is now, probably doesn't own a data center
21:47 < Aaron1011> :)
21:47 < Aaron1011> When did Wolverness actually file the DMCA?
21:47 < Aaron1011> takedown notice^^
21:48 < dx> Date: 3 September 2014 03:48
22:03 < morfin> lol
22:03 < morfin> bukkit was removed from site
22:07 < morfin> R.I.P Minecraft
22:12 < dx> 2slow
22:13 <+AndrewPH> ur2slow
22:13 <+AndrewPH> gotagofaust
22:13 < morfin> i did not expect that all Bukkit builds will be removed
22:14  * morfin still hopes there is backups somewhere
22:14 < dx> so what do you normally expect after a DMCA?
22:14 < dx> a party?
22:15 < dx> ok ok sorry i just had to say that
22:15 < iBotPeaches> beverages at the least
22:16 < morfin> lol github is still avalible
22:16 < morfin> *available
22:18 < dx> but only because a dmca wasn't sent that way
22:19 < morfin> it will be i think
22:19 < dx> that's up to wolvereness
22:19 < morfin> and it probably can take loong time
22:19 < dx> it might not be in his interests to block access to the source code completely
22:19 < morfin> since project have GPL license
22:21 < dx> i think taking down the builds is more than enough to pressure mojang to fix this situation
22:21 < morfin> they removed all plugins?
22:21 < dx> no?
22:22 < dx> craftbukkit builds
22:22 < morfin> plugins links are missing
22:22 < dx> from where?
22:23 < morfin> oh phew
22:24 < morfin> thought they removed plugins too
22:25 < humerusj> What happened?
22:26 < dx> http://dl.bukkit.org/dmca/notification.txt
22:28 < morfin> does he know about github?
22:28 < morfin> Mojang has not authorized the inclusion of any of its proprietary
22:28 < morfin> Minecraft software (including its Minecraft Server software) within the
22:28 < morfin> Bukkit project to be included in or made subject to any GPL or LGPL
22:28 < morfin> license, or indeed any other open source license
22:28 < morfin> but sources are on Github
22:29 < morfin> as i said )
22:29 < humerusj> Oh damn
22:29 < humerusj> Mojang owns bukkit I thought?
22:31 < morfin> i think best hosting ever is in space orbit/in neutral waters
22:32 < dx> morfin: ...of course he knows about github, he even linked it there
22:33 < morfin> i see
22:37 < woder_> in 1.8, when they say the packets are "compressed" what are they compressed with? Gzip?
22:40 < Thinkofdeath> deflate
22:43 < woder> so uncompressing should just be Inflater.inflate I suppose?
22:44 < Thinkofdeath> yep
22:49 < woder> weird, I keep getting bad compressed data format
22:54 < woder> Thinkofdeath, if you have a second could take a quick peak and tell me if you see anything blatently wrong with this? https://github.com/woder/TorchBot/blob/devel/src/me/woder/network/NetworkHandler.java
22:58 < Thinkofdeath> woder: you never fill the data array
22:58 < woder> wow, thats a dumb mistake, thanks xD
22:59 < Thinkofdeath> np :)
23:00 < woder> also packet length includes the data length field?
23:00 < Thinkofdeath> yes
23:02 < woder> thanks :D
23:11 < woder> hey Thinkofdeath, any idea what could cause a "java.util.zip.DataFormatException: incorrect header check" error to be thrown?
23:11 < Thinkofdeath> nope
23:12 < woder> well, thanks anyways
23:24 < Drainedsoul> woder: That readData method looks ridiculously long, consider refactoring
23:25 < woder> yeah, its only temporary while I figure out what is going on with this update ^^
23:42 < fysac> hi, woder
23:42 < fysac> big fan
23:43 < woder> oh? hi
23:48 < fysac> I've been writing a bot too, but mostly for server logging purposes.
23:49 < woder> ah, I see, how is that coming along?
23:51 < fysac> badly. I'd just gotten the hang on 1.7, not 1.8 comes along...
23:51 < fysac> *now
23:51 < woder> yeah... 1.8 has shaken stuff up quite a bit lol
23:54 < woder> but fysac, if you can't get your code to work, Torchbot is rather versatile and I'm sure you could setup something to do what you would like
23:54 < fysac> Yeah, I've used torchbot, it works pretty well
23:54 < fysac> but my code works too
23:55 < fysac> it's just not complete
23:56 < fysac> And I keep rewriting everything because I get sick of my own code
23:57 < woder> that tends to slow things down
23:58 < fysac> absolutely, but I can't help myself
--- Day changed jeu. sept. 04 2014
01:19 < woder> is it normal that when the packet is compressed packet length is 0 and data length has a value? (seems strange that packet length goes to 0)
01:20 <+SpaceManiac> woder: don't think that's normal
01:20 <+SpaceManiac> packet len = len [ compressed len bytes + data bytes ]
01:57 < woder> SpaceManiac: yeah, I think I'm leaving some random data in the pipe before I try to parse the next packet
02:55 < woder> the post compression format is "Packet Length, Data length, Packet id, Data" correct?
02:56 <+SpaceManiac> packet id is included in the data as far as compression is concerned
02:57 < woder> yeah, I meant after you decompress it the first thing you would read from the now decompressed byte array would be the packet id
02:58 <+SpaceManiac> right
02:59 < expir3dcow> is this discussion over? I don't want to obstruct it by asking my question
02:59 <+SpaceManiac> expir3dcow: no worries here, ask away
02:59 < expir3dcow> thanks
03:00 < expir3dcow> How do I connect to a PC server via java then say hi then leave? I've read that I need to perform a 'handshake' but I haven't seen any examples that I understand
03:00 < woder> its actually pretty complicated just to say hi
03:01 < expir3dcow> really?
03:01 < expir3dcow> well my project is going to be beyond hard if  a message is hard
03:01 < woder> yeah, because you need to deal with encryption - that alone is not exactly the easiest
03:01 < expir3dcow> Wow.
03:02 < expir3dcow> Well, I'm a networking noob, so I guess I'll have to leave that idea alone
03:03 < woder> this is the login process, you need to this before messages can be sent
03:03 < woder> http://wiki.vg/Protocol#Login
03:04 < expir3dcow> oh ok
03:05 < expir3dcow> wow
03:05 < expir3dcow> I'll see if I can find anything useful
03:06 < woder> you can look at what others did here: http://wiki.vg/Client_List
03:06 < expir3dcow> oh thanks
03:10  * SirCmpwn pokes TkTech
03:19 < Drainedsoul> Is the NBT in the Update Entity NBT packet in the same format as in Update Block NBT?  I.e. well-formed NBT, unless there's no NBT, in which case just the byte 0
03:28 < Drainedsoul> s/Update Block NBT/Update Block Entity/g
03:35 < woder> is it written anywhere what "chunk data" actually looks like now? (for packet 0x26 and 0x21)
03:36 <+SirCmpwn> has it changed recently?
03:36 <+SpaceManiac> Yeah.
03:36 <+SirCmpwn> bugger.
03:36 <+SpaceManiac> 1.8 removed the additional bitmask and data section and merged type and metadata into one number
03:37 <+SirCmpwn> why?
03:37 <+SpaceManiac> gradual phasing out of the metadata nibble entirely
03:37 <+SpaceManiac> too much of the possible data space was being wasted on metadata that was always 0
03:38 <+SirCmpwn> but I wrote this cool NibbleArray class to handle that :(
03:38 < woder> would be cooler if they just got rid of it one shot, so I didn't have to rewrite this again
03:38 <+SpaceManiac> don't worry! light and skylight still nibble arrays.
03:38 <+SpaceManiac> woder: my implementation -> https://github.com/SpaceManiac/Glowstone/blob/master/src/main/java/net/glowstone/GlowChunk.java#L606
03:40 < woder> hmm, thanks
04:07 < woder> just to confirm, is this packet size "166445002" possible for chunk packet? it seems really big and its overloading my heap
04:09 <+SpaceManiac> One chunk, or bulk chunk?
04:09 < woder> bulk
04:10 <+SpaceManiac> definitely, especially if it has a lot of chunks
04:10 <+SpaceManiac> actually I think the protocol now defines a max packet size if you don't compress
04:10 < fysac> yep
04:11 < woder> mc source says max is 2097152
04:12 < woder> but that could be wrong because its hard to see
04:12 <+SpaceManiac> yeah, that's correct (0x200000)
04:13 < woder> 166445002 > 2097152? (sorry I'm not sure I understand that)
04:14 <+SpaceManiac> yeah, I think even after decompression it has to be under that size
04:14 <+SpaceManiac> so break up your bulk chunk packet into multiple bulk chunk packets
04:15 < woder> to clarify, the server sent me that value
04:15 <+SpaceManiac> oh, weird, dunno then
04:15 <+SpaceManiac> that does seem unusual
04:16 < woder> yeah, trying to figure out whats going because its blowing up my memory
04:46 < humerusj> SpaceManiac: will you update glowstone to 1.8?
04:46 <+SpaceManiac> humerusj: it already is
04:47 < humerusj> SpaceManiac: oh, i should probably keep up with these things
04:48 <+SpaceManiac> it's fine, it isn't always immediately obvious :P
04:52 < belak> Does this still work? http://wiki.vg/Query It seems like the server I go on has been stuck on 7 people even though it doesn't match at all...
06:15 < Not-f47f> [Glowstone] SpaceManiac pushed 2 commits [+0/-0/±3] http://git.io/dZ9BDg
06:15 < Not-f47f> [Glowstone] Grinch 5b6d309 - Fix missing property 'bukkitVersion' in Gradle 2.x
06:15 < Not-f47f> [Glowstone] SpaceManiac 20aafbc - Fixed chunk depth (fixes #137), chunk sending, and MultiBlockChange handling.
10:03 < ackpacket> are there snapshots of older protocols?  like 1.7.2?
12:07 < l4mRh4X0r> ackpacket: you mean on the wiki? You can use its history function
12:09 < ackpacket> tyvm.  having trouble dealing with a 1.7.2 server -.-
12:10 < l4mRh4X0r> I believe http://wiki.vg/index.php?title=Protocol&oldid=5500 is the last 1.7.2 one
12:10 < l4mRh4X0r> Or rather, protocol version 4, used from 1.7.2 to 1.7.5
12:10 < ackpacket> hmmm
12:11 < ackpacket> I wish there was a summary of the bare minimum for a client to behave normally
12:11 < ackpacket> minus the physics
12:11 < l4mRh4X0r> ackpacket: I believe there is, on the wiki
12:11 < ackpacket> I've been sending this server look packets, but the avatar does nothing in the eyes of other notchian clients
12:11 < ackpacket> l4mRh4X0r: that info is a tad dated
12:12 < l4mRh4X0r> Ah, that's a shame
12:13 < ackpacket> tell me about it lol
12:15 < ackpacket> if a server gives me a y pos... how can I calculate feet/head y from that?
12:19 < l4mRh4X0r> +1.62
12:19 < l4mRh4X0r> At least, that's a player's eye height.
12:20 < l4mRh4X0r> Or isnt't that what you meant?
12:21 < ackpacket> well
12:21 < ackpacket> what y value is the server passing me in a 0x08?
12:21 < ackpacket> ah yes, eye pos
12:22 < ackpacket> so feet height is eye height minus 1.62
12:24 < l4mRh4X0r> Yes.
12:30 < ackpacket> I'm just continually repeating back every 0x08 I get, into an 0x06 out
12:30 < ackpacket> hoping to get some responsiveness out of the avatar
12:30 < ackpacket> but at this moment, look packets don't move the head, and other players can not hit him
13:41 < morfin> hello
13:58 < morfin> how does Minecraft send symbols like é?
13:58 < dx> ...utf-8?
14:02 < morfin> i mean like \u00e9 or like \u0065\u0301?
14:04 < dx> ...why would anyone use the latter
14:04 < dx> that's just awful
14:04 < morfin> lawl
14:05 < dx> and i wouldn't expect minecraft's text renderer to handle any advanced unicode crap like that anyway
14:06 < morfin> interesting does that support IDN
14:06 < morfin> like hmmm 
14:06 < dx> ?
14:07 < morfin> sending cyryllic/etc domain in hanshake
17:33 < morfin> just asking because i assume they're being sent as UTF-8 but should be converted into punicode 
17:37 < jast> punycode is pretty horrible
18:03 < morfin> i know)
18:04 < morfin> i am trying to implement state-machine to handle incoming packets
18:05 < morfin> i readed somewhere that i can discard some packets which are not implemented
18:05 < morfin> is there some critical packets?
18:08 < morfin> which should be always handled
18:33 < Dykam_> SpaceManiac, what licence is the one you added to Glowstone. MIT?
18:34 < Dykam_> (x11)
18:48 < Bibl> You need to send back the keep alive
18:48 < Bibl> Probably the movement data would be nice
18:55 <+SpaceManiac> Dykam_: it is MIT insofar as allowed by the fact it links to a GPL library... still working on that :/
18:56 < Dykam_> you can dual licence it afaik
18:56 < Dykam_> or just keep it MIT and do the releases with GPL
18:56 < Dykam_> (and MIT)
18:56 < Dykam_> or something like that, not entirely sure, but GPL mentions MIT is compatible
18:57 < belak> Does anyone know if anything was changed with the query protocol?
18:57 < belak> On one of the servers I frequent, it's been showing 7 users for the past 2 days, even though there are currently less than that and usually more than that...
18:58 < barneygale> belak: query as in the UDP protocol?
18:58 < belak> barneygale: yeah
18:59 < barneygale> that's interesting, I thought that was pretty much abandoned the moment it was released
18:59 < belak> :/
18:59 < belak> Are there any alternatives?
18:59 < barneygale> what are you after? a player list?
18:59 < belak> If all else fails, just count... but yes, I'd like a player list
18:59 < barneygale> I'll check whether the code is any different
19:00 < barneygale> did you write your own query client? or use existing code?
19:00 < belak> I wrote my own, based off of xPaw's PHP query library...
19:00 < belak> http://quigley.coded.io/ville/
19:01 < belak> It looks awful, but that's because it fits in elsewhere
19:01 < belak> Anyway, I haven't been online in the past few days
19:01 < belak> And here's the code: https://gist.github.com/belak/94821f129b077a755686
19:05 < barneygale> belak: I'm getting reasonable values from the 1.8 vanilla server {'map': 'world', 'motd': 'A Minecraft Server', 'server_mod': '', 'hostport': 25565, 'numplayers': 0, 'gametype': 'SMP', 'players': [], 'version': '1.8', 'maxplayers': 20, 'plugins': [], 'game_id': 'MINECRAFT', 'hostip': '127.0.1.1'}
19:07 < morfin> i have next question: is only way to name entity using names(like name tags do)?
19:07 < morfin> i mean NPC
19:09 < belak> barneygale: I guess I'm confused as to why my php (and the current stuff on the site) would be seeing 7 users.
19:09 < belak> barneygale: what are you using to query?
19:09 < morfin> raw sockets probably
19:10 < barneygale> belak: I'm using this https://github.com/barneygale/MCQuery
19:10 < morfin> python..
19:10 < barneygale> aye
19:11 < barneygale> I didn't mean to replace your PHP solution
19:11 < barneygale> just for testing
19:11 < barneygale> I'll try your PHP code
19:11 < belak> Yeah, for sure.
19:11 < belak> I'll take a look at what you do differently
19:12 < barneygale> Oh, is it the "numplayers" field that's wrong? Or the player list? Or both?
19:12 < belak> Both
19:13 < barneygale> Hm
19:15 < belak> It looks like we build the query packets very differently.
19:16 < belak> Er, maybe
19:16 < belak> You have that build packet function (I probably should have done that)
19:16 < barneygale> my code isn't great
19:17 < barneygale> I was quite new to python at the time
19:22 < barneygale> belak: are you using vanilla 1.8? or spigot protocol hack?
19:22 < belak> Vanilla
19:22 < belak> 66.240.202.11:25565
19:24 < barneygale> Yep I see 7 players too
19:24 < barneygale> hm
19:26 < belak> Alright, so it's server side
19:26 < belak> That's really weird
19:32 < barneygale> Strange that I don't see it on my server
20:52 < Not-f47f> [Glowstone] SpaceManiac pushed 1 commit [+0/-0/±1] http://git.io/nL_tTg
20:52 < Not-f47f> [Glowstone] SpaceManiac b43cf57 - Tweaked chunks per bulk packet down again (fixes #145).
21:03 < Not-f47f> [fNbt] fragmer pushed 1 commit to master [+3/-2/±5] http://git.io/k8o69A
21:03 < Not-f47f> [fNbt] fragmer ba7adf2 - Continuing work on fNbt.Serialization. Renamed NbtSerializer to more friendly-sounding NbtConverter. Simplified the API some more. Moved all dynamic (non-compiled) serialization code out of NbtConverter to DynamicConverter. Added checks for a couple more unsupported edge cases (multi-dimensional arrays and nullable primitive types).
21:56 < Drainedsoul> Thinkofdeath: You around?
21:57 < Thinkofdeath> yep?
21:57 < Drainedsoul> Is the NBT in the Update Entity NBT packet in the same format as in Update Block Entity?  I.e. well-formed NBT, unless there's no NBT, in which case just the byte 0
21:57 < Thinkofdeath> yes
21:57 < Drainedsoul> sweet, thanks :)
21:59 < Drainedsoul> dx: What's "awful" about NFD?
22:01 < dx> oh damn i've offended the gods of unicode
22:01  * dx hides
22:01  * dx silently prays for mercy
22:02 < Drainedsoul> o_o
22:03 < Drainedsoul> I was just curious what the reason was
22:17 < dx> Drainedsoul: é already has a perfectly good unicode code point, using a combining accent instead just makes things more complex to handle for no good reason, particularly in rendering
22:21 < TkTech> SirCmpwn: What's up
22:21 <+SirCmpwn> TkTech: you took your time :P
22:21 <+SirCmpwn> thought you might want to hear some exciting KnightOS news?
22:21 < dx> exciting
22:22 < dx> SirCmpwn: does KnightOS support unicode combining accents?
22:22 <+SirCmpwn> KnightOS doesn't support unicode at all
22:23 < dx> that's terrible
22:23 <+SirCmpwn> it runs on a calculator, dude
22:23 < dx> i bet Drainedsoul is willing to help :3
22:23 < TkTech> SirCmpwn: What's up?
22:23 <+SirCmpwn> TkTech: check this out: http://www.knightos.org/
22:23 < dx> whoa
22:24 <+SirCmpwn> emulation isn't perfect, but fileman works fairly well and phoenix is more or less playable
22:25 < TkTech> Aw, crashed
22:25 < dx> http://dump.dequis.org/Azb0a.png do i have to take out the cartridge and blow it?
22:25 <+SirCmpwn> ctrl+r will refresh your page :P
22:25 < TkTech> Silly Windows Plebe
22:25 <+SirCmpwn> we have a list of emulation bugs and we're hunting them down, but it is difficult
22:26 < dx> is the guided tour supposed to work?
22:26 <+SirCmpwn> no