14:38 < Not-1ae1> [minecraft-data] ... and 2 more commits.
17:43 < rom1504> what's up with 15w35a
17:44 < redstonehelper> *b
18:04 < rom1504> 15w42a incoming
18:43 < rubyrandom> 3/
19:16 <+Amaranth> rom1504: Expect protocol changes
19:33 < rom1504> okay
19:53 < TkTech> The scrollback on this channel makes me sad sometimes. 
19:55 < TkTech> Other times it's hilarious.
21:52 <+ammar2> TkTech: integrating a positive feedback loop with humor and diversity are one of the key pillars of this community that allow it to syngergize and create distruptive innovation in this globalzied marketplace
21:56 < roblabla> disruptive...
21:56  * roblabla checks the chan topic
21:56 < roblabla> yup, still minecraft projects.
21:57 < roblabla> :P
21:58 < TkTech> ammar2, I violently accosted the items on my desk in response to that.
21:59 <+ammar2> working as intended then :3
22:07 < TkTech> You monster.
23:33 < Not-1ae1> [minecraft-data] rom1504 pushed 1 commit to 1.8 [+0/-0/±1] http://git.io/vsD6Q
23:33 < Not-1ae1> [minecraft-data] rom1504 da1340f - make jsonschema test display all the recursive errors : no point in limiting to 4, all the level are needed to understand the error
--- Day changed mar. août 25 2015
00:16 < wordnice> can someone help me with basic 0x00 protocol?
02:12 < Not-1ae1> [minecraft-data] rom1504 pushed 6 commits to 1.8 [+4/-0/±5] http://git.io/vsyZj
02:12 < Not-1ae1> [minecraft-data] Gjum 2122bee - Add schema for windows.json
02:12 < Not-1ae1> [minecraft-data] Gjum 83f1836 - add example windows.json
02:12 < Not-1ae1> [minecraft-data] Gjum d183be8 - Add windows.json to tests
02:12 < Not-1ae1> [minecraft-data] ... and 3 more commits.
03:27 < Not-1ae1> [minecraft-data] rom1504 pushed 4 commits to 1.8 [+0/-0/±5] http://git.io/vsyak
03:27 < Not-1ae1> [minecraft-data] roblabla 94e8f72 - Introduce switch, remove condition
03:27 < Not-1ae1> [minecraft-data] rom1504 dcf9cfc - replace condition by switch in the schema
03:27 < Not-1ae1> [minecraft-data] roblabla 1b26ff3 - Merge pull request #2 from rom1504/1.8-feature-introduceSwitch replace condition by switch in schema
03:27 < Not-1ae1> [minecraft-data] rom1504 a3c60d7 - Merge pull request #43 from roblabla/1.8-feature-introduceSwitch Introduce switch and void, remove condition
09:24 < wordnice> Cannot find any info about first byte and last 2 bytes of 0x00 packet. When reading client request, got "0F 00 2F 09 6C 6F 63 61 6C 68 6F 73 74 63 DD 01 01 00" (Assuming that second byte 00 is packet id). 0x2F is readed as 47 VarInt = version, VarInt 0x09 + text = host, 0x63DD = port, 01 VarInt = get status, but what are there doing the last "01 00" bytes? Cannot find anything about that in /Protocol. Client version 1.8.8. Thanks!
11:09 < rom15041> wordnice: I guess the first byte is the length of the packet since that packet is probably sent uncompressed
11:16 < rom15041> 0F is 15 so your packet stop at that 01, the last two bytes aren't part of that packet
11:19 < rom15041> 1+1+10+2+1=15
12:06 < morfin> ah that's stream do not forget
13:46 < angal> Why mojang removes dashes from uuids...
13:46 < angal> What UUID version used for online mode?
13:46 < angal> 4?
13:48 < ScruffyRules> Yes
13:48 < ScruffyRules> The version numbers are in the UUID
14:35 < rom1504> angal: dashes are in some packet
14:35 < rom1504> but then it's not uuid4 I think
14:36 < ScruffyRules> What?
16:04 < XorBoole> TIL: the new mojang launcher does not like using a directory named version.jar instead of a true jarfile, even though the old launcher didn't mind
16:04 <+ammar2> thats a bad directory
16:12 < XorBoole> shhh
16:47 < XorBoole> things that are not fun: tinkering with lwjgl via bytecode hacks
16:54 < AlphaBlend> i have a question, I may not be around for the answer, but I'm just wondering if it's possible to detect if a spectating player uses the spectate menu to interrupt his target and choose another spectator to target, while he's already spectating
16:58 < johni0702> AlphaBlend, looks like the client sends Spectate (0x18) to the server to tell it which player to spectate. I suppose the answer from the server (packet 0x43: Camera) can contain any entity id and the client will obey it. have not yet tried it myself though
17:07 < AlphaBlend> the camera packet works
17:07 < AlphaBlend> i can tell a player which entity to spectate
17:07 < AlphaBlend> but the problem i had was detecting if a player spectated someone else while spectating
17:07 < AlphaBlend> i can try 0x18
17:09 < AlphaBlend> actually i already tried that method
17:09 < AlphaBlend> i can try it again, but i think when i did test it out, that packet wasn't sent to the server
17:09 < AlphaBlend> when the client chose its next spectator target
17:10 < AlphaBlend> it only teleported to the target client-side, the server wasn't notified
17:10 < AlphaBlend> unless i did something wrong
22:40 < Yoduza> where is the samples for using client side app with server protocol http://wiki.vg/Protocol ?
22:49 < nick___> in the wiki.vg @ protocol version numbers there's 15w34a and 15w35b, but 15w34b 15w34c 15w34d and 15w35a is missing
22:55 < rom1504> nick___: add them ;)
22:55 < nick___> .
22:56 < rom1504> does entity metadata have to be valid to see the players ? (when building a server)
22:56 < rom1504> well I mean, does it have to contain something
22:59 < nick___> i got this error when i tryed to register to wiki.vg: "Login error Incorrect or missing confirmation code."
23:21 < angal> rom15041, enough any 1 valid (posible) value (ie. air level)
23:21 < Wuppie> hey guys, they changed the chunk data i see, what do they mean with: list of block state IDs possible within the chunk
23:24 < rom1504> angal: actually in the end, providing no value just work
23:25 < rom1504> ah pre-release page has been updated indeed
23:26 < rom1504> we miss the bot telling us about wiki.vg updates here
23:32 < Yoduza> where can i test client ? ip:port ?
23:36 < rom1504> test what Yoduza ?
23:37 < Gjum> a test server for their client
--- Day changed mer. août 26 2015
00:42 < rom1504> well the vanilla server is one
02:59 < nickelpro> Wait, where is our wiki bot?
02:59 < nickelpro> I liked wiki bot
03:03 < dx> TkTech: ^
03:06 <+ammar2> its dead
03:06 < dx> RIP
03:21 < nickelpro> rip in pepperoni wiki bot, you will be missed
11:59 <+Thinkofdeath> The wiki bot has never lasted more than a few days before crashing
12:36 < rom1504> someone makes a new one
12:38 < rom1504> https://github.com/fenhl/mwikiircbot
12:38 < rom1504> google gave me this. Like seriously we're the only mediawiki users that also use irc ?
13:54 <+Amaranth> I swear back in the day Wikipedia themselves had a bot reporting edits to IRC
14:05 <+SinZ> I'd prefer to check what is breaking the existing bot before coming up with replacements
14:07 < Fenhl> Amaranth: yeah, well, they don't anymore, hence mwikiircbot
14:29 < Fenhl> TkTech: if you're having problems with the wiki bot, you might want to try setting up mwikiircbot?
17:47 < nick____> lol i can slap people on irc [here]
17:47  * nick____ slaps nick____ around a bit with a large fishbot
17:47  * nick____ slaps nick____ around a bit with a large fishbot
18:17 < rom1504> nick____ is discovering /me, in the future he might discover /nick
20:04 < Aikar> welp, my server finally supports name changes
20:04 < Aikar> has went off mostly w/o big issues
20:05 < Aikar> just missed 1 not touched much db table i forgot used user names so some people got credit a 2nd time for joining website
20:06 < Aikar> and forgot to do a "user is renaming to same name but diff case" check, so it was like "Oh I need to free up that name for you, let me go process a name change for that user and ask mojang the new name", which caused inf recursion and bombing mojang API lol
20:08 < Aikar> sorry mojang :P
20:08 < Aikar> was only 2 people who triggered it before i stopped it :3
21:54 < Aragas> Are there already samples of those varint list from chunk update? Can't really get what is written in wiki
22:20 < johni0702> Aragas, I'm not exactly sure what varint lists you're referring to but MCProtocolLib (https://github.com/Steveice10/MCProtocolLib/tree/snapshot) seems pretty up to date
22:48 < Aragas> johni0702 thanks
23:20 < Fenhl> what does the new Tracking Position field on the Maps packet mean?
23:31  * nick____ slaps nick____ around a bit with a large fishbot
--- Day changed jeu. août 27 2015
00:28 <+Thinkofdeath> Fenhl: hides the player icons as far as I can tell
11:22 < morfin> Minecraft client can send not normalized UTF-8?
12:23 < morfin> ok, another question
12:24 < morfin> does Minecraft allow to use non-ASCII symbols in nicknames in oline mode?
12:32 < barneygale> morfin, not as far as I know. allowed characters are A-Za-z0-9_
12:38 < morfin> hm
12:47 < morfin> idk how nick in game changes
12:48 < morfin> or nick == login?
15:15 < rubyrandom> morfin: nick is not login
15:15 < rubyrandom> morfin: after introducing mojang accounts, your login is an email
15:16 < rubyrandom> morfin: and you can change your nickname at your will (once a month iirc)
15:16 < rubyrandom> before that, your nick was your login, right
20:51 < mhsjlw> One of the mc devs: is there reasoning behind your decision to convert player look packets from floats to byte arrays then back? It seems unneeded.
21:07 <+Amaranth> Did they try to make it fixed point like positions then realize that is a bad thing to do to a camera?
23:15 < rom1504> should I send the respawn packet to make a client respawn ?
23:16 < rom1504> wiki.vg description seems to say no but that's confusing
23:17 < gamingrobot> rom1504: spockbot does
23:17 < gamingrobot> err
23:17 < nick____> .
23:17 < gamingrobot> spockbot when it dies sends the respawn packet to the server
23:22 < nick____> in hardcore?
23:37 < rom1504> yeah okay
23:37 < rom1504> indeed sending the respawn packet worked
--- Day changed ven. août 28 2015
02:53 < Aikar> https://kobra.io/#/e/-Jxliqqc6TOg9mI50Dam group coding - make something epic....ly useless.
12:57 < nick____> "*.net *.split"?
13:03 < rubyrandom> nick____: https://en.wikipedia.org/wiki/Netsplit
18:10 < Fenhl> snapshot time!
18:11 < Fenhl> I wonder what the reason for the protocol version bump is this time
18:51 < Gjum> > [Bug MC-87078] – Using a sweep attack sends "lasdjfhlsdhjflsdij" to output log
18:51 < Gjum> lol
18:53 < nickelpro> Classic
20:15 < nickelpro> SpaceManiac: Your projects are looking for you
23:34 <+Thinkofdeath> Is this me or is vanilla rendering these in the wrong order? http://i.imgur.com/XDb45C4.png
23:40 < angal> Maybee...
23:43 < Fenhl> Thinkofdeath: stained glass rendering is a horrible hack
23:44 < Fenhl> Thinkofdeath: it sometimes corrects itself after a couple seconds
23:44 < Fenhl> I think it caches the z layering or something like that
23:44 <+Thinkofdeath> took a minute or two but it did correct itself
23:45 <+Thinkofdeath> Fenhl: I think Amaranth said it was just sorting the vertices using the painters algorithm, I assume its got a chunk per a frame limit or something
23:47 < Fenhl> there's a building with rainbow glass walls at our spawn, it looks wrong most of the time and it's really annoying
23:48 <+md_5> Gjum I made that report first, then the silly mods closed mine as "duplicate" supposedly because the other one had more detailed repro info... not that ctrl+f didn't suffice....
23:49 < Fenhl> I don't see why you're complaining, the other report was significantly more descriptive
--- Day changed sam. août 29 2015
00:06 <+md_5> Fenhl both were equally descriptive in terms of identifying and fixing the issue
02:31 < Not-2be> [mineflayer] rom1504 pushed 1 commit to master [+1/-2/±6] http://git.io/vGsqZ
02:32 < Not-2be> [mineflayer] rom1504 ca365c3 - move biome and block to prismarine-biome and prismarine-block for reusability
09:37 <+Grum> did anyone document the protocol changes already in the latest snapshots?
09:38 < dx> i see some activity http://wiki.vg/index.php?title=Pre-release_protocol&action=history
09:41 <+Grum> ah yeah, seems to not be up2date yet. I'll wait a bit longer :)
10:21  * gamingrobot wonders what Grum is waiting for
10:23 <+Grum> just to see what people make of it
10:29 <+SinZ> you can always tell us ^.^
10:30 <+Grum> i will once someone looks at it, its interesting to see what people figure out on their own, gives an insight in what they expect
10:31 <+Grum> which says something about what i did
10:37 < gamingrobot> How do people find these protocol changes, decompiling the server jar?
10:37 <+Thinkofdeath> Grum: the chunk changes?
10:38 <+Thinkofdeath> if so i've been meaning to update the wiki with that info, never got around to it
10:39 <+Grum> communicating chunks is different because they are now stored differently
10:40 <+Thinkofdeath> yeah i've implemented the changes into my client already
10:40 <+SinZ> rip anvil?
10:40 <+Grum> no anvil is still there
10:40 <+Thinkofdeath> https://github.com/thinkofdeath/steven/blob/master/chunk.go#L567-L614
10:40 <+Grum> at quite the cost though
10:41 <+Grum> that will break Thinkofdeath
10:41 <+Grum> we have different kinds of storage now
10:41 <+Grum> boundaries are at   4 and 8 bits
10:42 <+Grum> <=4 & <= 8 is palette based
10:42 <+Grum> but bigger than that .....
10:42 <+Grum> will not send a palette
10:43 <+Thinkofdeath> when did that change happen? didn't see that in 35b
10:44 <+Grum> very last one
10:44 < gamingrobot> Grum: what do you mean by "at quite the cost though"
10:44 <+Thinkofdeath> ah i'm behind then
10:44 <+Grum> gamingrobot: literally that
10:44 <+Grum> breaking down efficient data into something 'compatible' is expensive
10:45 <+Grum> Thinkofdeath: also the data is designed to be send as longs, might not make a difference -- but it might do :P
10:46 < gamingrobot> Ah ok what's the name of the new storage format, sword? 
10:46 <+Thinkofdeath> i'd hope not but i'll look out for it :)
10:46 <+Grum> there is no new storage format
10:46 <+Thinkofdeath> Grum: out of interest why was sky light and block light moved next to the block data? Won't that affect how well it compresses?
10:46 <+Thinkofdeath> since block light will be mostly 0 anyway
10:46 <+Grum> it matters actually jack shit :)
10:46 <+Thinkofdeath> oh
10:46 <+Grum> this format compresses better, but barely
10:46 <+Grum> mostly because its significantly less data
10:47 <+Grum> shows how well compression does its job :)
10:48 <+Thinkofdeath> yeah, would have thought there would be small improvements with the old way of handling light though
10:49 <+Thinkofdeath> Grum: speaking of which have you fixed the issue of removing empty chunk sections that have light traveling through them?
10:49 <+Thinkofdeath> causes some lighting issues in rare cases
10:49 <+Grum> Thinkofdeath: no idea
10:50 <+Thinkofdeath> hmm, ok
10:50 <+Grum> the 'multichunk' packet is gone btw
10:51 <+Thinkofdeath> noticed, the way the wiki shows it isn't great 
10:51 <+Grum> i put a 'forgetthischunk' packet in its place so all the order wouldn't shift, no idea if that is something we'll keep like that though (order)
10:52 <+Thinkofdeath> the order is only really a pain for the wiki, in code its just me rearranging a struct
10:52 <+Grum> i think the packets should be given names
10:53 <+Grum> and then have a list of numbers for the names
10:53 <+Thinkofdeath> hmm, could work.
10:54 <+Grum> that is how we handle them
10:54 <+Grum> our ids are dynamically assigned
10:55 <+Thinkofdeath> same with steven, just slightly harder to dynamically assign them on a wiki without a plugin :)
10:55 <+Thinkofdeath> unless there is a counter feature i'm missing
10:56 <+Grum> counter feature?
10:56 <+Thinkofdeath> so it gets its id from the order its on the page
10:57 <+Thinkofdeath> changing the order updates the ids for us 
10:57 <+Thinkofdeath> don't think it exists though
10:58 <+Thinkofdeath> meh the table will do
11:23 <+Grum> Thinkofdeath: in theory the protocol supports 'infinite' blockstates now
11:23 <+Grum> so 'at least that is nice' ;D
11:24 <+Thinkofdeath> yep noticed that :D
11:24 <+Thinkofdeath> when do the virtual (for lack of a better name) block states become real?
11:24 <+Thinkofdeath> (fences redstone etc)
11:25 <+md_5> I really should just make a new wiki account... given up on someone ever being nice enough to recover md_5
11:25 <+Grum> Thinkofdeath: after 1.9
11:25  * Thinkofdeath marks calendar
11:26 <+Thinkofdeath> implementing the UpdateState methods is pain :P
11:26 <+Grum> yeah :/
11:26 <+Grum> going to be quite the effort of doing it 'properly' though 
11:28 <+md_5> in other news, I made a debian/ubuntu package for the Minecraft launcher. Just the depends/jar/icon/shortcut really. Makes it easier to grab+add to unity on ubuntu though
11:29 <+Thinkofdeath> neat
12:07 <+Thinkofdeath> http://wiki.vg/Pre-release_protocol#Packets Done (somewhat)
12:08 <+Thinkofdeath> Just need to remove the ids from the packets on the page and at a warning at the top saying "Don't build your code around theses ids, Grum will randomize them just to brake your code" :)
12:10 <+md_5> building it around IDs is useful when you dont feel like implementing every packet :p
12:11 <+Grum> some links are not working Thinkofdeath :p
12:11 <+Grum> md_5: yes but they are also not based on ids in our code
12:11 <+Thinkofdeath> damn it
12:12 <+Grum> like the chunkdata one
12:12 <+md_5> more than aware of that
12:12 <+Grum> http://wiki.vg/Pre-release_protocol#ChunkData
12:12 <+md_5> yeah missing underscores
12:12 <+md_5> Chunk_Data
12:12 <+Thinkofdeath> fixed
14:03 < yawkat> you should totally add this to vanilla https://github.com/thinkofdeath/steven/pull/65
14:03 < yawkat> if srv is offline, connect to A
14:04 < yawkat> it's nice for ddos protection :)
14:12 < nevercast> Just confirming that Entity Status 10 is both Sheep eating grass & Play TNT ignite sound?
14:12 < nevercast> This is entity type dependent?
14:12 < yawkat> yes.
14:12 < nevercast> Okay thank you. 
14:21 < nevercast> Map Chunk Bulk. Chunks are not collated with their Meta? It's Meta[Count], Data[Count] ?
14:22 < yawkat> correct.
14:22 < yawkat> this helps compression.
14:23 < nevercast> Being that metadata with stacked values can be compressed very effectively. Yes ok
14:26 < nevercast> Most of these packets have great structure, then there is particle and player list item that have strongly varying structure. 
14:28 < yawkat> it would be nice if they all got an easy-to-specify structure
14:28 < yawkat> punch it into xml and generate bindings for languages
14:29 < nevercast> It almost does. The optionals and conditions break it however. 
14:29 < Fenhl> md_5: no don't use underscores in wiki links that's bad style
14:30 < nevercast> I'm going to slap up some optional and conditional attributes on my definitions. But it would be great if it was more portable.
14:30 < Fenhl> Thinkofdeath: counting ids is totally possible, but our wiki is lacking even the most basic parser functions for some reason
14:38 < Fenhl> also, I'm tweaking [[Template:PacketList]] a bit since some of the anchors are broken
14:50 < nevercast> yawkat, Is there a syntax standard description of the protocol that can be consumed by generators?
14:51 < yawkat> well not currently i think.
14:53 < nevercast> That's unfortunate.
15:04 < nevercast> yawkat, For reference, this is the best I've found out there: https://github.com/PrismarineJS/minecraft-data/blob/1.8/enums/protocol.json
15:05 < yawkat> there's also this https://github.com/thinkofdeath/steven/blob/master/protocol/play_clientbound.go
15:05 < yawkat> it generates the protocol bindings from go structs.
15:05 < yawkat> you can also see it has conditions in some cases.
15:06 < nevercast> Conditions and field based arrays?
15:06 < yawkat> https://github.com/thinkofdeath/steven/blob/master/protocol/play_clientbound.go#L830
15:07 <+Thinkofdeath> Fenhl: oh right, we have multiple packets with the same name
15:07 < nevercast> yawkat, That is really good. I think the protocol could be split in to another repository and then tagged with snapshots and protocol versions. 
15:08 < yawkat> yea, ive thought of it before
15:08 < yawkat> i have a similar setup in java like Thinkofdeaths version
15:08 < yawkat> but an xml one would be very nice
15:08 < yawkat> xcb does this but having one for minecraft would be great
15:08 < yawkat> hey Thinkofdeath, youre bored all the time, right?
15:09  * Thinkofdeath hides
15:09 < yawkat> :D
15:09 <+Thinkofdeath> also the steven one you linked is for the snapshots not 1.8
15:09 < yawkat> whatever
15:10 < nevercast> Yes that was my point. Its latest snapshot
15:10 < nevercast> Something tagged with versions would be great
15:11 <+Thinkofdeath> the json one is the closest you are going to get with that for now
15:11 <+Thinkofdeath> I have no plans to keep the format used in steven stable
15:13 < nevercast> "OpenGL profile requested but WGL_ARB_create_context_profile is unavailable" I'm surprised my graphics is missing an OpenGL feature
15:14 <+Thinkofdeath> normally that means your gpu is missing gl3.2+ support
15:15 <+Thinkofdeath> or glfw/me is derping somewhere, never checked :)
15:15 < nevercast> Updating drives to be sure of PEBKAC
15:15 < nevercast> s/drives/drivers/
15:19 < johni0702> nevercast, out of curiosity, what is it you're trying to do / why isn't the minecraft-data protocol.json sufficient?
15:20 < nevercast> johni0702, It is sufficient. I'm looking at other options. The less work I have to do to write a generator the better.
15:20 < nevercast> What I'm doing is writing a protocol lib. There are so so many of them, but so very few if any maintained.
15:20 < johni0702> ah, which language?
15:21 < nevercast> Currently C#. I've not touched it in years, thought I might try out the new features. 
15:23 < nevercast> Thinkofdeath, The realtime reloading of block textures is a wonderful thing. Also got it running. 
15:23 <+Thinkofdeath> :D
15:23 < nevercast> Laptop configurable graphics. System didn't detect Steven.exe as a game. 
15:24 <+Thinkofdeath> ah those fun systems
15:24 <+Thinkofdeath> yeah it wouldn't, nvidia hardcodes the list
15:24 < nevercast> I wish it was NVidia. 
15:24 <+Thinkofdeath> amd?
15:24 < nevercast> ATI (No I don't mean AMD)
15:24  * Thinkofdeath shivers
15:25 < nevercast> ^ This
15:25 <+Thinkofdeath> bane of my life those
15:25 <+Thinkofdeath> their drivers love to segfault
15:26 < nevercast> I don't call myself a measure of "fanboy", but I have a prejudice against AMD
15:26 < nevercast> Just like I use WD not Seagate. It's a matter of one brand has caused me far less trouble than the other. 
15:27 < nevercast> Thinkofdeath, Chance of a Windows 1.8.8 build? :) :) :)
15:28 <+Thinkofdeath> the 1.8.8 builds exist on the ci but are pretty old now
15:28 <+Thinkofdeath> didn't seem worth maintaining two unfinished versions :)
15:29 < nevercast> That's fair enough. Means I can't walk around my server though 
15:30 <+Thinkofdeath> its nothing fancy anyway
15:30 <+Thinkofdeath> apart from the clouds I guess http://gfycat.com/GrimyHarmfulAnemone :)
15:31 < nevercast> Heh, rendering works when the window is not focused, when the window is focused render order is broken. Backfaces of blocks are show and the sun renders over the blocks. 
15:31 <+Thinkofdeath> o.o
15:31 < nevercast> I wouldn't consider that a noteworthy issue though. Likely my laptop. 
15:31 < nevercast> Odd that it's only when the window is in focus that it happens
15:31 <+Thinkofdeath> yeah sounds like it, opengl support in drivers isn't the greatest 
15:32 <+Thinkofdeath> and I don't feel like learning directx
15:33 <+Thinkofdeath> Fenhl: do you think its worth removing all the packet ids from the packets descriptions on the page so we only update in one place?
15:35 < nevercast> Thinkofdeath, I'd like to thank Steven for pinning a core on the login page :D
15:35  * Thinkofdeath whistles
15:36 <+Thinkofdeath> worth it for the backgrounds :P
15:36 <+Thinkofdeath> http://i.imgur.com/2PdTYC8.png
15:37 < nevercast> Aether client style "Render last world" ?
15:37 <+Thinkofdeath> yeah
15:37 < nevercast> Nice
15:37 < nevercast> Too much FPS though. Needs less. Or maybe I need less Laptop. 
15:37 < Fenhl> Thinkofdeath: sounds like a bad idea
15:38 <+Thinkofdeath> nevercast: should be vsync'd, maybe thats why your cpu usage is so high
15:38 <+Thinkofdeath> guess I never thought about gpu's not supporting that
15:38 <+Thinkofdeath> Fenhl: oh?
15:39 < Fenhl> I'd be okay with adding templates to reduce errors, but that's not currently possible and I do think the information is important
15:39 <+Thinkofdeath> hmm I was thinking it would make any future reorders easier
15:41 < nevercast> With this JSON file I'm left to ponder if I should generate statically-typed structures or just have a dynamically typed protocol library that takes this JSON as a 'schema'
16:03 < nevercast> Thanks for your help #mcdevs. Will be online later. Cheers. 
16:55 <+Amaranth> Thinkofdeath: You could probably get by with rendering that to a FBO like 10 fps and just doing some artistic pans to fill the rest of the time
17:33 <+Thinkofdeath> hmm could work. The current implementation is lazy, it just doesn't clear the render state when leaving servers and does it on join instead
17:33 <+Thinkofdeath> so the world stays in the background, frozen
18:06 < rom15041> nevercast: in what language do you want to do that ?
18:07 < rom15041> And btw look at this. https://gist.github.com/rom1504/7b4c0cc29fb03122b6a5 but we are trying to make something usable by anybody ( and language) with minecraft-data
18:11 <+Thinkofdeath> rom15041: he left and has apparently commented on that gist :P
18:12 < rom15041> Ha !
18:12 < rom15041> Good point ^^
19:57 <+Amaranth> Thinkofdeath: Oh, I assumed it was rendering something back there since he said it was maxing out his system sitting on the menu
19:57 <+Amaranth> But I guess the possibility of broken vsync makes more sense now
19:58 <+Thinkofdeath> well it is rendering but just the old chunks from before (so no building/updates) so it shouldn't have maxed out
20:01 <+Thinkofdeath> Vanilla still beats me in rendering performance :3
20:06 <+Thinkofdeath> Vanilla: http://i.imgur.com/4ZJ1AyW.png ~500fps    Steven: https://i.imgur.com/bYiqH0P.png ~150fps 
20:16 < DiaLight> Clouds different
20:18 <+Thinkofdeath> they don't make much difference in terms of fps
20:18 <+Thinkofdeath> 150 with, 180 without
20:21 < DiaLight> may be reason in OpenGL settings or texture mip mapping
21:13 <+Amaranth> Thinkofdeath: Using index buffers?
21:13 <+Thinkofdeath> yeah
21:14 <+Amaranth> Stop drawing the UI and output the FPS to console once a second
21:15 <+Thinkofdeath> ~190fps
21:16 <+Amaranth> Wow guess you've got decent text rendering
21:16 <+Thinkofdeath> :)
21:16 <+Amaranth> Are you doing occlusion culling?
21:16 <+Amaranth> And are you culling as much as Minecraft is?
21:16 <+Thinkofdeath> yes and hopefully
21:17 <+Thinkofdeath> i implemented what tomcc put on his blog and it seems to work fine
21:17 <+Thinkofdeath> plus frustum culling
21:18 <+Amaranth> Well other than color differences the only other thing that stands out is the FoV which won't change the performance that much
21:18 <+Grum> Thinkofdeath: you implemented the 'narrowing cone' ?
21:18 <+Amaranth> So it looks like you're going to have to bust out a profiler
21:18 <+Thinkofdeath> Grum: narrowing cone?
21:19 <+Thinkofdeath> Amaranth: yeah :|
21:19 <+Grum> what did you implement? :D
21:19 <+Thinkofdeath> https://tomcc.github.io/2014/08/31/visibility-1.html
21:19 <+Thinkofdeath> something like that
21:19 <+Amaranth> Flood fill to detect connected section faces and BFS to filter out hidden chunks
21:20 <+Grum> humz yeah that one has bugs
21:20 <+Thinkofdeath> .-.
21:20 <+Grum> frustum clamping is the 'bestesterest' way
21:20 <+Grum> but i've not been able to implement that properly
21:21 <+Grum> its a bit more high-traffic but also significantly more perfect
21:22 <+Amaranth> Thinkofdeath: He means https://tomcc.github.io/frustum_clamping.html but in 3D
21:22 <+Grum> aye
21:22 <+Amaranth> Except how does that handle caves?
21:22 <+Grum> that is 'the bestest way' but i've had stupid issues implementing it for some reason
21:22 <+Grum> Amaranth: it handles them perfectly
21:22  * Thinkofdeath reads source
21:22 <+Amaranth> You're still going to render them unless you're doing visibility testing
21:23 <+Grum> no?
21:23 <+Grum> because that beam will never go back on itself
21:24 <+Amaranth> btw frustum clamping appears to be a term you guys made up
21:24 <+Grum> yes
21:24 <+Grum> which is why i mentioned it, since its mentioned in the last link in the article ;)
21:25 <+Grum> basically 'cone of view' clamping
21:25 <+Amaranth> I'm trying to think of terms/phrases that would be used in CG literature to see if there are any papers out there for this
21:27 <+Amaranth> Surprise, the most similar things involve raytracing
21:27 <+Grum> yup
21:27 <+Grum> which is far too expensive
21:28 <+Amaranth> You can almost get away with voxel raycasting for rendering these days
21:29 <+Grum> haha yeah on beast machines without textures :p
21:29 <+Amaranth> https://www.shadertoy.com/view/4ds3WS
21:30 <+Amaranth> I think that has a 180 block render distance by default
21:30 <+Grum> quite amazing what people make ;P
21:31 <+Amaranth> Apparently if it was running in a real engine and not recalculating the noise for the entire scene every frame the frame time would be cut in half
21:35 <+Grum> doesn't matter, not really an option
21:36 <+Amaranth> Sure, when I couldn't get anything interesting to run at 30 fps on my laptop I came to the same conclusion
21:36 <+Amaranth> But it's close :D
21:37 <+Amaranth> Would make a lot more sense for a game that is mostly indoors though
21:37 <+Amaranth> Expansive outdoor scenes are a worst case scenario for raycasting
21:39 <+Grum> yeah
21:41 <+Grum> still want to implement the idea we had though
21:42 <+Grum> going to be very interesting though :P
22:49 < Aikar> Dinnerbone / Grum: RegionFile where it gets a DeflaterOutputStream, its missing a BufferedOutputStream in the same fashion the InputStreams do for reading. this causes MASSIVELY ineffecient writes using DeflaterOutputStream.write(int), creating tons of new byte[1]
22:50 < Aikar> those bytes[] appear to be causing much more allocation than BlockPositions
22:52 <+Grum> it seems to have its own buffer
22:52 <+Grum> new DataOutputStream(new DeflaterOutputStream(new ChunkBuffer())))
22:52 < Aikar> right, but thats farther down the chain...
22:52 <+Grum> the ChunkBuffer is an 8k ByteArrayOutputStream
22:52 <+Grum> there is only one place where we make a new DeflaterOutputStream and that is there
22:54 < Aikar> it has to pass through the deflation stream to get to that stream
22:54 < Aikar> memory profiler results: http://screencloud.net/v/m2Qn
22:56 <+Grum> not sure what you are making me look at
22:56 < Aikar> saying to simply inject a BufferedOutputStream before the DeflaterOutputStream in the same way you are for reads
22:56 < Aikar> so it'll never call .write(int)
22:57 < Aikar> return this.d(i, j) ? null : new DataOutputStream(new java.io.BufferedOutputStream(new DeflaterOutputStream(new RegionFile.ChunkBuffer(i,j))))
22:58 <+Grum> i'm missing where it is creating byte[]'s O.o
22:58 < Aikar> DeflaterOutputStream.write(int)
22:59 < Aikar> every single call, and .writeInt() calls it 4 times
22:59 <+Grum> yes, and how will this method suddenly change to not do that if there is a bufferedoutputstream infront of it?
22:59 <+Grum> oooh
22:59 <+Grum> hmmm
22:59 < Aikar> buffered stream will build up a buffer, then call dEflateroutputstream.write(byte[])
22:59 <+Grum> buffered will just do the byte[] and not byte ?
22:59 < Aikar> yeah
23:00 <+Grum> hmmm
23:00 < Aikar> ##java told me "they probally havent optimized it because you shouldnt be using it"
23:01 < Aikar> which will also be more effecient for the Deflater too
23:01 <+Grum> ugh
23:02 <+Grum> ok so in all honesty, i have noticed it doing 'single byte writes'
23:02 <+Grum> didn't realize this could be fixed so trivially >>>
23:02 < Aikar> lol
23:02 < yawkat> :D
23:03 < Aikar> oh your in here ;P
23:05 < Aikar> I found the source of the issue, and was about to replace it with a Deflater that re-uses a single buffer, but yawkat suggested the buffered stream instead which def is better for Deflater too
23:07 < Aikar> Grum: my next goal is to look into pooling MutableBlockPositions for the "hot" sections only, notably pathfinding appears to really churn some allocations. Thoughts there? fixing these 2 issues should drastically reduce memory allocation
23:07 <+Grum> i think nathan took a look at the pathfinding already
23:07 <+Grum> and just drastically clamped it max-length
23:07 <+Grum> without any noticable difference
23:08 < Aikar> cpu performance wise i thought? or did he improve object allocations too?
23:09 < Aikar> I've been studying GC activity for a few days now. Seeing a lot of object promotions to old that i'm pretty sure is premature... so trying to cut down on allocation to slow down GC.
23:09 < Aikar> VisualGC: http://screencloud.net/v/wL7p
23:10  * Aikar sees another FullGC about to happen :(
23:11 <+Grum> would be nice to see where these blockposes get spammed from
23:11 < Aikar> sec ill show the memory profile for that
23:11 <+Grum> hmm visualvm does it?
23:11 < Aikar> yes but makes server crash pretty fast
23:12 < Aikar> took me like 5 tries to get usable data
23:12 < Aikar> http://screencloud.net/v/4A9p overview: String im working on but that is actually my fault for using String keys for block positions with String.format("x:y:z") so i gotta fix that. 
23:13 < Aikar> now, given this was with a lot of mobs around me in order to generate activity: http://screencloud.net/v/ahgl
23:13 < Aikar> so under more production standards, other areas could be more of the %
23:14 <+Grum> mmm what created that? profiling/sampling?
23:14 < Aikar> profiling
23:14 < Aikar> gotta checkbox the stack trace option though
23:14 < Aikar> i was running with "Capture every 3"
23:15 < Aikar> maybe vanilla will be more stable in terms of crashing lol
23:15 < Aikar> could be CB stuff that makes it unstable
23:16 <+Grum> aaaah
23:16 <+Grum> that is why the stacktrace is missing
--- Day changed dim. août 30 2015
00:56 < Not-f7bb> [minecraft-data] rom1504 pushed 1 commit to 1.8 [+0/-0/±1] http://git.io/vGnhb
00:56 < Not-f7bb> [minecraft-data] rom1504 93c3d81 - add projects using minecraft-data in the readme
00:59 < Not-f7bb> [minecraft-data] rom1504 pushed 1 commit to 1.8 [+0/-0/±1] http://git.io/vGnjn
00:59 < Not-f7bb> [minecraft-data] rom1504 28a6df3 - add craftyjs in users
01:13 < nevercast> Was not aware that notified here. Nice. 
01:16 < Gjum> nevercast: several projects are notifying acually
01:17 < nevercast> Gjum, good :)
10:38 < luii> Good morning
11:08 < luii> http://hastebin.com/izinonupax.coffee what is the number on the 14th byte
11:10 < luii> well nvm i oversaw that .readUInt16BE reads 2 bytes
15:33 < LEGENDFF> anyone knows whats disabling movement keys while guis are opened in the notchian client?
15:35 < Aikar> Grum: you around?
15:35 < Aikar> I've made epic progress on memory allocation :)
15:36 < Aikar> live stream of my GC: http://www.hitbox.tv/aikar
15:38 < Aikar> patch for pooling hotspots: https://bitbucket.org/starlis/empirecraft/commits/0845a41c5704d8b932f45540309cedb7b25164c4
15:52 < Aikar> killed stream since I gotta leave, but http://screencloud.net/v/89Ao - GC's are running once per 4 MINUTES now...
15:52 < Aikar> for young gen
15:52 < Aikar> and old gen only increasing 1-2M
15:52 < Aikar> so.... yeah old gens not going to need any GC for a single day I believe
18:42 < Not-f7bb> [minecraft-data] rom1504 pushed 5 commits to 1.8 [+0/-0/±7] http://git.io/vGWix
18:42 < Not-f7bb> [minecraft-data] Gjum f3333b2 - Add all window types, some data still missing, sort by id
18:42 < Not-f7bb> [minecraft-data] Gjum 6e1965c - Add Player window
18:42 < Not-f7bb> [minecraft-data] Gjum 5a7a6bb - Add data from wiki.vg, use their names, also use numbers now (1,2 for one,two)
18:42 < Not-f7bb> [minecraft-data] ... and 2 more commits.
19:52 < Not-f7bb> [minecraft-data] rom1504 pushed 1 commit to 1.8 [+0/-0/±1] http://git.io/vGWj2
19:52 < Not-f7bb> [minecraft-data] rom1504 e1984fd - rename craftyjs
20:07 < luii> hi
20:12 < luii> how do i know what EID a user get?
20:15 < angal> EntityID?
20:16 < luii> yes
20:16 < angal> If you are client, you will receive it in http://wiki.vg/Protocol#Join_Game
20:17 < luii> in this case i am the server
20:17 < angal> Then you deside it on your own.
20:19  * angal sending EntityID 0 for players entity to each player...
20:19 < angal> Please, do not PM me.
20:19 < luii> http://minecraft.gamepedia.com/Entity this table says it is "Player"
20:24 < Fenhl> luii: that's the entity savegame ID, which specifies the type of entity
20:25 < Fenhl> EID is a unique ID for each individual entity
20:26 < Fenhl> Minecraft Wiki seems to call the savegame IDs “Entity IDs” in some places, which is confusing/wrong
20:31 < rom1504> the entity id better be unique yeah
20:31 < rom1504> idk what is going to happen if you send 0 for every entity, but it will be confusing :p
20:39 < luii> http://minecraft.gamepedia.com/The_Player i think they mean the network id 
20:39 < luii> but there only a n/a
20:59 < Not-2be> [mineflayer] rom1504 pushed 1 commit to master [+0/-0/±4] http://git.io/vGlsp
20:59 < Not-2be> [mineflayer] rom1504 3bd31f5 - use prismarine-entity, and remove doc that is now in prismarine-* modules
22:35 < Not-2be> [mineflayer] rom1504 pushed 1 commit to master [+0/-1/±0] http://git.io/vGlww
22:35 < Not-2be> [mineflayer] rom1504 6515192 - remove entity.js (forgot to remove it in last commit)
--- Day changed lun. août 31 2015
05:32 < Not-2be> [mineflayer] rom1504 pushed 1 commit to master [+0/-0/±1] http://git.io/vG8aw
05:32 < Not-2be> [mineflayer] rom1504 18f141c - the destination of unequip is not optional, produce an error if not given
07:57 <+Grum> Aikar: i'll look into it, sadly it seems that pooling might be useful :(
07:58 < Aikar> Grum: note I missed a line in my patch, let me get new diff, and I moved it into NMS
07:58 < Aikar> https://bitbucket.org/starlis/empirecraft/src/9228ba69c2f09852a1356e1e22e6d808a5d1eefd/patches/craftbukkit/0117-Pool-BlockPosition-to-reduce-memory-usage.patch?at=master
07:59 < Aikar> ive put it in many of the hotter spots, left the others alone
07:59 < Aikar> first iteration REALLY improved memory stability, but found more spots today ill push out soon
08:00 < Aikar> i mean it can still churn out 700-1200MB/s, but compared to before... leaps and bounds better. on low activity I was going minutes between
08:01 < Aikar> what I'm really noticing with peoples timing reports looks like GC activity is killing their TPS (avg tick < 50ms yet TPS loss)
08:02 < Aikar> also Grum vanilla wasn't any more stable for memory profiling.... dont know if its a VisualVM bug or something the MC code is doing
08:04 < Aikar> another place i wanna see about pooling is the backing byte arrays for NibbleArrays, those seem to attribute to byte[] usage a lot
08:23 < Aikar> Grum: another small change - i cant say with confidence on #'s, but in the region file constructor: https://bitbucket.org/starlis/empirecraft/src/9228ba69c2f09852a1356e1e22e6d808a5d1eefd/patches/craftbukkit/0116-More-effecient-RegionFile-zero-ing.patch?at=master   - its currently writing 4 bytes at a time, which is going in and out of native calls... but another place in the file your already doing this 4k block write. should speed up chunk generation zero'ing
08:24 < Aikar> also this... https://bitbucket.org/starlis/empirecraft/src/9228ba69c2f09852a1356e1e22e6d808a5d1eefd/patches/craftbukkit/0113-Use-a-Last-Access-Cache-for-getChunkAt-calls.patch?at=master   - getChunkAt has become so hot now with every single getType() method calling .getChunkAt. this small cache dropped that method off the radar. 
08:26  * Aikar hopes 1.9 can really be a massive improvement to server performance
08:37 <+Grum> lets see
08:39 <+Grum> you can do 1 more optimisation after it
08:40 <+Grum> the if right after the if you are in
08:40 <+Grum> that pads the file to a multiple of 4k
08:41 <+Amaranth> Heh, I got rid of that cache
08:59 <+Grum> Amaranth: iirc we had that cache once upon a time in bukkit and implemented it wrong so it would cause the occasional corruption
08:59 <+Amaranth> Yep and iirc I also benchmarked and couldn't find a case where it was useful
09:00 <+Amaranth> I also patched things to call getChunkAt less often
09:01 <+Grum> all getblock calls do it
09:02 <+Grum> hard to do less of those in a significant way? or did you find a spot whre it was significant?
09:02 <+Amaranth> Well I also had a super fast HashMap in there so that probably helped
09:03 <+Amaranth> But iirc the worst hot spots for getBlock only actually cared about blocks in a single chunk so could be patched to just look up the chunk once and call getBlock on it
09:03 <+Grum> but that only works if you can guarantee to not step outside of it?
09:03 <+Grum> which is not so easy to do
09:04 <+Amaranth> And I had a chunk neighbor loaded cache which iirc was most calls to getChunkAt because lighting
09:04 <+Grum> yeah lighting is still atrocious
09:04 <+Grum> that should be sitting at chunksection level
09:04 <+Grum> so it can just access raw data
09:04 <+Grum> and on the borders get passed in a neighbour and access its raw data
09:05 <+Amaranth> This was also 1.7 so I don't know if you've done things to make it worse since :P
09:05 <+Grum> haha some people have touched the lighting code yeah
09:05 <+Amaranth> You should make ChunkSection have 6 Optional<ChunkSection> in it: top, bottom, left, right, front, back
09:06 <+Amaranth> Optional because the edge of the world, of course
09:06 <+Grum> That would require populating
09:06 <+Grum> and that means quite some more legwork to unload something
09:06 <+Amaranth> Eh? No populating? Just what you do now but keep pointers
09:06 <+Grum> and getting that wrong in whatever way == memory leak :)
09:07 <+Amaranth> And unload would just poke your neighbors to remove you from them
09:07 <+Amaranth> And if you leak you'd at most leak two rows
09:07 <+Amaranth> One row for X and one for Z
09:08 <+Amaranth> Well, I suppose you could leak worse
09:08 <+Amaranth> But then you'd be really screwing it up
09:08 <+Grum> haha yeah
09:08 <+Grum> not sure what would benefit from it right now
09:08 <+Amaranth> It's not very complicated, could probably drop those in to your code base bug free in a day
09:09 <+Grum> yeah but nothing would be using it :)
09:09 <+Amaranth> Making use of them would require moving everything from Chunk to ChunkSection, basically :P
09:09 <+Amaranth> And then porting them to use it
09:09 <+Grum> yeah
09:09 <+Amaranth> But you're the one that said ChunkSection
09:09 <+Grum> which is the not so trivial part
09:09 <+Amaranth> So if you want something easier put them on Chunk
09:09 <+Grum> I'm still trying to peel apart level/levelchunk/levelchunksection
09:09 <+Amaranth> Easier to implement, easier to use
09:10 <+Grum> so much prods as if it is a single class
09:10 <+Amaranth> I feel like you should just not have getBlock on Level
09:10 <+Amaranth> Everything should need to get the chunk(s) and query them
09:11 <+Grum> I think that anyone knowing about chunks except storage is probably wrong
09:12 <+Amaranth> Except performance is shit if you think like that
09:12 <+Amaranth> You've got to get a super fast hashmap which you definitely don't have right now and you've got to figure out some sort of caching and you're still not doing great
09:12 <+Grum> Not necessarily 
09:13 <+Grum> Why is the current hash map slow? 
09:14 <+Amaranth> I don't even remember how it works :P
09:14 <+Grum> I know the hashing is pisspoor 
09:14 <+Amaranth> But I just got someone coming to me to ask if they could use mine because they ran in to a case where half their CPU time was LongHashMap.getValueForKey() or whatever MCP names it
09:16 <+Grum> What did yours do? Open addressing? 
09:16 <+Amaranth> Yeah, so does yours
09:17 <+Amaranth> Mine is robin hood hashing though
09:17 <+Amaranth> Which generally means really fast lookups at the expense of slower inserts and deletes
09:17 <+Amaranth> But MC is like 99.999% lookups so...
09:17 <+Grum> Nah ours is not open addressing afaik. Those typically do not use entry objects 
09:18 <+Amaranth> They can, mine does
09:18 <+Grum> Expensive memory wise then :(
09:18 <+Amaranth> Better cache or something apparently
09:19 <+Amaranth> I benchmarked it, shocking Entry objects came out slightly faster
09:19 <+Amaranth> Your main problem is probably your hash though
09:19 <+Amaranth> Mine should still be faster even if you had a better cache but you'd be doing a ton better
09:19 <+Amaranth> s/cache/hash/
09:21 <+Amaranth> I think your default load factor is too high too although this might just be outdated
09:21 <+Amaranth> Open addressing shouldn't have a load factor higher than 0.5
09:22 <+Amaranth> Because the more empty slots you have the shorter your distance from ideal slot to matching on positive lookups and the faster you hit an empty slot on negative lookups
09:23 <+Amaranth> Grum: https://gist.github.com/amaranth/a16bc02e18f577ab4a91 use that for your hash (it's public domain from murmurhash) and change your load factor and you should have a much faster LongHashMap
11:17 <+Grum> iirc using the murmur's mixing method should provide enough entropy to do 0.7/0.8 loadfactors?
12:29 < gurun> Hmm, here we go again. Wonder if MCPE will follow suite again https://twitter.com/Dinnerbone/status/638282256151375872
13:11 < TobiX> gurun: Some poeple tweeted it's already like this on console?!?
13:12 < gurun> used to be like this on PE too
13:12 < gurun> but not now
14:15 < ScruffyRules> Dinnerbone, The pushing of someone looks really delayed.
14:18 <+Amaranth> Grum: Not likely. It'll do better at high load factors because the mixing is better but open addressing still gets faster the lower the load factor is
14:20 <+Amaranth> Robin hood hashing is supposed to perform well at 0.7 or 0.8 which is usually where you put chained systems but in my benchmarks it still got noticeably faster down to 0.5
14:38 <+Grum> Amaranth: how would you find an entry if you roundrobin? :)
14:39 <+Amaranth> Grum: If you mean robin hood you store key, value, and distance from ideal position
14:40 <+Amaranth> So if you find something that isn't what you're looking for but is in a more ideal position than your thing would be if it were in this position you know your thing isn't in here
14:40 <+Amaranth> Or if you find an empty slot like usual
14:40 <+Amaranth> Or if your distance is higher than the maximum distance for the entire map
14:56 < jast> for a high load factor, your best bet is probably chaining
14:56 < jast> or, you know, making your hash table bigger
15:03 <+Amaranth> jast: If your hash table is bigger that means your load factor is smaller
15:05 < jast> I'm aware...
17:00 < Aikar> Amaranth (and re Grum) - so many things do world.getType(blockposition) now for every time it needs to check a type, and that getType calls .getChunkAt(pos). so everything is bombarding getChunkAt. I was doing sampling, and getType was dominating. I believe the getChunkAt was inlined into getType, as when I added that cache... it disappeared from hotspots entirely. And it also just makes sense.... Calling thousands of getChunkAt on the same chunk as the 
17:00 < Aikar> previous call, skipping the hash lookup is an obvious save.
17:01 <+Amaranth> Should stick the cache in the hashmap, less likely to miss a spot to invalidate it
17:02 <+Amaranth> It should be a useful optimization for a hashmap to have anyway
17:02 < Aikar> hmm, not a bad idea
17:02 < Aikar> but actually, its only removed from the map in one of the places iirc, yet i also want to expire the cache for unload queues
17:03 < Aikar> so would have to add the expiration to the unload queue and chunk map
17:04 <+Amaranth> Just store lastKey and lastKeyIndex, set lastKeyIndex to -1 if missing, and update it on lookup, insert, and remove
17:04 < Aikar> Amaranth, and were you talking about CB's version of LongHashMap ?
17:05 <+Amaranth> The one CB ended up with is my old really simple chaining one that doesn't even do resizing
17:05 < Aikar> I noticed it is responsible for a good bit of the Object[] allocations
17:05 <+Amaranth> Only once, basically
17:05 < Aikar> for each bucket it does Object[8]
17:06 <+Amaranth> No resizing so the only way to get churn on it is if you're creating a lot of maps
17:06 <+Amaranth> Oh yeah and it does resize those to fit
17:06 <+Amaranth> But you can't be allocation free so... *shrug*
17:06 < Aikar> right, im not trying to remove it all, but to least find the really hot allocations
17:06 < Aikar> cause 1GB/s is pretty crazy
17:07 <+Amaranth> That being a hot spot for allocations is just telling you you are beating on hashmaps too much
17:07 < Aikar> I'm not saying its the hotspot
17:07 <+Amaranth> Probably the one in World
17:07 < Aikar> I'm havingt trouble finding the Object[] ones
17:07 < Aikar> I just did a heap dump and noticed they were part of the live data set
17:07 <+Amaranth> Ah
17:07 < Aikar> and that those 8 arrays are 92~ bytes
17:07 < Aikar> which is around what I saw though for object churn
17:08 < Aikar> cant do a full memory profile in prod :/
17:08 <+Amaranth> Well if you have an insert heavy workload you'll get a lot of churn on them
17:08 <+Amaranth> Otherwise you should only churn on them if you're churning LongHashMaps somewhere
17:08 < Aikar> well people moving around ,teleporting in town (I dont allow teleporting in survival world), will be loading lots of chunks
17:08 <+Amaranth> iirc the only two uses are ChunkProviderServer and World
17:09 <+Amaranth> Right but if you have an insert heavy load you're going to have churn
17:09 <+Amaranth> It's just a fact of life
17:09 <+Amaranth> Creating things requires memory
17:09 < Aikar> 3k~ chunks for 20~ players atm
17:10 < Aikar> you know, for a school day.... 168 playes on at 11am is kinda weird o.o
17:10 <+Amaranth> Average of about 7 players per group of them
17:10 <+Amaranth> Assuming default view distance
17:10 <+Amaranth> But of course not, probably more like view distance of 3
17:10 < Aikar> I'm at 5 and 7 VD I think
17:10 < Aikar> oh 4 and 6
17:11 < Aikar> 4 for town, 6 for survival worlds
17:11 <+Amaranth> Less than 8 and I probably wouldn't even stay connected
17:11 <+Amaranth> Like, I don't even care if you only tick 4 although that would also be sad
17:11 <+Amaranth> I just want to see things
17:11 < Aikar> heh, high VD in town destroys perf, because theres soooo many entities
17:11 < Aikar> 1 player being logged in loading 20 peoples animal farms
17:12 <+Amaranth> Loaded doesn't mean ticking
17:12 < Aikar> yeah it does, EAR helps a ton but still %5% tick rate
17:12 < Aikar> and they can also trigger immunity
17:12 < Aikar> I developed EAR because of my town issue
17:12 < Aikar> 1 player can be building on their plot, yet all their neighbors animals are loaded but 'unused'
17:13 < Aikar> though im trying to optimize perf as best as i can so i can raise it to 5 at least
17:13 < Aikar> i think i've probally acheived that goal
17:18 < Aikar> Amaranth, but you dont really 'play' anymore do you :P I'm not after lookers :P
17:18 < Aikar> not actually received any feedback re view distance in like over a year
17:27 < Aikar> analyzing my GC logs, out of 6~GB  Eden, averages 15-35MB~ Surviving objects, which then averages to 500k-5M usually that survives to Age 15 for promotion to OldGen
17:28 < Aikar> but this is with me actually tuning and optimizing to get this desirable results. I bet others are thrashing GC to all hell. 
17:51 < LEGENDFF> was working on a chat client, my parser and all seems to be working, however the very first chat packet is always broken json, looking like
17:51 < LEGENDFF> {"extra":[{"color":"white","text":" "},{"color":"white","text":" "},{"color":"dark_blue","text":" "},{"color":"black","te
17:52 <+Thinkofdeath> that looks like you aren't reading the length prefix correctly
17:52 < LEGENDFF> yea thought so too, but its just the first one, and the packet after is also alright
17:53 <+Thinkofdeath> pastebin your code?
17:56 < LEGENDFF> that should be the relevant parts, http://pastebin.com/HdCM1CAp
18:01 < LEGENDFF> here is a snippet of the payload from some chatpackets produced with new String(payload, Charset.forName("UTF-8")) http://pastebin.com/F0HjuWKX
18:58 < Aikar> Amaranth, got a link to your improved LongHashMap?
18:59 <+Amaranth> The robin hood hashing one? Nope
19:48 < angal> I have some... Poorly related question. Is there are any http repository, that contians content of https://repo.spacehq.org/content/repositories/ ?
19:56 < Welite> can anybody explain me packet compression introduced in 1.8 ? when should I send compressed packet and when uncompressed (from client to server) and if I write packet lenght 0 it means that it is uncompressed so client can always choose to compress or not ?
19:59 < Welite> anybody please ?
20:03 < angal> You are client?
20:03 < Welite> yes
20:04 < Welite> angal: ^
20:05 < angal> You alowed to send compressed packet only, when packet uncompressed size >= size set in Set Compression.
20:06 < angal> Packet Length can't be 0. it at least 1 always. If Data Length == 0, then the packet not compressed.
20:08 < Welite> angal: packet lenght must be > 0, but what happens if I send 0 in data lenght ?
20:09 < angal> You should send packet uncompressed.
20:09 < Welite> well and how can I know if the servers wants it compressed or not ?
20:10 < angal> Wait for Set Compression packet.
20:10 < angal> After it you allowed compress packet, which size greater than specified in that packet.
20:11 < Welite> so after compression packet all packets has to be compressed regardless ont the size of the packet ?
20:12 < Welite> or the compression packet is sent from server for every single packet individually ?
20:14 < angal> All packet are send in "compression format" and if Data Length != 0, they are compressed.
20:15 < Welite> lol mc protocol is really one big mess
20:24 <+Grum> Aikar: where did you see the getType()? cpu time?
20:32 < LEGENDFF> Welite: http://wiki.vg/Protocol#Set_Compression, http://wiki.vg/Protocol#Set_Compression_2, enable compression, you can compress all packets that are bigger than the threshold set in there, and all packets that you receive with data length != 0 are compressed
20:33 < LEGENDFF> notchian std threshold is 256 iirc
20:40 <+Grum> notch hasn't coded jack shit on minecraft since 29feb 2012
20:50 < Fenhl> we'll probably forever call it notchian anyway 
20:59 <+AndrewPH> rolls off the tongue better than mojangian
21:13 < johni0702> angal, if you haven't found it by now: http://maven.ensemplix.ru/artifactory/spacehq/
21:14 < angal> Ya. Thanks!!!
21:36 <+Grum> Welite: the protocol is not made for other people to be 'read easily' it was made to be read absolutely trivially by our setup
21:41 <+Grum> I guess that doesn't really make it that easy for others :/
22:01 < Welite> Grum: why you are so againts 3rd developers ?
22:01 < dx> Grum: please disregard the bait
22:01 < dx> the >=1.7 protocol is just fine, anyone who complains clearly didn't know what was there before
22:08 < gamingrobot> dx: agreed
23:03 < shoghicp> I remember when you had to parse everything in the correct way to get to the next packet :)
23:12 <+Thinkofdeath> ah the good old days
23:54 < jython234> hello, I noticed that in 15w35b the chunk sending format changed to some sort of VarInt array. The description here: http://wiki.vg/SMP_Map_Format#Data is not quite clear enough, I still don't understand how the array is sent, or what's in it
--- Day changed mar. sept. 01 2015
00:33 < barneygale> http://quarry.readthedocs.org/en/develop quarry finally has some documentation, if anyone is interested :)
00:33 < barneygale> (quarry is a python protocol library)
01:34 < Aikar> Grum, sampling with VVM on production server
01:34 < Aikar> can we drop java6 in 1.9 and move to full on NIO for IO ops :3
01:35 < Aikar> GSP's WILL update java if mojang themselves drop the support.
01:35 < Aikar> and its so rarely used already as is
01:36 < Aikar> we believe in you Grum :D you can convince rest of team to drop java6 (and if you were already planning it, take all the credit)
01:47 <+SinZ> doesn't mojang only support their own java they ship with the vanilla client
01:59 < WizWiz> Could anyone tell what the rightclick packet is?
01:59 < WizWiz> That client sends
01:59 < WizWiz> I mean like rightclicking when you are in the hub of a server
02:24 < Aikar> TIL MC has a in built concept of "right clicking action on a hub"
02:31 < roblabla> dx, I liked pre-1.7 protocol so much better. It was so much fun having one small packet wrong and suddenly your whole client goes out of whack :P
02:34 < roblabla> (to be perfectly serious though, I'd like to know what led to the protocol becoming stateful, allowing packets to reuse the same packet ids and stuff.. that's the major thing I dislike about the >= 1.7 protocol)
04:54 < Not-f7bb> [SpockBot] gamingrobot pushed 8 commits to master [+0/-0/±14] http://git.io/vGgqg
04:54 < Not-f7bb> [SpockBot] nickelpro 61a4338 - Complete rework of Physics plugin
04:54 < Not-f7bb> [SpockBot] nickelpro e8b6c3a - Remove unnecessary prints and import from physics
04:54 < Not-f7bb> [SpockBot] nickelpro cb2a9af - Fix python2
04:54 < Not-f7bb> [SpockBot] ... and 5 more commits.
04:55 < nickelpro> roblabla: The vanilla client has no concept of packet ids
04:56 < nickelpro> It just registers packets and the ids are wherever they happen to land
05:20 < Not-f7bb> [SpockBot] gamingrobot pushed 4 commits to master [+6/-0/±19] http://git.io/vGg30
05:20 < Not-f7bb> [SpockBot] Gjum 233cc3b - Move constants from plugins to mcdata.constants
05:20 < Not-f7bb> [SpockBot] Gjum 7b19c3f - Do not use `import *`
05:20 < Not-f7bb> [SpockBot] gamingrobot 2bae9cd - Fixed merge conflict
05:20 < Not-f7bb> [SpockBot] gamingrobot 38729b1 - Merge branch 'Gjum-constants-to-mcdata'
06:08 <+Grum> roblabla: how do you mean 'stateful' ?
06:09 <+Grum> we just have no packet ids defined in our end in the code, they get assigned based on bootstrap order
06:11 < Fenhl> Grum: I'm assuming stateful as in there's Handshaking, Play, Status, and Login states
06:12 < Fenhl> though I don't see how that's a bad thing
06:12 <+Grum> yeah to me that just makes it better
06:12 <+Grum> rather than being always required to answer to any packet, we now demand intent at the door
06:24 <+AndrewPH> yeah loads of games do that
18:18 < SkylordRedstone> hello
18:21 < barneygale_> I should write a minecraft username generator one day
18:22 < SkylordRedstone> :3
18:24 < SkylordRedstone> can anyone help me with a small problem I'm having
18:24 < SkylordRedstone> to do with the minecraft protocol
18:25 < barneygale_> what's the problem
18:26 < SkylordRedstone> okay basically I'm trying to write a big thing, but starting out in steps, so right now I'm trying to get server list ping working
18:26 < SkylordRedstone> basically writing a server-side app in node that responds to server list pings (will eventually forward connections)
18:27 < SkylordRedstone> I've managed to read and interpret the handshake packet, but for some reason when I write the Response packet the client doesn't respond
18:27 < SkylordRedstone> am working in node.js
18:28 < barneygale_> Can you give a dump/hexdump of the packet you send, and/or the code you're using?
18:28 < SkylordRedstone> sure, gimme a sec
18:29 < SkylordRedstone> here's code http://hastebin.com/hoqeqikose.avrasm
18:30 < SkylordRedstone> output looks like http://hastebin.com/ediyodewil.xml
18:30 < SkylordRedstone> the first buffer is the handshake packet
18:31 < SkylordRedstone> the json after is the parsed form of the handshake packet
18:31 < SkylordRedstone> and I think the second buffer is the buffer'd form of the response json
18:31 < SkylordRedstone> I probably have mucked around with the code a bit since
18:31 < SkylordRedstone> the third buffer is the legacy ping
18:32 < SkylordRedstone> which minecraft sends if modern ping fails I believe
18:32 < SkylordRedstone> I think the problem is that node doesn't prefix strings with their length, but I could be wrong
18:35 < SkylordRedstone> well this is strange
18:37 < SkylordRedstone> its weird, because if I write the buf object by itself, not a lot happens
18:40 < SkylordRedstone> also sometimes I get a buffer that just contains 00 01
18:42 < SkylordRedstone> also the client is MEANT to send an empty request packet, but I don't seem to receive it at all
18:47 < roblabla> SkylordRedstone, just saying, if you're trying to do minecraft stuff in nodejs, there's already a minecraft packet serialization library that can abstract all that.
18:48 < roblabla> https://www.npmjs.com/minecraft-protocol it is very much active (I am the maintainer0
18:49 < SkylordRedstone> yeah I saw that earlier
18:49 < SkylordRedstone> I was making my own mainly to learn about how the minecraft protocol works
18:49 < roblabla> ok, fair enough :)
18:49 < SkylordRedstone> any ideas what my problem might be? :3
18:51 < roblabla> SkylordRedstone, you're not parsing the packet length varint or the packet id varint ?
18:51 < roblabla> every packet is prefixed with those
18:51 < SkylordRedstone> oh that's probably it
18:52 < roblabla> yeah
18:52 < SkylordRedstone> hmmm
18:52 < roblabla> if you want a nodejs varint reader : https://github.com/PrismarineJS/node-minecraft-protocol/blob/master/src/datatypes/utils.js#L13
18:52 < roblabla> I don't think it's possible to tell packet to read varints natively
18:53 < roblabla> I wanted to use packet in NMP at one point but it lacks some datatypes and it doesn't look like we can easily add them
18:53 < roblabla> :(
18:53 < SkylordRedstone> packet is interesting
18:53 < roblabla> it is ^^
18:54 < SkylordRedstone> hmm is there a way to write to the start of the buffer
18:55 < roblabla> create a new buffer that is the length of the existing buffer + the size of the addition ?
18:55 < roblabla> more simple : use Buffer.concat
18:55 < SkylordRedstone> ah
18:55 < SkylordRedstone> good call
18:58 < SkylordRedstone> for some reason it's writing the length as 37 61 rather than 7a
19:01 < roblabla> SkylordRedstone, what's your code now :P
19:01 < SkylordRedstone> ok even if I forcefully write 7a it fails
19:02 < SkylordRedstone> this is relativley frustrating XD
19:03 < roblabla> I know that frustration :P
19:03 < roblabla> SkylordRedstone, so you read the handshake properly now ?
19:04 < SkylordRedstone> uh
19:04 < SkylordRedstone> the handshake has always been being read, packet manages to read it
19:05 < SkylordRedstone> I just can't manage to write the response
19:05 < roblabla> SkylordRedstone, I don't think you're reading it properly
19:05 < roblabla> I'm fairly sure if you look at it, you get messed up values ;)
19:06 < SkylordRedstone> { version: 47, host: [~snip array of bytes that translate to string of host~], port: 25565, state: 1 }
19:06 < SkylordRedstone> that's what packet gives me
19:12 < roblabla> so you're reading the packet length and id now ?
19:12 < SkylordRedstone> oh I ignore the packet id at this point
19:13 < roblabla> right ok
19:13 < SkylordRedstone> when I'm reading
19:13 < SkylordRedstone> reading is fine
19:13 < SkylordRedstone> its writing that's the problem
19:13 < SkylordRedstone> writing the Response packet
19:13 < SkylordRedstone> which contains a String JSON object
19:14 < roblabla> you need to send the packet id
19:14 < roblabla> you're not doing this
19:14 < SkylordRedstone> which should just be 0x00 right?
19:14 < SkylordRedstone> you can just flame me if I'm wrong
19:14 < SkylordRedstone> im sending
19:14 < SkylordRedstone> Buffer <00 7a 7b ...>
19:15 < roblabla> client sends handshake, then send ping request
19:15 < SkylordRedstone> continues on with the bytes of the JSON string
19:15 < roblabla> server sends ping response
19:15 < roblabla> client sends timing request
19:15 < roblabla> server sends timing response and shuts down stream
19:15 < roblabla> this is how a ping works in minecraft
19:15 < SkylordRedstone> yup
19:15 < SkylordRedstone> im reading off wiki.vg
19:15 < roblabla> I think you're not waiting for the client to send the ping request which might already throw the client off track
19:15 < SkylordRedstone> possible.
19:16 < roblabla> If you want to keep it stupidly simple, you could just add the packetId of the ping request to the handshake packet (so add an x8/b8 - don't know which - at the end of handshake)
19:17 < SkylordRedstone> x8 is ignore
19:17 < SkylordRedstone> b8 is single byte, bigendian
19:17 < roblabla> make that two x8/b8, since there's also the packet length
19:17 < roblabla> that way handshake event will only be triggered once the packet has sent you the ping request along with the handshake :P
19:17 < roblabla> (it's a bit hacky but yeah)
19:18 < SkylordRedstone> oh that might work
19:18 < SkylordRedstone> does packet do that?
19:18 < roblabla> do what ?
19:18 < SkylordRedstone> interpret two packets and look against one rule
19:19 < roblabla> ah I think you're misunderstanding something
19:19 < roblabla> c.on("data") isn't garanteed to contain an entire minecraft packet
19:19 < roblabla> it may contain multiple packets, it may contain only half of one packet
19:20 < SkylordRedstone> oh right
19:20 < roblabla> it's a tcp stream, so there's no system of "packet"
19:20 < roblabla> it's only one big continuous stream of bytes
19:20 < SkylordRedstone> yeah
19:20 < SkylordRedstone> #derp
19:20 < roblabla> The question is does packet have a streaming api, so you could just pipe your stream to it
19:21 < SkylordRedstone> I assume that parser.parse handles everything correctly
19:22 < roblabla> doesn't look like it does
19:22 < roblabla> hnng
19:22 < SkylordRedstone> welp XD
19:23 < SkylordRedstone> kinda considering switching to java for this
19:23 < SkylordRedstone> might be easier
19:23 < SkylordRedstone> node is a weird language
19:23 < roblabla> well there's a very simple way to keep your current thing
19:23 < roblabla> nodejs has this awesome thing in streams
19:23 < roblabla> you can compose them
19:23 < roblabla> so you take your TCP stream, you pipe it through a "transformer"
19:23 < roblabla> and then pipe it through another
19:23 < roblabla> etc
19:23 < SkylordRedstone> ye
19:24 < SkylordRedstone> anyway I like java more so TO JAVA!
19:24 < SkylordRedstone> XD
19:24 < roblabla> It's a bit similar to what netty does
19:25 < roblabla> what you could do is just do a simple "splitting" transform stream that reads the varint, and then doesn't emit data event unless it is exactly one packet
19:25 < roblabla> https://github.com/PrismarineJS/node-minecraft-protocol/blob/master/src/transforms/framing.js this is what this does (sorry for the weird class syntax)
19:25 < SkylordRedstone> you using ES6?
19:25 < roblabla> yup
19:25 < SkylordRedstone> 'tis nice
19:25 < roblabla> well sometimes
19:25 < SkylordRedstone> can't wait until it's actually implemented XD
19:25 < roblabla> the codebase is pretty old so it's sporadic :P
19:25 < SkylordRedstone> JS is kinda a mess of a language XD
19:26 < roblabla> It's not so messy once you start using es6
19:26 < roblabla> and polyfills
19:26 < roblabla> well JS itself is messy
19:26 < roblabla> nodejs fixes the mess though
19:26 < SkylordRedstone> kinda
19:26 < SkylordRedstone> callback hell becomes a bit messy
19:26 < roblabla> es6 fixes that :P
19:27 < roblabla> NMP doesn't have much callback hell for example
19:43 < Aikar> too bad async/await didnt make it to es6
19:43 < Aikar> solves the problem even better
19:43 < Aikar> I currently use a system that is very close called Streamline 
19:44 < Aikar> var foo = bar(baz, _);  _ = callback replacement
19:44 < Aikar> then it transpiles into a CB version, and has options to use fibers or generators instead of CB rewriting
19:44 < roblabla> Aikar, I use async/await with babel. Transforms into generators, works well
19:45 < Aikar> roblabla, oh are they in babel?
19:45 < Aikar> ive only just got started with babel
19:45 < roblabla> yup, you just have to enable experimental features
19:45 < Aikar> ah
19:45 < Aikar> thats why i didnt see it then
19:45 < Aikar> i was just looking at stable stuff
19:45 < roblabla> and it uses promises
19:46 < roblabla> I don't think there's an option to transform into callbacks sadly :(
19:46 < roblabla> https://github.com/lukehoban/ecmascript-asyncawait
19:46 < Aikar> well the downside to CB transformation is keeping stack info the same, streamline generates a lot of ugly code to keep stacks lined up
19:46 < roblabla> oh wait fail
19:46 < roblabla> https://babeljs.io/docs/advanced/transformers/
19:47 < roblabla> under es7, a lot of those are very useful
19:47 < roblabla> es7.functionBind for instance is sooo useful
19:47 < roblabla> and trailingFuncionCommas is nice too
19:47 < roblabla> https://github.com/zenparsing/es-function-bind
19:48 < Aikar> so it takes LHS of :: and passes it to map.bind(lhs ?
19:49 < Aikar> does seem nice to provide native chaining to many datasets
20:03 < SkylordRedstone> why is the handshake packet prefixed with 16
20:04 < SkylordRedstone> my handshake packet is <Buffer 0f 00 2f 09 6c 6f 63 61 6c 68 6f 73 74 63 dd 01 01 00>
20:04 < LEGENDFF> old client?
20:04 < SkylordRedstone> nope, 1.8.8
20:04 < SkylordRedstone> old client is prefixed with FE anyway
20:05 < LEGENDFF> oh thats the size
20:06 < SkylordRedstone> ohhhh it prefixes with size
20:06 < SkylordRedstone> well done me
20:23 < roblabla> Aikar, .map(::console.log)
20:23 < roblabla> instead of .map(console.log.bind(console)
20:23 < roblabla> :P
20:26 < roblabla> the idea is that libraries like underscore/lodash can be rewritten so that you use thame like []::slice, []::filter, etc... taking the argument as this
22:00 < SkylordRedstone> this is frustrating
22:03 < SkylordRedstone> size of buffer is 124
22:03 < SkylordRedstone> the first byte I send is 7c because that should be the length
22:07 < SkylordRedstone> OH OF COURSE
22:08 < SkylordRedstone> MUAHA!
22:10 < LEGENDFF> dont forget that the size also includes the packet Id^^
22:11 < SkylordRedstone> yeah, I knew that, but I was setting my buffer size to be too small, so data was being cut off
--- Day changed mer. sept. 02 2015
04:05 < AlphaBlend> regarding the lead breaking issue prior to 1.8 (as it was fixed in a latest snapshot), how was it fixed, so i could possibly add a fix to my server if possible?
04:05 < AlphaBlend> prior to 1.9*
05:49 < conji> Evening folks. Been a while.
05:49 < conji> So I have a question about chunk data over wire.
05:50 < conji> What the heck is going on with block IDs? How it was explained on the site doesn't quite click in my head.
05:54 < Not-f7bb> [SpockBot] gamingrobot pushed 12 commits to master [+2/-0/±20] http://git.io/vGKiT
05:54 < Not-f7bb> [SpockBot] Gjum 61bdb10 - Add minecraft_data to install_requires in setup.py and tox.ini
05:54 < Not-f7bb> [SpockBot] Gjum 205fde5 - Make inventory.py pass flake8
05:54 < Not-f7bb> [SpockBot] Gjum 25b7b8f - Add mcdata.windows
05:54 < Not-f7bb> [SpockBot] ... and 9 more commits.
05:58 < jython234[away]> conji: I'm looking for an explanation too
05:59 < conji> It's kind of clicking the more I read into it.
05:59 < conji> I'm just seriously "wtf"ing in my head if what I'm thinking is right.
06:01 < jython234[away]> The 1.9 stuff, or the two byte thing?
06:01 < conji> The 1.9 stuff.
06:01 < conji> Two byte is simple. I've had that working for forever.
06:01 < jython234[away]> Yeah
06:01 < jython234[away]> But varint array?
06:02 < jython234[away]> Never heard of that
06:02 < conji> I kind of have, but it's a terrible choice.
06:02 < conji> I don't understand why we need to send possible states.
06:02 < jython234[away]> Limited my project from the pc angle
06:02 < conji> yeah, same.
06:03 < conji> How does the client not know what states a block can be in?
06:03 < jython234[away]> Ikr
06:03 < conji> Ugh. 
06:03 < jython234[away]> I might take a crack at it tomorrow if I can 
06:04 < conji> I'm trying to right now :(
06:04 < conji> It's such a waste of resources to figure out what identifier is where
06:04 < conji> and to do for each chunk
06:04 < jython234[away]> Yeah
06:04 < conji> for each player update
06:05 < jython234[away]> Well if you find anything, I'd be great if you could let me know
06:05 < conji> Hey, add my Skype so we can figure this out together?
06:05 < jython234[away]> For now, bed :)
06:05 < conji> justin_cox_bozt
06:05 < jython234[away]> It's almost midnight, gotta sleep
06:05 < jython234[away]> Night
06:06 < conji> Aight
07:21 <+Grum> <conji> I don't understand why we need to send possible states. <-- which possible states?
07:26 <+Grum> Ah, read a bit further back
07:26 <+Grum> conji: the format to send chunks is the same as it is held in memory now, which means that it is different than before
07:27 <+Grum> conji: until a certain amount of blocks the data get stored using a per-section-palette
07:27 <+Grum> conji: because of that the palette is now part of the data send over the wire
10:21 < Not-f7bb> [SpockBot] gamingrobot pushed 2 commits to master [+0/-0/±4] http://git.io/vG6zL
10:21 < Not-f7bb> [SpockBot] gamingrobot 0ee35a4 - Updated to newest python-minecraft-data
10:21 < Not-f7bb> [SpockBot] gamingrobot 4a2aa50 - Merge pull request #96 from gamingrobot/mcdata-upgrade
11:12 < Not-f7bb> [SpockBot] gamingrobot pushed 1 commit to master [+0/-0/±1] http://git.io/vG6Qo
11:12 < Not-f7bb> [SpockBot] gamingrobot 123bf1c - Update README.rst
11:13 < Not-f7bb> [SpockBot] gamingrobot pushed 1 commit to master [+0/-0/±1] http://git.io/vG6Qb
11:13 < Not-f7bb> [SpockBot] gamingrobot d5107aa - Update README.rst
11:13 < gamingrobot> sorry
13:41 < nickelpro> Never apologize gamingrobot, show #mcdevs your dominance
13:41 < nickelpro> Those one line ReadMe changes are of crucial importance to the community
13:42 < roblabla> think of the children !
13:42 < roblabla> If they don´t read those 3 line changes, what would happen to them !
13:42 < roblabla> :3
13:49 < XorBoole> hmm, a new mac launcher
13:49 < XorBoole> I wonder if it blends
14:05 < Gjum> no it launches
14:42 < nickelpro> That's more than the latest launcher does on my Arch Linux install. I can't launch anything after 1.8.1, too lazy to debug
15:42 < StarFan> Hello I have a question about Set Compression packet, when is this packet sent ? Because I received 0x03 3 times after successful login so this packet is sent after every packet or when ?
15:45 < barneygale_> StarFan, my understanding is that you'll only receive it once, during login
15:46 < StarFan> barneygale_ yea but I received it 3 times, for the first time it sends me number like 70 or 120 and later it sends me 0 and again one more 0
16:26 < StarFan> why I always receive 70 as a compression threshold when I have 256 in server properties ?
16:59 < roblabla> StarFan, 0x70 is 256 decimal ?
16:59 < roblabla> oh wait no it isn't
16:59 < roblabla> facepalm