20:36 < kvgeorge1> or is it that the client tells the server to update the item counts in the slots
20:37 <+Amaranth> Some of this is handle client side so I don't know off hand
20:38 <+Amaranth> The server can override however it wants but by default the client knows what the recipes are so does some of the logic itself
20:40 < Gjum> kvgeorge1: got the same problem atm, not fun
20:41 < kvgeorge1> so, here's the deal.  I have a plugin I am writing for a non-bukkit server.  I can force the client to handle custom recipes and show the result in the client by forcing a SetSlot at the server to the client on a confirmation transaction (0x32) and this works great
20:42 < kvgeorge1> However, if the user then clicks on the item that gets set in slot 0 of the crafting bench, the client does not update the inventory slots in the crafting bench.
20:42 < kvgeorge1> even with vanilla recipes.  If I remove my code, it works fine
20:42 < Gjum> do you send the coddect window ID?
20:42 < Gjum> *correct
20:43 < kvgeorge1> I am just trying to get the client to update the counts/remove items for each time the user crafts the item via the protocol
20:43 < kvgeorge1> um....yes, I believe so.
20:43 < kvgeorge1> I am getting the ID from the packet itself and just passing that along
20:43 < Gjum> ok
20:44 < kvgeorge1> if the user crafts the item, places it in their player inventory, then clicks on the items in the crafting slots, they then update
20:44 < kvgeorge1> I believe this is from a 0x2F packet
20:44 < Gjum> should be
20:44 < kvgeorge1> but this is not the normal behavior and I wanted to send the right information along to the server
20:45 < kvgeorge1> which is a set slot - right (0x2f)
20:45 < Gjum> or 0x30, which would send the complete crafting table?
20:45 < kvgeorge1> hmmm....
20:45 < kvgeorge1> so, if the user clicks on an item in the crafting table, should I send a 0x30 to reset the table?
20:45 < Gjum> you could try... :D
20:45 < kvgeorge1> :D
20:46 < kvgeorge1> so, would I have to do this by trapping when the user clicks the mouse and the slot is 0?
20:47 < kvgeorge1> I'm guessing that is a 0x0E serverbound packet - correct?  To trap the mouse event?
20:48 < Gjum> yup
20:48 < Gjum> don't forget to confirm with 0x0f
20:48 < kvgeorge1> cool, I will give it a shot
20:48 < kvgeorge1> thx
20:49 < Gjum> don't think he read that ^^
20:50 < gamingrobot> I did find a issue if you spam sending click events, atleast in the case of spigot it only accepted the first 3, havent tested on vanilla
20:53 < Gjum> did spigot return not-accepted or ignore it?
21:22 < morfin> hmmm
21:23 < morfin> does really client allow using custom recipes?
21:27 <+Amaranth> You can do custom recipes with command blocks even
21:27 <+Amaranth> I don't know how that actually works
21:36 < Thinkofdeath> Removing recipes is slightly harder due to client prediction
21:54 < morfin> hmm
21:57 < Gjum> gonna push that later when im done with some more stuff tho
21:57 < Gjum> wrong channel :P
--- Day changed ven. févr. 13 2015
05:49 < benbaptist> ohai, what does the 'bungeecord' option do in Spigot's spigot.yml? Does it allow some extra 
05:49 < benbaptist> packets to be sent to force UUIDs or something?
05:53 <+SpaceManiac> it enables use of the 'hostname' field in the handshake to encode the user's UUID and properties (i.e. skin)
05:53 <+SpaceManiac> BungeeCord can then inject into this field the data it got from the login server for the player
05:54 < benbaptist> awesome. Would I be able to use this for my own proxy project, to allow UUIDs to remain consistent 
05:54 < benbaptist> damn enter key!
05:55 < benbaptist> to remain consistent after Spigot's own online-mode is set to False?
05:55 <+SpaceManiac> I would expect you would be able to
05:57 <+SpaceManiac> the format is something like... <real hostname> \0 <client ip address> \0 <client uuid, no dashes> (optional) \0 <json: properties from login server>
05:57 <+SpaceManiac> "optional" applying to the properties field, that is
05:59 < benbaptist> ah, okay.
05:59 < benbaptist> and is \0 just the 0x00 byte?
05:59 <+SpaceManiac> aye
05:59 < benbaptist> okay awesome~!
05:59 < benbaptist> awesome!*
06:00 < benbaptist> thanks man. I'm gonna try implementing this into Wrapper.py now :P
06:02 < dcbartlett> con someone explain how to use position of the chat protocol?
06:02 <+SpaceManiac> 0 and 1 both appear in the chat as normal. 2 causes the message to appear above the hotbar, where jukebox "Now playing" messages go
06:04 < benbaptist> here's a screenshot of the hotbar text, dcbartlett http://s.benbaptist.com/mTY7J.png
06:04 < benbaptist> (as you can see, it's slightly higher than the selected-item text)
06:11 < dcbartlett> right
06:11 < dcbartlett> i'm working on porting a server over to JS and trying to figure out how to send the parameters of for it
06:11 < dcbartlett> this is what i currently use to send messages
06:11 < dcbartlett> lient.write('chat', { message: JSON.stringify(msg) });
06:12 < dcbartlett> where
06:12 < dcbartlett> var msg = {
06:12 < dcbartlett>     "text": "Some text here"
06:12 < dcbartlett>   };
06:15 < dcbartlett> http://wiki.vg/Chat
06:15 < dcbartlett> this page doesn't really say how to send the position over
06:16 <+SpaceManiac> the position is another field in the packet
06:16 <+SpaceManiac> probably like... { message: ..., position: 0 }
06:16 < dcbartlett> OH
06:16 < dcbartlett> probably at the same level as 'chat'
06:16 < dcbartlett> i think i get it
06:17 < dcbartlett> yes
06:17 < dcbartlett> yes that makes sense
06:25 < dcbartlett> hum
08:55 < morfin> hm 
08:55 < morfin> so if client predicts default crafting recipes(probably to avoid waiting for server response lag) it's hard to remove default recipes?
17:03 < gurun> what's the best implementation of picking up dropped itemns. Having the player check surroundings on move, or having the entity check players on tick?
17:04 < gurun> object oriented wise, cleanest is having the entity item figure it out.
17:08 < toqueteos> guys i'm following the Protocol FAQ, sending "LoginStart, LoginSuccess, LoginSetCompression, JoinGame, SpawnPosition, PlayerAbilities, WindowItems, ChunkData, PlayerPositionAndLook" packets but it seems to get stuck on WindowItems or PlayerPositionAndLook; vanilla client crashes with this error: http://i.imgur.com/bbr8Zat.png any advice?
17:10 < gurun> if you don't know which one, comment out the code until you do.
17:11 < gurun> it looks like you are sending a lenght that is not correct and when it is parsing its reading beyond the stream, or someting like that.
17:11 < gurun> and windows items could be one such thing..
17:13 < toqueteos> well it seems ClientSpawnPosition may be the one causing it
17:16 < toqueteos> damn varints
17:17 < Xor_Boole> can anyone find a usecase for `interface AutoFunc<A> extends Function<A, AutoFunc<A>>`
17:20 < gurun> yes, i have similar in my code for the object pool
17:21 < Xor_Boole> gurun really? what's the use?
17:21 < gurun> hmm .. actally, looking at it now. I removed it. Was too weird. It had to do with inheritance of generic methods, where i used the generic class as input or return on methods.
17:22 < gurun> then it needed that shit.
17:22 < gurun> really weird.
17:22 < gurun> but i remeber now .. thanks to resharper, it help me simplfy the code.
17:23 < gurun> now it looks much more simple: Package<T> : Package, ICloneable where T : Package<T>, new()
17:23 < gurun> hihi
17:24 < gurun> basically it says that Package<T> .. where T has to be a Package<T> :-P
17:24 < Xor_Boole> no, no, that's not it
17:24 < gurun> no, that's the new code
17:24 < Xor_Boole> I mean a function that returns a function of the same type
17:25 < gurun> well, chained commands perhaps?
17:25 < gurun> like fluent interface implementation .. return "this" kind of thing.
17:25 < Xor_Boole> no, I mean f.apply(x).apply(x).apply(x).apply(x).apply(x).apply(x).apply(x)
17:25 < gurun> yes
17:25 < gurun> fluent !
17:25  * Xor_Boole facepalms
17:26 < Xor_Boole> in mathematica notation: f : X -> X -> X -> ...
17:26 < Xor_Boole> mathematical*
17:26 < Xor_Boole> mathematica has no types =p
17:26 < gurun> rect.Rotate(r).Move(1,1,1).Screwup(bad);
17:26 < Xor_Boole> not at all what I mean
17:27 < gurun> hm, so not acumulated .. transformations .. still looks like fluent code to me.
17:27  * Xor_Boole sighs and goes back to his electromagnetism homework
17:27 < gurun> Xor_Boole: you know what fluent interfaces are, right?
17:28 < Xor_Boole> gurun yes, and they're not what I mean
17:28 < Xor_Boole> I am speaking of a function, not an object
17:28 < gurun> yeah, me too
17:29 < Xor_Boole> the function wouldn't necessarially return itself
17:29 < gurun> that's why i wrote "chained commands". Because rule-engine code often look like that.
17:29 < Xor_Boole> just another function that will return another function and so on
17:30 < gurun> "this" was not in the "object.this" sense, no.
17:30 < gurun> it was "self" .. but could of course be a new SameShitFuntionPointerOfSameType() kind of thing
17:30 < Xor_Boole> I think a better restriction for this would be in a functional, immutable environment
17:31 < Xor_Boole> actually, can you declare such a thing in haskell?
17:31 < gurun> i think you already realized what the problem is here.. you are doing haskell :-)
17:32 < Xor_Boole> how is that a problem?
17:32 < gurun> hehe, yes lets have a friday bar brawl over languages :-P
17:32 < gurun> i'm just kidding
17:32 < Xor_Boole> C# sucks lololololol
17:32 < gurun> damn
17:33  * gurun throws a punch towards Xor_Boole and simultainously finish his pint..
17:35 < Xor_Boole> lel
17:40 < toqueteos> what the hell.. it was actually the SetCompression packet, apparently it doesn't like -1 as threshold
17:44 < nickelpro> toqueteos: works for me
17:45 < nickelpro> -1 threshold should disable proto compression
17:45 < toqueteos> nickelpro: aaaand now it's working again, this is driving me nuts
17:45 < toqueteos> yeah, i want -1 because i don't have compression support implemented yet
17:45 < toqueteos> i just wanted to know if packets were working as expected
18:12 < toqueteos> nickelpro: may i ask how you if your "join game" packet is same as http://wiki.vg/Protocol#Join_Game ?
18:12 < toqueteos> it's the one causing me problems, yours seem to be working nicely
18:13 < nickelpro> my implementation is 100℅ based on the wiki
18:13 < morfin> returning to networking
18:14 < morfin> soo minecraft switch to reading/writing in same time when connected to server
18:14 < nickelpro> toqueteos: you have code up somewhere?
18:14 < morfin> and i have to push everything into queue
18:15 < nickelpro> lol, a queue, why?
18:15 < toqueteos> nickelpro: yes i do, it's rust though
18:15 < toqueteos> nickelpro: https://github.com/toqueteos/hematite_server/blob/master/src/common/packet/mod.rs#L125
18:15 < morfin> what's wrong about handling queue from several threads?
18:16 < nickelpro> toqueteos: I can manage, I'll look at it when I get home if you haven't fixed it by then
18:17 < toqueteos> i'm sending hardcoded values right now "ClientJoinGame entity_id=131072 gamemode=0 dimension=0 difficulty=2", which their correct types
18:17 < toqueteos> entity_id comes from nowhere so i suppose i create one myself
18:17 < toqueteos> nickelpro: no need to check a thing, just curious if eid was actually a varint but misstyped on wiki or something
18:18 < morfin> so nickelpro
18:18 < morfin> why do you think queue is bad?
18:18 < nickelpro> in that case, you're good as far as protocol types go
18:19 < nickelpro> morfin: why do you need it? just send bytes when the socket is ready and read them when it has something to read. That is the whole point of netty
18:19 < morfin> don't forget you're async..
18:20 < morfin> i am trying to implement own basic server: that's first my target
18:20 < morfin> and queue would be implemented for inbound packets 
18:21 < morfin> so i read data -> push into queue -> handle from separate threads
18:22 < nickelpro> Seems excessive, just read and hand off to a dispatcher to update the world state. If a part of the world state is not thread-safe put a lock on it
18:23 < nickelpro> Queue are for when you have a dozen worker threads handling arbitrary jobs
18:25 < morfin> i am not going to have lots of workers(maybe like 2-3-4)
18:27 < morfin> but i am thinking about scalability
18:38 < gurun> yes, queues are good.
18:38 < gurun> a must for anything a bit serious.
18:38 < gurun> but if not, then just "complex"
19:39 < morfin> anyway i will have to use strand
--- Day changed sam. févr. 14 2015
14:50 < Wuppie> hmm weird, my block placement works fine, except when 1 or more of the coordinates are below 0...
14:56 < Grum> Wuppie: you math wrong with truncation rather than proper flooring
14:59 < Wuppie> Grum, i guess that could be it yes :) thanks, ill look at that
14:59 < Grum> we had that mistake lots of times hehe
15:00 < Paprikachu> Grum: what can i do if i know my username & password, but not my security questions, and so i cant change my email
15:00 < Grum> where people went: 'oh yeah i just need to remove the fractional part to get to the block coordinate'
15:00 < Paprikachu> actually, i think i might know one of the questions or something
15:00 < Grum> Paprikachu: get an account you own ;D
15:00 < Paprikachu> or what they approximately are
15:00 < Paprikachu> uh, its mine
15:00 < Grum> no-one at mojang can see the answers to the question
15:00 < Paprikachu> thing is, i don
15:01 < Paprikachu> i don't have access to the email anymore
15:01 < Paprikachu> are you able to change my email?
15:02 < Grum> yes and CS is if you can prove the account is yours
15:02 < Paprikachu> CS?
15:02 < Grum> customer support
15:02 < Paprikachu> how would i prove that?
15:02 < Grum> transaction id of purchase will always work
15:02 < Paprikachu> i bought the key on some website years ago
15:02 < Paprikachu> the company doesn't even exist anymore
15:03 < Paprikachu> (i bought it cause they let me use psc)
15:03 < Paprikachu> do you guys store activation keys?
15:03 < Paprikachu> i might be able to find mine
15:04 < Grum> yes
15:05 < Paprikachu> nice i found it
15:05 < Paprikachu> i bought 10 keys back then so i dunno which one it is
15:05 < Paprikachu> what should i do now
15:05 < Grum> not buy second hand accounts ;)
15:05 < Grum> and contact customer support :)
15:06 < Paprikachu> they sold me 10 keys for 50 euros :P
15:06 < Paprikachu> how can i say no :D
15:07 < Grum> good luck regaining access to your stole^hresold accounts
15:07 < Paprikachu> eh
15:07 < Paprikachu> i doubt they're stolen
15:07 < Grum> almost 100% sure they are
15:08 < Grum> you bought giftcodes?
15:08 < Paprikachu> uh... idk? keys?
15:08 < Paprikachu> not sure if that's the same
15:08 < Wuppie> i remember the time where you could fake payments on minecraft.net
15:08 < Wuppie> xD
15:08 < Grum> probably
15:08 < Grum> your account even works Paprikachu? :/
15:08 < Paprikachu> it does
15:08 < Paprikachu> i play on it
15:09 < Grum> did you use all your keys?
15:09 < Paprikachu> i sold 9 of them
15:09 < Paprikachu> i would assume the people who bought them used them
15:09 < Grum> that domain ... geez
15:09 < Paprikachu> ?
15:10 < Grum> your username? :)
15:10 < Paprikachu> oh :P
15:10 < Paprikachu> what about it
15:10 < Wuppie> he gonna ban u
15:10 < Wuppie> xD
15:10 < Paprikachu> inb4
15:10 < Grum> haha that is not even possible
15:10 < SinZ> yet
15:10 < Paprikachu> ^
15:10 < Grum> at all
15:10 < Grum> there is no need for us to ban anyone
15:10 < Grum> that is up to servers
15:10 < Wuppie> haha lol
15:11 < Paprikachu> inb4 customer supports bans all the accounts whose keys i send them
15:11 < Paprikachu> -s
15:11 < Grum> how would customer support know whihc keys those were?
15:12 < Paprikachu> ?
15:12 < Paprikachu> i thought you store them in a db
15:12 < Paprikachu> just select the ones where the key matches :p
15:12 < Grum> matches against what? something our magic ball shows?
15:13 < Paprikachu> huh?
15:13 < Wuppie> yes, you are mojang. you got magic grum! :)
15:13 < Paprikachu> if i send customer support "my key is one of {A, B, C, ...}"
15:13 < Wuppie> Can i get a free hug btw?
15:13 < Grum> Paprikachu: i could look up which one it is if you want
15:13  * Grum hugs Wuppie for free
15:13 < Paprikachu> oh im sure i got the right one
15:13 < SopaXorzTaker> oh hi grum
15:13 < Paprikachu> but uh
15:13 < Wuppie> thanks Grum <3
15:13 < Paprikachu> -> query
15:14 < SopaXorzTaker> Mojangstas give free hugs?
15:14 < Grum> sure
15:14 < SopaXorzTaker> :3
15:14  * Wuppie has a huge smile on his face because he got a free hug from Grum
15:14  * SopaXorzTaker wants too
15:15 < Grum> i just have one per day! :P
15:15 < Grum> well ok
15:15  * Grum hugs SopaXorzTaker
15:15 < SopaXorzTaker> thanks!
15:23 < morfin> hmmm
20:16 < gurun> why the heck is yaml so popular in the MC community?!
20:51 < angal> Couse it simple?
21:34 < nickelpro> Because its a readable, easily parsable, configuration format. What would you have us use?
21:35 < dx> hocon :^D
23:57 <+Amaranth> dx: Is there a second implementation of hocon?
23:57 <+Amaranth> Or still just the scala one
23:58  * dx was not seriously suggesting it
23:58  * dx does not care about hocon at all
23:58 <+Amaranth> hehe
23:58 <+Amaranth> It's pretty neat
23:58 <+Amaranth> But also pretty complicated
23:59 < dx> i know some people like it, i'm not one of those. mostly out of indifference though
23:59 <+Amaranth> Otherwise there is also toml
--- Day changed dim. févr. 15 2015
00:01 < gurun> XML
00:02  * dx still uses xml configs in a certain project that was created 10 years ago when it was cool
00:03 <+Amaranth> hehe, I'm not sure it was ever cool for configs, it was very enterprise-y though
00:03 <+Amaranth> But yeah, 10 years ago using it for data was a no brainer
00:03 < dx> it's fairly minimalist xml, not meant to be directly editable by users (although definitely possible), and i don't see any good reason to bother about changing it
10:13 < morfin> YAML easy parsable ha-hahash-
10:14 < morfin> it's harder to parse than XML/JSON/INI/anything else
10:16 < morfin> at least because it have 210 lexemes 
12:58 < morfin> so
13:00 < morfin> i had a question: what if i have disconnect request when already sending something to that client
13:01 < gamingrobot> serverside or client side?
13:02 < morfin> server 
13:02 < morfin> does it just hmm interrupt?
14:03 < morfin> as example some packets are big
14:03 < Grum> no
14:03 < Grum> but you can just close the connection
14:03 < Grum> that will stop it :)
14:42 < morfin> oh probably but i am not sure how boost would like that 
16:19 < Bibl> damnit i broke something http://i.imgur.com/SEw2pwR.png
16:56 < dx> https://imgur.com/gallery/jdNA6
16:56 < dx> relevant to this channel because this guy is the same guy who wrote avrcraft, that one mc server for 8 bit devices
20:56 < toqueteos> how weird is that sending position (0, 64, 0) is read by vanilla client as (8500, 128, 8500)
20:57 < toqueteos> impl follows wiki.. i don't get it http://is.gd/gVR99D
21:06 < Paprikachu> did you reverse the bytes?
21:06 < Paprikachu> did you send it correctly?
21:09 < toqueteos> i'm sending the long value as big endian
21:11 < Paprikachu> did you shift it correctly?
21:12 < Paprikachu> mh
21:12 < Paprikachu> maybe something else is wrong
21:12 < Paprikachu> looks correct
21:12 < Paprikachu> though << 38 >> 38 is really dumb
21:24 < Bibl> disconnects at line 32 
21:24 < Bibl> http://hastebin.com/icibamadoh.hs
21:25 < Bibl> wtf is happening
21:26 < toqueteos> Paprikachu: wait what?
21:27 < toqueteos> oh, nvm, z decoding..
21:28 < toqueteos> Bibl: you are sending chat messages a bit too soon?
21:28 < Bibl> toqueteos: thats receive
21:29 < toqueteos> server is sending chat messages*
21:29 < Bibl> yeah it joins fine 
21:29 < toqueteos> where's the player pos + look to confirm client can spawn?
21:29 < Bibl> then something is off
21:29 < toqueteos> playermove?
21:30 < Bibl> it actually joins ingame http://i.imgur.com/HY56Lye.png
21:30 < Bibl> and in console http://i.imgur.com/yKWP13I.png
21:30 < Bibl> its always 26
21:31 < toqueteos> what are you using?
21:31 < toqueteos> vanilla server, custom client?
21:34 < Bibl> writing my own client, spigot server
21:37 < Bibl> turned server compression from 256 to 0 and the client can join and play just fine
21:40 < Bibl> toqueteos: what are you supposed to do if the packet is smaller than the compression threshold?
21:40 < Bibl> like if its bigger then you compress it but if its smaller?
21:41 < Paprikachu> set compressed size to 0
21:41 < Paprikachu> and dont compress it
22:00 < Bibl> aight figured it out:
22:01 < Bibl> i have a client class like this: http://i.imgur.com/6f8XbM8.png
22:01 < Bibl> has the compressionThreshold field with a getter and a setter
22:01 < Bibl> my TcpClient class extends that Client class http://i.imgur.com/wGtcm4b.png
22:02 < Bibl> but it had the compressionThreshold field in it 
22:02 < Bibl> and i was overriding the setter so that I could add a netty codec when i set compression but it wasnt editing the same field that the getter was referencing
22:02 < Bibl> not sure how it was working all this time before though
--- Day changed lun. févr. 16 2015
14:33 < ellisvlad> Hmm
14:33 < ellisvlad> I'm having trouble with implementing authentication on a player login..
14:33 < ellisvlad> I'm using https://sessionserver.mojang.com/session/minecraft/hasJoined?username=username&serverId=hash
14:34 < ellisvlad> for one of my accounts, a legacy account, that works fine.. With the other, a mojang account, it just returns a 204 No Content..
14:34 < ellisvlad> Anyone have any idea why? :P
15:13 < Bibl__> ellisvlad: let me get dressed then ill check
15:20 < Bibl__> lol nvm, i didnt implement that in my auth library because ive never needed a use for it
15:22 < Bibl__> ellisvlad: did you encode the email address properly?
16:59 < ellisvlad> Bibl__: Encode the email address? I've just been using their username in https://sessionserver.mojang.com/session/minecraft/hasJoined?username=username&serverId=hash
17:38 < morfin> btw interrupting connection when writing is probably bad
18:11 < Bibl__> ellisvlad: sorry for the late reply, what language are you using?
18:11 < Bibl__> or are you just using the browser?
18:16 < Bibl__> ellisvlad: http://hastebin.com/erodofokex.avrasm
18:16 < Bibl__> you need to encode the email address
19:22 < morfin> he-he i think i started to understand some of Minecraft design decisions
19:59 < morfin> how do you think there no better way to calculate explosions than Minecraft have?
20:00 < shoghicp> morfin: what do you mean? that it's good, or bad?
20:00 < morfin> i am not sure is that good 
20:01 < shoghicp> for big explosions, there are better ways to do it
20:01 < shoghicp> for small ones, you want to have blocks harder or softer
20:01 < morfin> 1352 rays for each explosion
20:01 < morfin> and lots of checks for materials
20:01 < shoghicp> you could do it on a different similar way, and it *might* work
20:02 < shoghicp> but yeah, wastes lots of resources :)
20:02 < morfin> just thinking is there more performant way hmm
20:03 < shoghicp> for explosions aligned on the grid, maybe
20:03 < morfin> how they can be unaligned?
20:03 < shoghicp> but remember that they can be anywhere on the grid
20:03 < shoghicp> tnt
20:03 < shoghicp> it's an entity
20:03 < morfin> oh wait flying
20:03 < morfin> looooool
20:03 < morfin> it can fly over world and make boom
20:04 < morfin> so it can explode between blocks edge or something like that
20:04 < shoghicp> yep
20:05 < morfin> Notch->kill("fire")
20:07 < morfin> btw how that's being calculated?
20:08 < shoghicp> what thing?
20:08 < shoghicp> explosions?
20:08 < morfin> yes
20:08 < morfin> if they explode on edge
20:08 < morfin> as example
20:08 < shoghicp> it's just a raytrace from the center of the explosion
20:08 < shoghicp> in all directions
20:08 < morfin> yep i know
20:08 < morfin> but hmm 
20:09 < shoghicp> I think it's on a few pages elsewhere more detailed :P
20:09 < morfin> http://minecraft.gamepedia.com/Explosion
20:09 < shoghicp> had to implement it for PocketMine
20:09 < morfin> was looking at this
20:10 < shoghicp> https://github.com/PocketMine/PocketMine-MP/blob/master/src/pocketmine/level/Explosion.php#L92-L120
20:11 < shoghicp> basically reduces the strength of a ray in 0.3 increments
20:11 < shoghicp> as it goes past a block
20:14 < shoghicp> hmm
20:15 < Paprikachu> a minecraft server in php?
20:15 < Paprikachu> was your goal to create the slowest server possible?
20:16 < morfin> lol
20:16 < morfin> let's explode 1000 TNT blocks on your serverr)
20:17 < morfin> and let your PHP script crash with fatal error out of memory
20:17 < shoghicp> morfin: it works! I had to try it :P
20:17 < Paprikachu> i can't believe someone actually started implementing a server in php
20:17 < shoghicp> Paprikachu: the goal was to document the protocol, but people started using it and wanted things D:
20:18 < Paprikachu> it's like
20:18 < Paprikachu> you choose the worst language ever designed
20:18 < Paprikachu> for the slowest game ever made
20:18 < morfin> lol
20:18 < Paprikachu> with the worst protocol ever
20:18 < shoghicp> +1
20:18 < morfin> Minecraft is not so slow if properly design server
20:18 < shoghicp> at least it uses less memory that the normal mc server
20:18 < shoghicp> and handles 80 players pretty ok on normal hardware
20:19 < Paprikachu> lol
20:19 < Paprikachu> 80 players doesn't even show up in cpu usage on my c++ server
20:20 < shoghicp> players itself are not the cause, but having them spread around the world and ticking chunks :)
20:20 < shoghicp> I'm not aiming for performance itself now, but extensibility by plugins
20:20 < morfin> i am developing own server for fund 
20:20 < morfin> *fun
20:20 < Paprikachu> that's already a thing
20:20 < Paprikachu> it's called bukkit/spigot
20:20 < shoghicp> this is for MCPE :)
20:20 < Paprikachu> mhh
20:20 < shoghicp> that's why I started it to document the protocol
20:20 < morfin> Paprikachu what's your server name?
20:21 < shoghicp> it was unknown 2 years ago
20:21 < Paprikachu> quicksilver
20:21 < morfin> ow
20:21 < morfin> and you did everything yourself even async stuff?
20:21 < Paprikachu> well, i haven't implemented pretty much anything but chunk loading
20:21 < morfin> :)
20:21 < Paprikachu> but it already has 5k loc, it must be good!!
20:21 < morfin> :D
20:22 < Paprikachu> https://bitbucket.org/Paprikachu/quicksilver/src
20:22 < shoghicp> you made it public :D
20:22 < Paprikachu> i did
20:22 < Paprikachu> and hey, it can't do anything, but at least it supports chunk generator plugins!
20:22 < shoghicp> nice
20:23 < morfin> C++11
20:23 < Paprikachu> https://bitbucket.org/Paprikachu/quicksilver-flatgenerator/src/
20:23 < morfin> hello new standards
20:23 < Paprikachu> c++14 actually
20:23 < Paprikachu> and some c++17 features as well
20:23 < morfin> holy shit
20:23 < shoghicp> I'm now trying to split the client/server part in MCPE
20:24 < shoghicp> and I keep doing side refactoring in the code
20:24 < morfin> you even used SFINAE
20:24 < Paprikachu> https://bitbucket.org/Paprikachu/quicksilver-flatgenerator/src/1a379d7c58d726ec562bfb8d2b6962dc8afbed39/main.cpp?at=master
20:24 < Paprikachu> i think the api is pretty decent
20:24 < Paprikachu> what do you think
20:24 < Paprikachu> :P
20:24 < morfin> hmm
20:24 < morfin> API should be not overloaded
20:24 < Paprikachu> eh?
20:25 < morfin> anything else should probably go into internal implementation
20:25 < Paprikachu> this is pretty much as small as you can get
20:25 < morfin> (*data.biomes)[z][x] = PLAINS; he-he
20:25 < Paprikachu> yes, and?
20:26 < morfin> so you always gernerate plains 
20:26 < Paprikachu> in a flat land generator, ofc
20:26 < morfin> let's have flat generator allowing to choose your destiny)
20:27 < Paprikachu> that's not even one of the cool parts of the server
20:27 < Paprikachu> this right here is a gem
20:27 < Paprikachu> https://bitbucket.org/Paprikachu/quicksilver/src/f28ca97a718737e055e2cfb8f904d5fa851f3f1a/source/utils/TupleForEach.hpp?at=master
20:27 < morfin> something like hmm
20:27 < Paprikachu> or here: https://bitbucket.org/Paprikachu/quicksilver/src/f28ca97a718737e055e2cfb8f904d5fa851f3f1a/source/utils/Fold.hpp?at=master
20:27 < Paprikachu> :>
20:28 < Paprikachu> or if you're into custom containers: https://bitbucket.org/Paprikachu/quicksilver/src/f28ca97a718737e055e2cfb8f904d5fa851f3f1a/source/utils/ArrayMap.hpp?at=master
20:31 < morfin> i am trying to implement with ASIO and some boost stuff ;\
20:31 < Paprikachu> i use asio as well
20:31 < Paprikachu> but the network code could need some cleanup
20:32 < morfin> because too lazy to learn any platform
20:32 < Paprikachu> https://bitbucket.org/Paprikachu/quicksilver/src/f28ca97a718737e055e2cfb8f904d5fa851f3f1a/source/protocol/?at=master
20:32 < morfin> Boost is full of shit(#ifdef,#if) for platform-specific code
20:32 < Paprikachu> who cares
20:33 < morfin> lol i use varint as POD
20:33 < Paprikachu> eh?
20:33 < morfin> why not?
20:33 < Paprikachu> i dont even know what you mean
20:34 < Paprikachu> like it makes any difference
20:34 < Paprikachu> my VarInt<T> is just a wrapper around a T
20:34 < Paprikachu> kind of a marker type
20:34 < morfin> but why no SFINAE here?
20:34 < Paprikachu> cause i'm lazy and it's completely irrelevant
20:35 < morfin> it does not make sense to use VarInt<std::string> :D
20:35 < Paprikachu> so what
20:35 < Paprikachu> you can't serialize it anyways
20:35 < Paprikachu> serialization actually does use sfinae
20:35 < morfin> template<typename T,typename boost::enable_if< boost::is_integral< T >,T >::type=0> struct varint { operator T(){return value_;}T value_;}; //just stupid container
20:35 < Paprikachu> but not because i want to, but because i have to
20:36 < morfin> *almost same with C++11 anyway
20:36 < Paprikachu> i wouldnt sfinae that anyways
20:36 < Paprikachu> if you want to exclude non-integers, static_assert it
20:36 < Paprikachu> so you get a decent error message at least
20:36 < morfin> no C++11 for me
20:36 < Paprikachu> why noit
20:36 < Paprikachu> not
20:37 < morfin> i want to support some older a bit compilers
20:37 < Paprikachu> well that's a stupid attitude
20:37 < Paprikachu> c++11 is getting 4 years old
20:37 < Paprikachu> four years
20:37 < morfin> i recall guys from ##c++-general suggested that static_assert 
20:37 < Paprikachu> f.o.u.r
20:37 < morfin> lol
20:37 < morfin> did you see VS?
20:37 < Paprikachu> who cares?
20:38 < Paprikachu> nobody runs a minecraft server on windows
20:38 < morfin> it still suck in C++ standard implementation
20:38 < Paprikachu> *no sane person
20:38 < morfin> ok 
20:38 < Paprikachu> i actually code using cygwin
20:38 < morfin> my Linux have gcc 4.4.7
20:38 < Paprikachu> update it
20:38 < morfin> Ubuntu had some 4.6.x
20:39 < morfin> can't remember which one
20:39 < morfin> still bad :(
20:39 < shoghicp> 4.9 here
20:39 < Paprikachu> well, im not gonna let shitty compilers hold my project back
20:39 < Paprikachu> at some point in the near future i'm going to require full c++17 support
20:39 < shoghicp> or 4.8 on 14.04 I think
20:39 < Paprikachu> sometime this year prob
20:39 < morfin> FreeBSD uses clang(because installed 10)
20:40 < morfin> why you use Cygwin?
20:40 < Paprikachu> only sane way to build software on windows
20:40 < morfin> nope
20:40 < Paprikachu> uh yes
20:40 < morfin> MinGW works fine for me
20:40 < Paprikachu> i rely on posix functions
20:40 < morfin> too bad :(
20:41 < Paprikachu> it's a good trade-off
20:41 < Paprikachu> nobody cares about windows in the server world, as i said
20:41 < Paprikachu> and cygwin is good enough for development
20:41 < morfin> say that to my employee )
20:41 < Paprikachu> also
20:41 < Paprikachu> you haven't even seen
20:41 < Paprikachu> the most glorious piece of c++ ever written
20:41 < morfin> but what Posix functions you use?
20:42 < Paprikachu> dlfcn.h stuff for example
20:42 < Paprikachu> and some file functions like ftruncate
20:42 < Paprikachu> fsync
20:42 < morfin> ow
20:43 < Paprikachu> https://bitbucket.org/Paprikachu/quicksilver/src/f28ca97a718737e055e2cfb8f904d5fa851f3f1a/source/protocol/PacketSchemes.hpp?at=master
20:43 < Paprikachu> https://bitbucket.org/Paprikachu/quicksilver/src/f28ca97a718737e055e2cfb8f904d5fa851f3f1a/source/protocol/Packets.hpp?at=master
20:43 < morfin> not sure why you use C functions for files
20:43 < Paprikachu> code generation 101
20:43 < Paprikachu> mainly because 1. iostreams suck and 2. don't give me the control i need
20:44 < morfin> oh do not tell me you reinvented protobufs
20:44 < morfin> they don't suck
20:44 < Paprikachu> that's pure c++ right there
20:44 < Paprikachu> no external codegen
20:44 < morfin> i know
20:44 < morfin> external suck
20:44 < Paprikachu> define a packet, get serialization for free
20:44 < Paprikachu> and whatever you happen to need
20:44 < Paprikachu> it's insanely convenient
20:45 < morfin> i don't like idea to compile compiler to compile packet with compiler and then compile by compiler
20:45 < Paprikachu> :P
20:45 < Paprikachu> i just abuse the preprocessor to include headers multiple times
20:45 < morfin> i was going to avoid that)
20:46 < Paprikachu> have fun writing all your stuff by hand
20:46 < Paprikachu> and getting errors due to typos
20:46 < morfin> don't forget about modifications)
20:46 < Paprikachu> that are hard to find
20:46 < morfin> :D:D
20:46 < Paprikachu> modifying a packet is as easy as modifying the line in the definition file
20:47 < Paprikachu> i might do something similar for enums
20:47 < morfin> hmm 
20:47 < Paprikachu> and also
20:47 < Paprikachu> iostreams do suck
20:47 < Paprikachu> they are slow
20:47 < Paprikachu> they are ugly
20:48 < morfin> pff
20:48 < Paprikachu> and they dont support my use case
20:48 < morfin> how they're slower
20:48 < Paprikachu> 10x
20:48 < morfin> why you think so?
20:48 < Paprikachu> i measured it
20:48 < morfin> hm
20:48 < Paprikachu> sequential read
20:48 < Paprikachu> .read(buf, size)
20:48 <+jnoah> "slow" is a relative term. come back with true statistical analysis before you shove your ambiguity in people's faces
20:48 < Paprikachu> 10x slower
20:48 < Paprikachu> :DD
20:49 < Paprikachu> i don't need to justify my design choices
20:49 < Paprikachu> iostreams will soon be banned from my project :)
20:49 < morfin> lol )
20:49 <+jnoah> your language, not design choices (though they may follow) are in question
20:49 < Paprikachu> :DD
20:49 < morfin> language is not bad
20:49 < Paprikachu> c++ is the least retarded language there is
20:50  * morfin was thinking about C )
20:50 <+jnoah> lolol language, as in choice of words, e.g. what i just called you on: "slow"
20:50 < Paprikachu> ok buddy
20:50 < Paprikachu> w/e dude
20:50 < Paprikachu> 10x is slow by my definition
20:50 <+jnoah> lolk
20:51 < Paprikachu> especially for something as simple as reading a file linearly
20:51 < Paprikachu> https://bitbucket.org/Paprikachu/quicksilver/src/f28ca97a718737e055e2cfb8f904d5fa851f3f1a/source/utils/FileUtils.cpp?at=master
20:51 < Paprikachu> File ftw
20:52 <+jnoah> Paprikachu: http://zedshaw.com/archive/programmers-need-to-learn-statistics-or-i-will-kill-them-all/
20:52 < Paprikachu> looks boring
20:52 < Paprikachu> tl;dr?
20:52 <+jnoah> learn statistics and stop spouting 10x faster! and words like "slow"
20:53 < morfin> need proper benchmarking
20:53 < Paprikachu> 10x is a measured fact
20:53 < Paprikachu> i hope you're not gonna argue with facts
20:53 < morfin> wait a second
20:53 < morfin> i am going to blow up ##C++-general )
20:53 <+jnoah> that article may show you that your "facts" are not actually facts. I don't know though. I'm not sure how you measured your data
20:54 < Paprikachu> ok, got it
20:54 < Paprikachu> in your world, 10 is apaprently a different number
20:54 < Paprikachu> equal to 1 or something
20:54 < Paprikachu> cause who needs the 0 anyways, it has no value
20:55 < Paprikachu> i really don't see what's to discuss here. 10x slower ist 10x slower. has nothing to do with terminology, it's a *fact*.
20:55 <+jnoah> yup, sounds about right. i do recommend that article. it's a (tad boring possibly, but a) good read
20:57 < Paprikachu> damn, /dev/random is slow in cygwin
20:57 < Paprikachu> i was about to create a random file for reading
20:57 < Paprikachu> but zzz
20:57 <+jnoah> tbf anything related to crypto has it's shortcomings in windows
20:59 < Paprikachu> oh right, /dev/random is pure entropy while /dev/urandom is pseudo random
20:59 < morfin> ok they're not listening :(
21:00 < morfin> i do not like abusing templates 
21:01 < morfin> because compilation becomes veeeeery slow
21:02 < morfin> how did you read file?
21:05 <+jnoah> bit by bit
21:05 < morfin> )
21:05 < morfin> use_mmap_then
21:05 < Paprikachu> i don't need to prove anything, you can find numerous benchmarks on the internet
21:05 < Paprikachu> also it's common knowledge
21:06 < morfin> can't find one
21:07 < morfin> ok CONCLUSION: Using <cstdio> is faster than <fstream>. The reason fstream is slower is because c++ streams have their own internal buffer. This results in extra copying whenever you read/write and this copying accounts for the entire extra time taken by fstream. Even more shocking is that the extra time taken is longer than the time taken to actually read the file
21:08 < morfin> but is not that not bottleneck?
21:09 < morfin> reading into internal buffer is much slower  than copying from one place to another in memory
21:10 < morfin> but mmap anyway seems to be best 
21:10 < Paprikachu> welp i cant test it
21:10 < Paprikachu> benchmark segfaulting
21:10 < morfin> lol
21:10 < Paprikachu> dunno why
21:10 < Paprikachu> in the vector constructor apparently
21:10 < morfin> you want to mess with C in C++ then you should probably avoid exceptions
21:11 < Paprikachu> wrong :)
21:11 < morfin> i do not think that code is exception safe
21:11 < Paprikachu> which one
21:12 < Paprikachu> weird
21:12 < Paprikachu> new char[] works
21:12 < Paprikachu> vector crashes
21:12 < Paprikachu> wtf
21:13 <+jnoah> lol@c++
21:16 < morfin> are you one of that C#/Java fans?
21:16 <+jnoah> nope
21:16 <+jnoah> rust/c/haskell/python fan
21:17 < Paprikachu> c == stone age
21:17 < morfin> eeh strange Haskell
21:17 < Paprikachu> haskell == functional cancer
21:17 < Paprikachu> python == we cant afford braces
21:17 < morfin> lol
21:17 < morfin> write your own language)
21:17 < Paprikachu> been there, done that
21:17 <+jnoah> rust = memory safe c
21:17 < morfin> with blackjack and hookers
21:18 < Paprikachu> not sure how i feel about rust, i have yet to try it
21:18 < Paprikachu> looks very restricted tho
21:18 <+jnoah> it's fun. weird at first because of the whole borrowing of pointers concept, but once you understand that, the language is awesome
21:18 < morfin> hmm 
21:19 < Paprikachu> http://i.imgur.com/WBlCjTR.png
21:19 < Paprikachu> k
21:19 <+jnoah> 1k?
21:20 < Paprikachu> ~5gb
21:20 <+jnoah> oh, can't open larger that 4g probably
21:20 < Paprikachu> prob
21:21 < Paprikachu> alright
21:21 < Paprikachu> 10 gb file
21:21  * Xor_Boole hears `haskell`
21:21  * Xor_Boole starts wooping
21:21 < Paprikachu> something is wrong
21:22 < Paprikachu> the 3gb file took longer than the 10gb file with iostreams
21:22 < Paprikachu> that makes no sense :D
21:22 < morfin> i'd use mmap for huge files)
21:22 < morfin> not regular API
21:22 <+jnoah> Paprikachu: different methods for mapping different sized files (32bit size vs 64bit size, etc) would be my guess
21:23 < Paprikachu> reading using iostreams ...     0.876000 s
21:23 < Paprikachu> reading using C api ...         4.126000 s
21:23 < Paprikachu> also makes no sense :P
21:23 < morfin> hmm
21:23 <+jnoah> buffers
21:23 <+jnoah> /cache
21:23 < Paprikachu> nah, something is wrong here
21:24 <+jnoah> ok
21:24 < Paprikachu> http://ideone.com/KdSngf
21:27 < morfin> hmm
21:27 < Paprikachu> either i'm blind or iostreams are bugged
21:31 < jast> in my experience, with components as thoroughly time-tested as iostreams it's usually a blindness issue :)
21:32 < Paprikachu> im gonna run it on my server
21:33 < Paprikachu> maybe its a cygwin bug
21:33 < jast> that's not entirely likely either...
21:33 < morfin> Paprikachu do you have Linux box?
21:33 < Paprikachu> my server is running ubuntu, yes
21:33 < morfin> and you test on Ubuntu?
21:33 < jast> protip: testing in a VM is convenient
21:33 < Paprikachu> im going to
21:34 < morfin> hope that's not VM
21:34 < Paprikachu> why would my server be a vm
21:34 < Paprikachu> it's a root obviously
21:34 < jast> there are some advantages to virtualization
21:34 < Paprikachu> creating a 10gb file is taking forever, wtf
21:35 < Paprikachu>  dd count=10000 bs=1000000 if=/dev/urandom
21:35 < jast> but only if you throw lots of money at it
21:35 < jast> /dev/urandom generates pseudorandom numbers when no entropy is left... the PRNG isn't extremely fast...
21:36 < Paprikachu>  /dev/random is worse
21:36 < Paprikachu> cancelled it, 2.6 gb
21:37 < jast> /dev/random blocks when entropy is used up, until more arrives
21:37 < morfin> that shit would not work on M$
21:37 < Paprikachu> reading using iostreams ...     1.255000 s
21:37 < Paprikachu> reading using C api ...         0.363000 s
21:37 < morfin> properly
21:37 < Paprikachu> that makes more sense
21:37 < jast> entropy usually fills up very slowly
21:38 < morfin> hmm
21:38 < morfin> that was test on Cygwin?
21:38 < Paprikachu> no, thats linux
21:39 < morfin> oh
21:42 < Paprikachu> god hdd suck
21:42 < Paprikachu> hdds
21:42 < Paprikachu> why is that tech even in use still
21:42 < Paprikachu> read/write speeds are atrocious
21:43 < morfin> ok 
21:43 < Paprikachu> seriously it's taking forever to create a file filled with random numbers
21:43 < morfin> let's do this
21:43 < Paprikachu> on my pc it's a matter of seconds
21:43 < jast> well maybe because it's not horribly expensive?
21:45 <+AndrewPH> Paprikachu: because most people need a lot more space than SSD can get for an affordable price
21:45 < gamingrobot> Paprikachu: https://twitter.com/Benjojo12/status/498586223624327168
21:45  * morfin waiting for created file
21:45 < Paprikachu> what does this graph tell me
21:45 < gamingrobot> harddrive failure
21:47 < Paprikachu> $ cat random.txt >> random.txt
21:47 < Paprikachu> cat: random.txt: input file is output file
21:47 < Paprikachu> WHY
21:47 < dx> use sponge
21:47 < morfin> still waiting
21:48 < dx> sponge from the 'moreutils' package
21:48 < Paprikachu> meh
21:48 < Paprikachu> whatever
21:48 < Paprikachu> file size: 5070 MB
21:48 < Paprikachu> reading using iostreams ...     1.439000 s
21:48 < Paprikachu> reading using C api ...         0.754000 s
21:49 < morfin> btw what do you use for generating pseudorandom numbers in your code?
21:49 < Paprikachu> cat /dev/urandom > random.txt
21:50 < morfin> no in C++ code 
21:50 < dx> Paprikachu: what have you done to disable caches?
21:50 < dx> (sorry if you mentioned it, i'm just skimming)
21:50 < Paprikachu> that was the wrong button
21:50 < Paprikachu> lol
21:50 < morfin> i generated that shit 
21:50 < Paprikachu> and about caching
21:50 < Paprikachu> it actually works pretty well
21:50 < Paprikachu> reading using iostreams ...     0.829000 s
21:50 < Paprikachu> reading using C api ...         0.751000 s
21:51 < Paprikachu> after a few runs
21:51 < Paprikachu> but
21:51 < Paprikachu> irrelevant in my application
21:51 < morfin> i am going to modify your "benchmark"
21:51 < Paprikachu> sure
21:51 < dx> put C api first, iostreams later?
21:51 < morfin> what's point of doing that?
21:52 < dx> caching?
21:52 < morfin> i do not pretend i know C++ well but still interested
21:53 < dx> i don't even know what's going on in this channel but i like to throw random suggestions anyway
21:53 < Paprikachu> hm
21:53 < morfin> some shit happens
21:53 < Paprikachu> looks like you're right actually
21:54 < Paprikachu> it's a result of caching
21:54 < morfin> lol
21:54 < morfin> that's smart OS work
21:54 < morfin> btw i thinked about using ifstream::binary also
21:54 < morfin> for binary files IO
21:54 < Paprikachu> makes no difference on linux
21:59  * morfin testing on FreeBSD 10, compiled with Clang 3.4
22:00 < morfin> those shit just hanged up on 4100Mb file
22:00 < morfin> my disk is being read very much(i hear that) but no message appeared
22:00 < morfin> lol
22:01 < morfin> reading using iostreams ...     133.541000 s
22:02 < morfin> and you say 0.1s is very much?
22:02 < morfin> reading using C api ...         141.645996 s
22:03 <+jnoah> sounds like the 10x faster remark was just nonsense.
22:03 < morfin> yes my disk was not supposed to be used for such things
22:04 < morfin> it's just storage disk
22:04 < morfin> basically native reading is faster yes at least because no copying happens
22:04 < morfin> but i would use mmaping anyway)
22:05 < morfin> 32x32 chunks regions are huge hmmm
22:07 < Bibl__> https://gitorious.org/c-plus-equality/c-plus-equality/source/cefcfb4276889bd3833c539225a9cdfd3eb16d33: ahahahahahahahaah
22:09 < morfin> looooooooooool
22:12 < Bibl__> http://blog.mollywhite.net/why-im-not-laughing-at-c-plus-equality/ this cant be for real
22:13 < morfin> fuck it really works?
22:14 < morfin> they forgot about slave/master)
22:14 < morfin> in databases
22:15 < Bibl__> best bit was
22:15 < Bibl__> "...There is to be no encapsulation: don't tell me to protect my members, tell other functions not to access them!..." ahaahaha
22:18 < morfin> they even know about std::mt19937 funny
22:27 < morfin> i was always interested how works default random generator
22:29 < morfin> because it seems to be not very random 
22:29 < morfin> *default Minecraft random generator
22:56 < ellisvlad> Bibl__: Well, I'm using C++, but just requesting the authentication with https... Didn't think the https://sessionserver.mojang.com/session/minecraft/hasJoined?username=username&serverId=hash used their email?
22:57 < Bibl__> ellisvlad: wait what were you sending?
22:57 < Bibl__> i thought you were sending email addresses
23:00 < ellisvlad> As http://wiki.vg/Protocol_Encryption#Authentication explains, I'm implementing the "Server" part, and using my username for both of my test cases to https://sessionserver.mojang.com/session/minecraft/hasJoined?username=username&serverId=hash.. For one of the usernames, ellisvlad - legacy, it works correctly. For the, Thartax - Mojang account, the session server just replies with 204 and no 
23:00 < ellisvlad> data..
23:01 < ellisvlad> I'm sure the serverId is correct, because I've checked it with the debug client.. but for my Mojang (non-legacy) account, the hasJoined request always returns 204
23:01 < Bibl__> are you supposed to send the profile name or the mc username?
23:03 < ellisvlad> Well, when this is called, I've only got their username from the handshake packet?
23:04 < Bibl__> i think theres a way to get the other name for it
23:04 < ellisvlad> *login start
23:04 < Bibl__> one of the web auth calls
23:04 < Bibl__> http://wiki.vg/Mojang_API
23:05 < Bibl__> username to uuid
23:05 < Bibl__> or playernames to uuid
23:05 < ellisvlad> But even so, https://sessionserver.mojang.com/session/minecraft/hasJoined?username=username&serverId=hash takes their username? no? Which I have
23:06 < Bibl__> dunno, try it
23:06 < ellisvlad> I did lol, and I could only get a response when I request with my non-legacy account
23:06 < ellisvlad> *legacy account, the non-legacy gives 204
23:07 < Bibl__> not sure then, sorry
23:11 < ellisvlad> Ah
23:11 < ellisvlad> solved it!
23:12 < ellisvlad> First I did some testing using the old session server http://session.minecraft.net/game/checkserver.jsp?user=Thartax&serverId=1b3114d33fb91ede6f63c5b87f9288352d55d046
23:12 < Bibl__> how
23:12 < ellisvlad> http://session.minecraft.net/game/checkserver.jsp?user=Thartax&serverId=1b3114d33fb91ede6f63c5b87f9288352d55d046 works, "YES"
23:12 < ellisvlad> http://session.minecraft.net/game/checkserver.jsp?user=thartax&serverId=1b3114d33fb91ede6f63c5b87f9288352d55d046 doesn't "NO"
23:12 < ellisvlad> ...I forgot I put the username to lower case when they log in..
23:12 < ellisvlad> my bad :3
23:13 < Bibl__> lol
23:34 < ellisvlad> Success :D http://i.ellisvlad.com/Bg7tG.png
--- Day changed mar. févr. 17 2015
04:59 < morfin> guys is there session timeout on Minecraft site?
05:00 < morfin> and what if i play and session die?
05:00 < morfin> what server do in that case?
07:40 <+SpaceManiac> morfin: the session only matters when you join a server - there's no checks while you play
07:41 <+SpaceManiac> what happens is the client, on joining an online-mode server, contacts the session server and fails to auth, so it shows an error on its end
18:13 < morfin> does notchian server clean up whole region file when no chunks are loaded from that region?
18:15 <+Amaranth> morfin: It has a LRU cache of file handles
18:15 < morfin> or does server clean up only when shutting down?
18:16 <+Amaranth> It might have more than file handles, think maybe it also has the index or whatever
18:16 < morfin> i meant removing old pieces of worlds
18:16 <+Amaranth> Removing pieces? How would the server ungenerate the world?
18:16 < morfin> like as somebody said: if not enough space to fin new data -> move to another place(relocate) and change pointer 
18:17 < morfin> *to fit
18:17 <+Amaranth> You mean stale data in the region file from after a resize?
18:17 < morfin> yep
18:17 <+Amaranth> It just leaves it afaik
18:17 < morfin> but old data stays and somebody here said server do clean up region files from those junk
18:17 <+Amaranth> Index isn't pointing to it so it doesn't exist
18:17 < morfin> but only when shutting down probably
18:19 <+Amaranth> Why would it clean them up?
18:19 < morfin> i heard it perform checks to save only valid data(using temporary copy maybe) to reduce file size
18:19 <+Amaranth> It'll just overwrite them next time it needs that spot
18:19 < morfin> hmmm
18:20 < morfin> so chunks are not ordered
18:21 <+Amaranth> morfin: http://minecraft.gamepedia.com/Region_file_format#Chunk_Location
18:22 < morfin> i hate those "filesystems" in filesystem
18:22 <+Amaranth> *shrug* it's a lot faster
18:23 < morfin> but why 
18:23 < morfin> is not better idea to use fixed chunks buffer at beginning and other shit after those?
18:23 <+Amaranth> I don't think there was much difference than this and single chunk per file on ext4 but on fat and ntfs at least it was a huge win
18:24 <+Amaranth> Oh, you're talking about the index vs chunks being in fixed locations in the file
18:24 < morfin> anyway as i know data is compressed
18:24 < morfin> so even gzip can compress lots of zeroes into "nothing"
18:24 <+Amaranth> I think a better question would be what happens if a chunk has enough entities in it to compress to more than 1MB of data
18:25 <+Amaranth> Since the file format doesn't seem to allow for that
18:25 < morfin> btw 
18:25 < morfin> "Chunks will always be less than 1MiB in size."
18:25 <+Amaranth> Think it just throws away entities until it fits? I don't remember seeing code like that in there
18:25 < morfin> hmm 
18:26 < morfin> how many entities i will need for that?
18:26 < morfin> 1000000?
18:26 <+Amaranth> A lot, dunno though
18:26 <+Amaranth> First start would be to fill the chunk with blocks in a way that doesn't compress
18:27 < morfin> not sure 
18:27 < morfin> how it's possible
18:28 < morfin> i think need blocks with metadata, tile entities, entities - any shit having more data than regular block
18:29 <+Amaranth> There are 197 possible blocks and you need to fill 65536 spots with them in a way that defeats zlib
18:29 < morfin> not simple task 
18:29 <+Amaranth> Eh, just use a RNG to select what block id to use for each one
18:29 <+Amaranth> It'll do a pretty good job
18:30 <+Amaranth> That should get you close to 192KB to add entities to
18:31 <+Amaranth> Assuming you're randomly selecting block and sky light values as well
18:32 < morfin> how heavy are entities?
18:33 < morfin> btw that's not gzip limits
18:34 < morfin> gzip does not care if you would try to compress 4Gb 
18:34 < morfin> btw i had next question: Minecraft commit changes to FS?
18:35 < morfin> like every N secs/N changes 
18:36 < morfin> because gzipping seems very CPU intensive for me
18:52 < morfin> hmmm
18:55 < morfin> btw is not accessing any element of fixed array like O(1) when accessing using index
18:56 < morfin> only questionable thing is how would i link entities and chunks
18:58 < morfin> because entities have variable length
18:58 < morfin> and i will need to load only entities belong to chunk i load
19:06 < morfin> i forgot chunks are build from sections
--- Day changed mer. févr. 18 2015
16:36 < Thinkofdeath> Grum: So... 'animated MOTD' bug or feature? :)
16:36  * Thinkofdeath hopes on bug
16:54 < gurun> to implement the fluids dynamic .. which way would the algorithm work. Is it from the source of the liquid or .. from the end of the spread?
16:54 < gurun> like the root or the leaf
16:55 < shoghicp> gurun: flood fill in x/z, then downwards movement
16:57 < gurun> ok, so you would say start at the source, and work in the natural order of physics.
16:57 < gurun> the minecraft wiki ... kind of implied it would be implemented in the reverse way.
16:58 < gurun> i will follow your advice, thanks.
16:59 < morfin> hmm
17:00 < gurun> btw, when i look at this map https://d1y0oqfyli6x95.cloudfront.net/wp-content/uploads/2013/08/overviewMap_new.png
17:00 < morfin> still thinking is there better way to implement map
17:00 < gurun> it implies that fjords are actually implemented as a .. structure. Could it be like that?
17:00 < gurun> it's like a feature on the map.
17:01 < gurun> morfin: if you start with a really bad implementation of map, it makes it easier to implement a better way ;-)
17:02 < gurun> key in coding is making really bad code that you can get credit for improving. So make it bad .. with potential.
17:02 < gurun> that's how you get a raise from fixing your own bugs.
17:06 < morfin> what?
17:08 < morfin> gurun i don't like design of map right now
17:08 < gurun> map .. could mean anything to a developer. You mean the item map that the player is holding, or?
17:08 < morfin> all that NBT
17:09 < morfin> storing map 
17:09 < gurun> so .. "all that NBT". Just to be sure, are you against NBT, or something else. NBT is just a "format" you know.
17:10 < Xor_Boole> <Thinkofdeath> Grum: So... 'animated MOTD' bug or feature? :)
17:10 < Xor_Boole> what the actual fuck
17:11 < Thinkofdeath> Xor_Boole: ?
17:11 < Xor_Boole> how
17:11 < Xor_Boole> just how
17:13 < Thinkofdeath> Xor_Boole: the client doesn't close its connection to the server for pinging until after the ping packet from the server is received
17:14 < Thinkofdeath> so if the server doesn't reply with a ping the client will wait, you can then keep sending status replies to the client
17:14 < Thinkofdeath> causing it to update the motd/icon already displayed
17:14 < Thinkofdeath> servers abuse this to 'animated' the motd and icon
17:14 < Thinkofdeath> *animate
17:14 < Xor_Boole> horray for protocol hacks
17:14 < Thinkofdeath> by repeatedly resending the motd
17:15 < Xor_Boole> it's a terrible way to do it, but it sounds cool
17:15 < Thinkofdeath> Xor_Boole: its nasty :(
17:15 < Xor_Boole> Thinkofdeath well, it's a nice DoS vector for one
17:15 < morfin> gurun - of course if i store everything in NBT it's compatible with original server
17:15 < Thinkofdeath> Xor_Boole: well yes, for the server too :P
17:16 < Xor_Boole> that sounds like it would just destroy the host bandwidth
17:16 < Thinkofdeath> the client can keep requesting motds too
17:16 < gurun> morfin: yes, but if that's not a requirement .. well, don't.
17:16 < Xor_Boole> Thinkofdeath I meant the server, no the client =p
17:16 < morfin> but if i store not like that then i will have to deal with some stuff
17:16 < gurun> morfin: but regardless, you probably need to convert to and from anyway.
17:16 < yawkat> Xor_Boole: theres actually a ddos that kinda does that
17:16 < morfin> yes when sending to client
17:16 < gurun> yeah.
17:16 < Xor_Boole> yawkat look at how surprised I am
17:16 < morfin> like i do not know how would i link chunks and entities
17:16 < gurun> so you can choose to choose you fights.
17:17 < morfin> i am not sure how would i do that
17:17 < gurun> well, entities have a global position, so that's not difficult.
17:18 < morfin> nope it is
17:18 < morfin> i want to speed up loading not slow down
17:20 < morfin> as example i was thinking about storing huge region(32x32 chunks) with fixed layout for blocks and some stuff but some blocks would probably have metadata hmm
17:24 < morfin> what's max block size?
17:25 < Thinkofdeath> Xor_Boole: it also causes other issues too, one of the plugins that do it makes the motd return an out of date protocol version
17:26 < Thinkofdeath> so they can animate the 'out of date' message
17:27 < gurun> morfin: i'll bite. Why do you feel you need to speed up loading?
17:29 < morfin> well - that's one bottleneck
17:29 < gurun> usually, there is little you can do design wise to speed it up when reading from disc. 
17:29 < morfin> another one is network bandwidth
17:29 < gurun> so, the strategy is usually to be smart about when and how you read it.
17:30 < gurun> so, bandwidth.. there are constructs in place to deal with that, but that's prett much out of your control, is it not?
17:30 < morfin> last one is not very big problem
17:30 < morfin> with good VDS
17:31 < morfin> but HDD hmm well
17:31 < gurun> well assume SSD .. and then your problem will be elsewhere :-)
17:32 < gurun> i mean .. even though i work with PE so it's a bit different... but reading from disc has never been an issue.
17:32 < gurun> having smart caching solves all these problems. So, the overhead i see, is actually in locking of the cache while looking for a chunk.
17:33 < gurun> .. and that takes an unproportially big chunk of the ticks.
17:33 < gurun> so i'm looking for another way to cache to avoid locks, and rather sacrifice memory instead.
17:34 < gurun> increase the number of cache hit failures and risk having to regenerate chunks, rather than lock on the cache.
17:35 < gurun> i'm loading worlds like Kings Landing (huge) and never seen an issue with reading them in real time.
17:35 < gurun> and then you have to also realize that i read that in anvil, and convert every block to a more PE friendly format on the fly, real time.
17:37 < morfin> what do you mean cache locking?
17:38 < gurun> well, if you have a dictionary as a cache (chunk coords, chunk)
17:38 < gurun> if you access that, you need to lock the dictionary in a multithreaded environment.
17:38 < morfin> ow you mean lock in-memory copy
17:38 < gurun> so, the time spent in lock wait state far exceed the time it takes to do the work of getting them.
17:38 < morfin> well hmm that's a problem 
17:39 < gurun> it's a problem i have in my server, but a small problem.
17:39 < gurun> i just say, that is the ONLY problem i have around chunk loading and reading. It is where the current bottleneck is.
17:39 < morfin> hmmm
17:39 < morfin> locking is not good btw
17:39 < gurun> but it doesn't affect performance enoigh to bother with it.
17:39 < morfin> anyway
17:40 < morfin> why don't implement something like RDBMS did?
17:40 < gurun> locking is a required thing if you muiltithread. It is always a question of balancing the resources when you thread stuff. Sometimes sequential is faster.
17:40 < gurun> RDBMS, don't know that.
17:40 < gurun> unless you mean database :-=)
17:40 < morfin> versioning
17:41 < morfin> sooooo
17:41 < morfin> if somebody request data you give older version(pre-lock) and then change?
17:41 < morfin> idk
17:41 < gurun> sooo, just give up the idea and put the time thinking about something else.
17:42 < morfin> anyway 
17:42 < gurun> it's not a problem.
17:42 < morfin> i was not thinking about locking issues
17:42 < gurun> i do multithreading to make sure that long tasks run in their own, to really use the CPU.
17:42 < morfin> but was thinking how can i do better design: i wanted to mmap
17:42 < gurun> and long tasks .. means anything even remotely close to 2-3ms or longer..
17:43 < morfin> wait are not you who wrote C++ server with TBB?
17:43 < gurun> no
17:43 < morfin> can't remember those server name