01:22 < redstonehelper> that's one of the reasons they did all this block states stuff
01:22 < Bibl_> but why would the values be the same D:
01:22 < Thinkofdeath> Not every state was stored in previous versions and was worked out at runtime
01:22 < redstonehelper> instead of figuring out what a block is supposed to look like, they now save it
01:23 < Thinkofdeath> well they /will/ save it, they don't yet
01:23 < redstonehelper> oh yeah, sorry
01:23 < Thinkofdeath> 1.9 hopefully
01:23 < Bibl_> so i have to do my bounding box creation stuff at runtime?
01:23 < redstonehelper> are there any blocks that change bounding box independent of data value?
01:24 < redstonehelper> (unless you want to do bounding boxes different than in vanilla)
01:24 < Thinkofdeath> fences do
01:24 < redstonehelper> oh yeah
01:24 < Bibl_> it wouldnt be a problem if the data values werent the same
01:24 < Bibl_> guess i have to create at runtime instead of caching them
01:25 < Bibl_> also i met sir martyn poliakoff today
01:25 < Bibl_> he did a talk at my school on superfluid chemistry
01:25 < redstonehelper> I think I've seen him in a numberphile video once
01:26 < Bibl_> he's in all of the periodic videos i think
02:06 < gamingrobot> Bibl_: your having the same problem I am right now, bounding boxes
02:06 < Bibl_> haha
02:06 < Bibl_> well i have a system where there is a factory and a registry
02:06 < Bibl_> the registry stores static data which i thought included bounding boxes
02:06 < gamingrobot> I just have the block figure out its bounding box based off the state
02:06 < Bibl_> such as hardness, name, datas etc
02:06 < gamingrobot> https://github.com/nickelpro/spock/blob/master/spock/mcmap/mapdata.py#L91
02:07 < Bibl_> and i have a block factory where if you want an interactive block object, you can do factory.create... and then it gives a block with the properly calculated bounding boxes
02:07 < Bibl_> gamingrobot: you sure that works?
02:07 < gamingrobot> mhmm works great
02:08 < Bibl_> does it also work the same for stairs?
02:08 < gamingrobot> I havent written the stairs bit but it will when I am done
02:08 < gamingrobot> same system
02:08 < gamingrobot> and you dont have to instantiate the block to get the rest of the data, the instancing just gives you the metadata parsing
02:08 < Bibl_> i printed out the values and it looked to me like you couldnt distinguish between some of the data values
02:09 < Bibl_> oh wait what, do you not store the blocks data value?
02:09 < gamingrobot> I havent look that heavily into stairs, but I am also cheating in quite a few places
02:10 < Bibl_> how are you going to get blocks by id?
02:10 < gamingrobot> @map_block(0) decorators my dear sir
02:13 < gamingrobot> https://github.com/nickelpro/spock/blob/master/spock/plugins/helpers/inventory.py Inventories are being fuuuuuuun
02:20 < redstonehelper> and here I am creating schematic files with block ids :(
02:23 < gamingrobot> schematic files?
02:23 < toqueteos> hello guys, do all entity ids get really serialized as varints? some packets show Int and on top there's a description saying it's always 4 bytes
02:31 < gurun> Well, to get around that.. Nothing stopping you from making sure they are alway full int.
02:32 < gamingrobot> toqueteos: there are some packets where the entity id is a int
02:32 < toqueteos> so it's not typos
02:32 < gamingrobot> https://github.com/nickelpro/spock/blob/master/spock/mcp/mcdata.py
02:32 < gamingrobot> that will prob help you some
02:33 < gamingrobot> Attach Entity, Join Game, Entity Status
02:34 < gamingrobot> and a few more like Use Bed etc
02:35 < toqueteos> i have all packets declared and working, it's just that some of them are ugly as fuck to parse
02:36 < toqueteos> i was hoping i could remove some of the uglier parts but..
02:42 < Bibl_> lol gamingrobot: my bot has like 500 classes or something haha
02:42 < Bibl_> and you'res has like 30 files
02:42 < gamingrobot> :3
02:42 < Bibl_> yours*
02:42 < gamingrobot> you can blame nickelpro for that
02:42 < gamingrobot> its really clean
02:42 < Bibl_> http://i.imgur.com/suypj0A.png
02:43 < Bibl_> good job modern jvm is fast :D
02:43 < gamingrobot> python best XD
02:43 < Bibl_> haha na
02:46 < Bibl_> gamingrobot: https://github.com/nickelpro/spock/blob/e03121ec889eccd883cd7556a5b2ef5286ec7a3b/spock/mcmap/mapdata.py#L96 whats this about?
02:46 < Bibl_> you aren't calculating the boxes properly?
02:46 < gurun> Spock, where the hell is the code that actully do all the stuff.
02:47 < gamingrobot> if a fence gate is open you dont colide with it period
02:47 < Bibl_> i meant the second bounding box
02:48 < Bibl_> "	self.bounding_box = BoundingBox(1,1.5)"
02:48 < Bibl_> doesnt it depend on orientation?
02:48 < gamingrobot> I was lazy and didnt check the orientation of the gate and make it a thin rectangle bounding box
02:48 < gamingrobot> I just made it so that collision didnt throw a fit
02:49 < gamingrobot> same thing with fences, I assume the bounding box is the entire block
02:49 < gamingrobot> and for a bot that works fine for now
02:56 < gamingrobot> gurun: what do you mean?
03:41 < Gjum> gamingrobot: mineflayer has had problems with fences, because it assumed that bounding boxes are max. 1x1x1, it messed up its pathfinding quite a bit
03:43 < gamingrobot> well if you dont account for the 1.5 height on the bounding box then it will prob have issues
03:43 < gamingrobot> spock atleast acount for that
03:43 < gamingrobot> accounts*
03:44 < Gjum> ah I see
03:45 < gamingrobot> I am not looking forward to writing pathfinding
03:45  * gamingrobot leaves it for nickelpro :P
03:46 < Gjum> what's the problem?
03:46 < gamingrobot> just doesnt exist yet, and I have to fix collision first
03:47 < gurun> gamingrobot: i just mean the code is very compact
03:50 < Gjum> what is the state of spock anyway?
03:51 < gamingrobot> world stuff works, collision mostly works, basic movement and jumping, inventory is starting to work
03:52 < gamingrobot> collision has some edgecases that make it freak out
03:53 < gamingrobot> like walking into the top half of a door
03:54 < Gjum> I noticed some funny behaviour when climbing blocks, you can go up multiple blocks but the triangle above the stairs has to be empty, somehow the server does not check the direct from-to path
03:54 < Bibl_> server doesnt care
03:54 < Bibl_> nocheatplus might
03:54 < gamingrobot> spock cant handle stairs yet XD
03:55 < Gjum> nah, 1.8.1 vanilla corrected my position
03:55 < Bibl_> i think you can treat the top of a door as a full block
03:55 < Bibl_> so just stand there and nocheatplus will be ok i think
04:00 < gamingrobot> Can I treat stairs as a triangle ramp, or does the server get angry?
04:00 < Gjum> vanilla doesnt care
04:00 < Gjum> i think
04:00 < gamingrobot> I guess its another way to tell its a bot and not a player if I go that route
04:01 < Gjum> mh, how often do you send position updates?
04:01 < gamingrobot> 20 times a second
04:01 < Gjum> afaik positions inside collision boxes will make the server angry
04:02 < gamingrobot> I know that for a fact
04:02 < Gjum> but if you update from bottom to top of the stairs, the server interpolates and says ok
04:02 < Gjum> that is, no intermediate packets
04:02 < gamingrobot> thats a interesting way to do it
04:02 < Gjum> do you always send your position or only when it changes?
04:03 < gamingrobot> always
04:03 < Gjum> i think vanilla clients do not
04:03 < Gjum> another indicator
04:03 < gamingrobot> if you dont send 20 position updates per second you dont get health updates
04:03 < gurun> HU
04:03 < gamingrobot> so im pretty sure the vanilla client does that
04:03 < gurun> is it reactive or something!?
04:04 < Gjum> hm, maybe the server doesnt forward them
04:04 < Gjum> *the no-movement packets
04:05 < gamingrobot> time to use protocol lib one sec
04:05 <+md_5> they do
04:05 <+md_5> 20 packets a sec, as above :p
04:05 < gamingrobot> :D
04:05 < gurun> lol
04:05 < Gjum> ok, but my client only received packets when something changed
04:06 < gamingrobot> you will end up receiving "position and look" packets from the server if you messed up and the server has to correct you
04:06 < Gjum> no i mean from other players
04:06 < gamingrobot> oh thats entity relative move
04:07 < gurun> so, the clients are streaming in the positions, but the server doesn't broadcast it further?
04:07 < gurun> unless necessary
04:07 < Gjum> seems like that
04:07 < gurun> ok, that is managable.
04:07 < gamingrobot> it will just send entity relative move when players move
04:08 < gurun> and only every 50ms
04:08 < gurun> work tick, right
04:09 < gamingrobot> my terminal blew up when I put spock inside a farm
04:09 < Gjum> hm, one could actually just pull in the nocheat code and check against it before moving
04:09 < Gjum> lol!
04:10 < gamingrobot> so many entity events
04:14 < gamingrobot> gurun: spock isnt that small, it just got over 5k lines of code
04:15 < gurun> it just looks so compact when you look at the code
04:16 < gamingrobot> thats prob because 2.1k lines are just packet layouts and block data
04:16 < gurun> yeah i generate that stuff.. at least the packages
04:19 < gurun> what is best .. to tick entities as part of world-ticking .. or have a ticker for every entity?
04:19 < Gjum> are you talking server or client?
04:19 < gurun> server
04:19 < gurun> i'm a bit scared i would just drain all threads
04:20 < Gjum> if many entities have to move every tick, a global one might be the way to do it
04:21 < gamingrobot> it depends on how much you have to do in a tick
04:21 < gurun> for players .. i do it multithreaded for positions. And then i join all threads in the end. Otherwise it would make use of my multicore.
04:22 < gurun> so by doing that i can basically have a world tick of 0-1ms even for 400 players.
04:22 < gurun> but .. entities other than players.. it can become a lot.
04:22 < gamingrobot> maybe you batch it?
04:23 < gurun> i batch the heavy/long running stuff.
04:23 < gurun> long running as in many many many small tasks.
04:24 < gurun> batch time is based on RakNet (MCPE) 10ms.
04:24 < gurun> so .. buffer would be a better word perhaps.
04:24 < gurun> trial and error again i guess.
04:26 < gamingrobot> maybe have a thread that has a list of entities it has to update, and that way you can still update on a world tick but across multiple threads
04:28 < benbaptist> hmm. why doesn't Minecraft's implementation of JSON like double-quotes for variable names? e.g. {"text": "Ohai."} versus {text:"Ohai."} (Or am I mistaken?)
04:29 < gurun> are you sure you are not confusing JS objects with JSON objects?
04:30 < benbaptist> I don't believe so - O
04:30 < benbaptist> Damn enter kye!
04:30 < ScruffyRules> gamingrobot, I heard you're helping with Spock?
04:30 < dx> benbaptist: {text:"Ohai."} is invalid json
04:31 < benbaptist> I know dx, and that's what Minecraft only seems to accept at times.
04:31 < dx> and i'm pretty sure the minecraft json parser won't take that
04:31 < dx> wat.
04:31 < benbaptist> well
04:31 < benbaptist> let me try to get you an example.
04:31 < dx> please do
04:31 < benbaptist> Minecraft's parser seems very cherrypicky on this subject, and sometimes it handles the "" under variable names just fine 
04:32 < benbaptist> i know Minecraft's tellraw command is very tolerant of these types of weird issues - e.g. `/tellraw @a {text:hi}` works 
04:32 < gamingrobot> ScruffyRules: yup
04:32 < benbaptist> not sure if they're using the same code for when parsing JSON in the protocol, though.
04:35 < benbaptist> Okay, so I was able to send the kick packet with the exact value for a string: {text:hi}
04:36 < benbaptist> However, I was unable to do this: json.dumps({"text": "hi"}) which results in the following string: {"text": "hi"}
04:39 < benbaptist> Wait, hold on. I might've worked this out. I didn't actually test json.dumps with the hi string - but I tested it with a ban reason sent from the vanilla server. It contained a newline, and I believe that newline threw something off. 
04:42 < benbaptist> dx, http://benbaptist.com/minescript/ - This generates a long command 
04:42 < benbaptist> sorry, my enter key keeps prematurely sending my messages.
04:43 < benbaptist> This generates a command and uses Javascript's JSON.stringify. I find it has parsing issues unless I remove the double-quotes from the string entirely - which oddly enough, that'll parse.
05:10 < gurun> separate entity ticks for each entity works just fine. Makes threading even easier since they don't affect eachother. So i'll go with that for a while and then see.
11:13 < ScruffyRules> nickelpro, You there?
14:34 < angal> How ti set chest block? I need to send something, except 0x23 (BlockChange)?
14:34 < angal> *to
14:53 < angal> Thanks. figured it out. Forgot to send blockstate.
15:47 < Bibl_> http://i.imgur.com/AwKotPD.png oo
15:47 < Weloxux> uh
15:48 < Weloxux> wazdat?
15:51 < Bibl_> i was just playing stuff and it looked nice lol
17:22 < Gjum> Bibl_: new debian logo
20:00 < gamingrobot> bleh figuring out what side something collided with is hard
20:39 < nickelpro> ScruffyRules: Your bug report is appreciated, I pretty much know what causes the issue. Working on it now
20:48 < ScruffyRules> nickelpro, Sweet.
21:04 < ScruffyRules> nickelpro, It's better but still not working. xD
21:04 < nickelpro> ScruffyRules: Like I said in the Github issue, the problem has two parts
21:05 < ScruffyRules> Ah
21:05 < ScruffyRules> Right
21:05 < nickelpro> Still working
21:14 < nickelpro> ScruffyRules: Maybe works now
21:14 < ScruffyRules> Will test.
21:17 < ScruffyRules> nickelpro, Works. :D
21:17 < nickelpro> ScruffyRules: Happy to help, please feel free to report any issues. Its very appreciated since I'm horrible with testing
21:17 < nickelpro> gamingrobot is trying to set me straight
21:17 < ScruffyRules> Ahahaha
--- Day changed dim. févr. 01 2015
00:18 < Paprikachu> i know there was a way to make the client show the packets it received
00:18 < Paprikachu> but i can't find it anymore
00:18 < Paprikachu> can anyone help me
00:21 < Paprikachu> nvm found it
12:16 < Paprikachu> i dont quite understand how the packet length field works for compressed packets
12:16 < Paprikachu> theres packet length and uncompressed lengtth
12:17 < Paprikachu> shouldnt packet length be the length of the packet in compressed form
12:23 < Paprikachu> nvm, i got it
20:15 < gurun> Anyone know if Mojang is making their LevelDB compile and run on Windows. Looking at resent checkins it kind of indicates that. Getting rid of some of the xtra libraries too.
--- Day changed lun. févr. 02 2015
00:13 < nickelpro> LevelDB?
00:15 < gurun> PE
00:25 < nickelpro> What's it do?
00:27 < gurun> storage for the client in PE.
00:27 < gurun> world, etc.
05:46 < kvgeorge1> anywhere here that can answer a question about the minecraft protocol - specifically serverbound packetID 0X3f5?
05:47 <+SpaceManiac> is this pocket edition?
05:47 < kvgeorge1> no - PC
05:48 <+SpaceManiac> there's no packet by the id of 0x3f5
05:48 < kvgeorge1> How about 1013?
05:48 <+SpaceManiac> that's the same number, so no
05:48 < kvgeorge1> basically, I am trying to capture packets when a user right-clicks on a sign
05:48 < kvgeorge1> what I get when trapping the PacketID is 0X3F5
05:48 < kvgeorge1> But, that is not documented on the wiki
05:49 <+SpaceManiac> maybe you are pulling from the length field and not the packet id field?
05:49 < kvgeorge1> could be
05:49 < kvgeorge1> but I can trap other Packet types using the same technique without issue
05:49 <+SpaceManiac> what technique is this?
05:49 < kvgeorge1> is there a specific packet id/type when a user right-clicks an entity/block?
05:50 < kvgeorge1> I am using a Rainbow server and building a ServerPacketListener
05:50 < kvgeorge1> In the listener, there is a field sent back called packetID that contains the id
05:50 < kvgeorge1> this is the number I am getting back when right-clicking on any block
05:50 <+SpaceManiac> right-clicking on blocks is various forms of play/serverbound/0x08 Player Block Placement
05:51 < kvgeorge1> including signs
05:51 <+SpaceManiac> maybe ask the Rainbow people
05:51 < kvgeorge1> hmmm...so, technically, I should be trying to trap 0x08 for right-clicking a sign
05:52 < kvgeorge1> I will try that first, then contact the Rainbow people.  Thanks for all your help
05:52 < dx> ...people seriously use rainbow?
05:52 < dx> that's worrying
05:55 <+AndrewPH> my keyboard's backlighting is set to rainbow wave
05:56 <+AndrewPH> something tells me that's not the rainbow you're referring to
05:57 < dx> http://www.project-rainbow.org/
12:16 < Paprikachu> how does multi-color text work with the new json chat?
12:24 < Fenhl> Paprikachu: it's pretty broken right now
12:25 < Paprikachu> meaning?
12:26 < Fenhl> hang on
12:27 < Fenhl> let me get an example
12:27 < Fenhl> ok, so for one, you can still use the old § escapes inside a tellraw text thing
12:28 < Paprikachu> i'm more interested in the server description right now
12:28 < Fenhl> Notchian client displays those mostly correctly (they reset at line breaks and soft wraps though)
12:29 < Fenhl> in the server list?
12:29 < Paprikachu> yes
12:29 < Fenhl> same story there afaik
12:32 < Fenhl> Notchian server seems to just put the description from server.properties in a JSON string and send that
12:32 < Paprikachu> weird
12:33 < Fenhl> meaning that § escapes in the property are sent literally and interpreted by the client as formatting codes
14:41 < Paprikachu> so... i'm sending chunks correctly to the client and unloading them as well
14:41 < Paprikachu> but sometimes the client just renders them extremely slow
14:42 < Paprikachu> takes like a minute for new chunks to appear after i moved, say, 5 chunks
14:43 < Paprikachu> and chunks are barely unloaded
14:49 < Paprikachu> i have a live server running at leaguecraft.cc:1337 if anyone feels like checking it out
14:49 < Paprikachu> protocol debugging shows that chunk data packets are sent correctly for both loading and unloading.
14:55 < barneygale> nickelpro, I put barneymc under MIT, btw. Not that it matters as you're not using any code from there anymore, right?
16:24 < Brycey92> is a TE's validate() function called on both server and client or only client?
19:14 < gamingrobot> Paprikachu: empty player list look so bizzar
19:17 < Brycey92> worldObj.isRemote returns if the world is NOT remote, correct?
19:17 < Brycey92> wait
19:18 < Brycey92> well you get the point
21:00 < Paprikachu> gamingrobot: heh
21:01 < Paprikachu> did you observe the same loading issues i did?
21:13 < Xor_Boole> mrw that paper title http://adriaanm.github.io/files/higher.pdf
21:17 < gamingrobot> Loading issues?
21:18 < Paprikachu> gamingrobot: yeah, fly around a bit and observe how the client just stops rendering chunks
21:18 < Grum> and after f3+a it does render them?
21:18 < Grum> or does it just not have them?
21:18 < Paprikachu> good hint, i'll try
21:18 < Paprikachu> that reloads the renderer, right?
21:19 < Grum> sortof yes
21:23 < Paprikachu> hm weird, can't seem to reproduce it anymore
21:23 < Paprikachu> magically fixed itself without even restarting the server i guess
21:25 < Xor_Boole> Paprikachu welcome to the protocol, I will be your guide
21:25 < Paprikachu> but i know that the client always had the chunks since i paid close attention to the multiplayer chunk cache variable which jumped whenever you would move to a new chunk (and then jump back to before when chunks are unloaded)
21:25 < Xor_Boole> *cue weird gif*
21:25 < Paprikachu> and it also displayed the packets being received with protocol debugging on
21:25 < Xor_Boole> actually, I think Thinkofdeath ridding a giant, sentient cat5 would be appropriate
21:27 < yawkat> We need a picture of Thinkofdeath for that 
21:27 < Paprikachu> Grum: wanna see what pain you guys are inflicting to me with your dynamically changing packet headers
21:27 < Xor_Boole> yawkat we can just do his ugly grim reaper skin
21:27 < Xor_Boole> Paprikachu don't you'll give him ideas
21:27 < Paprikachu> ?
21:28 < Xor_Boole> do you /want/ Grum to find more ways to torture us?
21:28 < Paprikachu> he already does?
21:28 < Xor_Boole> every single time I touch the protocol I end up pulling out some hair
21:28 < Xor_Boole> bah, whatever
21:28  * Xor_Boole goes back to reading that generics paper
21:29 < Paprikachu> http://ideone.com/wiFseB
21:29 < Paprikachu> one of the must ugliest - if not the ugliest - pieces of code i've written to this day
21:29 < Paprikachu> *most
21:30 < Xor_Boole> your first promblem: not using gist
21:30 < Xor_Boole> your second problem: using C++
21:30 < Paprikachu> not
21:30 < Xor_Boole> what does auto do again? type inference?
21:30 < Paprikachu> oh wait, is that a trolling attempt
21:31 < Paprikachu> sorry for responding :D
21:31 < Paprikachu> yes
21:31 < Xor_Boole> Paprikachu you don't know me do you
21:31 < Xor_Boole> I am a #mastertroll
21:31 < Paprikachu> :)
21:31 < Xor_Boole> blame Thinky
21:31 < Xor_Boole> fucking britbongs
21:32 < Xor_Boole> thinky is such a troll, he decided to +g *fuck* his channel
21:32 < Xor_Boole> I mean, it's not like there's any minors in there except yawkat and md_5 
21:33 < yawkat> Which is a bit ironic since md opped him 
21:33 < Xor_Boole> is md_5 still 17?
21:33 < Xor_Boole> I know he's like a few months behind me
21:34 < yawkat> No idea 
21:34 < Xor_Boole> I know because he's applying for uni and didn't apply to mine
21:36 < Paprikachu> you make me feel old :p
21:36 < Grum> they do not dynamically change
21:37 < Paprikachu> Grum: enabling compression changes headers, no? :P
21:37 < Xor_Boole> Paprikachu it's ok, I skipped a year. or... would that make you feel older? =D
21:38 < Paprikachu> i'm glad the first digit of my age is still a 1 for the few months i have left
21:38 < Grum> then you are just handling the packets wrong ;)
21:38 < Paprikachu> enlighten me, Grum :P
21:39 < Xor_Boole> Paprikachu > 19
21:40 < Xor_Boole> > feeling old
21:40 < Xor_Boole> seriously
21:40 < Paprikachu> uh yes
21:40 < Xor_Boole> I'm 18, how do I make you feel old
21:40 < gurun> Paprikachu: sad be the day when you can count to 4
21:40 < Paprikachu> 20 is a horrible number
21:41 < gurun> 20 is less than 4
21:41 < Xor_Boole> Paprikachu agreed
21:41 < Xor_Boole> not a power of two OR prime
21:41 < Paprikachu> :P
21:41 < Xor_Boole> horrible factorization
21:41 < Paprikachu> also, i love how c++ is the only language where listing all files in a directory is a hard task
21:41 < Xor_Boole> 19 is vastly superior
21:41 < Xor_Boole> Paprikachu execute ls -1
21:41  * Xor_Boole runs
21:41 < Paprikachu> that'd work
21:41 < Paprikachu> i don't like C++, i just don't hate it as much as other languages
21:42  * Xor_Boole crams scheme down Paprikachu's throat
21:42 < gurun> why do you have feelings about a lanauge?
21:42 < Xor_Boole> eat lisp peasant!
21:42 < cindy_k> I like C
21:42 < Paprikachu> call the ambulance
21:42 < Xor_Boole> gurun because my neckbeard senses tell me so
21:42  * Xor_Boole strokes neckbeard
21:42 < gurun> cindy_k: it's just becase of you rname
21:43  * gurun strokes his wifes neckbeard
21:43 < Xor_Boole> also a friend of mine insists that all scala devs are hat-wearing wikipedia editors
21:43 < Paprikachu> a full build of my server already takes over a minute to build
21:44 < Xor_Boole> except I don't edit wikipedia and I'm not wearing my fedora right now
21:45 < Paprikachu> 21:43:54 Build Finished (took 1m:29s.517ms)
21:45 < Paprikachu> what the fuck
21:45 < Xor_Boole> Paprikachu you're winner
21:45 < Paprikachu> :|
21:46 < Grum> Paprikachu: https://gist.github.com/grum/cb6ca427ad9901ee0f3d 
21:46 < Paprikachu> but is it efficient
21:47 < Paprikachu> i know you don't care, just curious
21:47 < Grum> no idea? it hasn't shown up as being slow :p
21:47 < Paprikachu> i guess i could have done everything way easier if i didn't try to make it almost zero-copy
21:49 < Paprikachu> but that's the price you gotta pay when you want efficiency i guess... you have to actually deal with this crap
21:49 < Grum> i love that, 'almost zero copy' means "not zero copy" :p
21:50 < Bibl_> ok so i'm writing my compiler for cfide
21:50 < dx> one copy
21:50 < Bibl_> and at the moment, when it reaches a character it doesn't know, it gives an error
21:50 < Bibl_> and im using regex
21:50 < Paprikachu> it's essentially zero-copy, except in some cases it's not because i didn't take the steps to make it fully zero-copy
21:50 < Bibl_> so when it cant find any valid token stuff it matches ANY(".|[\\s]"); and then prints that out
21:51 < Bibl_> is there a way to make it match until the next space/tab/newline
21:51 < Paprikachu> > .:Bibl_:. and im using regex
21:51 < Bibl_> like any characters until the new  /t/n/r
21:51 < Paprikachu> now you have 2 problems
21:51 < Bibl_> what do you mean :(
21:51 < dx> Paprikachu: i think it's really sad that your memory bandwidth is so low that you really need to optimize that
21:52 < dx> but it's okay some day you'll be able to afford a better microcontroller
21:52 < Paprikachu> way to be a dick :)
21:52 < dx> <3
21:52 < Grum> zero copy is kinda bs btw, you still need to turn whatever you are reading into the data you use, which is where you copy it :)
21:53 < dx> nah just use varints everywhere else
21:53 < Paprikachu> you could certainly use strings in-place
21:53 < Grum> sure
21:53 < Paprikachu> or arrays for that matter
21:54 < Paprikachu> if you don't care that you can't resize
21:54 < MrARM> heh, the price for that, is that the code will soon get hard to read
21:55 < dx> append-only structures are more efficient anyway
21:55 < dx> the same applies to code
21:56 < Paprikachu> certainly my encodePacket function is an ugly piece of shit, i don't disagree
21:57 < Paprikachu> i just hope i'll never have to touch it again
21:58 < MrARM> encryption...
21:58 < Paprikachu> won't touch the function
21:58 < MrARM> also, what about compression?
21:58 < Paprikachu> already implemented :P
21:58 < Thinkofdeath> Grum: (Offtopic) the FutureTask queue in MinecraftServer eats exceptions :3 Took me a while to work out why things weren't breaking
22:00 < MrARM> Paprikachu: how many lines it is that it takes 1 min to compile oO
22:01 < Paprikachu> my code has around 5k (output of wc -l)
22:01 < Grum> Paprikachu: i'm going to change encoding
22:01 < MrARM> urgh, how did you make it take an minute to complete then...
22:01 < Paprikachu> but if you're familiar with c++'s build system, you know that's not the full story
22:01 < Grum> wait, what, c++ has a buildsystem? lol!
22:02 < Paprikachu> ^
22:02 < TkTech> ^2
22:02 < MrARM> What do you do in the makefile?!
22:02 < dx> TkTech: I FOUND YOU
22:02 < TkTech> Oh shit
22:02 < Paprikachu> Grum: what are you going to change about encoding?
22:02 < TkTech> dx: Were you looking for me? What's up buddy?
22:03 < dx> TkTech: i sent a notifico PR, looking for feedback
22:03 < TkTech> Oh ho, one moment
22:04 < Grum> Paprikachu: anything so you have to change that file again ;D
22:04 < Paprikachu> heh
22:04 < Paprikachu> i have a suggestion for the protocol though
22:04 < Grum> afk
22:04 < Paprikachu> aka i'm about to get killed
22:04 < Paprikachu> :P
22:04 < dx> he's not going to return, rip
22:05 < Paprikachu> varint encoding is suboptimal for negative numbers
22:05 < Grum> known
22:05 < dx> ah yeah i mentioned those zigzag varints that thrift uses
22:05 < Grum> will be fixed somewhere when i decide to care, zipping is better
22:05 < Grum> err zigzag even
22:05 < Paprikachu> hm k
22:05 < MrARM> apache made an trick for that, I saw
22:05 < dx> https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/protocol/TCompactProtocol.java#L452-L458
22:06 < Grum> not a trick, just the way you do it
22:06 < Paprikachu> good thing my code doesn't care how varints are encoded
22:06 < Grum> then your code is broken
22:07 < Paprikachu> i meant the piece of code i showed before :P
22:59 < nickelpro> barneygale: Ehhhhh, the code is similar, you can definitely feel the "inspired-by" vibe in https://github.com/nickelpro/spock/blob/master/spock/mcp/mcdata.py and https://github.com/nickelpro/spock/blob/master/spock/mcp/mcpacket.py
23:00 < nickelpro> I appreciate the license in any case, your work was foundational to my understanding of a lot of minecraft minutia
23:04 < TkTech> dx: I'm leaning towards a multiselect box for actions and keeping the is_allowed for branch names.
23:05 < TkTech> dx: We can't be expected to know the branch names, and the users can't be expected to know the possible actions.
23:05 < TkTech> dx: There are no validation constraints on actions either so if they typo for example it'll suck for everyone
23:06 < dx> TkTech: wtforms.fields.SelectMultipleField?
23:06 < dx> i suspect the html side of that is shitty
23:07 < dx> TkTech: but good point, will do
--- Day changed mar. févr. 03 2015
00:47 <+Amaranth> MrARM: Long compile times are easy in C++ :)
00:48 <+Amaranth> And just as easy in Rust :/ I've got ~300 lines of code that, as a library, makes _users_ of the library take an extra 2 minutes to compile
00:56 < dx> ouch
00:56 < dx> i hope they manage to improve that over time
01:00  * Xor_Boole pokes Amaranth 
01:00 < Xor_Boole> have you ever had LHS lock up?
01:43 <+Amaranth> Xor_Boole: LHS?
01:44 <+Amaranth> dx: It was a 3x3x3x3 search area for 4D noise that I unrolled into 81 macro invocations and the macro calls 3 functions that I force to be inlined
01:44 <+Amaranth> It generates a shitload of code
01:45 <+Amaranth> And it inlines across crate boundaries because of the way I marked it for inline so every user of the library has to have the LLVM IR for that massive thing parsed and lowered again
01:45 < dx> Amaranth: oh so like macros in header files? (not sure if that makes sense in rust)
01:45 <+Amaranth> dx: More comparable to templates in header files
01:46 <+Amaranth> Like a header only library that is heavy on templates
01:46 < dx> fun
01:47 <+Amaranth> I cut the time down to 30 seconds by only unrolling the first 33 and running the other 48 via a loop
01:48 <+Amaranth> With most of the performance benefit from the unrolling still since it is likely to have found the closest two points in the first 33 and just do range checks for the rest
01:48 <+Amaranth> Still tweaking to find the right balance of performance vs compile time
11:01 < Paprikachu> how many block changes occur in 24h in a world with say 100 players, does anyone happen to have statistics on that?
11:02 < Paprikachu> Grum? :P
11:02 < gurun> PVP none :-)
11:03 < gurun> Are you looking for performance targets?
11:03 < Paprikachu> i'm trying to estimate how big a file tracking all changes could get
11:03 < Paprikachu> since i'm thinking of building kind of a transaction save format
11:04 < gurun> A transaction log...
11:04 < Paprikachu> that also allows arbitrary rollbacks
11:04 < Paprikachu> built in right into the server
11:05 < gurun> I would suggest tagging..
11:05 < Paprikachu> i'd group changes by chunk, so a change is always relative to the chunk position
11:05 < Paprikachu> which means i can store block coords in 2 bytes, 2 more bytes, makes 4 bytes
11:06 < Paprikachu> then i'd also want the world age at which it occured, another 4 bytes
11:06 < Paprikachu> and probably a timestamp, 4 more bytes
11:06 < gurun> Storage is cheap.
11:07 < Paprikachu> player uuid would be convenient, another 16 bytes
11:07 < Paprikachu> makes it 28 bytes
11:07 < Paprikachu> per single block change
11:07 < gurun> Make sure you use sequential UUID in that case, so it can be indexed effeciently
11:07 < Paprikachu> huh?
11:08 < gurun> Just google it
11:08 < gurun> SQL server uses them.
11:09 < Paprikachu> i could just define yet another set of ids
11:09 < Paprikachu> don't need to be uuids
11:10 < Paprikachu> most of those would be 1-2 bytes then
11:10 < Paprikachu> if i use varint encoding
11:11 < gurun> Well, the honest advice I would give is ..make it work, stable and then fast
11:11 < gurun> Refactoring....
11:12 < Paprikachu> i could probably just offset the timestamps and world age from the last save
11:12 < Paprikachu> which would make those fields significantly smaller
11:12 < gurun> Well, another advice then. Use UTC, always.
11:12 < Paprikachu> i mean, obviously :)
11:13 < gurun> And just a reference to a world time, but for information only.
11:13 < Paprikachu> world time should be the primary key so to speak
11:14 < Paprikachu> it's the only thing guaranteed to advance and be stable
11:14 < Paprikachu> real time can get awkward when you change the system clock
11:14 < Paprikachu> i'd probably need to track system clock changes to maintain a coherent view of time
11:15 < gurun> But advice around the target.. You are asking "how long is a string" question. So you could do like me, exaggerate widely.
11:15 < gurun> Like, how many updates do I need to handle in the server.. Well, I have no idea. So I use 400 players moving between 4 chunks sending updates to each other.
11:16 < jast> time as a primary key requires quantizing changes on a per-second basis
11:16 < gurun> If I can deal with that, I can probably deal with a world of 400 real players or even 10 times as much.
11:16 < Paprikachu> jast: i was thinking of tracking them per tick :P
11:17 < jast> sounds nasty :}
11:17 < jast> what kinds of things do you want to do with that log?
11:18 < gurun> Will you be storing in a real DB?
11:18 < Paprikachu> world -rollback -date 1/2/14 -time 13:40:56
11:18 < Paprikachu> stuff like that
11:18 < Paprikachu> or world -rollback -player foobar
11:19 < jast> thing is, rolling back several days worth of data can take a _long_ time if you have to apply each change individually
11:19 < Paprikachu> not the way i'm storing stuff
11:19 < Paprikachu> my files are going to be append-only
11:19 < Paprikachu> you can just truncate it to where you want to go.
11:19 < jast> in that case first reading in the files will be slow
11:19 < Paprikachu> gurun: no real db, that'd be way to slow
11:20 < Paprikachu> too
11:20 < Fenhl> if you're going to work on a log format for Minecraft worlds I'd be interested in that
11:20 < jast> I'm mentioning because redis does persistence that way, and recovering from a crash takes a _long_ time
11:20 < Paprikachu> jast: should be instant here
11:20 <+Amaranth> There are custom DB chunk based logging plugins for Bukkit
11:20 < Paprikachu> but yeah, loading could take longer
11:20 <+Amaranth> Or were
11:20 < jast> initializing from append-only files is never instant :}
11:20 < Fenhl> something I've always wanted to do is a server mod that can record gameplay and play it back later
11:21 < Paprikachu> well, i'm not going to log everything
11:21 <+Amaranth> Fenhl: Someone did that, went live a couple days before protocol encryption came and broke it
11:21 < Fenhl> heh
11:21 < jast> just so we're on the same page: recovering state from a log can take several hours
11:21 < Paprikachu> no
11:21 < Paprikachu> recovering is instant
11:21 < Fenhl> well if it's a server mod you wouldn't care about encryption
11:21 <+Amaranth> You connected to your target server via a proxy then you could login to the proxy as a spectator and replay the recording
11:21 < jast> by recovering I mean restarting the server after a crash
11:22 < Paprikachu> well, you pay the cost of loading it again
11:22 < Paprikachu> but who cares, that's constant cost.
11:22 < jast> exactly, and that will be many, many hours once you've collected enough data
11:22 < Paprikachu> i don't think so ;)
11:22 < gurun> Db too slow. Not sure what db you are using then :-P
11:22 <+Amaranth> How is that constant? That's like O(n) at best where n is the length of the log
11:22 < jast> unless you store the data twice: once as a log, once as a snapshot
11:23 < Paprikachu> Amaranth: depends on what you refer to by n
11:23 < jast> gurun: everybody knows DB is not web scale
11:23 <+Amaranth> Paprikachu: I just told you what I refer to by n
11:23 < gurun> Haha, LOL
11:23 <+Amaranth> In the same sentence, like, right there
11:23 < Paprikachu> what i meant was that loading only occurs once
11:23 < Paprikachu> so i don't really care how long it takes
11:23 < jast> exactly, and loading once takes several hours with a few gigabytes of log
11:23 < Paprikachu> performance of loading chunks on demand is where it gets interesting
11:24 < jast> yeah, that'll take several hours again, most likely
11:24 <+Amaranth> iirc this is how git works btw, it periodically snapshots things so it doesn't have to reconstruct shit from the entire commit history
11:24 < jast> git always snapshots everything
11:24 < jast> and does delta compression under the hood, periodically, to make the full snapshots more space-efficient
11:24 <+Amaranth> Nah, it's not a snapshot every commit
11:24 < Paprikachu> and also, one could always merge the changes
11:24 < jast> it is
11:24 < jast> I've contributed to the code base, I know how it works ;P
11:24 <+Amaranth> Hmm, maybe I'm misremembering
11:24 < gurun> yiu have to differentiate between latency and latency. Since this is append only, you can just free thread it and hand it over to the db. No need to wait for the transaction to return :->
11:25 < Paprikachu> i don't like dbs though :P
11:25 < Paprikachu> i'd rather build my own thing that supports just the stuff i need.
11:25 < gurun> I doubt you will get anywhere near db performance working with IO on disc.
11:25 <+Amaranth> Just use sqlite ;)
11:26 < Paprikachu> i don't like sql, so i won't use any sql-ish thing
11:26 < Paprikachu> includes sqlite
11:26 < jast> sqlite is one of the better embedded DBs
11:26 < jast> yeah, and I don't like transistors, that's why I use valve-based computers
11:26 <+Amaranth> sqlite is just an easy way to get a super efficient persistent storage
11:26 < jast> well sqlite isn't really super efficient
11:27 < Paprikachu> sql and efficient don't work together
11:27 < jast> especially not with its defaults, which are geared towards _robustness_
11:27 < jast> Paprikachu: false
11:27 < Paprikachu> operations as strings, lol
11:27 < Paprikachu> parsing that thing takes longer than inserting a million entries
11:27 < jast> in fact with SQL you can do query optimizations that are not possible with unstructured or overly simple queries
11:27 < gurun> SQL and effecient doesn't have anything to do with eachother :-P
11:27 < jast> don't exaggerate, it doesn't help your argument
11:27 <+Amaranth> Err, which are converted to an AST and optimized based on the query and the table(s) it's being run against
11:27 < Paprikachu> great, but i don't need that
11:27 < jast> also SQL statements can be prepared, after that they're compiled for the remainder of the session
11:28 < Paprikachu> i know the set of operations i want to work with
11:28 < gurun> You could always go with LevelDB if you want something fast. After all, you do C right
11:28 < Paprikachu> don't need it to be fully generic
11:28 < Paprikachu> c++ actually
11:28 < gurun> Well, it is c++ actually
11:29 < gurun> As I understand, the C API is a wrapper around the C++ :-)
11:29 < Paprikachu> look, i can see the merits of databases, but for me, the disadvantages in this case are greater than what i'm gaining
11:29 < Paprikachu> which is potentially shitty performance
11:29 < jast> only if you do it wrong
11:29 < Paprikachu> you can't tell me that storing a million block changes is going to be faster with a database
11:30 < Paprikachu> there's no way that's going to work out
11:30 < gurun> I bet you implemented your own logging API too :-)
11:30 < jast> depends on what you do and how you do it
11:30 < jast> most databases are configured so that they commit the data to disk before they return, and that's what takes the most time
11:30 < Paprikachu> it's next to impossible to beat a write to disk
11:30 < jast> if you don't do fsync() or something like that, of course you're going to be heaps faster
11:30 < gurun> Paprikachu: THAT is completey wrong!!!
11:30 < Paprikachu> gurun: logging? i don't really have logging right now, i log to stdout :DD
11:31 < jast> transaction logging, duh
11:31 < jast> databases can usually be configured to either wait until disk is synced, or enforce syncs periodically
11:31 < jast> if you want to have a good trade-off between robustness and performance, you're going to have to write something like that yourself
11:31 < jast> or you can just trust the OS to sync when you need it... good luck :)
11:32 < gurun> And you have fire and forget. Since you don't care about the transactions. Or do you intend to write a faster transaction manager than the DB?
11:32 < jast> it's not so critical when you do append-only storage, but then again that won't really scale once you introduce on-demand loading
11:32 < Paprikachu> i'd just collect changes in memory until the world is saved
11:32 < Paprikachu> and then write out everything all at once
11:32 < jast> okay, so performance without robustness, got it :}
11:33 < Paprikachu> it's robust enough
11:33 < Paprikachu> configure your auto save properly
11:33 < gurun> How much throughout do you have today? Max?
11:33 <+Amaranth> It does make sense to only save your log as often as you save your world
11:33 < Paprikachu> losing 10 minutes is not a big deal
11:33 < jast> well, I mean, nothing wrong with that. it's what the standard MC server does, too.
11:33 <+Amaranth> Otherwise you might log things that didn't make it to the world or vice versa
11:34 < Paprikachu> transactions would be on a per-save basis anyways
11:34 < jast> Amaranth: AFAICT he wants to implement *only* logging for storage
11:34 < gurun> So, what you are saying is that, the You could allow the DB up to 10 minutes to execute inserts?
11:34 < Paprikachu> sure i guess
11:34 < gurun> If we are not talking realtime persistence, the whole discussion is mot
11:35 < gurun> Then you can just use access or excel :-P
11:35 < Paprikachu> :DD
11:35 < gurun> Hihi
11:35 < jast> plain XML files
11:35 < gurun> Haha
11:35 < Paprikachu> oh god
11:35 < Paprikachu> i should totally implement that
11:35 < gurun> I hear JSON is popular these days
11:35 < jast> nothing beats XML files
11:35 < jast> which is a shame... I think they deserve a sound beating
11:35 < Paprikachu> maybe some kind of dynamically loaded library for providing saves
11:36 < Paprikachu> so i could implement a XmlSaver
11:36 < Paprikachu> :DD
11:36 < jast> no, that won't work
11:36 < jast> you're going to need a TransactionalAbstractXmlDataSerializerProxyFactory
11:36 < Paprikachu> :)
11:36 < gurun> Haha
11:36 < gurun> I suggest *dbblob
11:37 < Paprikachu> gurun: i have to admit, you make a fair point with async saving
11:37 < gurun> I think it could work.
11:37 < Paprikachu> but the question is: how expensive will that be?
11:37 < Paprikachu> will it consume resources on my machine?
11:37 < Paprikachu> and which ones?
11:37 < gurun> I will try that on MiNET and let you know how that play out. I also want a temporal storage like you do.
11:38 < Paprikachu> because even if it runs async, it could make the machine unsuable
11:38 < gurun> Try LevelDB. I mean, it works for MCPE, and is supposedly very very fast.
11:39 < gurun> I promised myself to attempt a .NET port of that soon. A lot of demand for that.
11:39 < Paprikachu> i dunno about that
11:40 < gurun> .and it's not SQL
11:40 < Paprikachu> i don't like depending on too many libs :|
11:40 < Paprikachu> especially ones that i don't have a clear idea of yet.
11:40 < gurun> Here is a problem that I think will demand for you to go DB.
11:40 < gurun> You aim at scaling to 1000+
11:41 < gurun> so, that means a single instance will manage lots of different worlds.
11:41 < gurun> Your discs, unless they have infinite amount of heads, will not be able to deal with it. You will sync out on the IO immediately.
11:41 < Paprikachu> that depends on what you're using
11:42 < Paprikachu> a ssd should be able to handle it
11:42 < gurun> Basically, the kernel even will kill you before you get started.
11:42 < gurun> SSD is fast but not infinite fast.
11:42 < Paprikachu> i don't constantly write to disk though
11:43 < jast> well if you're I/O-bound, a database isn't magically going to make things better
11:43 < Paprikachu> since i collect changes, i can write them all at once, which gives performance
11:43 < gurun> If you batch things, it changes the requirements so much that you should go back and rethink it.
11:43 < Paprikachu> what?
11:43 < gurun> I assume you also want to focus on the core of the functionality, not necessarily write your own DB unless absolutely failing. Right?
11:44 < Paprikachu> i don't want a db, i already said that - unless we have different definitions of db
11:44 < gurun> And for hosting, serious hosting. I don't think anyone want the DB on the same machine either.
11:44 < gurun> DB is DB regardless how you do it. ISAM or not :-P
11:45 < Paprikachu> to me db approximately means 'something that uses sql and stores data'
11:45 < gurun> Yeah, and that is where you get it wrong.
11:45 < Paprikachu> i don't like the sql part ;)
11:46 < gurun> So, don't hate the word DB. Use it to your advantage instead, to target your google searches.
11:46 < gurun> As I said, LevelDB is NOT SQL.
11:46 < gurun> Lots of DB doesn't not use the language SQL
11:46 < Paprikachu> and i think that my problem is specific enough that i won't find anything that is a good enough match
11:46 < gurun> I think it is actually the "relational" part that you hate
11:47 < gurun> So search for fast blob storage db.
11:47 < gurun> Like Amazon and MS have.
11:47 < Paprikachu> let's just go the other way around
11:48 < Paprikachu> why would i use a db when i can store it on disk directly
11:48 < gurun> Because DB is a concept
11:49 < gurun> Our DB is a file storage. Never heard that expression.
11:49 < gurun> ISAM, index file storage
11:49 < gurun> A DB standard.
11:50 < gurun> SQL server also writes the data to a file. Just that they invent their own file system ...
11:50 < gurun> So, if you have a method in your code called "writetofile" that is your "DB"
11:51 < gurun> I bet your interface will be called IChunkDb :-)
11:52 < gurun> And I predict that in a couple of years you will opensource your implementation as a separate project calling it "high performance file DB" :-P
11:52 < barneygale> hah
11:52 < barneygale> just go back to saving each chunk in a file
11:52 < gurun> ..and then you will see on the project page that it links to "similar projects" about a million of them, all faster :-P
11:52 < barneygale> it worked for mojang ;D
11:53 < gurun> Yeah, file AND folder if you ever want to run it on windows :-P
11:54 < gurun> But eh absolutely funniest thing is that...
11:54 < gurun> ..someone decide to use your server, and the first thing they do is to store the world data on a a SAN disk :-P
11:54 < Paprikachu> wait, vanilla uses a single file per chunk?
11:55 < gurun> Anvil
11:55 < gurun> ?
11:55 < MrARM> region
11:55 < MrARM> few chunk columns
11:55 < gurun> But hmm, that's the old, isn't it?
11:57 < barneygale> Paprikachu, it used to
11:57 < barneygale> hasn't done in a couple years now
11:57 < Paprikachu> hm ok
11:58 < barneygale> (because it was slow as balls)
11:58 < Paprikachu> i can imagine
11:58 < Paprikachu> any reason why it doesn't just use a single file though?
12:03 <+Amaranth> It wasn't really that bad on most Linux file systems, iirc
12:03 < jast> if the size of a single region changes, having them all in the same file can mean 90% of the file needs to be rewritten
12:03 <+Amaranth> The main performance benefit was on Windows
12:03 < jast> or more, in fact
12:03 < Paprikachu> if you design it inproperly :)
12:04 < jast> well the easiest way to do it is multiple files, in this case, and there's no significant impact on performance, anyway, compared to one fragmented huge file
12:05 < Paprikachu> if you like losing your data sure i guess
12:05 < jast> after all loading new regions doesn't need to happen that often
12:05 < Paprikachu> overwriting is just a bad idea imo :|
12:06 < jast> it can be done safely, and... less so
12:26 < gurun_> Paprikachu: how far did you get. Can you do the basic stufff with the server now?
12:27 < Paprikachu> yup, and i already have a chunk generator api
12:27 < Paprikachu> and i have a public server running
12:28 < gurun_> did you do any performance test?
12:28 < Paprikachu> not yet
12:28 < gurun_> i'm in desperate need to compary with something
12:28 < Paprikachu> leaguecraft.cc:1337
12:28 < gurun_> i don't have MCPC :-P
12:29 < Paprikachu> :P
12:30 < gurun_> my test is basically to spam the server with move-messages
12:30 < gurun_> like from 500 players every say 50 ms (doesn't matter if it is 20 or 50ms)
12:30 < gurun_> in the end, measure throughput in/out. Mostly out.
12:31 < gurun_> like now
12:31 < gurun_> i'm connecting 700 players. THey result in outgoing stream of 700*700*20 moves per second processed.
12:32 < gurun_> roughly 10.000.000 moves being processed on the outgoin pipe.
12:32 < gurun_> And then, the goal is to have no bytes waiting in the receieve buffers, and keep latency through the server below avg 10ms and tick time below 5 ms.
12:33 < gurun_> in the end, the measurement will be throughput. Around 400mbit/s on that configuration.
12:34 < Paprikachu> i'm just gonna use the same strategy as bukkit
12:34 < gurun_> oh, what is that?
12:34 < Paprikachu> release it and see how it goes :D
12:35 < gurun_> well, i run this tests daily .. 
12:35 < gurun_> .. it has a tendency of affecting design a LOT.
12:35 < gurun_> like checking for simple things like "is the player in water?".
12:35 < gurun_> .. or lava.
12:35 < gurun_> had to rewrite the whole thing to deal with that stuff. Total redesign. So now i continously do the performance tests.
12:36 < gurun_> i set a target of 400 players so i won't overdo it..
12:36 < Paprikachu> i wanna get 2k
12:36 < gurun_> but then, i thought you where serious about the 1000+ (10k+) .. :-P
12:36 < Paprikachu> i've come to realize that 10k is probably impossible :D
12:36 < gurun_> probably not at all
12:37 < gurun_> i do 700 now over UDP. And UDP is really a big bottleneck for me on this machine.
12:37 < Paprikachu> udp is a different story
12:37 < gurun_> my router overheated and closed down if i run it over network.
12:37 < Paprikachu> :DD
12:37 < gurun_> if i would change the implementaiton to TCP now, i could probably do it at least 10-20 times as much.
12:37 < gurun_> at least
12:39 < gurun_> actually, it's the first time i made it to 700 without buffer overflow now. SO .. now test with a 1000 and see it burn again :-P
12:40 < gurun_> i'm not maxded out on the CPU yet hehe
12:40 < Paprikachu> :)
12:41 < gurun_> HAHA
12:41 < gurun_> 100% CPU but holding
12:43 < gurun_> 1000 players. Latency through server at 15ms, tick time 5-10ms, buffer holding (no problem). That's about 20M moves/s
13:15 < xehbit> "Paprikachu | release it and see how it goes :D" made my day hehheh :D
13:15 < Paprikachu> :)
13:16 < gurun_> design my accident :-)
13:16 < gurun_> designed by accident (damn keyboard)
13:16 < xehbit> But, you're writing a server ?
13:16 < Paprikachu> yup
13:17 < xehbit> Cool, what language :) ?
13:17 < Paprikachu> c++
13:17 < xehbit> Nice!
13:18 < Paprikachu> https://bitbucket.org/Paprikachu/quicksilver-flatgenerator/src
13:18 < xehbit> Oh, cool, opensource :D
13:19 < Paprikachu> all i can show though, server is closed source :P
13:19 < Paprikachu> ^
13:19 < xehbit> Ah :(
13:19 < xehbit> Thats sad :)
13:20 < xehbit> I wish MC used UDP
13:20 < xehbit> for movements
13:21 < Paprikachu> or even better, something like raklib :P
13:21 < xehbit> raklib :P ?
13:21 < Paprikachu> or raknet, whatever it's called
13:22 < xehbit> oh, heard about it yea
13:22 < xehbit> idk what it is hehheh
13:22 < gurun_> why do you do a closed source project? What's the point of that when you are cracking a software?
13:22 < gurun_> it's like begging for it..
13:22 < Paprikachu> what
13:22 < xehbit> He could have hist reasons
13:22 < gurun_> just saying ..
13:22 < Paprikachu> who is cracking anything
13:22 < xehbit> True
13:22 < xehbit> You :)
13:22 < Paprikachu> i have bought minecraft
13:22 < xehbit> Nononono
13:23 < xehbit> that is not what he means hehheh
13:23 < MrARM> lol
13:23 < xehbit> right gurun_ ?
13:23 < gurun_> xehbit: yes, very right.
13:23 < xehbit> you're cracking the server, to write your own
13:24 < Paprikachu> idk what it means then
13:24 < gurun_> i have to say that i have tremendous respect for the way Mojang has dealt with this so far.
13:24 < xehbit> About hacking their software ?
13:24 < gurun_> i used to do ICQ back in the days.. and lest say, they where not so forgiving when they sold it for that 11bilion
13:25 < xehbit> gurun_: i dont get it :P ?
13:25 < gurun_> they came at us with lawyers :-(
13:25 < xehbit> Oh, i see
13:26 < gurun_> and what did we do with ICQ? We reverse-engeneered their protocol.
13:26 < xehbit> Hehheh, the same thing about reverse engineering the WhatsApp proto
13:27 < xehbit> They do everything to block that :(
13:28 < MrARM> cuz it's bad
13:28 < xehbit> To reverse engineer a proto ?
13:28 < MrARM> no
13:28 < MrARM> the protocol for WhatsApp is bad
13:28 < MrARM> seeing how many times it was hacked before
13:28 < xehbit> Oh yea, correct!
13:28 < xehbit> Still dont get it why they dont use XMPP
13:29 < xehbit> That would be awesome, and user friendly for other platforms
13:29 < jast> well they probably don't want to be open
13:30 < jast> add to that a healthy dose of NIH syndrome, and you have yourself a new protocol
13:30 < gurun_> you know about XMPP
13:30 < gurun_> after ICQ came hunting.. we started a new IETF group called IMPP.
13:31 < Paprikachu> who is 'we'?
13:31 < jast> also I think some of the things in XMPP are a dirty hack, and it makes certain routing designs terrible
13:31 < gurun_> after a while all the big guys came (Microsoft at that time). And they destroyed the workgroup.
13:31 < gurun_> and then came the true open standards around that stuff.
13:32 < gurun_> Paprikachu: we as in a bunch of guys in interet
13:33 < gurun_> IETF <used to have> this nice culture around "implementation over spec". So while they where analyzing it to bits and pieces, we did working implementations. After a while they got tired of loosing against the small hackers..
13:59 < Grum> < Paprikachu> how many block changes occur in 24h in a world with say 100 players, does anyone happen to have statistics on that? <-- billions depending on the server
13:59 < Paprikachu> a billion in 24h?
13:59 < Paprikachu> that doesn't sound right
14:02 < gurun_> an explosion per second .. around 3 milion blocks
14:02 < gurun_> so ... no not bilions
14:05 < Paprikachu> a few million changes wouldnt even result in that much log data... just a few megs
14:05 < Paprikachu> but billions would be an issue
14:06 < gurun_> contrary to what might feel natural .. i don't think chunk-management is a problem on that end.
14:07 < gurun_> neither sending, reading or writing.
14:07 < gurun_> just store it in a wire-friendly format.
14:10 < Paprikachu> don't state the obvious :P
14:10 < Paprikachu> actually i do things a little bit differently
14:10 < Paprikachu> i don't have any of that section stuff, chunks are just uint16[256][16][16]
14:13 < gurun_> well, we had to explain to you that db is the way to go .. that was pretty obvious to the rest of us :-P
14:14 < Paprikachu> db is not wire friendly
14:15 < Paprikachu> and still wrong
14:15 < gurun_> hehe
14:21 < jast> do you want to persist stuff like redstone state, too?
14:22 < Paprikachu> redstone state is just regular block state
14:24 < jast> okay, same question, different words :)
14:25 < jast> because that means you'll have to log all changes in state in addition to changes of the blocks themselves... most of the time it probably isn't going to be too horrible, but elaborate redstone setups can probably inflate the set of changes quite a bit
14:25 < Paprikachu> hm
14:25 < Paprikachu> true that
14:26 < gurun_> entities, block entities, c.
18:25 < anonzadas> can someone give me a help with Entity Properties??
18:26 < anonzadas> Sorry, I mean Use_Entity
18:27 < anonzadas> I'm reading from I'm reading from http://wiki.vg/Protocol#Entity_Properties what are the fields, but dont know what is the target
18:29 < ellisvlad> ...Oh the joys of Eclipse not rebuilding it's index correctly 0.0 I've been thinking this bug was my fault all night... http://i.ellisvlad.com/EWuR2.png
18:32 < ellisvlad> Very annoying behaviour and Eclipse plays it off like it's done nothing wrong :P
18:42 < gurun__> i don't think it was a secret
20:52 < Paprikachu> i really don't understand how server and client lighting work together
20:53 < Paprikachu> the server can't send lighting updates, correct
20:53 < Paprikachu> so that'd mean in return that any changes to sky light need to be detected by the client in order for it to render correctly
20:54 < Paprikachu> except they're not, i'm setting skylight to 15 for every block and skylight doesn't change on the client when i update blocks
20:54 < Paprikachu> caves are fully lit up
20:54 < Paprikachu> except the client says skylight 14 instead of 15
20:57 < Paprikachu> in other words, is there any way to make the client not care about light the server sends
23:34 < ellisvlad> Paprikachu: Sending the light value of 15. Is that the byte that you are sending? or the nibble? Because the light sent byt teh server is two values per block. One for block light and one for sky light. Block light gives the lit block a yellow-y tinge, but otherwise is almost the same as skylight (as far as I can tell...). But minecraft client will update lighting client-side of any blocks you 
23:34 < ellisvlad> interact with/stand near every so often. Other than that, you have to implement lighting yourself....
23:35 < ellisvlad> Kind of like this: In it's simplest form.. out_light = in_skyLight * in_skyBright + in_blockLight
23:35 < ellisvlad> But you have to provide all the lighting, yes..
23:35 < ellisvlad> *initial lighting
23:42 < ellisvlad> http://minecraft.gamepedia.com/File:Light_night.PNG - X=skyLight Y=blockLight
23:43 < ellisvlad> edit: *sigh* X=blockLight Y=skyLight
23:44 < Paprikachu> ellisvlad: skylight and blocklight is sent seperately, and i'm sending nibble vaues of 15
--- Day changed mer. févr. 04 2015
02:47 < Paprikachu> http://i.imgur.com/cKtFUMa.png
02:47 < Paprikachu> 3d function plotter!
02:47 < Paprikachu> x^3 * y
03:03 < Xor_Boole> Paprikachu gniess
03:04 < Paprikachu> what does that mean
03:04 < Paprikachu> :p
03:06 < Xor_Boole> gniess is a type of rock, pronounced "nice"
03:06 < Xor_Boole> I am funny. laugh, mortal.
03:07 < Paprikachu> huehuehue
16:54 < Xor_Boole> I wonder how many services exploded because they weren't UUID ready =D
17:09 < Fenhl> scoreboards did
17:10 < redstonehelper> optifine capes did too apparently
17:10 < Xor_Boole> are scoreboards not uuid ready?
17:10 < Xor_Boole> redstonehelper > optifine capes
17:10 < Xor_Boole> kek
17:10 < redstonehelper> scoreboards are not, but that's working as intended
17:10 < Fenhl> yeah, except nearly everyone uses them to store info about players
17:11 < Fenhl> and does not expect them to break when someone changes their name
17:11 < Fenhl> but that's what happens
17:11 < Xor_Boole> scoreboards aren't meant for that
17:11 < Xor_Boole> but then again a lot of things are used for things they're not meant for.
21:42 < Xor_Boole> are there any good command-line minecraft clients? too busy to finish mine these days
21:44 < Xor_Boole> unrelated: can we have an API for looking up all name changes in a time interval, w/ timestamps?
21:44 < Xor_Boole> could be useful for things
21:47 < Thinkofdeath> Xor_Boole: use case?
21:47 < Thinkofdeath> struggling to see one
21:48 < Xor_Boole> for data visualization mostly
21:48 < Xor_Boole> you could pull up the name changes in a time period and graph it
21:48 < Thinkofdeath> So... no 'real' use then
21:48 < Xor_Boole> you could also potentially track trends in names
21:48 < Xor_Boole> Thinkofdeath die
22:05 < gamingrobot> Xor_Boole: what do you want the client to do?
22:05 < Xor_Boole> gamingrobot just chat, it's commandline
22:07 < gamingrobot> how does spigot do the > in the console?
22:07 < gamingrobot> I am trying to do something similar in python
22:07 < Xor_Boole> they use jline, which in turn calls gnu read
22:08 < Xor_Boole> or does native shit on wandows (which shouldn't be used anyways)
22:26 < gamingrobot> yay readline works
22:26 < gamingrobot> it should work on windows but not sure
22:27 < Xor_Boole> > windows
22:27 < Xor_Boole> > 2015
22:27 < Xor_Boole> > giving a fuck about it
22:28 < gamingrobot> everything else in spock works on windows :P
22:30 < _zoot> Xor_Boole: year of the linux desktop 2016
22:32  * Xor_Boole secretly uses BSD
22:32 < _zoot> BSD makes a good router and NAS, but that's all its good for
22:32 < _zoot> also macfags
22:33 < Xor_Boole> specifically, I used closed BSD. also known as Darwin, or by its marketing moniker, osx
22:33 < Xor_Boole> or, by gamerfags, "mac", which is a disgusting name
22:34 < Xor_Boole> osx is about half as good as linux, mostly because brew exists
22:35 < _zoot> Why do you use it then?
22:36 < jast> I believe darwin is only part of osx
22:37 < Xor_Boole> jast darwin is the BSD component iirc
22:37 < jast> in any case, I don't feel the need to take anyone seriously who wastes time talking about how horrible one of the popular operating systems is :)
22:38 < _zoot> install gentoo
22:38 < Xor_Boole> http://en.wikipedia.org/wiki/Darwin_(operating_system)
22:38 < Xor_Boole> darwin is the open source bit
22:38 < _zoot> >opensource.apple.com
22:38 < _zoot> Now there's a URL I didn't ever expect to exist.
22:39 < Xor_Boole> jast well, windows /is/ a bad user experience, but ultimately linux trumps all
22:39 < Xor_Boole> _zoot opensource.microsoft.com is also a thing
22:39 < jast> the quality of user experience depends on the user, too
22:39 < jast> I use windows, and while I do most of my actual work in a linux VM, the OS itself I don't really mind
22:40 < _zoot> Do it the other way around and use VGA passthrough to get native graphics performance in the VM
22:40 < Wuppie> lol, managed to get my mc username to be PocketEdition
22:40 < Wuppie> :P
22:40 < Xor_Boole> jast such is life =)
22:40 < jast> I need a lot of direct hardware access in windows, e.g. for ASIO
22:40 < Xor_Boole> I spent most of this morning explaining to a friend why delegates are useless if you have lambdas
22:40 < jast> and there's no noticeable slowdown inside the VM, so this way works better for me
22:41 < Xor_Boole> cindy_k you're crazy!
22:41 < Xor_Boole> jast I'm a macfag in college. woop-tee-doo
22:41 < Xor_Boole> I'm also a math major, which means my OS is irrelevant as long as mathematica runs on it
22:41 < Xor_Boole> #mathematicamasterrace
22:42 < jast> by delegates you're referring to what's commonly called the delegation pattern?
22:42 < _zoot> http://shop.gluglug.org.uk/product/libreboot-x200/
22:42 < jast> I used mathematica for a little bit. it's great for symbolic computation but I don't need to do that a whole lot
22:42 < Xor_Boole> jast no, C# delegates. unless that refers to the same thing
22:42 < jast> I believe delegates in CLI are language-level support for the delegation pattern
22:43 < Xor_Boole> it's basically function pointers
22:43 < Xor_Boole> which all sane lambda-using langauges have already
22:43 < jast> well it's kind of different, actually
22:43 < jast> and I don't know, I can see one or two advantages to delegates
22:43 < Xor_Boole> then ms's documentation sucks then, because that's the gist I got
22:43 < Xor_Boole> do tell me what is different
22:44 < Xor_Boole> I could potentially like C# a little more
22:44 < Xor_Boole> honestly it doesn't help that C#'s lambda syntax /also/ uses the `delegate` keyword
22:45 < jast> honestly I'm not familiar enough with CLI's delegates to be sure about this
22:45 < jast> I just read that delegates can carry an object reference as part of them. is that right?
22:45 < Xor_Boole> it looks like method references to me with some pretty stuff
22:45 < Xor_Boole> jast idk, I'm just another java user that likes hating on C#
22:45 < jast> oh, right
22:46 < jast> well I hate java with a passion, so that's great :)
22:46 < Xor_Boole> well, I also hate on java, since I'm actually a scala user
22:46 < jast> and you're not going to see me sing the praises of the JVM either
22:46 < Xor_Boole> java: great, modern runtime, shitty language from the 90s
22:46 < jast> in fact I'm more likely to say favourable things about the CLR
22:46 < _zoot> b-b-b-but c style syntax is the best syntax :'(
22:46 < Xor_Boole> _zoot go back to your hole
22:47 < Xor_Boole> meh, haskell is better than both anyways
22:47 < jast> personally the thing I'm most excited about for the near future is rust
22:47 < Xor_Boole> rust looks fun
22:47 < Xor_Boole> but lisp is fun too
22:47 < Xor_Boole> LIIIISP
22:47 < jast> I dunno, haskell doesn't seem like that much of an advantage to me, in most scenarios
22:47 < jast> I made a project in haskell once and it was awesome for _that_
22:48 < Xor_Boole> jast the main thing you get out of haskell is: elegant code, easy-to-read-and-maintain code, occasinal performance improvements due to lazy eval
22:48 < jast> about a fifth the LoC compared to the C++ impl a friend of mine wrote, and only about 40% slower
22:48 < Xor_Boole> yep, that's the same story with java v scala
22:48 < jast> it's not always elegant :) when you have to start munging several monads together, things can get hairy
22:49 < Xor_Boole> though a lot of people compare java v scala to c v c++
22:49 < Xor_Boole> except c++ is a language designed by too many cooks
22:49 < jast> and lisp... I dunno, all of the dialects are dynamically typed, aren't they?
22:49 < Xor_Boole> yes
22:49 < jast> and no proper namespacing from what I've seen so far
22:49 < Xor_Boole> lisp is good for small things, that's it
22:49 < jast> I much prefer static typing with type inference
22:49 < _zoot> lisp? what year is it?
22:50 < jast> I've toyed with ideas about a new language, with the same power as lisp, but static typing and *gasp* syntax
22:50 < Xor_Boole> _zoot 6 of our Lord Obama
22:50  * Xor_Boole runs
22:50 < jast> but the runtime-extensible parser was too much work for me to actually implement :)
22:50  * _zoot goes into the time machine and writes lisp in emacs
22:50 < Xor_Boole> jast fun fact: scala turns into a lisp-like thing halfway during compilation
22:51 < jast> a few months ago I decided to give emacs an honest try... the one thing that turned me off was that the lisp environment felt like a huge unsorted bag of names
22:51  * _zoot edits the emacs config with vi
22:51 < cindy_k> delegates are ok, function pointers are better. long live C :)
22:53 < jast> what I don't like about lambdas is that you're usually saddled with uncontrollable closures, so as long as your lambda lives you have tons of other stuff pinned in memory... would be kind of nice to decide myself what to keep and what to toss
22:54 < Xor_Boole> jast scala is secretly lisp https://gist.github.com/drXor/3673aed7380522dd8c90
22:54 < jast> yeah, I've heard about that
22:54 < Xor_Boole> jast closures are fine if they're implemented sanely, i.e. only the needed variables get captured
22:55 < jast> most of the time you simply get a grab bag of everything that's accessible in the given context
22:55 < Xor_Boole> e.g. val x: Int => String = _.toString shouldn't capture anything
22:56 < jast> yeah, that's straightforward, because you can essentially just make it into a direct reference to toString
22:56 < jast> if your language isn't too dynamic you can analyze which references are needed, so that's okay