22:56 < Xor_Boole> as long as the bound name isn't referenced in the lambda body the compiled code shouldn't contain it 22:56 < jast> but most of my day work is javascript. ugh. 22:56 < Xor_Boole> jast you're expecting sane closures in javascript? 22:57 < jast> no, I never said I was :) I'd _like_ them, though 22:57 < Xor_Boole> I'd expect you to have proper expectations for JS 22:57 < Xor_Boole> playing with scala quasiquotes is fun 22:57 < jast> the real problem is when your closure uses references to god objects 22:57 < jast> which is kind of common in certain languages and programming styles 22:58 < Xor_Boole> the real problem is the god objects themselves 22:58 < jast> var myclosure = { application.session.params.corrode() } 22:59 < Xor_Boole> sorry, gotta run 22:59 < Xor_Boole> dinner awaits 22:59 < jast> enjoy --- Day changed jeu. févr. 05 2015 00:39 < Xor_Boole> does the vanilla client even set EXIT_ON_CLOSE? 00:39 < Xor_Boole> closing the main window keeps the process alive, annoyingly 00:40 < Xor_Boole> s/client/laucher 00:42 <+SpaceManiac> I'm using the new Windows .exe and the process closes after I close the window (didn't open the game, though) 00:45 < Xor_Boole> > implying I would use wandows 02:00 < gurun_> didn't know what windows had that new .exe thing ..hmm, and i read MSDN every day :-( 02:19 < Xor_Boole> can someone explain to me why people are taking such issue to uuidless scoreboards? 02:20 <+SpaceManiac> you'd have to explain what you mean by 'uuidless scoreboards' 02:21 < gurun_> Xor_Boole: it's not difficult. Its because the general issue people have with it is that they are uuidless. 02:22 < gurun_> they don't have issues with it being a scoreboard 02:22 < gurun_> i have issues with my wife. But it's not because of uuidness, rather cluelessness 02:26 < Xor_Boole> SpaceManiac the scoreboard stores data by name and not uuid 02:26 < Xor_Boole> which people seem to be bitching about 02:26 <+SpaceManiac> probably annoyed about name changes doing things 02:27 <+SpaceManiac> I thought it did store by UUID though, guess I was wrong 02:27 < Xor_Boole> ofc. it just pisses me off that people are complaining about their servers' scoreboard crap not working 02:27 < Xor_Boole> seriously, if you want that type of stuff you should have been using CB/Spigot 02:28 < Xor_Boole> or Glowstone ^^ 02:28 < Xor_Boole> except Glowstone don't do shit! 02:28 * Xor_Boole runs 02:28 <+SpaceManiac> :V 02:28 < Xor_Boole> something something CB is better something something 02:28 * Xor_Boole huggles SpaceManiac 02:28 < Xor_Boole> how is GS comming along, anyways? 02:29 < Xor_Boole> I haven't looked at your repo lately 02:30 <+SpaceManiac> Alright. Things have been a little slow since I've been busy with school, though, and there's a lot of architecting that needs to be done (new block system, network rewrite, &c) 02:34 < Xor_Boole> s/new/sane 08:04 < ackpacket> Idk if Dinnerbone is around, but for some minecraft servers the mcstatus plugin he wrote times out, yet his website has no problem querying the player list 08:04 < ackpacket> Can't figure out why for the life of me. The module is sending out the right bytes, that's confirmed 09:11 < Fenhl> Xor_Boole: Bukkit doesn't handle name changes well either btw. The shutdown happened before the bulk of things were changed to use UUIDs 09:41 < ackpacket> so... many... breaking plugins 09:50 <+md_5> Fenhl lolwat. Bukkit handles it fine, and has for a year. 09:57 < ackpacket> define handle. And define the problem 10:10 <+md_5> ackpacket bukkit has provided the necessary APIs to plugin developers for a year now, it itself doesnt need to care about name changing, therefore there can be no "doesnt handle well" with regards to bukkit itself 10:11 < ackpacket> Developers should just treat names as volatile 10:19 < ackpacket> join #linux 10:19 < ackpacket> fail 12:01 <+Amaranth> ackpacket: I even added storing the last known name for a player to make it easier to go from UUID to name for display purposes 12:01 <+Amaranth> I think that was about a year ago now --- Day changed ven. févr. 06 2015 04:09 < kvgeorge1> Can someone answer a protocol question about Crafting Inventories? 04:10 < kvgeorge1> Which PacketIDs are sent to a user (client) when they try to craft an item using a workbench? 04:11 <+SpaceManiac> IIRC, only Set Slot (play/clientbound/0x2f) 04:12 < kvgeorge1> So here is why I am asking. I use Rainbow Server and it has its own API. While I can add a new recipe like I can in Bukkit, they don't show-up in the client, but Bukkit does 04:13 < kvgeorge1> I wanted to know what is being sent to the client to see if I can do something similar to get the recipe to show 04:13 <+SpaceManiac> a sufficiently clever server can tell the client what to show in the result slot, which is what Bukkit did 04:13 < kvgeorge1> ah.....ok 04:13 < kvgeorge1> so basically, it sets the slot of the crafting bench with the item 04:13 <+SpaceManiac> mmhm 04:13 < kvgeorge1> you're awesome! 04:14 < kvgeorge1> thx 04:39 < ackpacket> SpaceManiac: 04:39 < ackpacket> whoops 04:40 < ackpacket> Has anyone gotten the UDP querying to work? On Dinnerbone's site, it works fine for every server that supports it. But then when you download the python module written by him, it times out for some of those servers. 04:41 < ackpacket> No response ever received on Wireshark. the bytes sent out by the module match the protocol 07:17 < kvgeorge1> how does one go about reading a String with the MC protocol? 07:18 < kvgeorge1> For example, capturing 0x2D, the Window Type is defined as a 'String' 07:19 < kvgeorge1> but I can't seem to figure out how to read the String since it should start with a VarInt that could be 1-5 bytes long 07:19 < kvgeorge1> Is there a terminating character that marks the end of the string? 07:19 <+SpaceManiac> no, you must decode the varint 07:21 < kvgeorge1> how do you do that? Is there some algorithm to do this? 07:22 <+SpaceManiac> here is a description of varint structure: https://developers.google.com/protocol-buffers/docs/encoding#varints 07:22 <+SpaceManiac> here is a Java implementation: https://github.com/flow/network/blob/a17d9545ae1ed519cbd085394f341e7eda8371ee/src/main/java/com/flowpowered/networking/util/ByteBufUtils.java#L74 07:22 < kvgeorge1> thanks. I will look it up now. 09:00 < gurun> Minecraft in China. Anyone knows how big that market is. MiNET got its early adopters from China doing plugins before we hardly have plugin APIs. And I wonder why.. 09:02 < gurun> When I asked, I got the impression that it's because it's .NET and neither java or PHP is very popular in China. But that felt like a simplified explanation. 09:04 <+AndrewPH> probably huge because it offers freedoms not commonly granted (shots fired! but only kindof) 09:06 < gurun> You mean freedom as in not really monitored? 09:06 < gurun> Or freedom as in "I am free to be creative" 09:10 <+AndrewPH> all of the above probably 09:11 <+AndrewPH> (I'm being slightly facetious but might be right?) 13:45 < SopaXorzTaker> Wolfe actually got swatted 13:45 < SopaXorzTaker> O.M.G 14:00 < dx> welcome to 5 months ago? 14:00 < SopaXorzTaker> yeah 14:00 < SopaXorzTaker> I don't read the news 14:01 < dx> ok 14:03 < barneygale> wait, really? 14:03 < barneygale> that's disgusting 14:05 < Klong> Where did you hear that? 14:18 < SopaXorzTaker> here: http://abc13.com/news/software-writer-in-la-marque-latest-swatting-victim/305170/ 14:50 < gurun> man, that sucks 14:53 < Paprikachu> what compression algorithm(s) give the best results (both in terms of speed and space) for map data? does anyone know? 15:07 < barneygale> SopaXorzTaker: christ. 16:13 < jast> Paprikachu: speed vs. space is a trade-off. you're going to have to decide which one is more important to you, or make it configurable. :) and of course it depends on the format in which you store the data. 16:14 < Paprikachu> there must be algorithms that are generally better for minecraft like data. 16:14 < jast> LZ-based algorithms tend to be able to be faster than the competition 16:14 < jast> but of course that can be at the expense of compression ratio 16:15 < Paprikachu> mh 16:15 < jast> well there's going to be some amount of RLE-friendly data in minecraft, e.g. long runs of the same material 16:15 < jast> huffman/shannon-fano/entropy coding is going to help make use of the non-evenly distributed materials, for instance 16:16 < jast> LZ algorithms probably aren't going to help _that_ much for the raw terrain data, though they may have advantages for some of the other data 16:17 < jast> the best way to figure out what to use is to take lots of different datasets and run them through actual compressors :) 18:42 <+SpaceManiac> in my experience, the nature of the anvil format means you can use deflate on fastest mode with no size problems 18:42 <+SpaceManiac> it sounds like you're gunning for a custom format, though 18:50 < Paprikachu> i am indeed 19:00 < Grum> Space is barely ever a real issue, speed however is 19:01 < Grum> especially since we still have random ticking which means everything has to be unpacked @ server and thus causes everything to have to be packed when send to the client 19:02 < gurun> is the PC format for persistance same as wire format? 20:08 < Grum> gurun: almost 20:36 < Xor_Boole> Grum wat 20:36 < Xor_Boole> my bouncer seems to have derped 20:38 < SinZ> <gurun> is the PC format for persistance same as wire format? 20:39 < Xor_Boole> well that tells me nothing 20:40 * Xor_Boole goes back to his latex 21:35 < Not-f107> [Glowstone] SpaceManiac pushed 3 commits [+0/-0/±26] http://git.io/biPN 21:35 < Not-f107> [Glowstone] SpaceManiac a0c9234 - Cleaned up some warnings and unused code. 21:35 < Not-f107> [Glowstone] SpaceManiac 66fb303 - Made use of Lombok in a few more places. 21:36 < Not-f107> [Glowstone] SpaceManiac 50a46d0 - Updated build instructions in README. --- Day changed sam. févr. 07 2015 02:33 < Gjum> is there a way to get the lagometer back? 02:39 < SinZ> Gjum: alt+f3 02:45 < Gjum> tried, didn't work... well optifine adds it, but in vanilla I can't get it to work - hidden config file option maybe? 02:48 < dx> Gjum: i keep reading your name wrong 02:48 < dx> is that intentional? 02:56 < Gjum> lol no, we had that discussion already ^^ 02:56 < Gjum> i created that nick back in the day when there was no minecraft 02:57 < Gjum> any ideas how to improve the visual difference? 02:57 < _x_Gjum_x_> like that? :D 03:03 < Xor_Boole> Gjum -> Gjum_not_Grum 03:04 < Gjum> well things like that would confuse other chats 04:06 < Xor_Boole> Gjum alterantive option: challenge Grum to a fight to the death. 04:07 < Gjum> nah 04:08 < Xor_Boole> lowercase g? 04:08 < dx> gJuM 04:09 < gurun> gjum is like an mock asian way of saying the swedish word grym .. translating to crule. 04:10 < Gjum> it also means sleep in some east european language 04:10 < Gjum> which is what i'll get now 04:10 < gurun> sounds like a good plan. 04:10 < gurun> i'll copy 04:11 < dx> and then there's gurum 04:11 < gurun> damn, only one dx 04:12 < gurun> i think i will buy a random two letter nick 04:12 < gurun> night guys,. 06:20 < Grum> tried, didn't work... well optifine adds it, but in vanilla I can't get it to work - hidden config file option maybe? <-- it is in the pre-releases 07:54 < Xor_Boole> useless API idea: search for all accounts whose UUID contains a certain string. 07:56 < Xor_Boole> for no better reason than to find players with b00b5 in their UUID 10:04 < prplz> feedfacedeadbeef 10:07 < prplz> Xor_Boole: found a few in my database lol: [u'03cdc03d098a4b00b5d6df83da325b2a', u'0b00b5081ca84ad3977cf00fabde98b5', u'15a2cdcb79744b00b55e3d3853d13f5f', u'35b00b598c564691836458a8270a2c60', u'4a34ce9f8c084b9a8b00b54f621c174a', u'7c9ee5a72b794b00b5d40e44db9407f8', u'8673815d1d6349dda565b00b5ce29f7b', u'ab00b5d3c6be4be581e3891ae93c3deb', u'ba015d8298874e06afab00b589e97999', u'beb00b5d561040b4ba1cd21f73aa2864'] 15:20 < redstonehelper> Gjum|AFK: shift+f3 I think 17:19 < SopaXorzTaker> ARRRRRRRGH 17:19 < SopaXorzTaker> Lost all the items in my chests 17:19 < SopaXorzTaker> played a 1.8 world in 1.7 :< 17:31 < Gjum|AFK> nickelpro, gamingrobot: how stable is spock's packet parsing? 17:37 < redstonehelper> Gjum: did you get my ping earlier? 17:38 < Gjum> yup, can't check now, gonna do later 17:53 < nickelpro> Gjum: Um, super stable? It works as far as I know 17:53 < nickelpro> The API hasn't changed in a very, very long time and it's not likely it will, if that's what you're asking 17:57 < Gjum> ok, i was just taking a look at datautils.py and wondering about the comments for unpac_slot and pack_position 17:58 < nickelpro> Gjum: I need to remove those, pack_position apparently has been tested and works, though I don't really understand why. unpack_slot has that comment because while it theoretically implements the spec, I have a bad history with fucking up NBT 17:59 < nickelpro> Try it and see, if you get a crash I'll fix it and then whala, improvements for everyone 19:30 < morfin> interesting 19:32 < morfin> i am trying to understand how different types are being serialized 19:33 < morfin> but why Minecraft limits varint by 5 bytes? 20:18 < nickelpro> morfin: Locally minecraft stores varints in 4-byte signed ints 20:20 < nickelpro> Neither the server nor the client have the ability to send greater than a 5-byte varint, and trying to decode one would result in an overflow. So its forbidden 20:22 < morfin> they used protobufs stuff but limits length 20:22 < morfin> *limit 20:22 < nickelpro> They don't actually use a protobuf lib or anything 20:23 < nickelpro> pseudo-varints are the only protobuf-like thing in the protocol 20:37 < morfin> i know they do not use protobufs 21:04 < morfin> btw that's very strange 21:04 < nickelpro> ? 21:29 < morfin> why did not they use such thing 21:30 < morfin> it already have gzipping, varints, serialization stuff --- Day changed dim. févr. 08 2015 03:43 < Xor_Boole> I should write a client wrapper that combines multiple minecraft instances into tabs 03:51 < nickelpro> Anyone know how entities are removed from a clients de-spawned? 03:51 < nickelpro> ie a player entity that moves too far away 03:51 <+SpaceManiac> Destroy Entities (play/clientbound/0x13) 03:52 < nickelpro> ty 07:14 < Not-f107> [Glowstone] SpaceManiac pushed 2 commits [+0/-0/±4] http://git.io/bH0P 07:14 < Not-f107> [Glowstone] SpaceManiac 575d55c - Tidied world I/O somewhat. 07:15 < Not-f107> [Glowstone] SpaceManiac 16cb7d5 - Fixed incorrect reference in ToolType. 10:20 < morfin> how varLong can be greater than 10 bytes? 10:21 < morfin> oh i forgot about MSB 10:21 < morfin> and 7 bits per byte 10:40 < morfin> so max value of varint having 5 bytes is hmm 268435456 10:40 < morfin> 2^28 10:51 < Grum> no, 35bits of data 10:51 < Grum> 7 per byte 10:51 < Fenhl> morfin: VarInt can represent all 32 bit integers, VarLong can represent all 64 bit ints 10:51 < Grum> obviously anything more than 32 gets lost :) 10:52 < Fenhl> ceil(32 / 7) == 5 10:53 < Grum> ceil(64 / 7) == 10 :( 10:54 < morfin> look you read 5 bytes 7 bits per byte 10:54 < Grum> no? 10:54 < Grum> erm yes 10:54 < Grum> so that means 5x7 = 35 10:54 < Grum> 28 is 4x7 10:54 < Grum> l2basicmath =D 10:54 < morfin> oops 10:55 < morfin> non-standard numbers 10:55 < Grum> huh? 10:55 < Grum> 5 and 7 are quite standard 10:55 < Fenhl> ^^ 10:56 < morfin> 35 bytes numbers are bad 10:56 < Grum> and they do not exist 10:56 < Grum> the space for the 3 excess bits is just wasted, doesn't matter what you fill in there 10:56 < Fenhl> btw, is the upper limit on string length really the largest number representable as a VarInt? 10:56 < morfin> btw what about sign? 10:57 < morfin> did you forget about that 10:57 < Grum> morfin: no? 10:57 < Fenhl> you encode it as two's complement, then encode that as a VarInt 10:58 < Grum> morfin: it just takes the raw data and puts it back together, if bit 32 happens to be 1 the value is negative 10:58 < Grum> this does mean that all negative numbers take the full size of the VarInt 10:59 < Grum> which is a tad annoying and can be solved by moving the sign bit to the front 10:59 < morfin> he-he 10:59 < Grum> or doing some other bigwise magic :) 11:00 < morfin> wait a second i want to check one thing 11:00 < Fenhl> that would also get rid of the distinction between the two VarInt types 11:00 < Fenhl> and allow you to switch over to bignums later without breaking things 11:01 < Fenhl> but I guess breaking things isn't that much of a concern 11:01 < Fenhl> given how often you break things ;) 11:01 < Grum> at a moment we'll just deprecate varint and use something that works nice for negative values too 11:01 < Grum> nothing breaks? 11:02 < Fenhl> I was talking about backwards compat 11:02 < Grum> which there is not? 11:02 < Fenhl> ? 11:02 < Grum> that is why we have an incrementing protocol version 11:02 < Fenhl> yeah I know 11:02 < Grum> every version is a whole different version by itself 11:02 < Grum> and you can just implement any of them 11:02 < Fenhl> hence “isn't that much of a concern” 11:02 < morfin> even Google uses only unsigned :O 11:03 < Grum> no google has both 11:03 < morfin> can't find signed 11:03 < Grum> (n << 1) ^ (n >> 31) 11:03 < Grum> https://developers.google.com/protocol-buffers/docs/encoding#types 11:04 < morfin> i am looking at protobufs source 11:05 < Grum> they have a sint32 and sint64 type-support 11:05 < Grum> just read the docs >.> 11:05 < morfin> let me checkout && grep 11:08 < morfin> and also see those one 11:08 < morfin> static const int kMaxVarintBytes = 10;static const int kMaxVarint32Bytes = 5; 11:08 < morfin> now i see where from Minecraft devs got that limits 11:08 < Grum> no? 11:08 < Grum> the limits just make sense 11:08 < Grum> geez O.o 11:08 < Grum> you need 5 bytes of varint data to encode a 32bit integer 11:08 < Grum> and 10 to encode a 64bit integer 11:09 < morfin> but why they have void CodedOutputStream::WriteVarint32(uint32 value) { 11:09 < Grum> we just noticed protobuf had a nice 'make integers as short as they need to be' and we made our own 11:09 < morfin> uint32 -> unsigned 11:09 < Grum> and since there is only one way to do it it just happens to work the same 11:10 < Grum> so there are no references at all between protobuf and what we did 11:11 < Grum> so feel free to use logic to explain why rather than some weird causality between the two 11:12 < morfin> anyway 11:13 < morfin> seems like protobufs can't do signed 11:13 < morfin> but they described how that could be done 11:13 < Grum> no idea, no care =D 11:14 < morfin> hmm i heard Minecraft protocol started using varints in more places 11:14 < morfin> from 1.8 or something like that 11:14 < Grum> yes and? :) 11:15 < Grum> also signed or unsigned matters nothing for support, the 'problem' is that unless you specialcase handle unsigned negative ints you get less benefit from it 11:16 < morfin> just interested why so? 11:17 < morfin> *i meant using varints everywhere 11:17 < Grum> in more locations, not everywhere 11:17 < morfin> i guess it saves not so much traffic 11:17 < Grum> depends, would you mind sending longs for every int? 11:17 < Grum> I mean, it is only double the size 11:18 < morfin> it's being used even for food 11:18 < morfin> in Update Health 11:18 < Grum> no, it is being used in 'Update Health' 11:18 < Grum> nothing to do with food :) 11:18 < Grum> dog is an animal but not all animals are dogs >.> 11:18 < morfin> meant field Food 11:19 < Fenhl> http://wiki.vg/Protocol#Update_Health 11:19 < Grum> consider it future compatibility for if that fields needs a value larger than a byte 11:19 < morfin> i was thinking how do i precalculate packet length with all that varints and packets having 3 different fieldsets 11:20 < morfin> when fieldsets are not even same size :( 11:20 < Grum> you do not 11:20 < Grum> if you attempt to do that you will just fail 11:20 < Grum> but you would have failed far far earlier already than there 11:20 < Fenhl> why not just serialize the packet content and then check the length? 11:21 < Grum> there really is no way to do predictive size-calculations of a packet 11:22 < Grum> but it is not possible for a lot of reasons, anything that has a string, byte array, varint ... name it, you cannot 'guess' those 11:23 < Fenhl> iirc there's only 2 or 3 packets whose length is known without looking at the data 11:23 < morfin> varints and strings are not big deal 11:24 < Fenhl> Time Update is one of them 11:24 < morfin> but what about entity data, block data etc 11:24 < Grum> you cannot predict, that simple 11:24 < Grum> so, stop trying and you will have more success 11:24 < morfin> but how do i allocate enough memory 11:24 < morfin> without having to reallocate again and again 11:24 < Grum> just allocate 2^21bits of memory 11:24 < Grum> that is going to be enough 11:24 < morfin> hmm 11:25 < Grum> as that is the maximum packetsize both server and client will read 11:25 < Grum> and that is not going to change 11:26 < morfin> i can predict only for some types 11:26 < morfin> *packet types 11:26 < Grum> You cannot predict, period 11:26 < Grum> stop trying >.> 11:27 < Grum> the max size is 2^21bits, grow your buffers dynamically or use that size 11:27 < morfin> growing dynamically will mean reallocations -> moving around memory 11:27 < Grum> yes, and not growing dynamically means your code will not work 11:28 < Grum> so, suck it up :P 11:29 < Grum> it's completely legal for the client to send you 2^21bytes of data 11:29 < Grum> ditto for server 11:29 < Grum> so, depending on what you are making, you are going to need to keep that in mind 11:30 < morfin> i never saw client send so many data 11:30 < Grum> doens't matter 11:30 < Grum> protocol supports it 11:30 < Grum> modded clients do it 11:30 < morfin> :O 11:30 < Grum> You either implement the protocol or you do not ;) 11:32 < Grum> oh btw, those 2^21bytes can be compressed 11:32 < Grum> so enjoy allocating the buffer to decompress it ;D 11:33 < morfin> sounds like impossible 11:33 < morfin> Minecraft itself is badly designed 11:33 < Grum> Wait, are you saying that the language you are using is inferior to Java? 11:34 < Grum> Not sure how it is badly designed, you seem to have issue with the design with your language of choice :/ 11:34 < Grum> our code is quite trivial/elegant/simple; https://gist.github.com/grum/cb6ca427ad9901ee0f3d 11:35 < morfin> i was thinking why vanilla server is so unoptimal 11:35 < morfin> *unoptimized 11:36 < Grum> because it was made by Notch after the fact without ever considering multiplayer before that 11:37 < morfin> but it seems like only one design can exist 11:37 < Grum> one design of what? 11:37 < morfin> and nothing can be optimized 11:37 < morfin> of server/client 11:38 < Grum> so why do custom servers and clients exists with different designs? 11:38 < morfin> hmm 11:40 < Grum> surely you have to implement the protocol, and surely there is more than a single way of doing that and the whole design of the client/server wouldn't depend on that 11:42 <+AndrewPH> notch's code is top-level kek 11:43 < Grum> It made as many $ as it has made problems 11:44 <+AndrewPH> did it have one goto statement for every million it made? 11:44 < morfin> they rewritten to Netty as i know 11:45 < morfin> but it's still bad 11:45 < Grum> in which way? 11:45 < morfin> at least because Minecraft can't full duplex 11:45 < Grum> why not? 11:46 < morfin> it use something like autoread(false) then doing stuff to send stuff then return autoread(true) 11:46 < morfin> on both sides 11:46 < Grum> and? 11:47 < morfin> so it does not read anything when sending and does not write when reading 11:47 < Grum> when it does a protocol switch it does that yes 11:47 < Grum> and only then 11:47 < morfin> what do you mean? 11:48 < Grum> so between handshaking and logging in, only on that one connection, it does what you say 11:48 < Grum> also full duplex doesn't mean what you think it does 11:49 < Grum> it is the 'mode' your connection is in 11:49 < morfin> so you say later you can read/write in same time? 11:49 < Grum> and is operated by your networkcard rather than something on a higher layer 11:49 < morfin> i know 11:49 < Grum> morfin: yes obviously we can 11:49 < morfin> i do not understand how that protocol can be implemented any more 11:50 < Grum> I am not sure which part you are having problems with 11:53 < morfin> i checkedf out original code 11:53 < morfin> it uses disableAutoRead for every write operation 11:54 < morfin> so code can only read or only write at some moment 11:54 < Grum> you are mistaken 11:54 < morfin> why? 11:55 < Grum> it sets autoread to false when: 1): protocol changes (eg handshake->login) for a single packet; 2): something throws an exception and we send a disconnect packet (because we're not interested in reading then anymore) 3): on disconnect 11:57 < Grum> ah sorry, not 'for 1 packet', it does it for a few opcodes, 11:57 < morfin> hmm then that's much more complicated to implement 11:57 < Grum> it was to combat a race condition we had, nothing more nothing less 11:57 < Grum> the 'after disconnect' are just so we do not accidentally read and handle any more packets between the time we send the packet and terminate the connection 11:57 < morfin> hmm 11:58 < morfin> i don't understand 11:58 < Grum> If you didn't get this information yourself, I would from this point on question your sources; if you did get it yourself, well, maybe read the sourcecode again =) 11:59 < morfin> why not just work until disconnect received 11:59 < morfin> then ignore anything 12:00 < Grum> because that was a more involved change than this? 12:00 < Grum> and there is no downsides to doing where doing nor any extra tight coupling? 12:00 < Grum> s/where/what we're/ ... gosh :D 12:00 < morfin> i still don't understand how it works 12:01 < morfin> i will assume it works like i said 12:02 < morfin> i forgot i have queue with packets to handle 12:02 < Grum> you do not have to do any autoreading stopping/starting 12:03 < morfin> do i ignore packets came before disconnect? 12:03 < morfin> but still not handled 12:03 < Grum> yes and what is what autoreading (false) ends up doing for us 12:03 < morfin> but why? they came before disconnect 12:04 < Grum> or after, netty is fully async 12:04 < Grum> at the point of execution there is no way to know 12:04 < morfin> hmm 12:04 < Grum> but when we disconnect, any packet after will just throw exceptions 12:04 <+Amaranth> Plus if the user is going away who cares about any packets they might have lingering 12:04 < morfin> i guess user will lose some data 12:04 <+Amaranth> They're gone anyway 12:04 < Grum> so we stop reading -> no handling of packets -> no exceptions 12:05 < Grum> indeed :/ 12:05 <+Amaranth> Otherwise they could fill a buffer with chat packets for spam and their spam would continue after they were kicked 12:05 < morfin> lol 12:05 < Grum> which makes no sense 12:05 < Grum> that is the nature of handling async networking 12:05 < Grum> you get that sort of meh stuff 12:05 < morfin> but imagine situation when i drop something and disconnect 12:06 < Grum> then it will either have reached the server or not 12:06 < morfin> but disconnect have priority so i discard drop 12:06 < Grum> sorry no 12:06 < Grum> that will have reached the server 12:06 < Grum> because tcp guarantees order 12:06 < Grum> so your dropping is done before disconnecting 12:06 <+Amaranth> Dropping something while kicked might not drop it 12:06 < Grum> now, if you just sever the connection, yeah there is a chance it might not drop it 12:06 <+Amaranth> Dropping something then disconnecting client side will always drop 12:07 < Grum> but 'not doing something' is always safer than doing something 12:07 < Grum> in those cases 12:07 < morfin> async stuff is very complicated 12:08 < Grum> but fast and scalable 12:08 < morfin> because i have to read/write, handle packets with priority instantly(Disconnect as example) and handle my invound queue 12:08 < morfin> *inbound 12:09 < Grum> no there are no packets with priority 12:09 < Grum> that doesn't exist nor will it ever 12:09 < morfin> wait what? 12:09 <+Amaranth> It still exists it just isn't used 12:09 < morfin> hmm 12:09 <+Amaranth> Wait maybe 1.7 removed it entirely 12:09 <+Amaranth> But it wasn't used before that since 1.2 or so anyway 12:09 < Grum> ah the 'on thread' and 'offthread' handling? 12:10 <+Amaranth> No, the low priority queue 12:10 <+Amaranth> For chunks 12:10 < Grum> oh that bullshit 12:10 < Grum> yes, fuck that 12:10 < Grum> horrible notch hacky bullshit 12:10 < morfin> i meant another thing 12:10 < morfin> why not handle such stuff as Disconnect etc instantly 12:10 < morfin> not push into queue 12:10 < Grum> why would we? 12:10 < Grum> it gives no benefit, it pushes gameplay logic down into the communication layer ... it is just worse on every front 12:11 < morfin> if you push into queue then you will have to check whole queue each time 12:11 < morfin> if there is disconnect packet for user 12:11 < Grum> we do not have a queue 12:11 < Grum> or rather, we have no visible queue 12:11 < Grum> we just get elements fed from the end of a pipeline and handle each one in order as they come 12:12 <+Amaranth> They don't drop all packets when the client sends a disconnect 12:12 <+Amaranth> Only when the server decides to disconnect 12:12 < Fenhl> that doesn't sound very async 12:12 <+Amaranth> So you don't need to scan the queue looking for a client disconnect 12:12 < Fenhl> or maybe I'm misunderstanding what you mean by async? 12:13 <+Amaranth> Although they do drop all packets _after_ the client disconnect one so there still is dropping 12:13 <+Amaranth> But only non-vanilla clients could send any packets after the disconnect anyway 12:13 < morfin> but what if you have 4 packets from same player and 2 handling threads and last packet is Disconnect 12:13 < morfin> *4 handling threads 12:14 < morfin> hello race conditions 12:14 < morfin> ok as i said just drop anything after disconnecting 12:14 < morfin> non-vanilla clients can do anything 12:15 < morfin> even send packets with broken length/incorrect contents etc 12:17 < Grum> yes and they get disconnected quite fast when the do that 12:17 < Grum> with nice and obscure errors 12:18 < morfin> ok my attempt to handle some packets instantly was not nessesary then 12:18 < morfin> btw queue can be used with async code as well 13:15 < Grum> morfin: yes, there is a queue, we just do not see it 13:16 < gurun> What's the purpose of motion ? 14:28 < morfin> hm? 14:28 < morfin> i know there is handling queue and separate queues for sending 17:11 < c1yd3i> i'm trying to reobfuscate on MCP but I keep getting this error: https://gist.github.com/c1yd3i/58c86fb930a88abceaa2 17:11 < c1yd3i> how to fix? 17:39 < Block> Hello 17:39 < item> Block: hello 17:40 * item use on Block 17:40 < Block> :D 17:41 < Block> gurun_: Can you help me with my mc-client? 17:42 < Block> I am reading all the packets, and that also works 17:42 < Block> But at a point it stops, because I get an error that the VarInt is too long 17:43 < gurun_> sorry, i only to the lightweight version .. PE. 17:45 < Grum> Block: so you are reading the data wrong? 17:45 < Block> Grum: The first VarInt is the length and the second is the ID, right? 17:45 < Grum> depends on which protocol you are reading 17:46 < Block> That is the standard protocol format, isn't it? 17:46 < Grum> no 17:46 < Grum> depends on the version 17:47 < Block> 47 17:47 < Grum> no idea which that one is -- but in 1.8 compression was added 17:47 < Grum> (1.8.*) 17:47 < Block> So it's always with compression? 17:48 < Grum> no 17:48 < Grum> when packets go over a certain size agreed upon they get compressed 17:48 < Block> Oh 17:49 < Grum> http://wiki.vg/Protocol#Packet_format 18:10 < nickelpro> Does no one read the docs? 18:10 * SopaXorzTaker set the threshold to -1 on his server 18:10 < nickelpro> So much work went into them... 18:11 < nickelpro> I just want to make sure something isn't completely nutty on my end, because I'm getting weird behavior from the Player List 18:12 < nickelpro> Often I will get PLAYER_UPDATE before the PLAYER_ADD has given me the player for the Player List 18:12 < nickelpro> Sometimes I get two PLAYER_ADDs for the same player, and later two PLAYER_REMOVEs for that same player 18:13 < nickelpro> And occasionally I get REMOVES for players I have never seen 18:13 < nickelpro> Is that all, I dunno, how that is supposed to work? Seems wonky 18:20 < Grum> SopaXorzTaker: poor people connecting to it 18:20 < SopaXorzTaker> yeah 18:20 < SopaXorzTaker> but it's being developed 18:22 < Grum> :) 18:44 < Bibl> https://www.youtube.com/watch?v=WRWrmT0ovPE omg lol 18:56 < morfin> oh shi* 18:57 < morfin> incorrect length for compressed data => big problems 18:58 < morfin> i still think Notch was reinventing wheel 18:58 < morfin> when rewritten Protobufs stuff 19:17 < Bibl> he was smoking $$$$ 19:18 < morfin> how do you think is that possible to split one world to separate "shards"? 19:19 < morfin> primary issues i see right now is transferring objects between "shards" and redstone 19:25 < Gjum> morfin: damn difficult, as all interacting objects must be on the same shard or you'd get inconsistence 19:25 < Gjum> but when you have like two loaded areas that are far enough apart, you could put each on one shard 19:25 < Gjum> so I think it's not as simple as to redirect packets 19:25 < morfin> lol 19:26 < morfin> will need to implement server-server protocol i think 19:26 < morfin> i think that's nearly impossible for stuff like explosions 19:27 < Gjum> remember, when shard-A-area and shard-B-area get merged, you have to immediately update one to the other's state(-differences) 19:28 < Gjum> like players forming a queue between the two 19:29 < sdasad> when i reobfuscate the compiled files in MCP then put those back into the vanilla MC jar 19:29 < sdasad> I get this error when the client starts 19:29 < sdasad> Exception in thread "main" java.lang.NoClassDefFoundError: net/minecraft/client/main/Main Caused by: java.lang.ClassNotFoundException: net.minecraft.client.main.Main at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClas 19:29 < sdasad> why is this happening 19:30 < nickelpro> Sharding behavior is barely worth it anyway, BC solves most of the practical problems while dancing around the massive technical problems of trying to shard MC 19:30 < morfin> i think sharding by worlds is much easier) 19:31 < sdasad> if i remove the main class 19:31 < morfin> with BC as exampl 19:31 < sdasad> the Minecraft.class file 19:31 < nickelpro> That's what BC does, and it works well enough that the major server networks haven't need to push for anything else 19:31 < sdasad> the client boots fine 19:32 < nickelpro> sdasad: What is your end goal here, what are you trying to build? 19:32 < sdasad> i wrote a mod to the vanilla 1.8 jar with MCP 19:32 < sdasad> Edited the main Minecraft class file to initialize an object 19:32 < sdasad> when I recompiled/reobfuscated 19:32 < sdasad> That happened 19:33 <+Amaranth> I thought there was one big server that used a heavily modified bungeecord to do single world sharding 19:34 <+Amaranth> It's the kind of thing that once you get figured out would be relatively easy to update for new versions 19:35 < sdasad> it's like whenever I edit the Minecraft class the game just won't run, and I don't know why 19:35 < Gjum> Amaranth: would be really interesting to take a look at how they did it 19:36 < Gjum> sdasad: why would you modify Main? 19:36 < sdasad> I'm not modifying the class Main, I'm modifying the class Minecraft 19:37 < sdasad> net.minecraft.client.Minecraft 19:37 < Bibl> recompile straight from eclipse 19:37 < Bibl> and use that jar 19:37 < sdasad> it gave a compilation error 19:37 < Bibl> mcp is horribly borked (and stupid) 19:37 < Bibl> whats the error 19:38 < sdasad> nvm 19:38 < Bibl> ? 19:38 < Bibl> did it work 19:38 < sdasad> i'll see 19:38 < morfin> google uses magic 19:38 < morfin> GOOGLE_PREDICT_TRUE 19:39 < sdasad> yes 19:39 < sdasad> wait 19:39 < sdasad> no 19:39 < sdasad> it crashed 19:39 < sdasad> https://gist.github.com/c1yd3i/5edb69e998d4ffd02d96 19:39 < Gjum> morfin: what? 19:39 < morfin> i am looking on protobufs code 19:40 < Bibl> sdasad: add the mc 1.8.1 jar to your build path 19:40 < morfin> *at protobufs code 19:40 < Bibl> it's missing the assets files 19:40 < morfin> and tryin to understand how they serialize/deserialize varlong 19:40 < sdasad> it's already in my buildpath 19:40 < sdasad> and i'm using 1.8, not 1.8.1 19:40 < sdasad> MCP doesn't work with 1.8.1 19:40 < nickelpro> morfin: Exact same as a minecraft varint, just more bytes 19:40 < Bibl> that error is because the assets arent found 19:40 < sdasad> hmm 19:41 < morfin> they call it "slow" method that's interesting 19:41 < sdasad> MCP seems to be a load of shit, any other reccomendations? 19:41 < Bibl> learn java objw asm and analyse and edit classes yourself? :p 19:42 < sdasad> lol 19:42 < morfin> i guess if (GOOGLE_PREDICT_TRUE(buffer_ < buffer_end_) && *buffer_ < 0x80) { just checks if number was small enough to avoid checking MSBs and just copy whole thing 19:42 < sdasad> w/e, but yeah i'm including 1.8 in the build path 19:42 < morfin> java asm is not very hard to learn) 19:42 < sdasad> i'll try copying the assets manually 19:43 < morfin> i was playing around with classes and JavaBite ) 19:44 < nickelpro> morfin: GOOGLE_PREDICT_TRUE is just a macro that informs the compiler that the result of conditional is expected to be true. Also for some optimizations 19:44 < nickelpro> Allows for some* 19:44 <+Amaranth> iirc that's also sometimes a hint to the CPU as well? 19:44 < nickelpro> Ya, it biases the branch prediction 19:44 < morfin> interesting how would Minecraft code look with LLVM 19:44 < sdasad> so I copied the assets in 19:45 < sdasad> now it just gives Exception in thread "main" java.lang.NoClassDefFoundError: net/minecraft/client/main/Main 19:45 <+Amaranth> Everything since Pentium 4 actually ignores those hints so hopefully the compiler doesn't output them anymore 19:45 <+Amaranth> On the x86 side, at least 19:46 < Fenhl> ugh 19:46 < Fenhl> I would be totally fine with Gjum and Grum's nicks 19:46 <+Amaranth> Pentium 4 mispredicted branch was very expensive so having the compiler or developer help avoid them was useful. Since then branch prediction in the CPU has gotten smarter and a mispredict isn't as expensive 19:47 < Fenhl> but in irccloud they're even the same color! 19:47 <+Amaranth> The compiler hint is still useful though 19:49 < nickelpro> Amaranth: I wonder if this would still come up on a modern CPU? http://stackoverflow.com/a/11227902 19:51 <+Amaranth> nickelpro: Yep, they're better but not omniscient or something :P 19:51 <+Amaranth> And a mispredicted branch does still hurt just not as much as on Netburst 19:52 < nickelpro> Amaranth: My understanding was that the CPU starts processing both pipelines and just ditches the mispredicted one. Have do something with all the new silicon on smaller and smaller chip lithographies 19:53 < nickelpro> But that's way beyond me, I only have a PopSci understanding of chip design 19:53 <+Amaranth> I haven't seen anything about that, their answer to what to do with the spare transistors and stalls was hyperthreading 19:53 <+Amaranth> What you're talking about is how GPUs work though, iirc 19:53 < nickelpro> Entirely possible I'm mixing up concepts 19:53 < Grum> would be REALLY awesome if you can hint which side of the branch is more likely to happen 19:54 <+Amaranth> As we've just covered you can hint to the compiler and x86 has bytecode to hint to the CPU but the CPU ignores it now 19:54 < sdasad> got it to boot 19:54 < sdasad> only thing is my client is like 30mb 19:54 < Grum> should i ahve to add +in java? ;D 19:55 <+Amaranth> haha 19:55 <+Amaranth> Well in Java you have hotspot tracing to determine the likely side of a branch at runtime and reoptimize for that 19:56 <+Amaranth> A JIT shouldn't need such a hint 19:56 < Grum> ;) 19:56 < Grum> though as author i know better than whatever thing looks at my code 19:58 < Grum> would be nice to have a known good default as well 19:58 < morfin> hmm 19:58 < Grum> like always presume false 19:58 < morfin> i thought branch prediction does not require hints 19:59 <+Amaranth> morfin: This hint would be for the optimizer, mainly as an optimization for cache layout 20:20 < morfin> that's for some ancient compilers? 20:29 < nickelpro> morfin: lol no? 20:30 < nickelpro> It's a hint, it biases behavior, that's what hints do 21:10 < morfin> hmmm 21:11 < morfin> what's point of having packets with different fieldsets? 21:22 < Grum> No idea what you mean morfin 21:29 < morfin> i mean packets where fields are different(depends on value) 21:29 < gurun_> you mean the lenght of the same field 21:29 < gurun_> like variable size integers? 21:30 < morfin> no 21:30 < gurun_> uh, ok. 21:30 < shoghicp> oh, entity spawn packets 21:30 <+SpaceManiac> packets with big switches, it sounds like 21:30 < morfin> yes 21:30 < shoghicp> where an specific value can send extra fields after it 21:30 <+SpaceManiac> player list, teams, scoreboard etc. 21:30 < morfin> like if value == 1 then field1 and field2 else field3 and field4 etc 21:31 < gurun_> it's because of bad reverese engeneering i suppose 21:31 < morfin> hm? 21:31 < Grum> i can agree taht use to be an issue when the protocol wasn't just splittable in packets by length 21:31 < shoghicp> gurun_: no, it's that way 21:31 < gurun_> if you try to store an object model in a database, that's also what you get. 21:32 < Grum> now, well, because it is smaller ? :) 21:32 < gurun_> a type identifier, and then the type-data after 21:34 < gurun_> ok Grum and shoghicp, next someone asks you, you just sound really professional and say that it's a consequence of inheritance mapping in a flat structure. 21:34 < gurun_> :-P 21:34 < Grum> except that is not what it is 21:34 < gurun_> ok, so just an accident or lazy coders :-) 21:34 < Grum> not really, just ancient and shit design 21:35 < gurun_> hehe 21:35 < Grum> some of the serialization is like that on purpose, its smaller that way 21:35 < gurun_> yeah i got that. 21:37 < Grum> seems to be quite minimal for the scoreboard :/ 21:38 < Xor_Boole> what exactly is the problem with packets with big switches? 21:39 < Xor_Boole> it's not that bad of a way to do it if you ask me, since it consolidates the protocol 21:39 < morfin> it's packets with same id 21:39 < Xor_Boole> that said the protocol is a giant clusterfuck that could use significant cleaning up 21:39 < Xor_Boole> morfin example? 21:40 < morfin> Player List Item is one of that 21:41 < morfin> holy shit 21:42 * Xor_Boole checks 21:42 < Grum> http://wiki.vg/Protocol#Player_List_Item <-- that looks quite ok 21:43 < Xor_Boole> I don't think it's too bad 21:43 < Xor_Boole> I mean, it could be better 21:43 < Xor_Boole> but it consolidates all of the actions into a single header 21:43 < Xor_Boole> otherwise you'd have a shitload of packets for similar things 21:43 < Grum> yeah i'd actually prefer that :/ 21:43 < Xor_Boole> that said... Grum fix your protocol 21:43 < Grum> yeah lol 21:43 < Xor_Boole> too much stuff is disparate 21:43 < Grum> so many things meh and bleh 21:44 < Grum> kinda pointless to fix small shit though :/ 21:44 < Xor_Boole> who is it that says "fix your damn game jeb!" 21:45 < Xor_Boole> Grum depends on how you define "small shit" 21:45 < Grum> name a big shit? :D 21:45 < Xor_Boole> Grum ur mum 21:47 < Grum> ashy shit that is 21:47 < Grum> but Xor_Boole, what is 'really bad' then in your eyes? 21:47 < Xor_Boole> one sec 21:48 < Xor_Boole> oh yeah, the model format 21:48 * Xor_Boole runs 21:48 < Grum> Because it is enough to make everything ingame? ;D 21:48 < Xor_Boole> a lot of the Entity packets could probably be consolidated... 21:48 < Grum> yup 21:48 < Grum> prefer to not touch it, rather fragile :/ 21:49 < Xor_Boole> Grum make DB do it when he's back from his vacation then =p 21:49 < Xor_Boole> speaking of which, is there no snapshot for the rest of the month, or is it just DB not working on his branch? 21:50 < Grum> not doing snapshots between pre-releases 21:50 < Xor_Boole> I still don't want to imagine what a clusterfuck your git repo is 21:50 < Xor_Boole> how many dead branches does the main repo have? =p 21:51 < Grum> i think i have 80+ 21:51 < Xor_Boole> I'm afraid to ask how many es had with all the bugs he spent time fixing 21:51 < Xor_Boole> shame he left, he was good a fixing bugs 21:52 < Grum> ah yeah, 173 branches @ repo 21:52 < Grum> and 87 locally 21:53 < Xor_Boole> I still think you should post commit messages to some public page 21:53 < Grum> but that stuff includes 22 april fools branches etc 21:53 < Xor_Boole> I know you did something like that very briefly around when models were added 21:53 < Grum> yeah no-one cared 21:53 < Grum> so meh :P 21:54 < Xor_Boole> I care. I told you I cared last minecon =p 21:54 < Xor_Boole> just some script to post them to some page 21:55 < shoghicp> added files. 21:55 < shoghicp> commit. 21:55 < shoghicp> fix. 21:55 < Xor_Boole> I prefer 'aklshdfklajsdhf this wokrs ksjlahglfbkajsghd' 21:55 < Grum> nah, prefer to not just share commit messages 21:55 < Xor_Boole> Grum to keep stuff secret from non-devs, I presume? 21:55 < Grum> also mentions exploits etc 21:55 < Grum> so best to not do :) 21:56 < Xor_Boole> damn users ruining our fun 21:56 < shoghicp> I love this one from PE: "2 entities 1 boat!" (that was guessed by some user on reddit) 21:57 < Xor_Boole> I love this site http://www.commitlogsfromlastnight.com/ 21:57 < Grum> there is no 'fuck' in our commitlog 21:58 < Grum> there is shitty though ;D 21:58 < Grum> ha! on my commit 21:58 < Xor_Boole> except for ninja rebases =p 21:58 < Grum> i have a lot of 'temp' commits locally 21:58 < Grum> and fix em up after 21:58 < Xor_Boole> I'm not a small-commits kind of guy 21:59 < Grum> if a single line is not enough you are doing too much in the commit 21:59 < Xor_Boole> wut 21:59 < Xor_Boole> in english please 22:00 < Grum> that is english? 22:00 < Grum> If a single line (in the commit message) is not enough, you are doing too much in the commit (you are writing the message for) 22:00 < Xor_Boole> oh, by small-commits I meant commits with little code 22:00 < Xor_Boole> my messages tend to be short 22:00 < Xor_Boole> the amount of swearing in them is inversely proportinal to the intervals between pushes 22:01 < Grum> i'm happy to not be a user in your repo 22:02 < Xor_Boole> there's also a constant that determines how well I behave on repos based on who uses it 22:02 < Xor_Boole> you'll notice my spigot commits are much saner 22:02 < Xor_Boole> and then there's this, because I wanted to murder whomever last touched the protocol: https://github.com/drXor/LibsDisguises/commit/85642572884899b87b565e48b261176cdd283e96 22:03 < Xor_Boole> also pro plays with string lit typos 22:03 < Grum> seems quite ok ;D 22:04 < Xor_Boole> I hum "everything is broken" to myself whenever I'm coding 22:04 < Xor_Boole> I need to finish the lyrics for it at some point 22:14 < Weloxux> 99 little bugs in the code 22:14 < Weloxux> 99 little bugs in the code 22:14 < Weloxux> take one out, patch it around 22:14 < Weloxux> 127 little bugs in the code 22:15 < Weloxux> too old? --- Day changed lun. févr. 09 2015 00:58 < Gjum> gamingrobot: any unpushed work on spock's inventory? 01:00 < gamingrobot> Gjum not really I have been fixing physics 01:00 < Gjum> ah 01:00 < gamingrobot> Force vectors and such 01:00 < Gjum> yup, great work so far 01:01 < gamingrobot> Decided to use Spock? 01:01 < Gjum> but i need the inventory more :) gonna do it myself and submit as pull request then, if thats ok 01:01 < Gjum> yup 01:01 < Gjum> quarry and its strange use of twisted got too complicated ^^ 01:02 < Gjum> and I like the plugin system 01:02 < gamingrobot> Yea the inventory ouline is there the inventory.extra is whenever some other inventory is opened 01:02 < Gjum> yes i saw that 01:03 < Gjum> a lot better than what i did 01:03 < gamingrobot> I just never filled in the packets 01:03 < gamingrobot> So shouldn't be too hard 01:03 < Gjum> one problem tho is when you open one of these glitched-out triple chests 01:03 < gamingrobot> ? 01:03 < Gjum> server sends slot_num, but you seem to ignore that 01:04 < gamingrobot> Yup because I know the size of the slots list 01:04 < Gjum> you can place three chests next to each other with /setblock and the inventory gets 3*3*9 slots 01:05 < gamingrobot> Weird make a note about it but don't worry about that edge case 01:05 < gamingrobot> For now 01:05 < Gjum> kk 03:44 < nickelpro> "I like the plugin system" is the only thing anyone ever say about Spock. Spock only is a plugin system. It's like saying "I like the saltiness" about a salt shaker 03:45 < gamingrobot> nickelpro: its because its so rare to find a really good plugin system in python 03:45 < gamingrobot> :P 11:09 < morfin> hm every string is up to 65535 bytes right? 11:11 < morfin> hmm seems like it can be bigger 11:30 < Grum> Short.MAX_VALUE 11:31 < Grum> can be longer, that is the longest allowed value given in our code now 11:35 < prplz> how can a short be long? 11:35 < prplz> :] 11:39 < morfin> it allows to max signed int positive value 11:39 < morfin> *up to 12:21 <+Amaranth> Grum: Is that bytes or codepoints? 12:24 < Grum> codepoints when we encode it 12:25 < Grum> so when we decode it we need to account for 4 times as large data :/ 12:27 < Grum> so much fun them unicodes 12:48 < rebecca> Hey people, i have an idea i want to implement in minecraft but it will need a mod that doesn't yet exist. wondering if someone could point me toward the path of least resistance for getting it done. ie: a similar opensource mod i could alter perhaps. 12:49 < rebecca> I want a block that works with a item pipe system that auto crafts based upon a pattern in it. 12:50 < gurun|work> before i discovered unicode my life was dull and full of frustration. Now, with this new product i can finally live a happy life and have time for my wife and child. I recommend unicode to anyone suffering from the same depression i was. 12:50 < rebecca> but crucially, i want to be able to input the crafting pattern via item blocks 12:50 < rebecca> hi gurun|work 12:50 < gurun|work> rebecca:money is usually the least restistance... 12:51 < gurun|work> hi rebecca 12:51 < rebecca> time and work also helps 12:52 < rebecca> i wouldn't mind taking a stab at this myself 12:53 < gurun|work> so, basically you want to .. build a pattern in MC, and then kind of point of that being the pattern used to craft? 12:53 < gurun|work> kind of like what you do with some stuff like portals and things 12:54 < rebecca> yeah, kind of like auto crafting meets a shift register 12:54 < rebecca> i'll describe how i see it function 12:56 < rebecca> the block is connected to a pipe. it's pattern grid is empty. as items flow via the pipe they first fill the pattern grid in a predictable pattern (maybe a special block = whitespace) 12:58 < rebecca> then with a full pattern grid, further items matching what's contained in the grid are held in a little buffer. until each item slot is filled.. and then it poops out the patterned item 12:59 < rebecca> it would be a low tech programmable block 13:03 < rebecca> any ideas? 13:12 < gurun|work> it's like a machine that you feed, right? 13:13 < gurun|work> so you feed it with blocks, and then when a pattern is filled, you craft something, and then it continues feeding off of the input .. and so on. 13:14 < rebecca> yes, automatically 13:29 < Grum> gurun|work: ☃ 13:30 < Grum> ⛄ ? :D 13:31 < gurun|work> hehe 14:41 < gamingrobot> mmm fancy command interface https://db.tt/hsf6udjp 14:44 < gamingrobot> wops bad link https://db.tt/XFYGu4qX 15:31 < toqueteos> could anyone explain the 1.8 changes for http://wiki.vg/Protocol#Chunk_Data please? it says Data value section removed, is that the Chunk-type field? 15:44 < Grum> toqueteos: which part is unclear? 15:45 < toqueteos> Grum: it seems to be describe for an older version and then some notes are added here and there.. so i'm not entirely sure which "data" field the notes are refering to 15:45 < toqueteos> it seems to be a description* 15:45 < Grum> to me the description looks accurate 15:45 < Grum> at least from what i am reading in the code :) 15:46 < toqueteos> http://i.imgur.com/OxJqBeF.png , the "Changes in 1.8" part 15:47 < toqueteos> the funny thing is I already did this for 1.5 15:47 < toqueteos> but now can't get my head around it :( 15:48 < Grum> i'm not sure what the issue is ? 15:48 < Grum> there is just one 'data' field 15:48 < toqueteos> ok.. rewording, are all those changes related to the packet or to the map format? 15:48 < Grum> if you are reading multiple, you are doing something weird 15:49 < toqueteos> because, for example, there's no "extended id" on the packet definition 15:49 < Grum> yes nor metadata 15:49 < Grum> that is all packed into the same data 15:49 < Grum> before you had 3 sections of data, 1x8bits, 2x4bits with one of the two 4bits being optional 15:50 < Grum> now you just have a single 16bit one 15:50 < toqueteos> ok, that was weirding me out 15:50 < toqueteos> thank very much kind sir 15:51 < Grum> should be much easier to read now :D 15:51 < toqueteos> A LOT easier 15:52 < toqueteos> (i was still thinking with the 1x8, 2x4 (one optional) mindset) 17:33 < iasdk> best way to check if a player is in-game? 17:33 < iasdk> minecraft.thePlayer and minecraft.theWorld both work 17:34 < iasdk> but if a player is paused it acts like they aren't connected to a server or in a SP world 17:58 < dx> wat, what kind of api is that 20:07 < morfin> that's from MCP i guess --- Day changed mar. févr. 10 2015 00:46 < gurun> http://www.ikvm.net/index.html 00:46 < gurun> that is next for bukkit to do .NET 00:46 < gurun> salvage operation 01:00 < jython234> xD 01:01 < gurun> hmm .. i wonder how many of the bukkit plugins that actually do anything other than .. just getPlayer() and getBlock() .. 01:01 < gurun> yeah .. getPlayer().getInventory() 05:53 < Xor_Boole> the fact that the vanilla launcher doesn't realign itself with the center of the screen on bootstrap is driving me nuts 08:58 < SupaHam> Anyone know of any decent guides for launching an enviroment with your latest build in Intellij? Specifically for plugins 20:24 < Gjum> nickelpro, gamingrobot: how do I get the display name of an item/block? mapdata only contains blocks, right? 20:24 < Gjum> ^ in spock, that is 20:31 < gamingrobot> Gjum: correct we need to make a map data for items or add items to mapdata 20:32 < Gjum> I could copy mine from Bat, aso did that for inventory stuff 20:32 < Gjum> *also 20:32 < Gjum> but it's in a dict format, not sure if that fits spock's class style 20:34 < gamingrobot> Gjum: map data used to be a duct, class based way allowed for more flexibilty 20:34 < gamingrobot> Stupid autocorrect I'm on my phone 20:35 < gamingrobot> I'll be at my computer in 30min 20:36 < Gjum> btw we don't have to do all that project internal communication via irc 20:36 < gurun> not we don't find it intersting when you start arguing ... :-P 20:50 < gamingrobot> gotta keep the channel active somehow :P 21:05 < gamingrobot> Gjum: for now just return the id and the meta, similar to what world does see here https://github.com/SpockBotMC/SpockBot/blob/master/spock/plugins/helpers/physics.py#L107 21:07 < Gjum> I would rather return a Slot object which has id, damage, ... attributes 21:24 < gamingrobot> then I would do something like mapdata for items 21:26 < gamingrobot> nickelpro might have a better way of doing it that is more spock like 21:27 < Gjum> that should then contain attributes for display name, name, max stack size, id of the block when placed, more ideas? 21:48 < gamingrobot> for most blocks doesnt the id in the slot data match the block id? 21:48 < Gjum> for most, yes 21:48 < gamingrobot> so maybe only have mapdata for the ones that are not blocks? 21:48 < gamingrobot> err itemdata* 21:49 < gamingrobot> because we really shouldnt be duplicating data like that, it becomes hard to maintain if it changes 21:49 < Gjum> right, but e.g. bed items are placed as bed blocks 21:49 < Gjum> so the bed item class should know that 21:50 < gamingrobot> that makes sense 21:50 < Gjum> also, the damage field sometimes indicates damage and sometimes it indicates the block meta 21:51 < Gjum> so that should also be stored 21:53 < Gjum> relevant: http://minecraft.gamepedia.com/Data_values#IDs 22:04 < gamingrobot> I think it should be called meta just to match mapdata, but can be interpreted as damage 22:04 < Gjum> most times, it is damage 22:07 < gamingrobot> alright keep it damage then 23:01 < Gjum> nickelpro: I don't understand what you do in unpack_slot 23:01 < Gjum> are you only unpacking one enchantment? 23:30 < nickelpro> Damage field never indicates metadata as far as I know 23:31 < nickelpro> Slots have are just an id by default, with three optional fields 23:31 < nickelpro> item count, item damage, and optional NBT data 23:31 < Gjum> nope 23:32 < Gjum> slots are -1 or all three 23:32 < Gjum> so all non-empty slots have them 23:32 < gurun> break blocks on PC. Does that start with a use item and finish with a remove block kind of packets? 23:32 < nickelpro> Gjum: Nope 23:32 < nickelpro> A slot is a short with an item id followed by a byte 23:32 < nickelpro> if the byte == -1 you're done 23:32 < Gjum> yep 23:32 < nickelpro> if it is anything else you have an item count and item damag 23:33 < nickelpro> The NBT is optional, you could just get TAG_END/a zero 23:33 < Gjum> so what does that tell us for damage/meta? 23:33 < nickelpro> What item uses damage as metadata? 23:33 < dav1d> pickaxe 23:33 < nickelpro> No, that's just damage 23:34 < dav1d> oh, nvm, didnt follow the conversation, just seen damage and item 23:35 < nickelpro> Any interesting data about items is pushed into the NBT <-- 95% sure on this 23:35 < nickelpro> Spock calls this 'ench' because that NBT blob used to only be about enchantment data 23:35 < Gjum> nope, only enchantment 23:36 < nickelpro> Now, especially with server mods, it holds all sorts of stuff 23:36 < Gjum> sure? 23:36 < nickelpro> 100% I've written some of those mods 23:36 < nickelpro> You can store anything in there, NBT is flexible 23:39 < nickelpro> Here are the nbt tags stored in there: http://minecraft.gamepedia.com/Tutorials/Command_NBT_Tags#Items 23:39 < nickelpro> Many plugins piggyback on the Lore field to store any arbitrary data associated to items 23:40 < Gjum> just tested mossy stonebricks 23:40 < Gjum> PLAY you can store anything in nbt 23:41 < Gjum> but vanilla doesnt 23:41 < nickelpro> Ya but spock supports custom servers 23:41 < nickelpro> And vanilla does do custom names and lore 23:42 < Gjum> right, but damage might contain meta 23:42 < nickelpro> Vanilla doesn't, and I haven't encountered any plugin that does 23:42 < Gjum> so there should be a flag in stonebrick's class that says this 23:42 < Gjum> vanilla doesnt? look above, I pasted it for you :P 23:44 < nickelpro> oh hell that's shitty 23:44 < Gjum> yep 23:45 < nickelpro> Ya someone is going to have a hell of a time implementing that. We really should look into a tool to extract this stuff 23:46 < gamingrobot> inb4 1.9 fixes all this 23:48 < nickelpro> Ok so what we call meta in the world format is stored in DVs in the item format 23:48 < nickelpro> That's not so bad 23:48 < nickelpro> I thought it was a completely different map 23:48 < nickelpro> mapping* 23:48 < Gjum> why? `stack.meta = 0 if item.damage_is_meta is not None else stack.damage` 23:49 < Gjum> or alike 23:49 < Gjum> or maybe a default-false boolean? 23:50 < nickelpro> It's not the decoders job to make sense of the data it gets off the wire, someone needs to build a get_item() function like we have get_block right now 23:51 < nickelpro> The actual problem is managing and maintaining all this block and item data 23:51 < gamingrobot> nickelpro: dont you have the same problem with entities as well? or do you just make use of mapdata and itemdata 23:52 < nickelpro> Also ya we're kinda taking over mcdevs here, time to spin out a freenode channel? :-P 23:52 < Gjum> alright, back to my second question: how do I get the enchantments off the NBT? 23:52 < gamingrobot> time for a #spockbot channel? 23:53 < nickelpro> Gjum: its a mutablemapping https://github.com/SpockBotMC/SpockBot/blob/master/spock/mcp/nbt.py 23:53 < nickelpro> Its a dictionary, basically 23:54 < Gjum> ive been poking around that nbt code for too long and still only get empty dicts :( 23:54 < Gregor> Would it be possible to (or is it already implemented) record and replay the protocol through a proxy, so you could replay a session to a player? Or is enough stuff client-only that you couldn't make things smooth/convincing/correct? 23:55 < nickelpro> It's not mine, I stole it to parse the nbt and forget about it. If you need nbt and hate twoolies nbt reader, build something better and give it to SpockBot 23:55 < Gjum> there is someone actually doing that 23:55 < Gjum> Gregor: ^ 23:55 < Gjum> lemme get their website 23:55 < Gregor> Awesome :) 23:56 < Gjum> mh, might take a while tho 23:57 < nickelpro> Gregor: MCServer has a reasonable up-to-date protocol proxy 23:57 < nickelpro> https://github.com/mc-server/MCServer/tree/master/Tools/ProtoProxy 23:57 < Gregor> Gjum: I appreciate the memory. Maybe if you remember a name I could hunt it myself? 23:58 < nickelpro> gamingrobot: Ya we kinda need a channel 23:58 < Gregor> nickelpro: I guess the deeper question was whether the nature of the protocol was such that replaying it would produce on the client something that looks sort of like a play session. Although if it ends up being "write it yourself", I'll certainly start from that :) 23:59 < nickelpro> Gregor: If the state of the world is identical, certainly 23:59 < nickelpro> If not, you might walk off a cliff or something --- Day changed mer. févr. 11 2015 00:00 < Gregor> But... the world updates are part of the protocol, no? Theoretically one wouldn't even need the server/world if all you're doing is spewing recorded protocol messages. 00:00 < redstonehelper> that's what dividuum does on miners-movies.com 00:01 < Gjum> dammit, can't find it :/ 00:01 < Gjum> aaah redstonehelper thats it! 00:01 < redstonehelper> :D 00:01 < Gregor> That looks like exactly what I want! 00:01 < Gregor> Amazing! 00:01 < Gjum> nice :) 00:02 < Gjum> so, #spockbot or what? 00:02 < redstonehelper> what's spockbot? 00:02 < Gregor> Thanks all :) 00:02 < Gjum> redstonehelper: nvm 00:02 < redstonehelper> I'm interested :( 00:02 < Gjum> https://github.com/SpockBotMC/SpockBot needs its own irc channel already 00:02 < nickelpro> I'm not a real adult, someone create the channel and setup chanserv 00:03 < Gjum> so am I lol 00:03 < nickelpro> redstonehelper: https://github.com/SpockBotMC/SpockBot 00:04 < gamingrobot> nickelpro: already doing it 00:04 < nickelpro> gamingrobot: Have I ever told you how helpful you are? 00:05 < gamingrobot> what are you talking about :P 00:05 < Gjum> https://blog.freenode.net/2008/04/registering-a-channel-on-freenode/ or what? 00:05 < nickelpro> I actually have not one but two completely unrelated bugs sitting in spock's repo. I've never had options about what to fix before 00:06 < gamingrobot> Gjum: yea I am working on it 00:08 < gamingrobot> anyone fiddling with spockbot head over to #spockbot 03:20 < Gregor> Unfortunately, miners-movies is protocol-out-of-date, closed-source and the original author seems to have no intent of updating it particularly soon :( 03:20 < Gregor> I wonder if it would be worthwhile to try to make a plugin for an existing proxy that would do the same. 03:23 < Gregor> [the answer is no, but, y'know, a man can dream X-D ] 03:28 < dx> Gregor: "protocol-out-of-date"? 03:28 < dx> this claims to support 1.8 https://github.com/dividuum/fastmc 03:34 < Gregor> dx: From what I can see, that one component supports 1.8, but the complete recording software is stalled at 1.7.2. I might be misunderstanding something important tho :) 03:34 < Gregor> (It's not for technical reasons that it's stalled) --- Day changed jeu. févr. 12 2015 00:46 < Xor_Boole> What changed clientside with map rendering? 00:46 < Xor_Boole> as in 1.7 -> 1.8 00:46 < Xor_Boole> I feel like some cacheing appeared that is breaking things 08:56 < xehbit> mogge 08:57 < xehbit> And wrong channel... Good moring then :) 09:06 < Grum> such dutch 09:07 < xehbit> Hehheh yea :) 09:07 < xehbit> How did you know ? 09:08 < Grum> dutch myself =) 09:09 < xehbit> =D !! 12:03 < Not-f107> [node-minecraft-protocol] roblabla pushed 2 commits to master [+0/-0/±2] http://git.io/NCIU 12:03 < Not-f107> [node-minecraft-protocol] gitter-badger fb7eba4 - Added Gitter badge 12:03 < Not-f107> [node-minecraft-protocol] roblabla 98cfb4a - Merge pull request #107 from gitter-badger/gitter-badge Add a Gitter chat badge to README.md 15:53 < Gjum> does the protocol allow for multiple windows being open at the same time, like 3 crafting tables? 15:54 < Gjum> and if yes, would servers respond to clicks? 16:04 < Xor_Boole> Gjum do I want to know why you want this? 16:07 < Gjum> just to make sure that the client won't crash 18:07 < morfin> hmm 18:07 < morfin> some random wrong thing can crash client 20:12 < kvgeorge1> Can someone answer a protocol question for dealing with a crafting table? 20:12 < kvgeorge1> (workbench) 20:15 < kvgeorge1> When a player crafts an item, it appears that an 0x0E is sent to the server, and a resulting 0x32 (confirmation) is then received. If a player clicks on slot 0 of the bench, how does the server deal with updating the inventory slots if not all the items in the workbench are consumed? 20:16 < kvgeorge1> is there a way to force the server to send setslot updates to the client? 20:32 < kvgeorge1> is there a way to force the server to send setslot updates to the client? 20:33 <+Amaranth> The client can't force it in any way I know of 20:33 < kvgeorge1> but can the server send a request? 20:33 <+Amaranth> The server can just send set slot packets how it wants 20:33 < Gjum> you mean like the buckets when crafting a cake? i think no 20:33 < Gjum> except rejoining/reopening the window 20:35 < kvgeorge1> when the client clicks on slot 0 in the workbench, what tells the client to update slots 1-9?