16:59  * roblabla is tired
16:59 < roblabla> StarFan, vanilla server ?
17:00 < StarFan> roblabla, I tried it on bungeecord
17:01 < StarFan> And if I try it directly to the hub server it says threshold 0
17:01 < roblabla> maybe bungeecord is messing with the compression threshold ?
17:02 < StarFan> I have just downloaded latest version of bungeecord
17:02 < StarFan> So how it can be messy ?
17:03 < roblabla> well nevermind, looked through the source of bungeecord, it doesn't look like it's changing the compression value
17:06 < StarFan> Well, maybe I did something wrong... After successful login (server sent me 0x02) I listen for 0x03 from server is that right ?
17:08 < StarFan> roblabla ^
17:10 < rom1504> you need 0x46 too I think
17:11 < roblabla> StarFan, without the code it's hard to know
17:11 < roblabla> oh
17:11 < roblabla> StarFan, 0x03 will arrive before 0x02
17:11 < roblabla> 0x02 is the state transition packet
17:12 < StarFan> roblabla yay thanks I will try it :)
17:12 < roblabla> StarFan, http://wiki.vg/Protocol#Set_Compression_2 and http://wiki.vg/Protocol#Set_Compression
17:13 < roblabla> there are two places the server can set the compression, one in LOGIN state (before 0x02 arrives) and one in play state (after 0x02 arrives)
17:15 < StarFan> Well I still receive 70
17:16 < StarFan> May I send you my code (in java) ?
17:17 < roblabla> sure
17:17 < roblabla> put it on pastebin or something
17:17 < StarFan> yea give me a sec
17:21 < StarFan> roblabla, http://hastebin.com/ijawoxotuc.avrasm
17:30 <+Thinkofdeath> bungeecord sets the compression threshold to the value of the first server
17:31 <+Thinkofdeath> because of that it wont be sent during login but instead it'll use the one in the Play state
17:37 < barneygale_> I thought "set compression" in play mode was useless, as the server couldn't tell when the client actually switches the threshold
17:39 < StarFan> Thinkofdeath so it will be sent as 0x46 packet ?
17:39 <+Thinkofdeath> StarFan: yes
17:39 < StarFan> Ok thanks
17:40 <+Thinkofdeath> barneygale_: its sent just before the Join Game packet so in theory its fine
17:41 <+Thinkofdeath> the play one is mostly useless because sending it a second time or sending it after the login one crashes the client
17:41 < XorBoole> Thinkofdeath feature?
17:41 <+Thinkofdeath> at this point yes
17:42 <+XorBoole> why does nickserv insist on unidenting me
17:42  * XorBoole stabs nickserv
17:42 <+Amaranth> phew, too much java, I'd forgotten how finicky it can be to keep track of memory
17:42  * XorBoole pushes rust in Amaranth's general direction
17:43 <+Amaranth> That's what I'm working with
17:43 <+XorBoole> back at school, one of my friends is apparently buds with the rust people and he won't shut up about it
17:43 <+Amaranth> So at least I get compile errors instead of crashes but that doesn't make it any easier to figure out how to fix it :P
17:43 <+XorBoole> "so I wrote this program in rust" "I think you can just stop saying 'in rust' now, it's kind of implicit"
17:43 <+Amaranth> hehe
17:43 <+XorBoole> ah yes, rust
17:43  * Thinkofdeath hugs garbage collectors
17:43 <+XorBoole> the language where programming devolves into having an argument with the compiler
17:44 <+Amaranth> Everything I've done in Rust so far hasn't needed to worry about the borrow checker
17:44  * XorBoole borrows Amaranth 
17:44 <+Thinkofdeath> Never really figured out rust plus its syntax looks ugly
17:44 <+XorBoole> rust is sooo ugly
17:45 <+Amaranth> Eh, ugly is subjective
17:45 <+XorBoole> I mean I kind of like rust + go. two really nice approaches to making a sane C
17:45 <+Amaranth> It's not as bad as perl :P
17:45 <+XorBoole> perl doesn't exist
17:45 <+Thinkofdeath> rust is too symbol heavy for my liking
17:46 <+XorBoole> Thinkofdeath what does that make scala?
17:46 <+Amaranth> I think a gccgo with the new GC from Go 1.5 and a better story for C interop would be a really nice language
17:46 <+XorBoole> who needs .hashCode() when you have ##?
17:46 <+Thinkofdeath> scala is just scary
17:46 <+Amaranth> Well, toss generics in there too, then it'd be nice
17:47 <+Thinkofdeath> the C interop finally goes the other way now
17:47 <+Amaranth> It's still slow as shit
17:47 <+XorBoole> you what's fun
17:47 <+XorBoole> JNI in scala
17:47 <+Thinkofdeath> wonder if go still creates a thread per a cgo call :P
17:47 <+Amaranth> Pretty sure
17:47 <+XorBoole> actually, I need to get around to writting a way to use JNI and FLI to bridge scala and haskell
17:47 <+Thinkofdeath> s/creates/moves to
17:47 <+Amaranth> Because green threads
17:48 <+Amaranth> You've at least got to switch out the stack which means you've already lost
17:48 <+Thinkofdeath> wonder if thats were all my time is spent per a frame on steven
17:48 <+Thinkofdeath> its really heavy cgo wise 
17:49 <+Amaranth> I don't think JNI is any better so it wouldn't explain why you're slower than MC
17:49 <+Amaranth> C interop is actually why Rust completely changed its threading story
17:49 <+Amaranth> It used to be green threads (not very optimized though) but that made C interop too slow
17:50 <+Amaranth> Then it was pluggable so you could choose native or green and even make a native thread then spin up a green thread scheduler on it
17:50 <+Amaranth> But green threads were still too slow to do C interop and making it pluggable slowed native threads down a lot
17:50 <+Amaranth> So now Rust's thread story is "call out to pthread" :D
17:51 <+Thinkofdeath> shame c interop was so important
17:52 <+Thinkofdeath> (for me at least) all the c stuff is on one thread so green threads would have been fine
17:52 <+Thinkofdeath> unless it couldn't optimize for that case I guess
17:52 <+Amaranth> You can build coroutine things on top of native threads
17:52 <+XorBoole> I really should relearn rust
17:52 <+Amaranth> https://github.com/rustcc/coroutine-rs
17:53 <+XorBoole> then complain about how ugly it still looks ang go back to using the the slowest language ever used by big tech
17:53 <+Amaranth> You have to explicitly give up control since this is cooperative multithreading
17:53 <+Thinkofdeath> hmm
17:53 <+Amaranth> Go gets around that by putting those scheduler calls in the runtime, Python green thread stuff gets around it by monkey patching the runtime
17:54 < StarFan> Thinkofdeath, when I use 0x46 it sends me always 4 values, first 79, then 2 times 77 and finally 256, what does that values before 256 mean ?
17:54 <+Thinkofdeath> it means you are parsing something wrong
17:54 <+Thinkofdeath> its only ever sent once
17:54 <+Thinkofdeath> if it was sent more vanilla would crash
17:55 <+XorBoole> vanilla likes crashing doesn't it
17:55 <+Thinkofdeath> Amaranth: maybe I should give rust another shot then. Got a suggestion for an editor/ide for it?
17:55 < SkylordRedstone> vanilla be like nope
17:55 <+XorBoole> I really think they should put a try {} catch (Throwable t) {} inside the main try {} catch (Throwable t) {} to avoid these crashes
17:55 <+Thinkofdeath> otherwise i'll use sublimetext/atom
17:55 <+Thinkofdeath> XorBoole: I mean they do
17:55 <+Amaranth> Thinkofdeath: Nope, I just use sublime text with syntax highlighting and a terminal
17:55 <+Thinkofdeath> I say crash but mean disconnect
17:56 <+XorBoole> oh ok
17:56 <+Amaranth> iirc atom's plugin does syntax highlighting and calls cargo build for you so you don't even need the terminal
17:56 <+Thinkofdeath> Amaranth: ok *adds to todo list*
17:56 <+XorBoole> disconnect is sane
17:56 <+XorBoole> > atom
17:56 <+Amaranth> Nothing great in the world of autocomplete or refactoring though
17:56 <+XorBoole> > not intellij because yes
17:56 < StarFan> Thinkofdeath, I am listening for 0x46 after the server sends me 0x02 (play state)
17:57 <+XorBoole> there is indeed a rust plugin for idea
17:57 <+Thinkofdeath> StarFan: have you checked your parsing code is actually correct?
17:57 <+XorBoole> > support for 0.13
17:57 <+Thinkofdeath> XorBoole: intellij tends to suck for things like this
17:57 <+XorBoole> topkek
17:57 <+XorBoole> Thinkofdeath shh, I do all my haskell in intellij
17:58 < SkylordRedstone> I have spent most of today writing a proper packet parser in nodejs for the Minecraft protocol
17:58 <+Thinkofdeath> Amaranth: to be fair for go I used the command line tool 'gorename' since no editor really did it well :P
17:59 <+Amaranth> Thinkofdeath, XorBoole: https://gist.github.com/amaranth/83c8af003015968e06ec is what I was writing btw
18:00 <+Amaranth> I was trying to have blocks_by_name by HashMap<&str, &Block>
18:00 <+Amaranth> &Block is wrong because when the Vec resizes that would no longer be valid
18:00 <+XorBoole> dear god why do we need 'pub' and 'fn' instead of 'public' and 'func'
18:00 <+Amaranth> XorBoole: Why func instead of function?
18:00 < StarFan> Thinkofdeath - http://hastebin.com/yawezeyada.avrasm this is the cycle which I run after 0x02
18:01 <+Thinkofdeath> StarFan: well there is your issue
18:01 <+Thinkofdeath> thats not how it works 
18:01 <+XorBoole> Amaranth function is too long
18:01 <+XorBoole> the sweet spot is 3-4 chars
18:01 <+Amaranth> func is too long :P
18:01 <+XorBoole> I dislike 'function' because of js's lambda syntax
18:01 <+Thinkofdeath> StarFan: you are just reading bytes until you find a 0x46 one instead of parsing packets
18:01 <+XorBoole> ok, fun/def then
18:01 <+XorBoole> I prefer def
18:01 <+Thinkofdeath> just use f and p
18:01 <+Thinkofdeath> best savings
18:01 <+Amaranth> This is super bikeshed'y
18:02 < SkylordRedstone> writing a packet parser is difficult but you need to do it :3
18:03 <+XorBoole> Thinkofdeath pls, haskell has zero chars
18:03 <+XorBoole> f args = body
18:03 <+Thinkofdeath> Amaranth: so instead of &Block what would you use? Rc? 
18:03 < SkylordRedstone> clearly GolfScript best
18:03 <+Thinkofdeath> this is the part I never really got with rust
18:03 <+Amaranth> Thinkofdeath: I used usize and store the index in to Vec
18:03 <+Thinkofdeath> ah
18:05 <+XorBoole> I like how the match syntax is not only basically scala's, but they have the same names for the Option ctrs
18:05 <+Amaranth> XorBoole: OCaml
18:07 <+Amaranth> Rust sort of started as OCaml in C++ clothing
18:08 <+XorBoole> oh that makes sense
18:08 <+Amaranth> The original compiler was written in OCaml too
18:08 <+XorBoole> but now it's written in rust
18:08 <+Amaranth> Yep
18:09 <+XorBoole> delicious
18:09 <+XorBoole> if you want to see a horror of a compiler, I suggest checking out nsc, scalac's internals
18:09 <+XorBoole> I know my way around down there a little too well
18:12 <+Amaranth> Rust's compiler has some types like Vec<Arc<RefCell<Box<Foo>>>>, I suspect the only reason it would be less horrible is because I know the syntax :P
18:17 <+XorBoole> I dislike that a lot of rust's core types have no sugar
18:17 <+XorBoole> e.g., no special pointery-syntax sugar of Box<>
18:19 <+XorBoole> I guess the fact that I'm a scalaist doesn't help, because I'm used to [] for type constructors
18:23 < SkylordRedstone> my internet is being so slow today .-.
18:23 < SkylordRedstone> IM MEANT TO HAVE 100MBPS
18:28 <+XorBoole> SkylordRedstone http://www.speedtest.net/result/4631183636.png
18:28 <+XorBoole> in other news holy shit speed test has a lot of adds adblock isn't catching
18:29 < SkylordRedstone> lol mine is catching them
18:30 < SkylordRedstone> dat ping thou
18:30 <+XorBoole> probably the waifi
18:32 < StarFan> Thinkofdeath, I have figured it out (a bit messy but it works) so now I am able to send chat packets without any problem but there is problem with chat tab-completes bungeecord always disconnects me with this error: http://hastebin.com/amakatifav.avrasm
18:32 < StarFan> running the latest
18:38 < SkylordRedstone> something's up with the message
19:05 < SkylordRedstone> ew how are you meant to handle only receiving parts of a packet
19:23 <+Amaranth> SkylordRedstone: Fail
19:23 <+Amaranth> The only reason you should get part of a packet is because the network died or your code has a bug
19:24 < SkylordRedstone> oh okay, I've never had it but I figure that network dropouts might be an issue
19:38 < Not-f7bb> [minecraft-data] rom1504 pushed 7 commits to 1.8 [+0/-0/±8] http://git.io/vG1iA
19:38 < Not-f7bb> [minecraft-data] roblabla 121c290 - Add new types hash, move the states to its own hash
19:38 < Not-f7bb> [minecraft-data] rom1504 9a72fa8 - change structure of the protocol : types and states
19:38 < Not-f7bb> [minecraft-data] roblabla f49f51b - Add entityMetadataItem
19:38 < Not-f7bb> [minecraft-data] ... and 4 more commits.
19:52 < Not-f7bb> [minecraft-data] rom1504 pushed 1 commit to 1.8 [+0/-0/±1] http://git.io/vG1yF
19:52 < Not-f7bb> [minecraft-data] rom1504 936d1c2 - fix formatting
19:54 < Not-f7bb> [minecraft-data] rom1504 pushed 2 commits to 1.8 [+0/-0/±2] http://git.io/vG1SP
19:54 < Not-f7bb> [minecraft-data] gitter-badger 05a1ef1 - Added Gitter badge
19:54 < Not-f7bb> [minecraft-data] rom1504 932b0c3 - Merge pull request #57 from gitter-badger/gitter-badge Add a Gitter chat badge to README.md
--- Day changed jeu. sept. 03 2015
01:13 < Not-2be> [mineflayer] rom1504 pushed 1 commit to master [+0/-0/±1] http://git.io/vGDEx
01:13 < Not-2be> [mineflayer] rom1504 221187a - update gitter room to mineflayer room
01:39 < Not-f7bb> [SpockBot] gamingrobot pushed 2 commits to master [+0/-0/±2] http://git.io/vGDVW
01:39 < Not-f7bb> [SpockBot] nickelpro d174db7 - Reset velocity vector on collision
01:39 < Not-f7bb> [SpockBot] gamingrobot e74f070 - Merge pull request #97 from nickelpro/bugfix-physics
02:01 < Fenhl> XorBoole: fun fact, at one point Rust keywords were *required* to be 6 chars or shorter
02:02 < Fenhl> then there was a big discussion about some stuff and cont became continue?
02:02 < Fenhl> or something like that
02:02 < Fenhl> my point being, Rust likes short keywords
03:51 < conji> Evening folks
03:52 < conji> Grum: I was curious as to the layout of the chunk wire data because it kinda doesn't make sense on the site.
03:58 < conji> Also, did something change with the server list ping in the latest version?
04:25 < nickelpro> conji: What are you talking about with server list ping?
06:18 <+Grum> conji: feel free to ask :)
06:19 <+Grum> but i reckon you might be sleeping already :D
06:21 < Not-f7bb> [SpockBot] gamingrobot pushed 3 commits to master [+0/-0/±3] http://git.io/vGyl2
06:21 < Not-f7bb> [SpockBot] nickelpro 87a2fc0 - Fix physics bugs when interacting with corners
06:21 < Not-f7bb> [SpockBot] nickelpro bbc4c55 - Whoopsie, Vector() -> Vector3()
06:21 < Not-f7bb> [SpockBot] gamingrobot 460f75e - Merge pull request #98 from nickelpro/bugfix-physics
10:02 < StarFan> Hello, can anybody help me please ? I am trying to send 0x01 to bungeecord (chat packet) and 1 of 10 times I got this error: http://hastebin.com/tahofeyuzo.avrasm and client is disconnected. What is wrong ?
10:05 < StarFan> Am I compressing something wrongly ?
10:15 < LEGENDFF> pretty hard to judge just from the bukkit stacktrace, got some code?
10:18 < StarFan> LEGENDFF: yes give me sec I will send you a paste
10:20 < StarFan> LEGENDFF: here http://hastebin.com/awixewuloz.avrasm
10:21 < StarFan> the error appears to be thrown in all packet of the Play state
10:22 < StarFan> packets*
10:22 < StarFan> but the login is successful
10:26 < LEGENDFF> StarFan: seems like youre writing the packet size after the packet id, its the other way around, also dont forget that the size value also contains the size of the packetId VarInt
10:35 < StarFan> LEGENDFF: Sorry the code I sent you was a bit messy look at that:
10:35 < StarFan> http://hastebin.com/noculenine.avrasm
10:35 < StarFan> I am not really sending size after packet id
10:37 < LEGENDFF> i see
10:41 < LEGENDFF> the packet creation looks right to me
10:43 < LEGENDFF> maybe try to make a dump of the packet, or check its content with a debugger
10:45 < StarFan> LEGENDFF, you mean that I try to read the packet before I send it ?
10:46 < LEGENDFF> yea exactly, iterate through send2.toByteArray() and print it to std
11:11 < StarFan> LEGENDFF, the problem is that the packet works only in 1 of 10 cases it throws the error
11:15 <+Thinkofdeath> when exactly are you sending that packet?
11:19 < StarFan> Just after login and 0x02 play state it is just for testing for now
11:33 < StarFan> Thinkofdeath: I think I solved the problem I did 30 ms delay after success login and after that if I send chat packet it works
11:34 < StarFan> It was just test-fail
11:34 < StarFan> I sent the packet too early probably
11:34 <+Thinkofdeath> should wait for the Join Game packet before sending anything
11:35 < StarFan> Yea but on vannila or standart spigot it worked normally but bungeecord maybe has a bit longer join process
11:38 < StarFan> Anyway thanks for help I realised the problem when you asked me when I am sending the packet :)
12:17 < nick____> why snowgolems despawn?
12:18 < nick____> :[
12:18 < angal> melt?
12:18 < nick____> .
12:18 < nick____> underground
12:20 < nick____> someone know an easy program to patch .gif animation?
12:21 < nick____> i found a dancing zombie
13:00 < nick____> 470 files
14:08 < Not-f7bb> [minecraft-data] rom1504 pushed 1 commit to 1.8 [+0/-0/±1] http://git.io/vGSAb
14:08 < Not-f7bb> [minecraft-data] rom1504 204a494 - change protocol schema to comply with the json reference draft (http://tools.ietf.org/html/draft-pbryan-zyp-json-ref-03#section-3)
15:04 < conji> Sorry, I was asleep indeed. For some reason, the server list ping sends an ID of 245 instead of 1 for pinging with my client. I'm sure I'm probably just reading something wrong so I'll look into it further on the server end.
15:13 < barneygale_> conji, mojang servers respond to old-style server list pings with that packet
17:01 < StarFan> Can anybody help me please ? I am trying to send chat packet but for some reason in 50% of cases (other 50% of cases works fine) I got this error from bungeecord: http://hastebin.com/vulepumohu.avrasm
17:03 < barneygale_> StarFan, thrown here: https://github.com/SpigotMC/BungeeCord/blob/master/native/src/main/c/NativeCompressImpl.cpp#L76
17:03 < barneygale_> Looks like bungee can't decompress your packet
17:06 < StarFan> barneygale_ yea but I am sending packets always exactly the same way and one of them works and another no
17:06 < rom1504> sounds like a timing issue
17:07 < StarFan> rom1504 what do you mean by timing issue ?
17:07 < rom1504> you are sending things at the wrong time
17:08 < rom1504> did you "wait for the Join Game packet before sending anything" ?
17:08 < StarFan> well, and how can I know when the time is wrong or good to send a packet ?
17:08 < StarFan> Yes I have waited for join game packet
17:09 < barneygale_> I doubt it's a packet order issue
17:10 < barneygale_> -3 is Z_DATA_ERROR if you're interested: http://www.zlib.net/manual.html
17:10 < barneygale_> It seems unreasonable that bungee should be trying to decompress a chat packet. Surely it shouldn't be long enough?
17:12 < LEGENDFF> it would be a lot easier having some packet dumps
17:16 < StarFan> LEGENDFF yea but it is a lot of work
17:18 < StarFan> and you know I am just "weekend" developer I am not a coding star xD
17:19 < LEGENDFF> here is some dirty code, http://pastebin.com/912tmNBV, nextPacket.getData() would be the byte array, put it right before you send the packet, should work out
17:20 < barneygale_> dumping packets you're about to send should not be a lot of work
17:21 < StarFan> LEGENDFF thanks I will try it right now
17:21 < barneygale_> I wonder if you can DoS a minecraft server by sending absurdly large packet lengths or uncompressed lengths
17:23 < rom1504> 2147483647 is not that big a packet length
17:24 < rom1504> now if you send the actual packet, that's different
17:24 < rom1504> I don't think there's any packet that can be that big though
17:24 < rom1504> well any server bound packet
17:25 < StarFan> LEGENDFF chat packet gave me this output: http://hastebin.com/nivenahaki.1c
17:25 < rom1504> maybe the Plugin Message packet
17:26 <+Dinnerbone> Actually the max packet length you can send to the server would be 2,097,152 bytes
17:26 <+Dinnerbone> And you'd have to send it all, and it'd have to be valid.
17:27 <+Dinnerbone> Serverbound plugin message is itself limited to 32,767 bytes
17:29 < rom1504> I guess slot sizes are limited too (for example in Creative Inventory Action)
17:35 < StarFan> LEGENDFF So I think the format is not a problem
17:35 < LEGENDFF> yea seems fine to
17:35 < LEGENDFF> yea seems fine to me*
17:35 < StarFan> Maybe the join game packet when exactly the packet should arrive ?
17:37 < LEGENDFF> usually after you send encryption response
17:37 < LEGENDFF> http://wiki.vg/Protocol_FAQ
17:47 < StarFan> LEGENDFF: Would you be so kind please to show me how to "catch" the join game packet from the input stream ?
18:05 < StarFan> LEGENDFF: Would you be so kind please to show me how to "catch" the join game packet from the input stream ?
18:41 < nickelpro> StarFan: what framework are you using?
18:41 < StarFan> nickelpro: just pure java and guave for bytestreams
18:41 < StarFan> guava *
18:42 < nickelpro> Then you'll have to implement packet dispatchers yourself
18:42 < nickelpro> Decode the packet, check the ID, when you get Join Game you're good to go
18:48 < StarFan> nickelpro: well, I dont even know how decode the packet
18:48 < StarFan> is there any lib for that around ?
18:49 < nickelpro> StarFan: The wiki is your friend in all things http://wiki.vg/Library_List
19:57 < StarFan> hey guys please help me I have a big problem the bungee always throws this: http://hastebin.com/ehiquzusag.avrasm but for example first 5 packets are absolutely without any problem and when I try to send 6th then it crashes the client and bb
20:00 < LEGENDFF> what packets are you sending?
20:00 < StarFan> it throws this error while sending any packets (chat, slot change...)
20:00 < StarFan> but on normal vannila or pure spigot it works perfectly
20:01 < StarFan> it does not work only if it goes via bungeecord
21:08 <+Grum> Conji: still had questions on the chunkdata?
21:59 < Not-f7bb> [SpockBot] nickelpro pushed 3 commits to master [+0/-0/±5] http://git.io/vG7I6
21:59 < Not-f7bb> [SpockBot] nickelpro 95ba3a8 - Fix very rare physics bug and generally cleanup physics module
21:59 < Not-f7bb> [SpockBot] nickelpro a2d45b7 - flake8 is important /s
21:59 < Not-f7bb> [SpockBot] nickelpro ae2a58b - Merge pull request #99 from nickelpro/bugfix-physics
22:16 <+Thinkofdeath> Grum: the wiki is still missing everything after 15w35b for the chunk packet
--- Day changed ven. sept. 04 2015
00:30 < Conji> Grum: Yes I did, but I just got off of work.
06:14 <+Grum> Thinkofdeath: too much effort to edit a wiki :
06:14 <+Grum> :p
06:14 <+Grum> but i could explain ;)
06:18 < Fenhl> that might be helpful
06:20 <+Grum> What would be unclear atm?
06:27 < Fenhl> it's just not documented at all
06:28 < Fenhl> I haven't looked at the current format at all so maybe someone else should ask
06:28 <+Grum> The internal storage is now divided into 3 kinds, of which two are significantly for the protocol differences. The data is now stored using a palette per section, this allows for unlimited (but 24/32bit should be plenty) amounts of blocks being referenced and smaller in memory sizes.
06:30 <+Grum> To store the data, there is a long[] storage sized 4k/64*bits big. Because upgrading to a bigger size is the most expensive operation we only have the following transition paths: 4->5->6->7->8->13
06:31 <+Grum> 13 currently is the smallest power of two to reference 'any block', that number is dynamic depending on the amount of known blockstates
06:32 <+Grum> So: 0-4bits are 1 type (linear for size), 5,6,7,8 are another one (hash based for speed), 9+ (becomes 13, global palette) is the last one
06:32 <+Grum> on the wire you will see (let me fetch the code so i get this right :D)
06:35 <+Grum> byte with 'number of bits in storage', the palette (which doesnt exist when bits is 13 atm (code does > 8)) and a long array (varint size + size*longs)
06:37 <+Grum> The palette is just: varint size + size*varint (of 'global palette ids' -- the 'chars' currently)
06:38 <+Grum> that's basically it O.o
06:41 <+Grum> (and obviously that just replaces the 'raw data' normally read; the 'multichunk'-packet is gone because the benefits were negligable
06:41 <+Grum> and in theory it just means that someone on a slow line will not be able to do anything with any of the 10 chunks in the packet until he has received all of them
06:43 < Fenhl> okay so Map Chunk Bulk is simply replaced by multiple Chunk Data packets, as expected
06:44 <+Grum> The chunk packet used to have a functionality that let you 'forget chunks' that caused issues and is now a seperate packet
06:44 < Fenhl> already documented as Unload Chunk, not much to get wrong there I think
06:45 < Fenhl> let me see if I can get your explanation into wiki format
06:47 <+Grum> in an ideal world the server would obviously not have to care for that ... but that change as not so trivial in the current way of things
06:47 < Fenhl> if that fails I can always go with what whoever wrote http://wiki.vg/Pre-release_protocol#Spawn_Player did and quote you verbatim :P
06:48 <+Grum> i think the only note should be: 'when bit-size > 8 there will not be a palette' -- for now -- safer could be when it is 'exactly 13' but this might change in the future when we need 14 bits (or less if we clean some significant stuff up)
06:49 < Fenhl> btw, can you confirm if the changes documented for that packet are accurate? The server I play on has a weird bug which seems to occur at Spawn Player which I can't explain with just the changes listed in the wiki
06:50 <+Grum> Maybe I should put in a '0 varint' when there is no palette, that would make it stateless again
06:50 < Fenhl> (the bug is https://bugs.mojang.com/browse/MC-87041 fwiw)
06:51 <+Grum> almost done making breakfast, slower to answer, but i'll check that one in a bit :)
06:51 <+SinZ> what's for breakfast
06:52 < Fenhl> this is the most important question obviously
06:52 <+Grum> omelette+fruitjuice
06:52 < ScruffyRules> SinZ, ASCII
06:52 <+SinZ> ascii is boring
06:52 <+Grum> errr vegetable juice :P
06:53 <+SinZ> which is my steam name is mostly unicode just so it breaks in like half of my games
06:55 < ScruffyRules> I had coco pops. xD
06:56 <+Grum> hehe so wholesomely good!;D
06:57 <+SinZ> I had chocolate cake...
06:59 <+Grum> mmmmchocolade
07:04 <+Grum> Fenhl: i can actually not confirm anything, we do not number the 'metadata' i the code
07:04 <+Grum> bootstrapping does it
07:04 <+Grum> *in the code
07:16 < Fenhl> “number the metadata” not sure what that means
07:36 < Fenhl> Grum: okay so let me make sure I get this right: the Chunk Data packet still has the same fields, but Primary Bit Mask is now an Int and the Chunk data type itself has changed?
07:45 <+Grum> hmmm is it an int?
07:46 <+Grum> ah yeah it is :)
07:47 < Fenhl> why an int though? Preparation for even taller worlds? :P
07:48 <+Grum> probably should become a varint O.o
07:48 < Fenhl> I'm changing the docs to say Unsigned Int, since it makes no sense for a bit mask to be signed
07:48 <+Grum> there is no such thing as unsigned ints in java ;)
07:48 <+Grum> but yeah
07:49 < Fenhl> I know but that's an implementation detail
07:49 <+Grum> I'll add writing out a 'varint 0' if there is no palette rather than the size
07:51 < Fenhl> I'm assuming the least significant bit of the int represents the chunk at the bottom of the column?
07:51 <+Grum> that didn't change from before
07:51 < Fenhl> otherwise changing to a VarInt wouldn't help much
07:51 <+Grum> I'll just go change it to a varint
07:52 < Fenhl> yeah but it wasn't documented for the old format either
07:52 <+Grum> so the section mask is now int, will become a varint (i'll check order)
07:52 < Fenhl> wait nvm it was, but not at [[Protocol]]
07:52 < Fenhl> > The least significant bit represents the chunk from Y=0 to Y=15, and so forth.
07:52 <+Grum> yeah
07:53 <+Grum> sections from the bottom
08:25 < Fenhl> ugh, I seriously need to introduce the notion of enums to the protocol documentation
08:38 < Fenhl> Grum: does this look right? http://wiki.vg/Pre-release_protocol#Chunk_Section
08:50 < Fenhl> Thinkofdeath: what type is the Type field in Entity Metadata? You wrote “Unsigned Type”
08:51 < Fenhl> also, I'm assuming the actual value of the field immediately follows the Type field?
08:56 < Fenhl> I'm going to assume you meant to type “Unsigned Byte” there
09:07 <+Grum> Fenhl: yes but the data is 'longs' so your 'divided by 8' can be easier
09:27 < Fenhl> Grum: it's just the individual n-bit (n being the value of Bits Per Block) entries stringed together, right? Or is there some padding going on?
09:28 < Fenhl> because unless the longs thing matters somehow (e.g. padding), it's easier to define it as a Byte Array, given how the wiki defines its data types
10:28 <+Thinkofdeath> Fenhl: yeah unsigned byte 
10:28 < Fenhl> alright, that's fixed then
10:29 < Fenhl> Unsigned Type sounds fancy though
10:30 < Fenhl> Thinkofdeath: btw, could you add the missing superclasses mentioned there, or change the “extends” bits to the nearest superclass with fields?
10:30 <+Thinkofdeath> hm?
10:30 < Fenhl> in the list of entity metadata
10:30 <+Thinkofdeath> oh
10:31 < Fenhl> it has e.g. “Bat (extends Ambient)” but it doesn't say what Ambient is a subclass of
10:31 <+Thinkofdeath> going to be honest, I cheated with that table and generated it by catching all register calls on the data watcher and printed the craftbukkit names of the classes
10:32 <+Thinkofdeath> Ambient extends Insentient
10:32 < Fenhl> so it should either say “Ambient (extends Foo): no additional indices” or “Bat (extends Insentient)”
10:32 <+Thinkofdeath> Animal extends Ageable
10:33 < Fenhl> s/Foo/Insentient/
10:33 <+Thinkofdeath> don't mind which really
10:33 <+Thinkofdeath> guess the first is better for future changes
10:33 < Fenhl> yeah but skipping empty classes is less clutter
10:34 <+Thinkofdeath> Golem extends Creature   any more missing?
10:34 <+Thinkofdeath> Fenhl: guess so
10:34 < Fenhl> the first would also help people writing stuff in classes with inheritance though
10:34 < Fenhl> so I'm going to do that
10:34 < Fenhl> uh let me see
10:35 < Fenhl> Creature, Fireball, Flying, Hanging, Monster
10:35 < Fenhl> er, I meant “languages with inheritance”, although “classes with inheritance” also works m)
10:36 <+Thinkofdeath> Creature -> Insentient , Fireball -> Entity, Flying -> Insentient, Hanging -> Entity, Monster -> Creature
10:37 < Fenhl> thanks
10:37 <+Thinkofdeath> I wish entity metadata keys were named like block states, would make things so much easier
10:37  * Thinkofdeath smiles at Grum
10:38 < Fenhl> :P
10:38 < Fenhl> the type annotations are new though, right?
10:38 <+Thinkofdeath> they always had types just its fixed internally now
19:17 < TkTech> barneygale, Gjum, you both starred my repo at the same time, what ya up to?
19:47 < Not-f7bb> [minecraft-data] rom1504 pushed 2 commits to 1.8 [+0/-0/±2] http://git.io/vGN2N
19:47 < Not-f7bb> [minecraft-data] Gjum 9bf60ce - Change slot range names of crafting table grid -> craft grid result -> craft result
19:47 < Not-f7bb> [minecraft-data] rom1504 44d2d07 - Merge pull request #61 from Gjum/patch-1 Change slot range names of crafting table
--- Day changed sam. sept. 05 2015
01:28 < AlphaBlend> are armor stands no longer living in 1.9+?
01:28 < AlphaBlend> that was sure annoying
01:29 < AlphaBlend> an unfortunate side effect of easily adding armor stands to the code
01:36 < Gjum> Fenhl, you there? I think youremoved vital info about the inventory types from wiki.vg
01:38 < Gjum> the "Technical name" column is the "Window Type" sent by server in "Open Window", and that is now missing
04:15 < Fenhl> Gjum: oh okay
04:17 < Fenhl> Gjum: what is the numeric inventory type used for then?
04:17 < Gjum> Fenhl, there should probably be a note about the usage then
04:17 < Gjum> nothing, lol
04:17 < Gjum> maybe it wwas used before
04:18 < Fenhl> alright, fixing
04:19 < Gjum> thanks
04:22 < Fenhl> done
10:28 <+Thinkofdeath> AlphaBlend: they are still living
17:03 <+Thinkofdeath> oh so the packets got sorted, that explains a lot
17:14 <+Grum> :p
17:20  * Thinkofdeath stabs Grum 
17:21 < yawkat> sorted?
17:21  * Grum deflates
17:21 <+Thinkofdeath> somewhat sorted
17:21 <+Thinkofdeath> a few still seem out of position
17:21 <+Thinkofdeath> (on 15w36c)
17:22 <+Grum> they are sorted  by our names, could be others were added after i didi t
17:22 <+Thinkofdeath> ah names, I assume you were grouping similar packets
17:22 <+Grum> ofc not
17:22 <+Thinkofdeath> somewhat turned out that way :P
17:23 <+ammar2> speaking of names, do you think our wiki names are better or yours?
17:23 <+Grum> 7
17:24 <+Thinkofdeath> one of these days i'm going to work out what that combat event packet does
17:26 <+Grum> ENTER_COMBAT, END_COMBAT,ENTITY_DIED
17:26 <+Grum> about that :P
17:26 <+Thinkofdeath> I see when its called but I can't work out what the client does with it
17:27 <+Grum> just showing death-screen
17:27 <+Grum> nothing more
17:27 <+Thinkofdeath> oh its the game over screen?
17:54 < Fenhl> Thinkofdeath: is Collision Rule really always, hideForOtherTeams, hideForOwnTeam, never
17:54 <+Thinkofdeath> apparently
17:55 <+Thinkofdeath> oh without never
17:55 <+Thinkofdeath> wait, never is there
18:07 <+Grum> latest snapshot should also have the change where it sends a '0 length palette'
18:14 < Fenhl> oh right
18:14 <+Grum> i commited+pushed it while we were talking about it
18:29 <+Thinkofdeath> https://github.com/thinkofdeath/steven/commit/951d5eda83e4db4c9e3b0bb456b2025f9bfa06c4 yay, done
18:35 <+Grum> oof such a massive diff because you shuffled everything? :D
18:40 <+Thinkofdeath> Grum: yep, luckily the _proto files are generated for me
18:41 <+Thinkofdeath> made a slightly hacky system where any struct with the comment "This is a Minecraft packet" gets an id assigned and read/write methods generated
18:45 <+Thinkofdeath> anyway, good luck to the person that decides to reorder the wiki. I need a break :)
18:45 <+Thinkofdeath> if you use that commit to help Use Item and Block Place are backwards
18:48 < Fenhl> D:
18:51 < Fenhl> oh hey look I have a minigame server which needs to be up and running in an hour, someone else has to do the wiki thing
19:31 < Assossa> Hey guys, I'm trying to parse minecraft packets in python, but I am completely lost. Can anyone help?
19:31 < Assossa> I'm brand new to parsing packets on a low-level
19:33 < Assossa> Anyone?
19:37 < morfin> hello, Entity ID is only used in runtime? so it used only in protocol and stored in memory
19:54 < nickelpro> morfin: yes, its a runtime generated value
19:56 < nickelpro> Assossa: I recommend referencing one of the half dozen Python protocol implementations
19:56 < morfin> then i understand how that hack bungeecord works
20:00 < Assossa> Can you link me nickelpro? I googled for it, but I don't see anything useful :/
20:01 < nickelpro> Shameful self plug: https://github.com/SpockBotMC/SpockBot
20:01 < Assossa> Ok, thanks
20:01 < nickelpro> But there is also quarry: https://github.com/barneygale/quarry
20:02 < nickelpro> And fastmc is very popular also: https://github.com/dividuum/fastmc
20:04 < Assossa> Thanks, this will help me a lot :)
20:12 < Not-f7bb> [minecraft-data] rom1504 pushed 6 commits to 1.8 [+0/-0/±6] http://git.io/vGj0q
20:12 < Not-f7bb> [minecraft-data] Gjum f4cc1db - Add a name for each armor slot
20:12 < Not-f7bb> [minecraft-data] Gjum ae9a623 - Add horse slots
20:12 < Not-f7bb> [minecraft-data] Gjum cacd822 - Add Anvil slots
20:12 < Not-f7bb> [minecraft-data] ... and 3 more commits.
20:37 < Not-f7bb> [minecraft-data] rom1504 pushed 1 commit to 1.8 [+0/-0/±1] http://git.io/vGjaa
20:37 < Not-f7bb> [minecraft-data] rom1504 4f3ff30 - format projects using mcdata in a table, add spock, add windows in data
--- Day changed dim. sept. 06 2015
06:16 < Not-f7bb> [SpockBot] nickelpro pushed 2 commits to master [+0/-0/±2] http://git.io/vZvfb
06:16 < Not-f7bb> [SpockBot] nickelpro 2c27160 - Minor physics update
06:16 < Not-f7bb> [SpockBot] nickelpro 447720b - Merge pull request #102 from nickelpro/master
06:55 < ohcreative> can someone help me?
06:55 < ohcreative> I need to create a packet to close a players open inventory window
06:55 < ohcreative> :(
06:57 < ohcreative> anyone here?
08:27 < Not-f7bb> [SpockBot] nickelpro pushed 2 commits to master [+0/-0/±2] http://git.io/vZv3E
08:27 < Not-f7bb> [SpockBot] nickelpro 865b8d4 - More vector methods
08:27 < Not-f7bb> [SpockBot] nickelpro 14db6a5 - Merge pull request #103 from nickelpro/master
08:33 < Not-f7bb> [SpockBot] nickelpro pushed 3 commits to master [+0/-0/±3] http://git.io/vZvsU
08:33 < Not-f7bb> [SpockBot] nickelpro 1aa64a7 - Walk with vectors
08:33 < Not-f7bb> [SpockBot] nickelpro 1a7d9e0 - Minor typo fix
08:33 < Not-f7bb> [SpockBot] nickelpro 3c56b17 - Merge pull request #104 from nickelpro/master
14:29 < MrARM> so, I'm wondering, in minecraft, when player starts mining, the server calculates the time that it should take the client to break the block
14:30 < MrARM> and after mining the client sends the server a packet too
14:30 < MrARM> but my question is, what happens if the clients sends the packet before the block hasn't been mined yet on the server - for example due to net lag
14:31 <+Thinkofdeath> the server will wait and remove it at the correct time
14:31 <+Thinkofdeath> you can send both instantly and the server will still wait out the full time
14:32 < MrARM> but will the server revert the block to the client?
14:32 <+Thinkofdeath> revert? You mean send back the correct block?
14:33 < MrARM> yeah
14:33 <+Thinkofdeath> because I think it does but i haven't tested much
14:33 < MrARM> also, another question then; what happens if the client will already start mining another block?
14:33 <+Thinkofdeath> it'll clear the previous's progress
14:33 < MrARM> hmm, ok, thanks
14:34 <+Thinkofdeath> oh and fun fact: you can send a start digging packet and a finish digging packet instantly and then walk away. The server will continue breaking it even if you aren't near it
14:35 < MrARM> I'm making my own server and I came up to this already and were thinking what happens in such case
14:35 < MrARM> I think I'm going to include net lag into the time
14:35 < MrARM> as in PE it is much more of a problem than in PC
14:45 < Fenhl> ah, so that's why blocks randomly reappear sometimes
16:05 < Timelaw> clonejo: Hey! Just tried to get your mc-erl running using your instructions but it seems it is crashing. Using MC 1.4.7, as it was the listed version. 
16:05 < Timelaw> clonejo: Can't get it to work as I try to connect to the server
16:07 < Timelaw> clonejo: I'm trying to get it to run because I was thinking of writing my own MC server using Erlang but I would like to know what you did to implement the network protocol. 
16:36 <+Thinkofdeath> if its 1.4.7 then its way to out of date to be useful for 1.7+
17:04 <+clonejo> Timelaw: i'll try running it. haven't touched it in ages. the network protocol isn't that nicely done, as the abstractions have runtime costs. that abstraction is obsolete now anyway, because packet definitions are not bidirectional anymore.
19:08 < morfin> what do you mean not bidirectional?
19:19 <+Thinkofdeath> in 1.6 and less packets could be sent both ways, there wasn't the clientbound/serverbound split
19:25 < morfin> but why?
19:26 < morfin> i remember something like that now
19:26 < rom1504> why what ?
19:30 < morfin> what's point to send same "packets" in both directions?
19:38 < Timelaw> clonejo: Did you get it to run? Went away meeting some friends so that's why it took me so long
19:40 < Timelaw> clonejo: I don't really know anything about how to get the protocol and I wanted to ask you/check your code in order to get a hint on how it works, but I do not it's obselete as there has been 4 major versions of MC since then anyway.
19:40 < Timelaw> clonejo: Just thought I'd ask the only guy that even tried doing it in Erlang so :P 
19:41 <+Grum> it makes more sense to not have bidirectionality as you get better control over what you send and what you are allowed to receive
20:00 < Timelaw> Did you reverse-engineer the protocol or is there some place where I can find the specs for it? I don't know what the common practices are since I have never tried it :P And I just want to have write a server for any game really but Minecraft seems like the most suitable
20:01 < Timelaw> clonejo: ^
20:02 < nickelpro> Timelaw: wiki.vg
20:03 < angal> Protocol already reversed by this team and you can find it (unofficial) spec on wiki.
20:03 < angal> :(
20:08 < rom1504> you might also be interested by https://github.com/PrismarineJS/minecraft-data/blob/1.8/enums/protocol.json
20:08 < Timelaw> nickelpro: wiki.vg? What does vg stand for?
20:08 < Timelaw> rom1504 angal: Thanks!
20:08 < yawkat> It's a domain  
20:08 < nickelpro> Timelaw: Officially? Virgin Islands. Unofficially? Often used for video game related domains
20:08 < Timelaw> yawkat: I know, but usually it's for a specific country or so and i haven't seen vg before
20:09 < Timelaw> nickelpro: Oh, that makes sense haha
20:11 < Fenhl> Timelaw: specifically, the articles you want to look at are http://wiki.vg/Protocol if you're working with 1.8 or http://wiki.vg/Pre-release_protocol for 1.9
20:12 < Fenhl> also http://wiki.vg/Protocol_FAQ but disregard that first entry, it's outdated
20:15 < Fenhl> there I fixed it http://wiki.vg/Protocol_FAQ#Is_the_protocol_documentation_complete.3F
20:19 < Not-f7bb> [minecraft-data] rom1504 pushed 1 commit to 1.8 [+0/-0/±1] http://git.io/vZJMm
20:19 < Not-f7bb> [minecraft-data] rom1504 6f60cd1 - 10 slots doesn't form a grid
20:23 < Timelaw> Fenhl: THanks :) I'll definitely have a look at both of them.
20:30 < Timelaw> Fenhl: This is really the thing I needed haha
20:30 < Timelaw> Thank you all that helped :) I'll try to dive into it now
20:31 < Fenhl> Timelaw: oh and [[Pre-release protocol]] is *not* up to date. A recent snapshot shuffled all the packets around and no one has bothered to fix the wiki
20:34 < Timelaw> Fenhl: Okey :) But if I would just focus on 1.8 for now, can I assume that the Protocol page will be sufficient? I am not too worried at all regarding futur updates. I am actually doing this for myself to just learn and experiment with Erlang
20:34 < Timelaw> Fenhl: Want to do a project that has a really scaleable nature, and Minecraft is perfect for this
20:35 < Timelaw> Fenhl: So if it turns out I manage to make a fully-functional server and decide to keep developing it, then I'll worry about the future updates at that point :) 
20:35 < rom1504> yeah 1.8 is correctly documented
20:36 < rom1504> 1.9 is a moving target, that's why it isn't always up to date
20:37 < Timelaw> rom1504: Completely understandable. It is after all a dev release, right?
20:37 < Timelaw> rom1504: So anything could happen
20:37 < Fenhl> Timelaw: you might need to look at [[Protocol Encryption]] as well (but afaik only if you want to implement online-mode), but otherwise the article should be self explanatory
20:38 < Timelaw> Fenhl: I can't remember if online mode is restrictive as in it won't allow me to host my server to others or if it is the auth with mojang's online service?
20:39 < Timelaw> Fenhl: As far as I remember, you could still connect as long as you had the IP and ports open so it didn't seem to matter in my case when playing with a locally hosted server?
20:39 < Timelaw> Fenhl: Don't know if something changed since then though. Haven't played since 1.4.5 I think
20:39 < rom1504> Timelaw: yeah after each snapshot, there is often protocol changes
20:39 < Fenhl> I'm the wrong person to ask here, maybe someone else knows
20:40 < rom1504> Timelaw: online mode only means you need to auth people using mojang api
20:40 < Timelaw> rom1504: Yes and so I would only focus on versions that are finished.. for now anyway
20:40 < rom1504> but you can still host your own server and everything
20:41 < Timelaw> rom1504: Yeah, so not necessary, right?
20:41 < rom1504> yes you can do offline mode too
20:41 < Timelaw> rom1504: For now that's what I'll do :)
--- Day changed lun. sept. 07 2015
00:34 < Not-f7bb> [SpockBot] nickelpro pushed 21 commits to master [+10/-0/±19] http://git.io/vZU8s
00:34 < Not-f7bb> [SpockBot] Gjum 5ca1cc8 - Implement InteractPlugin.open_inventory()
00:34 < Not-f7bb> [SpockBot] Gjum 3b3a535 - Split chat message into chunks of 100 chars in InteractPlugin
00:34 < Not-f7bb> [SpockBot] Gjum 96aa185 - Add Slot.copy() method
00:34 < Not-f7bb> [SpockBot] ... and 18 more commits.
00:46 < Not-f7bb> [SpockBot] nickelpro pushed 1 commit to master [+0/-0/±1] http://git.io/vZUBw
00:46 < Not-f7bb> [SpockBot] nickelpro 366593c - Update README.rst
00:47 < Not-f7bb> [minecraft-data] rom1504 pushed 1 commit to 1.8 [+0/-0/±1] http://git.io/vZUBX
00:47 < Not-f7bb> [minecraft-data] rom1504 f184c73 - spockbot now uses recipes !
00:48 < Not-f7bb> [SpockBot] nickelpro pushed 1 commit to master [+0/-0/±1] http://git.io/vZUBD
00:48 < Not-f7bb> [SpockBot] nickelpro 1008c48 - Update README.rst, crush hopes and dreams
01:09 < morfin> i was interested - when you die new entity spawned for player?
01:09 < morfin> with new id etc
01:12 <+Thinkofdeath> no, you can't change your player id
01:12 <+Thinkofdeath> (internally its a new entity with the old id copied over)
01:12 < morfin> hm
01:13 < morfin> because i noticed when you join to vanilla it says "created entity id xxx for player" or something like that
01:20 < morfin> remember i was asking about worlds synchronization?
01:20 < morfin> should they synchronized to milliseconds?
01:20 < morfin> or some precision is enough?
01:29 < nickelpro> So I have no idea if this is what you're talking about
01:29 < nickelpro> But when if I tell my bot to follow me, based on entity ID, and I kill my bot
01:29 < nickelpro> After he respawns the server send him a new entity id for me which I thought was weird
01:32 < morfin> i say that somebody said worlds should be synchronized
01:32 < morfin> and i am not sure is "lag" few milliseconds between them very critical
01:34 < morfin> ah i remember - he said it's critical for mechanisms
01:53 < Not-f7bb> [SpockBot] nickelpro pushed 1 commit to master [+0/-0/±8] http://git.io/vZUgj
01:53 < Not-f7bb> [SpockBot] nickelpro 3ca2d3c - Cleanup, bug fixes, a little bit of everything
15:32 < Fenhl> https://www.reddit.com/r/Minecraft/comments/2u45a9/some_questions_regarding_the_iron_titan/co52nuq where is the spawn chunk cache file this comment refers to located?
15:37 < Gjum> I assume they are stored like all other chunks, but loaded before ticking them
15:37 < Gjum> when you start a server, it shows "Preparing spawn chunks..."
15:38 < Fenhl> which would imply that villages are stored within the anvil files?
15:38 < Gjum> no, they are in villages.dat or so
15:39 < morfin> what?
15:42 < Gjum> http://minecraft.gamepedia.com/Villages.dat
15:43 < Gjum> the spawn chunks are not "unloaded", and thus the villages not "forgotten", and remain in villages.dat
15:43 < Fenhl> no, villages.dat only contains villages within view distance of players
15:43 < Fenhl> it's empty when no one is online
15:46 < Gjum> hm
15:46 < Gjum> so where are the doors stored then? they must be somewhere, or it wouldnt make sense to build it in the spawn chunks
15:52 < morfin> but what for that's used?
15:54 < morfin> are not villages just generated once?
15:54 < morfin> what for " Stable: Last time a house was added to the village." is required
15:57 < Thinkofdeath_> Fenhl: doesn't exist, its just a distance check hardcoded in the server
15:59 < Fenhl> Thinkofdeath_: that doesn't explain how the Iron Titan survives a server restart iff it's built in the spawn chunks
16:00 < Thinkofdeath_> they never unload
16:01 < Fenhl> where are the villages stored though?
16:02 < Thinkofdeath_> Village.dat i'd assume
16:02 < Thinkofdeath_> or villages.dat
16:02 < Fenhl> it's not villages.dat because that's empty when the server is not running, even with a working Iron Titan, we tested this on our server at one point
16:04 < Gjum> that's interesting, because then there's no use for villages.dat at all
16:04 < Thinkofdeath_> Theres a Village.dat too, no which one used
16:08 < Gjum> Village.dat is for the generated village structures it seems
16:08 < Gjum> like nether fortresses
16:08 < Gjum> not related to the iron titan at all
16:17 < morfin> what do you mean?
16:18 < morfin> everything can be stored in region
16:19 < morfin> what for that villages.dat is used i have no idea
16:26 < Gjum> morfin, region does not save villages at all
16:28 < morfin> villages you mean houses?
16:28 < morfin> villagers? golems?
16:29 < morfin> it seems like villages.dat used only to spawn new villagers and golems
16:29 < morfin> if enough doors and enough villagers
16:29 < Gjum> not the blocks, we are talking about an iron golem farm, which is based around the center point of a village, which is depending on the doors of that village
16:29 < morfin> oh you mean that
16:29 < morfin> but that seems to be temporary file
16:30 < morfin> is not that bad useless idea?
16:30 < morfin> why write temporary file if after shutdown it's viped anyway
16:30 < Gjum> yeah, which is weird because in that reddit comment someone said the villages in spawn chunks are kept across server reboots
16:30 < morfin> *wiped
16:30 < morfin> hmm
16:35 < angal> Maybe they selected each time in the same rule after server restart, like when they builded first time.
16:37 < morfin> i se that villages.dat store only some metainformation
16:37 < morfin> *see
16:37 < morfin> maybe it's just - loading spawn chunk and it have village, then fill villages.dat with information about that village
16:47 < Gjum> No because then the villages of the iron golem farm would meld into one, instead of being separated
16:50 < morfin> i am not sure how it works
16:50 < morfin> i think only reversing can ask
16:51 < morfin> is not there 1 village btw?
16:52 < morfin> i watch guide where guy  built farm for golems, he used lots of doors and 1 place with villagers
16:53 < morfin> https://www.youtube.com/watch?v=Dev3Ls8papM
16:54 < morfin> 1 room with villagers i mena
16:56 < morfin> i think that's why nobody have sane implementation of minecraft
16:56 < morfin> server
16:57 < morfin> only reverse engineering can help to undestand how that works, and it's more like rocket science
17:32 < Fenhl> reason I'm asking is, it seems to be broken since 15w36a
18:09 < roblabla_> anyone here knows how knockback works ? Is that documented somewhere ?
18:13 < roblabla> (this is from a client perspective)
18:54 < nickelpro> roblala, when the client is attacked it is responsible for calculating knockback on itself. If the client doesn't do this, no knockback happens. Server doesn't enforce anything
18:54 < nickelpro>  roblabla ^^
18:55 < roblabla> nickelpro, yup, I know that much. The question is, on what packet does the notchian client knocksback
18:55 < roblabla> that's the biggest trouble I'm having
18:57 < rom15041> Yeah, how do you know who attacked you ?
18:57 < rom15041> ( swing arm animation ? )
19:03 < nickelpro> That can't be right, there can be a dozen people swinging arms with different equipment
19:03 < nickelpro> Combat event maybe?
19:03 < nickelpro> Time to get the ol' echo every packet plugin out again
19:06 < nickelpro> Or perhaps we just get sent an entity velocity with the client eid
19:06 < nickelpro> Haven't looked, just spit balling
19:14 < roblabla> Thinkofdeath> roblabla: isn't it just an entity velocity packet?
19:16 < roblabla> But I think we already handle it
19:19 < Gjum> You get a health update and combat event, and know the position of the entity that hit you
19:20 < Gjum> From that you should be able to calculate your movement
19:29 < nickelpro> Health Update could be anything, I think the Combat Event is the key
20:00 < nickelpro> Nope, that ain't it, the Combat Event eid is only sent at the end of combat
20:10 < morfin> can player theoretically extist when disconnected?
20:10 < morfin> *exist
20:11 < morfin> i mean Entity, i was thinking about "hack" to force players fight to death 
20:16 < nickelpro> roblabla, Gjum: I've done a lot of fiddling, there is no way to definitively identify an attacker when you are being attacked. The server only send you your attacker after some period of time when you're no longer engaged in combat with that entity. Knockback is done be recieving an entity velocity from the server with the Player's eid
20:18 < nickelpro> Like canidates for an attacker would be whoever just did a Swing Arm animation withing 4 blocks of you right before the start combat event/health update
20:18 < nickelpro> Likely*
20:18 < Gjum> Interesting
20:19 < morfin> what
20:20 < morfin> i thought do you mean client?
20:20 < morfin> so it does not know who attacked you
20:20 < nickelpro> morfin: correct, the client doesn't know who attackd it. In fact a malicious server could attack clients without ever having a valid entity
20:21 < nickelpro> Also who came up with the 1/8000 of a block unit for Entity Velocity? That seems right-ish but is it based on anything or just "feels good"?
20:30 < nickelpro> For anyone interested, here is a full log of all combat related packets. I took one swing at a client with a diamond sword. Everything after the initial swing until combat end is just health regeneration 
20:30 < nickelpro> http://hastebin.com/fudayovuvo.py
20:30 < morfin> hmmm
20:30 < morfin> but what's point to do that?
20:31 < nickelpro> morfin: What's your question exactly?
20:31 < morfin> "malicious server could attack clients without ever having a valid entity"
20:31 < morfin> what's point to do such thing
20:31 < nickelpro> What's ever the point of that sort of thing
20:32 < roblabla> the point is you can attack clients without being attacked yourself
20:32 < roblabla> think hacked clients :3
20:33 < morfin> but he said "server"
20:33 < nickelpro> Ya you'd need the server to play along, I'm pretty sure even vanilla enforces the "no interaction outside range" rule
20:33 < morfin> i guess client can't attack without attacking
20:33 < nickelpro> Oh no, it can
20:34 < morfin> ?
20:34 < nickelpro> I don't think the swing animation is mandatory at all
20:34 < nickelpro> You just send an interact attack packet
20:34 < morfin> i meant attack player when server think it's not you attacked him)
20:34 < morfin> something liek that
20:34 < Gjum> ^ nick is right
20:35 < Gjum> nick in your log there is combat evt
20:35 < nickelpro> Sure, but the server by default doesn't report the attacker to other clients until combat is over. So the point is moot, the server knows who your attacking but no one else does and the server won't do anything
20:35 < Gjum> So i suspect that tells you who hit you? !
20:36 < nickelpro> Gjum: Ya but it's just an "Enter Combat" event, you don't get the "End Combat" with the attacker eid until long after combat is over
20:36 < Gjum> Oh ok
20:36 < nickelpro> 15-ish seconds according to the logs
20:38 < Gjum> Would be cool if sb looked that up in the actual Client code
21:31 < Fenhl> that packet sounds like it might have been implemented for the (scrapped?) combat music thing
22:25 < morfin> but you enter combat only when some creature or player attack you
--- Day changed mar. sept. 08 2015
01:26 < Not-f7bb> [SpockBot] nickelpro pushed 7 commits to master [+0/-0/±12] http://git.io/vZtma
01:26 < Not-f7bb> [SpockBot] Gjum e8c36b9 - Reformat inline function definitions for flake8 and flake8 alone
01:26 < Not-f7bb> [SpockBot] Gjum 1c65eca - Refactor InventoryAsync
01:26 < Not-f7bb> [SpockBot] Gjum 249c8b4 - Improve crafting speed and reliability
01:26 < Not-f7bb> [SpockBot] ... and 4 more commits.
02:57 < dx> made a crappy minecraft client in C this weekend, for shits and giggles https://github.com/dequis/minecrap
03:02 < nickelpro> I've done this too, on top of libuv. I am also a terrible programmer
03:02 < nickelpro> So it didn't work too good
03:03 < dx> i wasted waaaaay too much time getting serialization right
03:03 < dx> but i think implementing the rest of the packets i care about (in offline mode, without encryption) should be smooth
03:07 < dx> btw, i'm building packets by doing two passes, one to calculate the size, and another one to actually write to the socket
03:07 < dx> is that a sane way to do it? or will it bite me in the future?
03:12 < nickelpro> dx: I just reallocated and moved the buffer but like I said, bad programmer
03:12 < dx> heheh
03:12 < dx> yeah that's exactly what i'm trying to avoid
03:12 <+ammar2>  /* varargs are a list of pairs (type, value) */
03:13 <+ammar2> lik dis if u cri everitim
03:13 < dx> ammar2: thanks ammar2
03:15 <+ammar2> dx: I once tried to read without buffering
03:15 <+ammar2> that was really fun
03:18 < dx> ammar2: i still have some buffers because i want to move this to nonblocking sockets in an event loop (actually, it's probably nonblocking already and i'm doing IO wrong atm)
03:18 <+ammar2> dx: are you gonna use libevent
03:19 < dx> ammar2: nah glib's event loop
03:22 < dx> not sure if GIO can use other event loops (i'm using it to be lazy with the socket connection details)
03:27 < Not-f7bb> [SpockBot] nickelpro pushed 2 commits to master [+0/-0/±2] http://git.io/vZtRc
03:27 < Not-f7bb> [SpockBot] Gjum f119850 - Fix string formatting for non-integer metadata
03:27 < Not-f7bb> [SpockBot] nickelpro f671117 - Merge pull request #106 from Gjum/master
06:44 < nickelpro> Is the Player Abilities packet ever used for anything?
07:18 < nickelpro> Ignore me I just screwed something up
11:42 < Fenhl> /ignore nickelpro
12:10 < rom15041> You'd need a /ignorewhenscrewup :p
14:50 < Gjum> /z/z
14:50 < Gjum> umm, ignore that
20:26 < Conji> Howdy folks.
20:26 < Conji> Grum: Sorry I didn't reply if you said anything. Something came up and I had to go out of town for a few days.
20:27 < Conji> But if there's any way you could inform me of how the chunk data packet is laid out in 1.9, that'd be great. I don't fully understand what the site is trying to relay.
20:31 <+Grum> should be documented now on the site
20:32 < Conji> It's documented but it's just confusing. :l
20:32 < Conji> Like possible block state IDs. What exactly does that mean?
20:33 <+Grum> I haven't read the documentation, i just explained it here and Fenhl said he documented it =D
20:33 <+Grum> so without context it would be hard to answer that question
20:34 < Conji> https://gist.github.com/19d87b03aeba4ffa19bc that's how he worded it.
20:35 <+Grum> an url would at least wrap it and make it readable :'(
20:35 < Conji> Yeah, gimme a sec. Working on that wrap :(
20:36 <+Grum> its ok, just read it
20:36 <+Grum> it's basically: size in bits; palette; raw data
20:37 < Conji> what exactly is the palette? 
20:37 < Conji> Because the raw data just seems to look like what it was in previous versions
20:37 <+Grum> previous versions being what?
20:38 < Conji> 1.8 being a base
20:38 < Conji> the raw data just being (blockdata << 4) | metadata per block
20:38 <+Grum> yes, but now its just the palette
20:38 <+Grum> so a really limited amount of entries in that format
20:39 <+Grum> how many described in the varint before they appear
20:42 < Conji> Is there someone who has this already implemented in an open source repo?
20:42 <+Grum> it really is not a hard format, but what do you want to do with it?
20:42 <+Grum> actually understand the data? what is your goal?
20:42 < Conji> Use it as a base. Idk if it's just the fact that I just got off of work or what, but it's not clicking in my head.
20:43 <+Grum> you understand the concept of a palette?
20:43 < Conji> Not really. :(
20:43 <+Grum> such young users haha
20:43 < Conji> I've never had to use one before so it's relatively new to me.
20:43 <+Grum> it's quite a common technique from ye olden days to conserve space
20:44 <+Grum> usually used for images
20:44 < Conji> Yeah, I mainly deal with web backends and such.
20:44 <+Grum> imagine instead of having 256*256*256 colors, you just have 16
20:44 <+Grum> but you can pick each of the 16 colors (out of the 256*256*256 RGB)
20:44 <+Grum> that means you can make '16 color images'
20:45 <+Grum> and instead of having to store 3 bytes at every pixel, you just have to store 4 bits
20:45 <+Grum> the 4 bits would be able to reference to the 16 values
20:45 < Conji> Ok so here's what I'm understanding
20:45 <+Grum> but in a smaller way than referencing the data it references itself (4 bits vs 3 bytes in this case)
20:46 < Conji> There's a group of block IDs that appear in the chunk
20:46 < Conji> Well, block data that appears
20:46 <+Grum> the palette basically contains the 'unique blocks' in the 'following data'
20:46 < Conji> Then following the pallete, there's an array that points to the position in the palette
20:46 <+Grum> yes
20:46 < Conji> Ok that makes so much more sense.
20:47 <+Grum> so instead of having '16 bit' references, you get a 'X bit' reference which you can look up in the palette
20:47 < Conji> Yeah, it keeps the pallete then just reads the index as needed
20:47 <+Grum> yes, so convey this information to the client we need to send: "bitsize", "palette", "rawdata"
20:48 < Conji> So question, does air count as a block ID?
20:48 <+Grum> varint + varint (length) + lenght*varint, length+longs*length
20:48 <+Grum> yes
20:48 < Conji> Ok awesome.
20:48 < Conji> That clears up so much.
20:48 <+Grum> some formats (sizes of bits) do not have a palette, and they use the 'global palette' (like before) but they do not use 16 bits to represent the value, just 13 atm
20:49 < Conji> I'll keep that in mind.
20:49 <+Grum> oh could be the first one is a byte 
20:49 <+Grum> since it will never going to be big :p
20:49 <+Amaranth> 13 bits? That doesn't seem worth the trouble
20:50 <+Grum> 2k less data
20:50 < Conji> Yeah, but with each entry, it saves space in the long run
20:50 < Conji> 3 bits * 10 entries
20:50 < Conji> That's 30 right there
20:50 <+Grum> 3bits * 4k entries
20:50 < Conji> ^^
20:50 <+Grum> 4k entries in each chunk
20:51 <+Amaranth> Sure you could save a maximum of ~10MB per user but I would think the cost to parse it would outweigh that benefit
20:51 <+Grum> that is only on chunks with >256 unique states
20:51 < Conji> It wouldn't be hard to parse at all :v
20:51 <+Amaranth> It's rare so the memory saving doesn't matter and neither does the CPU usage for the memory saving :D
20:52 <+Grum> barely any cost involved for it, and i just set it up that it takes the minimum amounts of bits to represent  every entry in the global palette
20:52 <+Grum> which allows this system to be used for whatever the fuck amount of states you can think of
20:53 <+Amaranth> The larger your global entries the more unique entries are viable before you switch to them
20:53 <+Amaranth> So it's not quite just automatically doing the best thing :P
20:53 <+Amaranth> Unless you didn't make the 256 a hardcoded thing
20:53 <+Grum> it is now
20:54 <+Grum> its actually quite hard to get 256 states in a chunk :p
20:54 <+Amaranth> Redstone?
20:54 <+Amaranth> Oh yeah those states are only for rendering
20:54 <+Grum> they wont be
20:55 <+Grum> but even then, getting 256 in a single section (sorry, what you call section is what i call chunk)
20:55 <+Grum> this is per 16^3
20:55 <+Amaranth> Oh did you guys adopt the Chunk/ChunkStack terminology then?
20:55 <+Grum> no but that is how it works in my head =)
20:58 <+Grum> i should just rename them classes haha
21:00 <+Grum> anyhow. a lot of the chunks are <16; those take 2k+64bytes to store in raw data
21:03 <+Grum> 5,6,7,8 bits are 2.8k/3.8k/5k/7k big
21:03 <+Grum> and 9+ 6.5k
21:04 <+Grum> oh wait, 3k/4k/5.5k/8k
21:06 <+Grum> anyhow, on average smaller than now :P
21:06 <+Grum> significantly
21:06 <+Grum> no world-gen chunks will use more than 64 -- so at minimum 50% less for sections that store data
21:06 < Fenhl> Conji: uh, where did you find that paste? I did not write that
21:07 < TkTech> Lies, the internet said you did
21:07 < Fenhl> I wrote http://wiki.vg/Pre-release_protocol#Chunk_Section
21:07 <+Grum> http://wiki.vg/Pre-release_protocol#Chunk_Data <-- that one is not up2date
21:08 < Conji> It's on the site :v
21:08 < Fenhl> …
21:08 <+Grum> hmm that is wrong btw
21:08 <+Grum> PaletteLenght is varint
21:08 < Fenhl> what's not up to date there?
21:09 <+Grum> ah no i see
21:09 <+Grum> the Palette Lenght is not correct
21:09 <+Grum> that is a varint iirc
21:09 < Fenhl> okay, you said byte last time, changed now
21:09 <+Grum>         buffer.writeVarInt(size); <-- quite sure
21:09 <+Grum> no byte is for the 'bitsize'
21:10 < Fenhl> the Bits Per Block field?
21:10 <+Grum> the very first bit of data
21:10 <+Grum> aye
21:10 < Fenhl> okay
21:10 <+Grum> that is a byte
21:10 < Fenhl> should be correct now
21:10 <+Grum> signed or not matters little in that case, values over 32 would be utterly pointless :p
21:11 < Fenhl> right, but a negative value even more so
21:12 <+Grum> true, but its written as signed byte :p
21:12 < Fenhl> implementation detail ¯\_(ツ)_/¯
21:13 < Conji> So question.
21:13 < Fenhl> ah I see, it's on SMP Map Format
21:14 < Conji> It is recommended I palette the chunk data to conserve data, correct?
21:14 < Conji> Even though it IS optional to use 13 bits per block
21:14 <+Grum> you will just waste memory on the client
21:14 < Conji> Alright.
21:15 < Conji> _Whatever makes the client happy_
21:15 <+Grum> it makes the server happy to, it just sends its raw data ;)
21:15 < Fenhl> I'm going to remove pre-release info from that article and add a “see also” link to [[Pre-release protocol]] instead
21:15 < Conji> Well damn, entity metadata is also changed
21:16 < Conji> I find it funny I started this server with 1.7 and here I am trying to get it to work nicely with 1.9
21:28 < Conji> It says data array length is number of bytes divided by 8
21:28 < Conji> Shouldn't it be multiplied by 8 since it's bit length?
21:48 < Fenhl> no
21:49 < Fenhl> Data Array is an Array of Long internally
23:18 <+Amaranth> Grum: With this new code you could get rid of the logic for not allocating empty full sun sections too
23:19 <+Amaranth> They'll take a few bytes vs zero but you won't have to deal with null checks everywhere
23:20 <+Amaranth> Hmm, I guess 512bytes is the smallest you could go there without special casing things inside the storage
--- Day changed mer. sept. 09 2015
00:41 <+Thinkofdeath> Amaranth: well I tried rust, http://hastebin.com/jutilolavi.tex I can connect to servers in online mode at least.
00:42 <+Thinkofdeath> the code is horrible though
00:42 <+Amaranth> neat
00:43 <+Thinkofdeath> its really weird getting used to it
00:44 <+Amaranth> Thinkofdeath: https://github.com/PistonDevelopers/hematite_server/blob/master/src/packet.rs might be interesting to look at
00:45 <+Amaranth> Bit heavy on the magic there
00:45 <+Thinkofdeath> I looked at that for ideas
00:45 <+Thinkofdeath> Amaranth: https://gist.github.com/thinkofdeath/a8fa24856426299a6c3b
00:46 <+Thinkofdeath> when I realised macros existed I /may/ have gone over the top
00:46 <+Amaranth> hehe
00:46 <+Amaranth> You wrote your own OpenSSL binding?
00:47 <+Thinkofdeath> yeah the existing one was missing parts
00:47 <+Amaranth> I guess I shouldn't be surprised, I "tried" rust by implementing most of rust-sdl2 back in the day :D
00:47 <+Thinkofdeath> lol
00:49 <+Thinkofdeath> I do miss go's stdlib when using rust, not used to having to use external deps for things like crypto and zlib
00:49 <+Amaranth> Yeah, that's kind of on purpose
00:49 <+Amaranth> Back in the day the thought was that rust's stdlib would be batteries included but things just weren't ready
00:49 <+Amaranth> Now I think the plan is to not significantly expand the stdlib
00:50 <+Amaranth> Which is funny because in some ways C++ has a more fleshed out stdlib and they think theirs is too small
00:50 <+Thinkofdeath> hehe
00:50 < Fenhl> > thread 'protocol::test' panicked at 'TODO!'
00:51 < Fenhl> 10/10
00:51 <+Thinkofdeath> Amaranth: oh since you know rust i'm I crazy or is there no easier way to do this https://gist.github.com/thinkofdeath/a8fa24856426299a6c3b#file-mod-rs-L176 it seems really long
00:51 < Fenhl> Thinkofdeath: there's an unimplemented! macro for this btw
00:51 <+Thinkofdeath> psh
00:51 <+Thinkofdeath> I just needed stdout to print
00:52 < Fenhl> huh?
00:52 <+Thinkofdeath> stdout doesn't when tests work
00:53 <+Thinkofdeath> I just hardcoded a panic as the first thing I did
00:53 <+Thinkofdeath> unimplemented would work too
00:55 < Fenhl> without having read most of the code, I don't see how that line requires all these type constraints
00:55 < Fenhl> if they are needed, Into and From are in the prelude so you don't need the convert:: prefix
00:57 <+Amaranth> I don't think you can use type for this but you could make a new trait that requires all of those, implement it for everything that satisfies those, and then just require your trait
00:58 <+Amaranth> pub trait Foo: Any + Whatever {} impl<T: Any + Whatever> Foo for T {}
00:58 <+Amaranth> I think that'll work
00:59 <+Thinkofdeath> https://gist.github.com/thinkofdeath/c43de2c2690e97595969 I realised that I only needed them on the impls that used them not on all of them
00:59 <+Thinkofdeath> Amaranth: that works?
00:59 <+Amaranth> Pretty sure
01:01 <+Amaranth> I'm doing something like that to do something ugly because of rust's lack of variadic generics
01:02 <+Thinkofdeath> it worked, thanks :)
01:03 <+Amaranth> Actually I guess I'd have to do this with or without variadic generics
02:53 < Doxin> so I'm trying to implement a minecraft protocol parser in D, but I'm having trouble getting 0x00 handshake parsed. I keep having bytes left over and nextstate being invalid.
02:53 < Doxin> see http://paste.pound-python.org/show/HGFp9qZmZs0F2htr1jAP/ for the code that's relevant
02:53 < Doxin> can anyone see what I'm doing wrong?
03:02 < roblabla> Doxin, your parseUshort is most likely wrong
03:02 < roblabla> you're parsing everything up 'till the port properly
03:02 < Doxin> right
03:02 < roblabla> the port is 99, 221, which equates to 25565
03:02 < Doxin> right
03:02 < Doxin> huh, it should be gobbling up two bytes...
03:02 < roblabla> yet your thing gives something off, so I suppose it's wrong. Can you post the code ?
03:03 < Doxin> sure
03:03 < Doxin> roblabla: http://paste.pound-python.org/show/o0lmZ2grjvW58SIuhfEj/
03:04 < roblabla> right
03:04 < roblabla> I see the problem
03:04 < Doxin> :D
03:04 < Doxin> do tell!
03:04 < roblabla> Doxin, you forgot to increment offset in readString, didn't you ?
03:05 < Doxin> I very well did
03:05 < roblabla> :3
03:05 < roblabla> D looks fun
03:05 < Doxin> it is
03:06 < Doxin> it's awesome
03:06 < Doxin> it's what c++ should have been really
03:06 < roblabla> heh
03:06 < Doxin> ServerHandshake(47, "localhost", 56675, 1), that looks better, now to fix byte order :P
03:06 < roblabla> Heh, C++ should have been many things
03:06 < roblabla> and in a way, it did achieve being many things. That's not necessarely a good achievement :P
03:07 < Doxin> :P
03:07 < Doxin> ServerHandshake(47, "localhost", 25565, 1) there we go.
03:07 < roblabla> yay
03:29 < Not-f7bb> [SpockBot] gamingrobot pushed 1 commit to master [+0/-1/±0] http://git.io/vZsRa
03:29 < Not-f7bb> [SpockBot] gamingrobot 1e1c4eb - Delete TODO.md
03:29 <+ammar2> there's actually a bunch of D fanatics in here
03:29 <+ammar2> *cough* dav1d Prf_Jakob 
03:30 < Doxin> neat-o
03:42 < Conji> Question just to verify. In the data array, each byte is an index of the palette, correct?
04:12 <+XorBoole> did someone say D?
04:17 <+ammar2> not the D you like XorBoole 
04:17 <+ammar2> we're talking about the language
04:23 < dx> :D
04:38 < Conji> #rekt
07:22 < Not-f7bb> [SpockBot] nickelpro pushed 2 commits to master [+38/-2/±12] http://git.io/vZshM
07:22 < Not-f7bb> [SpockBot] gamingrobot c545b32 - Add initial documentation
07:22 < Not-f7bb> [SpockBot] nickelpro 1b5d650 - Merge pull request #113 from gamingrobot/update-docs
07:27 < Not-f7bb> [SpockBot] gamingrobot pushed 8 commits to master [+4/-2/±27] http://git.io/vZsjc
07:27 < Not-f7bb> [SpockBot] nickelpro 34fad28 - Entity changes to ease certain tasks
07:27 < Not-f7bb> [SpockBot] nickelpro d3660b5 - A great of of work implementing notchian physics
07:27 < Not-f7bb> [SpockBot] nickelpro dea1b11 - move -> movement
07:27 < Not-f7bb> [SpockBot] ... and 5 more commits.
08:19 <+Grum> [23:18:40] <+Amaranth> Grum: With this new code you could get rid of the logic for not allocating empty full sun sections too <-- yeah perhaps later
09:20 < Not-f7bb> [SpockBot] gamingrobot pushed 2 commits to master [+0/-0/±2] http://git.io/vZG3Z
09:20 < Not-f7bb> [SpockBot] gamingrobot 963fb5c - Simplified pathfinding
09:20 < Not-f7bb> [SpockBot] gamingrobot 4591db7 - Merge pull request #116 from gamingrobot/f-movement
09:37 < Not-f7bb> [SpockBot] gamingrobot pushed 3 commits to master [+0/-0/±3] http://git.io/vZGZH
09:37 < Not-f7bb> [SpockBot] gamingrobot 51921d3 - Add logging of what plugins are loaded
09:37 < Not-f7bb> [SpockBot] gamingrobot 9b580d4 - Fix logging of plugins loaded before main loop
09:37 < Not-f7bb> [SpockBot] gamingrobot 0611bbe - Merge pull request #117 from gamingrobot/f-logplugins
10:50 < Not-f7bb> [SpockBot] gamingrobot pushed 2 commits to master [+0/-0/±4] http://git.io/vZGaM
10:50 < Not-f7bb> [SpockBot] gamingrobot 95ee2cf - Updated example to use the new api's
10:50 < Not-f7bb> [SpockBot] gamingrobot c436579 - Merge pull request #119 from gamingrobot/u-example
12:09 <+Thinkofdeath> Fenhl: finally got around to updating the packet ids http://wiki.vg/Pre-release_protocol#Packets Not sure what you want to do with the packets on the page though
12:11 < Fenhl> I think I'm just going to remove packets which only changed ids
12:12 < Fenhl> and include the changed packet id in the remaining ones
12:13 < Not-f7bb> [SpockBot] gamingrobot pushed 1 commit to master [+0/-0/±1] http://git.io/vZG5a
12:13 < Not-f7bb> [SpockBot] gamingrobot 5fd843e - Remove string_types
12:13 < gamingrobot> oh thats a lot of commits
12:15 < Emile_> hi
12:15 < Emile_> Was wandering what it means if the clients sends a packet of length 0
12:16 < Emile_> as in the bytes it sends is zero
12:16 <+Thinkofdeath> it shouldn't happen
12:16 <+Thinkofdeath> although I think 1.7 had a bug that causes that
12:24 < Emile_> cool thx should i just egnor the pacet or respond
12:24 < Emile_> (im dyslexsic sorry)
12:26 <+Thinkofdeath> ignore
12:28 < Emile_> cool and i cant seem to find this packet on wiki ?
12:28 < Emile_> ?
?  M C | P i n g H o s t    l o c a l h o s t  c? Packet id: 122
12:28 <+Thinkofdeath> thats the pre 1.7 ping packet
12:29 < Emile_> ah so why is my 1.8.8 offical client sending that
12:30 <+Thinkofdeath> it does that if it encounters an error pinging the server
12:30 <+Thinkofdeath> it assumes its a really old one
12:31 < Emile_> ok becuse im geting the handshake and the right after that i get a zero packet and the the old ping
12:33 <+Thinkofdeath> oh by zero-length packet were including the packet id?
12:33 < Emile_> well yes