21:32 < Meeeh> nah, it will be fun 21:38 < Huherak987> Hi, I would like to ask about pre-release protocol, because I think that some things are not correct 21:39 < Huherak987> http://wiki.vg/Pre-release_protocol there is stated that serverbound packet chat message is 0x02 21:40 < Huherak987> but there: http://wiki.vg/Protocol#Chat_Message_2 is said that the id is 0x01 so ? 21:41 < rom1504> Huherak987: there are 2 chat packets 21:42 < Huherak987> what ? 21:42 < rom1504> serverbound and clientbound 21:42 < Huherak987> of course I know 21:42 < pokechu22> I see what you mean - the table at the start shows the serverbound one as 0x02, but the table for the packet itself shows 0x01. 21:42 < pokechu22> Clientbound chat was 0x02 and is now 0x0F? 21:43 < Huherak987> yeah, exactly 21:43 < Huherak987> I dont know what id to use then 21:43 < rom1504> serverbound chat is unchanged, so it's not details in http://wiki.vg/Pre-release_protocol 21:43 < rom1504> *detailled 21:43 < pokechu22> Let's see if my semiupdated burger is good enough to show that packet... 21:44 < rom1504> pre-release page is correct 21:44 < rom1504> in 16w04a that is 21:44 < rom1504> not in 1.9-pre3 21:45 < rom1504> all the ids changed between 1.8 and 1.9 of course, and http://wiki.vg/Protocol#Chat_Message_2 is 1.8 ;) 21:45 < pokechu22> It's definitely 0x02 now. 21:45 < rom1504> yes 21:46 < pokechu22> If you want I can try to spit out some packet instructions stuff but it's messy... still missing blockpos, the JSON chat, and NBT tags I think. 21:48 < rom1504> (the table at the top of http://wiki.vg/Pre-release_protocol do say all the packet that are unchanged (except the id), including chat, so it's correct) 21:48 < pokechu22> Shouldn't the ID for chat have the colored diff though? 21:49 < Huherak987> Definitely it should be 21:50 < rom1504> yeah it should 21:51 < Huherak987> maybe there are a lot of misstakes on that page because me and my friend we are working on protocol hack for 1.9 but for some reason packets are just random 21:52 < pokechu22> OK, here's the (mostly correct but not fully correct) packet instructions for 1.9-pre3: https://gist.github.com/Pokechu22/072dbcda9c6ad6a52008 21:53 < M1nef4n> thanks a lot! 21:57 < Not-3368> [wiki] Edit by Pokechu22 to Pre-release protocol -> http://tinyurl.com/h9fathk 22:03 < Huherak987> pokechu22 is it possible that pre-1, pre-2 and pre-3 all have different packets ? 22:04 < pokechu22> Maybe, but I don't know. It wouldn't be likely. 22:04 < pokechu22> At least, not for a large set of changes between two prereleases. 22:04 < Huherak987> because we are expecting different behavior of each client (pre 1,2 and 3) 22:05 < pokechu22> It might change a bit - when I get burger working better it should also be possible to generate a list of changes between versions (like you see with http://b.wiki.vg, just with the current versions) 22:07 < Huherak987> And when do you think you can get it working ? 22:07 < Huherak987> because it would be a really nice tool 22:09 < Fenhl> it would be great if we could get some more info on 1.9 protocol before release 22:11 < Fenhl> I would like to “commandeer the merging” as the article so eloquently puts it but I don't have access to any sort of decompiled code so if the pre-release protocol article is outdated someone else needs to update it 22:11 < Fenhl> (or describe the changes here in enough detail for me to wikify them) 22:13 < Fenhl> of course, there's always time to correct and expand [[Protocol]] after the merging, as has happened quite a lot during 1.8 22:16 < pokechu22> Hopefully I can get it working - I've been improving it a fair bit. A week ago or so it didn't do packet instructions at all. 22:17 < Huherak987> pokechu22 please could you send me burger from version 16w04a ? because this is the version documented on wiki 22:19 < rom15044> Huherak987: I can assure you that the information on pre-release page for 16w04a is correct, we tested that thoroughly in node-minecraft-protocol 22:20 < rom15044> What's undocumented are the new changes in 1.9-pre3 22:20 < rom15044> If mojang added a packet in the middle of the protocol, then it's possible most packets ids have changed again 22:21 < pokechu22> Huherak987, sure, but it's unstable and might not make sense quite yet. 22:21 < M1nef4n> We want to compare 16w04a and 1.9-pre3 22:21 < pokechu22> Hm... if they're both missing the same information a diff might still make some sense - one sec. 22:22 < Huherak987> Look, these are message we got while connecting to 1.8.8 server semi-hacked for 1.9 - http://imgur.com/7fIExGu 22:22 < rom15044> 1.8 packets ids are completely different from 1.8 22:22 < rom15044> 1.9 22:23 < rom15044> You need to change them all 22:23 < M1nef4n> what? 22:23 < Huherak987> rom15044 you dont say ... we have translated them all 22:23 < pokechu22> I think it's https://github.com/sadimusi/Hamburglar that generates diffs from burger JSONs? 22:23 < rom15044> And trying it on a 16w04a server M1nef4n ? 22:24 < M1nef4n> nope, we are making protocol hack (running on spigot 1.8 R3 server) 22:25 < rom15044> No clue what a protocol hack is 22:25 < pokechu22> FYI, the spigot people have said that they're going to release 1.9 spigot a day after 1.9 is released. 22:25 < pokechu22> rom15044: There was a "Protocol hack" build of spigot for 1.7.10 that allowed both 1.7.10 and 1.8 clients to connect (though it actually ran 1.7.10) 22:26 < rom15044> Ok 22:26 < Huherak987> yeah but we want to keep 1.8 and just allowing people with 1.9 to join (like old protocol hack for 1.7.10 allowing clients with 1.8 to join) 22:31 < pokechu22> Looks like there certainly were some changes, but nothing with the ids. 22:32 < pokechu22> https://gist.github.com/Pokechu22/438b164eaa2086a705fc 22:33 < M1nef4n> thx! 22:34 < Huherak987> thanks a lot ! --- Day changed ven. févr. 26 2016 01:28 < Gjum> pokechu22: on that gist, all "operation"s are "write"...? 01:28 < pokechu22> There should be a few 'loop's... I'm just going off of what the output for earlier versions was. 01:29 < pokechu22> I think vitrine adds type information back? If not I should be able to add it. 01:29 < Gjum> oh, so the loops didnt change in the first portion 01:29 < Gjum> yeah, the second part has loops and case etc 01:32 < pokechu22> FYI it _is_ missing a few types, namely chat components, positions, NBT tags, and item stacks. So cases where those would be written are currently missing. 04:56 <+XorBoole> kind of annoyed no one has made a model converter for 1.8 -> 1.9 04:57 <+XorBoole> because as far as I can tell it's quite nontrivial 04:58 <+XorBoole> by which I mean they're too complicated for me to figure out 04:58 <+XorBoole> because math is hard 08:22 < Not-3368> [wiki] Edit by AN0NY0US to Pocket Edition Program List -> http://tinyurl.com/hwusqsk 08:45 <+SinZ> :O notifico actually reported something on the wiki 08:47 < rom15044> Fenhl fixed it recently 08:48 < Fenhl> well, not so much “fixed it” as “set up a new instance because the other one was down and tktech didn't want to fix it” :P 08:48 < tktech> Was only ever a couple lines quickly hacked together running in a screen session 08:49 < Fenhl> I'd still rather have an actual edit hook but this is better than nothing 10:49 < Meeeh> creating protocol hack for 1.9 don't seems as good idea for me... they use different chunk system, you will need process every chunk 2x. 10:50 < Meeeh> (other format in packet) 10:52 < rom1504> doesn't mean it cannot work 13:06 < hansihe> you could do it on a separate box as well 13:22 < Not-3368> [wiki] Edit by Myles to Pre-release protocol -> http://tinyurl.com/h3k89m6 13:26 < rom1504> this edit is clearly wrong ^ 13:26 < MylesC> Hm? 13:27 < rom1504> idk if they now use double for spawn, but they certainly don't use double to store a fixed point representation 13:27 < rom1504> and I doubt they use double only in this spawn packet 13:27 < MylesC> Client side code shows it reads a double for the packet 13:28 < rom1504> I mean mojang is inconsistent, but not that much 13:28 < rom1504> MylesC: okay, can you check it does that for all other spawn packets ? 13:28 < MylesC> Sure, i'll look into it 13:36 < rom1504> an my other point was you changed int to double, but the other column is now wrong : "X position as a Fixed-point number" 13:36 < rom1504> it should now be "absolute position", as in http://wiki.vg/Protocol#Player_Position_And_Look_2 13:37 < MylesC> I'll rectify my edit in a minute 13:40 < MylesC> Yeah they're all doubles now 13:44 < Not-3368> [wiki] Edit by Myles to Pre-release protocol -> http://tinyurl.com/jduqj55 14:05 < rom1504> ok 14:23 < Akaibu> so, i'm wondering, it how would it be to do machine learning for minecraft 14:23 < Akaibu> like full player gaming 14:25 < Akaibu> i don't know too too much on machine learning so i'm not sure which method of ML would work best 14:29 < rom1504> we were talking about that a few weeks ago 14:30 < rom1504> basically I think it's not very interesting to do it for the full problem 14:31 < rom1504> but for stuff like high level decisions or "making the bot movement look like an human", it might be useful 17:39 < MylesC> need to write about it later but entity look move relative and entity move relative are now Shorts for the XYZ 17:43 < MylesC> and entity teleport packet uses doubles now 17:51 < rom1504> @MylesC did that change between 16w04a and 1.9-pre3 ? I'm surprised we would be only noticing that change now 17:52 < rom1504> (I tried 16w04a protocol with a proxy and it works so...) 17:52 < MylesC> I'm not sure, i'm using PRE-3 (at the minute) 17:53 < MylesC> I'd assume so 17:54 < rom1504> could you check if packet ids changed in 1.9-pre3 ? (if not I guess we should update the version at the top of pre-release page) 17:54 < MylesC> I think there was one change I found but that was the chat message one that someone updated other day as far as i'm aware. 17:56 < rom1504> I'll just try my proxy with your changes tonight, see if that's enough 17:58 < MylesC> working on a bukkit plugin to allow 1.9 to connect to 1.8 which is how I know most of the changes 17:59 < rom1504> ok 18:01 < rom1504> I guess you're doing "packet translation" ? (a bit like dragonet does between mcpc and mcpe https://github.com/DragonetMC/DragonProxy/tree/master/src/main/java/org/dragonet/proxy/network/translator ) 18:02 < rom1504> in node-minecraft-protocol we implemented multiple version support, but I didn't try yet to translate any packets (which is kind of needed to build a full multi-version server or client) 18:04 < MylesC> Yeah simply some netty handlers to modify incoming packets and outgoing, I've got most of it done so far for the base. Still need to work on the new chunk stuff (which is a bit complicated with translating from what i've seen). (I plan to publically publish this plugin if I manage to complete it haha) 18:06 < rom1504> okay, cool 20:25 < tktech> fragmer, you have any old classic .dat's laying around? 20:41 < AlphaBlend> i've had quite an interesting conversation with a few friends, and one of them said they downloaded minecraft and it came with forge/modloader, saying they got it on the official site, their drive wiped before they got it. I want to end this silly discussion, and figure I'd ask here, so I'm not the only person saying it was a weird mistake. Minecraft has never shipped with forge, is this correct? 20:45 < angal> From the official site yu download only launcher. 20:45 < angal> If you already have forge on your pc, it will be shown in official launcher. 20:45 < tktech> AlphaBlend, Your friend is an idiot. 20:46 < angal> :) 20:47 < AlphaBlend> well, i just really had to ask in the most official place i could think of 20:48 < AlphaBlend> you know when your friends say they did something, and then say their perspective 20:48 < AlphaBlend> if it goes against your own, you don't have much ground to say your experience 20:59 < Meeeh> phttps://github.com/PrismarineJS/minecraft-data/blob/master/data/1.9/blocks.json there is no blast resistance? 21:04 < rom1504> Meeeh: no, nobody needed it so I didn't add it, but I know how to (https://github.com/PrismarineJS/minecraft-wiki-extractor/issues/11), it could be added if you need it 21:07 < Meeeh> rom1504, I can get them from linked list too, but it will be great if that will be included in data, because, why not? :D 21:09 < rom1504> yeah sure, I'll do that ;) 21:09 < Meeeh> rom1504, also maybe some info about blocks like ice and soul sand that they affect movement 21:10 < Meeeh> but idk if there is any real param for this ;/ 21:12 < rom1504> there was some discussion about this there https://github.com/PrismarineJS/minecraft-data/issues/52 21:12 < Meeeh> this.frictionFactor = 0.98F; 21:12 < rom1504> but I think it would have to be manual 21:12 < rom1504> or extracted from somewhere else yeah 21:13 < Meeeh> so yeach, blocks have that friction too, about simple block and bounce stuff, idk if this is needed to be in any way in file o.O 21:13 < Meeeh> slime block* 21:13 < Meeeh> nah :D 21:15 < Meeeh> as this isn't any param of block, it just how it works, but I think that friction and blast resistance should be included 21:21 < Meeeh> rom1504, do you want friction of every block? 21:22 < rom1504> Meeeh: is there some kind of default value ? 21:23 < Meeeh> 0.6 21:23 < rom1504> how many blocks don't have the default value ? 21:23 < Meeeh> lol 21:23 < Meeeh> only 3 21:23 < Meeeh> ice: 0.98 21:23 < Meeeh> slime: 0.8 21:23 < Meeeh> packed_ice: 0.98 21:23 < rom1504> ah 21:23 < rom1504> well 21:23 < Meeeh> weird 21:23 < Meeeh> there is no soul sand 21:24 < rom1504> that's why I was proposing a different file 21:24 < rom1504> for friction and co 21:24 < rom1504> then you can read both and have all your info 21:24 < Meeeh> soul sand just manualy decrease mov 21:24 < Meeeh> paramEntity.motX *= 0.4D; 21:24 < Meeeh> paramEntity.motZ *= 0.4D; 21:24 < Meeeh> weird 21:38 < Meeeh> rom1504, Glowstone doesn't emit light? 21:38 < Meeeh> https://github.com/PrismarineJS/minecraft-data/blob/master/data/1.9/blocks.json#L2249 I don't understand something or? 21:42 < rom1504> https://github.com/PrismarineJS/minecraft-wiki-extractor/issues/12 there are some light values to fix 21:43 < rom1504> I'll fix them, but didn't have time yet 22:42 < MylesC> do chunks have to be sent for entities to show? 23:22 < Meeeh> there is any block that can't be stacked to 64? 23:34 < MylesC> don't think so (block wise) 23:35 < edk> do you count signs 23:37 < edk> i guess their block is not the same as their item, so no 23:40 < Gjum> MylesC: I believe I saw players being rendered outside the loaded chunks once, so yes I guess so 23:41 < Gjum> well, you wouldn't need the chunk 23:43 < redstonehelper> Meeeh: cake 23:44 < redstonehelper> same id as block and as item 23:44 < Gjum> no block, like doors 23:44 < Gjum> oh is it? 23:45 < Gjum> no, it's 92 and 354 ;) 23:45 < redstonehelper> banners? 23:45 < redstonehelper> probably have multiple ids for blocks too 23:45 < Gjum> no, 176, 425 --- Day changed sam. févr. 27 2016 00:02 < rom15044> Bed has a stack size of 1 00:02 < Gjum> bed is two blocks and a diff item 00:03 < Gjum> could very well be that all blocks stack to 64 00:07 < Meeeh> cake use 2 ids too 00:07 < Meeeh> ah, Gjum said that 00:08 < rom15044> https://tonicdev.com/56d0d9e386312b0d0010983a/56d0d9e386312b0d0010983b 00:08 < Meeeh> so there is no blocks like that as far as I see 00:08 < rom15044> Bed is a block 00:08 < Gjum> bed is different as an item though 00:10 < Gjum> only candidates are end+nether portal 00:10 < Gjum> and fire, they all stack to 0 according to blocks.json 00:10 < rom15044> Cake 00:10 < rom15044> And banner 00:10 < Gjum> the others in that tonic are different ID as an item 00:11 < Gjum> incl. sign, cake, banner, 00:11 < rom15044> Yes, is "not an item" part of the question? 00:11 < Meeeh> I'm looking for block, not item 00:11 < Meeeh> so... :P 00:12 < Gjum> I understood "any block that can stack" as "any block which has the same id in world as in inventory" 00:12 < pokechu22> If it doesn't have an item it can't stack, since it can't go in to the inventory. 00:12 < pokechu22> At least, if we're talking about 1.8. 00:13 < pokechu22> For 1.7.10, I'm pretty sure the bed block stacks to 64, and I know from experience the cake block stacks to 64. 00:13 < Gjum> so the only special cases where blockId == itemId and stackSize != 64 would be fire, nether+end portals 00:13 < pokechu22> Fire stacks to 64 in 1.7.10 IIRC... 00:13 < Meeeh> eeem, they stack too, and in 1.8 you can't get them 00:13 < Gjum> Im pretty sure in 1.7 bed had a different item id 00:13 < Meeeh> in all mc versions 00:13 < Meeeh> bed have block and item 00:14 < rom15044> Stack == 0 means you can't get them 00:14 < Gjum> ok 00:14 < rom15044> In the inventory 00:14 < Gjum> so no, all blocks in 1.8 stack to 64 00:20 < pokechu22> Checking the item registration method, no item blocks change the max stack size. The bed _item_ and cake _item_ do change the stack size, but they're separate from the block and have different ids. 00:53 < M1nef4n> hi guys, where can I find Metadata for EntityItem or FallingBlock? 00:55 < Gjum> M1nef4n: http://minecraft.gamepedia.com/Chunk_format#Dynamic_tiles 00:56 < M1nef4n> no, I mean the Metadata for 1.8 protocol (http://wiki.vg/Entities#Entity_Metadata) 00:56 < pokechu22> It's probably best to use MCP to find it... One second. 00:58 < rom1504> objects have metadata ? 00:58 < M1nef4n> I found that Objects are spawned via Spawn Object 00:58 < pokechu22> It doesn't look like FallingBlock uses any custom metadata. 00:58 < Gjum> M1nef4n: but its in there? 00:59 < Gjum> http://wiki.vg/Entities#Item 00:59 < M1nef4n> but the server seems to send PacketPlayOutSpawnEntity for Item or FallingBlock 00:59 < rom1504> M1nef4n: yes 00:59 < rom1504> they are objects 01:00 < rom1504> what's your question ? 01:00 < rom1504> does this answer your question http://wiki.vg/Object_Data#Falling_Block_.28id_70.29 ? 01:00 < rom1504> that's a field of spawn object 01:00 < pokechu22> Item uses metadata / the data watcher, falling block doesn't seem to. 01:00 < rom1504> nothing to do with entity metadata 01:02 < M1nef4n> it looks like the server sends metadata for Item in metadata for EntityItem in PacketPlayOutSpawnEntity. When I read the metadata from output byte array I found that there are 2 undocumented fields 01:02 < M1nef4n> with index 2 and 3 01:02 < pokechu22> Are you using a vanilla server? Or is it a modded one? Just to check. 01:03 < rom1504> M1nef4n: all fields are documented in wiki.vg/Protocol 01:03 < M1nef4n> I'm using spigot 1.8.8 R3 01:03 < M1nef4n> This server is running CraftBukkit version git-Spigot-fdc1440-53fac9f (MC: 1.8.8) (Implementing API version 1.8.8-R0.1-SNAPSHOT) 01:05 < pokechu22> I've had cases where spigot added an invalid field to item frames (well, actually, it set the custom name to the same thing as the entity inside of the frame). 01:05 < pokechu22> Do you know if the server you're using runs bungeecord? 01:05 < M1nef4n> when i decode Metadata for EntityItem: http://hastebin.com/ajelamobaf.txt 01:06 < M1nef4n> no, I'm not on bungeecord 01:07 < pokechu22> I've had a case where an item frame had fields 2 and 3 set, even though they're invalid for item frames... 01:07 < pokechu22> https://github.com/Pokechu22/WorldDownloader/issues/12#issuecomment-148975191 01:08 < Meeeh> ugh, why people create tools like that 01:09 < Meeeh> but this is still this version 01:09 < Meeeh> with plugin message api? 01:09 < pokechu22> Are you refering to WDL? I work on it because I like to keep my builds. 01:10 < pokechu22> I was only on mineplex becasue that's where someone else was getting the bug reliably. And yep, this version does have the plugin message API. 01:10 < Gjum> +1 for wdl 01:11 < Meeeh> nah, so at least it can be disabled server side 01:12 < pokechu22> Some day I hope to get the permission requests system figured out - it's complicated keeping track of requests serverside, though I'm getting there. 01:12 < M1nef4n> when I drop ItemStack the server will send PacketPlayOutSpawnEntity and PacketPlayOutEntityMetadata with 2 unknown fields 01:14 < pokechu22> 99% sure those fields are for custom name and display custom name - I think spigot is sending it even when it shouldn't... 01:14 < pokechu22> Though it actually looks like those fields are part of the base entity class in 1.8 instead of entityliving. 01:15 < M1nef4n> the custom fields are BYTE and STRING 01:16 < pokechu22> Field 3 is a byte, and field 2 is a string. It seems to match with http://wiki.vg/Entities#Living_Entity 01:16 < M1nef4n> so these fields should be in Entity instead of LivingEntity... 01:17 < M1nef4n> when you look at 1.9 protocol http://wiki.vg/Pre-release_protocol#Entity_Metadata 01:17 < M1nef4n> you will find that these fields are in Entity 01:19 < pokechu22> Seems like they're definitely in Entity in 1.8 as well, not LivingEntity. Though I'll need to look further... 01:21 < pokechu22> There's actually two types... EntityLiving and EntityLivingBase. Confusing :/ 01:22 < pokechu22> 6, 7, 8, and 9 are all part of EntityLivingBase. 15 (noai) is part of EntityLiving. And 2 and 3 are just basic entities. 01:23 < pokechu22> Only armor stands and players inherit EntityLivingBase but not EntityLiving. I'll restructure this. 01:30 < Not-3368> [wiki] Edit by Pokechu22 to Entities -> http://tinyurl.com/hwp2oju 04:37 < Akaibu> http://mojang.com/2016/02/bring-minecraft-into-your-world-with-mine-chest/ 04:38 < Akaibu> so basically lootcrate - minecraft edition? 04:38 * Akaibu sigh 05:15 <+AndrewPH> autism crate 05:15 <+AndrewPH> instead of being focused on loads of nerd stuff, it's focused on one topic, and will run out of anything worthwhile to send out after the first 2 months. 06:18 < AlphaBlend> oh my 06:23 < tktech> So close to done this implementation of the Java Serialization Protocol v5. 06:24 < tktech> It's so simple yet somehow manages to be incredibly convoluted. Yay JVM. 07:04 < Not-3368> [wiki] Edit by Phasesaber to Client List -> http://tinyurl.com/zcjd4zy 12:41 < Huherak987> Hello, could someone help me please ? I think that http://wiki.vg/Pre-release_protocol#Spawn_Object this packet is wrongly documented because when I try to read this from client I got this: http://hastebin.com/ugucukaxag.avrasm 12:54 < Huherak987> Anybody here ? 12:56 < Huherak987> I think this Spawn Object packet is terribly wrong documented or I dont know but its lenght is only 32 bytes 13:06 < Huherak987> By the way how should I read angle ? As a byte ? 13:07 < Fenhl> Huherak987: Pre-release protocol is partially outdated 13:08 < Fenhl> Huherak987: and yes, an Angle is a single byte, as documented at http://wiki.vg/Data_types 13:10 < Fenhl> actually, the documentation for that packet was recently changed by MylesC, who is no longer in the channel 13:11 < Fenhl> http://wiki.vg/index.php?title=Pre-release_protocol&diff=7374&oldid=7371 people have been wondering if that change was correct 13:12 < Fenhl> Huherak987: could you try testing it with the format as it was documented before those edits? 13:17 < Huherak987> Fenhl I got the same problem with Spawn Mob I am not sure if those doubles are correct 13:19 < Huherak987> I have made a simple bot that joins server and reads incoming packets from server, because me and my friend we are trying to do protocol hack for 1.8.8 spigot to be compatible with 1.9 clients so we are comparing packets from vanilla mc 16w04 13:19 < Fenhl> the packets MylesC changed are Spawn Object, Spawn Mob, and Spawn Player 13:21 < Fenhl> Client side code shows it reads a double for the packet 13:21 < Huherak987> Fenhl, yeah but look it is really strange what I got when I debug incoming Spawn mob packet: http://hastebin.com/rarurozava.avrasm, always the same x, y, z, even if it is a different mob 13:21 < Fenhl> I believe what happened is MylesC misinterpreted the client side code 13:22 < Huherak987> even the velocity is always the same 13:22 < Fenhl> Huherak987: I was going to say I can't read AVR assembly but that's just a text file lol 13:22 < Huherak987> yeah, it is debug of all values from the packet my client received 13:22 < Fenhl> (protip: you can change the file extension on a hastebin to fix syntax highlighting) 13:24 < Fenhl> hmm, that's weird, can you give me a hex dump or something so I can double-check your decoding? 13:25 < Huherak987> This is the code from where it comes: http://hastebin.com/wuduhufuxo.avrasm 13:26 < Huherak987> the variable buf is bytebuf 13:28 < Fenhl> what happens when you replace those readDouble calls with your fixed-point decoder? 13:33 < Huherak987> hmmm 13:33 < Huherak987> http://hastebin.com/qewefipuwo.avrasm 13:33 < Huherak987> it seems like you are right because these numbers makes much more sense 13:34 < Fenhl> yeah that looks reasonable. Reverting 13:35 < Huherak987> I just read those values as integers and then I converted them to fixed point double 13:35 < Fenhl> yeah, that sounds correct 13:36 < Huherak987> hm so maybe somebody should put it on the wiki that these values are not doubles, because you have to read them as integers from the protocol and then convert them to fixed point double 13:36 < Fenhl> Huherak987: just to make sure, you're reading this from a Notchian (vanilla) 1.9-pre4 server, yes? 13:37 < Fenhl> if that's the case I will fix the wiki 13:37 < Fenhl> already have the edit ready, just need your confirmation 13:37 < Huherak987> Fenhl I am reading it from vanilla server but from version 16w04a 13:38 < Huherak987> because this was the version previously documented on wiki 13:38 < Fenhl> ah, that would explain it. Protocol might have changed since then 13:38 < Fenhl> wiki always documents the latest version 13:38 < Fenhl> if the version number is outdated, that's just because someone forgot to update the intro paragraph 13:39 < Huherak987> hmmm I thought that the wiki is actually for 16w04a thats why I am testing it on this version 13:42 < Huherak987> Fenhl I am going to try it with the pre 4 13:43 < Not-3368> [wiki] Edit by Fenhl to Protocol version numbers -> http://tinyurl.com/jggcboj 13:45 < Not-3368> [wiki] Edit by Fenhl to Pre-release protocol -> http://tinyurl.com/jhp8m5l 13:49 < Huherak987> Fenhl I dont know but when I try it with the 106 it starts to give me weird numbers again 13:50 < Huherak987> these numbers gave me the 106 version if I read them as doubles http://hastebin.com/lovidiqezu.avrasm 13:51 < Huherak987> no sorry my mistake... 13:51 < Huherak987> It is really double in pre4 14:04 < Fenhl> ok thanks for confirming 14:08 < Not-3368> [wiki] Edit by Fenhl to Pre-release protocol -> http://tinyurl.com/gsbqza8 14:45 < rom1504> okay interesting 14:45 < rom1504> idk why mojang made that change so late 14:46 < rom1504> I'll try updating my protocol.json for pre4 14:46 < rom1504> so it's ready for the real release :) 15:50 < Huherak987> Is there anybody who would help me and my friend developing a plugin that would allo 1.9 clients to join 1.8.8 Spigot server for some nice amount of bucks ? We have done some basics (protocol injector) but we are stuck at transforming entity metadata 15:53 < rom1504> Fenhl: I think http://wiki.vg/index.php?title=Pre-release_protocol&diff=7380&oldid=7379 should probably be just "Absolute position" (to be consistent with stuff like http://wiki.vg/Protocol#Player_Position_And_Look_2 ) 15:55 < Fenhl> rom1504: the Player Position And Look packet needs that clarification because it's a movement packet. Spawn packets don't 15:56 < Fenhl> but yeah, I could remove the notes entirely 16:00 < rom1504> ah 16:00 < rom1504> yeah ok, it's ok that way 16:05 < rom1504> it would be so nice if mojang could settle on a single position format 16:06 < rom1504> instead of using lot and lot of them 16:06 < rom1504> bitfield, double, int,... 16:06 < rom1504> I wonder if the 2 remaining packets using int for position have also be changed to double 16:07 < rom1504> 3 actually 16:08 < rom1504> ah no 2 http://wiki.vg/Protocol#Spawn_Global_Entity http://wiki.vg/Protocol#Spawn_Experience_Orb 16:08 < rom1504> the other one uses a bitfield 16:08 < rom1504> well anyway 16:08 < rom1504> I don't even know why there isn't just a single spawn packet 16:09 < rom1504> let's assume they didn't change these 2 packets 16:35 < Not-e729> [Charge] Wallbraker pushed 7 commits to master [+2/-0/±28] https://github.com/VoltLang/Charge/compare/9e3844d26491...3b80f162257b 16:35 < Not-e729> [Charge] Wallbraker 44e374e - math: Add copyright to matrix 16:35 < Not-e729> [Charge] Wallbraker bfbe473 - math: Add point and vector 16:36 < Not-e729> [Charge] Wallbraker 5775df5 - core: Make function global 16:36 < Not-e729> [Charge] ... and 4 more commits. 16:48 < Huherak987> can somebody confirm that the new entity metadata indexes and types are correct for pre4 ? 16:49 < rom1504> I can confirm the types are correct for 16w04a 16:49 < rom1504> no clue about the indexes, and idk if anything changed in pre4 16:50 < rom1504> I think there is something wrong with http://wiki.vg/Pre-release_protocol#Spawn_Object though 16:50 < rom1504> I'm getting errors about it 16:50 < rom1504> trying to figure out what 17:02 < Huherak987> Yeah, I got also error in that packet 17:02 < Not-3368> [wiki] Edit by Fenhl to Pre-release protocol -> http://tinyurl.com/gts4f9g 17:04 < Huherak987> rom1504 but somebody earlier this day said that the protocol is documented for the latest version so pre4, so its a bit confusing now 17:04 < rom1504> pre-release was correct for 16w04a. Now some stuff are updated in it for pre4 but not the whole thing 17:07 < Huherak987> Well, as I said I am working on plugin for spigot 1.8.8 that will allow 1.9 clients to join, it is working so the client gets connected to the server but once entity metadata packet is sent client crashes with error "Byte canno be cast to Float" 17:07 < Fenhl> Pre-release protocol should always be on latest snapshot/pre-release 17:07 < rom1504> did you translate the entity metadata Huherak987 ? lot of things changed in it from 1.8 17:08 < Fenhl> yeah, some things aren't going to be updated right away but that doesn't mean we should stay on an old version 17:08 < rom1504> (I mean the types and the whole format) 17:08 < Huherak987> Of course I did, but I think there is something wrong documented because my client always crashes with this error 17:08 < rom1504> Fenhl: yes indeed 17:08 < Huherak987> I think it has something to do with absorption hearths 17:08 < Huherak987> hearts * 17:09 < rom1504> Huherak987: these indexes haven't be changed in a while http://wiki.vg/Pre-release_protocol#Entity_Metadata 17:09 < rom1504> but you don't really need them at the protocol level 17:10 < rom1504> you mostly need the types 17:10 < Huherak987> What do you mean by" I dont need them" ? I have to translate 1.8 packet from server to be compatible with 1.9 client 17:10 < rom1504> yes for the full translation you need them 17:11 < rom1504> but if they are incorrect, you still shouldn't produce wrong packets 17:11 < rom1504> the types are available independently from the indexes 17:12 < Huherak987> Yeah but in case that some index is wrong client is assuming some value as something different than the value actually represents 17:12 < Huherak987> And I think that this is exactly my problem, client receives byte instead of float for some reason 17:13 < rom1504> that means you are ignoring the type 17:13 < rom1504> well 17:13 < rom1504> anyway 17:14 < rom1504> what is sure is that the indexes are updated 17:14 < rom1504> *outdated 17:14 < rom1504> they should probably be updated 17:15 < rom1504> I'm trying to read the decompiled thing to get more info about spawn object 17:15 < rom1504> so https://gist.github.com/rom1504/dc44d011bf8a5427cb94 that's for finding which file to look into 17:17 < rom1504> http://wiki.vg/Pre-release_protocol#Spawn_Object https://gist.github.com/rom1504/dc44d011bf8a5427cb94#file-protocol-json-L71 17:17 < rom1504> looks like there's a new byte 17:18 < rom1504> hmm no 17:22 < rom1504> okay found something 17:22 < rom1504> dX dY dZ are now short 17:22 < rom1504> in http://wiki.vg/Protocol#Entity_Look_And_Relative_Move 17:22 < rom1504> and other packets 17:25 < rom1504> http://wiki.vg/Protocol#Entity_Teleport now uses double for the position 17:28 < rom1504> seems like that's all, it works 17:28 < rom1504> I'll make these changes 17:34 < Not-e729> [minecraft-data] rom1504 pushed 1 commit to master [+0/-0/±4] https://github.com/PrismarineJS/minecraft-data/compare/e1299ee2cf51...fb97e8c53c31 17:34 < Not-e729> [minecraft-data] rom1504 fb97e8c - update 1.9 to 1.9-pre4 * packet_spawn_entity, packet_spawn_entity_experience_orb, packet_spawn_entity_weather, packet_spawn_entity_living and packet_named_entity_spawn use f64 instead of i32 for position now * packet_rel_entity_move and packet_entity_move_look use i16 instead of i8 for relative move now * packet_entity_teleport uses f64 instead of i32 for position now 17:40 < Not-3368> [wiki] Edit by Rom1504 to Pre-release protocol -> http://tinyurl.com/hqynoj7 17:43 < Not-3368> [wiki] Edit by Rom1504 to Pre-release protocol -> http://tinyurl.com/jqevz72 17:44 < Not-3368> [wiki] Edit by Rom1504 to Pre-release protocol -> http://tinyurl.com/h4qpomv 17:53 < Not-3368> [wiki] Edit by Rom1504 to Pre-release protocol -> http://tinyurl.com/hqmj5hb 17:58 < Not-3368> [wiki] Edit by Rom1504 to Pre-release protocol -> http://tinyurl.com/jfkypzj 17:58 < rom1504> alright, all edited 17:59 < Not-3368> [wiki] Edit by Rom1504 to Pre-release protocol -> http://tinyurl.com/z84neg2 18:06 < Huherak987> could somebody help me please, how to read Entity Metadata packet http://wiki.vg/Pre-release_protocol#Entity_Metadata ? First I read unsigned byte, then byte and then value depending on the byte (for example if the byte is 1 then I read varint) but for some reason I got always index and type == 0, why ? 18:10 < pokechu22> Can you post the code you're using to read it on gist.github.com? 18:11 < rom1504> Huherak987: you should check the "value depending on the byte" fits the type (== the unsigned byte) 18:12 < rom1504> hmm 18:12 < rom1504> no 18:12 < rom1504> you should read the value depending on the unsigned byte 18:12 < rom1504> there's no point in depending on the index at that time 18:12 < Huherak987> pokechu22 here it is: https://gist.github.com/anonymous/f58ba4f42c5e722e1255 18:13 < rom1504> https://github.com/PrismarineJS/node-minecraft-protocol/blob/master/src/datatypes/minecraft.js#L130 18:14 < rom1504> nevermind the type is indeed the second byte 18:14 < rom1504> hmm 18:14 < Huherak987> rom1504 field named "type" is defining the data type of value, correct me if I am wrong 18:15 < Huherak987> whatever but I got always index && type == 0 18:16 < rom1504> Huherak987: can you indent the gist correctly ? it's kind of hard to read that way (and name the file .java so it's syntax highlighted) 18:17 < Huherak987> yeah, sorry I am going to rewrite it because it has offset because of my IDE 18:19 < rom1504> that's what we're using but it's kind of hard to understand without knowing about the format and all https://github.com/PrismarineJS/minecraft-data/blob/master/data/1.9/protocol.json#L133 18:19 <+Amaranth> lol at people thinking Mojang would sell a license that allows them to violate the EULA's rules on p2w crap 18:21 < Huherak987> rom1504 lol sorry I am stupid, it was my while cycle mistake :D 18:22 < rom1504> Huherak987: you should update all the packets I updated in pre-release now if you want to support 1.9-pre4 ;) 18:23 < Huherak987> rom1504 ok thanks, but I am still stuck with translating the Entity Metadata (0x39) packet 18:23 < rom1504> ah, still doesn't work 18:23 < Huherak987> because this packet has the most significant changes if I dont count the chunk data 18:23 < rom1504> ? 18:23 < rom1504> yes 18:27 < Huherak987> rom1504 I am just doing a simple console client that is reading vanilla packets so I know the exact format and then my friend is doing that translating plugin, and I am comparing his translated packets and vanilla packets :D 18:31 < rom1504> okay 18:32 < Not-e729> [mineflayer] rom1504 pushed 2 commits to master [+0/-0/±2] https://github.com/PrismarineJS/mineflayer/compare/b566a764b938...b26ce963f7eb 18:32 < Not-e729> [mineflayer] rom1504 b26ce96 - Merge pull request #399 from PrismarineJS/greenkeeper-minecraft-data-1.2.0 Update minecraft-data to version 1.2.0 🚀 18:32 < Not-e729> [mineflayer] rom1504 deleted branch greenkeeper-minecraft-data-1.2.0 18:33 < Not-e729> [flying-squid] rom1504 pushed 2 commits to master [+0/-0/±2] https://github.com/PrismarineJS/flying-squid/compare/77efc96d2ce6...dc52841a3b2b 18:33 < Not-e729> [flying-squid] rom1504 dc52841 - Merge pull request #216 from PrismarineJS/greenkeeper-minecraft-data-1.2.0 Update minecraft-data to version 1.2.0 🚀 18:33 < Not-e729> [flying-squid] rom1504 deleted branch greenkeeper-minecraft-data-1.2.0 19:51 < rom1504> Oh I didn't update "This packet allows at most four blocks movement in any direction, because byte range is from -128 to 127." 19:53 < rom1504> now -32768 to 32767, it allows 1024 blocks distance move now 19:56 < Not-3368> [wiki] Edit by Rom1504 to Pre-release protocol -> http://tinyurl.com/hkb4qu9 19:58 < Not-3368> [wiki] Edit by Rom1504 to Pre-release protocol -> http://tinyurl.com/jvyodys 19:59 < Not-3368> [wiki] Edit by Rom1504 to Pre-release protocol -> http://tinyurl.com/zdnbk2u 20:14 < Huherak987> rom1504 ? http://wiki.vg/Pre-release_protocol#Entity_Metadata if there is no Human entity listed it means that indexes and data havent changed at all ? 20:14 < Huherak987> Because in 1.8 protocol there is Human entity listed 20:15 < Huherak987> SO I am not sure if those ids are correct or not 20:17 < Huherak987> I am 100% sure that there are changes 20:18 < Huherak987> index 16, byte, in human entity has description: appears to be unused 20:18 < Huherak987> and in 1.9 pre 4 this byte value is not present 20:19 < rom1504> Huherak987: no, it's not a change list, if it's not there then it doesn't exist 20:19 < rom1504> but 20:19 < rom1504> keep in mind that list was last updated months ago 20:19 < Huherak987> Human entity exists in 1.9 100% sure 20:20 < rom1504> the last was correct when Thinkofname updated it some months ago. I don't think anybody updated it since then 20:20 < rom1504> *the list 20:20 < Huherak987> someone just maybe forgot to list it 20:20 < Huherak987> but I am now debugging this packet and I got these values from the server 20:20 < rom1504> well if you got better data, update the list ;) 20:21 < rom1504> I guess it would also be possible to look at the decompiled code for this 20:22 < Huherak987> in 1.9 Human entity has the following values: 10 - byte, 16 - float (absoprtion hearts), 17 - int (score) 20:30 < rom1504> Huherak987: update the wiki ;) 20:31 < Huherak987> rom1504 I have to be register or something to makes changes ? 20:31 < Huherak987> registered * 20:37 < rom1504> Huherak987: yeah you need to register 20:38 < pokechu22> It's easy enough to sign up - you just need to select "Create account" at the top. 21:53 < Huherak987> pokechu22 are you here ? 21:53 < pokechu22> Yes 21:53 < Huherak987> I have question, if you look at preprelease protocol, there is stated that Entity Look has changed, but the link is empty 21:54 < Huherak987> So is this packet change or unchanged ? 21:54 < Huherak987> changed * 21:58 < Not-3368> [wiki] Edit by Rom1504 to Pre-release protocol -> http://tinyurl.com/zp45skh 21:58 < pokechu22> I think that's your answer. 21:59 < Huherak987> Yeah, thanks anyway :)) 22:00 < pokechu22> And it doesn't seem like it's changed from what burger is showing. 22:01 < Huherak987> pokechu22, thanks for confirmation 22:14 < MylesC> anyone got examples of the new chunk packet format (with palettes)? 22:15 < Huherak987> One more question, 0x1B - Entity Status, should't be the Entity ID VarInt like in all other packets with Entity ID ? 22:16 < MylesC> nah, that's mojang being inconsistent :P 22:19 < clonejo> does anybody know good routes to china telecom? 22:21 < pokechu22> Nope, it's a regular int, can confirm with burger. 22:42 < pokechu22> ? --- Day changed dim. févr. 28 2016 00:15 < Huherak987> One thing, what is the difference between 0x19 Named sound effect and 0x47 sound effect ? They seem to be similar 00:17 < Huherak987> pokechu22 do you have any idea ? Or does the burger have any idea ? :D 00:19 < redstonehelper> Huherak987: possibly used for music in jukeboxes where the title displays above the hotbar on clients 00:19 < pokechu22> It looks like the only difference is one uses an enum and the other uses a string for the id/name 00:20 < pokechu22> Burger's only good for figuring out packet structure right now. I've got no clue how else these packets are different. 00:21 < Huherak987> redstonehelper well but what is the old ID (I mean in protocol 47) of each one of these packets ? 00:21 < redstonehelper> I know some of those words 00:22 < Huherak987> ? 00:23 < Huherak987> I mean, 0x47 is completely new packet or it already existed in protocol 47 ? 00:24 < Huherak987> because in http://wiki.vg/Pre-release_protocol packets table it is a bit confusing 00:26 < pokechu22> I think 1.8 only had the text-based sound effect one; the number one is new. 00:26 < pokechu22> Might be wrong about that. 00:28 < M1nef4n> in protocol 47 packet 0x2F = Set Slot (serverbounds) http://wiki.vg/Protocol#Set_Slot 00:29 < M1nef4n> but in diff table is 0x2F -> 0x19: Named Sound Effect 00:30 < M1nef4n> there is no clientbound packet 0x2F in protocol 47 00:40 <+Amaranth> pokechu22: Nah they started with the enum one and added the string one later 00:40 <+Amaranth> The enum one is basically legacy at this point I think, I'm not sure why they haven't removed it 00:41 <+Amaranth> I mean, I'm pretty sure they use it but I'm also pretty sure it's fully redundant 00:44 < _MylesC> I'm rather inexperienced with bytes and bits in java, what's the best way to arrays of 13 bits converted into bytes? (any suggestions are welcome) 00:45 < rom15044> 13, are you sure about that number? 00:46 < rom15044> Anyway, bitshifts 00:47 < _MylesC> am i being dumb? "(with 13 bits per block)" for chunk section format? 00:47 < _MylesC> that means each block is 13 bits, followed by next block 13 bits for data array in chunk section? 00:50 < rom15044> ", followed by padding to round the length up to the next multiple of 8 bytes" ah ok 00:50 < rom15044> So anyway, you need to use bitwise operations 00:50 < _MylesC> ugh, why 13 bits >:( 00:51 < rom15044> Heh you know, mojang uses every opportunity to do complicated stuff ;) 00:52 < rom15044> Always more fun 00:53 < Huherak987> yeah, but officialy they like community modders.... but they are just making their lives harder as much as possible, no mojang api, no mojang protocol doc..... 00:56 < Huherak987> _MylesC do you know how the new (1.9) entity metadata works ? 00:56 < _MylesC> yah I have a working porter ;) 00:57 < _MylesC> Some of the metadata got new types, some of it didn't 00:58 < _MylesC> anything specific you need info on? 00:59 < Huherak987> Well, I just noticed that there are some changes in Human entity 00:59 < _MylesC> As far as i'm aware, human entity meta isn't used anymore (I could be wrong?) 01:00 < Huherak987> Yeah, on wiki there isnt anything about it 01:05 < _MylesC> I mean they either changed the method things like skin info is sent or it's just not documented 01:14 < Not-1653> [Glowstone] mastercoms pushed 2 commits [+0/-0/±2] https://github.com/GlowstoneMC/Glowstone/compare/df4c87096533...8f183d404323 01:14 < Not-1653> [Glowstone] mhsjlw aea9640 - Change the organization 01:14 < Not-1653> [Glowstone] mastercoms 8f183d4 - Merge pull request #648 from mhsjlw/patch-1 01:16 < Huherak987> What does "List of 4096 indices pointing to state IDs in the Palette" mean ? What is indice ? How should I read them ? 01:20 < pokechu22> "Indicies" is the plural of index, if that helps. 01:21 < _MylesC> You write x bits (according to palette config) which refers to a state ID given by the palette. (The 4096 indices is just all blocks in the section, strung together) 01:22 < M1nef4n> pokechu22 thx :D 01:22 < Huherak987> _MylesC but ho do they "refer" ? 01:22 < Huherak987> how * 01:22 < _MylesC> Nobody has documented it, but i'd assume it's some sort of table linking shorter bits to the state ids 01:23 < _MylesC> so that instead of sending a chunk of nothing which (by the normal would be 13 bits * 4096) 01:23 <+Amaranth> Huherak987: The chunk format got more complicated because it's an in-memory compression format 01:23 <+Amaranth> It keeps a palette of unique entries and a compressed array of pointers to the palette for the actual blocks 01:23 <+Amaranth> That's why they take up weird numbers of bits and such 01:23 < _MylesC> ^^ 01:24 <+Amaranth> So instead of storing a chunk full of 1s for all stone it'll store a palette with 1 entry for stone and an array of 1 bit values to point to it 01:25 <+Amaranth> Unless he added the "these are all the same" compression setup like CraftBukkit and Spigot had, then it'd store even less 01:26 < Huherak987> hmm thanks 01:26 <+Amaranth> It's kind of like GIF files, if that helps? 01:26 <+Amaranth> Or any other indexed color format 01:27 < Huherak987> I am just thinking of way how to read them... 01:27 <+Amaranth> It's going to be fiddly 01:27 < _MylesC> Read the entire thing as bytes, then use bitwise ops to extract the info 01:27 < _MylesC> I'm currently writing the reverse 01:29 <+Amaranth> Hrm, global palette, what's the point of that? 01:29 <+Amaranth> That must be for when you have a lot of different kinds of blocks 01:29 < _MylesC> it's currently my one true god ;) 01:29 < _MylesC> cause it means I don't have to make my own palette generator and just use it 01:29 <+Amaranth> Better to be a little wasteful in this chunk so you can share the palette and save memory overall 01:30 <+Amaranth> Making your own palette isn't hard 01:30 <+Amaranth> It's supposed to be done on the fly as you're modifying the chunk 01:30 <+Amaranth> This is the in-memory format in the server 01:30 < _MylesC> maybe i'll implement it after I implement the magic bit to byte writing system haha 01:30 <+Amaranth> It's just getting dumped out on the wire with minimal framing 01:31 <+Amaranth> This is a huge memory win 01:33 <+Amaranth> Oh wow he adding a bunch of padding to the wire format 01:33 < _MylesC> it's not that much padding 01:34 <+Amaranth> That 4096 array for blocks is pretty much always just a handful of bits in memory but he makes each one a long on the wire? 01:34 <+Amaranth> Oh, no, I see 01:34 <+Amaranth> bits per block tells you how to parse this array and the padding is just because this is a long[] 01:47 < rom1504> "It uses the block ID for the first 9 bits, and the block damage value for the last 4 bits" I don't understand why 9 bits are needed for the block id 01:48 < rom1504> 8 is enough 01:48 < rom1504> and then that micro-optimization for damage value all the time 01:48 < rom1504> it could just be a byte too 01:48 < rom1504> that would be 2 bytes, would work just fine 01:49 < rom1504> but well 01:49 < rom1504> let's do 13 bits, at least it makes us learn more about bitwise operations 01:49 <+Amaranth> Probably wasn't hard to encode it that way, reusing code 01:50 <+Amaranth> You're going to have to get good at those to read the block array anyway, it's always 13 bits or less per entry 01:52 < Huherak987> Amaranth have you received my private message here on irc ? 01:57 <+Amaranth> Not interested, sorry 02:30 < Not-1653> [flying-squid] rom1504 deleted branch greenkeeper-minecraft-protocol-0.19.0 02:30 < Not-1653> [flying-squid] rom1504 pushed 2 commits to master [+0/-0/±2] https://github.com/PrismarineJS/flying-squid/compare/dc52841a3b2b...5958c154d67f 02:30 < Not-1653> [flying-squid] rom1504 5958c15 - Merge pull request #217 from PrismarineJS/greenkeeper-minecraft-protocol-0.19.0 Update minecraft-protocol to version 0.19.0 🚀 02:34 < Not-1653> [mineflayer] rom1504 pushed 2 commits to master [+0/-0/±2] https://github.com/PrismarineJS/mineflayer/compare/b26ce963f7eb...e2740a1d3047 02:34 < Not-1653> [mineflayer] greenkeeperio-bot d82a93a - chore(package): update minecraft-protocol to version 0.19.0 http://greenkeeper.io/ 02:34 < Not-1653> [mineflayer] rom1504 e2740a1 - Merge pull request #400 from PrismarineJS/greenkeeper-minecraft-protocol-0.19.0 Update minecraft-protocol to version 0.19.0 🚀 02:34 < Not-1653> [mineflayer] rom1504 deleted branch greenkeeper-minecraft-protocol-0.19.0 05:09 < Not-4b4f> [wiki] Edit by Floppy012 to Pre-release protocol -> http://tinyurl.com/gv6hxfx 07:07 < javaprophet> I'm creating a rendering client for MC in native C for Linux and Mac, is there anyone interesting in contributing? 07:07 < javaprophet> and Windows* 07:27 < mccstone> hey just wanted to to ask if there is more info on what does each value of a packet especifically does 07:27 < mccstone> for each packet 07:31 < javaprophet> mccstone, I recommend keeping an Eclipse open in the background at all times with MCP in it. :) 07:35 < mccstone> To be precise, I want to know some of the values that the WorldBorder packet really do 07:35 < mccstone> what* 07:35 < mccstone> For example OldRadius 07:40 < pokechu22> I think the old radius is there so that it can be animated cleanly, but from what I can tell the old radius is just the current radius. 07:44 < mccstone> And how would I know what the old radius is? 07:50 < pokechu22> It's the value you want it to start shrinking or growing from; in most cases this will be what was previously set, I think. 07:52 < mccstone> pokechu22, Isnt world border packet a way to prevent chunk loading beyond certain point and also block playes from traspassing said limit? 07:53 < pokechu22> I don't think world border does anything with chunk loading, but it does act as a wall. 07:53 < pokechu22> http://minecraft.gamepedia.com/World_border 08:01 < mccstone> If I happen to send that packet do I have to send it to every player on login or just once? 08:01 < javaprophet> Every player. 08:49 < Not-4b4f> [wiki] Edit by Floppy012 to Pre-release protocol -> http://tinyurl.com/hjwq896 09:12 < ecx86> oh hey prophet 12:09 < Huherak987> Anyone interested in writing 1 method in java that would transform object org.bukkit.Chunk (from Spigot 1.8.8) into new Chunk Section protocol format ? My offer is $80 12:10 < ecx86> why 12:15 < Not-4b4f> [wiki] Edit by Rom1504 to Protocol version numbers -> http://tinyurl.com/hvvm538 12:21 < Huherak987> exc86 because I am working on protocol hack I got everything else done (translating all other packets) I am just stuck with this one 12:21 < Huherak987> ecx86 * 12:22 < ecx86> . 12:23 < ecx86> so what is the new format like 12:23 < Huherak987> http://wiki.vg/Pre-release_protocol#Chunk_Section 12:26 < Huherak987> I just want to allow 1.9 clients join my 1.8.8 spigot server, I have already transformed all packets so now 1.9 client can join my server but he dont see the map and this is the only thing I am missing 12:27 < ecx86> is it hard for you to write this? 12:29 < Huherak987> Well, I just dont get the idea of palette and this data array... I was already messing up like 2 days with entity metadata because there is also everything changed 12:31 < ecx86> i suppose i could help you 12:31 < Huherak987> You know, I am just coding in my free time its not my job, I am not coding rockstar this is too much 12:31 < ecx86> bits per block is 0 12:31 < ecx86> dont send pallete length or pallete 12:31 < Huherak987> Yeah this thing I have also realized 12:32 < Huherak987> but I am lost with data array 12:32 < ecx86> ok 12:32 < ecx86> data array is just block states 12:32 < ecx86> each block state is 13 bits long 12:32 < ecx86> pack them together into array of longs (64 bits), pad at the end if neccessary 12:33 < ecx86> data array length is the number of longs you needed to pack together your block states 12:34 < ecx86> "Data Array, Block Light, and Sky Light are given for each block with increasing x coordinates, within rows of increasing z coordinates, within layers of increasing y coordinates. " 12:35 < ecx86> do you know how to pack bits into bytes? 12:35 < ecx86> * Huherak987 12:36 < Huherak987> I dont think so 12:37 < ecx86> do you understand bit shift operators? 12:37 < Huherak987> Yeah this I know 12:38 < Huherak987> But still it would be best if you write method that would transform org.bukkit.Chunk into this format or the old Chunk Section packet from 1.8 and I give you 80 bucks and we are done :) 12:38 < ecx86> im really busy and i dont really have a way to accept payments right now 12:39 < ecx86> i might do it though 12:41 < Huherak987> I could pay you via PayPal or Credit Card 12:41 < Huherak987> from paypal you could transfer the money later to your bank or something 12:42 < ecx86> yea yea 12:46 < Huherak987> So do you agree ecx86 ? 12:46 < ecx86> idk. i might do it tommorow and then ill check back. im kind of busy 12:46 < ecx86> and its 6:46am and ive stayed up all night 12:46 <+SinZ> like a true programmer 12:47 < ecx86> well 12:47 < ecx86> I kind of stopped working after 4 and just did nothing for 3 hours 12:47 < Huherak987> :D 12:49 < Huherak987> It would be the best if you was able to finish today or tomorrows night in my country its 12:48 am 12:51 < Meeeh> in BlockFire there are 2 maps , one is flameChances and second idk, what they mean? like leaves use 30, 60, and log only 5,5 12:51 < Huherak987> ecx86 can I have some contact on you ? (Skype, ICQ, QIP) 12:52 < ecx86> ill do it tommorow 12:53 < ecx86> im off to bed 12:53 < Huherak987> ok, thanks 13:23 < Not-4b4f> [wiki] Edit by Fenhl to Protocol version numbers -> http://tinyurl.com/jg72x9w 13:30 < Fenhl> Meeeh: maybe one is chance of spreading to an air block next to that material (http://minecraft.gamepedia.com/Fire#Spread) and one is chance of burning the block and replacing it with air (http://minecraft.gamepedia.com/Fire#Burning_blocks)? 13:33 < Meeeh> Fenhl yeach, I also think like this, make sense, just asking if someone ever checked this 13:33 < Fenhl> if that's what you're looking at, maybe you want to add the exact numbers to the Minecraft Wiki? 13:35 < Fenhl> currently it just says flammable: yes/no on all the articles 13:38 < Meeeh> I don't have time, too many projects. if anyone want: https://hasteb.in/tiyucegave.java 16:29 < Floppy012> Anyone an idea, what the client needs from the server to start flying with elytra? 16:32 < _MylesC> meta data for player + entity action? 16:36 < rom1504> proxy it, then you know 16:41 < Floppy012> The only Metadata i could find is the 0x80 as described here http://wiki.vg/Pre-release_protocol#Entity_Metadata 16:41 < Floppy012> until now there is nothing i found the server sends to the client 16:42 < _MylesC> it's controlled by the client perhaps? 16:51 < Floppy012> think so. What i found out until now is, if you jump of a cliff and want to start fly then the client sends an EntityAction to the server, which then checks some parameters, and then setting 0x80 to true, and doing some move stuff. But nothing causes the client to spread the wings 20:08 < Huherak987> pokechu22 have you noticed any changes about Player Digging packet ? I think that in 1.9 there are some values ommited 20:10 < Huherak987> Because I think that in 1.9 there is no position send in this packet 20:14 < rom1504> looks like there is 20:14 < Meeeh> Huherak987, what? there must be a position 20:15 < Huherak987> Well, must be, but for some reason there are only 2 params in this packet 20:15 < Huherak987> in pre4 20:15 < Huherak987> byte enum and byte 20:16 < rom1504> no 20:16 < pokechu22> Position, varint enum, varint enum, byte, byte, byte 20:17 < rom1504> http://wiki.vg/Pre-release_protocol#Player_Digging byte position byte 20:17 < pokechu22> No itemstack anymore, though. 20:17 < Meeeh> oh, they finally removed that usless field 20:18 < pokechu22> Wait, I"m looking at player block placement... 20:19 < pokechu22> I see enum position byte. 20:20 < pokechu22> But I'm pretty sure it's a varint enum, not a byte enum. 20:20 < rom1504> http://wiki.vg/Pre-release_protocol#Player_Block_Placement 20:27 < _MylesC> im so proud of myself 20:27 < _MylesC> i managed to make my chunk converter from 1.8 -> 1.9 work :') 20:27 < _MylesC> just need to fix block lighting haha 22:25 < Huherak987> Anyone know what has changed in EntityRelativeMove move packet ? Because when I send those packets to 1.9 client its laggy and I see the mobs are not moving but teleporting, they stand on one place and then they teleport ... 22:32 < _MylesC> I'd assume so huherak, I get same results 22:33 < rom1504> Huherak987: it's documented there http://wiki.vg/Pre-release_protocol#Entity_Relative_Move 22:33 < rom1504> byte became a short 22:33 < Huherak987> rom1504 I know but there is something more .... 22:33 < rom1504> and now you need to send a lot more of these instead of teleporting 22:33 < rom1504> byte becoming a short has a lot of consequences Huherak987 22:34 < Huherak987> rom1504 for example ? 22:34 < rom1504> the server used to send the teleport packet every time an entity moved more than 4 blocks 22:34 < rom1504> now it should send the relative move packet 22:34 < rom1504> except if the entity move more than 1024 blocks, which shouldn't happen often 22:38 < Huherak987> But what is that new short ? If for example X has changed by 0.5 what is the short value ? 22:38 < Huherak987> 0.5 * 32 or what ? 22:39 < Not-1653> [minecraft-data] rom1504 pushed 1 commit to master [+0/-0/±1] https://github.com/PrismarineJS/minecraft-data/compare/fb97e8c53c31...271eb45dc3fb 22:39 < Not-1653> [minecraft-data] rom1504 271eb45 - extract 1.9 items with revision <2016-02-29T00:00:00Z 22:40 < Huherak987> rom1504 ^ ? 22:40 < rom1504> Huherak987: yes I think so 22:41 < rom1504> short is still an integer 22:41 < rom1504> so it should be fixed point 22:44 < Huherak987> rom1504 if from 1.8 server I got "Change in X" value 8, what it would be in 1.9 ? 22:46 < Huherak987> I mean if this byte from 1.8 server is 8, in 1.9 this short would be ? 22:52 < rom1504> Huherak987: 8 22:53 < Huherak987> hmm probably not because the move is completely laggy 22:53 < rom1504> but if you got "entity teleport" then you need to figure out what was the previous value, and send a entity relative move 22:53 < rom1504> (figure out what was the previous value and compute the delta) 22:54 < rom1504> Huherak987: I bet that's because you're not translating all the move packets 22:54 < Huherak987> you mean Entity Relative Move, Entity Look and relative move and entity teleport ? 22:55 < rom1504> yes 22:56 < Huherak987> rom1504, we are translating all of them 22:56 < rom1504> so you are indeed translating entity teleport to entity relative move ? 22:57 < Huherak987> You mean that I should translate 1.8 Entity teleport to Entity relative move ? 23:05 < rom1504> yes 23:15 < Not-1653> [minecraft-data] rom1504 pushed 1 commit to master [+0/-0/±1] https://github.com/PrismarineJS/minecraft-data/compare/271eb45dc3fb...6c8c63c0817a 23:15 < Not-1653> [minecraft-data] rom1504 6c8c63c - extract 1.9 blocks with revision <2016-02-29T00:00:00Z 23:22 < Not-1653> [minecraft-data] rom1504 pushed 1 commit to master [+0/-0/±1] https://github.com/PrismarineJS/minecraft-data/compare/6c8c63c0817a...b01963233f30 23:22 < Not-1653> [minecraft-data] rom1504 b019632 - extract 1.9 recipes with revision <2016-02-29T00:00:00Z --- Day changed lun. févr. 29 2016 00:12 < M4GNV5> sooo i just found this: https://github.com/showcases/hacking-minecraft i dont know how showcases work but i assume theres some way to get your project displayed there? 00:16 < rom1504> who put the projects there ? 00:18 < rom1504> mineflayer somehow ended up on that list 00:18 < M4GNV5> yeah and some minecraft-github-skin repo (bottom one) 00:23 < pokechu22> Running burger on _ALL_ of the 1.9 snapshots right now for packetinstructions - let's see how well it works. 00:28 < rom1504> pokechu22: what kind of stuff do packetinstructions contain ? the basic fields ? 00:29 < rom1504> all complicated fields are probably not very usable in this .json ? 00:32 < pokechu22> packetinstructions is supposed to disassemble the entire packet writing code for each packet, although it isn't always sucessful. 00:33 < pokechu22> But it generates the kind of data you see on http://b.wiki.vg/. 00:39 < rom1504> ok 02:04 < Not-4b4f> [wiki] Edit by Floppy012 to Pre-release protocol -> http://tinyurl.com/z2sec56 02:08 < Not-4b4f> [wiki] Edit by Floppy012 to Pre-release protocol -> http://tinyurl.com/zku8qno 02:09 < Not-1653> [minecraft-data] rom1504 pushed 1 commit to master [+0/-0/±1] https://github.com/PrismarineJS/minecraft-data/compare/b01963233f30...087dd73ab9ca 02:09 < Not-1653> [minecraft-data] rom1504 087dd73 - attach_entity has no leash in 1.9 http://wiki.vg/index.php?title=Pre-release_protocol&diff=7398&oldid=7395#Attach_Entity 02:11 < Floppy012> rom1504? 02:14 < rom1504> Floppy012: yes ? 02:14 < rom1504> you are correct about that change ;) 02:15 < Floppy012> You're a hard working guy :) 02:15 < Floppy012> firstly thought you were a bot or something 02:16 < Floppy012> because that commit came so instantly 02:16 < rom1504> well I was warned by Not-4b4f ^^ 02:17 < Floppy012> I'm still fascinated about all these IRC Bots, etc. 02:17 < Not-1653> [mineflayer] rom1504 deleted branch greenkeeper-minecraft-data-1.2.1 02:18 < Not-1653> [flying-squid] rom1504 deleted branch greenkeeper-minecraft-data-1.2.1 02:18 < rom1504> that's ^ a bot though, checking stuff still work with that change 11:38 < Not-4b4f> [wiki] Edit by Paulomart to Pre-release protocol -> http://tinyurl.com/zn6krj4 11:41 < Not-4b4f> [wiki] Edit by Clankstar to Pre-release protocol -> http://tinyurl.com/gro4kwq 12:27 < rom1504> "(currentX * 32 - prevX * 32) * 128" wtf really ? 12:27 < rom1504> what's the point of that ? 12:28 < rom1504> ah without rounding I guess, so it gives a better precision if you don't store the fixed point values 12:29 < rom1504> if this is true then " Since a short range is limited from -32768 to 32767, and movement is offset of fixed-point numbers, this packet allows at most 1024 blocks movement in any direction. (-32768/32 == -1024)" should be reverted to the old description 12:29 < rom1504> if someone can check what Paulomart changed ? 12:32 < tktech> rom1504, if he's using updated burger code, it uses jawa to pseudo-decompile packets. It can handle complicated logic. 12:33 < tktech> It's more for human-readable output that you can easily translate into a wiki update then anything else 12:37 < rom1504> ok. I'm sure it can handle complicated logic, but I doubt it does. There are a few complicated field type in the mc protocol 12:37 < rom1504> I mean, jawa can surely handle it 12:40 < tktech> rom1504, http://b.wiki.vg/1.6.2 12:41 < tktech> An old example, but it doesn't have a problem with any of the pre-release packets 12:41 < hansihe> https://twitter.com/jeb_/status/704262855231717376 12:41 < rom1504> ah yeah these cases and loops, ok 12:42 < rom1504> why is there no varint though 12:42 < rom1504> there was no varint in 1.6 ? 12:42 < tktech> Correct 12:43 < tktech> It's pretty much a specialized decompiler tuned for a single subclass at that point. It produces human-readable code not necessarily something you can turn around and recompile 12:44 < rom1504> yeah I see, pretty good 15:38 < rom1504> > 1.9 is out 15:39 < Akaibu> Full release rom1504? 15:42 < rom1504> http://blog.mojang.com/2016/02/minecraft-19-combat-update/ yes 15:42 < rom1504> Removed Herobrine 15:42 < Akaibu> Le 15:52 < barneygale> 2funny4me 15:53 < hansihe> someone should keep a counter 16:10 < Huherak987> Are there any major changes in 1.9 protocol againts the pre4 of which I should know about ? 16:15 < Huherak987> Well the Set Slot packet has changed since pre4 16:34 < Not-1653> [mineflayer] rom1504 pushed 1 commit to master [+0/-0/±1] https://github.com/PrismarineJS/mineflayer/compare/e2740a1d3047...34df25992cf6 16:34 < Not-1653> [mineflayer] rom1504 34df259 - update readme links using frankenstein 16:36 < Not-1653> [minecraft-data] rom1504 pushed 1 commit to master [+0/-0/±1] https://github.com/PrismarineJS/minecraft-data/compare/087dd73ab9ca...7bbb5a99ec5f 16:36 < Not-1653> [minecraft-data] rom1504 7bbb5a9 - update README links using frankenstein 16:37 < rom1504> Huherak987: if you find any change, document them on the wiki ;) 16:37 < rom1504> I didn't try my proxy with it yet 16:38 < Huherak987> rom1504 what is the protocol version number of 1.9 ? 16:38 < barneygale> guess i'll update quarry tonight 16:38 < rom1504> Huherak987: n+1 16:38 < Huherak987> 48 ? 16:38 < rom1504> so 107 16:39 < rom1504> Huherak987: http://wiki.vg/Protocol_version_numbers 16:41 < tktech> Hundred+ releases and six years later 16:41 < Huherak987> rom1504 but there should not be any major changes from pre4 to final am I right ? 16:47 < pokechu22> I shouldn't be here right now, but... 16:47 < pokechu22> http://pokechu22.github.io/Burger/1.9.json and http://pokechu22.github.io/Burger/1.9.html#packets 16:47 < pokechu22> OK, cya everyone. 16:47 < tktech> He really needs a bouncer. 16:48 < rom1504> Huherak987: probably not a lot 16:49 < rom1504> it's not like mojang worked all week end to break everything 16:52 < tktech> That's how you jynx it. 16:57 < Not-4b4f> [wiki] Edit by Pokechu22 to Protocol version numbers -> http://tinyurl.com/z4o2bwq 17:00 < Fenhl> oh hey look it's a release 17:00 < Fenhl> I'll start merging [[Pre-release protocol]] into [[Protocol]] then 17:05 < AlphaBlend> yay 17:05 < AlphaBlend> finally mojang 17:18 < Not-4b4f> [wiki] Edit by Fenhl to Pre-release protocol -> http://tinyurl.com/jfjzpcy 17:18 < Not-4b4f> [wiki] Edit by Fenhl to Protocol -> http://tinyurl.com/jm239qs 17:28 < Huherak987> What exactly should I sent to 1.8 server, when I want to eat an apple for example ? 0x08 - location, byte -1, slot, -1, 255, -1 ? 17:50 < Not-4b4f> [wiki] Edit by Pokechu22 to Protocol version numbers -> http://tinyurl.com/hpe4cu7 18:09 < rom1504> Huherak987: probably 18:11 < Not-4b4f> [wiki] Edit by Pokechu22 to Entities -> http://tinyurl.com/gr4rlb3 18:11 < konwboy> Hello. Is log of this channel available anywhere? 18:12 < Akaibu> "Channel is publicly logged as of Feb.25/13" 18:13 < konwboy> Where can I find the log? 18:18 < barneygale> Nowhere 18:31 < Not-1653> [minecraft-data] rom1504 pushed 1 commit to master [+0/-0/±3] https://github.com/PrismarineJS/minecraft-data/compare/7bbb5a99ec5f...4509cac30f59 18:31 < Not-1653> [minecraft-data] rom1504 4509cac - update 1.9 version to 1.9 (release) 18:38 < Not-1653> [flying-squid] rom1504 deleted branch greenkeeper-minecraft-data-1.2.2 18:38 < Not-1653> [mineflayer] rom1504 deleted branch greenkeeper-minecraft-data-1.2.2 18:42 < Not-1653> [mineflayer] rom1504 deleted branch greenkeeper-minecraft-protocol-0.19.1 18:42 < Not-1653> [flying-squid] rom1504 deleted branch greenkeeper-minecraft-protocol-0.19.1 18:42 < rom1504> 05:37 < TkTech> Pretty logs optionally available to anyone (must be enabled by a channel op), and full text searching for select channels (limited resources) 18:42 < rom1504> (on 26/02/2013) 18:43 < rom1504> idk what happened with that 18:43 -!- Irssi: #mcdevs: Total of 152 nicks [1 ops, 0 halfops, 13 voices, 138 normal] 18:43 < rom1504> I certainly got all the logs 18:44 < rom1504> since janv. 07 02:20:15 2013 18:45 < Fenhl> rom1504: want to publish them somewhere? 18:49 < rom1504> I could, do you think it would be useful ? 18:53 < M1nef4n> can somebody explain me how eating works in 1.9? 18:55 < Fenhl> rom1504: yes 18:56 < Fenhl> (don't publish logs from before the topic was changed, that would be against freenode policy) 18:56 < Not-4b4f> [wiki] Edit by Fenhl to SMP Map Format -> http://tinyurl.com/jsxjbgg 18:59 < Not-4b4f> [wiki] Edit by Fenhl to Pre-release protocol -> http://tinyurl.com/hkb7cqg 18:59 < Not-4b4f> [wiki] Edit by Fenhl to SMP Map Format -> http://tinyurl.com/zw4j9m5 18:59 < Not-4b4f> [wiki] Edit by Fenhl to Pre-release protocol -> http://tinyurl.com/zj95pdk 19:04 < tktech> I've toyed with logging from the notifico bots a couple of times but nothing has ever become a permanent feature. 19:04 < tktech> That line in the MOTD is a disclaimer required by freenode for logged channels 19:05 < tktech> Currently, the notifico bots DO log channels, but they strip out PRIVMSGs and NOTICE first for privacy 19:06 < walle303> Freenode requires publically logged channels to have a notice? 19:07 < Fenhl> yes 19:07 < Fenhl> in the topic or the ChanServ join notice 19:08 < Not-4b4f> [wiki] Edit by Fenhl to Entities -> http://tinyurl.com/h9qxloc 19:08 < Fenhl> does anyone want to update http://wiki.vg/Entity#Entity_Metadata_Format for 1.9? Info is currently at http://wiki.vg/Pre-release_protocol#Entity_Metadata 19:10 < rom1504> oh that means I have to cut them, hmm 19:11 -!- Topic for #mcdevs: A haunt for developers working on projects related to Minecraft | Website & Rules: http://wiki.vg/MCDevs/rules | Wiki: http://wiki.vg | Channel is publicly logged as of Feb.25/13 19:11 -!- Topic set by TkTech [~TkTech@irc.tkte.ch] [Tue Sep 2 16:21:37 2014] 19:12 < tktech> walle303, the freenode site is currently down, but read the bottom of http://webcache.googleusercontent.com/search?q=cache:UsQUJssQtCEJ:https://freenode.net/channel_guidelines.shtml&num=1&hl=en&gl=ca&strip=1&vwsrc=0 19:13 < tktech> It's a losely-followed policy because of how crazy it can get ("request permission from every participant...") --- Log opened lun. févr. 29 19:29:18 2016 19:29 -!- Irssi: #mcdevs: Total of 152 nicks [1 ops, 0 halfops, 13 voices, 138 normal] 19:29 -!- Irssi: Join to #mcdevs was synced in 0 secs 19:29 < rom1504> test 19:29 < rom1504> ok 19:30 < rom1504> I did echo 1 > \#mcdevs.log 19:30 < rom1504> except it was a symlink :D 19:30 < rom1504> lucky my I had downloaded it a few mins ago to test 19:30 < rom1504> *me 19:34 < Fenhl> no one doing entity metadata? 19:34 * Fenhl sighs 19:34 < Fenhl> I guess I'll do that then 19:35 < tktech> Fenhl, <3 19:43 < walle303> Does anyone know the development status of spigot 1.9? 19:44 < pokechu22> They said they'd release it tomorrow. 19:44 < pokechu22> And they've already got an API of some sort. But that's all I know. 20:03 < hansihe> full hair-on-fire mode in here i see :) 21:15 < Not-8b17> [Charge] Wallbraker pushed 3 commits to master [+1/-0/±9] https://git.io/v2o8W 21:15 < Not-8b17> [Charge] Wallbraker d4aedc1 - gfx: Add target 21:16 < Not-8b17> [Charge] Wallbraker a0c0736 - game: Use target when rendering 21:16 < Not-8b17> [Charge] Wallbraker e4a017a - game: Use width and height from target in background 22:05 < Gjum> rom1504: did you already check mcdata against the new burger data? 22:10 < rom1504> Gjum: what part of burger data ? 22:10 < rom1504> packets didn't change according to my extractor, and nmp proxy works fine on 1.9 22:10 < Gjum> protocol, entities for example 22:10 < rom1504> so I'm assuming protocol didn't change between pre4 and 1.9 22:11 < Not-9c26> [wiki] Edit by Fenhl to Entities -> http://tinyurl.com/hhzwdxc 22:11 < rom1504> no I didn't check entities 22:12 < rom1504> once pokechu22 has finished updating burger, I guess I'll try to make that script work again https://github.com/PrismarineJS/minecraft-data/blob/master/tools/js/burger_extractor/generate_enums.js 22:12 < Gjum> also block/item ids/names 22:12 < rom1504> so I can compare easily with mcdata data 22:12 < Fenhl> rom15044: protocol version number changed, but redstonehelper has been marking all bugs that affect pre4 as affecting 1.9 as well, so I'm assuming that was literally the only change 22:12 < Gjum> yeah in the end burger is more dependable than the wiki 22:13 < rom1504> Gjum: it is, but I can't directly use it since it's missing most of the data 22:13 < rom1504> but yeah using it to check stuff would be interesting 22:13 < redstonehelper> Fenhl: to be fair I do not know if there were any changes between pre4 and release 22:13 < redstonehelper> I really really really hope that they did not touch anything 22:14 < Gjum> for the transition at least, and maybe for fixing the wikis C: 22:14 < Not-9c26> [wiki] Edit by Fenhl to Pre-release protocol -> http://tinyurl.com/zr2gbs7 22:14 < Fenhl> redstonehelper: %) 22:14 < redstonehelper> )) 22:15 < redstonehelper> btw I'm very glad 1.9 snapshots are over, Fenhl's confirming bugs for every snapshot got a bit tedious :D 22:15 < barneygale_> why are there now 2 sound effect packets? 22:15 < rom1504> same reason there are 6 spawn packets 22:15 < rom1504> more packets = better 22:15 < redstonehelper> (keep doing that, Fenhl) 22:15 < Sudzzy> 1 wasnt enough 22:15 < Fenhl> redstonehelper: :P 22:15 < Not-9c26> [wiki] Edit by Fenhl to Data types -> http://tinyurl.com/jk7xmx9 22:15 < barneygale_> lol rom1504 22:16 < Fenhl> one is for named sound effects as used by /playsound, the other is probably for everything else because the ids are smaller? 22:17 < barneygale_> for my purposes it's a bit annoying that The Packet Formerly Known As Sound Effect is now called "Named Sound Effect", and there's a new completely separate packet called "Sound Effect" 22:18 < Fenhl> okay so we have the data types, now merging the actual packets 22:21 < rom1504> looks like entity effect changed ._. 22:21 < rom1504> last field is a byte now, not a bool 22:21 < Fenhl> huh 22:21 < rom1504> http://pokechu22.github.io/Burger/1.9.html#packets:0x4c 22:25 < rom1504> I only tested nmp proxy on a server I was playing online on localhost. Turns out this is not real world conditions :d 22:25 < rom1504> getting more error on a real server 22:25 < rom1504> I'll fix the packets I found have changed 22:29 < Not-9c26> [wiki] Edit by Fenhl to Protocol -> http://tinyurl.com/h5slqqz 22:30 < rom1504> pokechu22: you are translating some fields to position when they should be varint 22:32 < Not-9c26> [wiki] Edit by Fenhl to Pre-release protocol -> http://tinyurl.com/h7dx4pb 22:35 < Not-9c26> [wiki] Edit by Fenhl to Pre-release protocol -> http://tinyurl.com/hpzmarm 22:50 < barneygale_> quarry users: 1.9 support is done and on pypi 23:07 < Not-8b17> [flying-squid] rom1504 deleted branch greenkeeper-babel-plugin-transform-runtime-6.6.0 23:17 < tktech> rom1504, He's not actually here, he seems to just be using the freenode webclient occasionally 23:23 < Not-8b17> [flying-squid] rom1504 deleted branch greenkeeper-babel-preset-es2015-6.6.0 23:39 < Not-8b17> [flying-squid] rom1504 deleted branch greenkeeper-babel-runtime-6.6.0 23:42 < Fenhl> pokechu22: you are translating some fields to position when they should be varint 23:43 < pokechu22> Checking that... the code that I use to determine if something's a position isn't too good. 23:43 < pokechu22> I wasn't able to find a good identifier for the position class so I chose "anything on packetbuffer that's not already covered" 23:45 < tktech> pokechu22, You should get an IRC bouncer and a proper client, not the web client. 23:46 < pokechu22> I've got no idea how, though I've heard of bouncers... I'm not too familiar with IRC. Any recomendations? 23:48 < redstonehelper> leave your computer on and connected 24/7, there's your bouncer 23:48 < tktech> A bouncer like znc will stay connected to the server while you're gone and send you the backlog when you return 23:50 < pokechu22> It says that this channel is publicly logged - is it possible to just read those logs? 23:53 < pokechu22> And I can confirm that something's wrong with varints - going to fix it. 23:56 < barneygale_> it's not publicly logged afaik 23:56 < barneygale_> privately logged perhaps 23:56 < pokechu22> In the header (at least on the webchat), it says "Channel is publicly logged as of Feb.25/13". 23:59 < rom15044> Well it's there now https://logs.rom1504.fr/%23mcdevs.log ;) --- Day changed mar. mars 01 2016 00:01 < rom1504> I wish there was a good irc log web viewer 00:01 < rom1504> downloading a 11MB file is not great 00:06 < pokechu22> ... oh, I see what happened - they made the writeVarInt method return the packetbuffer instead of void (so now it matches the regular netty methods) 00:07 < pokechu22> Um... I guess I'll make it check if the name of the method's really short instead; that'll probably work. 00:29 < rom1504> pokechu22: can you understand the login packet ? 00:30 < rom1504> Join Game 00:30 < rom1504> it kinds of look like it changed but I can't understand the decompiled code 00:30 < rom1504> and your burger fork give weird thing on this packet 00:30 < barneygale_> rom1504, my 1.8 code works fine with it 00:30 < rom1504> http://pokechu22.github.io/Burger/1.9.html#packets:0x23 00:31 < pokechu22> Yeah, burger's a bit borked due to a change I didn't notice. 00:31 < pokechu22> A lot of things say that they're positions when they're actually other types. 00:32 < rom1504> barneygale_: did you try your proxy on a server with many players ? 00:32 < rom1504> for some reason I don't understand this changes stuff 00:32 < rom1504> I only tried my proxy on localhost, with only me and it worked perfectly 00:32 < barneygale_> no, just simple client/server stuff 00:32 < pokechu22> I'll push a fixed verison in a few minutes, once I figure out everything I broke. 00:32 < rom1504> now trying on a real server and it's all borked 00:33 < rom1504> hmm 00:33 < rom1504> maybe login is not the problem 00:34 < rom1504> "this.g = ahy.a(☃.c(16));" idk what is that 00:35 < rom1504> it's supposed to read "Level Type" 00:39 < pokechu22> OK, I just pushed a fixed version to github pages, although the structure of that packet. Just gotta' wait... 00:39 < pokechu22> * although the structure of that packet seems unchanged. Just gotta' wait until github pages builds it. 00:40 < pokechu22> FYI, you're looking at the code to read the packet, not write it. 00:41 < rom1504> yes I know 00:41 < pokechu22> What you're seeing is WorldType.parseWorldType(data.readStringFromBuffer(16)); 00:42 < rom1504> what is that 16 00:42 < rom1504> hex ? 00:44 < pokechu22> It's the maximum length of the string - and that's why I prefer using the write version. 00:45 < rom1504> ok 00:45 < pokechu22> I don't entirely know why they have a max length but maybe it's to deal with corrupted packets. If the packet's well-formed you shouldn't worry about it. 00:48 < pokechu22> The version on gh pages should be up to date now - http://pokechu22.github.io/Burger/1.9.html#packets 01:05 < redstonehelper> pre4 -> 1.9 is unchanged https://twitter.com/SeargeDP/status/704383283061202945 01:18 < rom1504> err, I had pasted the 1.8 protocol.json on the 1.9 one 01:18 < rom1504> no wonder it was all broken 01:20 < rom1504> so 01:21 < rom1504> http://wiki.vg/Protocol#Entity_Effect has indeed a byte instead of the boolean 01:21 < rom1504> not sure where I'm supposed to change it now than Fenhl has started merging though 01:22 < Fenhl> rom1504: does it have possible values other than 0 and 1? 01:25 < Akaibu> when was twich broadcasting removed? and why? was it because there was little use of it, or some disagreement between twich and mojang? 01:25 < Akaibu> twitch* 01:30 < Not-8b17> [minecraft-data] rom1504 pushed 1 commit to master [+0/-0/±1] https://git.io/v2Klv 01:30 < Not-8b17> [minecraft-data] rom1504 80ffc1f - 1.9 protocol : fix packet_animation (still a varint and a u8, not sure why it was changed), hideParticles is a byte in packet_entity_effect 01:35 < pokechu22> Akaibu, it was sometime in 1.9, and if I recall correctly it's due to it being too laggy? Might be wrong about that. 01:36 < Akaibu> ah, might make sense 01:38 < Akaibu> wait DiCaprio got an Oscar? 01:38 < Akaibu> holy hell, about damn time 01:39 < Not-8b17> [minecraft-data] rom1504 pushed 1 commit to master [+0/-0/±1] https://git.io/v2K4G 01:39 < Not-8b17> [minecraft-data] rom1504 4fc91bc - i8 not byte 01:39 < Not-8b17> [flying-squid] rom1504 deleted branch greenkeeper-babel-runtime-6.6.1 01:40 < Gjum> rom1504: regarding log viewing, the logs could be split by day, so its not 1 large file 01:41 < rom1504> Fenhl: client<-server: play.entity_effect :{"entityId":2310,"effectId":1,"amplifier":1,"duration":120,"hideParticles":2} 01:41 < rom1504> yes 01:41 < Not-8b17> [mineflayer] rom1504 deleted branch greenkeeper-minecraft-data-1.2.3 01:41 < rom1504> 0 clue what it means though 01:41 < Not-8b17> [flying-squid] rom1504 deleted branch greenkeeper-minecraft-data-1.2.3 01:42 < rom1504> (hideParticles is clearly the wrong name now though) 01:42 < rom1504> Gjum: ah yeah, I guess I can do that 01:43 < Not-8b17> [mineflayer] rom1504 deleted branch greenkeeper-minecraft-protocol-0.19.2 01:43 < Not-8b17> [flying-squid] rom1504 deleted branch greenkeeper-minecraft-protocol-0.19.2 01:44 < Fenhl> rom1504: uh okay, add it to Pre-release protocol please, I haven't merged that part yet 01:44 < Gjum> znc does that by default for me ^^ 01:45 < Not-8b17> [mineflayer] rom1504 deleted branch greenkeeper-minecraft-data-1.2.4 01:45 < Not-8b17> [flying-squid] rom1504 deleted branch greenkeeper-minecraft-data-1.2.4 01:49 < Not-9c26> [wiki] Edit by Rom1504 to Pre-release protocol -> http://tinyurl.com/zonrcjz 01:49 < rom1504> Fenhl: done 01:49 < Not-8b17> [mineflayer] rom1504 deleted branch greenkeeper-minecraft-protocol-0.19.3 01:50 < Not-9c26> [wiki] Edit by Rom1504 to Pre-release protocol -> http://tinyurl.com/z4t2v5k 01:50 < rom1504> Gjum: well I use irssi :p, but anyway I'm running a tail (and copy) in a cron to keep only the part after the "publicly logged" was added 01:50 < rom1504> so I might as well do a split or something 01:59 < rom1504> Gjum: here you go https://logs.rom1504.fr/parts/167.txt 02:00 < kashike> rom1504: those are some interesting branch names 02:01 < rom1504> err yeah that's annoying 02:01 < rom1504> I wish notifico wouldn't report branch deletion 02:05 <+ammar2> https://github.com/notifico/notifico/commit/27dba4461478450a09ca3b84db2d02df6a2d6e75 02:05 <+ammar2> whoops