17:59 < MrARM> 0 -1
17:59 < MrARM> 0 -1
17:59 < MrARM> 0 -1
17:59 < MrARM> 0 -1
17:59 < MrARM> 0 -1
17:59 < MrARM> Moving: 0 -1
17:59 < MrARM> Moving: 0 -1
17:59 < MrARM> Moving only two times
18:00 < MrARM> then the sequence gets correct agaij
18:00 < MrARM> again
18:01 < MrARM> I never get the 4 packets
18:07 < MrARM> so, we can't do anything with it
18:07 < MrARM> The full update fixes it mainly thigh
18:18 < morfin> hmmm
18:19 < morfin> i am wondering why server\client are reading varint until b & 0x7f is reached
18:19 < morfin> btw some mistake and that will cause problems
--- Day changed mer. mars 26 2014
11:11 < morfin> length of packet can be big right?
11:12 < Flemmard> define big ?
11:13 < morfin> as instance chat packet data can be up to 65535 bytes..
11:14 < Flemmard> http://wiki.vg/Protocol#Chat_Message
11:14 < morfin> oops up to 32767  bytes
11:14 < Flemmard> "Limited to 32767 bytes"
11:15 < morfin> i am going to limit my async_reads by length i readed first
--- Day changed jeu. mars 27 2014
08:12 < morfin> hello
08:42 < morfin> hmm
14:12 < morfin> anybody can tell me
14:13 < morfin> does Minecraft store length of string type in bytes(in varint) or in actual symbols
14:13 < morfin> so for UTF-8 length != bytes_number
14:17 < Thinkofdeath> number of bytes
14:20 < morfin> phew)
14:22 < morfin> it makes my life much easier because i am reading raw streambuf :)
19:59 < ARedHerring> evening gents, if anyone's got time, I could use some help on some variable length integer decoding - I apparently cannot seem to get it right
20:06 < ARedHerring> Long story short, I've looked at a lot of implementations on the 'net for varint encoding and I'm trying to basically simply read the packet header from Minecraft 1.7.4 packets that I'm listening to while intercepting a connection. I don't want to modify packets - just read them. Issue I'm having is when it comes to multiple bytes, the implementation shits itself. I'm using a library called 
20:06 < ARedHerring> BinData which is meant to take care of the endianness of the stream for me (even though this machine is in big endian anyway), however I'm getting numbers wildly off the charts (opcodes of 9million, for example)
20:08 < ARedHerring> you can find my code along with logs here: http://pastebin.com/F99bpMM8
20:08 < ARedHerring> any help is greatly appreciated
20:14 <+Fador> ARedHerring: I think you should be shifting n..
20:14 <+Fador> like this: n <<= 7; n |= (b&0x7f);
20:15 < ARedHerring> Giving a shot now, I found a java example of the varint on your wiki so I adapted to use that
20:16 < ARedHerring> gonna give it a run in a sec 
20:16 <+Fador> =)
20:16 < ARedHerring> original one I stole from beefcake (ruby google protocol buffer implementation)
20:16 <+Fador> https://github.com/Mineserver/mineserver.js/blob/master/lib/mcbuffer.js#L114
20:17 < ARedHerring> I did look at that, but I really can't read that one all well
20:17 < ARedHerring> it makes my head spin, and i don't know why lol
20:17 <+Fador> hmm, ok =)
20:18 <+Fador> well, I think that works but haven't really run any tests ;)
20:19 < ARedHerring> well I'm somewhat there
20:19 < ARedHerring> now I'm getting an end of stream
20:19 <+Fador> =/
20:19 < ARedHerring> varints look right though
20:20 < ARedHerring> http://pastebin.com/HgFhGi9C they make much more sense now
20:20 < ARedHerring> just gotta work out why it's dying on opcode 31 s->c
20:22 < ARedHerring> er... oh. that's confusing. the opcodes are all way too high
20:22 < ARedHerring> there's no 0x7E opcode and yet I see 126s there
20:25 <+Fador> so, how are you handling the encryption?
20:26 < ARedHerring> I haven't even gotten to that part, yet
20:26 < ARedHerring> I just want to get the packet headers for the majority
20:26 <+Fador> since after the C -> S packet 0x01 the whole protocol gets encrypted =)
20:26 < ARedHerring> oh
20:26 < ARedHerring> well i'm stupid
20:26 < ARedHerring> lol
20:27 < ARedHerring> why didn't I think of that
20:27 < ARedHerring> well 
20:27 < ARedHerring> my program is an observer
20:27 < ARedHerring> it connects my client to my server
20:27 < ARedHerring> also - 
20:27 < ARedHerring> it's localhost
20:28 < ARedHerring> your wiki says there's no encryption for localhost servers?
20:28 <+Fador> hmm, does that mean "offline" servers
20:28 < ARedHerring> Doesnt' matter to me, I'm not connectiong to a live server
20:28 < ARedHerring> if it means they have to be offline that's fine by me aha
20:29 <+Fador> there used to be an option for that in vanilla server but I'm not sure if it's there anymore
20:29 <+Fador> But if you are running the server like you normally would, I'm quite sure the protocol encryption is used =)
20:30 < ARedHerring> well, RIGHT F'N now I'm talking to a REAL server. If that is the case, that would certainly explain why I am getting EOF errors
20:35 < ARedHerring> And the JRE is screwing up with craftbukkit. I'm just going to play LoL instead. Much less frustrating. :p
20:35 <+Fador> =(
20:35 < ARedHerring> something about org.fusesource.whatever missing
--- Day changed ven. mars 28 2014
09:52 < ARedHerring> Just wanted to say thank you to whoever helped me yesterday (Fador, I think?) You helped me write a proper varint implementation :-)
09:52 < ARedHerring> https://github.com/DanPantry/angler/blob/82413f01408690aa2ec4feb771e802ea6032875e/lib/angler/net/varint32.rb
09:53 <+Fador> =)
09:53 < ARedHerring> Do you ever sleep? Lol
09:53 <+Fador> ..it's 11am in Finland ;)
09:54 < ARedHerring> aha, 9am here
09:54 < ARedHerring> just thought you might not have slept :P
09:54 < ARedHerring> oh well, I should probably work sometime today, speak later :-)
09:54 <+Fador> sure =)
11:15 < l4mRh4X0r> ARedHerring: there's a bug in your varint serializer
11:16 < l4mRh4X0r> buff.pack 'c' only packs the first element of the array
11:16 < l4mRh4X0r> Also, your status message is malformed
11:17 < l4mRh4X0r> (JSON uses double quotes, quote missing before "players", trailing comma after protocol version
13:21 < ARedHerring> l4mRh4x0r: Yeah, I noticed the c bug and have fixed accordingly. Status message was indeed wrong - but double quotes are a non-issue
13:22 < ARedHerring> http://prntscr.com/34t7p7
13:22 < ARedHerring> came up w/ that just shortly after 9
13:44 < l4mRh4X0r> Ah. Hmm, okay then.
13:44 < l4mRh4X0r> It's still not valid JSON, but if gson accepts it it's okay I guess.
--- Day changed sam. mars 29 2014
04:18 <+Amaranth> Is there an API to lookup a player's name for a given UUID?
04:22 <+Amaranth> Looks like it's only possible to go the other way around and the server does not store any name for them in their player data file
04:23 <+Amaranth> So given a directory of player data files on the latest snapshot I can't figure out who anyone is
04:24  * Amaranth shelves migration plan and assumes crash position
04:31 < shoghicp> Amaranth: is the name saved in the NBT data?
04:31 <+Amaranth> It does not appear to be
04:31 <+Amaranth> Grum said that was a planned thing so maybe it is in a newer snapshot, just realized mine is a little out of date
04:32 < shoghicp> Amaranth: https://sessionserver.mojang.com/session/minecraft/profile/<uuid>
04:32 <+Amaranth> Yeah I found that
04:33 < shoghicp> http://wiki.vg/Authentication#Player_Information
04:33 < shoghicp> ah :)
04:33 <+Amaranth> I don't know if I want to expose Mojang's servers to that
04:33 <+Amaranth> Because this is a Bukkit API...
04:34 <+Amaranth> Well, it'll only be until 1.7.6 I guess
04:35 <+Amaranth> At that point things will be UUID and we'll store the name in the player data, I think
04:39 <+Amaranth> shoghicp: Have you used that URL at all?
04:39 <+Amaranth> It seems really funky
04:40 <+Amaranth> If I do a valid UUID any other lookup that isn't valid gives me the last valid one without any sign of errors
04:40 <+Amaranth> But of course if I get someone else to go to the URL with incorrect data they get an empty page
04:40 < shoghicp> no, but I hope I'll have to use it in the next Minecraft: PE update
04:41 < shoghicp> Mojang ¬¬
19:31 < erai> how can i send a player to another world of the same type?
19:31 < erai> I see that the respawn packet has bugs according to the wiki.
20:44 <+SirCmpwn> I made this earlier today: https://blog.mediacru.sh/2014/03/29/Compliments-as-a-service.html
--- Day changed dim. mars 30 2014
00:38 < Brottweiler> dav1d: hi
01:16 < dav1d> Brottweiler: o/
01:17 < Brottweiler> :D
01:18 < Brottweiler> dav1d: are you busy?
01:18 < dav1d> Brottweiler: no but drunk
01:18 < dav1d> lol
01:18 < dav1d> Brottweiler: why?
01:18 < Brottweiler> :|
01:18 < Brottweiler> how drunk
01:18 < dav1d> not bad
01:18 < dav1d> Brottweiler: u playing oc.tc?
01:19 < dav1d> or what's the matter?
01:20 < Brottweiler> yes
01:20  * dav1d updating
01:20 < Brottweiler> xD
17:35 < morfin> hello
17:36 < morfin> who can tell me how many traffic sends client per second\minute?
19:51 < dav1d> Brottweiler: when does dino stream?
19:53 < Brottweiler> uhm, soon i guess maybe?
19:53 < Brottweiler> dunno actually the time, maybe like in a few mins
21:53 < dividuum> is there a way to teleport all players in a radius centered relative to the position of a command block? /tp @p[z=~10,r=18] <target> seems to do nothing
21:54 < dividuum> (in 1.7)
21:55 < dividuum> i guess a workaround might be to setblock a command block with a tp command to the center, then setblock a redstone block next to it. and then finally removing it all
--- Day changed lun. mars 31 2014
02:23 <+Amaranth> Grum or Dinnerbone: Does 1.7.6 and 1.8 require migrating to a mojang account to keep playing?
02:24 <+Amaranth> The sessionserver lookup code in the snapshots has a failure case for user not migrated which is worrying
02:27 < Dinnerbone> No it does not
02:27 < Dinnerbone> What code are you referring to?
02:30 <+Amaranth> Hrm, I can't find it anymore
02:31 <+Amaranth> It was some code in com.mojang.authlib, one of the error causes was UserNotMigrated or something
02:31 <+Amaranth> Ah it was YggdrasilAuthenticationService, UserMigratedException
02:31 <+Amaranth> So now I'm really confused :P
02:32 <+Amaranth> In any case, I tested the latest snapshot and it worked, should have done that before I asked
02:35 < Dinnerbone> When logging in to a migrated account using the username and not email, yes
02:35 < Dinnerbone> Unrelated to sessionserver code, that's in user authentication code
02:37  * Dinnerbone waddles off to sleep
11:16 < marabou> I'm trying to change held item bit I don't really know what the value should look like. I try sending Encoding.UTF8.GetBytes("5") as value but that wasn't right to select index 5 :(
11:17 <+sadimusi> why are you sending it as a string? it should be a byte/short depending on the direction
11:18 < marabou> im sending it as byre
11:18 <+sadimusi> yes, the string "5" encoded in ascii
11:18 <+sadimusi> just send 5
11:20 <+sadimusi> if you're not sure how to do that you could paste your code somewhere so I can take a look
11:20 < l4mRh4X0r> i.e. \x05
11:20 < l4mRh4X0r> Or however C#(?) solves it
11:21 <+sadimusi> doesn't (byte)5 work as well in C#?
11:21 < SinZ> should
11:22 < SinZ> there are converter functions to make it more foolproof
11:22 < marabou> http://pastebin.com/9FnR39bB
11:23 < SinZ> marabou: what socket are you using?
11:24 <+sadimusi> this might work: byte[] tocomplete_val = new byte[] {(byte) 5};
11:24 <+sadimusi> or even just byte[] tocomplete_val = {(byte) 5};
11:27 < marabou> Invalid hotbar selection (Hacking?) :(
11:28 <+Fador> tocomplete_len <- remove this
11:29 < SinZ> invalid hotbar selection, meaning it wasn't a byte with a value of 0-8
11:29 < marabou> if i remove len i got [Proxy] Lost connection to server. lol
11:30 < marabou> I'm new at this.. normaly I do web development :3
11:30 < SinZ> I would look into Craft.Net's MinecraftStream class
11:30 < SinZ> will make your life much easier
11:31 < marabou> ill check it out
11:31 <+Fador> hmm, wait, are you coding a client or a server?
11:33 < marabou> client
11:33 <+Fador> well that explains it =b
11:34 <+Fador> "tocomplete_len" should be just a zero-byte
11:34 <+Fador> ..because the item slot is short (two bytes)
11:37 < marabou> ooooh
11:38 < marabou> I think it works now, thank :9
11:40 <+Fador> =)
11:42 < marabou> Now I just gonna have to try place the block 
11:42 < SinZ> marabou: btw, only strings have a length prefix
11:43 < SinZ> (and arrays, but they have documented length parts)
11:44 < marabou> okey :)
14:14 < marabou> I do use 0x08 to place block from client right?
14:14 <+sadimusi> yes
14:15 <+sadimusi> did you have a look at Craft.Net?
14:15 < marabou> yes
14:16 < marabou> dont know how to aply it to my project
14:16 < marabou> "my" project
14:19 <+sadimusi> depending on what you're trying to build you can save a lot of time and trouble using it (or any other minecraft protocol library)
14:30 < marabou> I'm just trying to build a bot that will log on to a server and place a block, very minimalistic 
14:30 < shoghicp> well, it needs to know how to move, parse the map, and send correct values to the server
14:30 <+sadimusi> getting the encryption right might also take you some time depending on your experience
14:31 < l4mRh4X0r> marabou: maybe mineflayer is useful to you?
14:31 < l4mRh4X0r> Oh, wait, it says 1.6.2
14:31 < marabou> I will know the position I have and everything (it's the same everytime)
14:32 < marabou> so I'm gonna send the same package everytime I guess
14:35 < shoghicp> sadimusi: I remember the transition D:
14:38 <+sadimusi> shoghicp: remeber your hashing function from back then? http://pastie.org/4243927 :D
14:38 < shoghicp> well, technically, *it worked*
14:38 <+sadimusi> it sure did :)
14:38 < shoghicp> later I got a big number library and made it better
14:39 <+sadimusi> why can't you just use sha1() ?
14:40 < shoghicp> remember the sign things?
14:40 <+sadimusi> right
14:40 < shoghicp> sha1() in PHP returns hex or binary
14:40 < shoghicp> but without sign
14:40 <+sadimusi> but fixing that should be possible with way less code
14:40 < shoghicp> of course
14:40 < shoghicp> I did it later with less code
14:40 < shoghicp> and after that, in one line
14:43 < shoghicp> I wonder if I'll have to implement sessions in a few months
14:44 < shoghicp> at least we are getting lots of protocol improvements in Minecraft: PE ;D
20:01 < morfin> is there a way handle situation when user "lied" and sent bigger\smaller packet length than real length is?
20:06 < shoghicp> morfin: the stream desyncs, but you can try  to get to a magic value
20:07 < shoghicp> I think that the normal MC server kicks you when it does not expect a packet
20:58 < morfin> i saw something like that
20:59 < morfin> asctually yes, if i send length 10, but length is 20 next packet is being readed from byte 11 so it would be some unknow packet
23:50 <+sadimusi> coinbase seems really developer friendly, after sending just 14 test IPNs I get "You have exceeded the maximum number of test callback attempts for today.  Please wait 24 hours and try again." :D
23:51 <+AndrewPH> >restricting test usage
23:51 <+AndrewPH> >pls
23:52 <+sadimusi> I also love the fact that there's no way to verify a IPN is genuine. you just have to obfuscate the callback url :D
--- Day changed mar. avril 01 2014
08:07 < marabou> when I'm sending a player block placement from client do I need to pass along all the values http://wiki.vg/Protocol#Player_Block_Placement ?
08:08 <+sadimusi> yes
08:09 < marabou> "slot" isn't just a number in this case?
08:09 <+sadimusi> no. http://wiki.vg/Slot_Data
08:14 < marabou> so how would it look like if you had one dirtblock?
08:14 < marabou> or what ever block
08:16 <+sadimusi> 0001 01 0000 ffff
08:16 <+sadimusi> there are some more examples in the wiki
08:17 < marabou> could direct me?
08:17 < marabou> could you*
08:17 <+sadimusi> http://wiki.vg/Slot_Data
08:17 < marabou> i thought you ment more than thoes lol
08:18 <+sadimusi> you would really be better off using craft.net ;)
08:18 < marabou> cant compile it, missing shit.
08:18  * sadimusi starts sounding like SirCmpwn 
08:18 < marabou> and gon'r really understand what's happening 
08:18 < marabou> don*t
08:19 < marabou> 0001 is the item count, 01 dmg, whats 0000 ffff then?
08:19 <+sadimusi> 0001 is the id, 01 the count, 0000 the damage and ffff the length of the nbt data
08:19 <+sadimusi> ffff is -1
08:20 < marabou> oh
08:20 < marabou> 0002 is grass block then
08:20 < marabou> right?
08:20 <+sadimusi> yes
08:30 < marabou> id an item has this id #0397/3 what would I do with the /3?
08:30 <+sadimusi> that's the damage value
08:31 < marabou> really?
08:31 < marabou> what's dmg value really?
08:32 <+sadimusi> for tools like pickaxes it stores the uses
08:32 < marabou> but a tool doesn't have /# in their Id?
08:32 < marabou> but flowers do
08:33 <+sadimusi> for tools the damage changes every time you mine a block
08:33 <+sadimusi> and it starts at 0
08:33 <+sadimusi> flowers on the other hand use the damage value to differentiate the different versions
08:33 <+sadimusi> the same is used for wood types, door orientation and so on
08:34 < marabou> okey so the server will handle that so I'll just accept it lol
15:01 <+SirCmpwn> marabou: do you want help compiling Craft.Net?
15:13 < Not-001> [node-minecraft-protocol] roblabla pushed 6 commits to master [+0/-0/±25] http://git.io/TTF4DQ
15:13 < Not-001> [node-minecraft-protocol] deathcap 0cd3ed1 - Add packet names
15:13 < Not-001> [node-minecraft-protocol] roblabla 244ad8e - Use ProtocolLib naming scheme. Use hasOwnProperty instead of equality
15:13 < Not-001> [node-minecraft-protocol] roblabla 2f90252 - Merge upstream, fix mistakes in examples
15:13 < Not-001> [node-minecraft-protocol] ... and 3 more commits.
23:19 < ARedHerring> fucking BT, I pay £40 a month for my router to continually cycle for no reason
23:35 < dx> wat
--- Day changed mer. avril 02 2014
00:52 <+clonejo> ARedHerring: can't you use your own router?
00:55 < benbaptist> is there any way to avoid these villager skins? I've tried faking the skin servers, changing the date, etc.
00:55 < benbaptist> I'm confused as to where the code is to fix this. :P
00:57 < shoghicp> I think the servers itself are sending the skins
00:57 < shoghicp> just wait a few hours
01:02 < benbaptist> shoghicp, The server seems to be sending the actual skins - I tried overriding it 
01:02 < shoghicp> yeah, I was just reading about that
01:02 < benbaptist> and they should'
01:02 < benbaptist> and they should've went back to the old skins a few hours ago, I think. I really need to do something but I can't due to the skins. :P
01:03 < shoghicp> well, a few places are not in 2/04
01:07 < benbaptist> hmm
01:07 < benbaptist> so is it not minecraft.net or s3.amazonaws.com that sends the message to use the villager skins?
05:11 < morfin> villager skins are in game i think
05:13 < morfin> i mean in resources
--- Log closed mer. avril 02 13:45:09 2014
--- Log opened mer. avril 02 13:45:18 2014
13:45 -!- Irssi: #mcdevs: Total of 134 nicks [1 ops, 0 halfops, 12 voices, 121 normal]
13:49 -!- Irssi: Join to #mcdevs was synced in 268 secs
--- Day changed jeu. avril 03 2014
07:31 < gre-> hello :)
07:42 <+SirCmpwn> hello, gre- 
07:43 < gre-> all of you here are python coders?
07:43 < gre-> someone adviced me to join this channel
07:43 <+SirCmpwn> not all, but many
07:43 < gre-> ok
07:52 < gre-> http://pastebin.com/f9J1W02c
07:52 < gre-> im trying to create a script to add some commands on a vanilla mc server actually
07:52 < gre-> i did but
07:53 < winny> I find your style hard to follow
07:53 < gre-> i can't manage to create a command for my .tphere because syntax is different than .apple
07:54 < winny> i admire sticking to vanilla, i don't like bukkit either.
07:55 < gre-> i don't like mc servers with many plugins, many portals, many signs, its making me crazy
07:55 < gre-> and its less fun, idd
07:55 <+SirCmpwn> I think it would be easier to run it in a screen or tmux session
07:55 <+SirCmpwn> and then just talk to that
07:56 < gre-> SirCmpwn: the script i just pasted works with mcsuperserver
07:56 < gre-> so i can run it with a screen ofc
07:58 <+SirCmpwn> what is mcsuperserver
07:58 < gre-> a .py script
07:58 <+SirCmpwn> I had worked that out on my own, thanks
08:02 < winny> you should share mcsuperserver.py because it's hard to get ahold of if you don't want to share your email... http://members.iinet.net.au/~paulone/zip/mcsuperserver.py
08:02 < gre-> you can give a fake email
08:02 < winny> still feels wrong
08:02 < winny> anyways the above link is direct
08:03 < gre-> a new author of this script sent me a compatible mcsuperserver for 1.7
08:03 < winny> excellent
08:03 < winny> do you have it posted somewhere? I may find use out of it!
08:05 < gre-> you can find it easily on google, can't remember the link
08:05 < gre-> you will find it on a forum
08:06 < winny> I see it. https://dl.dropboxusercontent.com/u/44836193/mcsuperserver/mcsuperserver_1_7.py
08:07 < gre-> yep
14:46 <+sadimusi> gre-: are you still around?
17:06 < mbaxter> 1.7.6pre is out! Hurray!
17:16 < Not-001> [mcprotocol] thinkofdeath pushed 2 commits to 1.7.X [+1/-1/±197] http://git.io/JtU6IA
17:16 < Not-001> [mcprotocol] thinkofdeath 1b671fe - 1.7.5
17:16 < Not-001> [mcprotocol] thinkofdeath 4002e0a - 1.7.6-pre1
20:26 <+SirCmpwn> Microsoft released their C# compiler under the apache 2 license today
22:59 < winny> what about the .net runtime?
23:37 <+SirCmpwn> still closed, but their stuff runs on Mono's runtime
23:37 <+SirCmpwn> if I had to guess what the last thing to be opened will be, it'll be the runtime
23:37 <+SirCmpwn> it's the only thing convincing people to buy windows server :P
23:43 < winny> that's rather cool
--- Day changed ven. avril 04 2014
04:47 < gre-> i am sadimusi
05:09 < dx> commas are important
05:09 < dx> or better just say "sadimusi: i am"
05:10 <+sadimusi> dx: you're yoda?
05:10 < dx> sadimusi: hah
05:12 <+sadimusi> anyway, I don't think I should start a discussion at 5am :D gre-, if you still need help I'll be back tomorrow
05:13 < winny> i think gre- lives in europe
06:33 <+SirCmpwn> speaking of sadimusi 
06:33 <+SirCmpwn> b.wiki.vg is still borked and sadimusi won't talk to me about it :(
06:40 < umby24> does BV just read changes by parsing the protocol page?
06:40 < winny> what does BV do even
06:40 < umby24> BV shows differences in the protocol between versions
06:40 < dexter0> among other things
06:41 <+SirCmpwn> BV doesn't parse the protocol page
06:41 <+SirCmpwn> it parses binaries
06:41 < umby24> it parses the minecraft binaries?
06:41 <+SirCmpwn> correct.
06:41 < umby24> k
06:41 < winny> how do i make sense of the differences in entities
06:41 <+SirCmpwn> and thus is breaks often
06:41 < umby24> thanks :D
06:41 < winny> 1.6.1 -> 1.6.2
06:43 < umby24> yeah making something to parse the protocol page is simple enough.. binaries doe, much kudos
06:43 < winny> does BV show full sources?
06:43 < winny> for context
06:49 <+SirCmpwn> winny: no
06:49 <+SirCmpwn> winny: it's intended to be a clean-room tool
06:52 < winny> how do i figure out what a, b, var2 etc should be?
06:52 <+SirCmpwn> that's up to you
06:52 <+SirCmpwn> this is a tool to aid reverse engineering
06:52 <+SirCmpwn> not a reference
06:52 < winny> I see
06:52 < winny> I understand BV, now (lol)
06:53 < winny> so why did it break?
06:53 <+SirCmpwn> refactoring within Minecraft itself causes it to stop working from time to time
06:53 < winny> where is sources
06:53 < dexter0> https://github.com/mcdevs/Burger
06:55 < winny> maybe somebody should open a ticket
06:55 < winny> https://github.com/mcdevs/Burger/issues
06:55 <+SirCmpwn> I guess it's not just a tool for RE
06:55 <+SirCmpwn> I've used it from time to time for code gen
06:56 < winny> how does that work?
06:56 < winny> it sounds complex to me
06:56 <+SirCmpwn> it spits out a bunch of JSON
06:56 <+SirCmpwn> with things like packet structure, constants, whatever
06:56 < winny> man i kind of want to write a setup.py
06:56 < winny> it feels weird being a tool useful to so many people and not packaged
06:57 <+SirCmpwn> it's really only useful to this channel
06:57 < winny> lol.
06:57 <+SirCmpwn> and not everyone in it, too
07:13 < TkTech> There are enough humans looking at new releases now that the wiki gets updated quickly regardless.
07:13 < TkTech> Burger was written at a time when there were only a few of us and it took longer to update the wiki.
07:14 < TkTech> (And the binaries were more stable, they didn't have frequent refactors breaking it)
07:16 <+SirCmpwn> I would still like burger to update for the sake of the constants :/
15:31 <+sadimusi> SirCmpwn: At this point it makes more sense to rewrite Burger completely than trying to fix it. Maybe I'll find time during the next semester break, currently there's just too much other stuff going on
15:32 < shoghicp> sadimusi: the output will be kept the same, right?
15:32 <+sadimusi> of course
15:33 < shoghicp> good :)
15:33 <+sadimusi> but unlike the current version I'm planning on writing most of it in Java so I can directly access things like blocks or recipes
15:34 <+sadimusi> the protocol parser will still be python though 
15:35 < shoghicp> I'm sure that I'll have to rewrite PocketBurger for 0.9.0
15:35 < shoghicp> I learnt a bit more about ARM and assembly, so let's do it right this time
16:22 <+SirCmpwn> sadimusi: let me know if I can help
16:22 <+SirCmpwn> I've been learning more and more python lately, maybe I can assist
21:47 < TheUnnamedDude> Does 1.7.6 use the snapshot protocol?
22:08 < Thinkofdeath> TheUnnamedDude: Only the spawn player changes and uuids include '-'s
22:08 < TheUnnamedDude> Ahh, so a translator will be pretty simple then
22:09 < TheUnnamedDude> tnx u veri mush
22:42 < MrARM> I wonder, does local multiplayer work offline in 1.7.6...
22:46 < MrARM> Nah, player name is sent too so it should work
22:46 < MrARM> I thought that they will finally fight offline servers
22:50 < Thinkofdeath> MrARM: They wont have the skins of the player who's name they are using
22:51 < MrARM> At least this
22:51 < MrARM> Think, I think they can fake the UUID, can't they?
22:52 < Thinkofdeath> Currently but I believe that is planned to change in 1.8
22:53 < MrARM> Think but... how..? These are probably saved in launcher_profiles.json and i dont think it will get changed... Of course they can turn off uids in vanilla server. 
22:53 < MrARM> (offline mode only)
22:54 < Thinkofdeath> The server gets the needed info for downloading the skins from the session server and then forwards that to each client
22:54 < MrARM> yes
22:54 < Thinkofdeath> the data is signed so if its faked the client will disconnect
22:54 < Thinkofdeath> (well should, that part isn't done yet)
22:55 < MrARM> this way...
22:55 < MrARM> I wonder who will break it first. 
22:55 < Thinkofdeath> Its rsa so good luck :)
22:55 < MrARM> Always, they can mod the server
22:55 < Thinkofdeath> You'll need to mod the client not the server
22:56 < MrARM> So all non premium clients will require a mod to connect a server at all?
22:56 < Thinkofdeath> No, only if they want skins
22:57 < MrARM> That's bad
22:57 < MrARM> And what with local multiplayer? 
22:57 < Thinkofdeath> Not sure how that will work
23:16 < dav1d> did mojang ever care about pirating?
--- Day changed sam. avril 05 2014
13:29 < Grum> <Thinkofdeath> [22:54:52] the data is signed so if its faked the client will disconnect <-- nah it just wont load the skin; so you'll be steving about
13:30 < Grum> signed and timestamped; so evne if you obtain 'legal blobs' to send to the clients you will have to keep refetching them
13:30 < Grum> which is doable; but at rate you might as well be an online server :P
13:31 < Thinkofdeath> true :)
13:31 < Grum> (because you need a client logging on onto an online server to obtain the skin-blob)
13:31 < Thinkofdeath> What about https://sessionserver.mojang.com/session/minecraft/profile/4566e69fc90748ee8d71d7ba5aa00d20 ?
13:31 < Grum> its mostly to stop sending this retardo amount of data
13:31 < Thinkofdeath> it returns a valid skin blob right?
13:32 < Grum> that wont be able to be used for skins other than your local player and skulls
13:35 < Thinkofdeath> Oh I see, the '"isPublic":true' part
13:35 < Grum> yuppers
13:36 < Thinkofdeath> So what would a client do if you spawned two players with the same blob (and username/uuid)?
13:38 < Grum> pretend it sees two
13:38 < Grum> i think
13:38 < Grum> i dont think we force-unique them @ client; on the server
13:38 < Grum> +we do iirc
13:39 < Thinkofdeath> Good to know
--- Day changed dim. avril 06 2014
21:12 <+SirCmpwn> hey sadimusi, would it be possible to generate block/item data from burger? That's all I need from it, packet structure is less important
21:17 <+sadimusi> SirCmpwn: packets are not the hard part, blocks and items changed a lot as well
21:18 <+SirCmpwn> sadimusi: well, just trying to find a way to make it an easier task to tackle
21:18 <+SirCmpwn> I need to generate block/item code
21:27 <+sadimusi> SirCmpwn: what exactly would you need for each block?
21:28 <+SirCmpwn> anything I can get
21:28 <+SirCmpwn> the ID, name (i.e. "minecraft:dirt"), hardness, light info
21:28 <+SirCmpwn> the friendly name would also be good
21:28 <+SirCmpwn> the recipie would be great
21:29 <+SirCmpwn> I need items, too
21:34 <+sadimusi> you can easily get the name and hardness with a short java class iterating over minecraft's block storage
21:35 <+sadimusi> recipe would probably be a bit harder and the friendly name is in the language files
21:36 <+sadimusi> (a very basic example: https://gist.github.com/sadimusi/f81646e747bcce96c7df )
22:28 <+SirCmpwn> I know approximately 0 java, fyi
22:30 < dx> it's the same as C#, but uglier
22:32 <+SirCmpwn> I mean, I don't have an enviornment or the knowledge of how to do things like iterate over minecraft's blocks
22:33 <+SirCmpwn> basically, if anyone does have that knowledge, your help'd be wonderful
22:33 < dx> oh, right. i wouldn't know how to do that. probably some classpath related magic
22:36 < MonsieurApple> Grum: Apologies, I created this issue before realizing skins were not supposed to load in offline mode https://bugs.mojang.com/browse/MC-52564
22:37 < MonsieurApple> I would appreciate it if you closed it
--- Day changed lun. avril 07 2014
01:46 < dividuum> any idea what the incompatible change in the 1.7.6 protocol is?
01:46 < shoghicp> uuid
01:46 < dividuum> for teams?
01:47 < shoghicp> no
01:47 < shoghicp> users
01:47 < shoghicp> unique user ID
01:48 < shoghicp> there is info about that in mojang.com
01:49 < dividuum> ok. how does this change end up in the protocol? the spawn player packet already had that field.
01:49 < Thinkofdeath> dividuum: Two changes, Spawn Player is the same as the snapshots, all uuids now have the '-' back in them
01:50 < dividuum> thanks. so the new spawn player also has the data field?
01:51 < Thinkofdeath> yep
01:51 < dividuum> thanks a lot. was curious about what changed and i didn't see any wiki changes so far
01:51 < Thinkofdeath> The client seems to ignore it in my tests, the skin is based on the uuid instead
01:52 < dividuum> so the skin url is based on some template and includes the uuid?
01:52 < Thinkofdeath> By the looks of it
01:53 < dividuum> i guess the new skin layout wasn't backported?
01:53 < Thinkofdeath> nope
02:16 < Eviltechie> Does anybody know what mojang did to skull items and blocks?
02:16 < Eviltechie> Is the owner now a uuid?
02:17 <+sadimusi> Thinkofdeath: are you sure about the new skin format not being backported?
09:11 < Thinkofdeath> sadimusi: yep, http://www.reddit.com/r/Minecraft/comments/223v28/176_prerelease/cgj6hc4?context=3
18:13 < TheRay_> hey can anyone help me wiwth my problem? when i try to import the CraftPlayer class in my project (for a custom bukkit/spigot) it throws me the following error: The return types are incompatible for the inherited methods LivingEntity.getLastDamage(), CraftLivingEntity.getLastDamage()
--- Day changed mar. avril 08 2014
11:31 < dav2d> Brottweiler: brb reboot
--- Log closed mar. avril 08 11:39:52 2014
--- Log opened mar. avril 08 11:55:00 2014
11:55 -!- Irssi: #mcdevs: Total of 125 nicks [1 ops, 0 halfops, 10 voices, 114 normal]
11:59 -!- Irssi: Join to #mcdevs was synced in 275 secs
--- Log closed mar. avril 08 12:39:48 2014
--- Log opened mar. avril 08 12:40:38 2014
12:40 -!- Irssi: #mcdevs: Total of 121 nicks [1 ops, 0 halfops, 10 voices, 110 normal]
12:45 -!- Irssi: Join to #mcdevs was synced in 275 secs
14:17 < Not-001> [mcprotocol] thinkofdeath pushed 1 commit to 1.7.X [+0/-0/±38] http://git.io/9rgMOw
14:17 < Not-001> [mcprotocol] thinkofdeath dbfaa96 - 1.7.6-pre2
15:39 < TkTech> TheUnnamedDude: Banned from what?
15:40 < SinZ> I think it was just chanserv reapplying all the bans as the channel was completely empty due to the full restart of freenode
15:48 < TkTech> Ah, my backlog would have filtered all those messages out.
17:02 < Not-001> [node-minecraft-protocol] roblabla pushed 3 commits to master [+0/-0/±6] http://git.io/aBCP3g
17:02 < Not-001> [node-minecraft-protocol] roblabla c0ba7f8 - Proper generic read/write/sizeOf functions
17:02 < Not-001> [node-minecraft-protocol] roblabla 457df31 - Container, array, buffer and count types added
17:02 < Not-001> [node-minecraft-protocol] roblabla 82c45bc - Merge pull request #79 from roblabla/feature-containers Container and array data types
--- Day changed mer. avril 09 2014
09:02 < TheUnnamedDude> Ehr, what was the changes in 1.7.6 again?
09:02  * TheUnnamedDude forgets easily
09:47 < TheUnnamedDude> Did they revert it in prerelease 2?
10:48 < Not-001> [mcprotocol] thinkofdeath pushed 1 commit to 1.7.X [+0/-0/±99] http://git.io/-BnZ3Q
10:48 < Not-001> [mcprotocol] thinkofdeath 05d3cc7 - 1.7.6
12:34 < dividuum> I guess the "signed" skin part also include some kind of expiration date? So that SpawnPlayer packets cannot be reused indefinitely ? If that's the case, can the "Player Information" session server endpoint be used to fetch a new valid skin?
12:46 < Thinkofdeath> dividuum: It looks like they expire after a day and the information returned from Player Information isn't valid in SpawnPlayer
12:47 < dividuum> crap. so all miners movies recordings will be a giant steve fest :(
12:53 < dividuum> 1.7.6 reuses protocol version 5 from 14w02a!? 
12:58 < Thinkofdeath> yeah
14:02 < dividuum> on further investigation it looks like the 'texture' data field is optional.
14:03 < dividuum> I hope that's intended. but i guess it is, because otherwise all kind of lobby servers that show fake donator players would break
14:06 < Thinkofdeath> In 1.7.6 is it, I believe in 1.8 it wont
14:09 < dividuum> what's the main purpose of that change? removing load from the skin server seems to be the major reason as far as I can tell. or is this some kind of piracy thing to that justifies the crypto part
14:10 < dividuum> using the signature to push skin changes through potentially untrustworthy server seems smart. but optional out of band skin fetching (from the client) would break any of that
14:11 < dividuum> *wouldn't
14:12 < dividuum> or am I missing something, @dinnerbone?
15:42 <+Amaranth> dividuum: They want to reduce the load on their infrastructure but they don't want servers to be able to give players arbitrary skins
15:42 <+Amaranth> So the skin lookup goes through the server but is signed so the server can't modify it
15:50 < dividuum> yeah. that's a smart thing to do.
15:51 < dividuum> but making the 'texture' data field in the spawn player packet optional doesn't prevent or hurt that:
15:52 < dividuum> normal servers would send the 'texture' field, making it possible for the client to deduplicate or cache the skin sent in there
15:53 < dividuum> if the 'texture' field is not there, fetching the client using https (based on the player uuid) would also allow to cache the result (as the skin base url is hardcoded and the skin is based on the uuid. 
15:53 < dividuum> So even if there server sends a wrong uuid, the client would cache the corresponding skin
15:53 < dividuum> as far as i can tell, the 'texture' field could be optional without hurting mojang. but maybe I'm missing something
15:55 < dividuum> Oh. And offline servers don't have the player uuid (since they get it from the hasJoined response). So I guess an unmodified offline server couldn't make clients show correct skins (which may or may not be intended)
21:33 < Thinkofdeath> Grum: Out of interest does the player skin blob actually do anything in 1.7.6? Setting the UUID seems to be enough
21:39 < Grum> Thinkofdeath: how do you mean: 'enough' ?
21:39 < Thinkofdeath> The client downloads the skin with only the uuid
21:39 < Thinkofdeath> username doesn't matter either
21:40 < Grum> online or offline server?
21:40 < Thinkofdeath> online
21:41 < Grum> i'm not really sure how you mean 'setting the uuid is enough'
21:41 < Grum> are you preventing the skin-blob from arriving @ client?
21:42 < Thinkofdeath> Its a protocol patched 1.7.5 build, I only send the uuid and not the skin blob
21:42 < Grum> and you see skins for everyone or jut yourself?
21:42 < Thinkofdeath> Everyone
21:43 < Thinkofdeath> Its been tested by quiet a few people now as its the latest spigot build
21:44 < Thinkofdeath> *quite
21:52 < Grum> I'm not actually sure
21:52 < Grum> unless ofc not 1.7.7 client
21:53 < Thinkofdeath> Works on 1.7.6 and 1.7.7 fine
21:54 < Thinkofdeath> Strangely I did have to add the skin blob to player skulls so it works there
22:02 < Grum> yeah something smells rotten
22:02 < Grum> Thinkofdeath: what are you making up as 'gameprofile' ?
22:03 < Thinkofdeath> Grum: https://github.com/SpigotMC/Spigot-Server/blob/master/src/main/java/net/minecraft/server/PacketPlayOutNamedEntitySpawn.java#L65
22:08 < Grum> yeaaah lets just say that it shouldnt be like that ;)
22:08 < Thinkofdeath> :P
22:09 < Thinkofdeath> Is there any benefit for me adding the skin blob? 
22:09 < Grum> you cannot obtain it trivially
22:10 < Grum> well you might be able to
22:10 < Grum> i mean you should get it as reply :)
22:10 < Grum> from the auth-server
22:10 < Thinkofdeath> That means updating authlib :(
22:10 < Grum> yeah from tomorrow that will be fixed; pushed commit already
22:11 < Grum> so no skins on fake servers
22:11 < Thinkofdeath> Will that be a 1.8.X or 1.7.X ?
22:11 < Grum> not sure; its a one-char-fix in theory; might patch 1.7.7
22:12 < Thinkofdeath> Well a large amount of servers are going to suddenly lose skins :P
22:12 < Thinkofdeath> oh that breaks bungee's trick
22:12  * Thinkofdeath gets to work
22:12 < Thinkofdeath> Should be interesting to fix
22:16 < dividuum> grum, so the skin blob is required from now on for player spawn packets to have their skins displayed?
23:37 < gre-> hi
23:38 < Eviltechie> hello
23:41 < gre-> hi Eviltechie , did you test 1.7.7 new minecraft server?
23:43 < Eviltechie> Nope!
23:43 < Eviltechie> Haven't touched a minecraft server in a long time.
23:43 < Eviltechie> When mine crashed last, I decided to shut down for good.
23:44 < gre-> spawn-protection=16 is enabled in my server.properties, im not opped at all (ops.json file or "op nick" command in console) but i can break blocks in spawn location, any idea?
23:45 < gre-> is there a notch channel on freenode? :P
--- Day changed jeu. avril 10 2014
12:47 < Grum> Thinkofdeath: aaand that change is life
12:47 < Grum> live! :'(
12:47 < Thinkofdeath> Grum: noticed :(
12:47 < Thinkofdeath> Had a flood of people coming in already
12:48 < Grum> no more fakey-fakey --- this includes sending a coloured nickname
12:48 < Thinkofdeath> Trying to get the updated authlib working now
12:49 < Thinkofdeath> For some reason the console stops working when I add it and its dependencies o.O
12:52 < Grum> awesome
12:52 < Grum> it barely has deps though
12:52 < Thinkofdeath> lang3 and commons-io
12:53 < Grum>     compile 'commons-codec:commons-codec:1.9'
12:53 < Grum>     compile 'commons-io:commons-io:2.4'
12:53 < Grum>     compile 'com.google.code.gson:gson:2.2.2'
12:53 < Grum>     compile 'org.apache.commons:commons-lang3:3.1'
12:53 < Grum>     compile 'org.apache.logging.log4j:log4j-api:2.0-beta9'
12:53 < Grum>     compile 'org.apache.logging.log4j:log4j-core:2.0-beta9'
12:53 < Grum>     compile 'com.google.guava:guava:15.0'
12:53 < Grum> ok quite some, but many overlap with whatever the game has :)
12:54 < Thinkofdeath> Pretty sure bukkit pre-shades them so it wont find them :(
12:55 < Grum> yeah it moves them, which is good
14:14 <+Amaranthus> Grum: Wait, I can't use a colored nickname anymore? :(
14:14 <+Amaranthus> Eh, whatever, it was just a nice touch that people in ModMode didn't lose their skin
14:19 < SinZ> coloured nicknames were the best
14:19 < SinZ> but you could hack around it by saying they are team blue or something
14:19 < MrARM_> Amaramthus In chat you will be able to do it
14:20 < MrARM_> By sending server messages
14:21 <+Amaranth> MrARM_: I know you can still do it in chat, we have API for that :P
14:21 <+Amaranth> But that's not as cool, I was kind of hoping to make our display name also be the name above their head... which is exactly what Mojang doesn't want happening
14:21 <+Amaranth> Right then, never mind
14:22 < SinZ> yup, they want to control how people enjoy their sandbox experience
14:23 <+Amaranth> They want skins and names to be in the control of the player, not the server
14:23 < MrARM_> Hmmm
14:23 < MrARM_> This will also break the display-player-health mods :/
14:23 < MrARM_> (server mods)
14:24 <+Amaranth> You can use the scoreboard for that
14:24 < MrARM_> not same
14:24 < MrARM_> It was displaying it over player head
14:24 <+Amaranth> Doesn't the client even draw hearts now when you tell it to show the health stat under their name?
14:24 < MrARM_> Does it???
14:24 <+Amaranth> The scoreboard has the ability to add a second line above the players head showing some score
14:24 < MrARM_> hmm
14:24 < MrARM_> k
14:25 < MrARM_> Nah
14:25 < MrARM_> I think it won't break... I think it uses a hack with name tags
14:26 < Dinnerbone> <SinZ> yup, they want to control how people enjoy their sandbox experience
14:26 < Dinnerbone> Yup, by disallowing servers from controlling how players wanted themselves to look. This just happened to be a byproduct of that.
14:27 < MrARM_> However that would be useful on some servers, especially when players want the server to change it...
14:27 < MrARM_> like their name to add a [OP] or [VIP]
14:27 < prplz> you can add that with teams
14:27 < Dinnerbone> ^
14:27 < Dinnerbone> You can even do that in vanilla.
14:28 < MrARM_> You can add something to the beggining of the name?
14:28 < Dinnerbone> Yes. Even in vanilla.
14:28 < prplz> yes
14:28 <+Amaranth> A prefix or suffix can be added via the scoreboard and you can add some score below their name
14:28 < prplz> add the player to a team and set the team's prefix
14:28 <+Amaranth> The prefix can include color codes which apply to the name too
14:28 < prplz> heaps of servers already do this
14:28 < MrARM_> ah ok
14:28 <+Amaranth> The only problem is players can only be on one team
14:28 < MrARM_> hmmm
14:29 < MrARM_> add a middle team?
14:29 <+Amaranth> So if you want people to have special prefixes and also want to use teams for, well, teams you're screwed
14:29 <+Amaranth> Teams can have neat things like no friendly fire and being able to see invisible team mates
14:29 < prplz> another cool thing to note is you can make multiple scoreboards to give different players different views on these
14:29 < prplz> really nice for a server with complex clan to clan relationships
14:29 <+Amaranth> That is definitely not vanilla :)
14:30 < MrARM_> Well if you have 2 ranges and  you want a user to be on both of them add a third scoreboard which connects it
14:30 <+Amaranth> But that doesn't really solve the problem
14:30 <+Amaranth> You can only tell the player about a single scoreboard
14:30 < MrARM_> Yes, but half of servers are Bukkit, not Vanilla
14:30 < MrARM_> Right, so make a third one
14:30 < MrARM_> With both suffixes
14:30 <+Amaranth> So you can't tell Player A that Player B is on their team so don't attack them and also tell them Player B has an [OP} prefix
14:31 < prplz> friendly fire prevention is controlled by clients?
14:31 < MrARM_> hmmmm
14:32 <+Amaranth> Well, no, you can always block it server side
14:32 < MrARM_> I wonder can you work around that with Bukkit
14:32 < prplz> i mean, in vanilla is it?
14:32 <+Amaranth> But the client won't even try to attack if they're on a team with no friendly fire, iirc
14:32 < prplz> interesting
14:32 <+Amaranth> Which mainly means you won't see crit particles
14:34 < prplz> also this doesn't break the health displays at all MrARM_ 
14:34 < prplz> those are a vanilla feature too
14:34 < MrARM_> I found it out already :P
14:34 < prplz> (part of the scoreboard thing)
14:35 < Dinnerbone> Friendly fire is controlled serverside and clientside. Clientside for prediction, serverside for absolute
14:37 < WizardCM> i wish more pvp servers used native friendly fire to their advantage
14:38 < prplz> why is that WizardCM ?
14:38 < WizardCM> because lack of friendly fire tends to ruin gameplay
14:38 < WizardCM> people fighting the wrong people, etc
14:39 < prplz> oh i see what you meant now
14:42 <+Amaranth> Friendly fire being enabled is more hardcore and that's all that matters to PVP fans :P
14:57 < Thinkofdeath> Grum: If you're not busy, do you know what would cause this http://paste.md-5.net/raw/mifuteqawa ? Only happens for a few people
15:09 <+Amaranth> Grum: I think you're still stripping colors before doing the name check
15:10 < Thinkofdeath> Yeah coloured names still work in some cases
15:10 < Thinkofdeath> http://puu.sh/83ewB.jpg <- From #spigot
15:51 < Grum> Thinkofdeath: sending broken skull-data
15:52 < Thinkofdeath> Odd, I'm converting it the same way you do
15:52 < Thinkofdeath> Plus it works fine for everyone else
16:12 < Dinnerbone> Thinkofdeath: Pass ,true in your call to fillProfileProperties
16:12 < Dinnerbone> Our server does not do this because it's using an older authlib that defaulted to true
16:12 < Dinnerbone> But I'm assuming you're using a newer one that does not
16:14 < Thinkofdeath> I'm using what was in the 1.5.5 version
16:15 < Thinkofdeath> Looking at it it seems its the one that defaulted to true
16:25 < Grum> Thinkofdeath: scoreboard team-colors reflect in the nick
16:25 < Grum> so yeah, that works
16:26 < Grum> sending in a 'colored nick' on the addplayer doesn't
16:26 < Thinkofdeath> Grum: Apparently this is done with sending a coloured nick
16:26 <+Amaranth> Grum: They're using iTag which modifies packets to change the actual name
16:26 <+Amaranth> My thought was maybe they hadn't restarted their client since you ninja'd the update to 1.7.7
16:29 < Thinkofdeath> yeah, just tested. I can't get it to work
17:15 < dividuum> Grum, why is the signed skin blob mandatory? I don't get it. Using the UUID based method as backup still makes sure players get the correct skin, since the UUID->skin mapping is fix. 
17:15 < MrARM> to don't make players get other player's skin?
17:15 < dividuum> It breaks all replays on miners-movies.com. Which is sad as it break history and some nice archived recordings.
17:16 < dividuum> MrARM, how does this change prevent that? I don't understand
17:16 < MrARM> To don't make players who didn't bought the game, get a skin from a premium user.
17:17 < dividuum> But offline servers don't have the uuid for a player, since this information is given to the server by the hasJoined call
17:17 < MrARM> So they have no skin..?
17:18 < dividuum> so they cannot forward the uuid to the client and since the skin download seems to be uuid based now, the client has no way of getting a skin
17:18 < MrARM> yes, but they could make a half-offline server
17:18 < Dinnerbone> dividuum: because servers were just deciding to not send info to workaround the new protocol, and were giving players other players' skins. These are both things we do not want.
17:19 < dividuum> "giving players other players skins" - by sending a uuid of another player?
17:19 < Thinkofdeath> yep
17:20 < dividuum> Hm. I guess I can shut down miners-movies then. Recordings full of steves will make the experience horrible :(
17:21 < MrARM> dividuum maybe make it work on old servers only?
17:21 < dividuum> I really want to support 1.8. The camera thing looks promising
17:22 < dividuum> A recording full of steves... not so much :\
17:23 < dividuum> Maybe I'm missing something, but what's the problem with servers that assign players other players skins? I get that this might be confusing, but couldn't that be also be useful for something like team based servers?
17:23 < MrARM> Non-premium...
17:24 <+Amaranth> dividuum: They want the player to be in control of their skin and name, not the server
17:25 < Dinnerbone> ^
17:25 < Dinnerbone> The skin is the one thing you have complete control over. It's a little piece of you. Only you should be in control of that piece.
17:25 < dividuum> But why? What's the goal?
17:26 < dividuum> But I can download any other players skin and upload it as my own
17:26 < MrARM> Right
17:26 <+Amaranth> But that's your choice to do so
17:26 < MrARM> But you do so
17:26 < MrARM> Not the server
17:28 < dividuum> So it's the fact that a server might show another player a different skin for player while showing the correct skin for me?
17:28 < dividuum> *for my player
17:28 < MrARM> I don't think so...
17:30 < dividuum> But that's the only case which might be really confusing, since from my perspective everything seems to be alright. Any other case might be strange for a player but in my opinion has more downsides than upsides
17:31 < dividuum> (like for example breaking every lobby server that shows fake donator players)
17:33 < MrARM> You are right
17:33 < MrARM> I can't find any server replacing the player's skin
17:34 < MrARM> However non-premium...
17:35 < dividuum> Non premium clients might easily do their own uuid->url lookup and ignore all the crypto. probably. I didn't think that one through
17:35 < dividuum> or more correct ign->uuid->url lookup
17:36 < dividuum> If someone doesn't want to pay, they'll invest that 10 minutes to "hack" their client. Sad, but probably true
17:36 < SinZ> for non-premium singleplayer, you can just change char.png in the files
17:37 < dividuum> Again, I get the intention and it is a smart system. But I feel like it has downsides that might not have been intended
17:47 < dividuum> I guess the "isPublic":true thing in the texture base64 that can be retrieved from the session server prevents the client from using that information to download a skin?
17:47 < Dinnerbone> Yes
17:47 < dividuum> Sometimes I don't like crypto :-)
17:47 < Dinnerbone> :)
17:54 < Grum> 17:49:24 < dividuum> [17:17:22] But offline servers don't have the uuid for a player, since this information is given to the server by the hasJoined call  <-- why would we have to support offline servers having clients contacting us for skin-data?
17:54 < Grum> they are playing offline right?
17:56 < Grum> dividuum: we didn't intend for the downsides, we mostly did the change to make sure our skinservers infrastructure at amazon doesn't fully collapse at peak-times when serving 5 million requests/min
17:56 < dividuum> how would they fetch the skin? The server cannot send the players uuid to the client, since the server doesn't have it. Or am I missing something?
17:58 < dividuum> wouldn't it then be easier to send the skin inline as signed blob in the Spawn Player packet? that way the server is your proxy. right now you only forward the url to the skin (deduplicating it based on content, if I understood that correct)
17:59 < Grum> lets get back to the basics
17:59 < Grum> skins and cloaks were done by username
17:59 < Grum> which means no caching is possible that makes it so you do not have to do a request for data
17:59 < dividuum> yeah. so far so good (or bad) :)
17:59 < Grum> amazon actually died under the load we put it under
18:00 < Grum> so our goal was; lets lower the load
18:00 < Grum> start with caching on the client, so store the skins under the hash of the skin-data
18:00 < Grum> but, then how do you know if you can fetch it from the cache?
18:01 < dividuum> you guys sign it
18:01 < Grum> ok we make a public api call that says: gimme cloak+skin url+hash for a player
18:01 < Grum> this literally halves the requests
18:01 < Grum> so 1 person joins a server with 1000 players on it, 1000 players will do that request
18:01 < Grum> its all the same request
18:01 <+Amaranth> Grum: So skulls are kind of broken
18:02 <+Amaranth> Grum: They store the skin blob so if the player changes their skin the blob points to an invalid URL and the skull goes back to steve
18:02 < Grum> we dont delete data
18:02 < Dinnerbone> Amaranth: URLs don't go old
18:02 <+Amaranth> *shrug*
18:02 < Dinnerbone> And skulls are intended to point to the skin you had at the time
18:02 <+Amaranth> Paging Thinkofdeath
18:02 < Grum> so then the question is, 2.5Million requests of more complicated data ...
18:02 < Grum> and MANY are double
18:03 < Grum> so, the next solution is, lets have the server do this!
18:03 < Grum> i mean, the server can distribute this data! good idae
18:03 < Grum> but how about offline servers?
18:03 < dividuum> yep
18:03 < Grum> i mean they cannot contact us ....
18:03 < Grum> they are offline
18:04 < Grum> so we're looking for a solution for online servers now, well we already have this nice 'contact' point for when a player joins on an online server
18:04 <+Amaranth> I guess to be fair Thinkofdeath is probably testing on his 1.7.5 pretending to 1.7.7 but I figure he would have gotten the skulls working the same way
18:04 < Grum> so lets give the skinblob with that request
18:04 < Thinkofdeath> My skulls don't work on vanilla either
18:04 < Grum> and then we have the problem, that people who have  set their skin, suddenly will get a hitler skin set by the serverowner
18:04 < Grum> or not have their skin set unless they donate XXX to the server
18:05 <+Amaranth> Or a walking banana :D
18:05 < Grum> which obviously is BS too :)
18:05 < Grum> so you sign the data so you can verify it was our auth-server that send it
18:05 < Grum> and then you are at the solution we're at now :p
18:05 < dividuum> Ok. understood all that
18:08 < dividuum> so why don't you send the skin inline in the request instead of the url, as it is now? That way, a player joining a server causes at max one request to your backends since the server then caches the skin and can forward it to players. Too much overhead in the Spawn Player packet?
18:09 < dividuum> s/in the request/the spawn player packet texture data/
18:09 < Grum> because we don't have to? the players will have it cached locally?
18:10 < Grum> don't forget that this would be ~8kb/player the server has to send extra to *EVERY* player
18:10 <+Amaranth> That is quite a bit of skin data to be sending when HTTP has a solution for this
18:10 <+Amaranth> (caching)
18:10 < Grum> so on a server with 1000 players you will be sending 8gb of skindata around
18:10 < dividuum> oh. the average png size is 8k? didn't expect that. then it makes sense
18:10 < Grum> its not, but the max is around that
18:11 < Grum> when you do rainy-day-math you keep the worst-case scenario in mind :)
18:11 <+Amaranth> The 1.8 skin stuff makes it worse
18:11 < Grum> as they are bigger
18:11 < dividuum> right
18:11 <+Amaranth> Well, they have more data in them anyway
18:11 <+Amaranth> I didn't think they actually got bigger?
18:11 < Grum> yeah twice as big
18:11 < Grum> 32x64 -> 64x64
18:12 <+Amaranth> Oh, could have sworn it was just using blank spaces in the existing format
18:12 < Grum> nah that is what we do now :P
18:12 < Grum> to 'upconvert' it
18:12 < Grum> you might think omgllalala not big at all, but when you see that on peak hours we server 5M requests (so ~2.5M skin ones) per minute ....
18:12 < Grum> that is quite some data
18:13 < Grum> ~9.5gb/min of data :P
18:13 < dividuum> did you see the requests going down already as a result of the skins being cached?
18:13 < Grum> oh and ~50% of the people has the same skin
18:13 < Grum> yes
18:13 < Grum> 10%
18:13 < dividuum> nice
18:14 < Grum> so all in all, the new system should be better
18:14 <+Amaranth> I thought part of this was a plan to save storage too by doing deduplication?
18:14 < Grum> but yeah, migrational pains :p
18:14 <+Amaranth> But then you're apparently keeping every skin I ever upload
18:14 < Grum> yeah that is just a sideeffect of storing the file under its hashed name
18:14 < Grum> yes, because we have plenty of storage space :P
18:14 < dividuum> Again. The system is smart. I'm just a little biased as it breaks 3 month of work I put in miners-movies.com :}
18:14 <+Amaranth> So I'm going to call that a net loss
18:14 < Grum> they are still going to be unique
18:15 <+Amaranth> miners-movies.com is freaking incredible too
18:15 <+Amaranth> Coolest thing I've ever seen in minecraft
18:15 < Grum> no idea what it is/was
18:15 <+Amaranth> It was a recording/playback thing
18:16 < dividuum> you might take a quick look. It's basically recording packets while playing, then rewriting them and replaying them when you want to watch a recording
18:16 < Grum> why wouldn't that work anymore?
18:16 < dividuum> because now all the SpawnPlayer packets result in steves being displayed
18:16 <+Amaranth> Because it's all in the client and it can't get skins anymore
18:16 < Grum> if you dont store the actual skin-data
18:16 < Grum> you *can* store it
18:16 < dividuum> I thought that expires after one day?
18:17 <+Amaranth> It's not a mod or a third party program
18:17 <+Amaranth> The playback is in the vanilla client
18:17 < dividuum> yeah. It's all vanilla minecraft
18:17 < Grum> not sure how strict we enforce the data
18:17 <+Amaranth> 24h expiry
18:17 < Deaygo> dividuum: that's bloody cool
18:17 < Grum> yeah kinda sad that breaks
18:17 < dividuum> Yep. 24h to watch, after that it's a steve fest :-)
18:18 <+Amaranth> Quick ninja a 1.7.7 that ignores expiry when you're connected to miners-movies.com ;)
18:18 < dividuum> hehe. yeah. that would solve it :-P
18:18 < Grum> not another ninja 1.7.7 please >.>
18:19 < mbaxter> So I can still spawn steves, just fake players won't have skins anymore (due to not being valid)?
18:19 < dividuum> yes
18:20 < mbaxter> Woohoo! TagAPI isn't (100%) dead!
18:20 < dividuum> btw, what about that direct skin download bases on the player name. Is that going to be removed soon?
18:20 < Grum> dividuum: not soon :(
18:20 < Grum> probably not before 1.9 orso >.>
18:20 < TheUnnamedDude> ʘ‿ʘ
18:21 < Grum> we might just nuke it after we allow renames
18:21 < Grum> best case traffic goes down and we map the data to the hashes
18:21 < dividuum> ok. btw, on my site, i heavily cache all downloaded skins, so don't worry :-P
18:22 < Thinkofdeath> You can use https://sessionserver.mojang.com/session/minecraft/profile/<uuid> to get the skin url, just base64 decode the properties[0].value
18:22 < Thinkofdeath> If you have the uuid instead of their name
18:22 < dividuum> I have most of the uuid for recent recordings
18:23 < dividuum> some old 1.6 recordings don't have them obviously
18:23 < dividuum> so that change is doable
18:24 < mbaxter> So to clarify - No way to have a skin for a faked player, they have to have legitimately logged into your server/authed?
18:24 < Thinkofdeath> yep
18:24 < Grum> yes
18:25 <+Amaranth> Because fuck Citizens :P
18:25 < dividuum> yes. you get the information necessary with the hasJoined call that happens when a player joins a server
18:25 < Grum> and then the server becomes responsible for sending the data
18:25 < Grum> and we disconnect the client when you don't ;D
18:25 <+Amaranth> Oh so you are doing that on purpose
18:25 < Grum> yes
18:26 < dividuum> wait, I have to include the texture blob in the future?
18:26 <+Amaranth> So what do you do when a player is online but the server is offline?
18:26 < Grum>                 connection.disconnect(new TranslatableComponent("disconnect.genericReason", "Outdated server! pretending to be " + SharedConstants.VERSION_STRING));
18:26 < Grum> Amaranth: then the client will have an 'offline uuid'
18:26 <+Amaranth> So the client does account for that then
18:27 < Grum> we'll make a better check for 1.8 -- we managed to get this in without breaking stuff :P
18:27 <+Amaranth> Was just thinking you'd be dropping people saying the server is faking 1.7.7 when the server is vanilla 1.7.7 but in offline mode
18:27 < Grum> in other news we have >740 block-models O.o
18:28 < Grum> aand not really done with that
18:28 < Thinkofdeath> Nice, I've been doing something similar
18:28 < mbaxter> Since scrolling up through a large conversation is painful, could someone fill me in on the benefit of not letting the server (which is now the one handling the bandwidth for skins to clients) send the legit skin for an account who isn't online at the moment (faked spawn).
18:28 < Thinkofdeath> I needed models for my mapviewer, might just switch to using yours :)
18:28 <+Amaranth> The server isn't sending a skin, just a skin URL
18:28 < Grum> you can do that
18:28 < Grum> i you have the skinblob of the player that is not online
18:29 < Grum> you can pretend it is online
18:29 <+Amaranth> For 24 hours
18:29 < Grum> just make sure its <24hrs old :P
18:29 < Grum> totally doable to do NPCs like that 
18:29 < Thinkofdeath> Grum: Does the 24 hours apply to skulls as well?
18:29 < Grum> no
18:29 < Grum> that is also a one time resolve
18:29 < mbaxter> So to have functional NPCs, log in with that account once a day? :P
18:30 < dividuum> I'll just outfit all steves with skills then :-P
18:30 <+Amaranth> Skulls now take a snapshot of your skin at the moment they were placed which is kind of weird
18:30 < Grum> its not Amaranth
18:30 < Grum> that is how it should be actually
18:30 < Grum> we just couldn't ever do that
18:30 < Thinkofdeath> Thats how it is on the spigot build,
18:30 <+Amaranth> Remind me to only PVP with a skin that looks nothing like my normal one
18:30 < Thinkofdeath> Unless the url goes invalid (e.g. no one using it)
18:31 <+Amaranth> That's not my head! It looks nothing like me!
18:31 < mbaxter> lol Amaranth.
18:31 < Thinkofdeath> Amaranth: Good thing they save your name (at the time) and uuid too
18:32 < Thinkofdeath> Still work out if its you or not :)
18:32 <+Amaranth> Thinkofdeath: That only helps if you have client mods :P
18:32 < Thinkofdeath> :P
18:33 < Grum> we dont delete skins 
18:33 < Grum> we probably never will
18:33 < Thinkofdeath> Huh? I changed my skin and all my skulls lost it
18:33 < Grum> iterating a bucket with >gazzillion objects in it ... is not cheap/fun/nice/whatever :p
18:33 < Grum> Thinkofdeath: not in 1.7.7
18:34 < Grum> the url to the hash .. that file never gets wiped
18:34 <+Amaranth> Thinkofdeath: You're using a 1.7.7 vanilla server and /give to get the skull?
18:34 < Thinkofdeath> Amaranth: No my build :), Vanilla wont display my skin at all
18:34 <+Amaranth> Uh
18:34 < Thinkofdeath> Never worked for some reason
18:35 < dividuum> what does a skull nbt now look like? It has the player name, uuid and hash of the skin file?
18:35 < Thinkofdeath> everyone elses is fine
18:35 <+Amaranth> dividuum: iirc it's a serialization of the GameProfile and skin blob so more or less yes
18:36 <+Amaranth> I don't know what format the skin blob is in though, I didn't realize it was storing it
18:36 < dividuum> ah. so for skulls the timestamp isn't checked then?
18:36 <+Amaranth> Isn't the signature ignored for them too?
18:40 < Grum> Amaranth: it has the signed skin data
18:40 < Thinkofdeath> Also why can't I see my own skin in 1.7.7?
18:40 < Thinkofdeath> (Vanilla server)
18:41 < TheUnnamedDude> Why is the skins signed?
18:41 < Thinkofdeath> TheUnnamedDude: Read up :)
18:41 < TheUnnamedDude> prwegev
18:43 < TheUnnamedDude> Where do you like find info about that? D:
18:46 < Grum> you dont
18:46 < Grum> its signed; one way :p
18:47 < Grum> bet the nsa can crack it!
18:47 < Thinkofdeath> I'll crack it in no time!
18:47  * Thinkofdeath pulls out his raspberry pi
18:47 < Thinkofdeath> shouldn't take long
18:48 < TheUnnamedDude> Thinkofdeath, just buy their new compute modules and make a mojang skin cracker
18:49 < TheUnnamedDude> Is there any other reason than removing the possibility to fake players?
18:49 < Grum> yes, skins now distribute the location of skins, we do not want to give the server the power to control this
18:50 < dx> TheUnnamedDude: Read up :)
18:50 < TheUnnamedDude> Its hard to read up on something without info dx
18:50 < Grum> there's already enough people selling shit with/on/via servers that they have no right to sell
18:50 < Grum> this will not get added to that list :)
18:51 < TheUnnamedDude> Selling stuff people can do their self?
18:51 < Thinkofdeath> Buy diamonds, only $14.99!
18:51 < Thinkofdeath> (per one)
18:51 < TheUnnamedDude> You know it would be more useful in fighting nude skins
18:51 < TheUnnamedDude> And stupid anon masks
18:51 < dx> TheUnnamedDude: i meant this channel. i suggest starting from the message that says "lets get back to the basics", 52 minutes ago
18:52 < TheUnnamedDude> Ohh, thought you meant read up on it
18:52 < TheUnnamedDude> lol
18:52 < Grum> it was a literal up
18:52 < Grum> assuming your log is not inverted =)
18:52 < Thinkofdeath> ^ That way
18:52 < Thinkofdeath> about 500 lines
18:52 < Grum> ^
18:52 < Grum> ||
18:52 < Grum> such fail
18:53 < Thinkofdeath> ↑
18:56 < mbaxter> It's ok Thinkofdeath everything will be ok
18:56 < Grum> ↟ ↥ ↿ ↾ ⇈ ⇑ ⇞ ⇡ ⇧ ⇪ ⇫ ⇬ ⇭ ⇮ ⇯
18:56 < TheUnnamedDude> DONT PANIC
18:56  * TheUnnamedDude starts running in circle
18:56 < Grum> ↺
18:57 < Thinkofdeath> Grum: Last 5 didn't work :(
18:57 < Grum> or ↻ ? :D
18:57 < TheUnnamedDude> ʘ‿ʘ
18:57 < TheUnnamedDude> Those circles
18:57 < Grum> ◎
18:57 < Grum> purdy
18:57 < Thinkofdeath> Ｏ
18:58 < Grum> ◯
18:58 < Grum> ◌
18:58 < Thinkofdeath> ●
18:58 < Grum> ◉
18:58 < TheUnnamedDude> ◎‿◎
18:58 < TheUnnamedDude> ◉‿◉
18:59 < Grum> ◔.◔
18:59 < Thinkofdeath> (☞ﾟ∀ﾟ)☞
18:59 < TheUnnamedDude> ◔‿◔
18:59 < Grum> -◙.◙-
18:59 < shoghicp> start9
18:59 < astradev> Does anyone have some simple example code for auth to an MC server?
18:59 < Grum> ◯.◯
19:00 < Thinkofdeath> astradev: Mojang's authlib comes with source
19:00 < Grum> ▱>▱
19:00 < TheUnnamedDude> astradev, mojang has
19:00 < TheUnnamedDude> It might not be simple
19:00 < Thinkofdeath> ⁀⊙﹏☉⁀
19:00 < astradev> Oh, it does? Alright. I'll look. 
19:01 < Grum> ▣.◉
19:01 < TheUnnamedDude> Extends a lot of stuff so might not be the right ting to use for a example
19:01 < astradev> Then what else?
19:01 < Grum> magic ◉'s
19:02 < Grum> ▤+▥=▦
19:02 < TheUnnamedDude> Ehr, just look at the mojang authlib astradev 
19:03 < Grum> ⃣