00:23 <+Amaranth> Oh but that callback only happens once the packet is written out to the socket, right?
00:23 < Grum> and that is the code the future executes
00:23 < Grum> yes
00:23 < Grum> you *have* to do it that way
00:24 <+Amaranth> Right so that's the bug :D
00:24 < Grum> else because shit is async you can close the socket before writing disconnect
00:24 <+Amaranth> Someone tried to make things too generic here I think
00:24 < Grum> not really?
00:24 <+Amaranth> Grum: PM
00:24 < umby24> I know you don't support 3rd party stuff, but my client sends out in that order, and the server won't accept new updates
00:24 < Grum> that is the way you have to do things in netty :)
00:25 < umby24> it immediatly pushes back with a player position and look
05:43 < zontreck> Hello, I would like to know if anyone here could help me understand the packets for minecraft i want to make my own client. PM me if you can assist with this! I think the packet ID + parameters is what confuses me most. 
05:44 < nickelpro> zontreck: What protocol are you targeting? The latest protocol or 1.6?
05:44 < nickelpro> zontreck: Also, better to talk in channel where everyone can pitch in and help
05:44 < zontreck> The latest. I have not read it yet, but I suppose i should.
05:45 < nickelpro> zontreck: You can't be confused if you haven't even read the spec
05:45 < zontreck> I have read the 1.6 spec
05:45 < SinZ> 1.6 and 1.7 specs are almost completelly different
05:46 < dx> we don'te even keep links to the 1.6 spec other than the wiki revision history
05:46 < dx> >don'te
05:46 < zontreck> ok, yea, The protocol still includes a packet ID with the parameters. 
05:47 < zontreck> How do I do this?
05:47 < dx> zontreck: what language are you working with?
05:47 < nickelpro> Read packet id -> decode packet according to spec OR just throw it away since they're length prefixed
05:51 < zontreck> I am working with, C++ or Objective-C. 
05:52 < nickelpro> zontreck: What platform or networking lib are you targeting?
05:53 < dx> sounds like not targeting anything yet
05:53 < nickelpro> dx: Can send him to the relevant docs if I don't know what he's using for networking
05:53 < dexter0> if he's using ObjC it must be Mac or iOS.  Unless it's gnu step….
05:54 < zontreck> Mac and iOS likely. 
05:54 < dx> nickelpro: i mean he probably hasn't decided the networking lib yet
05:55 < dx> zontreck: okay, generic advice then, read and understand this page: http://wiki.vg/Data_types - after you do that, building a packet is a matter of concatenating data types
05:59 < zontreck> appending a raw string then?
06:00 < nickelpro> zontreck: Basically, packing and unpacking the types is a good starting point
06:01 < Fenhl> iirc, the ObjC data type for this would be NSData
06:05 < zontreck> got it! NSData is one i am familiar with, now, java, i assume is a byte[]?
06:07 < nickelpro> zontreck: Yes, a byte array
06:37 < Not-004> [fCraft] fragmer * r2294 18 files : Continuing the brush overhaul. IBrushFactory now provides "MakeDefault()", and IBrush provides "Clone()".
06:53 < Not-004> [fCraft] fragmer * r2295 6 files : Finished the brush subsystem overhaul. New Player methods: BrushSet(IBrushFactory) and BrushReset(). New Player property: BrushFactory, BrushDescription.
14:46 < ellisvlad> Drainedsoul: turns out I just derped when I was updating my code for 1.7 ... forgot to impliment UTF-8 :P
18:56 < Drainedsoul> ellisvlad: So where you just sending Latin-1/ASCII characters or something? :|
22:26 < Not-004> [fCraft] fragmer * r2296 24 files : Comment, formatting, and naming improvements. Also moved IBrushFactory out of IBrush.cs into a separate file.
23:33 < Not-004> [fCraft] fragmer * r2297 2 files : Fixed a regression/crash in NormalBrush. Fixed parameters in "/brush" not being read properly.
23:37 < Not-004> [fCraft] fragmer * r2298 2 files : Fixed "replaceNot" brush magically turning into "replace" brush.
23:38 < Not-004> [fCraft] fragmer * r2299 2 files : Fixed a regression in /Replace, /ReplaceNot, and /ReplaceBrush commands.
--- Day changed mar. déc. 03 2013
01:27 < shoghicp> md_5-: ping
01:28 <+md_5-> hi
01:29 < shoghicp> I'm asking you about RubberBand
01:29 < shoghicp> In PocketMine, we are developing a plugin to work like BungeeCord
01:29 < shoghicp> but they just found this: http://spoutcraft.org/threads/obsolete-elastic-portal-suite-the-future-of-inter-server-teleportation.4931/
01:30 < shoghicp> Is it ok to use the RubberBand name?
02:19 < humerusj> shoghicp: how about slingshot?
02:22 < shoghicp> hmm
02:23 < shoghicp> could work too
02:24 < shoghicp> I'll go with this for now on, since the other project is obsolete, and this is a plugin for a project
08:25 < Not-003> [fCraft] fragmer * r2300 2 files : Paste and pastenot brushes now align pasted contents by the first mark of a draw command. Not sure if this will be brushes' final behavior.
13:06 < TheUnnamedDude> How does the server notify the client to make the damage sound in 1.7?
13:11 < dav1d> Isn't there a packet?^^
16:50 < dav1d> pdelvo: ping!!!
17:04 < SinZ> pdelvo: pong!!!
--- Day changed mer. déc. 04 2013
00:09 < Not-003> [fNbt] fragmer pushed 2 commits to master [+0/-0/±18] http://git.io/N1N7FA
00:09 < Not-003> [fNbt] fragmer 3bb719b - Now using 'var' keyword when initializer explicitly declares type.
00:09 < Not-003> [fNbt] fragmer dd023ed - Improved NbtSerializer performance by caching reflection info
08:38 < Not-003> [fNbt] fragmer pushed 2 commits to master [+0/-0/±2] http://git.io/PyIFkQ
08:38 < Not-003> [fNbt] fragmer b5e9bfc - Another round of optimization in NbtSerializer.Serialize. Serializing "char" properties now produces NbtShort tags, and "decimal" properties now throw NotSupportedException.
08:38 < Not-003> [fNbt] fragmer 517938e - NbtSerializer.Deserialize() is now able to perform explicit numeric conversions, when possible and as needed.
09:09 < Not-003> [fNbt] fragmer pushed 2 commits to master [+1/-0/±3] http://git.io/PahZFw
09:09 < Not-003> [fNbt] fragmer 5088c00 - Added a couple basic unit tests for NbtSerializer -- more to come.
09:09 < Not-003> [fNbt] fragmer 49275f2 - Added support for serializing (although not yet de-serializing) any object or property that implements IList<T>. It gets mapped to NbtListTag of corresponding type.
16:55 < Thinkofdeath> For anyone who works on launchers/clients: http://wiki.vg/Game_Files#Assets the way the launcher stores assets as changed
17:19 < Dinnerbone> Virtual reconstruction will not happen for future versions of minecraft (1.7.3 and above)
17:19 < Dinnerbone> They will take in an index and the object list, and do the rest internally
17:19 < Dinnerbone> The launcher needs to reconstruct to stay compatible with versions that do not support this
17:20 < Dinnerbone> 'legacy' is the name of the asset index to use, and we will make new ones for categories of versions (alpha can have "ooph" sounds again, for example)
17:20 < Dinnerbone> If a version json has 'assets' defined, that's the index to use. Otherwise 'legacy' which is basically just everything we had until this change
17:21 < Thinkofdeath> ah i'll add that, thanks
17:21 < Dinnerbone> I hope custom launchers respect the required launcher number in the json
17:22 < Dinnerbone> So they can at least identify when we do changes like this and not crash because of it :(
17:26 < Thinkofdeath> I doubt any check that field, I don't think it has been documented anywhere
17:30 < Dinnerbone> Basically consider it the protocol version of the launcher world
17:30 < Dinnerbone> If it's 11 and you're expecting 10, something probably changed and you may not be able to run this version
17:43 < Thinkofdeath> Trying to look around at launchers and see if any check it, so far none do
17:53 < MrARM> Hi
17:54 < Thinkofdeath> Hey
17:54 < MrARM> I am first time here; trying to write as simple as possible MCPC Modern client
17:55 < MrARM> And my question is only: if something is a unsigned byte, can i just send a signed byte?
17:56 < Thinkofdeath> yes but negatives will become large positives
17:57 < MrARM> okay, so this isn't the problem
17:57 < MrARM> thanks
17:58 < MrARM> It soo bad that nobody wrote a 1.7.2 client library
18:00 < MrARM> anyway, bye, I hope I will get it finally to work (:
18:00 < barneygale> Packing an unsigned byte into a signed byte...
18:00 < barneygale> just why
18:02 < Thinkofdeath> No idea
18:13 < Paprikachu> because java doesn't have unsigned bytes.
18:14 < Thinkofdeath> But it does method to read/write them from ints
18:14 < Thinkofdeath> *does have methods
18:36 < SinZ> Dinnerbone: I'll pass that onto the Technic launcher people
20:14 <+SirCmpwn> what do custom launchers *do* when Mojang tells them the version number increased
20:14 <+SirCmpwn> tell the user "oh well, sorry you can't play Minecraft today"
20:14 <+SirCmpwn> or press on and hope it works?
20:17 < Dinnerbone> That's up to you. Either run it and explode, or not run it knowing that it probably won't run and say "sorry, we can't run this (vanilla can though), wait for the developer of this custom launcher to push out an update"
20:18 <+SirCmpwn> since in the past, version increments have been largely non-breaking, I'd make my launcher (if I had one) warn the user and the proceed as usual
20:18 < Dinnerbone> So you assume. I don't think I've upped it without breaking anything.
20:19 < Dinnerbone> The whole reason it's there is to tell users who are running an old launcher to restart because it can't run this json
20:19 <+SirCmpwn> well, non-breaking from my point of view
20:20 <+SirCmpwn> last change I remember was adding something (user UUID?) to the login response (which wasn't JSON at the time)
20:20 < Dinnerbone> Huh?
20:20 <+SirCmpwn> and I just split the string on the : and since the index of the important info didn't change, everything worked
20:20 < Dinnerbone> ... I don't know what you're talking about 
20:20 <+SirCmpwn> maybe I'm thinking too far into the past, though, all of that is way different now
20:20 < Dinnerbone> Login response? In the new launcher?
20:20 < Dinnerbone> That's always been json.
20:20 <+SirCmpwn> >new launcher
20:20 <+SirCmpwn> yeah, I'm talking about the old one
20:21 < Dinnerbone> Back when this version number didn't exist because that didn't use these version info files
20:21 < Dinnerbone> Yes, we upped it needlessly. Lots of times back then.
20:21 <+SirCmpwn> do you up it when you remove or change JSON schema, or when you add new things, too
20:21 < Dinnerbone> We even went from null to 0 once. That's an increase unexpressable by a percentage!
20:22 <+SirCmpwn> one might argue that null to zero isn't an increase, or a decrease for that matter
20:22 < Dinnerbone> Then one would have a very harsh lesson to learn when they treat it as such :p
20:23 < Dinnerbone> It's increased when we change json schema or the launch will require a new concept by the launcher (adding a new process argument, or library now needs archtypes to download)
20:23 <+SirCmpwn> sounds good
20:31 < x86123> for the 1.7.2 server list ping, how does one get the list of the players' names?
20:32 < x86123> some of the 1.7.2 servers i queried are not responding back with "sample" 
20:33 < Thinkofdeath> x86123: I don't think Bukkit supports the sample part of the ping
20:33 < Thinkofdeath> yet
20:33 < x86123> i see, thanks thinkofdeath 
20:36 < barneygale> x86123: that's limited to 12 players even on vanilla servers
20:36 < barneygale> only reliable way to get player list is through the gs4 query thing
20:40 < x86123> barneygale: dby any chance, would you have a code sample of how i should send the query? 
20:40 < barneygale> There's some example code on http://wiki.vg/Query
20:40 <+SirCmpwn> http://wiki.vg/Query#Example_implementations
20:40 < barneygale> At the bottom
20:41 < x86123> much appreicated
21:23 < Not-002> [Craft.Net] SirCmpwn pushed 2 commits to 1.7.x [+0/-0/±7] http://git.io/KrHLuQ
21:23 < Not-002> [Craft.Net] SirCmpwn 144b2aa - Disable most of Craft.Net.Client I need to focus on testing Craft.Net.Networking, so I'm disabling all but the basic parts of Craft.Net.Client so that I can get that done more easily.
21:23 < Not-002> [Craft.Net] SirCmpwn ba3293b - Update ServerPing to use 1.7.x server ping Looks like NetworkManager works great, after a few simple changes.
21:30 < Not-002> [Craft.Net] SirCmpwn pushed 1 commit to 1.7.x [+0/-0/±2] http://git.io/kHwaWA
21:30 < Not-002> [Craft.Net] SirCmpwn a8e21b1 - Fix issue with ServerStatus player sample
--- Day changed jeu. déc. 05 2013
03:49 < x86123> barneygale: about your python implementation of the gs4 query
03:50 < barneygale> yah
03:50 < barneygale> it's a bit shit in places, might want to look at Dinnerbon-e's
03:51 < x86123> barneygale: i presume the user does, query.get_packet()
03:51 < barneygale> check demo.py
03:51 < x86123> didn't notice that, much appreciated
04:15 < x86123> barneygale: is it possible to limit the data that query displays?
04:22 < barneygale> limit in what way?
04:23 < x86123> just not display the server vsoftware version and the plugins being used 
04:40 < x86123> barneygale: this peice of code, 'self.socket.recvfrom(2048)[0]', i assume that it reads 2048 from the network stream?
04:41 < barneygale> 2048 bytes yeah
04:42 < x86123> the python docs say that
04:43 < x86123> the recvfrom func returns,  (string, address), does the strign represent a byte representation (e.g '\x00\x00')?
04:46 < barneygale> it's like recvfrom() in any other language
04:47 < x86123> i see
04:48 < barneygale> and yeah, the string is a sequence of bytes
04:49 < barneygale> are you writing your own query client?
04:49 < x86123> i am trying to port it to php
04:50 < barneygale> there's a few PHP versions already
04:50 < barneygale> https://github.com/xPaw/PHP-Minecraft-Query
04:50 < x86123> i would like to implement my own just for the experience
04:51 < barneygale> fair enough
04:51 < barneygale> fair warning: minecraft isn't the best way to learn networking
04:52 < x86123> barneygale: as some one who wrote a c# minecraft client, i know 
04:52 < barneygale> oh right, I thought you were quite new
04:53 < barneygale> The docs at http://wiki.vg/Query are pretty good IMO
04:53 < barneygale> If you can figure out PHP UDP then it's not awful to implement
04:53 < x86123> i'm still getting used to the qwirks of it
04:55 < x86123> barneygale: much appreicate the help
04:55 < barneygale> no problem
04:56 < x86123> also going to try to implement a control panel via the rcon 
04:56 < barneygale> rcon is awful, I wouldn't bother
04:56 < barneygale> many commands won't return a response, or won't return the complete response
04:57 < x86123> the implementation is that bad?
04:57 < barneygale> it's OK if you're just sending commands and don't care about the response
04:57 < x86123> ah
04:58 < barneygale> It's not that the /rcon/ implementation is bad, it's just that many minecraft commands do things asynchronously
04:58 < barneygale> and rcon was just bolted on top of that without much thought
04:58 < x86123> i see
04:59 < barneygale> Query and Rcon were both added in 1.9 beta ("the version that never was"). At the time we speculated that notch was planning some deal with a game service provider, but it never materialised until Minecraft Realms came along, and that uses neither Query nor Rcon
04:59 < x86123> mminecraft realms? 
05:00 < barneygale> google it
05:00 < barneygale> I don't know much about it. It's basically server space you can buy from mojang
05:01 < x86123> ah, interesting..
05:03 < barneygale> notch has a very unique approach to programming and made a number of weird choices/errors, e.g. unsigned short in the middle of a list of null-terminated strings, or randomly printing "player_" before the player loop, when I think he was attempting to make the player list part of the (k, v) section in full stat
05:04 < barneygale> i.e. instead of "player_1\0barneygale\0player_2\0x86123\0" he wrote "player_\0\0barneygale\0x86123\0"
05:04 < barneygale> and randomly throws in a few other bytes for good measure
05:05 < x86123> i have one question, why the randomness? 
05:09 < barneygale> notch is a lazy programmer
05:10 < zml> there are non-lazy programmers?
05:10 < barneygale> he also tried to reverse the player list order for reasons unknown
05:10 < barneygale> even though it's in an arbitrary order anyway...
05:10 < barneygale> and did so by casting the list length to a byte then counting backwards
05:10 < barneygale> which meant about 127 players, you wouldn't get any sent due to an overflow
05:10 < barneygale> s/about/above
05:11 < barneygale> that's now fixed in 1.7 :)
05:12 < barneygale> sleep time o/
05:14 < cathode> wow all that protocol stuff sounds freaking awful
06:17 < Grum> < barneygale> notch has a very unique approach to programming  <-- that code (the 'gamespy query protocol') was donated by a gsp; not for a deal though
06:18 < Grum> also from what i understand it follows the rather crude gamespy protocol for that packet
07:09 < Not-002> [fNbt] fragmer pushed 2 commits to master [+1/-0/±3] http://git.io/94Rwlg
07:09 < Not-002> [fNbt] fragmer 0c6ef11 - Raised .NET framework requirement to 4.0
07:09 < Not-002> [fNbt] fragmer 0f4e00f - Added NbtSerializationGen (a work in progress), that can compile type-specific serialization methods on demand.
07:50 < Not-002> [fNbt] fragmer pushed 2 commits to master [+0/-0/±47] http://git.io/scYglQ
07:50 < Not-002> [fNbt] fragmer c2d677f - Tightened code formatting style
07:50 < Not-002> [fNbt] fragmer c4f0185 - Applied the formatting style changes to all the existing source files.
10:03 < Not-002> [fNbt] fragmer pushed 1 commit to master [+0/-0/±1] http://git.io/5Zbkag
10:03 < Not-002> [fNbt] fragmer 4c1a8e2 - First attempt at serializing IList's of primitive types in NbtSerializationGen
10:13 < Not-002> [fNbt] fragmer pushed 1 commit to master [+0/-0/±1] http://git.io/LdhGqA
10:13 < Not-002> [fNbt] fragmer 997e504 - Some fixes for SerializeIListOfPrimitives
18:23 < Thinkofdeath> http://wiki.vg/Pre-release_protocol#13w49a Just updated
19:10 < skarlitz> So, I understand that packets in MC1.7.2 are prefixed with the packet's length, correct?
19:14 < Thinkofdeath> skarlitz: Yep
19:15 < skarlitz> Okay, good... So this length is the number of bytes in the packet? Does this include the prefixed length as well? 
19:15 < [z]> See wiki link in topic.
19:21 < barneygale> Thinkofdeath: protocol version hasn't changed?
19:22 < barneygale> :/
19:22 < Thinkofdeath> Nope
19:22 < Thinkofdeath> The change just fixes a client bug
19:22 < barneygale> which bug is that?
19:23 < Thinkofdeath> "Fixed the SetSlot packet no longer being able to set the item under the cursor"
19:23 < skarlitz> The wiki doesn't specify if the packet's length includes the prefix that includes the length of the packet.
19:24 < Thinkofdeath> "Length	 VarInt	 Includes the packet id's length" 
19:25 < Thinkofdeath> Doesn't say anything about including the length of the packet therefore its safe to assume it doesn't
19:26 < skarlitz> Wait, I'm confused.
19:26 < skarlitz> Packet ID length or length of the packet? What do I send?
19:28 < skarlitz> Suppose I'm sending a Handshake packet. 
19:29 < Thinkofdeath> Length, ID, Data
19:29 < Thinkofdeath> Length = len(ID) + len(Data)
19:31 < skarlitz> Okay, that's exactly what I was asking, thanks. 
19:32 < skarlitz> And the length is the number of bytes, correct? 
19:33 < Thinkofdeath> yep
19:33 < skarlitz> Mkay, so how would I do that in Java? Like, say we have a string named "address". Would it be address.getBytes().length? It gives me an error when I attempt to do this. 
19:34 < skarlitz> I've searched some on the Internet for it but to no avail.
19:34 < Thinkofdeath> Can you pastebin/gist your code?
19:34 < skarlitz> Sure thing, give me a second. 
19:38 < skarlitz> Or a few minutes, I suppose.
19:44 < skarlitz> Nevermind. getBytes() doesn't work for all data types.
19:45 < skarlitz> Obviously as it's meant for strings... What about varInts?
19:47 < Thinkofdeath> Most handle it by writing the packet into a buffer 
19:47 < Thinkofdeath> Then write the length of the buffer followed by the contents of the buffer
19:48 < skarlitz> How does one get the length of a buffer? 
19:49 < skarlitz> size()?
19:49 < skarlitz> So it looks like, thanks for the advice.
19:54 < skarlitz_> Sorry. Got kicked. But anywho, here's a gist of what I have in mind. Would this work? https://gist.github.com/anonymous/6a2639f14554f14005a1
19:55 < skarlitz> Again, would that work? 
19:55 < skarlitz> https://gist.github.com/anonymous/6a2639f14554f14005a1
19:56 < SinZ> would error out
19:56 < skarlitz> (There isn't anything that's actually written to the out DataOutputStream, but this is a piece of concept code)
19:56 < skarlitz> Hm? Why?
19:57 < SinZ> echoSocket and out wont exist at line 11, because it was defined in the try{} statement, which might not succeed
19:57 < skarlitz> It was declared earlier in the code, silly.
19:57 < skarlitz> I just pasted a snippet.
20:00 < skarlitz> Just above that bit of code was the declaration of out, in, and the echoSocket.
20:00 < skarlitz> But anyways, would it work?
20:00 < barneygale> skarlitz: you need to write it as a varint
20:01 < barneygale> idk what .write() does
20:01 < barneygale> I assume it writes bytes
20:01 < barneygale> whereas out.size() is surely an int
20:01 < skarlitz> .write() can write an integer as a byte.
20:02 < barneygale> OK, but you want to pack a varint
20:02 < skarlitz> Hm?
20:02 < skarlitz> How do you write as a varInt?
20:03 < barneygale> https://developers.google.com/protocol-buffers/docs/encoding#varints
20:03 < barneygale> here's how I write packets (python): https://github.com/barneygale/authserver/blob/master/authserver.py#L268
20:05 < barneygale> That code also has packing/unpacking of varints further up, but only handles unsigned (as that's all I need for this project)
20:05 < barneygale> I think you need to handle signed varints, though I could be wrong
20:05 < Thinkofdeath> barneygale: Not anymore
20:05 < barneygale> Oh good
20:05 < Thinkofdeath> skarlitz: https://gist.github.com/thinkofdeath/e975ddee04e9c87faf22
20:06 < skarlitz> Oh yay, Java!
20:06 < skarlitz> Thank you :) 
20:06 < Thinkofdeath> Its taken from MC's code
20:06 < barneygale> skarlitz: what are you writing exactly? graphical client
20:06 < barneygale> ?
20:07 < skarlitz> A bot. 
20:07 < barneygale> consider using an existing protocol implementation
20:07 < skarlitz> Nah, I'd like to write my own. I'm using Darkbot for reference, however.
20:07 < barneygale> alright
20:07 < skarlitz> But Darkbot isn't 1.7.2 yet so I was stuck on the new protocol where you have to prefix packets with the packet lenght
20:08 < skarlitz> length*
20:08 < barneygale> if you're new to java networking / data structures, minecraft is a bad choice for learning.
20:08 < barneygale> That should really be in the topic heh
20:09 < Thinkofdeath> Pretty sure its on the wiki :)
20:09 < skarlitz> I can learn as I go along. :P 
20:10 < skarlitz> Is it normal that https://gist.github.com/thinkofdeath/e975ddee04e9c87faf22 's readVarInt() method takes no parameters? 
20:10 < skarlitz> I mean, there's no better way of learning that actually doing it. 
20:10 < Thinkofdeath> skarlitz: yes
20:10 < barneygale> skarlitz: it uses readByte() to read a byte from the buffer
20:10 < barneygale> that's your input
20:10 < skarlitz> Got it
20:11 < skarlitz> I have to go, thank you for your help!
20:11 < barneygale> another person who will surely give up in a few days time when he realises minecraft is stupid
20:12 < mathuin> Awww, it took me several weeks before I got frustrated enough to take a break. :-)
20:12 < Thinkofdeath> Or be back asking for help every other day
20:14 < barneygale> "I mean, there's no better way of learning that actually doing it." hmm when it comes to networking it helps to learn some theory at the same time
22:52 < nickelpro> Current protocol, packet 0x23 Block Change, the "Block Data" field is block metadata right?
22:52 < Thinkofdeath> nickelpro: Yep
22:52 < nickelpro> Thinkofdeath: Thanks "Block Data" is a little ambiguous
22:53 < Thinkofdeath> Feel free to rename it to match everything else
22:53 < nickelpro> will do
23:16 < ellisvlad_> Can't remember the right place to post about MC glitches, but http://puu.sh/5DhxA.jpg :P
23:17 < shoghicp> Nodus detected :s
23:17 < nickelpro> ellisvlad_: Not glitch, adorable feature
23:17 < shoghicp> sadimusi: ^
23:18 < SinZ> I cant see the glitch behind all the modifications
23:21 < mathuin> The dude in the foreground is so hot he's on fire?
23:32 < ellisvlad_> lol the glitch is that particle effects render behind water :P
23:33 < ellisvlad_> I'm using nodus so I can block all it's features on the server I am making
23:33 < ellisvlad_> lol
23:33 < shoghicp> ¬¬
23:35 < skarlitz> Speaking of glitches, I've found a lot of graphical ones in Minecraft 1.7.2.
23:35 < shoghicp> They are funnier on MCPE
23:36 < shoghicp> We got some weird bugs on the beta builds
23:36 < shoghicp> everything had textures and structure messed up
23:42 < skarlitz> By the way, Thinkofdeath, thanks for that code snippet. I used it to make an extended DataOutputStream class. 
23:42 < skarlitz> Which can write VarInts
23:42 < Thinkofdeath> np :)
23:47 < skarlitz> So, remember how you said to use a buffer to measure the amount of bytes? Would there be two separate buffers? One for networking and the other for the packet that's being measured? 
23:48 < skarlitz> Because if I were to measure the size in bytes of the current buffer (Which already has data in it), how can I write the prefix containing the length of the rest of the packet BEFORE the data? 
23:48 < Not-002> [fNbt] fragmer pushed 1 commit to master [+0/-0/±1] http://git.io/Um7TOg
23:48 < Not-002> [fNbt] fragmer 52e7cd4 - Fixed serialization of arrays other than byte[]/int[], and serialization of anything that implements IList<> of primitive types.
--- Day changed ven. déc. 06 2013
00:17 < nickelpro> skarlitz: Yes
00:17 < nickelpro> skarlitz: Build packet in a buffer, then write the packet size followed by the packet itself to your send buffer
00:18 < skarlitz> Alrighty, thanksh.
02:13 < skarlitz> Can someone direct me as to how to cause the Minecraft server to log packets again?
02:13 < skarlitz> Nevermind, found it.
02:14 < skarlitz> Been testing this. http://pastebin.com/U8N8Pnx2
02:14 < skarlitz> Ca
02:17 < skarlitz> And it doesn't seem to send anything. :\
02:18 < skarlitz> I've been trying to send packets to the server at the very least but it doesn't appear to do so at all.
02:25 <+SirCmpwn> skarlitz: it seems that you don't know very much about networking in general
02:26 <+SirCmpwn> you should be able to easily overcome the problem you presently face and you may not be prepared to write a Minecraft client with your level of experience
02:28 < skarlitz> You learn by doing. 
02:28 < skarlitz> And I'm going to do it. It's a task of figuring it out.
02:28 <+SirCmpwn> in that case, I'd ask you not to waste our time with basic networking questions
02:29 <+SirCmpwn> minecraft is a terrible place to learn networking from, too
02:30 <+clonejo> SirCmpwn: nobody said he'll be only looking at Minecraft's networking in the next years
02:30  * SirCmpwn shrugs
02:30 <+SirCmpwn> if someone else wants to help him out, feel free
02:30 <+clonejo> xD
02:30 <+SpaceManiac> skarlitz: could be you're closing the socket before anything actually happens
02:31 <+SirCmpwn> if you're opening, writing to, and closing your socket all in the same function, you're probably on the wrong track
02:31 < skarlitz> SpaceManiac: Could be, tried adding a sleep at the end, still nothing. 
02:32 < skarlitz> At the end of the flush, at leats.
02:32 < skarlitz> Least* 
02:32 < skarlitz> I'm opening and writing to it and then closing it because I'm only trying to send a single packet. 
02:32 <+SirCmpwn> do you have to flush the ExtendedDataOutputStream or the underlying BufferedOutputStream
02:34 < skarlitz> Hmm...
02:36 < skarlitz> I never claimed to have experience in this, it's my first crack at it. True enough it might be a horrible place to learn it but it is a challenging one at that. I was told to start small, so I did, working on writing a single packet to the server.
02:36 <+SirCmpwn> I think "start small" means to impress upon you that a Minecraft client is, in general, not "small"
02:37 < nickelpro> Does the server even log handshakes?
02:37 <+SirCmpwn> I'm curious to learn how you figured out how to make the server log packets, actually
02:37 < nickelpro> SirCmpwn: I think I'm responsible
02:38 < skarlitz> Debugging at the wiki
02:39 <+SirCmpwn> would you look at that
02:39 <+SirCmpwn> that's pretty neat
02:39 < skarlitz> Well if I sit around writing ping-pong apps in Java I won't get very far. 
02:39 < nickelpro> In other news, loading chunks into my Map module was too slow to do in sync, so I threw it into a thread. Now I have a half dozen new problems from race condition :-\
02:39 <+SirCmpwn> write an IRC client, that's what I suggest to people who are new to networking
02:40 <+SirCmpwn> an IRC bouncer if you're feeling frisky
02:40 < nickelpro> I learned on an HTTP server
02:40 <+SirCmpwn> I'll abstain from comments about java, though
02:40 <+SpaceManiac> I don't even remember
02:40 < nickelpro> Anything with a well specified protocol will do
02:40 < nickelpro> Preferably an RFC
02:41 < nickelpro> SirCmpwn: My first though looking at his pastebin was "Java, well there's your problem"
02:41 <+SirCmpwn> hee hee
02:42 <+SpaceManiac> there's stuff like NIO and Netty that make Java networking less painful
02:43 < nickelpro> I've done networking in Java, it's not particularly hard compared to other languages. I just never enjoyed the syntax or style of java, the language feels like it was designed only for IDEs
02:43 < skarlitz> I can't figure out Netty. 
02:43 < skarlitz> I find Java's built in bit simpler than Netty, in my honest opinion.
02:44 < skarlitz> Simpler to use, I mean. 
02:46 < skarlitz> Not even sure if the server logs handshakes, hm. 
02:47 <+SirCmpwn> finish up the handshake and do a status ping
02:47 <+SirCmpwn> if the server gives you something back you did it right
02:48 < skarlitz> Alrighty.
02:48 < skarlitz> I don't think I need to worry about setting it to offline mode either since I believe it disables encryption for localhost clients
03:04 < nickelpro> skarlitz: online in offline mode
03:04 < nickelpro> only*
03:04 < nickelpro> derp
03:04 < nickelpro> lets try that again
03:05 < nickelpro> skarlitz: only in offline mode
03:05 < skarlitz> So now I'm getting an EOF exception with my VarInt reader. 
03:06 < skarlitz> Hm
03:09 < skarlitz> Actually, it does log handshake packets.
03:11 < skarlitz> So, it basically doesn't even get the handshake packet. It gets the connection, but not the handshake
03:14 < skarlitz> http://pastebin.com/HVwJ0skb
08:16 < Not-002> [fNbt] fragmer pushed 1 commit to master [+0/-0/±1] http://git.io/AyW3xg
08:16 < Not-002> [fNbt] fragmer 3deef43 - Fixed a few edge cases related to serializing IList<T> in NbtSerializationGen
--- Log closed ven. déc. 06 09:29:51 2013
--- Log opened ven. déc. 06 09:30:00 2013
09:30 -!- Irssi: #mcdevs: Total of 142 nicks [1 ops, 0 halfops, 12 voices, 129 normal]
09:33 -!- Irssi: Join to #mcdevs was synced in 217 secs
16:51 < l4mRh4X0r> Hey, on the "Object Data" wiki page, it's mentioning an int field. Is that the "type" field of the "Spawn Object" packet, or is that a separate field inside the "Object Data" field?
16:53 < Thinkofdeath> Seperate field
16:53 < Thinkofdeath> https://github.com/NetherrackDev/netherrack/blob/master/protocol/packets_server.go#L121
16:54 < l4mRh4X0r> Ah, thanks :)
17:03 < l4mRh4X0r> That doesn't make sense at all though
17:04 < l4mRh4X0r> So if an empty minecart gets spawned, the speed *isn't* sent, but if a different type minecart gets spawned, the speed *is* sent?
17:05 < l4mRh4X0r> Not in the same packet, at least
17:06 < l4mRh4X0r> Thinkofdeath, ^?
17:06 < Thinkofdeath> By the looks of it, that would be correct
17:07 < l4mRh4X0r> Heh, that's just stupid. But this *is* Mojang we're talking about, so...
17:07 < l4mRh4X0r> No offense btw
17:08 < shoghicp> Minecraft protocol was always like that...
17:13 < l4mRh4X0r> Yeah, but you'd think that would be improved if the protocol was rewritten, right?
17:16 < shoghicp> they fixed it a bit on 1.7
17:16 < shoghicp> It seems that they prefis the packet length
17:16 < shoghicp> before you had to forcefully parse everything
17:16 < shoghicp> or you would have been out of sync
17:16 < l4mRh4X0r> I know
17:17 < shoghicp> I haven't looked at the MC PC protocol for a long time
17:17 < shoghicp> I'm working with the MCPE protocol
17:17 < l4mRh4X0r> Ah. Must be interesting as well, I suppose
17:17 < shoghicp> I even found some bugs caused by the compiler there :D
17:17 < shoghicp> yep
17:17 < shoghicp> they use UDP
17:18 < l4mRh4X0r> Yeah, I've read small bits about the protocol on the wiki
17:18 < shoghicp> and chunks are sent uncompressed o.O
17:18 < SinZ> wat
17:18 < l4mRh4X0r> They use raknet, don't they?
17:18 < shoghicp> yes, then, a mc pc-alike layer
17:18 < shoghicp> oh, I should update it on the wiki
17:18 < shoghicp> I update p.wiki.vg as soon as I can
17:19 < shoghicp> but i always forgot about the wiki
17:19 < shoghicp> SinZ: yes
17:19 < shoghicp> I talked with Johan and he said that would change in future releases
17:19 < SinZ> how does that even
17:19 < shoghicp> but for now, I've to send 23MB per player spawned
17:19 < SinZ> An unsafe binary stream, with uncompressed chunks
17:19 < shoghicp> Hopefully, maps are limited
17:20 < shoghicp> There is a packet recovery system in place
17:20 < shoghicp> by RakNet
17:20 < shoghicp> also, they only send the parts changed from the seed
17:20 < shoghicp> in PocketMine-MP, I can't do that
17:21 < shoghicp> or they can't do that with modified maps
17:21 < shoghicp> SO it is funny to see everything on Wireshark
17:43 < SinZ> does that mean, for a void map, you need to send a lot of info
17:50 < shoghicp> yes
17:50 < shoghicp> SinZ: full of null bytes
17:51 < shoghicp> of corse, I don't store them. I made a conversor for the MCPE map format and moved on
17:51 < shoghicp> course*
17:51 < shoghicp> but MCPE maps are 23MB each
17:51 < shoghicp> also, not compressed
19:48 < Not-002> [mineflayer] zuazo pushed 2 commits to master [+0/-0/±2] http://git.io/keAjYA
19:48 < Not-002> [mineflayer] zuazo 0c6895b - fixed non-JSON chat message parsing (related with issue #163)
19:48 < Not-002> [mineflayer] zuazo 4daa1f8 - Merge branch 'master' of github.com:superjoe30/mineflayer
20:05 < nickelpro> Who do I talk to about getting Not-002 to monitor my repo?
20:06 < Thinkofdeath> nickelpro: http://n.tkte.ch/
20:14 < nickelpro> Thinkofdeath: Thanks!
20:23 < SinZ> Thinkofdeath: registrations are closed though
20:23 < Thinkofdeath> Oh I don't know that, sorry nickelpro 
20:25 < Thinkofdeath> *didn't
20:25 < nickelpro> SinZ: worked for me
20:27 < SinZ> Oh, TkTech reopened it
20:27 < SinZ> ignore me
20:27 < nickelpro> will do
20:28 < nickelpro> Mineflayer has "rainfall" in its biomes enum along with temperature, anyone have any idea what it's refering to? https://github.com/superjoe30/mineflayer/blob/master/lib/enums/biomes.json
20:29 < nickelpro> I can't find mention of a distinct rainfall value in any other documentation
20:30 < [z]> I think it's called humidity elsewhere
20:30 < [z]> But as far as I know those values have basically been meaningless for a long time
20:31 < nickelpro> [z]: That's what I was looking for, thanks
20:40 < SinZ> temperature is used in 1.7, for more natual biome placement
20:40 < SinZ> and rainfall could refer to biomes that can rain, and biomes that cant rain (i.e. desert, snow)
20:40 < [z]> Is it though
20:40 < SinZ> iunno, I don't use mineflayer
20:41 < [z]> So why say it is when it's really just a guess...
20:41 < SinZ> temperature is used in vannila for better biome placement
20:42 < [z]> It used to be, way back before biomes were saved along with the world... Temperature and humidity varied smoothly and the biome was determined based on ranges from that
20:43 < [z]> After they changed to discrete biomes saved with the world, and biome placement became totally random, I think the temp/humidity were just hardcoded in each biome
20:44 < [z]> The values may mean more now, may not...
20:45 < nickelpro> [z]: Yep, but temperature still determines/can be used to determine the precipitation ina biome. Humidity doesn't seem to be relevant at all
21:27 < mathuin> The technical definition for different terrestrial biomes in biology class focuses on temperature (often strongly influenced by latitude and elevation) and humidity.
21:27 < mathuin> It would be v. nice if Minecraft biomes worked that way too.
21:27 < mathuin> Does anyone know for sure?
21:27 < [z]> They did before
21:29 < [z]> http://minecraft.gamepedia.com/File:BiomesGraph.png
--- Day changed sam. déc. 07 2013
03:16 < cathode> the problem is, 'latitude' is not part of minecraft
03:16 < cathode> because the world expands in both x and z indefinitely (for all practical purposes)
07:26 < umby24> http://pastebin.com/g9wsx7qn can anyone see why the server continues to try and fix my location here?
19:02 < hats> hello, I have a question about the chat packet in 1.7.2
19:02 < hats> I am making a bot, and right now it can connect to online-mode servers and display chat
19:02 < hats> I'm trying to make it reply to chat, but nothing happens when I do
19:03 < hats> this is what I'm sending: http://pastebin.com/tcmrPJqW
19:08 < Thinkofdeath> hats: The client doesn't send json
19:08 < Thinkofdeath> only the server
19:09 < hats> aah
19:11 < hats> so I should send a string with a packet id of 2?
19:13 < Thinkofdeath> hats: yes (under 119 chars)
19:13 < hats> alright, thanks
19:36 < Drainedsoul> Thinkofdeath: Why 119 chars?  Is that just a server-imposed limitation?
20:23 < Thinkofdeath> Drainedsoul: yes
20:32 < austin> Hello
20:46 < austin> Are you familiar with the TeleportSigns w/ BungeeCoord?
20:46 < austin> I need a custom join signs plug-in like that one, but with two lines on the sign changed
20:46 < austin> It's not that big of a project but I'll offer a developer position on the network I'm launching
22:31 < Not-002> [fCraft] fragmer * r2301 23 files : Renamed Color to ChatColor. Let there be merge conflicts!
22:39 < Not-002> [fCraft] fragmer * r2302 22 files : Moved IsoCat and DrawImage code to fCraft.dll -- which now requires System.Drawing. This means Mono users *must* have libgdiplus installed to run fCraft 0.900+
22:41 < Not-002> [fCraft] fragmer * r2303 2 files : Got rid of LoadGDIPlus config key, since it is now always needed.
22:52 < barneygale> Can someone explain the "blocks won't have IDs" thing to me? how will world saving/loading work between minecraft versions?
22:52 < barneygale> I guess chunks would need store a palette of sorts
22:53 < dexter0> where is this from?
22:53 < dexter0> The Mod API plans?
22:55 < barneygale> Reading it on minecraftwiki's "version history" page http://minecraft.gamepedia.com/Version_history
22:55 < barneygale> Plus I've seen it mentioned on r/minecraft and in this channel
22:56 < barneygale> Can now be referred to by their names instead of numbers. Will be the only option in the future. Necessary for the Plugin API.
23:00 < nickelpro> wait? What will be stored in the map saves?
23:00 < nickelpro> Just names?
23:00 < nickelpro> strings?
23:00 < dexter0> iirc the map format has not changed yet
23:01 < nickelpro> Oh so this is just for the API
23:01 < dexter0> well, it will have to change
23:01 < dexter0> b/c Gru_m wants to get rid of block IDs externally 
23:01 < nickelpro> So what's going to change from a protocol/file format POV?
23:02 < nickelpro> "externally"?
23:02 < dexter0> block IDs would still be used internally but before saving the map they would be converted into something more universal, like a string identifier.
23:02 < dexter0> that's what I recall
23:03 < dexter0> B/C using block IDs would not work in a world where any mod can register a new block.
23:06 < nickelpro> Sending strings for map updates over the network would be pretty terrible, so mod-registered-blocks will still need to be given IDs internally too. Guess they will just be assigned at runtime?
23:06 < dexter0> your guess is as good (or probably better than) mine.
23:34 < SinZ> afaik, ID's are mapped per world-save, but in all the code, it is referred by string
23:34 < SinZ> but they might change the world format to suit this
23:55 < nickelpro> SinZ: That makes sense, in net code maybe we get an opening map of strings -> ids before chunks are sent?
23:56 < SinZ> forge might be doing that already when they do a 1.7 release
--- Day changed dim. déc. 08 2013
08:33 < Not-002> [Craft.Net] SirCmpwn pushed 8 commits to 1.7.x [+1/-0/±18] http://git.io/ogHzSg
08:33 < Not-002> [Craft.Net] SirCmpwn 55e0760 - Re-enable the rest of Craft.Net.Client
08:33 < Not-002> [Craft.Net] SirCmpwn cadaf99 - Update MinecraftClient.cs to new networking model
08:33 < Not-002> [Craft.Net] SirCmpwn d35c638 - Resolve Craft.Net.Client build errors
08:33 < Not-002> [Craft.Net] SirCmpwn e1b6efb - Update TestClient
08:33 < Not-002> [Craft.Net] SirCmpwn b7b3d6d - Bring SMProxy packet log into C.N.Networking
08:33 < Not-002> [Craft.Net] SirCmpwn 5d3b2ca - Modify log to return string instead of write stream
08:33 < Not-002> [Craft.Net] SirCmpwn acd6479 - Modify how IDs are assigned to packets
08:33 < Not-002> [Craft.Net] SirCmpwn dede5f9 - Missed a packet in Play mode
09:31 < Not-002> [Craft.Net] SirCmpwn pushed 1 commit to 1.7.x [+0/-0/±9] http://git.io/cnBpsw
09:31 < Not-002> [Craft.Net] SirCmpwn 63b0011 - Standardize stance use with new networking API
09:31 <+SirCmpwn> if anyone here would like an update on Craft.Net, the networking core is finished and working, and the client is working for the most part, but I can't get it to move
09:32 <+SirCmpwn> going to update the server in the near future and merge in 1.7 support
09:35 <+SirCmpwn> I went the "no packet IDs" route and removed all hardcoded packet IDs, by the way
09:35 <+SirCmpwn> I'm a bit worried about performance but it seems to be fine
09:43 <+ammar2> o boy
09:47 <+SirCmpwn> well, the packet IDs are determined on startup
09:48 <+SirCmpwn> so the runtime performance isn't too badly affected
09:48 <+SirCmpwn> I just have to resolve the ID before I can send a packet
09:48 < Drainedsoul> what is the advantage to that?
09:48 <+SirCmpwn> more maintainable
09:49 <+SirCmpwn> mojang's probably going to be switching up packet IDs like mad with every update
09:49 < Drainedsoul> how, you still have to specify an ID somewhere
09:49 <+SirCmpwn> because I'm specifying them in the order they appear, not by declaring their ID
09:49 <+SirCmpwn> I can insert new packets wherever without any pain
09:49 <+SirCmpwn> and I can probably improve write performance enough so that it's not a problem with some tweaking
09:49 < Drainedsoul> so what happens when Mojang has non-contiguous packet IDs
09:50 <+SirCmpwn> I can insert a null wherever I please
09:50 <+SirCmpwn> but it looks like Mojang will have continuous packet IDs for the foreseeable future
09:50 <+SirCmpwn> https://github.com/SirCmpwn/Craft.Net/blob/1.7.x/source/Craft.Net.Networking/NetworkManager.cs
09:51 <+SirCmpwn> read performance is unaffected, but write performance is affected, and I can see a potential optimization that would make that not a problem
09:51 <+SirCmpwn> packet handler dispatch went from O(1) to O(log n)
09:52 < Drainedsoul> why
09:52 <+SirCmpwn> instead of looking up packet handlers by their ID I have to look them up by their type
09:52 < Drainedsoul> don't hash tables exist
09:52 <+SirCmpwn> also has an opportunity for improvement along a similar line of thought as packet writing
09:52 <+SirCmpwn> yes, hash tables are O(log n)
09:52 < Drainedsoul> lol wat
09:53 <+SirCmpwn> err, hash tables are O(n)
09:53 <+SirCmpwn> but I'm using a sorted hash table
09:53 < Drainedsoul> you need to get new hash tables
09:53 <+SirCmpwn> so O(log n)
09:53 < Drainedsoul> if it's sorted it's not a hash table
09:53 <+SirCmpwn> bleh, a whatever-you-call-it
09:54 <+SirCmpwn> in any case, I'll probably optimize it back down towards a similar level of performance it had before 1.7
09:54 <+SirCmpwn> but only after I finish the rest of 1.7 support
09:55 < Drainedsoul> I don't see why you wouldn't use a data structure that has O(1) lookup time in the first place
09:55 < Drainedsoul> i.e. a hash table/map
09:55 <+SirCmpwn> hash tables aren't O(1)
09:55 < Drainedsoul> how
09:55 <+SirCmpwn> aren't they O(n)?
09:56 <+SirCmpwn> oh, I guess not
09:56 < Drainedsoul> in the worst case, which doesn't happen unless your inputs are specially constructed or your hash function is bad
09:56 <+SirCmpwn> I'm using standard types, let me look up what's behind them
09:57 <+SirCmpwn> oh, it's just a plain old hash table
09:57 <+SirCmpwn> alright then
09:57 <+SirCmpwn> well, handler dispatch has the same performance as before, then
09:57 < DavidEGrayson> In my Ruby minecraft bot, all packet handlers were notified about all packets and it was their job to decide if they cared or not.  I liked the simplicity yet and haven't needed to change it yet.
09:57 <+SirCmpwn> packet writing does not, but that can still be addressed
09:58 < Drainedsoul> DavidEGrayson: So your minecraft bot wasted a lot of time?
09:58 < DavidEGrayson> Nope, it was always running at like 1% or 2% CPU.
09:58 < Drainedsoul> which means nothing
09:59 <+SirCmpwn> ^
09:59 < DavidEGrayson> It means I didn't need to worry about optimizing the code yet.
09:59 <+SirCmpwn> haha, good point
09:59 <+SirCmpwn> that's an easy opportunity for improvement, though, I wouldn't've done it that way in the first place
09:59 < DavidEGrayson> I figured that the Ruby interpreter was probably good at calling a couple dozen methods and doing some if statement in each of them.
10:00 < Drainedsoul> so you were expecting the interpreter to subsidize your shoddy engineering
10:02 < DavidEGrayson> I think you're missing the point of higher-level languages.  There is tons of waste everywhere, but at least it doesn't waste the developer's time.
10:02 < umby24> and when running interpreted languages such as ruby you're going to need all the preformance you can get
10:02 < Drainedsoul> The point of higher-level languages isn't to actively abuse the computer, the point of higher-level languages is to automate certain tasks that you don't need 100% control of, at the loss of some performance
10:03 < Drainedsoul> it isn't to take operations that are logically O ( 1 ) and blithely move them into the O ( n ) or higher domain because you're too lazy to properly design something
10:03 <+SirCmpwn> optimizations at the algorithmic level are still important in higher level languages
10:03 <+SirCmpwn> I got WAY better performance when I refactored Craft.Net.Anvil to use a different kind of block lookup
10:03 <+SirCmpwn> something like an order of magnitude, everything was much snappier
10:04 <+SirCmpwn> you run a client and I run a server, though, so our performance needs are much different
10:05 < DavidEGrayson> Handling block/chunk data is a pretty intense operation so yeah, you need to think about optimizing that stuff.  I would love to just have a ruby object for every loaded block in the minecraft map but I can't.
10:06 < DavidEGrayson> About packet handling: O(N) is not scary to me when N is a few dozen and I personally wrote every one of the N.
10:06 <+SirCmpwn> on the big-O scale, it's not so bad
10:06 <+SirCmpwn> but you're doing a function call and a compare for every iteration of that O(n)
10:06 <+SirCmpwn> I mean, it's not a huge deal
10:07 <+SirCmpwn> but it's an easy thing to not screw up
10:07 <+SirCmpwn> probably would be easier to write the code the right way, too
10:07 < Drainedsoul> ^
10:08 <+AndrewPH> DavidEGrayson: I hope mojang implements 10 million packets just so your script will be slower than it should be
10:09 < DavidEGrayson> lol
12:23 < MrARM> hello
12:24 < MrARM> had anyone anywhere succeed in making a 1.7.2 client? 
12:25 < MrARM> because JDGUI made a reference to something undefined and I don't know what I should do now
12:25 < shoghicp> MrARM: oh, are you MrARM from PocketMine Forums?
12:26 < MrARM> yeah
12:26 < shoghicp> :D
12:27 < shoghicp> https://github.com/nickelpro/spock
12:27 < MrARM> I can't read python, I don't get the code in it
12:27 < MrARM> along with visual basic
12:28 < MrARM> I'll try a different decompiler maybe
12:28 < shoghicp> then, everything else in the Client list seems outdated
12:29 < MrARM> I'll see, maybe there is a translator from python to something other
12:29 < shoghicp> Or just learn a bit of python ;)
12:30 < MrARM> generally I couldn't find the main file of that project...
12:30 < MrARM> I really need those (); {}
12:30 < shoghicp> or you could implement your own protocol lib
12:31 < MrARM> I an trying to, but JDGUI made me stuck in a point,  as it said "this.a.a.b ()"
12:31 < MrARM> but there is no this.a!
12:32 < MrARM> I'll try fernflower decompiler now
12:41 < MrARM> ok, fernflower saw the entry
12:55 < MrARM> so this part is done (: working with obfuscated mine craft source code is very hard
13:01 < shoghicp> MrARM: it is... obfuscated
13:02 < MrARM> yeah, so it isn't source code
13:03 < MrARM> I am trying to recive data from Netty now, not sure how to (too bad that they changed protocol)
13:03 < Flemmard> too bad ?
13:06 < MrARM> yeah, old protocol was much simpler
13:06 < Not-002> [mcdevs/BenchCraft] TRocket pushed 1 commit to master [+0/-0/±1] http://git.io/xbkidQ
13:06 < Not-002> [mcdevs/BenchCraft] TRocket dbb663f - Update Main.java starting to comment stuff... will add javadoc soon
13:07 < Flemmard> it was absolutely bad also
13:09 < MrARM> you are right too, packets size were undefinited
13:09 < Flemmard> yes
13:10 < MrARM> however, now, there is almost no documentation on the new protocol
13:11 < MrARM> I am not sure are the information correct
13:11 < MrARM> (on viki.wg)
13:12 < MrARM> there is no "how to write a client" thing,  so I don't know which packet to send
13:12 < MrARM> by browsing MC source code the pinging code were:
13:13 < TRocket> http://wiki.vg/Protocol_FAQ says what packets should be sent by the client?
13:13 < MrARM> (byte) 254, (byte) 1, (byte) 250
13:13 < MrARM> nope, not for 1.7.2
13:15 < TRocket> oh :( i'm currently trying to write a java client for BenchCraft... i guess i'll just try what it says and we can try and update the wiki...
13:15 < MrARM> my first attempt was to send 0x00 but the EOF was thrown just after sending
13:16 < TRocket> have you tried using wireshark and comparing what your client sends vs what vanilla client sends...
13:16 < MrARM> heh, no, I'll try maybe, but I'll have to install WireShark
13:17 < TRocket> It helped me a lot when writing stuff and I found the boost::asio was sending random extra bytes
13:18 < MrARM> so I'll comment out the Netty using and go back to my old packet sending
13:19 < TRocket> i'll have a go using netty and see if i can get something to work
13:20 < MrARM> I think I just made reviving packet wrong here
13:22 < MrARM> *retrieving
13:23 < shoghicp> encryption?
13:23 < MrARM> MCP could be out, it would be much simpler
13:24 < MrARM> shoghicp if encryption is online mode then nope.  Disabled. 
13:24 < TRocket> if i can successfully make a client with netty, and scripts to generate it from burger, i might put it as a repo on github/mcdevs...
13:26 < MrARM> anyway it looks like I were implementing pinging server,  not the real thing
13:28 < MrARM> Mojang could make a client library
13:29 < Flemmard> could
13:29 < Flemmard> but probably wont
13:29 < Flemmard> :)
13:30 < MrARM> just a simple, small library
13:30 < MrARM> I don't get why they obfuscate minecraft
13:32 < Dinnerbone> Specifically so that you can't reuse our client
13:32 < Flemmard> why do companies put some protections on their software ?
13:33 < Flemmard> that's a legit question. why would one protect it's work ..
13:34 < SomeoneWeird> because that's how they make money?
13:34 < Flemmard> (that was irony btw)
13:35 < Dinnerbone> No, it was sarcasm :p
13:35 < Flemmard> yeah sarcasm
13:35 < Flemmard> sorry
13:35 < Flemmard> :>
13:39 < MrARM> Dinnerbone but there is MCP
13:40 < Dinnerbone> Yes, MCP is a 100% pure representation of our code and you can completely understand, easily work with and use all of it.
13:41 < MrARM> yeah, but what I know java strips vars name in functions already
13:41 < MrARM> *from what
13:41 < Dinnerbone> And none of MCP is like vanilla source. It's obfuscated. It's stripped. It's made confusing, all names removed, all methods jiggled and poked.
13:42 < MrARM> yes, I know, in MCP some names are strange
13:43 < Flemmard> *some*
13:43 < Dinnerbone> Yeah, all the names.
13:43 < MrARM> not all, some are named logically
13:43 < Dinnerbone> No
13:43 < Dinnerbone> They are someones guess at a name
13:43 < Dinnerbone> They are not from us, they are not official, and quite frankly most of them are really silly names.
13:43 < Flemmard> but Dinnerbone don't argue, you know nothing of origial code .. (lol)
13:44 < MrARM> yes, I know, it's completely other than real names
13:44 < shoghicp> It is just a nice name for variables like "a"
13:44 < MrARM> but that's before MCP
13:45 < MrARM> anyway I remember when I wanted to make pistons length bigger and I didn't had problems finding it in MCP
13:45 < shoghicp> because they are "human" names ;)
13:46 < MrARM> I generally like decompiling stiff, I can't forget when I found a password to an internet in it
13:46 < shoghicp> At least MC for pc can be "decompiled"
13:46 < Dinnerbone> You once found a password to the internet?
13:46 < shoghicp> but in MCPE you will always work with assembly code
13:46 < MrARM> *infranet
13:47 < shoghicp> infranet or intranet?
13:47 < MrARM> what's the difference? 
13:47 < shoghicp> I haven't heard infranet
13:48 < shoghicp> then they are the same :)
13:48 < MrARM> An web page with level editor
13:49 < MrARM> for cut the rope
13:49 < Flemmard> and ?
13:50 < MrARM> I could see what is coming for Cut the Rope 2, but I saw a file called klogger.php in it, so I decided to do not open it
13:51 < Flemmard> and how is this related to minecraft?
13:51 < MrARM> idk
13:51 < Flemmard> ok
13:52 < shoghicp> But off-topic chatter is ok here, as the rules say
13:52 < shoghicp> if they do not interrupt an on-topic current conversation
13:52 < MrARM> Anyway I'll be back to coding now
13:53 < shoghicp> MrARM: also, I updated the android build
13:53 < shoghicp> so you may want to update DroidPocketMine
13:53 < MrARM> to PHP?
13:53 < shoghicp> several users reported that the latest dev failed to load there
13:53 < shoghicp> yes
13:53 < MrARM> anyway, you know my version manager? 
13:54 < shoghicp> hmm... no
13:54 < MrARM> I may add php to it.
13:54 < MrARM> ok, where you have posted it?
13:55 < shoghicp> in sourceforge
13:55 < shoghicp> files -> builds/
13:56 < MrARM> ok, but I don't remember the name of repo
13:56 < shoghicp> https://sourceforge.net/projects/pocketmine/files/builds/
13:56 < MrARM> ok
13:56 < shoghicp> the code is still on github
13:56 < MrARM> i thought it wasn't in the main repo
13:57 < shoghicp> the pocketmine-mp code ;)
13:57 < MrARM> anyway, you don't use github?
13:57 < shoghicp> I can't use it for the PHP binaries
13:59 < MrARM> hmmm... Why connection to server doesn't end with error and no messages are sent)
13:59 < MrARM> *?
14:06 < MrARM> hmmm
14:07 < MrARM> who is ^ ?
14:10 < MrARM> who is that ServereOverfl0w?
14:10 < shoghicp> MrARM: someone with severe internet issues
14:11 < MrARM> Excess Flood? I wouldn't say it? 
14:11 < shoghicp> hmm
14:11 < shoghicp> true
14:11 < shoghicp> maybe he is on another channel
14:11 < shoghicp> where someone is spamming
14:12 < MrARM> i think it's a bot
14:12 < MrARM> where IT is spamming
14:12 < MrARM> or his client went stupid
14:13 < bilde2910> Maybe he tries to join so many channels so fast he's kicked off, idk
14:15 < socks> hello, I am making a bot on minecraft and I can read chat messages, but not send them
14:15 < socks> so I'm wondering if the packet I send makes sense: b'\x07\x01\x05Hello'
14:15 < MrARM> socks 1.7.2?
14:15 < socks> yup
14:15 < MrARM> could I see source? 
14:16 < socks> sure but it's pretty ugly
14:16 < MrARM> what's the programming language? 
14:16 < socks> python
14:17 < MrARM> I would like to see the source code anyway.
14:18 < MrARM> socks I think you missed string length
14:18 < socks> http://pastebin.com/DX3r8MY4
14:19 < MrARM> thanks! 
15:36 < nyuszika7h> MrARM: \x05 looks like the string length to me
15:36 < nyuszika7h> that said I don't know the protocol specs
15:40 < MrARM> it's possible,
15:41 < MrARM> however I don't think it's the correct way
15:42 < MrARM> (I still can't get my client to work)
16:04 < woder> MrARM: if you are still having issues, I have a java client that works: https://github.com/woder/TorchBot/tree/Torchbot.1.7.x
16:32 < MrARM> woder thanks, I will take a look on it. If it will work I have 25% of my project done
16:45 < MrARM> woder what's license is it?
16:46 < woder> uh...
16:47 < woder> GPLv3
16:53 < MrARM> anyway, I'll try to fix my Packet class only
16:54 < woder> MrARM: what language are you writing in?
16:55 < MrARM> Java
16:55 < MrARM> I have written a cool Packet class
16:55 < woder> mind if I see your packet class?
16:56 < MrARM> ok, I can give you my whole code, I am stuck on sending any packet
16:57 < bilde2910> woder: How does your plugin system work
16:57 < woder> right now it loads all .js files into memory and passes events to them
16:58 < woder> so javascript
16:58 < bilde2910> hmm
16:58 < bilde2910> how do I hook into events then
16:58 < woder> I have an example, one second
16:59 < woder> bilde2910: http://pastebin.com/EhWwFqJD
17:00 < bilde2910> Hmmh interesting
17:00 < bilde2910> Is it possible to.. save files using that scripting?
17:01 < bilde2910> And are java classes like Properties available?
17:01 < MrARM> woder pastebin.com/LAPMt5xQ
17:01 < woder> anything java script can do you can do
17:01 < woder> and yeah, you can access bot (the main bot class)
17:02 < woder> MrARM: interesting way to do the byte array
17:03 < MrARM> yeah (;
17:06 < woder> you're setting the mode to status, are you trying to ping then?
17:06 < jj2baile>  hmm, has anyone had issue with seeing a custom client after it "respawns"? If It logs out and back in, it becomes visible, (or if I do the same with the client through which i am viewing the world)
17:06 < MrARM> I gave you all my code, I thought server is going to response anyway
17:07 < jj2baile> do I just need to actually move for the notchian client to bother rending the character or something
17:07 < woder> jj2baile: yep, you need to send movement updates
17:07 < jj2baile> hm okies. I send movement packets pretty frequently, but not actually going anywhere.
17:08 < woder> does the server reply to them?
17:09 < jj2baile> What is the servers reply to movement? just the look update thing, 0x08 or something?
17:09 < jj2baile> look/position update
17:10 < woder> im asking does the server send you look/position after you send it movement?
17:10 < jj2baile> yes
17:10 < woder> MrARM: I can't see anything obvious, so I guess there is a problem in your bit wise
17:10 < woder> yeah, if its sending you look/position it means you sent the wrong data
17:11 < jj2baile> Oh, interesting response. I thought there was a "moved wrongly" error for that or something
17:12 < woder> I had that problem earlier today :P
17:12 < woder> got around it because the server expects you to send it y-1.620 then just y for stance
17:14 < MrARM> woder should I get any response when just sending 0x00?
17:14 < woder> if the packet is wrong, no, it will just close the connection
17:15 < MrARM> I get EOF
17:15 < MrARM> woder but even if I won't ping
17:15 < MrARM> ?
17:16 < woder> Like I said, if it closes the connection its because the packet structure is wrong
17:18 < MrARM> ok, so I have to review my code
17:20 < MrARM> I'll maybe modify your code to dump all packets to file
17:21 < woder> im fine with that
17:21 < jj2baile> woder: Yep thanks. It was exactly as you said
17:21 < jj2baile> how'd you figure that out, it seems the wiki might be slightly inaccurate then
17:21 < woder> yeah, it only took me like 2 weeks to find that
17:21 < woder> :P
17:22 < jj2baile> ;_;
17:22 < jj2baile> That depresses me
17:22 < Flemmard> stance joys ?
17:23 < woder> yeah
17:23 < Flemmard> eh yeah ..
17:23 < jj2baile> So basically it might be more accurate to say posn/look packet returns the stance, and the y is a subtractive factor from the stance?
17:23 < Flemmard> especially that (on the version of protocol i played with, a long time ago), it was inverted ..
17:23 < jj2baile> or some rewording 
17:24 < woder> yeah, it basically sends stance instead of y, and y is just y-1.620
17:24 < woder> *stance-1.620
17:24 < Flemmard> nah, stance is y+1.620
17:24 < jj2baile> yeah I found it suspicious that the stance was x.620, but never got around to investigating
17:24 < Flemmard> but on a packet stance and y are inverted
17:24 < Flemmard> afaik
17:24 < Flemmard> jj2baile: it's basically the height of the 'guy'
17:25 < Flemmard> it measures 1.620 when up
17:25 < Flemmard> less when crouching
17:25 < Flemmard> etc ..
17:25 < Flemmard> (from what i understood)
17:25 < jj2baile> Flemmard: aha, I see
17:25 < woder> yeah, but pos look coming from server changed, it doesn't have a stance field anymore
17:26 < jj2baile> So like with half blocks like step, when you step up part way through a block, is stance, or y or both modified
17:27 < Flemmard> stance is basically everytime y+1.620
17:27 < Flemmard> unless you're crouching
17:27 < jj2baile> oh, Alright then. Duly noted.
17:28 < Flemmard> again, it was a long time ago
17:28 < Flemmard> maybe it has changed
17:28 < jj2baile> stance seems kind of evil.
17:28 < Flemmard> but tha's what i understood of it
17:28 < Flemmard> and in a way that makes sense
17:28 < woder> im not sure why they started sending the stance instead of the y
17:28 < Flemmard> uh ?
17:29 < Flemmard> are you sure you havent inverted y/stance ?
17:29 < jj2baile> the y that they send now is of the form x.62 for some x from what ive seen
17:29 < woder> I am 100% sure
17:30 < Flemmard> it's been a while i havent played with protocol .. not sure about new so .. don't mind me
17:31 < jj2baile> yeah, the y my client shows for the same elevation is (x-1)
17:31 < jj2baile> but still, good to know of what was, in case it becomes once more...
17:32 < jj2baile> I should implement real movement, typing out commands by hand is hard
17:32 < Flemmard> ahah
17:32 < Flemmard> yeah sure
17:33 < MrARM> woder how can I compile your torch bot?
17:33 < jj2baile> In general, is 0x08 - Player Position and Look, only sent after logging in, and respawning, or other times as well?
17:33 < woder> to compile you need a few libs
17:34 < MrARM> woder what ide did you use? How can I import it into eclipse?
17:34 < woder> ok, "a few" is putting it lightly: http://wltd.org/LoLDoc/2013-12-08_11-34-16.png
17:36 < MrARM> woder can you just zip it into an eclipse project?  Eclipse says  that it isn't a valid eclipse project and won't import
17:36 < woder> sure one second
17:38 < woder> http://wltd.org/Bot.zip it has the project file and the src
17:39 < MrARM> hmmm... the project doesn't look correctly
17:39 < MrARM> in eclipse there is no /src/
17:40 < MrARM> all packages put directly into /
17:40 < woder> might need to go add it manually in your workspace (I really need to make easier to compile :c)
17:40 < MrARM> yes, you need to
17:43 < MrARM> woder can you just zip all your eclipse folder? Or it is a too big upload? 
17:44 < MrARM> (now I get for what maven was made)
17:44 < woder> if you install EGit you should be able to have it done automaticly
17:46 < jj2baile> IDEs seem like a pain.
17:46 < jj2baile> Although I suppose makefiles aren't the pretties either.
17:46 < MrARM> no it doesn't, if it doesn't have all the required files it has no right to work
17:47 < woder> what files does it need?
17:48 < MrARM> ok, I gave up building this project
17:49 < MrARM> .settings folder
17:49 < MrARM> .classpath
17:51 < MrARM> anyway can you tell me which file in your project is encoding java vars to bytes? 
17:52 < woder> https://github.com/woder/TorchBot/blob/Torchbot.1.7.x/src/me/woder/network/Packet.java
17:54 < woder> MrARM: I rezipped it, that zip files has every project file I have in it
17:56 < jj2baile> i wonder what a good way to store state without...storing state is. Yeah thats not a very good question now is it.
17:59 < MrARM> woder not that file, I talk about tge file where you do int-> byte array
18:00 < woder> MrARM: I don't do int to byte array, I use a ByteArrayDataOutput
18:01 < MrARM> ok, so I will use my internet to browse for it
18:01 < MrARM> s source code
18:02 < MrARM> I really don't see the point of using that many libs :P
18:03 < woder> I don't really like to write code that is already written
18:13 < MrARM> woder I found an mistake in my sending code
18:15 < woder> MrARM: ah, does it work now?
18:15 < MrARM> starting MC server now
18:16 < MrARM> now doesn't throw EOF
18:18 < MrARM> woder what should I send now?
18:19 < woder> Assuming you want to login: http://wiki.vg/Protocol#Login
18:19 < MrARM> nope, not premium option
18:19 < MrARM> Which packet?
18:19 < MrARM> 0x..?
18:21 < MrARM> woder anyway guess what was the mistake...
18:21 < woder> no idea, what was it?
18:21 < MrARM> string -> bytes
18:22 < woder> ah
18:22 < MrARM> 1. Rather than using VarInt for string I used Short
18:22 < MrARM> 2. No encoding declared
18:23 < MrARM> woder which packet to send now?
18:23 < MrARM> login?
18:24 < MrARM> woder did anything with encryption changed in 1.7.2?
18:24 < woder> you're trying to login?
18:25 < MrARM> from what I know I have to send my username to server..?
18:25 < woder> yep, you send a login start
18:25 < woder> I *think* that is packet 0 in mode 2
18:25 < MrARM> or encryption start? 
18:26 < woder> MrARM: it says the order on the wiki, I linked the page
18:26 < MrARM> woder anyway what does encryption mean? online mode?
18:27 < woder> yeah, if server is on online mode it will send you encryption request
18:27 < MrARM> wait it says if localhost then won't
18:28 < woder> I have never seen that actually happen, even on localhost it still sends encryption
18:30 < MrARM> anyway Name is username? 
18:31 < woder> yep
18:31 < MrARM> ok...
18:33 < MrARM> yay! works! 
18:35 < woder> awesome!
18:36 < MrARM> so I am on the right way, probably I won't need help as long as I will be able to read all the stuff here
18:37 < MrARM> I really like my packet class; it's simple and makes it's task
18:39 < MrARM> woder mind if I steal your readVarInt function? 
18:40 < woder> nope, go ahead
18:40 < MrARM> lol
18:44 < MrARM> woder I just saw that snippet somewhere else on the Internet. ..
18:44 < woder> yeah, its not mine
18:44 < woder> got it from the wiki
19:07 < MrARM> woder thanks! I know how to send and receive packets now
19:07 < MrARM> I have successfully handled Login successful packet
19:08 < woder> MrARM: no problem, and good luck with the rest of your project
19:08 < MrARM> along with strings in it
19:08 < MrARM> now I'll have to write the rest of it+MCPE server
19:09 < MrARM> but MCPE server should be easier thanks to shoghicp
19:09 < MrARM> (you know what am I doing, right? )
19:11 < dexter0> building a PE to PC protocol converter?
19:12 < bilde2910> That's a crazy good idea ^
19:12 < bilde2910> Been thinking about it myself
19:14 < MrARM> nope
19:14 < MrARM> PC to PE
19:15 < dexter0> then why do you need to write a PE server?
19:19 < MrARM> ?
19:20 < MrARM> I am going to make PE players able to join PC servers
19:20 < dexter0> ok, that's what I guessed originally.
19:20 < dexter0> I suppose I was not clear though.
19:26 < MrARM> I write it in Java so later I just move the source code and add gui
19:26 < MrARM> I am not sure, should I implement premium users thought
19:27 < MrARM> I may, but then some people may say that I stole their passwords... blah blah blah
19:28 < umby24> keep it open sauce
19:32 < nickelpro> My code was posted twice and I slept through it =(
19:32 < nickelpro> Finally an oppertunity to be helpful
21:16 < shoghicp> MrARM: yes, I know
21:48 < Not-002> [fCraft] fragmer * r2304 2 files : Added a missing line in 0.640 changelog
21:49 < Not-002> [fCraft] fragmer * r2305 2 files : Added EnvWeatherType to CpeExtension enum, and corrected descriptions for a couple extensions.
21:50 < Not-002> [FemtoCraft] fragmer * r138 2 files : Added a note about email account support to FemtoCraft homepage
--- Day changed lun. déc. 09 2013
00:14 < Not-002> [Craft.Net] SirCmpwn pushed 1 commit to 1.7.x [+0/-0/±1] http://git.io/QKcrmg
00:14 < Not-002> [Craft.Net] SirCmpwn 0db18ae - Refresh tokens with Mojang at /refresh
00:25 < Not-002> [Craft.Net] SirCmpwn pushed 2 commits to 1.7.x [+0/-0/±5] http://git.io/qGj6Mw
00:25 < Not-002> [Craft.Net] SirCmpwn 54c2946 - Fix movement in Craft.Net.Client
00:25 < Not-002> [Craft.Net] SirCmpwn 1fc1d80 - Remove test code from C.N.Client
09:10 < nerd323> hey all
09:11 < nerd323> why is Dinnerbone not an op?
09:11 < Thinkofdeath> nerd323: Don't needlessly ping the devs please
09:12 <+AndrewPH> I would have expected "why is nobody an op?" before "why is [redacted] not an op?"
09:14 < Thinkofdeath> Also why just DB? Gr_m is here too!
09:14 < TheUnnamedDude> ^
10:19 < jj2baile> Is the only way to determine if you should fall to load the chunks and inspect beneath oneself?
10:20 < jj2baile> I seem to only get 0 for on_ground field of the 0x08 position and look packet
10:29 <+SirCmpwn> jj2baile: that's correct, you need to decode the chunk packets and do some basic physics simulation
11:09 < jj2baile> SirCmpwn: I see, Thanks.
11:10 < MrARM> hello
11:11 < ToXic> hey
12:13 < MrARM> 0x00 as disconnect packet, can be send only if 0x02 haven't seen already, right? 
12:14 < MrARM> *sent
12:15 < Thinkofdeath> After 0x02 your in the play state, its a different disconnect packet
12:15 < MrARM> yeah, so i were right
12:17 < MrARM> and the encryption takes place all the time after it or only for logging in?
12:18 < Thinkofdeath> All the time
12:18 < Thinkofdeath> After its turned on during login
12:18 < MrARM> ok
12:18 < MrARM> I'll leave this part for the end maybe, there's a lot of packets to handle any way
12:55 < zutto> out of curiosity since the protocol has changed, how many packets do you need to send to appear on a server now?
12:55 < zutto> before it was just handshake and some other, it seems to have changed quite bit