17:37 < Aragas> _stream.ReadPacket(length - 2, 0)
17:37 < Aragas> thank you, shoghicp!
17:37 < shoghicp> :)
20:29 < Aragas> it's working slower with overall compression
20:30 < Aragas> single thread can't handle packet reading and decompression, but makin' another thread isn't an option
20:34 < Aragas> A mean, mobile platforms wouldn't handle it. Hm. then threshold should be higher
--- Day changed mar. sept. 23 2014
07:38 < Jckf> sadimusi: Burger no longer maintained?
08:33 <+fragmer> The more I learn about 1.7+ protocol, the less sense it makes.
08:33 <+fragmer> I wanna go back to Classic :P
08:34 < Jckf> I was happy in beta
08:34 < Jckf> Although
08:34 < Jckf> ON GROUND ON GROUND ON GROUND ON GROUND
08:35 <+AndrewPH> attn server: I AM ON THE GROUND
08:35 <+AndrewPH> my y position IS THE SAME AS THE GROUND
08:35 <+AndrewPH> AM ON GROUND
08:35 <+AndrewPH> does it still do that thing where it spams position updates?
09:20 <+Amaranth> AndrewPH: 20 movement packets a second
09:20 <+Amaranth> Or more
09:20 <+Amaranth> But that makes sense, really. Quake is spamming positions back and forth every tick too, more or less
09:25 <+AndrewPH> Amaranth: I mean even when not moving
09:25 <+Amaranth> AndrewPH: Me too
09:25 <+AndrewPH> :c
09:26 <+Amaranth> The client does try to make sure it's always 20 instead of just spamming like it used to
09:26 <+Amaranth> But it fails a bunch so you can get up to 60 pretty easily
09:26 <+AndrewPH> technically I suppose quake had a reason - every cpu cycle counted!
14:10 < gurun> I'm using the PE protocol (0.9.5a client) and receive 0x84 a bit unexpected. Can't even see that package implemented in PocketMine. It's bigger than the package described on the website.
14:11 < gurun> Could it be that it is sending two RakNet packages in the same UDP message. The code of RakNet implies that it could do that for ..effeciency.
14:12 < PEMapModder> gurun: I remember it is an MCPE bug.
14:12 < gurun> oh.
14:13 < gurun> PEMapModder:do you remeber what the bug is .. that it is sending the package at all, or that it is putting them together (which I don't believe is a bug in itself, just unexpected)
14:14 < gurun> This is what I received: Packet data: {0x84,0x01,0x00,0x00,0x40,0x00,0x90,0x00,0x00,0x00,0x09,0xff,0xff,0xff,0xff,0x82,0xb5,0xe6,0x16,0x00,0x00,0x00,0x00,0x00,0x35,0xf4,0x0f,0x00,}
14:14 < gurun> if you look at the end.. i also get a 0x82 byte which is what I would expect.
14:14 < gurun> end as "at the second half"
14:15 < shoghicp> PEMapModder: hmm?
14:15 < shoghicp> 0x84 packets are RakNet packets
14:15 < PEMapModder> Oh
14:15 < PEMapModder> I thought he is saying the set time packet
14:15 < gurun> it might very well be that I'm sending something that provokes this, i'm just not sure. But since it works for the others i have to assume it is something I do.
14:16 < shoghicp> https://github.com/PocketMine/RakLib/blob/master/protocol/DataPacket.php
14:16 < shoghicp> https://github.com/PocketMine/RakLib/blob/master/protocol/EncapsulatedPacket.php
14:16 < shoghicp> a Data packet (0x80-0x8f) contains one or more encapsulated packets
14:16 < shoghicp> that have different flags, numbers, etc
14:17 < shoghicp> and inside that layer, the MCPE packets are sent
14:18 < gurun> yes. so hmm .. maybe I should ask what 0x84 represents for you? I'm not sure how to read the spec. I would expect it to be the message ID of a custom package.
14:18 < gurun> but maybe i missunderstand
14:18 < shoghicp> 0x84 is the header
14:18 < shoghicp> 0x84 + three byte id
14:19 < shoghicp> then, a list of encapsulated packets follow
14:19 < PEMapModder> He means why it is 0x84
14:19 < shoghicp> that three byte ID is used in ACK/NACK
14:19 < PEMapModder> Not 0x80 or whatever
14:19 < shoghicp> 0x84 is what MCPE used by default on 0.5.0
14:19 < shoghicp> it might mean priority or channels
14:19 < PEMapModder> And others?
14:20 < shoghicp> MCPE sends 0x80-0x8f, PM only sends one
14:20 < PEMapModder> 0x84?
14:21 < shoghicp> yeah
14:21 < shoghicp> well
14:21 < shoghicp> not pocketmine
14:21 < shoghicp> but RakLib
14:21 < shoghicp> pocketmine doesn't know about RakNet at all
14:22 < PEMapModder> OK, stop advertizing :P
14:22 < shoghicp> ?
14:22 < gurun> ok, just because I feel completely dumbstruck now. What RakNet message would you say this is?
14:23 < gurun> or MCPE
14:23 < shoghicp> oh, the inside of the packet itself?
14:23 < gurun> ok
14:23 < gurun> wait
14:23 < gurun> so, you say that this is a generic header.
14:23 < gurun> if that is what you mean, i can understand.
14:23 < shoghicp> 0x09
14:24 < shoghicp> that's part of the internal RakNet handshake
14:24 < shoghicp> after enabling reliable transmission (that's when 0x8X packets are sent)
14:24 < shoghicp> there is another handshake
14:25 < shoghicp> that starts with 0x09 :)
14:25 < gurun> so .. hmm, does your code deal with 0x84. I simply can't find the code that would read the header in your code. That is why i started asking.
14:25 < shoghicp> it's not in pocketmine
14:25 < shoghicp> it's in RakLib
14:25 < shoghicp> https://github.com/PocketMine/RakLib
14:26 < gurun> yes, i'm looking in the RakLib code
14:26 < PEMapModder> gurun: it is in another class
14:26 < PEMapModder> Something like DATA_PACKET_something.php in the same dir
14:26 < shoghicp> all those classes extend DataPacket.php
14:27 < shoghicp> then, DataPacket decodes the EncapsulatedPacket list
14:27 < PEMapModder> And all these packets are registered in some other file, I forgot what, use search :P
14:27 < PEMapModder> (Then shoghicp will tell you where it is)
14:27 < gurun> ok
14:27 < gurun> now i get it
14:27 < gurun> so, that is the DataPackage class
14:28 < gurun> so it is the msgId and the sequence number. and then the stuff.
14:28 < PEMapModder> It is DataPacket
14:29 < gurun> i suddenly undestand this line better ..             if($packet::$ID >= 0x80 and $packet::$ID <= 0x8f and $packet instanceof DataPacket){ //Data packet
14:30 < gurun> super guys. thanks a lot. i think i understand better now.
14:30 < shoghicp> :)
14:31 < gurun> shogchips:I went ahead and did that XML file I was talking about. So I'm actually generating this code from XML now (T4 templates). So I'm building documentation as I go too.
14:31 < shoghicp> nice!
14:32 < gurun> Small example
14:32 < gurun> <pdu id="0x01" client="true" server="false" name="ID_UNCONNECTED_PING" size="">
14:32 < gurun>   <field name="Ping Id" type="Int64" exampleData="" />
14:32 < gurun>   <field name="MAGIC" type="MAGIC" exampleData="" />
14:32 < gurun>  </pdu>
14:32 < shoghicp> looks nice!
14:32 < Aragas> yes, this is really time saving stuff
14:32 < gurun> it includes documentation where it exists too
14:32 < Aragas> i'm working on something like this too
14:33 < gurun> Aragas:for PE or for the other protocol?
14:33 < Aragas> main protocol
14:34 < shoghicp> Aragas: compatible with BurgerVitrine? 
14:34 < gurun> ok. that sounds good too. Maybe I can align with that format you have later. Is it XML or something more to-the-point format?
14:34 < shoghicp> gurun: BurgerVitrine uses JSON
14:34 < shoghicp> and the output looks nice ;)
14:34 < SinZ> JSON > *
14:35 < Aragas> nope
14:35 < gurun> yeah, JSON would work too. I'm just reading "some" structured format in the template. Right now XML but could just as easy be JSON.
14:35 < Aragas> i wanna to automatically convert new packet changes to C# (and maybe java) code
14:36 < Aragas> manually see differences isn't cool
14:36 < gurun> I just want to make sure to capture documentation and examples so tests can be generated from it too.
14:36 < Aragas> but fist, i'll port my network to 1.8
14:37 < gurun> did you look at the RakNet code .. geee, I never want to go back to that coding.
14:37 < gurun> The Peer CPP is really scary complex..
14:37 < shoghicp> gurun: all of the work at first was done without that code
14:38 < Aragas> Why do they use UDP?
14:38 < shoghicp> I checked later to remove some "Unknown" fields from the code
14:38 < gurun> shogchips: I will align the field-names with RakNet too, if it isn't already. Most of it seems to be though.
14:39 < shoghicp> yeah, those names were public
14:40 < gurun> I chatted with a contact at Lego today .. they are cooking something together with MC. Very hush hush.
14:41 < shoghicp> more lego packages :)
14:41 < gurun> I'm thinking texture stuff will come to PE. I understand that is not really supported right now.
14:41 < gurun> and non-killing gamemodes.
14:41 < shoghicp> you can't change them directly, but you can replace the files
14:42 < gurun> replace, on the client or?
14:42 < gurun> my son (6 years) is doing the business analysis for this little project.
14:42 < shoghicp> on the client, yeah
14:42 < gurun> he told me that in his pre-school class there was a great demand for a Lego MC.
14:43 < gurun> And yesterday evening he told his mom "Mom, you can't disturb daddy now, he is working for me now" ehh..
14:43 < gurun> 6 years.. and I'm already his bitch :-(
14:44 < shoghicp> haha
14:45 < gurun> but all fun. Thanks for the pointers. Time to get back to bits and bytes again.. next package.
14:54 <+sadimusi> Jckf: no. I would have to rewrite it almost from scratch and simply lack the motivation to do so…
14:55  * Jckf hugs sadimusi
14:56 < dx> did someone talk about burger? pseudo-burger here https://github.com/thinkofdeath/mc-autodocs
15:19 < gurun> ok, now i understand 0x84
15:20 < gurun> RakNet checks not for the range of messages, but it rather checks for the offline-identifier to see the difference.
15:20 < gurun> because there could be offline custom packages as well
15:20 < gurun> but for us, it means a "range" right now.
15:25 < shoghicp> yep, I found that looking at their code
15:26 < shoghicp> but RakLib is for MCPE only, so it's OK :)
15:31 < gurun> yep
16:00 < gurun> godamn i've never seen so many special cases as in RakNet. But at least it is clearer now. They have a datagram header as you said shoghi. And the framgmentation of messages fits the async model of C# very well, so that is really good news.
16:01 < shoghicp> :)
16:01 < gurun> I love to GOTO they have. But it is for performance, so I guess it is excusable :-)
16:04 < shoghicp> gurun: also, is the code for generating autodocs somewhere?
16:07 < gurun> wow. .NET actually have native support for writing the string-format used by RakNet. Luck. Are we sure that MCPE can't deal with unicode and stuff?
16:07 < gurun> i mean, double bytes
16:07 < shoghicp> gurun: it uses UTF-8
16:08 < gurun> cool. Maybe i missunderstood the wiki.
16:09 < dx> gurum
16:09 < gurun> gurum
17:45 < gurun> 0x84 finally got that one too.
17:45 < gurun> it's a bit-pattern based on booleans in the message header struct.
17:46 < gurun> so, for all non-offline messages that are also internal to RakNet it needs parsing.
17:48 < gurun> and depending on that bit-pattern, you get different structs (ack, nack, else). Hence forming the byte-patterns 0x00, 0x40, 0x60
18:43 < MrARM> Session servers down… this is strange
18:53 < MrARM> it looks like a DDoS...
18:53 < bgale> how can you tell that?
18:54 < MrARM> according to http://xpaw.ru/mcstatus/ the servers go up and down, sometimes with a long load delay 
19:10 < MrARM> it's still down... and still goes up and down
19:11 < dx> ok
19:11 < MrARM> hmmm... it may be on now
19:11 < dx> "servers down… this is strange" <-- lol
19:11 < Spurlex> xPaw isn’t showing correctly at the moment
19:11 < Spurlex> Minecraft.net is up
19:11 < Spurlex> “xPaw: mojang is aggressively rate limiting everything”
19:12 < MrARM> yeah 
19:12 < MrARM> session *was* down actually 
19:15 < MrARM> Yeah, session still down
19:15 < MrARM> skins are down too
19:15 < dx> ok
19:21 < Aragas> they just seein' up asp.net
19:21 < Aragas> settin'*
19:21 < Aragas> lol
19:23 < gurun> hmm .. hope it's not my server attacking :-)
19:28 < MrARM> gurun: one person is not enough to DDoS such a big server xD
19:40 < Bibl> god damn im back
19:44 < Jckf> Does anyone here have a dump of the current login procedure?
20:07 < dividuum> I just released my 1.7/1.8 protocol parser/writer for python. It's used on miners-movies.com, so it's kind of battle tested for the 1.7 protocol. enjoy: https://github.com/dividuum/fastmc
20:12 < bgale> I like the ascii art
20:18 < dividuum> yay. figlet :-)
20:22 <+sadimusi> hmm the code generation for the protocol isn't really pretty but I wonder how much faster it is than my more reflective approach
20:29 < dividuum> not sure. feel free to measure :-)
20:30 <+sadimusi> my implementation probably isn't complete enough to make a fair comparison. plus my more efficient io handling might make up for the slow parser
20:31 < dividuum> more efficient io handling?
20:32 < dividuum> i'm always interested in speeding up things...
20:32 <+sadimusi> I haven't measured anything, but you seem to be copying around a lot of data
20:32 <+sadimusi> for example when receiving from a socket https://github.com/dividuum/fastmc/blob/master/fastmc/proto.py#L1281
20:33 < dividuum> hm. that's bulk reading from the socket. i didn't measure it, but i feel like it should cause a big overhead. looking into mc4p now... :)
20:34 <+sadimusi> the mc4p on github is probably even worse than your method
20:34 < dividuum> https://github.com/sadimusi/mc4p/blob/master/mc4p/proxy.py#L202 :-P
20:35 <+sadimusi> as I recall it the packet emitter is even constantly joining strings together
20:35 < dividuum> mine is 100/4092*4096 % more efficient ;-)
20:35 < dividuum> did you ever update mc4p to 1.8?
20:36 <+sadimusi> I didn't even update it to 1.7 but I'm working on a complete rewrite which should be much more efficient
20:36 < dividuum> uh. you didn't? i was sure there was a 1.7 version
20:36 <+sadimusi> but I must admit I haven't done enough profiling to tell exactly what combination of buffers and recv_into works best
20:36 < dividuum> reading you code made me better understand how to parse minecraft. so thank you :-)
20:37 < dividuum> on a related note: parsing packed location data sucks
20:39 <+sadimusi> since 1.7 you can at least skip uninteresting packets altogether
20:39 <+sadimusi> at least for a proxy that speeds things up a lot
20:39 < dividuum> yep. that's useful
20:40 <+sadimusi> of course I couldn't resist to make my packet objects lazily parse themselves as soon as a field is accessed :)
20:41 < dividuum> how do you deal with data that's preceding the requested field? parse that before returning a value?
20:41 <+sadimusi> currently the complete packet is parsed even if you only access the first field
20:42 < dividuum> ok
20:42 < dividuum> is there a better way to do this: https://github.com/dividuum/fastmc/blob/master/fastmc/proto.py#L138
20:43 <+sadimusi> probably not, but I would define that function in the global scope
20:44 < dividuum> is access to that scope faster?
20:46 <+sadimusi> no, but you don't want to redefine the function every time you're parsing such a field  
20:48 < dividuum> hm. is that really a thing? if so i should probably change that. right now I use it for hiding crap away that's not used anywhere else
20:49 <+sadimusi> I'm not really sure if it's cached in some way if no variables from the enclosing scope are used, that might depend on the interpreter
20:50 < dividuum> might be worth looking into. thanks for the pointer
20:56 < dividuum> seems to depend on the amount of global functions. having only 2 global functions make calling a global function faster. with 1000 global functions it's slower than calling a locally defined functions
20:56 <+sadimusi> yeah, and the difference isn't that big
20:56 <+sadimusi> even with just one function it's only around 0.05ms faster per call on my machine
20:56 < dividuum> yeah :-)
20:57 <+sadimusi> oh wait, that should have been µs
20:58 < dividuum> https://github.com/dividuum/fastmc/blob/master/fastmc/proto.py#L609 is that the correct way of figuring out how many bytes to read in a bulk chunk update packet?
20:58 < dividuum> since there's no size header...
20:58 <+sadimusi> :D
20:59 < dividuum> also i'm embarrassed about my bit counting function :-)
20:59 <+sadimusi> probably not the fastest way but certainly the simplest
20:59 < dividuum> according to someone on stackoverflow[tm] it's the fastest way :-\
21:00 < dividuum> searched my "hacker's delight" book but figured it's not worth it
21:08 < antivapor> hi
21:08 <+sadimusi> hi
21:11 < antivapor> i'm looking for a tool similar to http://b.wiki.vg because i want to update the bravo server to current, but really i dont even know where to begin
21:12 <+sadimusi> there's some generated stuff here https://github.com/thinkofdeath/mc-autodocs
21:13 <+sadimusi> but to update bravo the wiki should really be enough http://wiki.vg/Protocol
21:15 < antivapor> sadimusi: thanks!
21:20 < antivapor> sorry to be annoying to anyone because i know you all have your own projects, but is anyone interested in helping me update https://github.com/bravoserver/bravo/blob/master/bravo/beta/packets.py ... i just kindof need to be shown how to fix a single error and then i think i can go on auto-mode
21:20 <+SirCmpwn> probably not. Do it yourself
21:21 < antivapor> i intend to :) just curious
21:34 < dividuum> antivapor, i just release my code like 2 hours ago. take a look https://github.com/dividuum/fastmc
21:35 < antivapor> dividuum: siiiick! thank you
21:36 < dividuum> 1.7 code should be correct. 1.8 is kind of new, so be careful
21:43 <+SirCmpwn> return bin(v).count("1") # yep
21:43  * SirCmpwn blinks
21:44 <+SirCmpwn> fwiw https://github.com/KnightOS/z80e/blob/master/libz80e/src/core/registers.c#L24-L33
21:44 <+SirCmpwn> I have no idea how it works, but it's supposedly the fastest way
21:45 < dividuum> SirCmpwn, yep :-P
21:46 <+sadimusi> it's actually a little slower for me
21:46 < dividuum> that's what's in my hacker's delight book too. that's divide and conquer somehow, but it seems that the stupid method i chose is faster in python
21:46 <+sadimusi> maybe if it was optimized for 16 bit wide values it would be a little faster
21:46 < dividuum> maybe
21:47 < dividuum> oh. the wiki is moderated?
21:47 < dividuum> enjoy my 2 different edits. thought I clicked the wrong button the first time :-)
21:48 <+sadimusi> I don't think it is
21:48 < dividuum> hm
21:51 < dividuum> I seem to end up on the editing page after I clicked "Save". And my changes disappear...
22:09 < Jckf> Hm. I am reading the following initial handshake 2f093132372e302e302e3163
22:09 < Jckf> 2f is parsed as the varint 47
22:09 < Jckf> Oh right
22:09 < Jckf> Never mind, I just realized what my problem is =)
22:10 < Jckf> I was thinking "Why I am reading a byte too little, and having a tab infront of my string", but I'm obviously reading the string length varint as part of the string
22:48 < Jckf> Is it possible to skip encryption the same way one would skip compression?
22:52 < shoghicp> Jckf: online-mode=off
23:17 < gurun> MCPE protocol. 0x10 message structure. I don't have a trace of it from a real session. But are we sure that this is a custom messsage, it doesn't really match RakNet structure, but the ID does.
23:37 < dividuum> what's the current state of signatures that is included in the PlayerListItem data? Is that signature checked?
23:37 < dividuum> what has changed since 1.7.6(?)
23:38 < dividuum> I'm asking since I'm deciding on whether to continue to develop miners-movies. since this signature might break everything, I'd love to know what's the current state and what's likely to happen in the future
--- Day changed mer. sept. 24 2014
04:21 < Not-fc45> [Glowstone] SpaceManiac pushed 4 commits [+0/-0/±4] http://git.io/0ccKDA
04:21 < Not-fc45> [Glowstone] JeromSar dc35436 - Added more command-line parameters.
04:21 < Not-fc45> [Glowstone] greatman a85637d - Added command line parameters for jline.
04:21 < Not-fc45> [Glowstone] bendem d986e8e - Handle invalid command line parameters with a warning only.
04:21 < Not-fc45> [Glowstone] ... and 1 more commits.
04:28 < Jckf> About my question regarding encryption earlier
04:28 < Jckf> Seems you can skip encryption entirely but just not sending the packets
04:28 < Jckf> *by just not
04:29 <+SpaceManiac> From the server perspective?
04:29 < Jckf> Yep
04:30 < Jckf> I cba'd to implement it, so tried without
04:31 <+SpaceManiac> Yeah, you can skip EncryptionKeyRequestMessage and go straight to LoginSuccess
04:31 <+SpaceManiac> This is the equivalent of disabling online-mode
04:31 < Jckf> So vanilla does this?
04:32 <+SpaceManiac> If you turn off online-mode, yes
04:36 < Jckf> Something else that's interesting then: The client sends me pos+look packets before I've told it where in the world it is
04:37 < Jckf> I've only sent the bed position, but it also does this without that packet
04:37 < Jckf> Although the "Download terrain" screen will flicker then
04:38 < Jckf> *Downloading
04:44 < Jckf> X:8.5 Y:65 Z:8.5
04:44 < Jckf> That's where it claims to be
04:44 < Jckf> Which isn't even the bed position
04:45 <+SpaceManiac> IIRC the client just assumes some default position until you tell it where it is
04:55 < Jckf> How ignorant =P
05:15 < gurun> This BE/LE mixing in the protocol drives me crazy. Spent all night hunting twisted bytes. One by one. But now got it right, and progressed a whole package further in a whole evening.
05:18 <+SpaceManiac> Huh, just noticed the client now spins the sand texture around randomly
06:06 <+fragmer> SpaceManiac: like "Natural textures" option in the old OptiFine?
06:06 <+fragmer> OptiFine did a nice job of removing seams by randomly rotating and mirroring repeating textures
06:06 <+SpaceManiac> Never really used optifine, but probably
06:07 <+fragmer> e.g. https://i.imgur.com/ZR7rt.gif
06:07 <+SpaceManiac> I only just noticed it today, but it's somewhat jarring now that I see it
06:08 <+SpaceManiac> Yeah, pretty much like that
06:09 <+SpaceManiac> looks like there's an "Alternate Blocks" toggle in video options to control this
08:47 < Not-fc45> [Glowstone] SpaceManiac pushed 5 commits [+3/-0/±10] http://git.io/F28okg
08:47 < Not-fc45> [Glowstone] SpaceManiac 5a6084c - Added ClientSettings to players for storing settings sent by the client.
08:47 < Not-fc45> [Glowstone] SpaceManiac 0a659d0 - Handle torch placement (see #119).
08:47 < Not-fc45> [Glowstone] Aaron1011 a8d6eef - Toggle between normal and inverted daylight sensor on interact.
08:48 < Not-fc45> [Glowstone] ... and 2 more commits.
11:55 < Jckf> Hm. 1.8 does not need the bed position to spawn.
11:56 < Jckf> Only the three packets login success, join game, and a single position and look
12:35 < gurun> The documentation here http://wiki.vg/Pocket_Minecraft_Protocol#Types claims signed for all types. I can't say that I agree. What is the policy on editing the wiki. Is it a true wiki so anyone can do it or is it moderated.
12:37 < gurun> Looking at the RakNet code, i find that they use mostly unsigned types. But they also use signed in the packages (which is evident from looking at the results). Bit I suspect that maybe this is MCPE using different strategy than RakNet for the messages.
12:37 < gurun> It is the same with BE/LE. It is a mixture.
12:38 < gurun> I spent all day debugging yesterday, only to realize that i had to flip the byte-order on one of the shorts. So maybe can improve the documentation for that if I am allowed.
12:40 < gurun> Also need to add documentation about the start-byte of "internal message". Refered to as 0x8* messages. It is a bit-pattern that is really important to understand.
12:41 < gurun> The same for the framing envelope for the messages. Now it is documented as 0x00, 0x40 and 0x60. But in reality, not understanding what the bytes mean, and that they are controller logic in bit-patterns makes it virtually impossible to implement to protocol.
12:43 < gurun> And, to make it really easy for someone to use (don't see why we wouldn't do that), I think we should include more samples that can be used in cross-solution testing. I don't think it is ok to both try to document the specification and then tell people to "do your own traces" at the same time. Not that it happened here, but it seems to be the stand
12:43 < gurun> ard answer in another channels.
13:04 < shoghicp> gurun: about editing the wiki, you just need an account there
13:05 < gurun> i will register, check.
13:06 < gurun> then, the edits is of course up for discussion.
13:07 < gurun> can you tell me what in PHP decide the default byte-order. Is it the language or the platform it runs on?
13:08 < shoghicp> gurun: look at the Binary::read* and Binary::write* methods
13:08 < shoghicp> writeInt() = big endian
13:08 < shoghicp> writeLInt() = little endian
13:08 < gurun> yes, i did that.
13:09 < gurun> i couldn't figure out the default though.
13:09 < shoghicp> default on PHP or the network?
13:09 < gurun> but then i am to understand that when you call write something (without the L) it will be BE.
13:10 < shoghicp> yes
13:10 < shoghicp> I use BE as the default since normally network protocols are done using BE
13:10 < gurun> well, network if I would simplify things by tradition is supposed to be network order. And that by definition translates to BE. But that is just .. by history and conventions. There are no laws of course.
13:10 < shoghicp> that comes from some Minecraft client I did
13:12 < gurun> so, i figured out that i had a short in one of the messages. And i wrote it LE and that messed up my day yesterday. I guess i came as far as I did with all wrong order because the client actually doesn't really care about much of this stuff we have in the initial handshake.
13:13 < shoghicp> I think that the initial packets sent in BE would be ok
13:13 < gurun> but I've also checked all the defines (and collected them for reference) in RakNet, and most of the stuff they use are unsigned char (which is just byte for us) or unsigned short/int
13:13 < shoghicp> before getting into the reliable packets
13:13 < shoghicp> MCPE runs on ARM... so that's why :P
13:14 < shoghicp> I think they have a check on the packet write on the assembly
13:14 < shoghicp> so they convert things before sending
13:14 < gurun> ok. Is ARM LE?
13:14 < shoghicp> yep
13:14 < gurun> i see. same as my stuff.
13:15 < gurun> same as my stuff on THIS particular computer i should say.
13:15 < gurun> But i found a very nice class (IpAddress.HostToNetwork) that checks the platform and makes sure that it translates if needed. I'm adding that to the framework right now.
13:16 < gurun> Do you agree on the types. That they are generally signed, not unsigned.
13:16 < gurun> Or perhaps, the type-table should include both of course.
13:17 < shoghicp> they are generally signed
13:17 < shoghicp> except for a few things
13:17 < shoghicp> like the short for the port
13:17 < gurun> yes, in the actualy .. framing/packaging protocol, most things are unsigned.
13:17 < gurun> and BE. Except that LE trio damn datatype they included :-)
13:18 < shoghicp> :)
13:18 < shoghicp> do you have a better name for it?
13:18 < gurun> yes .. coders headache bytes :-)
13:20 < shoghicp> I'm bad at writing documentation by hand
13:20 < gurun> but to be serious, yes it is an unsigned int 24 type
13:20 < shoghicp> but well, at least the code is easy to read and follow
13:20 < shoghicp> yep
13:20 < gurun> in my code it is called UInt24
13:20 < gurun> or .. "dwarf"
13:21 < shoghicp> I did not like readInt24() :P
13:21 < gurun> it's long short and dwarf
13:21 < gurun> maybe littleLong
13:21 < gurun> or biggerShort
13:21 < gurun> or ratherLong .. hehe
13:22 < gurun> I will name it a "little"
13:23 < shoghicp> I'll use triad :)
13:23 < gurun> yeah :-.)
13:23 < gurun> and so does the Java guys. Shit, that code almost looks auto-translated. I guess it helps them fix the bugs .. they just have to merge your changes :)
13:23 < shoghicp> haha
13:24 < shoghicp> someone asked for a PHP -> Java translator before :P
13:24 < gurun> of course :-)
13:25 < gurun> so.. what about this wierd 0x10 package. It's now hardcoded in every implementation so far.
13:25 < gurun> I can't live with that :-)
13:25 < shoghicp> those session values are like random tokens for the handshake
13:25 < shoghicp> server uses some time value
13:26 < shoghicp> but it gave us problems, and that being hardcoded works
13:26 < gurun> server has this typedef for these things ..  unsigned char UniqueIDType, unsigned short SystemIndex
13:26 < shoghicp> if you can understand and document that better, it would be nice :)
13:27 < gurun> well . .. it's labeled as a non RakNet message. And it absolutely doesn't fit the message they send out (which we never see of course). So I'm kind of thinking that it is all wrong.
13:27 < gurun> but then again, that hardcoded message is based on reality, which says otherwise.
13:27 < gurun> it's just strange that MCPE would do that message completely on their own, bypassing RakNet in the middle of things.
13:28 < gurun> but the client seems extremely picky about it.
13:28 < shoghicp> MCPE doesn't have those packets around
13:28 < shoghicp> MCPE protocol starts with LoginPacket (0x82, I think)
13:28 < shoghicp> from there everything is easy :D
13:29 < gurun> yeah, ok. So you are also saying that it should be vanilla RakNet?
13:29 < shoghicp> yes, but it was hard to find things around in that code
13:29 < gurun> in that case, i will actually try with the real message structure they propose. My problem when testing it was that i switch the short in the frame, so i couldn't get anything through.
13:29 < gurun> and then i went to sleep.
13:29 < shoghicp> found thinks, so I changed "unknown" and "unknown2" to "session" and "session2"
13:29 < shoghicp> things*
13:30 < gurun> (that code is a nightmare)
13:30 < shoghicp> it is
13:30 < shoghicp> and crashes like crazy
13:30 < gurun> the sessions looks like the client-index they use to keep "players" appart.
13:30 < gurun> the thing they call .. system index i think.
13:30 < shoghicp> also, remember that there can be partial packets sent
13:30 < shoghicp> I mean, partial bytes
13:31 < gurun> yeah. I haven't started on that.
13:31 < gurun> you mean, like getting fragmented deliveries.
13:31 < shoghicp> so if you see a length of 32 + 1 bits, for example
13:31 < shoghicp> don't be woried :)
13:31 < shoghicp> no, those are split packets
13:31 < gurun> and also i guess, the reverse, depending on what sockets API you have, can get several byte buffers in one.
13:31 < shoghicp> I mean things like SetTimePacket
13:31 < gurun> hmm .. ok, what do you mean then?
13:31 < shoghicp> that sends a single bit at the end
13:32 < gurun> oh, ok.
13:32 < gurun> like the CCTimeType
13:32 < shoghicp> it's just a flag to tell if the time is stopped
13:33 < shoghicp> I'll be back soon, going to eat something :)
13:33 < gurun> haha, so when time stops, my code will break .. and time will really stop!
14:03 < shoghicp> gurun: MCPE will break
14:03 < shoghicp> if you don't send that extra bit
14:04 < shoghicp> it's read from an undefined offset
14:04 < shoghicp> anything can be there
14:04 < shoghicp> TL;DR: crazy time/night cycles
14:04 < shoghicp> same with player movement :)
15:48 < gurun> If I send a NAK to the client (to indicate that I don't want the message). What would be the expected response to that from the client. It just keeps bombarding me with the same messages.
15:48 < gurun> (during handshake)
15:54 < shoghicp> gurun: NACK = not received, resend
15:54 < shoghicp> ACK = received
15:54 < shoghicp> it's not "I don't want it"
15:54 < shoghicp> it's "I did not get it
15:54 < shoghicp> you have to send ACK or you'll get it several times
16:00 < gurun> yeah, this is a bit tricky
16:00 < gurun> Not acknowledged can be on many levels of course.
16:00 < gurun> An ack can mean I received the message complete, will process
16:00 < gurun> it can mean I received it and processed it complete (done done)
16:01 < gurun> So the question here, since this is UDP, a missing ACK will timeout, so it can't be a transport NAK i send then, It has to be that sorry dude, i can't compute.
16:02 < gurun> The problem here, i'm testing robustness a bit. I am deliberatly sending a NAK in the middle of the handshake. That hangs the client.
16:02 < gurun> If i don't send an ACK, the client keeps repeating.
16:02 < gurun> If i send an ACK, the client hangs.
16:02 < gurun> (on the next message)
16:02 < gurun> but it's handshake.. and a game. I can live with not being perfect on the server.
16:03 < gurun> but as an answer to a NAK i would really not expect a resend of the same offending message.
16:03 < gurun> because that is taken care of by missing ACK resends.
16:03 < shoghicp> NACK = send me that back
16:04 < shoghicp> it's like TCP NACK
16:09 < gurun> it strikes me as a RUDP implementation.
16:10 < gurun> retransmissions, priority, windowing..
17:22 < gurun> https://github.com/NiclasOlofsson/MiNET/blob/master/src/MiNET/MiNET.Network/MCPE%20PROTOCOL.md
17:22 < gurun> Generated from code templates
17:23 < shoghicp> ACK / NACK is outside of the reliable packet itself
17:24 < shoghicp> you could use the table syntax :)
17:24 < shoghicp> | Name | Type |
17:24 < gurun> the table syntax?
17:24 < shoghicp> |:---|:---:|
17:24 < shoghicp> | count | short |
17:24 < shoghicp> etc
17:24 < gurun> Ah, you mean for the actual content.
17:25 < gurun> absolutely
17:25 < gurun> i just wanted to experiment. It actually works using XML comments as annotations.
17:26 < gurun> good thing. It can be generated to sort in all kinds of orders.. and automatic index etc.
17:26 < gurun> and grouped by example .. client side, server side, both sides, custom messages, internal messages, etc.
17:27 < gurun> so it could become a good specification in the end. And then can be used to generate the code itself of course.
17:27 < gurun> like i do.
18:47 < shoghicp> gurun: MCPE 0.10 beta group will be opened soon ;D
19:34 < gurun> shoghicp:Oh, really. How does that work. Who can join?
19:34 < shoghicp> anyone, it's a G+ group
19:34 < shoghicp> then you can have access to the beta channel on the Play Store
19:34 < shoghicp> (Only for Android)
19:35 < gurun> yeah, figured.
19:35 < gurun> THANK GOD i just bought my son an android then :-)
19:35 < shoghicp> the devs will give more info as needed
19:35 < shoghicp> be sure to follow @jbernhardsson and @_tomcc on Twitter
19:36 < gurun> cool
19:38 < gurun> do you have your code, so that it can concatenate a message over several datagrams?
19:39 < shoghicp> yep, split packets :)
19:39 < shoghicp> RakLib supports sending them, but not receiving them from the client
19:40 < shoghicp> never found that the client sends split packets, so it'll stay as it is for now :)
19:40 < gurun> ok. good.
19:40 < gurun> i just see a lot of support for it .. in code .. but still some pieces missing. It was the same with the Java code.
19:40 < gurun> I thought i might missed something.
19:40 < shoghicp> I just have to split it when sending it
19:41 < gurun> Actually .. i just received a 0x60 message. And that would be exactly that.
19:41 < shoghicp> after that, it's handled as a normal packet to be recovered
19:41 < shoghicp> that's different :)
19:41 < shoghicp> I send 0x50 messages
19:41 < shoghicp> 0x40 + 0x10 split packet flag
19:42 < gurun> i think i reversed the byte order on the short for MTU size. So now it thinks i can just receive tiny packages. I'm going crazy about that.
19:45 < gurun> ok. and when you split the package. Can you also read incoming splits?
19:45 < shoghicp> hmm... read incoming splits?
19:45 < gurun> or, hmm .. yes. Splits.
19:46 < gurun> when you receive a split message, it wouild come over several datagrams (1500 size).
19:46 < shoghicp> yeah
19:46 < shoghicp> well, the size depends on the client
19:46 < shoghicp> 3G players have a shitty MTU :P
19:46 < shoghicp> test your code with added packet loss and low MTU
19:47 < shoghicp> i tested it using 80% packet loss and a made MTU of 300
19:47 < shoghicp> works :D
19:49 < gurun> yeah, but look at this. I don't know what it means .. {0x84,0x01,0x00,0x00,0x60,0x02,0xf0,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x13 .........
19:49 < gurun> it's a 0x13 message .. as expected.
19:49 < gurun> but after it .. i receive a lot of other messages too, smaller.
19:51 < gurun> the next in order i get (not sent anything between other than ack) is this .. {0x84,0x02,0x00,0x00,0x00,0x00,0x48,0x00,0x00,0x00,0x00,0x00,0x00,0x08,0x5c,0xd5,}
19:53 < shoghicp> you'll get 0x00 and 0x03 messages :)
19:53 < shoghicp> they are something like PING PONG
19:53 < gurun> yeah .. i know what you mean ..
19:53 < gurun> so is that what it is doing .. it's just keeping warm while waiting or something?
19:54 < shoghicp> it's something to keep alive the connection
19:54 < shoghicp> 10 seconds without packets, and the connection is closed
19:54 < gurun> {0x84,0x03,0x00,0x00,0x40,0x00,0xb0,0x02,0x00,0x00,0x82,0x00,0x05,0x50,0x61,0x70,0x70,0x61,0x00,0x00,0x00,0x12,0x00,0x00,0x00,0x12,0xbe,0xa8,0x93,0x90,0x00,0x00,}
19:54 < shoghicp> well, PocketMine sends at least one packet per 6 seconds
19:55 < shoghicp> login packet?
19:55 < shoghicp> yeah, it is
19:55 < shoghicp> https://github.com/PocketMine/PocketMine-MP/blob/master/src/pocketmine/network/protocol/LoginPacket.php
19:56 < shoghicp> 0x82
19:56 < gurun> yeah, ok. I will parse the login then. I didn't go ahead since i started getting all that kind of stuff.
19:56 < gurun> shit. Now i see my misstake.
19:56 < shoghicp> I worked a lot with the RakLib protocol, I can decode them directly when looking at them xD
19:56 < shoghicp> RakNet*
19:56 < gurun> it is S->C and then folllowed by C->S & C->S
19:57 < gurun> i'm way too much into request response in my head.
19:57 < gurun> thanks. that helped.
19:57 < gurun> Yeah, you tend to get used to them, right :-)
19:57 < gurun> i'm fairly good with the 0x40 :-)
19:58 < gurun> but now that i have some better printing of the bytes, it makes things soo much easier too.
19:58 < gurun> I print the data-hearer too. So I know.
20:01 < gurun> Packet data header: {True,False,False,False,False,True,False,False,} Data Type: ID_NEW_INCOMING_CONNECTION
20:01 < shoghicp> gurun: If you want to see the raw packets sent by PocketMine, in order,
20:01 < shoghicp> when a client joins
20:02 < shoghicp> you can use the PacketLogger plugin :)
20:02 < shoghicp> it'll write packet logs in raw & decoded form
20:02 < shoghicp> so you can see the order and the info to send without looking at the code
20:02 < shoghicp> http://forums.pocketmine.net/plugins/packetlogger.716/
20:20 < gurun> is it a normal sniffer?
20:20 < gurun> like wireshark?
20:20 < gurun> or specific for MC?
20:22 < shoghicp> gurun: produces something like this: https://gist.github.com/shoghicp/77603334886de5a9ffbd
20:22 < shoghicp> (FullChunkPackets were removed from there, they take too much space)
20:23 < shoghicp> oh
20:23 < shoghicp> nope
20:23 < shoghicp> they are there
20:24 < shoghicp> you can choose the selector and filter options on the plugin settings :)
20:27 < gurun> I see. very good.
20:27 < gurun> .NET actually have that nativily on the sockets. It's just a matter of enabling it. BUT you of course don't get any sensible package types and things.
20:28 < gurun> but keep that one up for a while will you. So i can check with what I send out.
20:28 < gurun> .. i'm just getting to the login-package as you could see earlier :-)
20:29 < gurun> i don't have any phyton or php installed. My storm expired too :-(
20:32 < shoghicp> use the installer from the homepage, everything is installed locally
20:32 < shoghicp> won't replace anything
20:32 < shoghicp> I mean, just use it as a way to see the order of packets
20:54 < gurun> yeah, but it is very nice :-)
20:54 < gurun> I'm just looking at your trace for now. I will either download .. or build it into the server.
20:55 < shoghicp> don't look at that trace, it is a bit wrong :)
20:55 < gurun> i'm missing the C->S 0x84 DATA Ready (client spawns) event .. in your log though. Maybe obsolete. I see that it sends a set time..
20:55 < shoghicp> it's obsolete
20:56 < gurun> very good.
20:56 < shoghicp> doesn't exist in 0.9 anymore
20:56 < gurun> so, now i have all the packages for .. login.
20:56 < gurun> still running it in a unit-test .. i think that is called TDD right :-)
21:07 < Aragas> http://wiki.vg/SMP_Map_Format , is Data section actual? Or somethin' changed?
21:16 < angal> BlockID now 2 bytes.
21:18 <+SpaceManiac> the Chunk and Chunk Bulk packets on the Protocol page are up to date
21:19 < Aragas> Yes, but i mean SMP_Map_Format page
21:19 <+SpaceManiac> It is out of date, the other page is not
21:19 < Aragas> Cuz Protocol page doesn't describe ho to parse 1.8 data array
21:20 < Aragas> I'll try to read it with 2 bytes for ID
21:23 < Aragas> There is no more Add stuff, yes?
21:24 <+SpaceManiac> Right
21:25 < Aragas> Okay. What about SkyLight? No more too?
21:25 <+SpaceManiac> That's still there
21:26 < Aragas> Hm. It is true by default now?
21:26 <+SpaceManiac> It's based on the world type, I believe 
21:28 < Aragas> Strange decision
21:29 <+SpaceManiac> used in normal world, not needed in nether or end
21:29 < Aragas> Yes, but now we need monitor world type instead if one bool value
21:33 <+SpaceManiac> I updated the SMP Map Format page
21:36 < Aragas> Oh, thank you!
22:05 < gurun> shoghicp: I can't see that you implemented the connected PING/PONG. BlockServer did however do that.
22:06 < shoghicp> I did in 1.3.12, but I left that out for now in RakLib
22:06 < shoghicp> I'll use it to measure the ping between the client/server
22:06 < shoghicp> but I've to do it in a way that I like :)
22:16 < gurun> :)
22:17 < gurun> i have to figure out .. how to deal with "time". RakNet defines time as "the time since the system started, in milliseconds". What kind of a thing is that when it is the client sending the ping :-(
22:19 < gurun> also time is one of these typical things they seem to change depending on what platform the SERVER is compiled in. If it 64bit it actually sends long .. but only int if it is 32 bit .. well, in int.
22:19 < gurun> how the heck can the clients deal with that. Like "dynamic" protocol...
22:27 <+AndrewPH> gurun: that's what I call retarded design!
22:36 <+fragmer> TkTech, good news, someone at Mojang is finally redoing the website :P https://twitter.com/Bopogamel/status/514778135666368512
22:39 < dx> like metro but with screenshots instead of flat colors
22:39  * dx hides
22:40 < dx> ...well, not screenshots. it even says that there, "not even minecraft"
--- Day changed jeu. sept. 25 2014
00:28 < Dhruv0> Can someone check what is wrong with this? https://github.com/PlasmaShaft/Craft.Net/blob/master/source/Craft.Net.Server/ChunkHelper.cs
00:28 < dx> ..specifically?
00:32 < Dhruv0> dx: I have no idea, i basically spawn in a world filled with netherrack walls spaced about 5-6 blocks apart
00:33 < dx> fun!
00:33 < dx> so did this ever work?
00:40 < Dhruv0> dx: It used to (1.7), until I modified it for 1.8
00:40 < Dhruv0> also did I mention there is no ground?
00:40 < Dhruv0> You keep falling
00:40 < dx> i know that feel
00:45 < Dhruv0> dx: XD, is that common?
00:45 < dx> don't laugh :(
00:46 < Dhruv0> dx, So I'm guessing you found nothing wrong, everything I did was right, and Mojang screwed up? Happy ending :D
00:46 < dx> i didn't bother reading your code at all and i know nothing about 1.8 chunks
00:47 < Dhruv0> :P
00:47 < dx> was only asking those questions hoping there would be a shortcut to avoid reading your code (like regression testing)
00:51 < gurun> :-)
00:52 < gurun> So, going through the start-sequence, sent a startgame package over to the server. Now .. when in the communication should i be able to see "something" on the client. Like a reaction?
00:52 < gurun> startserver package FROM the server of course.
00:52 < shoghicp> status and startgame
00:52 < shoghicp> you've to send both
00:53 < gurun> ah, ok.
00:53 < gurun> or .. yes, you mean the loginstatus, right?
00:53 < shoghicp> I guess
00:53 < gurun> so, i did both.
00:53 < shoghicp> I'm going to bed now, so I can't check
00:53 < shoghicp> try logging PM packets ;D
00:54 < gurun> no, don't. I just wanted to know if I had to send all the other .. darn messages too.
00:54 < gurun> I'll connect to a server on internet and see perhaps.
00:55 < shoghicp> gurun: depends on the server, some will use the old 1.3.x branch, and others a version of 1.4
01:45 < gurun> i just need a 0,9.5a server anywhere. Not a problem.
04:15 < woder> what packet is used when you wack another entity with your fist? (client => server)
04:19 <+SpaceManiac> Use Entity (0x02)
04:19 < woder> ah, missed that one somehow, thanks
05:07 < woder> is that packet suppose to also do the arm swing?
05:08 <+SpaceManiac> There's a separate Animation packet
05:09 < Not-fc45> [fCraft] fragmer * r2351 2 files : Fixed yet another obscure way to reveal hidden players: We have two regular players (A and B) and a hidden player (C). A should spectate B, then B should try private-messaging C. If C is offline, A will not see anything. If C is online and hidden, A would've seen the PM being sent.
05:12 < Not-fc45> [fCraft] fragmer * r2352 2 files : Fixed libMonoPosix check being done too late in InitLibrary (after a GZipStream has already been used), resulting in unsavory exception messages thrown.
05:19 <+fragmer> [fCraft] fragmer * r2351 2 files : Fixed yet another obscure way to reveal hidden players: We have two regular players (A and B) and a hidden player (C). A should spectate B, then B should try private-messaging C. If C is offline, A will not see anything. If C is online and hidden, A would've seen the PM being sent.
05:19 <+fragmer> oops
05:19 <+fragmer> wrong channel
05:48 < Not-fc45> [Glowstone] SpaceManiac pushed 1 commit [+16/-0/±2] http://git.io/ZM3O-Q
05:48 < Not-fc45> [Glowstone] greatman 58e3bf0 - Implemented 1.8 codecs and add 1 to max packet in GlowProtocol.
17:27 < TkTech> fragmer: Tears, tears of joy and sadness.
17:30 < TkTech> fragmer: Hah, manually Notifico-ing for Esper?
18:14 < Aragas> I'm havin' really weird Position coordinates from Block Change packet
18:15 < Aragas> We read Position as long, then decode it, right?
18:17 < Aragas> X: -1048573, Y: -448, Z: 249 , lol
18:27 < nyuszika7h> -1048573 sounds like an overflow, Aragas 
18:29 < nyuszika7h> or maybe not, unless there's some weird integer type with those bounds
18:29 < nyuszika7h> s/those bounds/that lower bound/
18:30 < Aragas> nyuszika7h: Thinkin' about it too, but i *think* it's impossible, i get packet length, read them as byte array, then read stuff from array. I mean, it is not a reading error...i hope. Reading Position as always, but gettin' this. Weeeeird
21:29 < TkTech> There will be wiki downtime sometime between 2 and 8AM UTC for both the wiki and the database cluster (this affects notifico and other projects as well)
21:29 < TkTech> Amazon AWS is rolling out a fix for an undisclosed Xen exploit at this time
21:31 < shoghicp> D:
--- Day changed ven. sept. 26 2014
01:51 < benbaptist> Is there some trick to removing users from the Player List after they leave? 0x38 with REMOVE_PLAYER seems to disconnect the client with an error
01:52 < benbaptist> and the server never seems to send that anyways, does it use a different packet?
01:53 < benbaptist> actually, wait. something strange is going with my code, so the server probably is sending a REMOVE_PLAYER after all.
15:02 < gurun> Is Herobrine real? uh .. yes, and he is me?!
15:02 < gurun> What the heck is the answer?
15:04 < dx> u wot
15:05 < gurun> "Having trouble with the registration question? Come ask us in our IRC channel"
15:05 < gurun> i have problem with the registration question.. uhh.
15:05 < dx> ..have you tried answering "no"?
15:06 < gurun> yes .. and since .. well, it's programmers .. so i tried "false", "true", "no", "NO", "YES", "yes", "false=true" (since it is a myth)
15:07 < gurun> it seems to be some sort of intelligence test. Now it asks me the name of a person I have no clue who it is..
15:08 < dx> notch?
15:08 < gurun> "Markus "____" Perrson" .. i guess that is a misspelling of the swedish name Persson".
15:08 < dx> notch
15:09 < gurun> It
15:09 < gurun> it's not a captcha .. it's a gotcha
15:09 < dx> spoilers: it's the name of the guy who wrote minecraft
15:09 < dx> you're supposed to know that
15:10 < gurun> well .. in sweden we have something called "jante lagen". We don't approve of successful people, hence we make sure they are not remebered.
15:10 < dx> ...
15:10 < dx> anyway did you get pass the captcha?
15:11 < dx> *past
15:11 < gurun> no
15:11 < gurun> i'm back on the first question again now.. Is Herobrine real?
15:11 < dx> do you have cookies disabled, noscript, tor?
15:11 < gurun> nope
15:12 < dx> >Welcome, Asdasd! Your account has been created
15:12 < dx> welp
15:12 < gurun> what
15:12 < gurun> changing browser.. to test
15:13 < dx> TkTech: please delete user "asdasd"
15:13 < gurun> Hmm
15:13 < gurun> It didn't work on that browser either.
15:14 < gurun> nope didn't work on that either.
15:14 < gurun> maybe it's not the code that is the problem .. and the error message is actually wrong.
15:15 < gurun> Incorrect or missing confirmation code.
15:16 < gurun> nope :-(
15:18 < gurun> http://sveinbjorn.org/cgi-bin/cookie-check.pl
15:18 < gurun> You have cookies ENABLED
15:18 < gurun> just to .. check
15:20 < gurun> And here I am thinking that chunk-management was the difficult part of MC coding...
15:21 < gurun> User account "Gurun" is not registered. So that's not it either.
15:25 < gurun> dx:Can you create the account in my name and message me the password? To see if I can even login.
15:25 < dx> eh
15:26 < gurun> i mean .. just create a new account "gurun" and set the password to some shit .. and I'll try to see if i can login.
15:26 < dx> dammit, i typoed your name
15:26 < dx> wrote gurum instead of gurun
15:26 < gurun> hehe
15:28 < dx> TkTech: also delete user "gurum" (the correct one ends with n)
15:28 < gurun> YES, worked. Thanks a lot dx.
15:28 < dx> gurun: obviously change that awful password
15:29 < gurun> and change of password .. worked just fine too.
15:29 < gurun> maybe something with the encoding .. or something..
15:45 <+fragmer> TkTech: yep, manual notificing :P
15:46 < dx> so what happened with notifico exactly?
15:46 <+fragmer> EsperNet IRC network and Notifico do not get along, for some reason.
15:46 <+fragmer> Every once in a while the bots stop announcing there
15:47 < dx> that's... vague
15:47 < dx> and TkTech doesn't know why, either?
15:47 <+fragmer> I'm afraid I only know the symptoms, not the causes.
15:48 < dx> TkTech: TELL US EVERYTHING
15:52 < SinZ> notifico is allergic to netsplits
15:53 < SinZ> and esper likes getting ddos'd for some reason
15:55  * TkTech is a sad tktech
21:01 < Dhruv0> Ok, attempt 7 at ChunkData
21:02 < Dhruv0> BlockData length is Section.Width * Section.Height * Section.Depth?
23:07 < Not-c9f2> [Glowstone] SpaceManiac pushed 1 commit [+0/-0/±2] http://git.io/OsvlmA
23:08 < Not-c9f2> [Glowstone] jimmikaelkael ed97e68 - Added Eclipse and IDEA gradle plugins and title-cased project name.
23:11 < Not-c9f2> [Glowstone] SpaceManiac pushed 1 commit [+0/-0/±1] http://git.io/HpvIpA
23:11 < Not-c9f2> [Glowstone] SpaceManiac 1fa24a7 - Reverted project name change for now.
23:29 < Aragas> Dhruv0: BlockData = (Section.Width * Section.Height * Section.Depth * 2), in BlockLight and SkyLight divide by 2 instead of multiply
23:31 < Dhruv0> Aragas: Uhh, I was already dividing by 2 O-o
23:32 < Aragas> Successfully implementing Chunk Data reading, i'll upload read part in gist, i'm bad with explanations
23:32 < Dhruv0> Aragas: Thanks
23:36 < Aragas> Dhruv0: https://gist.github.com/Aragas/014213d4bc0dc015002d
23:36 < Dhruv0> Ty
23:37 < Aragas> Pleasure to help
23:37 < Dhruv0> Aragas: May I know the value of TwoByteData?
23:37 < Aragas> o, pardon me
23:38 < Aragas>  (Section.Width * Section.Height * Section.Depth * 2)
23:38 < Aragas> Half is  (Section.Width * Section.Height * Section.Depth / 2)
23:38 < Dhruv0> Ah I see
23:39 < Aragas> Some call HalfByte as NibbleArray
23:41 < Dhruv0> Aragas: In 1.8, was the blockdata not changed to a short array?
23:42 < Aragas> Dhruvo: Technically, it can be a char array too. It contains 2 bytes for a value, if i remember correctly
23:43 < Aragas> I don't remember correct, but using Array.Copy with short array is a bad idea, just use another method to convert whole array. It's simple
23:44 < Dhruv0> Yea, I've created a method to convert the array
23:45 < Aragas> I think it's better with byte array, looks more...organic?
23:45 < Dhruv0> Aragas: I guess so
23:46 < Aragas> Dhruv0: Wanna say, i think a have almost done most of the basic-for-work stuff, write me if you have questions
23:46 < Dhruv0> Ok
23:47 < Dhruv0> I'm not a networking lover as you can see
23:48 < Aragas> I see that you are porting Craft.Net to 1.8, what is really nice. I'm too soft to work with it, but you can adapt my stuff to it
23:50 < Aragas> You can also make Issues, that works for me too
23:50 < Dhruv0> Mkm
--- Day changed sam. sept. 27 2014
01:05 < SupaHam> What does the byte array header for a packet need to be?
01:06 < SupaHam> when I do the byte array's length, that isn't enough some times, it kicks the client
01:12 <+SirCmpwn> there are python devs here, right
01:13 < barneygale> yes
01:13 <+SirCmpwn> wanna add another project to your plate?
01:13 < barneygale> probably not but what is it?
01:14 <+SirCmpwn> a few python projects starting up in the KnightOS world
01:14 <+SirCmpwn> SDK and package repository, for two
01:14 <+SirCmpwn> ideally trying to find someone who likes python *and* windows, but those people are rare
01:14 < barneygale> KnightOS An open source OS for TI calculators
01:14 <+SirCmpwn> no one has the knowledge to help make anything work on windows :<
01:15 < barneygale> m$ winblowz
01:15 < barneygale> i think you mean
01:15  * SirCmpwn scratches barneygale's name off the list
01:15 < barneygale> ;D
01:15 < Dhruv0> XD
01:16 < Dhruv0> KnightOS programs may use 31K of RAM. TI-OS offers 24K under ideal conditions
01:17 < barneygale> you'd have to generate the world on the fly
01:17 <+SirCmpwn> all of our python devs are using linux or osx, I'm afraid
01:17 < barneygale> using something inexpensive
01:18 <+AndrewPH> I use windows 
01:18 <+SirCmpwn> and like python?
01:18 <+AndrewPH> I do the python
01:18 <+SirCmpwn> bonus points for knowing how to do native dev?
01:18 <+AndrewPH> what do you mean by 'native dev' - writing python that works on windows? or writing c extensions?
01:19 <+SirCmpwn> being able to write an installer for dumb people that installs msys and certain native bits of the KnightOS toolchain for you, in addition to the python bits of the SDK
01:19 <+AndrewPH> oh lol no idea
01:19 <+SirCmpwn> yeah, none of us have a clue either :P
01:20 <+AndrewPH> do you mean like a graphical installer?
01:20 <+SirCmpwn> yeah
01:20 <+AndrewPH> yep no experience there
01:27 < winny> SirCmpwn: knightOS runs python?
01:27 <+SirCmpwn> no, but the things around it do
01:28 <+SirCmpwn> documentation generation, the SDK, and the package repository
01:28 < winny> okay
01:28 < winny> oh cool runs on the ti-84 plus c silver edition (color)
01:28 <+SirCmpwn> poorly
01:29 <+SirCmpwn> can't get the damn Flash driver to work and switching between color and legacy mode is buggy
01:29 < winny> I have that model
01:29 < benbaptist> I don't have much experience with installers on Windows, though I sort've know how to use py2exe :P
01:29 < winny> TI-BASIC leaves a lot to desire
01:29 <+SirCmpwn> kpy is in the works, winny 
01:30 < winny> how hard is to to set up a working toolchain for a compiled language?
01:30 <+SirCmpwn> I don't understand your question
01:30 <+SirCmpwn> like how hard is it to install a C compiler?
01:31 < winny> yes that builds programs to run on the ootb OS
01:31 <+SirCmpwn> right now it's somewhat difficult
01:31 <+SirCmpwn> but we're working on the SDK to make it a lot easier
01:36 <+SirCmpwn> winny: https://mediacru.sh/-WIeDCfFWjU4
02:00 < dx> SirCmpwn: i've dealt with py2exe / NSIS a few years ago. rather unpleasant. would not do again
02:00 <+SirCmpwn> what if I smiled at you and asked nicely
02:01 < dx> hahah
02:01 < dx> i'd link the stuff i did but it's probably in a SVN repo in sourceforge
02:01 <+SirCmpwn> I don't think py2exe would be involved here, though
02:01 <+SirCmpwn> probably just some bootstrapper needed to call the python stuff
02:01 < dx> well if you don't mind asking people to install python and all the deps manually first...
02:02 <+SirCmpwn> one of the requirements is that the SDK installer does this for them :)
02:02 < dx> py2exe outputs a small .exe to launch it, a library.zip with the python stdlib + other modules, and all the DLLs ever, including stuff like python27.dll with the interpreter itself
02:03 <+SirCmpwn> that's nice
02:03 <+SirCmpwn> well, here's what would need to be ported: https://github.com/KnightOS/sdk
02:04 <+SirCmpwn> and ideally some sort of installer that also takes care of the toolchain dependencies cause I don't trust windows users to know how to compile C software
02:04 < dx> toolchain as in cross compilation stuff?
02:05 <+SirCmpwn> yes, but without the headache you'd usually think of with cross compiling
02:05 <+SirCmpwn> just make, our assembler, our emulator, and one other tool, none of which are hard to compile or use
02:07 < dx> ooh this might be a good excuse to try this thing http://www.appveyor.com/
02:07 < dx> it's like travis-ci with windows
02:07 <+SirCmpwn> can that help?
02:08 < dx> well it would take care of building that thing regularly
02:09 <+SirCmpwn> eh
02:09 <+SirCmpwn> building it in the first place is the important part
02:10 < dx> yep
02:10 < dx> well, let me find if i still have this windows VM, might have killed it to get more free space...
02:38 < dx> SirCmpwn: ok so apparently this whole sdk is a lie
02:38 < dx> the only command that works is init
02:38 < dx> and it does something very boring
02:38 < dx> i am so disappointed
02:39 <+SirCmpwn> it's not THAT boring
02:39 < dx> well, i am not entertained
02:39 <+SirCmpwn> it gets a kernel for you and sets up a brand new KnightOS project, ready to compile and run
02:39 <+SirCmpwn> try `make run`
02:39 <+SirCmpwn> it sets up a custom userspace with init and your program installed, and your program is in /etc/inittab
02:39 < dx> http://dump.dequis.org/N-93A.txt
02:40 <+SirCmpwn> wat
02:40 <+SirCmpwn> oh, you don't have the toolchain installed
02:40 < dx> ah yeah it seemed weird to me that you wanted to call a CSS preprocessor as part of the build process
02:40 <+SirCmpwn> dependencies: https://github.com/KnightOS/sass and https://github.com/KnightOS/genkfs
02:41 <+SirCmpwn> in theory the windows installer would take care of that for you, and the Linux packages will just depend on this stuff
02:41 <+SirCmpwn> and I guess we can toss something into brew for the osx users
02:41 < dx> sircmpwn's ass
02:41 <+SirCmpwn> thanks dx.
02:41 < dx> np SirCmpwn
02:42 <+SirCmpwn> the next version is called scas
02:42 <+SirCmpwn> mostly to avoid conflicts with the CSS preprocessor, but also to shut people like you up :P
02:42 < dx> :D
08:31 < Scruff> nickelpro, You there?
10:01 < MrARM|away> K-Lined? :o
10:01 < SinZ> its like gline, but K
10:01 < SinZ> but its just irccloud being banned, no biggy
10:02 < MrARM> yeah, wondering why
10:03 < shoghicp> they had some issues with their servers
10:03 < shoghicp> and had to restart
10:03 < SinZ> ^
10:03 < shoghicp> https://twitter.com/IRCCloud
10:07 < MrARM> restart via free node? :o
10:50 < Not-c9f2> [Glowstone] SpaceManiac pushed 1 commit [+0/-0/±3] http://git.io/L4LHYQ
10:50 < Not-c9f2> [Glowstone] SpaceManiac 5d54121 - Improved tree support and fixed lack of tree generation (fixes #101).
12:07 < Aragas> About that Block Change Packet error, where i have Position reading error If someone is interested, i can give full byte array dump
12:19 < Aragas> Nevermind. This error was caused because position reading in wiki isn't correct
18:21 < Bored> Hi, does anyone have much MineFlayer experience ? 
18:27 < dx> who knows. if you ask a more specific question you might get help.
18:32 < Bored> So looking at the MineFlayer examples they all seem to do stuff based of receiving chat messages, the issue is these chat messages are never being recieved because its switching on the translate i.e. chat.type.text however a standard "hello" message doesn't seem to have a translate property.
18:33 < Bored> Using Latest node-mc-protocol and mineflayer packages. server is spigot 1.7.10 r0.1
21:23 < Aragas> Is Record bitmask in http://wiki.vg/Protocol#Multi_Block_Change correct? I cant read it. Can someone help me? I can just get Y value - 'Y = coordinates & 0xFF'
21:23 <+SpaceManiac> it's a little tricky because ? makes it seem like it's some error
21:24 <+SpaceManiac> it's a short, with those bitmask values; followed by a varint that's the block id
21:24 < Aragas> yes, i read a short, then a varint
21:24 < Aragas> coordinates is a short
21:25 < Aragas> I'm strying to read it some like 2 hours now
21:25 <+SpaceManiac> z = (coord >> 8) & 0xf; x = (coord >> 12) & 0xf;
21:25 < Aragas> If it is so easy, i'm gonna rage
21:26 < Aragas> WHY
21:26 < Aragas> WHY IT WORKED
21:27 < Aragas> Thank you, SpaceManiac!
21:28 <+SpaceManiac> No problem :P
21:29 < Aragas> Why you didn't decode this packet in Glowstone?
21:29 <+SpaceManiac> It's a clientbound packet only, so I saved some effort by only writing encode
21:30 <+SpaceManiac> Since the server will never need to decode
22:33 < Dhruv0> In PlayerListItem, what does it mean by "The following fields are repeated length times" for the length?
22:41 <+SpaceManiac> the fields after 'length' are repeated that number of times
23:35 < Dhruv0> What packet sets the player skin? My guess is Spawn Player
23:36 < jython234> i think the client gets it from mojang servers
23:36 <+SpaceManiac> the skin is sent along with Player List Item
23:40 < Dhruv0> SpaceManiac, even in offline mode?
23:40 <+SpaceManiac> don't know about offline mode
23:40 <+SpaceManiac> probably not.
23:41 < Dhruv0> That's most likely my problem
23:41 < Dhruv0> I'm sending a UUID v3
23:42 < Dhruv0> I guess I should be sending a UUId v1
23:42 < Dhruv0> UUID*
--- Day changed dim. sept. 28 2014
00:40 < Dhruv0> SpaceManiac: What field in Player List Item controls skins? And does value have to be sent as a base64 string?
03:43 < Not-c9f2> [fCraft] fragmer * r2353 4 files : MapRenderer: Changed the way "--overwrite" parameter works: user can now choose when to overwrite existing image files: Never, Ask (default), IfNewer, or Always. Also removed "-d" as shorthand for rarely-used "--tryhard" parameter.
04:04 < Not-c9f2> [fCraft] fragmer * r2354 208 files : Brought fCraft code's whitespace/newline conventions closer to Microsoft-recommended ones.
07:30 < Not-c9f2> [Glowstone] SpaceManiac pushed 2 commits [+0/-0/±4] http://git.io/_88cmQ
07:30 < Not-c9f2> [Glowstone] SpaceManiac edb096f - Fixed outer skin layers not appearing (fixes #162).
07:30 < Not-c9f2> [Glowstone] mastercoms 2690d3f - Fixed swords stopping digging in Survival mode (fixes #349).
10:57 < SopaXorzTaker> hey!
10:57 < SopaXorzTaker> does anyone have a Minecraft Classic map?
10:57 < SopaXorzTaker> empty one
12:59 < Not-c9f2> [fNbt] fragmer pushed 1 commit to master [+0/-0/±2] http://git.io/libUZg
12:59 < Not-c9f2> [fNbt] fragmer 3a8dbaa - Sped up DynamicConverter's handling of ILists quite a bit (33% faster first call, 83% faster consequent calls) by using the (dynamic) trick to make generic methods on the fly: http://stackoverflow.com/a/13608657/383361
14:33 < Aragas> I need to get Block Position by knowing Chunk 2D Coordinates, Section 3D Position and Section Y. Has someone done that before?
14:35 < jython234[2]> It's called x y z
14:36 < Aragas> Yes, i mean x y z
14:37 < Aragas> Just wanna know, if there is some complete code
14:38 < jython234[2]> I don't get it, what are you using? Bukkit?
14:39 < Aragas> My own project
14:39 < Aragas> On C#
14:40 < jython234[2]> You have to code it yourself
14:40 < jython234[2]> I'm not sure how you handle world storage
14:40 < gurun> Do you mean that give
14:41 < gurun> ...given section position you want the world coordinates
14:41 < gurun> Of the block!
14:41 < jython234[2]> Yes
14:42 < jython234[2]> Oh wait wrong chat :/
14:42 < Aragas> I don't get it. There is no difference of how i handle world. Section Coordinates, Chunk Coordinates and Block Coordinates are same as vanilla
14:42 < gurun> Yeah, just different resolution, kind of.
14:43 < Aragas> I have Section position, Y of Section in Chunk and Chunk position
14:43 < Aragas> Y of section i mean 1-16
15:33 < Bibl> the best
15:33 < Bibl> ^
17:36 < Grum> Aragas_: that is how minecraft is internal as well
17:37 < Aragas_> ?
17:37 < Grum> everything is stored in 16x16x16
17:37 < Aragas_> A, yes
17:37 < Aragas_> I have already done it
17:37 < Grum> what people call 'chunks' is actually a chunk-column
17:37 < gurun> With the small difference between 128 and 256 on Y, right.
17:38 < Grum> well those are either 8 or 16 chunks high
17:38 < Aragas_> Dudes, i just have done full Anvil structure :DDD
17:38 < gurun> Genau.
17:39 < Grum> whooo time to change it again then
17:39 < gurun> Aragas_: if you don't mind me asking. Why not use Craft.Net?
17:40 < Aragas_> Most thinks are not anymore up-to-date, and i don't fully like it structure
17:41 < Aragas_> I'm doin; my own project, with blackjack and errors
17:42 < gurun> Is the target PC or PE?
17:42 < Aragas_> PC
17:42 < gurun> Ok.
17:43 < Aragas_> PE is interesing too, but it's too hard to implement both reading in one library
17:44 < gurun> I'm working on the PE server. https://github.com/NiclasOlofsson/MiNET I use some of the libraries from Craft.Net and they are rather ok. I am however checking the code before I use it.
17:46 < Aragas_> I'm not a very skilled coder, so, for me, it's better to do my own implementation, plus i don't always correct read its code (C.N.)
17:51 < rom1504> Aragas_: well if you're not a very skilled coder you should indeed use a library instead of doing everything yourself
17:52 < Aragas_> We don't have up-to-date library
17:52 < Aragas_> so i'm doing in myself
17:52 < rom1504> so you think you'd better start from scratch and make one ?
17:52 < Grum> craft net code is not really 'the best code' from what i've seen :/
17:53 < rom1504> might be an interesting goal to do it right yourself, but it's definitely not easier
17:53 < Grum> then again. neither is mc's code =)
17:53 < Flemmard> what is the problem with him making himself the code?
17:53 < Aragas_> yes, i thing so. My library works nice
17:53 < Flemmard> that's the best way to learn how shit works
17:53 < Flemmard> (or doesnt)
17:54 < Aragas_> Thanks
17:54 < SinZ> rom1504: it probably is better to atleast attempting to make your own so that even if you fail, you know more about the internals of mc networking, and could assist in using other libraries
17:54 < Flemmard> yep
17:55 < Flemmard> +1
17:55 < Aragas_> yes. Thanks for that, i understand how it's work
17:56 < rom1504> that depends entirely on your goal, if you want to understand minecraft protocol, it's better to redo everything yeah
17:56 < rom1504> if you just want to make a client or a server then you'd better use a lib
17:56 < Grum> the protocol is rather uninteresting
17:56 < Aragas_> Libs are not always the best
17:57 < Flemmard> one generally doesnt make a client just to make a client, afaik
17:57 < Aragas_> I'm doin' it just for lulz, and skillz :DDD
17:58 < SinZ> I learnt how to do socket networking from implementing a minecraft client
17:58 < rom1504> no, for example you can make a bot (which is a client) to do interesting things in AI
17:58 < SinZ> granted, this was before encryption and stuff
17:58 < rom1504> well ofc you need the lower things to work before that
17:59 < rom1504> but yeah if you want to learn network stuff then it's probably better to do it from scratch
17:59 < Grum> or start with a simpler protocol :p
17:59 < Flemmard> i learnt networking by doing IRC things
17:59 < Flemmard> bots, servers, ..
18:00 < Flemmard> protocol is a bit easier :D
18:01 < rom1504> yeah, but an irc bot can have a limited set of action (talking, joining chan, maybe kicking people)
18:01 < rom1504> but the protocol is easy yes
18:02 < Flemmard> yeah, unless you do a bot that connects to an irc server like another server :P it's a bit funnier then
18:02 < gurun> Yeah, just for the record; I didn't mean to imply that no one should do their own code. It was just a friendly pointer in the case Aragas_ didn't look at the craft.net project.
18:03 < Aragas_> I look, i take ideas from it
18:03 < Grum> thieflings
18:03 < gurun> And I'm not affiliated with that project either. I just abuse it when I need it :-)
18:04 < Aragas_> I don't think that any library can have dominate positions
18:04 < gurun> Well, I think the .NET framework for starters, is pretty dominant :-)
18:05 < Aragas_> At leas we have mono :DDD
18:05 < Grum> if you do not want to be crossplatform maybe
18:05 < gurun> Mono -> MS sponsored.
18:05 < SinZ> it works on mono
18:05 < SinZ> (needed some extra code too for it)
18:06 < gurun> Craft.Net as an example runs on mono. At least they claim that.
18:06 < Aragas_> Minecraft doesn't have code, that can't be implemented on mono
18:06 < SinZ> it found a bug in mono where they do AES encryption weirdly or something
18:07 < gurun> But running on Mono is of no interest to me. If you want a good server for MCPE for that, I would suggest MP instead.
18:07 < Aragas_> That why we use BouncyCastle
18:07 < Grum> actually minecraft doesn't use bouncycastle
18:07 < Aragas_> I mean C# projects
18:08 < Aragas_> Because mono have bugs with crypto stuff
20:30 < lucysan> Hi all
20:30 < lucysan> I'm trying to do some modding on raw minecraft server
20:30 < lucysan> (adding login and password like xAuth to be exact)
20:30 < lucysan> any tips where to start or where server entry point is? 
20:32 <+sadimusi> we will not help you circumvent player authentication
20:33 < lucysan> Well, i'm not tryint to do an offline server
20:33 < lucysan> *ing
20:34 < lucysan> But singe bukkit is down due to DMCA I can't get it
20:34 < lucysan> and I'm stuch with Spiggot (which is buggy as hell)
20:35 < lucysan> so since my only plugin is xAuth (had some problems with "my brother griefing") i thought i might reimplement it in vanilla
20:39 < lucysan> NVM fount it. net.miencraft.server.dedicated.DedicatedServer
20:47 < angal> I'm server. Client:Vanilla. When i use 0x26 Map Chunk Bulk, is there are some order, to send chunks? Couse chunks only loads, when i send - 0|0, then 0|-1, then, -1|0, then -1|-1. Is this normal?
21:18 < lucysan> is there any  javadoc for 1.7.10 (server)?
21:21 < dx> lol
21:36 < Aragas_> So, my console implementation of my library use 100mb, with world data saving. And about 30mb without saving
21:37 < MrARM> it can't. I think you meant kb... 
21:39 < Aragas_> It's a full client. Make a graphic wrapper and you'll see a game
21:39 < Aragas_> It can use not so many memory, but then you'll need to manually switch off handling of packeys, that you don't use
21:40 < gurun> Still... Kb right