17:02 < nyuszika7h> after code cleanup
17:02 <+sadimusi> requests uses the usual multipart encoding by default
17:02 <+sadimusi> s/multipart/x-form-something/
17:03 < nyuszika7h>     response = requests.post('https://authserver.mojang.com/authenticate',
17:03 < nyuszika7h> -                              data, headers=headers, verify=True)
17:03 < nyuszika7h> +                              json.dumps(data), headers=headers, verify=True)
17:03 < nyuszika7h> this fixed it
17:04 < nyuszika7h> sadimusi: x-www-form-urlencoded?
17:04 <+sadimusi> yeah that one
17:40 < morfin> how do you think is this possible to make frontend server which will have several realms as backends and allow to migrate between realms?
17:41 <+sadimusi> morfin: you're not making much sense
17:41 <+sadimusi> (as usual)
17:41 < morfin> why?
17:42 < morfin> one server will work as proxy and separate servers will be backends with possibly different rules etc
17:42 <+sadimusi> rephrase your question, maybe someone can answer it then
17:42 <+sadimusi> you mean bc?
17:43 <+sadimusi> (bc == BungeeCord in case you're not familiar with it=
17:43 <+sadimusi> *)
17:44 < morfin> ow
17:45 <+sadimusi> there are also a lot of multiworld plugins which do similar things
17:45 < morfin> that's not just multiworld
17:45 < morfin> do you know does it disconnect you when you teleport to another server?
17:46 <+sadimusi> of course not
17:46 < morfin> hmmm
17:47 <+sadimusi> the architecture of multiworld is quite different, but the result for the user is almost identical
17:47 < morfin> bungeecord is being installed into server and as proxy 
17:47 < morfin> as i see
17:48 <+sadimusi> it's a proxy, yes
17:55 < morfin> oh lol
17:56 < morfin> i've looked at rewriting ints in their code :D
17:57 < morfin> https://github.com/SpigotMC/BungeeCord/blob/master/proxy/src/main/java/net/md_5/bungee/EntityMap.java
17:57 < morfin> that looks very strange
20:00 < Jckf> Damned Quassel
20:00 < Jckf> Stop disconnecting me
20:00 < Jckf> And when you do, don't just rejain all channels except mcdevs!
20:00 < Jckf> *rejoin
20:27 <@TkTech> Jckf: Probably has an issue with +r channels.
20:27 <@TkTech> It doesn't register you quickly enough before trying to join, and doesn't retry after.
20:27 < Jckf> [17:26:13] * #mcdevs: Cannot join channel (+r) - you need to be identified with services
20:27 < Jckf> So it would seem
20:27 < Jckf> Which means it executes autojoin before identify
20:28 < Jckf> Silly
20:28 < Jckf> No wait. It does not. Because I am in +r channels on other networks as well
20:37 < Jckf> Latency between me and services perhaps
22:31 < Not-002> [FemtoCraft] fragmer * r129 2 files : Improved logging of the log-in process: messages added for situations where connection limit is exceeded, server is full, someone is kicked to make room for an op, etc. Also fixed ops being checked against MaxConnections setting, instead of OpMaxConnections setting.
22:38 < Not-002> [FemtoCraft] fragmer * r130 2 files : Added a config option to allow Mojanged (email-only) player names.
--- Day changed mar. sept. 24 2013
00:48 <+md_5> TkTech we can probs remove +r now
00:55 < TkTech> Any con to leaving it on? Doesn't seem to be affecting the majority of the channel.
00:59 < Drainedsoul> it's kind of a pain disconnecting and not auto-rejoining, and then missing things because you didn't notice.  Should probably setup a bouncer anyway though.
01:01 < dav1d> Drainedsoul: if you want I can make you a znc account
01:01 < dav1d> my vps is idling anyways
01:01 < dav1d> special bonus, I have a webchat for the znc setup
01:20 < Drainedsoul> dav1d: Sure, if it's not too much trouble.  I tried fiddling around with it on Ubuntu a while back, but couldn't get it working and moved onto other things ._.
01:25 <+md_5> fak
01:25 <+md_5> in the udp query
01:26 <+md_5> what encoding are the strings
01:29 < dav1d> Drainedsoul: sure thing, I'll make you an account tomorrow
01:29 < dav1d> sleep time
06:47 < morfin> bdzfjkdrgzf'podrgzfs
06:47 < morfin> ooops
06:48 < morfin> i saw BC in work: but i do not understand what for it's rewriting some stuff
07:20 <+md_5> morfin hey! Bungeecord creator here!
07:21 <+md_5> we need to rewrite certain  entity ids in packets, because when we switch servers we get a new entity id
07:21 <+md_5> unfortunately we cant tell the client about this new id, so we have to translate it
10:55 < dividuum> is there any clean way to change the clients entity id? can i resend 0x01 (login request) with a different entity id
10:56 < Not-002> [netherrack] thinkofdeath pushed 9 commits to master [+5/-1/±12] http://git.io/qCchfg
10:56 < Not-002> [netherrack] thinkofdeath 580b35d - /: Added list ping events
10:56 < Not-002> [netherrack] thinkofdeath 17ee71e - entity/player: Corrected filename
10:56 < Not-002> [netherrack] thinkofdeath 31bf0a5 - /: Player join event
10:56 < Not-002> [netherrack] thinkofdeath 07d8b7f - entity/player: Exported username and conn
10:56 < Not-002> [netherrack] thinkofdeath 49f9f12 - /: Added some missing documentation and allowed players to be disconnected during a join event
10:56 < Not-002> [netherrack] thinkofdeath d6854e2 - entity/player: Block place event
10:56 < Not-002> [netherrack] thinkofdeath 0b786d0 - world: Block placement and saving fixes
10:56 < Not-002> [netherrack] thinkofdeath b7b8f3d - world: region unloading
10:56 < Not-002> [netherrack] thinkofdeath 0bd1955 - blocks: Created
10:59 < Thinkofdeath> dividuum: From quick testing it doesn't look like sending again 0x01 will work
11:01 < dividuum> ok
11:02 < dividuum> so i have to masquerade entity ids, if I want to forward the connection from a lobby server to a game server.
11:06 < Thinkofdeath> I think that is what bungee does
11:09 < Not-002> [netherrack] thinkofdeath pushed 1 commit to master [+0/-0/±1] http://git.io/V4m8DQ
11:09 < Not-002> [netherrack] thinkofdeath 13808c4 - world: Fix data race in chunk sending
11:25 < dav1d> Drainedsoul: ping
11:29 < Drainedsoul> hi
11:38 < dav1d> Drainedsoul: you got my messages not sure if qwebirc ate it
11:40 < morfin> hmmm
11:41 < morfin> ow
11:41 < morfin> sounds difficult 
11:41 < dav1d> morfin: ?
11:42 < morfin> i mean rewriting entity ids
11:42 < Drainedsoul> what part of that do you think is difficult
11:43 < dx> morfin == dividuum? i'm confused
11:43 < morfin> no
11:43 < dx> okay
11:45 < morfin> i think new login packet will be ignored
11:46 < morfin> i am not sure how it works: as example i join server1 with entity id 666(server tells me that i have ent id 666). Then when i join another server proxy receives new ent id in another login packet right/
11:47 < morfin> but how conflicts are avoided
11:51 < dividuum> bungee does map between client entity ids and proxied server entity ids
11:51 < dividuum> i thought, maybe this can be avoided somehow
11:51 < Drainedsoul> I don't see why it's such a big deal
11:52 < dividuum> because you have in inspect every packet
11:53 < dividuum> it's not a big deal really, but it feels dirty to rewrite various data inside packets.
12:14 < V10lator> Hi, does anyone has any idea why I always get a EOFException at line 13 (in.readByte()) ? http://pastie.org/8351323 - This is for a Bukkit plugin, so Packet254GetInfo and Packet255KickDisconnect are from NMS
12:16 < V10lator> oh and the pinged server just says I lost connection
12:22 < Drainedsoul> if you're doing network operations, and things like EOF etc. are problems, you're going it wrong.  The other end can disconnect anytime it wants.
12:23 < V10lator> Drainedsoul, yea, I'm doing it wrong, that's what I already know. The question is where exactly I'm doing it wrong. According to http://wiki.vg/Server_List_Ping it should be right
12:54 <+md_5> > packets
12:54 <+md_5> > bukkit plugin
12:54 < V10lator> md_5, what are you trying to say?
12:55 <+md_5> I'm trying to say WTF are you doing
12:55 <+md_5> starting a 3rd party MC server from within a bukkit plugin
12:56 <+md_5> for starters you arent even writing the packet ID
12:56 < V10lator> I'm not trying to start a server, I'm trying to ping another server to get its infos
12:56 <+md_5> I'd suggest ditching the NMS class entirely, and rolling it all yourself
12:56 <+md_5> its an equal amount of code, and you are free from NMS dependence
12:56 < V10lator> oh, right, the packet ID... *facepalm*
12:57 < V10lator> well, I might change it to my own code later, but first I want it to work ;)
12:58 <+md_5> V10lator http://files.md-5.net/s/3mqTc.png
12:59 < Drainedsoul> synchronous reads whyyy
13:00 < V10lator> Drainedsoul, who says the code is executed in the main thread?
13:00 < Drainedsoul> who cares?  Why are you tying up a thread doing that
13:00 < Drainedsoul> context switches are expensive stuff
13:01 < V10lator> Drainedsoul, if the pinged server is offline it would hang the server till the network timout occurs...
13:02 < Drainedsoul> wat.  You issue an asynchronous read, you do other things, sometime later you get a callback that says hey your read failed
13:03 <+md_5> Drainedsoul java async io sucks balls
13:03 < V10lator> let the multitheading issues be my problem, I'm handling them... ;)
13:03 < Drainedsoul> well then
13:04 < Drainedsoul> roll yourself some nice C/C++ code that hangs around on an epoll fd/iocp/kqueue >:D
13:04 < jast> event loops are the only sane thing
13:04 < jast> but I'd never want to write one myself
13:05 < jast> ideally you have a runtime environment that abstracts all I/O complications away in an implementation of lightweight threads
13:05 < jast> and takes care of CPU in the same way
13:07 < Drainedsoul> well, IOCP/epoll/kqueue all do that
13:07 < jast> they take care of I/O but not of CPU task multiplexing
13:07 <+md_5> this discussion turned offtopic fast
13:08 < jast> plus the control flow tends to be quite a bit more complicated if you're working in the conceptual framework of an event loop
13:08 < Drainedsoul> depends what you mean.  IOCP at the very least does a lot of magic when multiple threads wait on it.
13:08 < jast> yeah, but IOCP isn't very portable
13:08 < Drainedsoul> :( unfortunately
13:08 < jast> and ISTR that someone told me about disadvantages in IOCP, too
13:08 < jast> though I remember zero details :)
13:09 < Drainedsoul> I'd be interested in hearing that, never heard disadvantages for IOCP.  Everything I've heard is positive.
13:09 < Drainedsoul> apparently you can just take the IO part out of it and use it as a worker task queue and it beats anything you can write in userspace
13:13 < jast> not sure if the person who told me about it knew their stuff, anyway :)
13:13 < jast> there's just so much nonsense going around in this field
13:15 < dav1d> lol
13:15 < dav1d> I have to make a socks tunnel to my vps in germany, so I can buy stuff on steam
13:16 < jast> on the surface IOCPs look pretty much exactly like kqueue and friends, just with a different interface
13:18 < jast> now I don't know kqueue very well, but linux's epoll indeed doesn't have the option to add a custom event to the queue
13:18 < jast> that said, if you make a library that abstracts away the underlying I/O completion mechanism, it's very easy to add that
14:28 < morfin> hmmm
14:46 < morfin> only player ent ids require rewriting?
14:54 < morfin> can you ask me: does player move from server to server without any stuff he had in inventory?
15:19 < SinZ> can be done, just requires more work on the front end
15:56 < morfin> o
21:34 < Thinkofdeath> I don't suppose anyone here knows a way to log in with two accounts at once? Minecraft's launcher doesn't seem to work
21:35 <+sadimusi> why not? you should be able to just create two profiles
21:35 < Thinkofdeath> sadimusi: But if I start two launcher and login with both only one can connect to servers
21:37 <+sadimusi> I have to try that myself
21:38 < Thinkofdeath> "Failed to login: Could not log you in :("
21:39 <+ammar2> eeyup, just got the same thing
21:39 <+ammar2> Failed to login: Bad login, even though it was two seperate accounts
21:40 <+sadimusi> the launcher might be refreshing the access tokens of all accounts
21:40 <+sadimusi> I can reproduce it too
21:40 <+ammar2> Dinnerbone: ^^
21:40 < dx> i feel left out, everyone but me owns two accounts
21:40 < dx> ..at least
21:41 < Thinkofdeath> dx: Only one is mine, the other is borrowed for testing :)
21:42 < dx> oh okay
21:43 < dx> https://account.mojang.com/terms i like this page. this is a nice page.
21:44 <+ammar2> legal mumbo jumbo to cover their asses?
21:44 <+ammar2> yup
21:44 < Drainedsoul> lol @ #1
21:44 < Drainedsoul> someone should frame that and hold it up as a standard for the truest thing ever written
21:45 < Thinkofdeath> Odd the first time I clicked it, it went to https://account.mojang.com/me
21:45 < dx> i mean, i like how it's a no-bullshit version of the legal text
21:45 < dx> other sites should do that more often
21:48 <+ammar2> no
21:48 < dx> god dammit. http://dump.dequis.org/1V8VD.png
21:48 < Drainedsoul> I kind of think distancing people from the "legal text" is bad, because it prevents people from becoming outraged at how bizarre the legal system is
21:48 < dx> lol
21:48 < dx> "outraged" more like "going tl;dr"
21:49 < Drainedsoul> which at the very least instills in them some feeling that it's horseshit
21:49 < dx> yeah i guess
21:50 < Drainedsoul> I might be biased though, as I'm Canadian, and another Canadian company headquartered <500km away from me sued me in Federal Court in the U.S., and apparently that was acceptable
21:50 < Drainedsoul> :|
21:50 < dx> but either way, i don't think the awareness of the shittiness of the legal system is what matters here
22:09 < Not-002> [Craft.Net] SirCmpwn pushed 2 commits to master [+0/-0/±2] http://git.io/EG8KXQ
22:09 < Not-002> [Craft.Net] Slowpython 447fd2f - Update DotMinecraft.cs It seemed as though this was meant to be returned. Without the return statement OSX would use the application Data folder, which may not exist.
22:09 < Not-002> [Craft.Net] SirCmpwn a8acf1d - Merge pull request #189 from Slowpython/patch-1 Update DotMinecraft.cs
22:11 < dx> >slowpython
22:11 < dx> that name insults my religion
22:11 <+AndrewPH> that's unfortunate
22:14 <+ammar2> dx: how is that high speed interpretation treating you
22:17 < dx> ammar2: gotta go fast
22:19 <+AndrewPH> http://www.meh.ro/wp-content/uploads/2013/05/meh.ro11240.jpg
22:20 <+ammar2> dx: how many sanics does your python go
22:23 < dx> ammar2: can't say a number for certain, but the number of sanics increases at factorial rates
23:48 < Not-002> [netherrack] thinkofdeath pushed 2 commits to master [+0/-0/±5] http://git.io/SsYbCQ
23:48 < Not-002> [netherrack] thinkofdeath 1e60a6a - world: Allow sending packets to watchers of a chunk
23:48 < Not-002> [netherrack] thinkofdeath 4a0edbe - world: send block changes to other clients
--- Day changed mer. sept. 25 2013
04:22 < Ghoul_> hmm
04:22 < Ghoul_> I'm a little confused
04:22 < Ghoul_> minecraft is throwing a NullPointerException back at me after 0xFD (EncryptionRequest)
05:57 < Drainedsoul> are you sure that your 0xFD is well-formed?
09:21 < Not-001> [netherrack] thinkofdeath pushed 1 commit to master [+0/-0/±1] http://git.io/y4jgjQ
09:21 < Not-001> [netherrack] thinkofdeath f3f26f7 - protocol: allow offline mode for testing with multiple accounts
14:48 < Not-001> [netherrack] thinkofdeath pushed 6 commits to master [+0/-0/±9] http://git.io/ZI629g
14:48 < Not-001> [netherrack] thinkofdeath 42cf0c1 - entity/player: block dig event
14:48 < Not-001> [netherrack] thinkofdeath eb88eb7 - protocol: fix typo in bool encoding
14:48 < Not-001> [netherrack] thinkofdeath ad11fc7 - protocol: Fixed offline mode causing players not to have UUIDs
14:48 < Not-001> [netherrack] thinkofdeath ac73c21 - world: add World.Block
14:48 < Not-001> [netherrack] thinkofdeath 2abad32 - blocks: correct typos
14:48 < Not-001> [netherrack] thinkofdeath 2f0fc2a - entity/player: limit yaw's range
18:22 < Not-001> [netherrack] thinkofdeath pushed 2 commits to master [+0/-0/±6] http://git.io/_9I0ag
18:22 < Not-001> [netherrack] thinkofdeath 874a0f3 - world,entity: show entities/players to players
18:22 < Not-001> [netherrack] thinkofdeath c169e59 - blocks: change leaves
--- Log closed jeu. sept. 26 08:14:30 2013
--- Log opened jeu. sept. 26 08:14:38 2013
08:14 -!- Irssi: #mcdevs: Total of 107 nicks [1 ops, 0 halfops, 9 voices, 97 normal]
08:17 -!- Irssi: Join to #mcdevs was synced in 195 secs
17:51 < Thinkofdeath> http://wiki.vg/Pre-release_protocol updated with the snapshot, still need to work out why the 'game mode' field of 0x46 is a float now
17:58 <+ammar2> oh god what
18:01 < Not-001> [netherrack] thinkofdeath pushed 2 commits to master [+0/-0/±6] http://git.io/cCSdFA
18:01 < Not-001> [netherrack] thinkofdeath b020580 - /: Store a list of all players
18:01 < Not-001> [netherrack] thinkofdeath 720eba0 - protocol: update to 13w39a
18:29 < Thinkofdeath> Seems to do something with the sky colour
18:30 < dx> better than something like "slightly creative, but mostly survival"
18:30 < Thinkofdeath> lol
18:33 < Thinkofdeath> Maybe not just sky colour http://i.imgur.com/6ySHh2S.png 
19:30 <+ammar2> Thinkofdeath: wow, what an edgy font
19:51 < winny> reminds me of q1 or q2's font
19:52 < winny> yeah, that's q1's isn't it
19:53 < winny> those textures look like the lovecraftian world
19:56  * winny likes where Thinkofdeath is going
20:03 < Thinkofdeath> ammar2: Its the font from Quake 1
20:04 < Thinkofdeath> winny: http://i.imgur.com/IirTA3c.jpg
20:04 < winny> oh man, that's great
20:04 < winny> can i grab your texture pack?
20:05 < Thinkofdeath> winny: It doesn't look good for normal playing http://i.imgur.com/8E98NaN.jpg 
20:05 < winny> ok
--- Day changed ven. sept. 27 2013
00:05 < superjoe> oh snap, mappum open sourced his server
00:05 < superjoe> https://github.com/mappum/redstone
00:07 < superjoe> too bad it's in coffee-script
00:22 < eddyb> superjoe: people should start switching to ES6 already :P
00:22 < superjoe> it's not released yet, is it?
00:23 < eddyb> it's not a thing that gets released, sillies (you're the thousand person I hear this from)
00:23 < eddyb> it's like C++11
00:23 < eddyb> implementation and usage are complementary
00:23 < superjoe> there is a concept of completeness though
00:23 < superjoe> or finalization
00:24 < eddyb> that's per-feature
00:24 < superjoe> but I agree. with a node project you are in control of the executable, so if you want es6 all you have to do is pass --harmony to node
00:24 < eddyb> not only that
00:24 < eddyb> traceur-compiler can already do almost everything in the latest drafts (and a few other things, like async functions - which have uncertain futures)
00:25 < eddyb> it could probably be better, but since I bugged the team (and helped a little), it can already work pretty nicely with node.js modules and stuff
00:26 < eddyb> and a small bonus is that you can do "await data = fs.readFile('foobar');" or "await setTimeout(0);"
00:26 < superjoe> oh neat
00:26 < superjoe> I like that syntax
00:26 < eddyb> that might actually not end up in ES6 :P
00:27 < eddyb> but generators get you almost there
00:27 < superjoe> how so?
00:27 < eddyb> the details of promises/futures are still being discussed
00:29 < eddyb> superjoe: https://github.com/google/traceur-compiler/issues/267
00:29 < eddyb> there are already libraries for doing this with only generator support
00:30 < eddyb> superjoe: ok, found it: https://github.com/google/traceur-compiler/tree/master/test/feature that's what I like to use as syntax examples
00:32 < eddyb> and most of that has been around for one or two years
00:35 < Not-001> [node-minecraft-protocol] mappum pushed 1 commit to master [+0/-0/±3] http://git.io/JjJvEQ
00:35 < Not-001> [node-minecraft-protocol] mappum 5e75cdf - Updated protocol version to support 1.6.4
00:43 < mappum> How do I add my project to the bot?
00:44 < SinZ> n.tkte.ch
00:45 < superjoe> oh hey mappum 
00:45 < superjoe> I see you've open sourced your server
00:46 < mappum> yeah, i just had the code sitting there and thought maybe i might as well
00:46 < mappum> if other people can see it, it might push me to update it
00:47 < mappum> SinZ: cool, thanks
01:09 < Not-001> [node-minecraft-protocol] mappum tagged 5e75cdf as 0.11.6 http://git.io/s_11RQ
02:00 < Ghoul_> :(
02:00 < Ghoul_> verification bytes don't match
02:00 < Ghoul_> now i have to debug encryption which I have no idea how to do
02:41 < Ghoul_> awww hell yes
08:40 <+Prf_Jakob> TkTech: http://www.pcgamesn.com/eve/eve-rubicon-coming-november-19th
08:44 < mappum> Prf_Jakob: <3 eve
21:42 < dividuum> anyone has an idea what packets are missing if a spawned player slowly falls towards the floor?
21:43 < mappum> dividuum: the chunk data for the chunk the player is in
21:43 < dividuum> hm. strange. i'll to check that. thanks
21:45 < dividuum> found the error. i was accidentally sending a second login packet.
--- Day changed sam. sept. 28 2013
00:28 < Ghoul__> anyone know how minecraft floats are supposed to be written in the packets?
00:28 < Ghoul__> I can't find any documentation on how to encode floats/doubles
00:33 < Ghoul__> nevermind, found an implementation
00:43 < mapppum> Ghoul__: it should just be standard, but big-endian
00:55 < Ghoul__> hmm
00:55 < Ghoul__> turns out I think my encryption is wrong. :(
00:56 < Ghoul__> I was sending the correct things but the client keeps giving random incorrect packet ID stuff, but the fact that its random and my code is all constants makes me think AES is busted on my end
03:48 < Drainedsoul> I've seen encryption issues like that
03:49 < Drainedsoul> I'd check to make sure you don't have unsynchronized access to the encryptor
03:49 < Drainedsoul> another possibility is that access to the encryptor is synchronized, but between encryption and sending there's no synchronization, so it's possible for packets to be recieved in a different order than they were encrypted
03:49 < Drainedsoul> obviously not going to work out...
15:23 < Thinkofdeath> The protocol encryption was added to prevent man in the middle attacks right?
15:27 < barneygale> Thinkofdeath: yeah
15:27 < Thinkofdeath> barneygale: Looks like I can mitm in the snapshot
15:28 < barneygale> Oh really? details?
15:29 < Thinkofdeath> barneygale: http://wiki.vg/Protocol_Encryption#Authentication server id is no longer a sha1 hash, its just the serverID sent in 0xFD
15:30 < barneygale> wait, really?
15:30 < Thinkofdeath> yep
15:30 < barneygale> are you sure?
15:30 < barneygale> that would definitely break it
15:30 < Thinkofdeath> Tested it
15:31 < Thinkofdeath> https://gist.github.com/thinkofdeath/d0fa2997886182b6a5ba Adds MITM to every chat message sent by the client
15:31 < Thinkofdeath> Dinnerbone: ^
15:32 < Thinkofdeath> Its a bit messy
15:37 < Drainedsoul> is it wrong that I think my C++ code is easier to read than that? ._.
15:37 < Thinkofdeath> :P
15:43 < Thinkofdeath> It also effect Spigot with the snapshot-protocol turned on
15:43 < Drainedsoul> I don't understand how someone does that, did they rewrite the authentication/encryption code and just forget to hash the server ID string
15:43 < Drainedsoul> like some bugs you see and you're like oh yeah someone totally did this by accident
15:43 < Drainedsoul> but others...
15:44 < iBotPeaches> its to make sure we are awake and protecting
15:44 < Drainedsoul> yeah they're testing the ancient order of #mcdevs, founded to safeguard the security of the Minecraft protocol
15:44 < Thinkofdeath> They moved it into a library
15:44 < Drainedsoul> to make sure we're still protecting mankind from man in the middle Minecraft attacks
15:45 < Thinkofdeath> Is it md_5 and ammar2 who are spigot devs?
15:45 < Thinkofdeath> They might want to disable snapshot-protocol for now
16:25 <+ammar2> Thinkofdeath: ...they seriously made the serverid static?
23:48 < Not-003> [netherrack] thinkofdeath pushed 3 commits to master [+0/-0/±3] http://git.io/2MM5tA
23:48 < Not-003> [netherrack] thinkofdeath 269b20f - entity/player: Fix possible case where the reading goroutine doesn't close
23:48 < Not-003> [netherrack] thinkofdeath 2497b65 - entity/player: Move packet writing into its own goroutine
23:48 < Not-003> [netherrack] thinkofdeath 911932d - /: Move chat onto its own goroutine
--- Day changed dim. sept. 29 2013
01:16 <+md_5> Thinkofdeath poke
01:18 <+md_5> Thinkofdeath ammar2 barneygale  - I'm confused, the serverId is only used in the mc.net auth, not encryption
01:18 <+md_5> the encryption is still the secret shared key
01:23 <+md_5> I see now
01:24 <+md_5> lets just remove encryption :c who cares about mitm
01:24  * barneygale lures a mindcracker to his server
01:24 < barneygale> muahahaha
01:24 < dexter0> NSA gonna snoop on your minecrafts.
01:26  * dexter0 wonders if they've figured out how to snoop on MC traffic.
01:27 < dav1d> I bet they have
01:27 < dav1d> I don't often share sensitive information, but when I do, I do it over minecraft
01:27 < dav1d> so definitly makes sense if NSA infiltrates minecraft traffic
--- Day changed lun. sept. 30 2013
03:04 < Drainedsoul> Can someone explain the vagaries of Notifico to me?
03:44 < Not-003> [bravo] MostAwesomeDude pushed 1 commit to master [+1/-0/±2] http://git.io/YitU2w
03:44 < Not-003> [bravo] Corbin Simpson 8602bab - beta/protocol, beta/structures: Expand Settings and use it for 0xca. Fixes #393.
05:33 < Not-003> [fCraft] fragmer * r2216 8 files : Assorted code cleanup; added two missing names to CpeExtension enum.
05:50 < Not-003> [fCraft] fragmer * r2217 5 files : Added "womid" to list of reserved command names. Changed generated XML documentation file's extension to lowercase. Cleaned up Heartbeat, Vector3I, and Position classes a bit.
09:10 < Not-003> [fCraft] fragmer * r2218 2 files : Fixed inaccuracies in Noise.FindThreshold, and greatly improved documentation coverage in Noise class.
09:46 < Not-003> [fCraft] fragmer * r2219 9 files : Various annotation and comment improvements, notably in IRCCommands.
10:08 < Not-003> [fCraft] fragmer * r2220 7 files : Added autocompletion to /commands category names, and more code cleanup.
10:21 < Not-003> [fCraft] fragmer * r2221 5 files : Got rid of some more legacy code, for pre-0.600 compatibility. It's been almost 2 years, hopefully everyone has upgraded.
11:03 < shoghicp> Hi
11:06 < Drainedsoul> hello
19:08 < TkTech> ... I *think* this is spam? http://wiki.vg/User:Sadfug4w
19:14 <+Prf_Jakob> I think you are right
19:14 < shoghicp> I couldn't find anything around there
19:14 < shoghicp> the text seems "unique"
19:14 < shoghicp> but the "&#25991" part...
19:16 < shoghicp> the text is really written as "&#20462;&#29702;..."
19:16 < shoghicp> except the title
19:16 < TkTech> Dedication, that is.
19:16 < TkTech> And poof it goes.
19:17 < shoghicp> there are some "," instead of ";", or even two ";"
19:17 < shoghicp> weird xD
21:09 < Not-003> [netherrack] thinkofdeath pushed 3 commits to master [+3/-0/±7] http://git.io/-Z_nnQ
21:09 < Not-003> [netherrack] thinkofdeath d11e4f0 - entity: Improvements with how spawning is handled
21:09 < Not-003> [netherrack] thinkofdeath a39c939 - entity/player: add SendMessage method
21:09 < Not-003> [netherrack] thinkofdeath 1dd7b2e - command: add a basic command system, still needs improvements
--- Day changed mar. oct. 01 2013
01:14 < Drainedsoul> Is anyone able to help me understand Notifico?
01:16 < iBotPeaches> Drainedsoul: add hook, add that hook into github web api hooks, add the channels. done
01:19 < iBotPeaches> assuming project on github (project -> settings -> service hooks -> WebHook URLs)
01:31 < Not-003> [MCPP] RobertLeahy pushed 1 commit to master [+0/-0/±3] http://git.io/nt_kQQ
01:31 < Not-003> [MCPP] RobertLeahy 15c37ba - World Column Storage Change ColumnContainer objects are now managed by a std::unique_ptr rather than a SmartPointer. Interest/player counts prevent pointers from being invalidated while they're in use, and therefore the overhead of a reference counting object is unnecessary.
01:31 < Drainedsoul> iBotPeaches: Thanks!
14:34 <+ammar2> "Rewriting the network code in Minecraft today. Using Netty, and may drastically change the protocol for some nice improvements." -Dinnerbro
14:36 < barneygale> abandon ship!
14:40 < t89> im sure this will go well ammar2 
14:40 < dx> ammar2: am i being trolled
14:40 <+ammar2> maybe
15:12 < winny> i hope they switch to udp
15:13 < zutto> winny: but that would actually be an improvement
15:13 < zutto> we cant accept that
15:14 < winny> lol, a dreamer must dream :3
15:20 < eddyb> there was a debate, either with grm or DB...
15:21 < eddyb> they won't change to UDP because they would end up reimplementing most of the TCP on top of UDP
15:21 < winny> lol unfortunately I fear for the same type of ridiculous design
15:21 < eddyb> now, with encryption... it's even less likely
15:23 < eddyb> WoW has a nice protocol: packet type and size in the header, and a certain bit in the size indicates that it's a larger size (kinda like utf8 multibyte encodings). but once you parse the header, you don't need to care about the contents, if you don't want to
15:24 < eddyb> I think the opensource WoW servers I've seen actually put the received packets in a queue, and parsing could be done even in another thread
15:25 < eddyb> (I guess it's the basic sane packet design, not that impressive)
15:25 < Flemmard> well yeah generally *every* protocol have this kind of thing, type of packet, size of packet, then the data
15:25 < jast> nah, most text-based ones don't
15:26 < barneygale> Dinnerbro: Sorry, it's pretty drastic in some aspects. You're getting the length header, for example.
15:26 < barneygale> length header!
15:26 < barneygale> sweet zombie jesus!
15:28 < SinZ> will be interesting to see the snapshot this week
17:25 < dx> "Most packets themselves aren't going to change much but the handshaking and ping procedure is being redone" - dinnerbro
17:25 < dx> i wonder if this is a "fuck backwards compatibility of ping packets" or not
17:26 < dx> they seemed to hate that
17:26 < dx> well, the code, not the backwards compatibility itself
17:30 < Dinnerbone> I'm going to try to keep back compat with old ping but that's it, and no promises
17:30 < TkTech> I don't think anyone here will complain if you break it.
17:30 < Dinnerbone> Users will.
17:30 < TkTech> Users are silly things.
17:30 < Dinnerbone> I agree
17:33 < dx> yeah, reading the messages dinnerbro replied to, he seems to get lots of dumb messages
17:35 < dx> my favorite one is "man, you really need to get that api to be a thing, so we don't have this crap every update"
17:37 < TkTech> I...what?
17:38 < TkTech> API at what level? That complaint kinda makes sense from the perspective of a modder.
17:39 < jast> it's APIs all the way down, didn't you know
17:44 < dx> TkTech: kinda, but it's replying to the message about refactoring networking code. it's just very short sighted to refer to that as "this crap".
17:45 < jast> when talking about "this crap", the guy was probably talking about his own face
17:45 < dx> lol
17:52 < dx> Dinnerbone: UTF-8?
17:54 < SinZ> this rewrite is something we have been wanting since beta came out
17:54 < SinZ> maybe earlier, but meh
17:55 < dx> yeah, i think we're not expressing our excitement enough
17:55 < dx> so here it is: FUCK YEAH
17:55 < SinZ> Also, this might mean the y height might not be 3 different data types
17:55 < shoghicp> wooo
17:55  * shoghicp hopes that extends to MCPE too
17:56 < dx> shoghicp: what does? isn't the mcpe protocol completely different?
17:56 < shoghicp> The packet structure is really similar
17:57 < shoghicp> inside the raknet packets
17:57 < dx> oh i see
17:57 < shoghicp> also... Y can be an int, short, ubyte and byte
17:57 < SinZ> just went through the protocol, Y currently has 5 different data types
17:57 < shoghicp> (and float)
17:57 < SinZ> byte, short, int, double, float
17:58 < shoghicp> see? they are similar
17:59 < SinZ> ranging from 1-4 bytes
17:59 < dx> you've got ubytes though
17:59 < dx> in java, "ubyte" is a typo
17:59 < shoghicp> yep, but they are going to change that
17:59 < shoghicp> also, I found a bug with the "short"
18:00 < shoghicp> it should be a byte or a int
18:00 < shoghicp> some kind of compiler optimization
18:00 < dx> interesting
18:00 < shoghicp> yep
18:00 < shoghicp> johan said that was due to not being explicitly defined there
18:09 < barneygale> Dinnerbone: while you're doing net things, I /promise you/ I'll buy you a pint of reasonably priced alcohol if you take a look at https://mojang.atlassian.net/browse/MC-10984 - It's a 2-line fix but would make my life a whole bunch easier
18:13 < TkTech> From the /query wiki page, "A simple way to parse the payload is to ignore the first 11 bytes, and then split the response around the token \x00\x01player_\x00\x00. At the very end there's an extra null byte"
18:14 < TkTech> I'm inclined to remove this as it promotes bad practice and is definitely not what you want to do.
18:15 < Dinnerbone> barneygale: fixed
18:15  * Dinnerbone goes home
18:15 < barneygale> Dinnerbone: thankyouthankyouthankyou
18:16 < dx> whoa.
18:17 < dx> dinnerbro is such a bro
18:18 < dx> barneygale: so what are you going to buy him?
18:19 < barneygale> guess it depends if dinnerbro is in london any time soon
18:19 < barneygale> or I suppose I could get some kind of spirit and mail it over
18:19 < Grum> send it to the office so i can have some toO!
18:20 < barneygale> To sweden? D:
18:20 < Grum> yes =D
18:20 < barneygale> I shall look into it :D
18:20 < SinZ> you did promise after all
18:21 < TkTech> Keep in mind that if you don't send the booze, you'll crush Dinner's faith in humanity, leaving him in a chronic state of unproductive depression and nothing will ever get fixed again.
18:21 < barneygale> Normally when one says "I'll buy you a pint" they mean in-person, but I can arrange something
18:22 < Grum> <dx> "Most packets themselves aren't going to change much but the handshaking and ping procedure is being redone" - dinnerbro <-- except for half of their ids
18:22 < edk> Organize some kind of meetup thing so I can buy him one as well
18:22 < Grum> <dx> Dinnerbone: UTF-8? <-- yes
18:23 < Grum> edk: minecon? ;D
18:23 < edk> Grum: I don't think my current net worth would cover a minecon ticket + flight to anywhere
18:24 < edk> I might have to sell my body
18:24 < SinZ> Grum: organise the next Minecon outside edk's house
18:24 < umby24> same, edk. xD
18:24 < SinZ> Grum: Mojang should come to PAX Aus next year, it was a fun time this year
18:31 < dexter0> Will anyone here (aside from the Mojang folks) be at minecon?
18:34 < Grum> [15:25:38] <Flemmard> well yeah generally *every* protocol have this kind of thing, type of packet, size of packet, then the data <-- we'll most likely flip it, size, type, data
18:40 < dx> 13:22 < Grum> <dx> Dinnerbro: UTF-8? <-- yes <-- <3
18:43 < Grum> tbh it makes more sense to do: size, type, data
19:01 < jast> with most packet-based protocols it makes no difference because usually endpoints will read the complete packet header in one go
19:02 < jast> and often the size value excludes the header
19:05 <+pdelvo> I cant understand that there are people on twitter complaining about the protocol changes
19:05 < Grum> yeah but the header (type) will not be constant size :)
19:05 < Grum> pdelvo: people always complain
19:06 <+pdelvo> they do :(
19:07 < Grum> ohnoes change is bad! ... well .. then do not play minecraft, go play something that makes you pay for extra content/changes/features
19:08 < jast> sure, if you have a variable-size header, putting the size first makes some amount of sense :)
19:08 < Grum> varints ftw =)
19:08 < Grum> very future compatible ;)
19:09 < jast> you know what's even more future-compatible? ASN.1
19:09 < jast> one charming side effect is that ASN.1 will DEVOUR YOUR SOUL
19:09 < Grum> good tradeoff
19:12 <+Amaranth> I seem to remember something about ASN.1 being turing complete
19:12 < jast> nah
19:13 < jast> though you could, of course, represent ASTs in ASN.1
19:13 <+sadimusi> with a varint as the packet id it will be pretty hard to keep backwards compatibility for pinging
19:14 <+sadimusi> having the size first makes it even harder
19:14 < SinZ> just have a legacy handler that is only active on login would do the job
19:15 <+sadimusi> that's pretty hacky but probably the only way
19:15 < SinZ> can be removed in future versions when backwards compatibility doesn't mean much anymore
19:15 <+Amaranth> Or just no
19:43 < TkTech> Grum: +1 for uint32_t length -> uint8_t packet_id, -> uint_8_t[] data.
19:44 < TkTech> Grum: Makes it simple to have an outgoing queue of packets where your write op only needs to prepend the length without any other work.
19:46 < TkTech> I'm curious, but I've been out of the loop for a long time.
19:46 < TkTech> sadimusi: Why does backwards compatibility matter here?
19:47 < TkTech> My opinion would be to break away and move on.
19:56 < Grum> TkTech: VarInt length, VarInt packetId, byte[] data
19:57 < TkTech> Grum: ~_~ VarInt? Custom type or provided by some library?
19:57 < Grum> quite 'standard' thing where you drop the msb of each byte to indicate 'another one coming'
19:58 < Grum> so you get 7 bits per byte of 'data'
19:58 < Grum> just a variable-length int
19:59 < TkTech> I'm assuming you guys actually profiled this and it's a wortwhile optimization?
20:00 < Grum> profiled how?
20:00 < TkTech> Bandwith, TCP latency on Windows, BSD/OS X and Linux 2.6+ with and without nagles.
20:00 < Grum> euuh?
20:01 < Dinnerbone> It's virtually no more expensive than normally writing out an int of any type to a stream, except that it only takes 1/2/3/4/whatever bytes instead of a constant 16 bytes
20:01 < Grum> yeah
20:01 < Grum> it'll just be shorter often
20:01 < Grum> 4 bytes
20:01 < TkTech> Right, there's no other savings.
20:01 < Dinnerbone> Yes but there's no other cost neither
20:02 < Grum> to recompose 4 bytes into an int you do: a << 24 | b << 16 | c << 8 | d ...
20:02 < Dinnerbone> 0 cost some gain, makes it worth the incredibly small effort to implement in my view
20:02 < Grum> vs: a & 0x7F << 21 | b & 0x7F << 14 | c & 0x7F < 7 | d & 0x7F
20:03 < Grum> sure, we can only transfer 28 bits per 4 bytes
20:04 < TkTech> I understand the reasoning, and I understand the how, wasn't really my question.
20:04 < Grum> but seeing we mostly stay under 2^21 (we rarely go over 2^16 actually)
20:04 < Grum> almost all our sizes will be 1-2 bytes vs 'strict 4' for uin32
20:04 < Grum> +t
20:05 < dx> so everything will be a ``VarInt''?
20:05 < Dinnerbone> Not everything
20:05 < Grum> where we can use it
20:05 < TkTech> Reworded, *Does sending "01 00 00000001" vs "00000001 00 00000001" happen to improve latency when naggle is disabled?
20:05 < Grum> or need to
20:05 < Dinnerbone> But everywhere it's smart to use
20:05 < Grum> TkTech: who cares for latency with nagle?
20:05 < Grum> not sure how it would even influence it
20:06 < Grum> nagle just provides local buffering right?
20:06 < TkTech> Are you guys explicitly disabling it?
20:06 < Grum> as we are now
20:07 < Grum> every thing that cares for latency does
20:07 < Grum> we can argue we do not care because we use TCP but lets put that aside ;)
20:08 < dx> so why is this varint thing worth doing?
20:08 < Grum> saves space?
20:08 < TkTech> When your packets are smaller, and spammy (like 00), having nagles enabled will negatively affect latency.
20:08 < Grum> you can send an intacross in less than 4 bytes?
20:09 < TkTech> The packet is too small to clear the buffer right away.
20:09 < dx> okay
20:09 < Grum> we're still supporting a buffered connection
20:09 < Grum> having nagles enabled will negatively affect your latency *always*
20:09 < Grum> unless you fill the buffer it expects every single time perfectly
20:10 < Grum> s/supporting/sporting
20:11 < barneygale> Would using an int32 for packet id be a significant bandwidth drain? It seems to me that it would be the best solution, provided it's not an unreasonable impact on bandwidth
20:11 < Grum> i dont see why we would if we have varints
20:11  * barneygale googles varints
20:11 < TkTech> The VarInts just seem like an unnecessary pre-mature optimization.
20:12 < barneygale> I assume they work something like UTF? If so I agree with Tk
20:12 < TkTech> Which I habitually shy away from without supporting profiling showing an advantage.
20:12 < Grum> TkTech: its more like a future-flexibility
20:13 < barneygale> right, but you need to define where your future ends. Surely 4 bytes would be sufficient, and if it's not a big deal bandwidth-wise, why complicate things?
20:13 < Grum> why would it complicate any things?
20:14 < TkTech> Grum: If the protocol grows to the point where you have more than 255 packet types, or excessively sends packets (other than map data) that require more than an int16 for length something is wrong.
20:14 < Grum> its not just that TkTech
20:14 < TkTech> Actually, I may be misunderstanding.
20:14 < Grum> we can actually simple stop using old ids
20:14 < Grum> and skip to a new one
20:14 < TkTech> Why? You have a version field in the handshake.
20:15 < barneygale> Grum: notch used a 5bit/3bit thing for entity metadata. It's not massively complicated either, but it still trips up a significant portion of people who have written code for it over the years
20:15 < Grum> i'm not sure i have to care for people doing things they cannot do
20:15 < TkTech> barneygale: That's not an excuse Mojang should or would care about.
20:15 < Grum> we'll document it
20:15 < Grum> we might even use protobufs when we resign the protocol in the future
20:16 < dx> lol "resign"
20:16 < Grum> hehe
20:16 < barneygale> Grum: TkTech, fair enough
20:16 < Grum> freudian slip!
20:16 < dx> definitely.
20:16 < Grum> +de;)
20:17 < barneygale> I suppose using varints for packet length makes a reasonable amount of sense, and if there, why not also use it for ID?
20:17 < Grum> yup
20:18 < Grum> doesn't mean we'll be using 'it for all the things'
20:18 < dx> i'm still not sure if i like it.
20:19 < dx> would love to see some comparisons / profiling of bandwidth usage
20:19 < Grum> i'm sure i do not care if you like it :)
20:19 < dx> i knew you would reply with that
20:19 < Grum> on average it should save bandwidth
20:19 < Grum> the math is rather siple
20:19 < Grum> *simple
20:19 < dx> yeah, but like tktech said, it could be a premature optimization too
20:19 < Grum> its not
20:20 < Grum> its meant as a 'future flexibility'
20:20 < Grum> means we can grow from the 'byte' as packet-id
20:20 < Grum> and have graceful protocol changes where every packetid is always handled unique if we'd care to
20:21 < barneygale> Grum: I think you or Dinnerbone mentioned keeping server list ping compatible with past versions. Anything you can reveal on how you're doing that?
20:21 <+ammar2> god that would be so hacky
20:21 < barneygale> well exactly
20:21 < barneygale> the 0xFA stuff is already somewhat hacky, though a welcome change nonetheless
20:21 <+ammar2> just break everything and get it all over in one swoop :P
20:21 < Dinnerbone> I said that I would *try*
20:22 < Dinnerbone> But it's super low priority
20:22 < Dinnerbone> And that it's not a guarantee
20:22 < Dinnerbone> And that it would be restricted to ping only
20:22 < barneygale> OK, just wondering
20:22 < Grum> barneygale: we can specialcase the ids
20:22 < Grum> but we rather not
20:22 < barneygale> I don't really mind if it's incompatible
20:22 < Grum> we rather just say fuck it
20:22 < dx> just consider pings as a different protocol
20:22 < Grum> barneygale: you are again not representative for the 12m people ;()
20:22 < dx> there's no reason it should be part of the same one, and accept the same kind of packets
20:22 < barneygale> Grum: I said I /don't/ mind
20:22 < TkTech> Grum: You don't need to care about the 12m people, push a launcher and client update and you're dandy.
20:22 < Grum> ;D
20:22 < barneygale> keep it compatible or don't, it doesn't bother me :)
20:22 < TkTech> Grum: It's the service hosters and devs that will care.
20:23 < Dinnerbone> I can make the ping just simply attempt the old method if the new one didn't work
20:23 < Grum> TkTech: awesome not! ;D
20:23 < Grum> Dinnerbone: the issue is the possible spam @ new server
20:23 < Grum> but we'll see
20:23 < Grum> we can probably catch that
20:23 <+ammar2> you don't even need to ping the servers properly, just say "Outdated server" if you can establish a tcp socket and the server sends you a 0xff for your 0xfe
20:23 < TkTech> Does it matter? That should be two or so context switches and a very early termination
20:24 < dx> ammar2: but pinging from 1.6 client to 1.7 server matters too
20:24 < Grum> TkTech: if every packet is prefixed with the length and you just connect with 'shit' ... everything will fall apart
20:24 <+ammar2> dx: woops right, oh well
20:24 <+ammar2> screw it
20:25 < dx> let's just ignore the hackiness in the pings, it can't be helped :(
20:25 < Grum> we can see if we can make it working
20:25 < Grum> i seriously doubt it
20:25 < TkTech> Grum: Sure, and you guys need to handle that case, there's nothing you can do to get around that.
20:25 <+ammar2> dx: well, you could just throw the new method and the old server should drop you for invalid packet id
20:25 < Grum> TkTech: you cant
20:25 < TkTech> Then don't, the path of infinite backwards compatibility is not a fun one.
20:25 < Grum> or we might not be able to
20:25 < barneygale> FWIW, I always thought (packet id, len(data), data) made more sense than (len(packet), packet id, data)
20:25 < Grum> or it might not be worthwhile
20:25 < Grum> barneygale: its not
20:26 < TkTech> Grum: How so? Read the length, read the next VarInt (packetId), invalid, dump without reading data[].
20:26 < Grum> TkTech: right, so what is the 'ping-packet'id?
20:26 < TkTech> barneygale: Think about a threaded server.
20:26 < TkTech> barneygale: A simple model which builds the packet and puts it on a stack to write out.
20:27 < TkTech> barneygale: The thread that's writing can just write(len(buffer)) + write(buffer)
20:27 < barneygale> That's true
20:27 < dx> also, i'm not sure if i understood it right, what's the maximum size in bytes of a varint field?
20:27 < barneygale> I guess I'm coming from it too much from a client perspective
20:27 <+ammar2> dx: theoretically infinite
20:27 < Grum> dx: infinite
20:27 < dx> perfect, thanks.
20:28 < Grum> we'll not support that though
20:28  * barneygale is excited for these changes
20:28 < TkTech> barneygale: Even then, your thread, coroutine, or what not doing the reading can read the length, put it on the stack, and keep at it without caring about the packet_id.
20:28 < Grum> TkTech: what is the packetid for the current 'request ping data' ?
20:28 < SinZ> 254
20:28 < barneygale> 0xFE
20:28 <+pdelvo> 0xFE
20:28 < Grum> and that actualyl causes a big problem already
20:28 < Grum> the msb is set :P
20:28 < barneygale> Yes, heh
20:29 < barneygale> next byte is 01
20:29 < dx> fun
20:29 < Grum> so we'll be reading: FE bytes after
20:29 < Grum> E_NO_AVAIL
20:29 < Grum> however
20:30 <+pdelvo> I would just dont have any backward compatibility to 1.6 and then in the new protocol have the version in the new server ping request packet to be more flexible in the future
20:30 < Grum> we can make a specialcase, to initiate a fallback if the *FIRST* packet happens to has the first byte or size set at a certain value
20:32 < TkTech> That's never a good idea.
20:32 < Grum> i know
20:33 < Grum> so its very likely we will simply accept the minor incompatibility (old clients not getting sane responses from new servers)
20:34 < barneygale> If you read FE 01 as a length, then FA 00 as packet ID, you get a Packet #122. At that point you could put in a special case to not read any further..
20:34 < barneygale> I suppose?
20:34 < barneygale> I don't think there's any non-hacky way to make it backward-compatible
20:35 < Grum> barneygale: no, after FE 01 we'll wait for that amount of bytes
20:35 < Grum> if we do nto get it, we break the connection
20:36 < Grum> You'll just get a read-timeout-error
20:37 < TkTech> Which the client already handles
20:37 < TkTech> *launcher
20:38 < Grum> not really?
20:38 < Grum> well
20:38 < Grum> this would just be rather ungraceful
20:39 < TkTech> Sure it does, the launcher handles timeouts during the server list ping just fine?
20:39 < Grum> the launcher has nothing to do with this
20:41 < TkTech> Yeah, I was right the first time. *Client. Not sure why I "corrected" that.
20:41 < Grum> yeah the client 'handles' it but it takes 30 seconds
20:44 < Grum> it should say: "1.7" :p
20:44 < Grum> btw obviously we'll reset the protocol version back to 0
20:44 < Grum> just for funsies ;)
20:44 < TkTech> You're dead to me.
20:44 < Grum> <3!
20:45 < Grum> not sure why that is a problem
20:45 < TkTech> I remember when Notch rolled it back at least 5 times in two weeks.
20:45 < Grum> its almost the same as resetting version numbers when doing alpha -> beta
20:45 < TkTech> Screws with tools and sites that track versions automatically.
20:45 < Grum> pfft
20:45 < Grum> they deal with more shit
20:45 < TkTech> Especially the simple check of >=
20:46 < TkTech> sadimusi: ^- Heads up
20:46 < Grum> well, people will learn!
20:46 < SinZ> just have ~80 versions between now and release so it still works
20:46 < SinZ> ^.^
20:46 < Grum> nah
20:47 < Grum> don't forget, we can now actually skip packets we do not understand :p
20:47 < SinZ> yay
20:47 < SinZ> does that mean modders just adding new packets wont cause derps
20:47 <+pdelvo> thats like school
20:47 < Grum> we wont ofc
20:47 < Grum> we'll fail on them
20:47 < Grum> HARD
20:47 < Grum> break the connection
20:48 < TkTech> SinZ: That's a bad idea.
20:48 < SinZ> heh
20:48 < Grum> we have to
20:48 < Grum> else you can trivially ddos a server
20:48 < Dinnerbone> Modders adding new packets should be using the plugin channel packet
20:48 < SinZ> should but some modders are idiots
20:49 < SinZ> hell, Forge doesn't even hook into the function called getPlugins() for query support
20:51 < barneygale> Dinnerbone: Grum: one final idea. Assign a new 1-byte packet to the /old protocol/, e.g. 0xFA, meaning "switch to new protocol". When a client connects to a 1.7 server, read 1 byte. If you get 0xFA, switch to the new length-prefixed protocol. if you get 0xFE, send an old-style server ping response. If you get anything else, send an old-style kick("Outdated client!")
20:51 < barneygale> err, not 0xFA. 0xF0
20:51 < barneygale> FA is taken ;D
20:52 < barneygale> And once everything prior to 1.7 is forgotten, 0xF0 essentially becomes your magic byte
20:52 < barneygale> I guess it would be a "connection header"
20:52 < Grum> barneygale: no
20:52 < Grum> because we cannot ever get away from that
20:53 < barneygale> is it such a terrible thing to have to get away from?
20:53 < Grum> yes?
20:53 < Grum> lets make new code to instantly introduce legacy in it
20:53 < TkTech> Grum: Ah, the Microsoft Approach™.
20:54 < barneygale> IMO it's the least intrusive way to maintain legacy support
20:54 < TkTech> Who cares? Death to legacy.
20:54 < barneygale> Well, whatever
20:54 < Grum> barneygale: i dont care for legacy support
20:54 < Grum> it matters for ONE whole version
20:54 < Grum> after that no-one cares
20:54 < TkTech> At some point you need to introduce breaking changes, otherwise you're stuck spending half your time working on backwards compatibilty.
20:54 < Grum> no-one cares for 1.3, 1.4 anymore
20:54 < barneygale> I understand that
20:54 < Grum> the second 1.7 comes out people stop caring for 1.5
20:55 < Grum> and if they dont, well, no whines if you do not want to upgrade
20:55 < barneygale> Alright
20:55 < Grum> in the not too far future people won't be able to play online using old versions
20:56 < Grum> because our session server will just accept new auth
20:56 < Grum> skins will eventually go away too from where they are now
20:56 < barneygale> I'm totally fine with that. My rationale is that if you /did/ have any inclination to maintain legacy support, a 1-byte header once at the beginning of a connection would be a small price to pay.
20:56 < Grum> its a high price to pay
20:56 < Grum> its a price you cannot ever get rid off
20:57 < barneygale> That's quite an abstract pricer
20:57 < barneygale> price*
20:57 < Grum> no, its infinitely costly
20:57 < barneygale> or I guess I'm not understanding its significance
20:57 < Grum> fixing it means breaking things
20:57 < Grum> and you carry that with you forever
20:57 < Dinnerbone> There's also the issue of we'd have to go back in time to add that packet to 1.7
20:57 < Dinnerbone> Uh
20:57 < Dinnerbone> 1.6
20:58 < barneygale> Oh, yeah. 1.7 client -> 1.6 server?
20:58 < Grum> we can consider a hacky pipeline element that specialcases this one packet, if its not too much work and pain we cna keep that in for 1-2 versions and then delete it
20:58 < barneygale> That ruins the whole idea, good point Dinnerbone
20:58 < Grum> Dinnerbone: we can just have a 'peek'-channelinboundhandler
20:59 < Grum> that removes itself after the first interaction with data
20:59 < Dinnerbone> I only care about ping, and it's not a priority. Players on 1.7 should see 1.6 servers listed as "1.6", and players on 1.6 should see 1.7 servers listed as "1.7".
20:59 < Dinnerbone> I'll probably make this happen by a fallback on the ping request
20:59 < Grum> well 1.6-> 1.7 server ping is the problem
20:59 < Grum> as it'll send FE01
21:00 < Grum> which for us means: 'read FE bytes of data NOW'
21:00 < Grum> but we can just specialcase it as i jsut said, should be doable
21:00 < Dinnerbone> Yeah
21:00 < Dinnerbone> It really helps that we have the ability to rewing the data now
21:00 < Dinnerbone> Bookmark, try new. Didn't work? Rewind, try old.
21:00 < Dinnerbone> s/rewing/rewind/
21:00 <+ammar2> hmm, with the launcher can't you actually go back to 1.6 and change stuff there
21:01 < Dinnerbone> Mods.
21:01 < Grum> so no ammar2
21:01 < Dinnerbone> We *can* update 1.6.4, but we don't want to. Mods will have to update too, and they can't update like we can
21:01 < barneygale> I really suck at installing mods in the new launcher
21:01  * barneygale is stuck in his ways
21:03 <+ammar2> Grum: maybe add something for small binary patches for future use? I'd like to imagine no mods modify the code used to send 0xfe, and if they do the patch can just be rolled back
21:03 < Grum> ammar2: we have
21:03 < Grum> its called LegacyLauncher :)
21:04 < Grum> its what the old version use, public, source available
21:06 < SinZ> which is what Forge uses iirc
21:13 < Grum> yup
23:01 < Not-003> [fCraft] fragmer * r2222 38 files : Further enhancements in annotation and documentation, notably in Config. Fixed Trie enumerators throwing ArgumentNullException when trying to enumerate an empty trie/subtrie. Color.Parse/Color.GetName/Rank.Parse no longer accept nulls.
--- Day changed mer. oct. 02 2013
00:33 < Blazedd> Oh wow quite a few people are here. Didn't expect this many people to be in this channel.
00:34 < Blazedd> So is mcdevs a collective of developers that make tools or something else? The website was very unclear as to affiliation.
00:35 < Blazedd> I guess the more important question now is the typical "who isn't idle"?
00:35 < Blazedd> (irc)
00:35 < Blazedd> the typical irc question**
00:35 < Paprikachu> it's a channel for minecraft related development
00:36 < Paprikachu> be it clients, server, libraries, whatever
00:36 < Blazedd> Ah, I see. I was kinda trying to find out who was primarily behind mark2, and burger. I know it's open source, but just trying to find out who.
00:41 < dexter0> the burger maintainer is in this channel, no idea about mark2 (never heard of it).
00:56 < Not-003> [fCraft] fragmer * r2223 2 files : Improved documentation in Trie, and added some more assertions.
00:57 < Not-003> [fCraft] fragmer * r2224 2 files : Removed old debugging/profling code from Fill3DDrawOperation
01:16 < barneygale> Blazedd: mark2 is me and edk141
01:17 < barneygale> mcdevs is mainly this channel. there's a website to explain what it is, also a little-used git repo as most people release their code under their own name or organisation
01:17 < barneygale> s/repo/organisation/
01:31 <+sadimusi> TkTech: backwards compatibility matters to me because I have to fetch the status of 30k servers every minute and trying two different methods would slow that down significantly
01:36 < winny> udp udp udp udp udp udp
01:39 <+sadimusi> winny: as you know there exists a (terrible) udp protocol for this purpose, but only about 20% of the servers have it enabled
01:39 < winny> you're referring to query right?
01:39 <+sadimusi> yes
01:40 < winny> idk, it was easy enough to write a tool that can utilize it
01:40 < winny> it's based off the UT query proto so that's why it's broken
01:40 <+sadimusi> I know
01:40 <+AndrewPH> did you miss the part where he said 20% of servers have it enabled
01:40 <+sadimusi> doesn't help me much though
01:42 < winny> i'm out of context -- i was spamming "udp udp udp" because i'm anticipating minecraft.java that utilizes udp for everything and I'd doubt there is a benefit to using the query proto instead a new server ping packet _if_ this udp thing every happens
01:42 < winny> ever happens* even
01:43 <+sadimusi> udp for everything definitely won't happen
01:43 < winny> ok, i'll have to dream harder, haha
04:59 < Not-003> [bravo] MostAwesomeDude pushed 3 commits to master [+0/-0/±6] http://git.io/iUq7JQ
04:59 < Not-003> [bravo] Corbin Simpson 925ed06 - world: PEP 8.
04:59 < Not-003> [bravo] Corbin Simpson 9d3ab1c - world: Start factoring out caching behavior. Now the permanent cache is a separate object which has its own rules. Also added a handful of tests and moved permanent cache initialization into World and out of the Factory. It's a detail of World that nobody else should see. Refs #366.
04:59 < Not-003> [bravo] Corbin Simpson 9676b27 - world: Make enable_chunks() return a Deferred, and test. This test actually shows off some pretty deep codepaths. Refs #366.
05:12 < Not-003> [bravo] MostAwesomeDude pushed 1 commit to master [+0/-0/±1] http://git.io/ekeVSQ
05:12 < Not-003> [bravo] Corbin Simpson ab0ae69 - utilities/automatic: Only feed acceptable blocks to automatons. This explains quite a bit of the slowness around ``naive_scan`` and why redstone was causing so many problems!
05:18 < Eviltechie> Not-003: help
05:19 <+AndrewPH> users with the name Not-00x are (usually) bots (unless somebody's trying to be a clever girl)
05:19 < Eviltechie> I know, and bots usually respond to a help command
05:22 < umby24> maybe with a command prefix
05:22 < umby24> dunno about with a ping
05:48 < Eviltechie> umby24: Every bot I've seen usually takes direct commands (a ping) or a prefix
05:51 <+AndrewPH> Eviltechie: Notifico is less of a general use bot and is more of a notifications-only bot. I don't think it even responds to anything anybody says in irc
06:04 < TkTech> sadimusi: Wait, you do? What are you doing?
06:04 < TkTech> sadimusi: Server list?
06:06 < dx> nice lag
06:10 < umby24> i've seen maybe 2 that take "direct" commands (their name first)
06:10 <+AndrewPH> umby24: voxelhead does (on esper), I forgot what it is. eggdrop bot maybe. Also, anything based on supy usually.
06:11 < umby24> that might have been one of the two
06:11 < dx> my irc bot used to work like that too. rip my irc bot
06:11 < umby24> the one I made, Yoshi2's, and Sinz' all take a command prefix
06:11 < Eviltechie> rbot, skybot
06:12 < Eviltechie> The chanserv on some networks I am on also takes direct commands
06:12 < Eviltechie> actually, no it dosen't
06:17 < umby24> we just made our own bots sooo meh
06:27 < Not-003> [fCraft] fragmer * r2225 10 files : More cleanup here and there, notably in PerlinNoise and Server classes.
12:16 <+sadimusi> TkTech: I operate http://minecraftservers.org
12:16 <+sadimusi> TkTech: you even recommended me for the job
12:23 < Not-003> [mc4p] sadimusi pushed 2 commits to master [+0/-0/±2] http://git.io/n656Bw
12:23 < Not-003> [mc4p] Florian Wesch 88d389a - fixed parsing of 0xcf
12:23 < Not-003> [mc4p] Simon Marti 5ca9fe5 - Merge pull request #2 from dividuum/master
12:33 < dividuum> sadimusi, got a second? I'm wondering if the way messages are version in mc4p can be improved somehow
12:34 < dividuum> because right now, if i create a new protocol version 78, it inherits all message types in the scope while defining it
12:34 < dividuum> so it gets the version 75 NamedSoundEffect, which has the category field
12:35 < dividuum> this field is not included in the 78 version, since it is based on the 74 version. 75 is the snapshop branch...
12:35 < dividuum> so basically i think protocol version should be based on a parent version, inherit it's messages and only add the locally defined messages for that version
14:11 <+sadimusi> dividuum: we could add an optional parent version to the protocol.version method
14:14 < iBotPeaches> sadimusi: some of those server player counts :o
14:14 < iBotPeaches> and I thought 10 was a lot
14:15 <+sadimusi> those are mostly networks running behind bungee or something
14:17 <+sadimusi> dividuum: it's probably best to wait for the refactoring before doing anything
14:40 < dividuum> sadimusi, what refactoring? for the upcoming protocol changes talked about yesterday?
15:00 <+sadimusi> dividuum: yes
--- Day changed jeu. oct. 03 2013
00:50 < Brottweiler> dav1d: you know MCExpertDE?
11:25 < dav1d> Brottweiler: no, waht is that?
12:36 < Brottweiler> dav1d: some german youtuber who played on OCN yesterday, famous apparently
19:21 < Eviltechie> http://dev.minecraft.net/
19:21 < Eviltechie> Gone.
19:22 < Eviltechie> Not that there was much there to begin with, but...
19:24 < dx> never heard of that page
19:25 < dx> what did it have?
19:25 < Eviltechie> It was the blog for all things related to the official api
19:25 < dx> oh
19:25 < dx> meh.
19:25 < Eviltechie> EvilSeph made two posts on it last novemeber I think
19:25 < Eviltechie> And never touched it again.
19:25 < Eviltechie> Now that he just left mojang, it's been removed
19:25 < dx> rip evilseph
19:30 < Morrolan> He left?
19:31 < Eviltechie> https://twitter.com/EvilSeph/status/385537792794959872
19:31 < Morrolan> Heh.
19:34 < Eviltechie> I would speculate that there was a falling out. It wouldn't be the first time that that sort of thing has happened.
19:34 < Morrolan> Who knows. :)
19:35 < Morrolan> (That's a rhetorical question. If you answer with "EvilSeph" I'll slap you. :P)
19:35 < dx> lol
19:37 < dx> last time i heard about him, had some 'personal issues' stopping him from spending much time messing with minecraft.
19:37 <+ammar2> Eviltechie: nice alias, EvilSeph
19:38 < dx> lol
19:53 < billyyjoee> kahrl, you there?
19:54 < kahrl> yes?
19:54 < billyyjoee> Creator of MCPatcher, right?
19:54 < kahrl> nope
19:55 < kahrl> all I made was a chunk fixer back in the pre-anvil days
19:55 < billyyjoee> Your name has one letter difference. The creator of MCPatcher is named Kahr.
19:56 < kahrl> interesting
19:56 < dx> ._.
19:56 < billyyjoee> You've never seen a Kahr in this IRC at all? Really need to speak to him.
19:56 <+pdelvo> Do you have a question? Maybe we can help even if we are not kahr
19:57 < billyyjoee> I'm from The VoxelBox. We use the voxelmodpack and theres a rumour going around that Kahr is removing the feature in CTM which allows alternate textures. Wanted to see if the rumour was true or not, that's all.
19:58 < billyyjoee> We use the alternate textures in CTM a lot. Most of our builds use it, so it's going to be quite harsh on the server if he is.
23:46 < Grum> < Eviltechie> [19:26:05] Now that he just left mojang, it's been removed <-- no the only thing removed, it was a happy timing coincidense btw
23:47 < Not-003> [fCraft] fragmer * r2226 9 files : Replaced boolean options with enums for PlayerInfo.Freeze/Unfreeze/ChangeRank and Player.Kick
23:48 < SinZ> shame, the dev blog was a decent idea, but perhaps too soon
23:49 <+AndrewPH> could somebody pastebin what I missed?
23:49 <+AndrewPH> client crashed and buffer didn't save
23:50 < SinZ> on it
23:50 <+AndrewPH> thx
23:50 <+md_5> Grum no such thing as coincidences
23:50 <+AndrewPH> (missed basically the last 6 hours)
23:50 < barneygale> Any new protocol news?
23:51 < SinZ> http://pastebin.com/bgw6RprP
23:51 <+AndrewPH> aha
23:51 < Grum> md_5: yes there is, it was faster to remove the whole site than to figure out how the permissions were arranged, and as i said, not just that vanishes
23:52 < Grum> *vanished
23:52 < Grum> barneygale: you will have ... let me see, 5 packets with id 0
23:52 < barneygale> :o
23:53 < barneygale> ping variations?
23:53 < Grum> no
23:53 < Grum> all completely different packets
23:53 < barneygale> I was going to say :P
23:53 < Grum> 4 with id 1 ... 4 with 2
23:53 < barneygale> Hm... ID0 is a category or something? I don't follow.
23:53 < Grum> no, the id 0x00 ;D
23:54 < Grum> like you have the packet 0xFE etc now .....you will have 5 completely different packets with the id 0x00 ;)
23:54 < dexter0> heh
23:54 < Grum> oh maybe even 6
23:54 < barneygale> Well, I guess I don't understand heh. What does having ID 0x00 signify?
23:54 < barneygale> or: how are IDs assigned?
23:54 < Grum> that we named it 0x00 ;)
23:54 < Grum> by hand
23:54 < Grum> oh, protocol version will be reset!
23:55  * md_5 doesnt care as long as he can reset the clients entity id
23:55 < barneygale> Grum: brand new protocol so it makes sense to
23:55 < Grum> not 'completely' new but different enough that you cannot even connect without doing major changes
23:55 < barneygale> I am either too tired today or Grum is being a bit of a tease
23:55 < dexter0> this has to do with the variant stuff right?
23:55 < Grum> the game related packets will be mostly the same, they will just be renumbered
23:56 <+sadimusi> will there be some kind of documentation?
23:56 < barneygale> dexter0: that would make sense to me, e.g. variations on Player Position & Look all have a single ID
23:57 < barneygale> but I don't know if that's what Grum is talking about :P
23:57 < Grum> sadimusi: no, dont be silly
23:57 < Grum> barneygale: no, they will all have a different id
23:57 < dexter0> err, I had a typo.  But I just realized my previous statement is not applicable here.
23:57 < barneygale> Grum: is there any point me asking again for a clarification
23:57 < Grum> you can :P
23:57 < barneygale> I know I /can/
23:58 < barneygale> I just don't know if it's worth it anymore :(
23:58 < Grum> we're making a distinction between different 'protocols' and what direction the traffic is going
23:58 < Grum> so a packet can only be used in 1 direction 
23:58 < Grum> one of the 'protocols' will be 'logging in' or 'being ingame'
23:58 < barneygale> Ahh, I see
23:58 < Grum> those account already for 4 packets with 'id' 0
23:59 < barneygale> very interesting
--- Day changed ven. oct. 04 2013
00:00 < Grum> client->server we'll most likely be really strict
00:00 < Grum> in that you can at most send like 4kb of data per packet
00:00 < Grum> and we can nail it down per packet-type send
00:00 <+md_5> just add a way to reset the client entity id
00:00 < Grum> yes yes md_5, if we get aroudn to do it
00:00 < Grum> 1+9 should be merged
00:00 <+md_5> yay
00:00 <+md_5> \o/
00:00 < barneygale> :)
00:00  * md_5 crosses fingers before today/tomorrows snapshot
00:01 < Grum> we dont know what kind of retardo logic that sits behind it might prevent us from doing that change
00:01 < Grum> we have tons to fix tomorrow
00:01 < Grum> and not a lot of time
00:01 < Grum> there is a change we arent ready
00:01 < Grum> *chance; and a high one ;)
00:02 < barneygale> You still working Grum?
00:02 < Grum> we'll release what we have if it compiles and lets you login ;)
00:02 < Grum> barneygale: stopping now
00:02 < barneygale> slave-drivers at mojang eh
00:05 < Grum> barneygale: not really
00:07 < barneygale> Grum: I didn't really think so anyway, just being silly
00:31 < Not-003> [fCraft] fragmer * r2227 2 files : Fixed a startup crash caused by overly zealous null checks in Config's self-test.
00:32 < Not-003> [fCraft] fragmer * r2228 8 files : Last round of commenting/cleanup. Now, time to add some features.
00:42 < Not-003> [fCraft] fragmer * r2229 4 files : Replaced the ancient NBTag library with fNbt, for indev map loading.
00:57 < Not-003> [bravo] MostAwesomeDude pushed 1 commit to master [+0/-0/±1] http://git.io/LgUAfA
00:57 < Not-003> [bravo] Corbin Simpson 72c03c4 - chunk: Refactor dirtiness to fire a simple callback hook. Seems easy enough! Refs #366.
04:59 < Not-003> [MCPP] RobertLeahy pushed 4 commits to master [+2/-1/±4] http://git.io/FsjjAA
04:59 < Not-003> [MCPP] RobertLeahy 2965cce - Module Convenience Macro
04:59 < Not-003> [MCPP] RobertLeahy cda189e - Configuration Commands
04:59 < Not-003> [MCPP] RobertLeahy 3806eb0 - Maintenance Bugfix
04:59 < Not-003> [MCPP] RobertLeahy c2ea9c1 - Doxyfile
05:09 < Eviltechie> does the bot do anything besides commit messages?
05:09 < Eviltechie> It's starting to get on my nerves and I'll just /ignore it if that's all it does
05:10 < dx> lol
05:10 < dx> yeah that's all
05:10 < dx> feel free to ignore
09:31 < didomusicuk> morning everyone :)
14:30 < Not-003> [MCPP] RobertLeahy pushed 2 commits to master [+1/-1/±3] http://git.io/UYpeZg
14:30 < Not-003> [MCPP] RobertLeahy eb1a149 - Noise Overhaul
14:30 < Not-003> [MCPP] RobertLeahy 396c588 - Default World Generator - Rivers and More
14:33 < Not-003> [bravo] MostAwesomeDude pushed 3 commits to master [+0/-0/±11] http://git.io/BMecBg
14:33 < Not-003> [bravo] Corbin Simpson b328b44 - world: Add dirtiness tracking as an event to the chunk cache. For reasons I'm not quite sure about, this unbreaks two expected failures. Hm.
14:33 < Not-003> [bravo] Corbin Simpson 92ea0f3 - world: Fix up save_chunk() and make its callers less racy. Refs #366.
14:33 < Not-003> [bravo] Corbin Simpson a3cdae8 - world: Switch caching subsystem to separate caching object. And fix up a bunch of callers nearby. Maybe the ``_cache`` attribute shouldn't be private? Refs #366.
15:16 < Not-003> [bravo] MostAwesomeDude pushed 1 commit to master [+1/-0/±0] http://git.io/kL5C4w
15:16 < Not-003> [bravo] Corbin Simpson ea37144 - Add a mailmap.
18:37 < didomusicuk> hi all
18:37 <+pdelvo> hi
--- Day changed sam. oct. 05 2013
02:19 < Not-003> [bravo] MostAwesomeDude pushed 1 commit to master [+0/-0/±1] http://git.io/7NUhXw
02:19 < Not-003> [bravo] Corbin Simpson da74157 - world: As seasons change, apply the changed season to cached chunks. Fixes #366.
02:20 < SinZ> ooh, seasons
02:22 < dx> bravo always had seasons
02:22 < dx> as an alternative to biomes
02:23 < dx> interesting concept but when i used it i was always stuck in winter :(
03:44 < Not-003> [fNbt] fragmer pushed 1 commit to master [+0/-0/±13] http://git.io/4nwVcw
03:44 < Not-003> [fNbt] fragmer d4784f9 - Optimized the serialization process a tiny bit (eliminated 1 conditional and 1 parameter pass per saved tag).
11:47 < Not-003> [fNbt] fragmer pushed 1 commit to master [+0/-0/±3] http://git.io/eA9iJg
11:47 < Not-003> [fNbt] fragmer ba528a6 - Sped up reading/writing files with NbtFile. Fixed NbtFile.DefaultBufferSize defaulting to 0. Optimized writing string-heavy files.