14:15 < MrARM> nvm fixed --- Day changed sam. janv. 04 2014 12:10 < MrARM> How can I know is my client dead when joining??? 12:12 < MrARM> nvm found it 14:19 < MrARM> I have to send a Client Status with Action ID 0 after JOIN GAME? 14:20 < MrARM> I think yes 14:24 < MrARM> Still isn't gonna send me Health Update :( 14:30 < HeavyBoss> hey anyone knows why a mapcanvas use so much server ram? 14:31 < HeavyBoss> sorry for my bad english 14:36 < HeavyBoss> no ideas? 15:03 < MrARM> Is that packet sending good for a client? Handshake-> Login Start (receives login success, then join game) -> Client Status (receives spawn position) -> Starts sending Player packet every 50ms -> Player Position and look -> (receives abilities, held item, statistics. ..) 15:03 < MrARM> It's still not sending me a health change packet :( 15:16 < MrARM> nvm found out that you can't send Player packet but Player Position 15:48 < HeavyBoss> anyone knows why a map canvas with images uses a lot of server usage? 18:13 < MrARM> ding dong ding dong ding dong ding dong ding... 18:13 < MrARM> oops 18:13 < MrARM> wrong channel 18:57 < umby24> mrarm: it may be related to your player position and look packets. If they are incorrectly sent, the server will not send you health updates. 19:16 < MrARM> I said I fixed it 19:17 < MrARM> It had to be player position or plater position+rotation packet, not just player packet 19:18 < MrARM> I wonder for what the Player packet is used 19:18 < MrARM> (on notchain client) 19:19 < MrARM> sending it every 50ms makes no health updates 20:50 <+Amaranth> Knockback when something hits a player is handled client side, right? 20:50 <+Amaranth> I mean I know the client can refuse to move but the server doesn't even actually tell it to do so, does it? 20:50 <+Amaranth> (too lazy to go look it up) 20:54 < MrARM> 1. yes 2. ? 20:54 < MrARM> yes it can refuse 20:54 < MrARM> Tested 22:52 < barneygale> Amaranth: yes it's client-side. No-knockback is one of the most frustrating hacks, though it's pretty easy to spot. 22:53 <+Amaranth> Right so any complaints about "relogging change knockback strength" would be a client bug 23:06 <+Amaranth> Actually I'm pretty sure an attack would trigger an entity velocity packet getting sent to every player in range 23:06 <+Amaranth> Isn't that what you'd use to push the player around from the server? 23:06 <+Amaranth> That's how the code seems to read 23:08 <+Amaranth> No, nevermind, broadcast and broadcastIncludingSelf are two different methods --- Day changed dim. janv. 05 2014 08:40 < CanVox> Does anyone know what the --user_type and --user_properties params are for minecraft 1.7.4? 15:24 < Morrolan> bearbin: Nice. :) 15:24 < Morrolan> bearbin: (About case sensitivity being gone, since I'm probably a tad late with my response ;) ) 15:26 < bearbin> Yep, probably :P 16:14 < Not-002> [MCPP] RobertLeahy pushed 17 commits to 1_7_protocol [+8/-1/±27] http://git.io/x2pSiw 16:15 < Not-002> [MCPP] RobertLeahy a6c2f7a - Remove /log 16:15 < Not-002> [MCPP] RobertLeahy d2ad001 - Remove Op/Deop Commands from Makefile 16:15 < Not-002> [MCPP] RobertLeahy fa5a0ce - info.hpp Missing Include 16:15 < Not-002> [MCPP] ... and 14 more commits. 17:58 < roblabla> Hello. I am trying to validate the session from a client, is the mojang sessionserver supposed to give me a 204 No Content when the authentication failed ? 17:59 < roblabla> (E.G., GET request to https://sessionserver.mojang.com/session/minecraft/hasJoined?username=lalala&serverId=38aaa7f0ffb3e6cb2b7fe89321aef5cfae0f480b , bogus username, gives me 204, do I take it as an "invalid session" ?) 18:12 <+sadimusi> roblabla: yes, that's what happens when the session is invalid 18:12 <+sadimusi> otherwise you get a json string back 18:13 < roblabla> mkay 18:13 < roblabla> I'm obviously not going to ask why doesn't it reply with a 40x error code >.> 18:14 <+sadimusi> because mojang :D 18:14 < roblabla> >.< 18:16 < roblabla> yay, my test suite now passes. Thx. 18:16 <+sadimusi> I'm even more intrigued by the error message on http://session.minecraft.net/game/checkserver.jsp 18:20 < MrARM> Player position packet (sent by client) actually want double or fixed point number 18:20 < MrARM> ? 18:20 < roblabla> sadimusi: lol 18:20 < roblabla> Mojang's WIP 18:21 < MrARM> Anyway I am pretty much interested why adding 0.01 to a double makes a very strange number oO 18:21 < roblabla> MrARM: that's due to the floating point specification 18:22 < roblabla> computers don't store floats like we do, with a dot at X position 18:22 < roblabla> http://en.wikipedia.org/wiki/Double-precision_floating-point_format 18:22 < MrARM> but anyway somehow MCPC server doesn't want to hear about my position 18:22 < MrARM> I just x-0.01 my position every tick 18:23 < MrARM> It rejects it 18:23 < roblabla> Does vanilla mc server like it ? 18:23 < MrARM> no 18:23 < MrARM> I am testing everything on vanilla 1.7.4 server 18:24 < MrARM> There is nothing in its way 18:24 < roblabla> does the server try to correct your position ? 18:24 < roblabla> or does it downright ignore it 18:25 < MrARM> try to correct 18:25 < MrARM> with a delay 18:25 < MrARM> In vanilla client I see no move 18:25 < MrARM> However using the same method I can move it up 18:26 < MrARM> I have an idea right now... 18:26 < MrARM> nope, still doesn't work 18:27 < MrARM> I am sending a move+rotation packet every 50ms 18:29 < MrARM> I'll try delaying my moves a little 18:31 < MrARM> it helped! 18:31 < roblabla> by how much did you change ? 18:32 < MrARM> I delayed it in 100ms 18:32 < MrARM> I was starting too quickly. 18:40 < MrARM> Anyway why Slot doesn't have NBT always? 18:40 < MrARM> (NBT data length) 18:41 < roblabla> i suppose for better bandwidth usage 18:41 < MrARM> yes, but I don't know when it has and when no 18:42 < MrARM> I think maybe it depends on damage? 18:42 < roblabla> which packet ? 18:43 < MrARM> Set slot and a few others 18:43 < roblabla> The structure consists of at least a short, which gives the item/block ID [1]. A value of -1 signifies that the slot is empty, and no further data follows. 18:43 < roblabla> If the block ID is not -1, three more fields follow. These fields are a byte (item count), a short (item damage), and another short (length of optional NBT data). 18:43 < roblabla> If the short (length of NBT data) is -1, there is no NBT data, and no further data follows. Otherwise, a byte array will follow. 18:43 < roblabla> The byte array contains gzipped (that is RFC 1952 rather than RFC 1950) NBT data. 18:43 < roblabla> from wiki.vg :P 18:43 < MrARM> This page weren't updated for 1.7 maybe Mojang changed it? 18:43 < MrARM> No 18:43 < roblabla> I doubt it 18:44 < MrARM> I corrected to NBT Data Length 18:44 < roblabla> I can read them just fine with my library 18:44 < MrARM> So what's wrong with my?! 18:44 < roblabla> pastebin some code 18:44 < MrARM> ok 18:47 < MrARM> pastebin.com/UWL0kKZv 18:48 < MrARM> roblabla ↑ 18:48 < roblabla> yeah got it 18:48 < roblabla> i'd just do if pNBTLength >= 0 18:49 < MrARM> I'll try 18:50 * MrARM hopes no error Packet size exceed will happen 18:50 < roblabla> might be a bit confusing, but https://github.com/roblabla/node-minecraft-protocol/blob/feature-mc1.7/lib/protocol.js#L1304 18:50 < roblabla> that's my method for reading slots 18:50 < roblabla> (not actually written by me) 18:51 < roblabla> I don't actually read the NBT data though 18:51 < roblabla> (This is all just a very low level library that provides the building grounds for a higher level one) 18:52 < MrARM> yeah but it's something strange 18:53 < roblabla> hmm? 18:53 < MrARM> The exception happens when a Set slot with ID -1 happens so maybe it's because? 18:53 < roblabla> oh you have an error 18:54 < roblabla> I think 18:54 < MrARM> yeah 18:54 < roblabla> itemCount is supposed to be a byte 18:54 < MrARM> here ya go1 18:54 < MrARM> *! 18:54 < MrARM> Thanks! 18:54 < roblabla> at least I'm reading it as a byte 18:54 < roblabla> glhf 18:55 < MrARM> yes it is! 18:56 < MrARM> I am still thinking how it was working at all... 18:56 < roblabla> well, a short is two bytes put together 18:56 < roblabla> :P 19:08 < MrARM> roblabla but I am thinking how it was working if I was reading one byte more... 19:09 < MrARM> and it even didn't say that I didn't read the whole packet/read too much! 19:09 < roblabla> that's because it crashed before it could complain about reading too much 19:09 < MrARM-Away> nope 19:09 < MrARM-Away> It was receiving such packets earlier 19:09 < roblabla> oh 19:09 < MrARM-Away> Ok, I know 19:10 < MrARM-Away> I was receiving an -1 as id 19:11 < roblabla> ya know, I wouldn't worry too much about it working in circumstances it shouldn'thave :P 19:11 < roblabla> you'll lose your mind 20:39 < superjoe> hi there roblabla 20:42 < Corgano> Hi? 20:43 < superjoe> hi Corgano 20:43 < zh32> Hi! 20:43 < superjoe> I'm looking at roblabla's PR right now 20:45 < MCorgano> disconnected :/ 20:46 < MCorgano> roblabla did a great job :D Trying to make my alt move on a server 20:47 < MrARM-Away> MCorgano A little hint: wait a second before sending any move packets 20:48 < MrARM-Away> And one more: Server->Client Position and Look packet sends stance as Y 20:50 < MCorgano_> I think my client is acting up 20:50 < MCorgano_> IRC client* 20:50 < MCorgano_> so join server, it sends 0x08, wait a second, send same position, and then try moving? 20:52 < nuclearChicken> can someone help me out setting up my minecraft forge 20:52 < MrARM-Away> You can change client position only the next click, in the nearest you have to confirm the position server gave you 20:52 < MrARM-Away> *tick not click 20:52 < nuclearChicken> in need the right (1.7) version for my MCP 20:53 < MrARM-Away> so generally yes, what you said 20:54 < MrARM-Away> And remember the Y sent you by server is stance (to get Y do: stance-1.65) 20:54 < MrARM-Away> Here a credit goes to woder which figured it out 20:55 < MrARM-Away> MCorgano ↑ 20:55 < MrARM-Away> Freenode problems reborn? lol 20:56 < nuclearChicken> lol 20:57 < nuclearChicken> Can anyone help me to setup my MCP? 20:57 < MrARM-Away> Generally just extract it and run right .bat if on Windows 20:58 < MrARM-Away> hmmmm... 20:58 < nuclearChicken> i need the right minecraft forge file for my mcp 20:59 < MrARM-Away> you are trying to compile forge yourself? 21:00 < MrARM-Away> Anyway one of freenode servers were literally unplugged 21:00 < MrARM-Away> *was 21:01 < MrARM-Away> For those people on that server we all *.net *.split 21:02 < MrARM-Away> nuclearChicken you are trying to compile forge yourself? 21:04 < MrARM-Away> Server gone offline 21:04 < MCorgano_> OH 21:04 < MCorgano_> you mean when server sends y it sends y+stance 21:06 < MCorgano_> How is stance supposed to be used 21:07 < MCorgano_> It says on wiki.vg/protocol that is modifies player bounding box for going up stairs, but I'm not sure what actual effect changing this number has 21:07 < MrARM-Away> It's 1.62 default 21:07 < MrARM-Away> do Y-1.62 21:07 < MrARM-Away> *stance-1.62 21:08 < MCorgano_> OH, thats used for the camera view height isn't it 21:09 < MrARM-Away> yeah 21:09 < MrARM-Away> I think 21:37 < MrARM-Away> MCorgano_ if you run into problems feel free to ping me, I think I will be able to help you 21:37 < MCorgano_> you seem very knowledable 21:37 < MrARM-Away> Especially because I spent a hour to figure it out 21:37 < MrARM-Away> Today 21:37 < MCorgano_> I'm using the node-minecraft-protocol library, found out an issue I was having was because I was sending 0x08 instead fo 0x04 Lol 21:37 < MrARM-Away> lol 21:37 < MrARM-Away> Anyway you shouldn't send 0x03 (Player) packet 21:37 < MrARM-Away> I am writing a Client libraru 21:37 < MCorgano_> are you any good at javascript? I''m wanting to for x = x to x+5 step (4.3/20) 21:37 < MrARM-Away> *library 21:37 < MrARM-Away> Yeah 21:37 < MCorgano_> then send tha packet 21:37 < MCorgano_> but I'm not sure how to do that in javascript 21:37 < MrARM-Away> MCorgano first of all setInterval(tick, 50); 21:37 < MrARM-Away> and make a function tick 21:37 < MrARM-Away> then make a global var moveX, moveY, moveZ or similar 21:37 < MrARM-Away> in the tick function make a if(moveX > 0) { 21:37 < MrARM-Away> moveX -= moveSpeed; 21:37 < MrARM-Away> // send change player X packet with X = currentX+moveSpeed; 21:37 < MrARM-Away> } 21:37 < MrARM-Away> and so on for others 21:37 < MrARM-Away> Actually this doesn't work for negative values thought but I think you can add it easily 21:37 < MrARM-Away> and define global moveSpeed = 4.3/20; 21:37 < MCorgano_> I guess I could do that 21:54 < MCorgano_> Hey 21:54 < MCorgano_> the 4.3 bps speed, is that total? Or per axis? 21:54 < MCorgano_> could I move 4.3 blocks on x and y axis at the same time or will it say I'm going too fast? 21:57 < MrARM-Away> MCorgano I'm not sure 21:57 < MrARM-Away> agrrrr 21:57 < MrARM-Away> I think that the server doesn't care but check it 22:06 < MrARM-Away> grrr 22:10 < MrARM-Away> Ok, going away now, really. 22:10 < MrARM-Away> lahwran U SPAM! 22:11 < SinZ> Hey, You! You are supposed to be away 22:11 < MrARM-Away> lol 23:41 < coolcat_> Hm, anyone know what might be causing this error? http://i.imgur.com/cFpxzC0.png 23:42 <+SpaceManiac> coolcat_: my guess is the length field is being written wrong, are you writing the server? 23:43 < coolcat_> I am 23:43 < coolcat_> Im using VarInt for the length of the string.. 23:44 <+SpaceManiac> are you trying to send the 15758 bytes or 16 23:44 < coolcat_> 16 23:45 < coolcat_> 16 is the overall packet length 23:46 <+SpaceManiac> so you're sending something like VarInt(15) VarInt() VarInt(13) <13 bytes of text> ? 23:46 < coolcat_> Varint(16) VarInt(0) Varint(14) (14 bytes of text) 23:47 < coolcat_> 17 bytes overall 23:47 <+SpaceManiac> if I had to guess your varint encoding is just wrong, the bytes for that should be 10 00 0E [your text] 23:49 < coolcat_> Hm, sending 10 00 8E 23:50 < coolcat_> Shouldnt the 0E be encoded to a Varint? 23:50 <+SpaceManiac> it's a small enough number it stays the same 23:51 < coolcat_> hm, looks like im accidently adding a bit on the end 23:51 < coolcat_> Thanks ^^ 23:51 <+SpaceManiac> np --- Day changed lun. janv. 06 2014 01:41 < nickelpro> md_5: I saw you were looking for a PyCraft replacement in #craft.net, Spock can do multiple bots from a single thread. As long as you just want them to spawn and not do anything intelligent 01:43 < dx> nickelpro: he was looking for a pycraft replacement in the sense of "server stress testing tool", not as "python protocol library" 01:43 < nickelpro> dx: Ya, Spock has an event loop than can spin up a few hundred bots with a handful of threads 01:44 < dx> nickelpro: well, most importantly, must be easy to use by dumb server admins 01:44 < nickelpro> dx: The only part that isn't written is the dozen lines of config code 01:45 < nickelpro> The just won't move or anything, they'll just sit their, load chunks, and send keep alives 01:45 < dx> i'm not sure if pycraft does much more than that 01:45 * dx pokes ammar2 01:47 < TkTech> dx: You're a Python lover eh? 01:47 < dx> TkTech: not sure if implying something lewd there, or just asking if i like the language 01:48 < dx> i love python, but unfortunately my github stats say that most of my code is java ;_; 01:49 < TkTech> Hah, asking if you like the language. I'm trying to optimize constant parsing as well as can be done in plain python. 01:49 < TkTech> Looking for another set of eyes. 01:49 < dx> sure then 01:49 < TkTech> It's awful to look at, https://gist.github.com/TkTech/99624f95e23ba925743c 01:49 < TkTech> I've gotten it down to 456ms for 1895 ClassFiles. 01:49 < dx> fun 01:50 < dx> where can i get some test data? do i just extract a minecraft jar and iterate over each class? 01:51 < TkTech> Hm, let me try it with the latest server jar 01:52 < nickelpro> TkTech: The elif tree is what 01:52 < nickelpro> 's killing you 01:53 < nickelpro> Maybe try a different data structure for maping values to operations? 01:55 < TkTech> dx: Okay, for minecraft_server-1.7.4.jar, pre-extracted (the overhead of ZipFile in py2 is huge) I get 1.99s for 6403 classes 01:56 < dx> gotcha 01:56 < dx> nickelpro: i'd rather not make guesses like that, they smell of premature optimization 01:57 < dx> not like we're actually doing premature optimization here, but that way of optimizing smells a lot like that 01:57 < nickelpro> dx: Just spitballing, anytime 01:57 < nickelpro> I see value == int elif trees I see something that can be optimized 01:57 < dx> maybe! 01:57 < TkTech> dx: Snippets from my ipython - https://gist.github.com/TkTech/11024b32638b9187f89d 01:58 < TkTech> dx: Testing with IPython's %timeit -n10 load_all_classes() 01:58 < TkTech> line-by-line profiling with %lprun -f cf.parse_classfile load_all_classes() 01:59 < dx> neat! 01:59 < TkTech> nickelpro: That seems counter-intuitive, I can't imagine that the lookup overhead for such a small number of keys (and plain type keys at that) in a dict would be less than if's 01:59 < TkTech> nickelpro: Especially when I've overdered those if's by frequency 02:00 < TkTech> (But I could be wrong!) 02:03 < nickelpro> TkTech: Wouldn't have suggested a dict, just use a tuple. You have operations for almost all values between 0-12 02:04 < TkTech> Ohhh 02:04 < dx> hm, yes, a tuple is definitely better than a dict 02:14 < TkTech> nickelpro: 7% slower using https://gist.github.com/7a091edda3f0ff64a280 02:15 < TkTech> (the r is just fobj.read, to remove the attribute lookup overhead) 02:15 < nickelpro> TkTech: Ah well, I'm dumb 02:16 < nickelpro> Curious that a tuple is slower than an elif, shouldn't it be constant time? 02:17 < TkTech> 4% slower when reassigned in the methods local scope 02:17 < TkTech> nickelpro: The overhead of the lambda's is high, function calls are brutal in Pythonm 02:18 < nickelpro> TkTech: Didn't think of that, makes perfect sense 02:18 < nickelpro> Multiple levels of indirection to get to the lambda 02:24 < TkTech> No variation I can come up with (including removing the lambda's) can beat the if's. Really close but no cigar. 02:24 < TkTech> It does *dramatically* shrink the LoC tho' 02:47 < TkTech> 409ms... 02:48 < TkTech> 389ms... almost at the read() bottleneck, at which point there isn't really anything I can do... 03:00 < nickelpro> How'd you manage it? 03:00 < TkTech> Horribly, horrible inling. Got minecraft_server from 1.99s to 1.43s. 03:00 < dx> \o/ 03:02 < dx> TkTech: could you update the gist? just had a dumb idea which i want to try 03:03 < TkTech> https://gist.github.com/TkTech/d5c40947ebcc47d9edd7 now dominated by file IO (read()) 03:03 < TkTech> dx: https://gist.github.com/20f3bd9c396724611e32 03:09 <+md_5> I dont get it, literally all that code does is write out the constant pool 03:09 <+md_5> I'd hardly call it parsing the class file 03:10 < dx> md_5: well, he never claimed to parse the class file with that 03:10 <+md_5> " Parses a JVM ClassFile per the The Java Virtual Machine 03:10 <+md_5> Specification, Java SE 7 Edition." 03:10 <+md_5> sounds like a claim to me 03:10 < TkTech> ... because the rest was trimmed out to make profiling and optimizing the constant pool parsing simpler ... 03:10 < dx> lolnevermind 03:11 < dx> next time trim the docstrings too 03:11 < TkTech> md_5: https://github.com/TkTech/Jawa - jawa.tkte.ch 03:11 <+md_5> and that takes 1.43s for the entire MC jar/ 03:12 < TkTech> Correct. It's essentially instant if you use multiprocessing or threading.Pool. 03:12 < TkTech> The main bottleneck is now IO. 03:15 < TkTech> Why is this reimplemented like this? Because it's immediately serialized to JSON and used to create a search index. 03:18 < dx> isn't it 1.43s for 10 loops of the same thing? 03:19 < TkTech> 1.43s is the best-of time 03:20 < dx> TkTech: Struct('>H').unpack seems like a great idea 03:20 < dx> and you missed it in a few data types 03:20 < dx> well, you didn't inline those at all 03:21 < TkTech> If you look at the profiling gist, the others essentially don't exist. 03:21 < dx> heh 03:21 < TkTech> But yeah, will inline all of them. 03:22 < TkTech> Python gods pitty me for this awful mess. 03:24 < dx> >float(fobj) 03:25 < dx> the word "essentially" in "essentially don't exist" might not be needed 03:28 < dx> herp derp nevermind you redefined 'float' as a lambda 03:36 < TkTech> Inlining the rest didn't really save anything, 0.01ms on average. 03:36 < dx> two appends seem to be faster than a single extend 03:37 < dx> also, append = constant_pool.append 03:38 < TkTech> Only a 0.03ms improvement 03:39 < TkTech> I think this is it, really. CONSTANT_Utf8 is the major time sync and that's just a read() 03:41 < dx> yeah, confirmed that what i said about extends was bullshit 03:42 < dx> it was "append = constant_pool.append" that brings me from 935ms to 889ms 03:42 < TkTech> Really? That's a much bigger change than what I noticed... 03:58 < dx> TkTech: i'm now doing %timeit -n1 -r60 load_all_classes() 03:58 < dx> 60 repetitions of a single loop 03:59 < dx> something else in my pc is making me get really inconsistent results when doing just just 3 repetitions of 10 loops, so instead of solving that, i just make it test harder 03:59 < TkTech> Science! 04:00 < dx> :D 04:02 < dx> you should do that too tbh. any loop that doesn't have the best time is a shitty loop. 04:05 < TkTech> 1.38s 04:05 < TkTech> Current working code https://gist.github.com/46bfc7ae3778675ea1bc 07:02 < Not-002> [node-minecraft-protocol] superjoe30 pushed 3 commits to master [+4/-0/±23] http://git.io/sHJMLg 07:02 < Not-002> [node-minecraft-protocol] roblabla 875d10e - Protocol 1.7 support, Yggdrasil login support, new Client State API 07:02 < Not-002> [node-minecraft-protocol] roblabla 018fb64 - Add new chat client example 07:02 < Not-002> [node-minecraft-protocol] superjoe30 c6d228d - Merge pull request #69 from roblabla/feature-mc1.7 Feature mc1.7 07:03 < dx> a tiny feature addition, huh 07:27 < superjoe> what happened to the client->server "disconnect" packet? (it used to be 0xff) 07:27 < superjoe> or rather, how does a client disconnect now? 07:36 <+SpaceManiac> I think it just disconnects 07:48 < superjoe> cool. no more "reason" 08:42 < Not-002> [MCPP] RobertLeahy pushed 5 commits to 1_7_protocol [+1/-2/±8] http://git.io/N9pWVQ 08:42 < Not-002> [MCPP] RobertLeahy pushed 163 commits to master [+150/-76/±373] http://git.io/CYlujw 08:42 < Not-002> [MCPP] RobertLeahy d877a1c - Merge branch '1_7_protocol' 10:43 < MrARM> MCorgano_ did you succeed? 13:15 < Not-002> [MCPP] RobertLeahy pushed 1 commit to master [+1/-0/±0] http://git.io/ixOaIg 13:15 < Not-002> [MCPP] RobertLeahy 309f0c5 - Whitelist Header 16:44 < TkTech> dx: Sorry if you said anything last night, I fell asleep at my desk ;\ 16:56 < clonejo> TkTech: still better than waking up on the toilet 16:57 < iBotPeaches> clonejo: or in it 16:59 < clonejo> :/ 17:02 < TkTech> >_> 17:17 < TkTech> clonejo: Is this from experience? 17:18 < clonejo> TkTech: yes, I went to bed as usual and woke up sitting on the toilet in the middle of the night 17:18 < clonejo> weird that it never happened at my parents house 17:19 < clonejo> I even turned on the light on the toilet :p --- Day changed mar. janv. 07 2014 12:16 < xerxes> hm 17:14 < MrARM> woder did you succeed with path finding? 17:44 < deathbydydx> Is there a reference yet on the 1.7 encryption? I'm assuming wiki.vg's article is out of date 17:44 <+sadimusi> the encryption is still the same 17:45 <+sadimusi> and everything on wiki.vg is up to date 17:45 < TkTech> deathbydydx: Can I ask why you thought it was different or out of date? 17:51 < deathbydydx> Oh whoops. I just read the doc wrong. My mistake. Thanks for the help anyways :/ 18:00 < MrARM> sadimusi not everything. How to write a client isnt and a thing in Protocol FAQ isnt too (order of packets) 18:06 < MrARM> Anyway how the client handles custom textures? 22:13 <+AndrewPH> supreme netsplits 22:14 < humerusj> True. 22:18 < iBotPeaches> Can anyone spot anything wrong with this java 0x3E packet: http://pastebin.com/KyQR8fKx ? Everything else works, until I enable the scoreboard, so the creation of my strings, varints can't be wrong --- Day changed mer. janv. 08 2014 01:02 < moomoohk> hey there guys 01:06 <+sadimusi> hi moomoohk 01:10 < moomoohk> just wanted to see if the group was still active :) 01:10 < moomoohk> stumbled upon the wiki and it really helped me with some project i've been working on 01:10 < moomoohk> got curious about its origin 01:21 <+sadimusi> the channel got a bit quiet recently, but most of the people are still here and answer if anyone asks anything 01:24 < moomoohk> awesome 01:24 < moomoohk> well i think i'll be off 01:24 < moomoohk> might be back in the future 01:25 < moomoohk> o/ 09:32 < morfin> hmmm 09:33 < morfin> offline mode is just using zeroes for sesssion id 16:50 < MrARM> anyone has idea why my client doesn't receive complete chunks which are away? 16:50 < MrARM> *far 16:50 < MrARM> more exactly: one chunk later 16:50 < MrARM> *after 16:51 < MrARM> no, actually looks like I do receive. .. 16:51 < MrARM> It looks like my getting function has an offset or like it 16:56 < MrARM> Actually looks like I reversed x and z... 17:04 < shoghicp> MrARM: That happened to me too 17:04 < shoghicp> exactly like that 17:18 < MrARM> shoghicp actually I've reversed them 17:18 < shoghicp> yep 17:18 < shoghicp> and that bug was all around the code 17:19 < shoghicp> I only found that when all the metadata was rotated 17:24 < MrARM> shoghicp Is it possible to do insta mine on survival using PocketMine? 17:24 < MrARM> (without mods) 17:24 < MrARM> or know when mining starts ? 17:24 < shoghicp> it *could* be possible 17:24 < shoghicp> tracking hand movement 17:24 < shoghicp> but that also means hitting 17:24 < shoghicp> or shearing 17:25 < MrARM> ok, thaanks! 17:25 < shoghicp> (besides placing and breaking)ç 17:25 < shoghicp> the client doesn't send anything until it has fully broken the block 17:25 < shoghicp> fyi, all the limits in the PocketMine side can be removed 17:26 < MrARM> shoghicp actually i am asking, because PC has a mining start packet 17:26 < MrARM> and I am writing PC2PEServ 17:26 < shoghicp> yep, I know. I hope that MCPE will get it in the future 17:27 < MrARM> but I thought insta mine is possible after 0.8.0? 17:27 < MrARM> There are world flags... 17:27 < shoghicp> hmmm... no 17:27 < shoghicp> those adventure flags where there long ago 17:28 < shoghicp> they are used for nametags 17:28 < MrARM> shoghicp :* 17:28 < MrARM> *:( 17:28 < shoghicp> pocketmine blocks cheating by measuring the time since the last action (any kind of action, so you can't do anything while mining) 17:28 < MrARM> Because in PocketInvEditor they added insta mine, fly in survival 17:28 < MrARM> shoghicp I know it 17:29 < shoghicp> If a mod is able to activate it, PocketMine can support it 17:29 < MrARM> It is no mod thought. .. 17:30 < shoghicp> hmm... 17:30 < shoghicp> but those affect the world 17:30 < shoghicp> and I can't send the level.dat file ;) 17:32 < MrARM> yeah, so they didn't introduce that into packets..? 17:32 < MrARM> I don't have two android devices to test :( 17:33 < shoghicp> nope :( 17:33 < shoghicp> I'll ask Johan once he gets back 17:34 < MrARM> shoghicp even more interestingly, now I am getting wrong tile for player coords :P 17:34 < shoghicp> xD 17:34 < MrARM> it is like those are reverted there too? :P 17:34 < shoghicp> if you had something reverted and it worked fine 17:34 < shoghicp> likely everything is *inverted 17:34 < MrARM> it worked only for pkayer 17:35 < shoghicp> eyah 17:35 < shoghicp> you have to swap those too ;) 17:35 < MrARM> While taking coords from vanilla these were reverted 17:35 < MrARM> Some debugging and we will see 17:35 < MrARM> starting vanilla 17:37 < MrARM> That's soo strange 17:37 < MrARM> I think I know where I reverted it now... 17:37 < shoghicp> I remember those times :') 17:37 < MrARM> 2 17:38 < MrARM> You were writing a client? 17:39 < shoghicp> I implemented a PC client when you had to implement all the packets 17:39 < MrARM> nope that's not the place 17:39 < shoghicp> then 17:39 < shoghicp> implemented it again, object-oriented 17:40 < MrARM> php? 17:40 < MrARM> I write in Java 17:40 < shoghicp> yes, PHP 17:40 < shoghicp> and it had the extremely original name of "Minecraft PHP Client" 17:40 < MrARM> I prefer Java and X# 17:40 < MrARM> *C# 17:41 < shoghicp> and the second version... "Minecraft PHP Client 2" 17:42 < MrARM> hmmm... 17:42 < MrARM> I know what's was wrong 17:43 < MrARM> After re-reverting it started working right... 17:43 < MrARM> (how?!) 17:45 < MrARM> I found out extracting, parsing half bytes difficult 17:45 < shoghicp> xD 17:46 < shoghicp> just get them and don't toush them until you need them 17:46 < shoghicp> also 17:46 < shoghicp> hint 17:46 < MrARM> Configure Perspective Switch dialog opened - what?! 17:46 < shoghicp> use bitwise operators 17:46 < MrARM> shoghicp implemented already (; 17:46 < shoghicp> nice! 17:47 < shoghicp> that improves map things a lot 17:47 < MrARM> that was pretty simple 17:47 < shoghicp> keep in mind that there are negative values too ;) 17:48 < shoghicp> in fact, I'll have to remove a few optimizations on PocketMine once MCPE has infinite worlds 17:48 < MrARM> Stupid me: wrote >= rather than < 17:48 < shoghicp> xD 17:49 < MrARM> which madr OutOfArrayException 17:50 < shoghicp> MrARM: Java! http://www.ioccc.org/2005/chia/chia.c 17:53 < MrARM> lol 17:53 < MrARM> I like Java and C# 17:54 < MrARM> I like php 17:55 < MrARM> file_put_contents would be 5 lines of code in Java 17:55 < shoghicp> and multiple classes ;) 17:55 < shoghicp> factories 17:55 < MrARM> And File.writeAllText in C# 17:56 < MrARM> factories <- never heard... 17:56 < shoghicp> MrARM: fopen() stream_get_contents() fclose() 17:56 < shoghicp> that works too ;) 17:56 < MrARM> I actually prefer Java handling of classes... 17:56 < MrARM> not better just file_put_contents. .. 17:56 < eggster> boo..oo. 17:56 < shoghicp> oh, PUT 17:57 < eggster> oops, wrong channel 17:57 < MrARM> lol, like me two days ago 17:57 < MrARM> But I don't like Mono and I switched from Windows 17:58 < MrARM> So C# is no longer language I use :( 17:58 < MrARM> I generally don't like writing good code... 17:58 < shoghicp> MrARM: http://www.bash.org/?246405 17:58 < shoghicp> typical error 17:59 <+sadimusi> MrARM: you already said that :P [17:54:59] MrARM: I like php 17:59 < MrARM> I know 18:00 < MrARM> But what it has to current discussion? 18:00 < MrARM> I like PHP for web servers 18:00 < MrARM> I am missing a code completion for it 18:01 < MrARM> A IDE like Eclipse 18:01 < MrARM> Or Visual Studio 18:01 <+sadimusi> I was referring to [17:58:33] MrARM: I generally don't like writing good code... 18:01 < MrARM> These are cool 18:01 < MrARM> By good code I meant free the objects 18:01 <+sadimusi> but since I don't really want another language war in here I'll shut up now 18:02 < MrARM> That isn't a language war... 18:02 < MrARM> I am not saying that x language is bad and y is much better and use it! 18:02 < iBotPeaches> it seems there is one every 3rd blue moon 18:03 < MrARM> For languages I seen I don't like only Python, but there are people who thinks it's cool (if I would still use Visual Basic then I would say something other...). It depends. 18:04 < MrARM> Python is C++ without operators but nvm 18:05 < MrARM> *for me 18:05 < MrARM> sadimusi I still don't know why you were referring to any from these... 18:22 < mochar> thats not true.. 18:23 < humerusj> Python makes life easy <3 18:31 < MrARM> Your "quick prototype language" is python, my is C# 18:33 < humerusj> Ehh, php does the job too 18:33 < MrARM> not for me thought 18:33 < humerusj> Mhmm, everyone has their own preferences 18:34 < MrARM> Yeah 18:34 < MrARM> php is good for websites thought <3 --- Day changed jeu. janv. 09 2014 17:02 < Thinkofdeath> http://wiki.vg/Pre-release_protocol#14w02a New fields added just need to work out what they do 17:02 < dx> \o/ 17:13 < SinZ> InventoryType going from byte to string is most likely for PluginAPI 17:40 < Thinkofdeath> http://i.imgur.com/56okx8i.png <- thats what the new byte in the chat packet does 17:44 < SinZ> Thinkofdeath: now to document it 17:44 < SinZ> is there any other possible things to do 17:45 < Thinkofdeath> Already have :) 17:45 < Thinkofdeath> Nope, only that or the chat box 17:45 < SinZ> boring 17:45 < MrARM> It's cool anyway :) 17:51 < Thinkofdeath> I think everything is updated now 17:52 < Thinkofdeath> Not sure what the 'Player Position And Look' flags do 17:55 < iBotPeaches> <3 Thinkofdeath 18:02 < iBotPeaches> hmm did NBT get some changes 18:03 * TkTech perks up 18:03 < Thinkofdeath> iBotPeaches: Don't think so 18:03 < TkTech> Noticing new tag types? 18:03 < iBotPeaches> I haven't looked at anything yet, just looking at notes 18:06 < Thinkofdeath> TkTech: nope, no new nbt tags types 18:16 < TkTech> Thinkofdeath: Thanks :) 18:18 < MrARM> Thinkofdeath where exactly you documented it..? 18:25 < Thinkofdeath> MrARM: http://wiki.vg/Pre-release_protocol#14w02a 18:26 < MrARM> Thanks 18:26 < MrARM> ah, that means "Pre-release" 18:26 < MrARM> I thought it means beta 18:31 < Dinnerbone> That chat byte: 0 is chat, 1 is system message, 2 is game info. Chat/system message is important if you want to respect the users 'chat visibility' options 18:34 < Thinkofdeath> Dinnerbone: Thanks, adding that to the page 18:34 < MrARM> what he said? 18:35 < Thinkofdeath> Nevermind iBotPeaches beat me :) 18:35 < shoghicp> Dinnerbro: That chat byte: 0 is chat, 1 is system message, 2 is game info. Chat/system message is important if you want to respect the users 'chat visibility' options 18:35 < shoghicp> MrARM: ^ 18:35 < MrARM> thx 18:36 < iBotPeaches> Thinkofdeath: I added a warning to respect client options, but doesn't really fit with the pattern of other warnings, so maybe I need to remove it 18:37 < Thinkofdeath> iBotPeaches: maybe have it as a comment above the packet like Player Position and Look 19:55 < barneygale> can someone explain the difference between chat/system/game info messages/ 19:55 < barneygale> oh, is the game info message used for jukeboxes at the mo? 19:56 <+sadimusi> if I got this correctly it's this thing http://i.imgur.com/56okx8i.png 19:56 < SinZ> used for locking chests 19:56 < barneygale> wow 19:56 < barneygale> that's pretty neat! 19:57 <+sadimusi> the difference between chat and system is probably just that system messages are still displayed when you disable chat 20:10 < barneygale> chat is only for " hello world" messages, everything else is system? 20:24 < Apiocera> awesome! kindle turns into a tad expensive ARM devboard with jailbreak and usbnetworking installed :D 20:55 <+clonejo> Apiocera: hey, nice to see you on irc some time again :) 22:01 < Apiocera> So my Kindle now runs Bukkit server, to stay on topic of this channel :) 22:02 < Eviltechie> ಠ_ಠ 22:02 < redstonehelper> meanwhile, I'm reading a book in minecraft 22:03 < Calinou> no, you're farming karma on reddit 22:04 < redstonehelper> it's working! --- Day changed ven. janv. 10 2014 01:06 < barneygale> Can anyone recommend a webapp for drawing diagrams? Just need boxes, arrows, text, etc 01:15 <+clonejo> barneygale: dia? graphviz? latex+tikz? 01:15 <+md_5> lucidchart.com, not free 01:15 <+md_5> google drive works too 01:28 < barneygale> google drive seems sufficient 01:28 < barneygale> thanks 02:54 < cdc_bob> wsup 05:44 < nickelpro> Anything interesting in the new update? 05:45 < Eviltechie> Yes 05:45 < Eviltechie> Bouncy slime blocks 05:45 < nickelpro> I noticed those 05:46 < nickelpro> How are they supposed to work? 05:46 < Eviltechie> Absorb fall damage 05:46 < Eviltechie> Bounce 05:46 < nickelpro> Are they entities? 05:46 < Eviltechie> I think they are just blocks 05:46 < nickelpro> Oh the block doesn't bounce 05:46 < nickelpro> It bounces people 05:46 < nickelpro> More client side physics, which are never documented, awesome 06:54 < cathode> lol 12:55 < Not-002> [node-minecraft-protocol] roblabla pushed 1 commit to master [+0/-0/±1] http://git.io/66tStQ 12:55 < Not-002> [node-minecraft-protocol] roblabla d1490e9 - Expose yggdrasil to API consumer The Yggdrasil library should be exposed to API consumer. --- Day changed sam. janv. 11 2014 01:21 < ashka> hey there, I'm trying to get the new protocol for 1.7+. I'm trying to get (serverside) how does the handshake works, I might be doing this wrong but the first byte from the first packet I receive is not 0x00 as described on wiki.vg but 0x0f 01:23 < ashka> some things seems to be matching, and some aren't, here's the full packet I'm receiving : http://paste.awesom.eu/zOW I can see the server address (localhost) in it 01:24 < Thinkofdeath> ashka: The 15 is the packet length 01:24 < ashka> oh okay, is it new ? I don't remember getting those before (long time I didn't work on my project, I might be wrong on that) 01:26 < Thinkofdeath> ashka: yep http://wiki.vg/Protocol#Packet_format 01:32 < ashka> thanks 01:37 < ashka> also, I'm new to VarInts, my first guess was that 3rd byte is the protocol version but then I don't have a clue what the 4th is 01:38 < ashka> I'd guess same thing applies at the end where I have two '1' where I'd expect only one for the next state 02:24 < Thinkofdeath> Position 2 (Above the action bar) for chat doesn't seem to support json style formatting/colors 02:25 < Thinkofdeath> Old style colors work, I guess its a bug 02:49 < SinZ> Thinkofdeath: Mojang keep on trying to tell us that the new system is better, yet stuff like this always happens 02:49 < SinZ> where the old system is the only way 02:53 < Drainedsoul> ashka: The very nature of VarInts is that integers are variable-length, you can't say with absolute certainty what the X byte will be, and if you're making such assumptions, you're almost certainly Doing It Wrong (tm) 02:53 < ashka> aw 02:57 < Drainedsoul> They are not difficult to implement. 03:10 < ashka> yeah, I've seen an implementation on the wiki 03:12 < ashka> still, on this : http://paste.awesom.eu/zOW third byte is (afaik) a VarInt for the protocol version, but what is the fourth then ? according to the wiki the server address should follow 03:32 < ashka> figured out it is the string length. heh 13:25 < Tirus> hi all 13:27 < Tirus> can me someone tell if iam right that with minecraft protocol 1.7.2 they have changed all packet header bytes? 13:37 < iBotPeaches> yes they are prefixed with length 13:37 < dx> pretty much everything has changed 13:39 < Tirus> is there already a docu? 13:40 < dx> http://wiki.vg/Protocol 13:40 < Tirus> ah, thanks 13:41 < dx> if you already implemented 1.6 you'll have to rewrite a bunch of it, but it should be easier. encryption was kept the same 13:42 < Tirus> yea, i have implemented neary all between beta 1.8.1 and relase 1.6.2 13:42 < dx> neat 13:43 < Tirus> have al client that can connect to all these versions 13:44 < dx> it's not exactly trivial to support both >=1.7 and <=1.6 but it's not impossible either 13:45 < Tirus> ok, i will try it :) 13:46 < Tirus> at the moment i have trouble with these varints 13:48 < iBotPeaches> Tirus: https://gist.github.com/thinkofdeath/e975ddee04e9c87faf22 13:48 < Tirus> is there an example with negative numbers? 13:49 < Tirus> thanks 14:19 < Drainedsoul> isn't it still the case that VarInts in the protocol are never negative, or did that change? 14:25 < dx> Drainedsoul: you mean in the 1.8 snapshot? 17:57 < Drainedsoul> dx: Sure 22:04 < Yogu> Hey there! I have trouble with my minecraft client implementation: The player spawns, can send text messages, but can not move 22:05 < Yogu> to be specific, the playerPositionAndLook package is received, and I send it with modified x/y/z/yaw/pitch, but the server completely ignores it 22:05 < Yogu> can someone help me? 22:05 < MrARM> I know why 22:06 < MrARM> player position and look packet sends stance 22:06 < Yogu> yes, I send y + 1.62 22:06 < Yogu> is that correct? 22:06 < MrARM> y-1.62... 22:06 < MrARM> wait, no 22:06 < Yogu> I also tried playerLook, but it did not work either 22:07 < MrARM> Player position packet, whick you receive sends you stance 22:07 < MrARM> *Which 22:07 < Yogu> no, the packet by the server does not include stance 22:07 <+pdelvo> how exactly do you modify them? 22:07 < MrARM> So to get Y from that packet you do Stance-1.62 22:07 < MrARM> Yogu it does 22:07 < MrARM> Try it 22:08 < MrARM> I've tried it on 1.7.4 and it works 22:08 < Tirus> @Yogu have your client received the chunks of the world? 22:09 < Yogu> yes, chunks are received fine 22:09 < MrARM> like that 22:09 < Yogu> they are correct 22:09 < Yogu> sorry, my client just froze. did you write anything after the server sending stance? 22:09 < Yogu> reading the documentation in wiki.vg, the package sent by the server includes x,y and z, and no stance 22:10 < MrARM> Tirus actually when I was sending Player pos incorrect it was sending chunks fine. ... 22:10 < MrARM> Yogu try doing -1.62 22:10 < MrARM> I've checked it last on 1.7.4 and it was working like it 22:11 < Tirus> hmm, as far iam it know you must respond to the first playerPositionAndLook package the server sends with the same data 22:11 < Tirus> after it you can modify it 22:11 < MrARM> Tirus hmmm... Not sure about it. 22:11 < MrARM> I was sending the first one 22:12 < MrARM> But not one every 50ms 22:12 < Yogu> now the server kicks me for illegal stance, -1,62 22:12 < MrARM> not there 22:12 < Yogu> you do not have to send playerPositionAndLook at all to get the chunks 22:13 < MrARM> Do -1.62 in receive of player position and look 22:13 < MrARM> In sending add it, as you had earlier 22:13 < Yogu> you mean, the server sends the head position, and I should send the foot position? 22:13 < MrARM> yup 22:14 < MrARM> But foot pos as Y and head as stance (; 22:14 < MrARM> // receive 22:14 < MrARM> playerY = receiveInt()-1.62; 22:14 < MrARM> // send 22:14 < MrARM> sendInt(playerY); 22:15 < MrARM> send (playerY+1.62); 22:15 < MrARM> like it 22:16 < Yogu> uh, now my client shows myself stuck in the ground 22:16 < Yogu> and it does not work either 22:16 < MrARM> Hmmm 22:16 < MrARM> Idk why 22:16 < MrARM> It was working for me 22:16 < MrARM> Yogu you use an library? 22:17 < Yogu> no, just taking some pieces from minecraft-protocol node package 22:17 < MrARM> It's possible that it handles it....l 22:17 < MrARM> Yogu Undo that then. 22:18 < Yogu> yeah 22:18 < MrARM> I had that problems with that too 22:18 < Yogu> does the server reject the position if onGround is wrong? 22:18 < Yogu> I noticed that the server sends onGround=false, even though the player is on ground 22:19 < MrARM> Yogu after receiving any playerPositionAndStance you have to wait one tick before sending another position 22:19 < MrARM> Yogu I dunno. 22:19 < Yogu> really? it rejects it if it's too quick? 22:19 < MrARM> yes 22:20 < MrARM> I ran into it a few days ago. 23:00 < Yogu> no, It won't work. well, thank you anyway. 23:44 < Not-002> [fNbt] fragmer pushed 1 commit to master [+0/-0/±1] http://git.io/kXpq4A 23:44 < Not-002> [fNbt] fragmer 7ed5099 - Fixed NbtReader attempting to read Position property of non-seekable streams. 23:47 < TheUnnamedDude> What does the new byte in the position and look packet do? 23:48 < TheUnnamedDude> (the one replacing on ground) --- Day changed dim. janv. 12 2014 00:02 < Dinnerbone> It's a bitfield, X/Y/Z/Y_ROT/X_ROT. If X is set, the x value is relative and not absolute. 01:01 < TheUnnamedDude> Ahh, ok 01:01 < TheUnnamedDude> Thanks 04:57 < Klong> test 07:15 < Not-002> [fNbt] fragmer pushed 1 commit to master [+0/-0/±3] http://git.io/OI-_cg 07:15 < Not-002> [fNbt] fragmer 42a7736 - Changed NbtFile.LoadFromStream/SaveToStream to accurately report bytes-written/saved for files over 2 GB in size. Fixed more issues with reading from/writing to non-seekable streams. 07:17 < fragmer> darn non-seekable streams and their non-seekableness 07:17 < fragmer> I can understand not being able to seek and report length (e.g. on chunked HTTP streams) 07:17 < fragmer> but not being able to report position within a stream is just silly 07:18 < fragmer> GZipStream throws a NotSupportedException when I try to get its position though. Weak. 07:18 < fragmer> (in .NET) 10:06 < Not-002> [fNbt] fragmer pushed 1 commit to master [+1/-0/±6] http://git.io/TlMjfA 10:06 < Not-002> [fNbt] fragmer 71a3c04 - Finally fixed the way bytes read/written are counted for non-seekable streams. Seriously this time. All tests passing! 14:20 < MrARM-Away> Yogu I have one more idea what could be wrong. .. 15:47 < Yogu> @MrARM give me a minute, I think I found my mistake myself 15:53 < MrARM> Don't write @, it doesn't ping. .. 15:55 < Yogu> ok 15:56 < Yogu> nope, it still does not work. I figured out that stance must be lower than y. but that does not fix the problem 15:56 < Yogu> what was your idea? 16:00 < MrARM> Yogu stance must be bigger than Y 16:00 < Yogu> the minecraft client sends Y as eye position and stance as feet position 16:00 < MrARM> Because in my code I actually not skip an tick but just resend that position server gave, second time 16:00 < Yogu> I just inspected the packets 16:01 < Yogu> we're both talking about 1.7.4, are we? 16:02 < MrARM> yes 16:02 < MrARM> Yogu I wouldn't age but nvm 16:02 < MrARM> I do +1.62 in code 16:02 < MrARM> as stance 16:03 < Yogu> Yeah! Steve is rising! *happy* 16:04 < Yogu> in my last try a couple minutes ago, I just sent the wrong packet (playerLook). But I think the stance was the problem 16:04 < Yogu> I just wrote this neat little packet sniffer: https://github.com/Yogu/minecraft-sniffer 16:05 < Yogu> it is a minecraft proxy. Start a local server, start the sniffer, and connect to the sniffer in notchian client. And volià, it will display all packates sent and received in JSON format 16:06 < Yogu> and there you see: playerPositionAndLook: {"x":-13.39741323635965,"stance":92,"y":93.62000000476837,"z":12.171497748473938,"yaw":92.39895629882812,"pitch":35.400062561035 16:06 < MrARM> As I said I do it correctly somehow 16:06 < Yogu> is it 1.7.4? 16:06 < MrARM> You replaced stance with Y for me... 16:06 < MrARM> yes 16:08 < MrARM> They changed it recently 16:08 < MrARM> Earlier it was reversed 16:08 < MrARM> But nvm 16:08 < Yogu> I used x-stance-y-z, as it is documented in the wiki 16:11 < Yogu> I'd say we should write what y and stance actually mean. what about "Feet position, normally Y - 1.62."? 16:12 < Yogu> and "Absolute head position" for y 16:13 < MrARM> nvm 18:32 < Tirus> hmm, how comes that the minecraft client says feet pos: y=88, eye pos y = 89,620 but the it receives from the server y = 89,620 and stance = 91,24 18:44 < Tirus> hmm ok, mail mistake, server sends only y = 89.620 (eye position) 18:44 < Tirus> my* 19:11 < Tirus> i think in http://wiki.vg/Protocol#Player_Position_And_Look_2 there should be y before stance, as the 2. double is the feet position of the player and the 3. double is the eye position (result of a network sniff from the orginal mc client) 19:25 < MrARM> yes 19:25 < MrARM> It is so I think 19:26 < MrARM> Stance = Head pos, right? 19:29 < MrARM> Tirus ↑ 19:29 < Tirus> yes, but it should be y 19:33 < umby24> https://github.com/umby24/libMC.NET/blob/master/Packets/Play/ServerBound/playerPositionAndLook.cs 19:33 < umby24> that's what works for me 19:36 < Yogu> This is confusing. If you /tp to 0 100 0, it says "teleported to 0.5 100.5 0.5". Then it sends a positionAndLook at y=102.12. This means that your feet at are 100.5 and your head is at 102.12. So what is the official Y coordinate of a player? the head or the feet? 19:37 < Yogu> I'm not a native speaker, so maybe I'm wrong, but "stance" does not seem to be a good word for position - regardless of whether feet or head. Shouldn't we call it "headY" and "feetY"? 19:41 < Tirus> yea headY and feetY is better 19:51 < Yogu> ok, changed it 19:55 < Tirus> hmm, you could add to http://wiki.vg/Protocol#Player_Position_And_Look that y is headY --- Day changed lun. janv. 13 2014 10:35 < Not-002> [fNbt] fragmer pushed 2 commits to master [+0/-0/±7] http://git.io/LyQYdg 10:35 < Not-002> [fNbt] fragmer 4b7dfe1 - Fixed an edge case in ByteCountingStream that affected reporting accuracy in streams that implement Read/Write by calling ReadByte/WriteByte. 10:35 < Not-002> [fNbt] fragmer 07ca503 - Formatting and comment improvements, particularly in NbtSerializationGen 15:53 < TkTech> fragmer: What would you expect? The position in the uncompressed or compressed stream? 16:35 < fragmer> TkTech: uncompressed stream! 16:36 < fragmer> Anyways, I figured out a solution that works on all non-seekable streams: I wrap them in my hacky ByteCountingStream: https://github.com/fragmer/fNbt/blob/master/fNbt/ByteCountingStream.cs 16:42 < fragmer> Slight throughput loss (I'm seeing 2-3% in my unit test suite for non-seekable vs seekable streams). But at least I can accurately track and report bytes read/written to streams, which is kinda important for network streams in particular. 17:18 < TkTech> fragmer: ick 17:20 < fragmer> TkTech, got a better idea? :P 17:21 < TkTech> Nothing good 19:59 < Not-002> [fNbt] fragmer pushed 1 commit to master [+0/-0/±1] http://git.io/CGYEHw 19:59 < Not-002> [fNbt] fragmer 2325cb9 - Fixed a few edge cases when handling enums and non-directly-mappable primitive types (like bool) in NbtSerializationGen. Also improved comments/annotations and refactored a couple things. 20:25 < Drainedsoul> what does "non-directly-mappable" mean? o_o 20:25 < MrARM> idk 20:25 < Drainedsoul> I guess I should do: fragmer: what does "non-directly-mappable" mean? o_o 20:26 <+SpaceManiac> Probably b/c bool doesn't have a corresponding NBT type 20:26 < MrARM> It can has something to casting. .. 20:30 < fragmer> yep, what SpaceManiac said. Types that do not have a direct analogue in NBT. 20:30 < fragmer> e.g. bool becomes byte, unsigned types become signed, char becomes short 20:34 < Drainedsoul> fragmer: What happens if the unsigned type is out of range? Throw? 20:35 < fragmer> I cast unsigned to signed of the same size. It always fits. 20:36 < Drainedsoul> so just directly map the underlying bits without any regard for what they represent? 20:36 < fragmer> Correct 20:37 < Drainedsoul> fragmen: Ah okay, that makes sense 20:37 < fragmer> I do mind the endianness, of course. A reverse cast on the other end will give the same number back. 20:37 < fragmer> I don't expect people working with NBT to actually be using unsigned values (aside from bytes) very often, honestly. I just wanted it implemented for completeness' sake. 20:42 < Drainedsoul> it's a shame that, unsigned values are beautiful --- Day changed mar. janv. 14 2014 00:20 < Chrisliebaer> Does someone know if the physics are computed on the client or on the server? Like player falling or movement from velocity? 00:21 <+sadimusi> most of the physics are calculated on the client 00:22 <+sadimusi> the server also keeps track of some things like dropped items and syncs with the client from time to time 00:23 < Chrisliebaer> perfect, thanks 05:38 < Eviltechie> Custom skins would be really cool, hint hint 05:38 < Eviltechie> Like modifying a skin to add a police uniform, team colors, etc 13:43 <+sadimusi> Eviltechie: unfortunately that won't be possible 13:45 < dx> sadimusi: do we know any implementation details? other than "the server tells the client something" 13:46 <+sadimusi> dx: https://twitter.com/dinnerbone/status/422752600073965568 "This will not mean that servers can give you custom capes/skins!" 13:46 <+sadimusi> apparently it's signed somehow 13:49 < dx> >If they do they'd have more fun breaking into banks with the giant security hole they found! 13:49 <+sadimusi> the servers don't even send the skin but a URL https://twitter.com/dinnerbone/status/422790133298266112 13:49 <+sadimusi> so it will be the exact same system? 13:49 < dx> no? 13:50 < dx> the current system is each client fetching the skin whenever they please 13:50 <+sadimusi> well, instead of just building the URL yourself you wait for the server to tell you the URL 13:51 < dx> i guess this adds change notifications, and is more cache friendly 13:52 <+sadimusi> so you think the only advantage is that your skin gets loaded by every other player the moment you join the game instead of when they get near you? 13:53 < dx> that would depend on when the server sends the packet with the skin url 13:53 < dx> and we don't know anything about that 13:54 < dx> i'm just saying that the url is probably constructed in a way that avoids unnecesary redownloads 13:54 < dx> and additionally they moved the polls for updates to the server side 13:55 <+sadimusi> this suggests that your skin is downloaded every time you join a server: https://twitter.com/dinnerbone/status/422752438031241216 13:56 < dx> hm makes sense 15:58 < MrARM> Even thought D-i-n-n-e-r-b-o-n-e said on twitter that servers won't be able to change it, will it be true? 15:59 < MrARM> If server downloads skins..? 16:00 < dx> MrARM: the server doesn't download skins, it sends a URL to the client 16:00 < dx> also how the fuck do i link tweets without pinging dinnerbro 16:00 < MrARM> So it can change it? 16:01 < dx> MrARM: it's "signed", whatever that means. some unspecified cryptography goes on to prevent the server from sending crap 16:02 < MrARM> I would like to make a cape for me on my server 16:02 < MrARM> dx MCP rocks! 16:02 <+sadimusi> dx: bitly 16:02 < MrARM> if bitly is cryptographic 16:02 < MrARM> ... 16:02 < dx> sadimusi: not a fan of that but yeah probably the most sensible option 16:02 < dx> MrARM: that was a reply to 'how to link without pinging dinnerbro' 16:03 < MrARM> oops 16:03 < MrARM> I didnt know SomethingNICKsomething can ping anyone. .. 16:03 < iBotPeaches> Smuxi is smart enough not to do that 16:03 < iBotPeaches> don't know about others 16:03 <+sadimusi> that really depends on your client 16:05 < dx> MrARM: you mean "D-i-n-n-e-r-b-o-n-e"? that won't ping him unless he really wants to get pinged by that 16:05 < MrARM> Yeah 16:07 < MrARM> Until client does foreach (char letter:nick) { if (!text.equals (letter)) return false;} return true; 16:07 < dx> wot 16:07 < MrARM> contains not equals 16:07 < MrARM> my mistake 16:07 < dx> oh 16:10 <+sadimusi> dx: dinnerbro just clarified a few things on twitter 16:10 <+sadimusi> most importantly, the skin URL will be included in one of the auth requests done by the server 16:10 < dx> oh, great, i was having issues with prepaid gift cards 16:10 < dx> like not being available in my country at all 16:11 * dx should check the stream that shows replies instead 16:13 < dx> "unfortunately my Litecoin miners are using too much of my resources. Mind if I implement into Bungee/Spigot ?" 16:13 < dx> md_5: funny guy 16:13 < Dinnerbone> Some game devs did that for bitcoin a long time ago, did they not? 16:14 < MrARM> So will I be able to replace my skin on my server or no? 16:14 < dx> haven't heard of that being done officially, but wouldn't be surprised if unofficial mods did that stuff 16:14 < dx> MrARM: no 16:14 <+sadimusi> MrARM: no 16:15 < MrARM> :( 16:15 < MrARM> Why? 16:15 < MrARM> If server sends URL..? 16:15 < Dinnerbone> No. This is not the server downloading your skins. This is not the server controlling your skins. This is the server just passing on two small pieces of information, and that's it. 16:15 < MrARM> So server doesn't send URL but just hashes? 16:15 < dx> Dinnerbone: would be cool to have a gist with technical details and a FAQ, to stop people from assuming dumb stuff 16:16 < Dinnerbone> Nothing stops people from assuming dumb stuff 16:16 < dx> well, "slow down" instead of stop? :D 16:17 < MrARM> Too bad :( I really wanted to do such thing 16:17 <+sadimusi> MrARM: everyone would want to do that, I guess that's why it isn't possible 16:18 < MrARM> Or to be able to upload own cape 16:18 < MrARM> heh, other skin on one server would be cool 16:18 < dx> capes are special because they are limited 16:18 < MrARM> I know 16:18 < dx> and skins.. they are the main reason to buy the game for some people 16:19 < dx> so commercially it makes a lot of sense to keep control of that 16:19 < MrARM> Heh... A mod? 16:19 < dx> yeah, has been done, several times 16:19 < dx> you can do that with an one line patch without even MCP, just change the skin fetch url 16:19 < dx> worth nothing, as nobody will use it 16:20 < MrARM> Actually not exactly I wanted to change skin, but cape 16:21 <+sadimusi> maybe I should start hashing skins as well, sooo many duplicate submissions :/ 16:28 < dx> every time i check twitter mentions to mojang employees i find classy gentlemen like this one http://dump.dequis.org/vj6Un.png 16:28 <+sadimusi> :D 16:29 < dx> :-)P emoticon of the year 16:30 < dx> i'm calling it - it's going to be bigger than :^) 16:30 <+sadimusi> :-)P 16:30 <+sadimusi> it's also always fun how people just reply to the last tweet when trying to mention somebody http://d.pr/i/4Fmo 16:31 < Dinnerbone> See his earlier tweets dx 16:31 < Dinnerbone> It was hilarious 16:32 < Dinnerbone> https://twitter.com/GusToughSon/status/422771607510056961 16:33 < dx> :D 16:33 <+sadimusi> "and i did read your "signed" or refused ive made shit on other games that "signed" itself again Anythings possible" 16:33 <+sadimusi> (https://twitter.com/gustoughson/status/422771080013418496) 16:34 < dx> anything is possible, you just need to be confident enough, believe in yourself, and others will use your shitty client mod 16:34 * Dinnerbone believes in dx 16:35 < MrARM> ol 16:35 < MrARM> lol 16:36 <+sadimusi> Dinnerbone: does the signature protect against replay? 16:36 < Dinnerbone> The contents of the message includes the ID of who it belongs to, and a timestamp 16:37 < MrARM> But it will be possible to replace skin by sending other users hash? 16:38 <+sadimusi> MrARM: you're not making any sense 16:38 < Dinnerbone> You can replay it for a little while if you kicked one user off and changed the id of someone to the user you just kicked, in theory. But don't do that. :D 16:38 < Dinnerbone> (May include protection against that, depending on how much I think that's going to be abused. I don't want people changing UUIDs of users for any reason) 16:38 < MrARM> I meant will it be possible to force change somebody's skin to somebody's other skin, who joined. 16:39 < Dinnerbone> No. The encrypted payload contains the userid of who it is for. The client will check this. You can only have one person with the same id, so this will not work 16:40 < MrARM> Hmmmm. Ok. 16:41 <+sadimusi> I wouldn't be surprised if someone bought 20 accounts, set their skins to team colors and then used their uuids in an arena game 17:20 < barneygale_> uhg 17:20 * barneygale_ doesn't understand this skin thing 17:23 < barneygale_> At first I though "oh, so servers cache skins and send them to clients" but apparently they only store a hash? So what's the system? 17:26 < dx> barneygale_: the servers ask mojang when was the skin updated, the server broadcasts the UUID + timestamp on join, the clients use that to know if it needs redownloading 17:26 < dx> or at least that's what i understood. i could be wrong 17:26 < barneygale_> ah OK 17:26 < Dinnerbone> A blob is returned on /hasJoined, server broadcasts blob to clients with the "add player" stuff 17:27 < dx> neat 17:27 < Dinnerbone> Blob contains skin/cape information 17:27 < Dinnerbone> That's it. 17:27 < barneygale_> makes sense 17:28 < barneygale_> using hmac or something/ 17:28 < barneygale_> ? 17:30 < dx> ~it is a mystery~ 21:52 < Thinkofdeath> Dinnerbone: Would the skin changes break disguise plugins? 21:52 < Thinkofdeath> e.g. heroes in DvZ 21:53 <+sadimusi> don't those just change your name? 21:53 < Thinkofdeath> sadimusi: but if the skin blob is got on join then the server couldn't send the skin with a fake player 21:54 <+sadimusi> true, unless you own the fake player 21:54 < Dinnerbone> You'd need an up-to-date blob from the real player 21:54 < Thinkofdeath> You would have to reauth each time 21:54 < Thinkofdeath> *re-/hasJoined 21:56 <+sadimusi> and that isn't a problem if you own the account 21:56 <+sadimusi> you don't even have to fake the name anymore, just the uuid 21:57 < Thinkofdeath> sadimusi: But if the account is in use by the server could the client still use it? 21:58 < Thinkofdeath> Because you can only be logged in at one place at a time 21:58 <+sadimusi> no, the account would be used exclusively for that purpose 21:58 <+sadimusi> you could for example buy 10 accounts and give them a red skin and 10 with a blue skin 21:59 <+sadimusi> and then let your server assign these uuids to the players in each team in some kind of mini game 22:00 < Thinkofdeath> sadimusi: I guess that would work 22:01 <+SpaceManiac> I imagine a texture packed red/blue headband helmet would be more effective, especially on large servers 22:01 <+sadimusi> [16:38:32] Dinnerbro: (May include protection against that, depending on how much I think that's going to be abused. I don't want people changing UUIDs of users for any reason) 22:02 <+sadimusi> SpaceManiac: it certainly is a lot easier to implement --- Day changed mer. janv. 15 2014 02:38 < Not-002> [fNbt] fragmer pushed 2 commits to master [+0/-0/±3] http://git.io/W34U-w 02:38 < Not-002> [fNbt] fragmer 71a3741 - Fixed a regression in serializing strings via NbtSerializationGen, caused by recent refactoring efforts. 02:38 < Not-002> [fNbt] fragmer 5e95c97 - First attempt at compiling serialization code for self-referential/cross-referential classes. Turned out a bit inefficient. Needs something more clever. 03:31 < TkTech> So the servers *do* cache the skin/cape image itself? 03:32 <+sadimusi> no, only the url 03:33 <+sadimusi> no, only the url 03:33 <+sadimusi> whoops 03:33 <+sadimusi> and the url is based on the hashed content of the skin 03:40 < TkTech> Ah, I was confused by what Dinnerbro said earlier, "[11:34] A blob is returned on /hasJoined, server broadcasts blob to clients with the "add player" stuff" 03:40 < TkTech> So it's just "broadcasting" the URL 03:42 < TkTech> Assuming there will be a client-side cache expiry, and a max cache size? 03:42 < TkTech> Otherwise this would be really easy to exploit 03:42 < dexter0> So it reduces traffic against the skin db but not the skin hosting (which has probably never been a bottleneck)? 03:43 < TkTech> Long, long time ago it was. For a very long time they've just been static assest on AWS S3 03:43 < TkTech> (So no, not a bottleneck. Possibly expensive, but a very small % of cost. 03:44 < dexter0> So what does Mojang gain from this change? 03:45 < TkTech> Skindex was the same, lookup was expensive but the images are so, so tiny when pngcrushed and what not that the costs are essentially 0) 03:48 < TkTech> I'm not sure, lots of guesses. 04:25 < Not-003> [bravo] edunham pushed 1 commit to master [+0/-0/±2] http://git.io/R1DHpA 04:25 < Not-003> [bravo] edunham 381bef1 - Move IRC to #bravoserver so we can kick spammers when necessary. 17:51 < morfin> hello how do you think is NBT optimal? 17:54 <+clonejo> morfin: Who claimed that? 17:55 < morfin> nobody :) 17:55 < morfin> just asked 17:56 < morfin> i think there can be issues with IO for that files format but not sure how to optimize 17:57 <+clonejo> There are definitely more efficient protocols for serializing dynamicly structured data 17:57 <+clonejo> (efficient in terms of size) 17:57 < morfin> my first idea was just mmaping :D 18:00 <+clonejo> if you don't plan on changing the world :p 18:01 < morfin> hm? 18:01 <+clonejo> um, what exactly do you want to use mmap for? 18:02 < morfin> load chunks et 18:02 < morfin> *etc 18:03 <+clonejo> the normal world save files don't work well for updating them frequently 18:04 < morfin> just remembered they're using huge regions 32x32 18:04 <+clonejo> also it's all compressed 18:04 < morfin> i've got files about 3-5M 18:04 < morfin> i beleive updating that is slow 18:05 <+clonejo> you probably don't want to store them uncompressed 18:06 < morfin> hehe 18:06 <+clonejo> also your cpu is faster at decompressing than the disk reading overhead introduced by the larger files 18:06 < morfin> i know 18:06 < morfin> but what about loading that 18:07 < morfin> need to decompress, load to memory(i think) and then update(with compressing) 18:07 <+clonejo> you don't have to save on every change 18:08 <+clonejo> even your filesystem doesn't do that (ext4 has a 60s write cache) 18:08 < morfin> hmm 18:11 <+clonejo> you could also use a different save format (maybe even separate files for different things, eg. entities and chunks) 18:11 <+clonejo> chunks should compress a lot better than entities 18:18 < morfin> not sure about ents 18:20 < morfin> i think if entities will be in separate files then there will be one more syscall to open 18:26 < morfin> interesting 18:27 < morfin> why not just let hostile mobs spawn after server has started? 19:25 < dividuum> is there a race condition free way to inject additional handlers into the netty pipeline for a player? 19:26 < dividuum> right now i'm doing that in onPlayerJoin, but I think I miss then JoinPacket an probably others, because they got sent before onPlayerJoin is called 19:26 < dividuum> My code is based on this: https://github.com/aadnk/ProtocolLib/blob/master/Examples/TinyProtocol/src/main/java/com/comphenix/tinyprotocol/TinyProtocol.java --- Log closed jeu. janv. 16 00:15:30 2014 --- Log opened jeu. janv. 16 00:15:38 2014 00:15 -!- Irssi: #mcdevs: Total of 149 nicks [1 ops, 0 halfops, 11 voices, 137 normal] 00:19 -!- Irssi: Join to #mcdevs was synced in 216 secs