11:53 < barneygale> chill out
11:53 < jast> oh hey you used the name of a fallacy. you win.
11:53 <+md_5> http://whofortedblog.com/wp-content/uploads/2013/03/strawman2.jpg
11:53 < jast> barneygale: just a bit of harmless ircing
11:54 < Paprikachu_> people make mistakes. making things easy is thus better unless there is technical reasons for not doing so.
11:54 <+md_5> um
11:54 < jast> I still think naming fallacies is for people who don't have arguments
11:54 < Paprikachu_> "saving space" is a bullshit reason for varints, the savings are irrelevant.
11:54 < jast> the technical reason, in this case, is backward compatibility
11:54 <+md_5> savings are irrelevant to you
11:55 < jast> the non-technical reason is "nobody but you gives a damn"
11:55 < Paprikachu_> backwards compatibility doesn't count, innovation always wins.
11:55 < jast> okay!
11:55 < jast> let me just switch this IRC server to an encrypted proprietary protocol real quick, so we can stop talking to you
11:55 <+md_5> I was actually involved a bit with the design and network engine rewrite that occurred here, and I fully support the notion of varints.
11:56 < Paprikachu_> md_5: so what was the reason to introduce them
11:56 <+md_5> in the year 2013, there is no technical reason for concern
11:56 < Paprikachu_> what?
11:57 < Paprikachu_> sorry, but this reasoning is just bullshit.
11:57 < barneygale> Paprikachu_, pretty sure the reasons are bandwidth and backwards-compatibility
11:57 < Paprikachu_> you are saying you did X, because there was no reason not to do X.
11:57 < jast> please rewrite minecraft protocol as an extension to IP. because efficiency.
11:57 <+md_5> if this was 1962 you may say that the bitshift and loop to decode a varint was cause for concern, given that my CPU can execute said loop in about 3 instruction cycles, I dont think efficiency is an argument
11:57 <+md_5> as for possible reasons
11:57 <+md_5> 1) Save bytes
11:57 <+md_5> 2) No fixed packet size limit
11:57 < jast> let's hope Paprikachu_ never has to work with a protocol that uses *gasp* compression
11:58 < barneygale> md_5, how many bytes does it save?
11:58 < SinZ> well, a fixed packet size limit would need to be the largest possible packet, which would be a chunk packet
11:58 < Paprikachu_> md_5: and both of those arguments are artificial made up bullshit.
11:58 <+md_5> a couple of bytes here and there for no measurable cost
11:58 < jast> SinZ: I think we're talking about varint fields here, not entire packets
11:58 <+md_5> no
11:58 <+md_5> SinZ 's point is valid
11:59 < Paprikachu_> space savings: completely irrelevant, do the math.
11:59 < Paprikachu_> no fixed packet size limit: bullshit again, you're never going to need more than 4 bytes.
11:59 <+md_5> the take away Im getting here is that varints are too hard for you
11:59 < barneygale> md_5, entity metadata format saves bytes too, but it's pretty retarded and most of the rest of the protocol doesn't go to such lengths to save space. Where do you draw the line?
11:59 < jast> SinZ wasn't talking about the "packet size" field, but about the size of the packet itself
12:00 < jast> I think
12:00 <+md_5> https://en.bitcoin.it/wiki/Protocol_specification#Variable_length_integer
12:00 < Paprikachu_> md_5: in return the protocol sends json over the network, fucking JSON. wheres your space savings there
12:00 <+md_5> https://developers.google.com/protocol-buffers/docs/encoding#varints
12:00 < jast> can we just use SOAP, guys?
12:00 <+md_5> you seem to be getting very fired up over a simple thing
12:00 <+md_5> its an extra 5 lines of code for you to write....
12:01 < jast> well, clearly arguing about it is a much more efficient way to get things done
12:01 < Paprikachu_> no, it's not
12:01 <+md_5> if varints are so shit, then why do they exist
12:01 < jast> in the time we've been talking about it I could have implemented it in hand-written x86 machine code
12:01 < jast> none of that fancy assembly crap
12:01 < barneygale> I'm not surprised he's getting frustrated when you guys are ridiculing him for quite a simple observation: why save a few bytes here and there through variable length headers, when the rest of the protocol is wasteful?
12:02 < gurun> varint good or not. that has to be a matter of statistics on the specific implementation.
12:02 < barneygale> I'm not saying I agree
12:02 < gurun> did anyone actually measure the saving of it over a normal session?
12:02 < SinZ> barneygale: since when was optimisation all or nothing?
12:02 < barneygale> but jast you're being a total knobhead to him
12:02 < Paprikachu_> md_5: there are use cases for varints, but this is not it.
12:02 < jast> barneygale: bit late for that, though. it simply doesn't make sense to belabour the point.
12:02 <+md_5> barneygale we provided a reason: backwards compatibility, but apparently that isnt good enough
12:02 < barneygale> I agree with the backwards compatibility point
12:02 < Paprikachu_> md_5: bullshit, backwards compatibility didnt exist when you introduced them.
12:02 < barneygale> And I don't even care particularly
12:02 < jast> barneygale: well that's what I do when someone else immediately goes "no you're wrong and you understand nothing about this"
12:02 < gurun> unless of course you need some monster int bigger than int64
12:02 <+md_5> so what
12:02 < barneygale> My code is in python so efficiency is out the window for me.
12:02 <+md_5> they were introduced
12:03 <+md_5> there is nothing you can do to change that
12:03 <+md_5> bickering over the reasons solves squat
12:03 <+md_5> you are just making yourself look like a pork chop
12:03 < jast> mmm pork chop
12:03 <+md_5> go write your own voxel game
12:03 < jast> time for lunch
12:03 < Paprikachu_> no, you are not even trying to understand my point, because you have already decided for yourself that i'm wrong, you refuse to read.
12:03 <+md_5> well yes, 
12:03 < jast> I understand your point, I just don't care at all
12:03 <+md_5> the protocol headers are not changing
12:04 <+md_5> there is nothing you can say to change that
12:04 < jast> and you're wasting your time, I'm just making sure you're wasting it with maximum efficiency of wasteage
12:04 < SinZ> and even then, the varint header was nothing but an improvement
12:04 < Paprikachu_> except not.
12:04 < SinZ> it was no length prefix in the past
12:04 < barneygale> SinZ, yep, a huge improvement
12:05 <+md_5> in an ideal protocol every integer would be a varint, and thats the way the protocol is going in future updates
12:05 < jast> btw you're going to love the varints in the Ogg container format
12:05 < Paprikachu_> different story probably, dunno.
12:05 <+md_5> jast but ogg is an application level protocol!
12:05 < barneygale> christ md_5
12:06 < Paprikachu_> and this ladies and gentlemen is how you get shitty, slow software
12:06 < barneygale> you're a bit like ricky gervais: I love the work you do, but I wouldn't want to sit next to you on a plane.
12:06 < jast> a segment in ogg works like this:
12:06 < Paprikachu_> you have people like grum and md_5 who just dont care about anything at all, "oh, the jvm is gonna fix it" (or not)
12:06 < SinZ> Who specified jvm here
12:07 < jast> <length, 1 byte> <<length> bytes>
12:07 < Paprikachu_> and who are too stubborn to listen to anyone
12:07  * md_5 wonders what java has to do with this
12:07 < jast> if length == 255, repeat until you encounter a length < 255
12:07 < SinZ> ^
12:07 <+md_5> no one is listening to you because it CANT be changed
12:07 < Paprikachu_> md_5: that's what grum said yesterday
12:07 <+md_5> and?
12:07 < Paprikachu_> i put you in his boat
12:07 < Paprikachu_> the boat of stubborn java programmers :)
12:08 < SinZ> yay unneeded stereotypes
12:08 < jast> so, for each 255 bytes of data, you have one byte of length info
12:08 <+md_5> so refusing to break compatibility with millions of users is being stubborn?
12:08 < Paprikachu_> jast: i really don't care, and it's probably justified (or not, i wouldnt care)
12:08 < jast> so a packet with a size of 64K has 258 bytes of length data
12:08 < jast> see, just like I don't care about whatever bugs you about whatever
12:08 < Paprikachu_> there is no ideal solution for everything, and varints are not suited for packet headers in minecraft.
12:08 <+md_5> good
12:08 <+md_5> point taken
12:09 <+md_5> but saying that wont change anything
12:09 < Paprikachu_> hey, you admitted i'm right
12:09 <+md_5> maybe it was a bad choice, maybe it wasnt. Either way it has to stay.
12:09 < Paprikachu_> progress!
12:09 < gurun> well all admit that you are right Paprikachu_, just that we will never admit that it is a reasonable request to change the protocol.
12:09 < jast> oh, we're doing the war metaphor
12:09 < Paprikachu_> i'm glad we have that out of the way.
12:10 < jast> "I won this battle. my supreme military might prevails yet again."
12:10 < jast> good on you
12:10 < Paprikachu_> you know what, i'm going to take a step back as well and say that maybe after all backwards compatibilty is a good enough reason not to change it because it works.
12:11 < Paprikachu_> not saying it's a good reason, but good enough.
12:11 <+md_5> sorry, just timed out
12:11 <+md_5> maybe varints were a bad idea, maybe they were a good idea, either way it doesnt matter because it cant be changed.
12:12 < Paprikachu_> [12:04] <Paprikachu_> you know what, i'm going to take a step back as well and say that maybe after all backwards compatibilty is a good enough reason not to change it because it works.
12:12 < Paprikachu_> [12:05] <Paprikachu_> not saying it's a good reason, but good enough.
12:12 < gurun> md_5, well. Consider this scenario that I work on with moveplayer messages in PE.
12:13 <+md_5> gurun first things first, try to only send move packets to players within reasonable range of eachother 
12:13 <+md_5> (no idea if the current servers do that)
12:13 < gurun> I creat a message with the location. The only difference between the packages sent is the entity-id
12:13 < gurun> so, i can directly manipulate the bytes for that and make Buffer.Copy and send.
12:14 < gurun> with a varint, that would be impossible.
12:14 < Paprikachu_> good point
12:14 < gurun> in a perfect world, instead of even having a buffer for each package to be sent, i can reuse the buffer and work un-threaded.
12:14 < gurun> because that would be the fastest.
12:14 <+md_5> performance impact of just using a gathering write across two buffers would be practically nil
12:15 < gurun> uh?
12:16 <+md_5> disclaimer: I have no idea what the PE protocol is like
12:16 <+md_5> but just a  write(header), write(entityId), write(restofpacket) will have negligible performance impact
12:16 < gurun> it's the "same" in concpet, just different sending. A move is still a move. A move still needs bytes for location and orientation.
12:16 < gurun> it's not like it is a world difference.
12:17 < gurun> it's the same as in battlefield or counterstrike.
12:17 <+md_5> C has stuff like readv and writev which can handle this for you
12:17 < Paprikachu_> md_5: actually, you dont want to have 3 writes for that. syscalls are expensive.
12:17 <+md_5> ....
12:17 <+md_5> youre writing a minecrfaft server
12:17 < Paprikachu_> ...?
12:17 <+md_5> 3 syscalls are the least of your worries (to draw upon the example you used earlier about 3 extra bytes)
12:18 <+md_5> heck, libc probably does something fancy when using the proper vectored write instructions anyway
12:18 < gurun> i think it is a pretty big difference between writeing write(byte) 3x and write(buffer) one time.
12:18 < jast> actually writev is a syscall, too
12:19 <+md_5> I was just checking that.,.....
12:19 < jast> a thousand buffers, one syscall. yay!
12:19 < gurun> in a perfect world, it would work like gfx cards. direct buffer access.
12:19 <+md_5> yeah it is too
12:19 < jast> DMA really only helps for unidirectional communication
12:20 < jast> once it gets bidirectional, you have to do lots of complicated things to not break everything
12:20 <+md_5> http://lxr.free-electrons.com/source/include/linux/syscalls.h#L565
12:21 <+md_5> one syscall for 0 <= x <= IOV_MAX buffers
12:21 < Paprikachu_> probably still more efficient to just use a single buffer.
12:22 < gurun> maybe i should try to write an unsafe version of the send-pipe.
12:22 < Paprikachu_> especially because your first 2 buffers would be really small.
12:23 <+md_5> If you spend this much time focusing on each component your server is never going to go anywhere.
12:24 <+md_5> sys_writev exists for a reason, to write multiple buffers with a single syscall
12:24 < Paprikachu_> thing is, i'm already done with that
12:25 <+md_5> I can almost guarantee there is no performance difference between that and a larger single buffer.  Furthermore, any such difference would be measured in the nanoseconds and not have any real bearing on the performance on your server
12:25 < Paprikachu_> and i can already spawn in an empty world
12:25 <+md_5> "an empty world"
12:25 <+md_5> you can do that in < 100 lines of code
12:25 < Paprikachu_> not really
12:26 <+md_5> take a look at MCserver for example
12:26 <+md_5> https://github.com/mc-server/MCServer
12:26 <+md_5> 8000 commits later and its not even close to being close to being feature parity with Vanilla
12:26 <+md_5> Anyone here remember pbunny?
12:26 < Paprikachu_> i'm not gonna say that all of my 3100 lines are needed to get a running server you can connect to, but some initial design choices need to be made.
12:27 <+Fador> md_5: pbunny \o/
12:27 < SinZ> \o/
12:27 < Paprikachu_> and mcserver seems to be written in pretty shitty c++.
12:28 <+md_5> you are clearly better  at this than everyone in the channel, so why are you here still?
12:28 < Paprikachu_> where exactly did i say that?
12:28 < SinZ> you have been implying it the entire time
12:28 < Paprikachu_> not really.
12:28 <+md_5> I never said you said it, I made an observation based on your attitude :)
12:29 < Paprikachu_> but for clarity, i'm going to make a bold claim here: i don't know everything.
12:29 < Paprikachu_> newsflash!
12:33 < Paprikachu_> md_5: and as for your question, i have hope :)
12:33 < Paprikachu_> hope that one or two of you will eventually become a better coder by looking outside of the java fairy world
12:34 < gurun> i don't think this has anything with attitue about java todo.
12:34 < Paprikachu_> there is a certain mindset that java people seem to have which causes lots of issues.
12:35 <+md_5> clearly based on the observations above java is the lowest level language Ive ever laid eyes upon
12:35 < Paprikachu_> the mindset of 'the jvm is going to all of my shitty code'
12:35 < Paprikachu_> +fix
12:35 <+md_5> oh good now we're making sweeping generalisations
12:36 < Paprikachu_> http://java.dzone.com/articles/memory-access-patterns-are
12:36 < Paprikachu_> heres why the server is slow
12:36 < gurun> ah, no it is about having the jvm take care of the shit, and then knowing how the jvm does it, and then optimizing for that.
12:36 < Paprikachu_> not gonna say more
12:36 < barneygale> md_5, oh god pbunny
12:36 <+md_5> or on the other hand experienced java programmers do fancy things like use offheap memory so the jvm doesnt stuff things up
12:36 <+md_5> what gurun said
12:37 < Paprikachu_> md_5: great, except minecraft doesn't do any of that.
12:37 <+md_5> and?
12:37 <+md_5> <Paprikachu_> hope that one or two of you will eventually become a better coder by looking outside of the java fairy world
12:37 <+md_5> no one in this conversation works for mmojang
12:38 < Paprikachu_> oh, i just generalized because you seem to have the exact same attitude :)
12:39 < Paprikachu_> good for you if you know more, sad that you didn't use it to improve anything
12:39 <+md_5> ......
12:40 <+md_5> and here you are just expecting the optimizer to fix all your shitty code, clearly the Minecraft server should be written in assembly.
12:41 <+md_5> Do you not realise the ridiculousness of these generalizations
12:41 < Paprikachu_> err no, i'm not expecting the optimizer to fix anything. i expect it to perform optimizations that can enhance the performance a little.
12:41 <+md_5> so then what makes you say
12:41 <+md_5> <Paprikachu_> the mindset of 'the jvm is going to all of my shitty code'
12:42 < Paprikachu_> the fact that people like you (hello generalization, so convenient) think like that.
12:42 <+md_5> ....
12:42 < gurun> .....
12:42 <+md_5> you know what I think, how?
12:43 <+md_5> based on the fact I dont care about your desire to break a protocol which does its job fine?
12:43 < Paprikachu_> yes, it would totally break the protocol.
12:43 < Paprikachu_> the world would end.
12:43 <+md_5> ....
12:43 <+md_5> when you have a userbase of > 10 million, come back to me about that
12:44 < Paprikachu_> there's a thing called an update.
12:44 < Paprikachu_> i'd assume you've heard of it before.
12:44 <+md_5> hint: when players get "connection timed out" or "protocol error" trying to connect to their favourite server, they get sad
12:45 < Paprikachu_> they get an error anyways when the protocol number doesn't match.
12:45 < gurun> md_5, that is about "when" you sit down and start building your own. Having your kid cry for being kicked off is motivation enough.
12:45 < barneygale> could you please fucking quit it. neither of you is going to persuade the other person of your viewpoint any more. don't sustain arguments just for the sake of it.
12:45 <+md_5> yes, but it says "outdated server"
12:45 <+md_5> as opposed to "connection error"
12:45 < Paprikachu_> md_5: congratulations, you can do that even with such a change.
12:45 <+md_5> ........
12:46 <+md_5> You can make an old application automagically understand and decode a new protocol?
12:46 <+md_5> Please share your secrets.
12:46 < gurun> Summary: Paprikachu_ says "optimization is the most important in the world" md_5 says: "i make money, you dont'"
12:46 < Paprikachu_> i doubt he does.
12:47 < MrARM> I don't think he does get money lol
12:47 <+md_5> fuck it, I'm going to bed
12:47 <+md_5> this is just stupid
12:47 < Paprikachu_> but hey, it's generally agreed on that minecraft's performance sucks in every regard and it has a lot of issues.
12:47 < MrARM> but still, current protocol does do it's job fine
12:48 < Paprikachu_> oh it does, but you can always improve something.
12:48 < MrARM> on vanilla, the server can't handle more than 100 player at once due to rest of the code
12:48 < gurun> it is also generally agreed that we wouldn't have this discussion without that crappy minecraft existing..
12:48 < Paprikachu_> some of the proposed changes are cleanup, some of them are performance improvements.
12:48 < Paprikachu_> cleanup certainly isn't necessary, but nice to have nonetheless.
12:49 < MrARM> also, varints are a bit weird to use for stuff like packet id
12:50 < Paprikachu_> MrARM: well, i'm sure java is one of the issues. not because you aboslutely can't write efficient java code, but because it suggests to oh-so-great object oriented designs which lead to terrible performance.
12:50 < MrARM> how would one get past 255 packets
12:50 < barneygale> MrARM, well, they were using something like 50% of that in 1.6 iirc
12:51 < MrARM> also, you have GC, meaning you have very little control over memory's
12:51 < Paprikachu_> i wouldn't know, but 2 bytes can fit 64k.
12:51 < Paprikachu_> that's plenty
12:51 < barneygale> iirc they also argued that mods might want to use more packet IDs, which is a totally bizarre argument considering mojang usually take pride in not giving a fuck about 3rd parties
12:51 < Paprikachu_> well, it's kind of true
12:51 < Paprikachu_> i'd suggest 2 byte ids
12:51 < Paprikachu_> that's enough for every possible use case ever.
12:52 < MrARM> uh, or if (firstByte == 255) readShort for rare enough packets
12:52 < MrARM> and the first byte for really often ones
12:52 < Paprikachu_> so... varint16? :D
12:53 < Paprikachu_> (kind of)
12:53 < MrARM> huh
12:53 < Paprikachu_> it has the same problems as varint :P
12:53 < MrARM> oh well
12:53 < MrARM> yeah, then a short is the only solution
12:54 < Paprikachu_> minecraft needs a rewrite using data oriented design
12:54 < Paprikachu_> and also not java
12:54 < Paprikachu_> java leads to object oriented designs,which is bad
12:55 < barneygale> you're not pbunny, are you?
12:55 < Paprikachu_> the entire inheritance hierarchy of entities, players, mobs, vehicles and what have you is just a huge performance issue
12:55 < Paprikachu_> and who tf is pbunny
12:55 < Paprikachu_> i think i knew if i were him/her
12:55 < barneygale> he used to come in here and chat shit about java constantly
12:56 < barneygale> not saying you do that
12:56 < Paprikachu_> well, those are the issues i talked about that java can't fix for you.
12:56 < barneygale> but it's an argument this channel has seen enough times now..
12:57 < Paprikachu_> java has a lot of libs available and building and shit works like a charm, i'll give you that
12:57 < Paprikachu_> but other than that, it's just a huge pita, i can't write java without getting pissed off about how the language gets so much stuff wrong.
12:57 < Paprikachu_> http://java.dzone.com/articles/memory-access-patterns-are
12:57 < Paprikachu_> i've linked this post before
12:58 < MrARM> let's say every language is bad except assembler maybe
12:58 < MrARM> someone will always find something for every language that's bad
12:58 < barneygale> ^
12:59 < MrARM> actually, Java performance is bad
12:59 < Paprikachu_> c++ has it's issues with build systems and the syntax is sometimes a little clunky, but other than that, it gets the important things right.
12:59 < MrARM> if MCPC was coded in C++ it would get at least 2x more fps
12:59 < Paprikachu_> what many people fail to understand is that performance is not so much about the code, it's about the data
13:00 < Paprikachu_> finding a sequence of instructions that does something faster is good and can lead to some improvements, but getting data layout right can give you 100x speedups
13:01 < Paprikachu_> the things that slow cpus the most these days is data access
13:03 < Paprikachu_> http://i.imgur.com/X1Hi1.gif
13:03 < Paprikachu_> this is a very representative diagram
13:09 < jast> that diagram is precisely the reason I don't care about most constant factors in pure computation performance
13:10 < jast> usually most of the time is spent waiting for I/O anyway, inner loops in number crunching code aside
13:11 < Paprikachu_> well, the minecraft server is definitely cpu capped
13:11 < jast> still no reason for me to ever touch java, of course
13:11 < jast> in the last ten years I've never touched java code unless I was paid for it
13:13 < Paprikachu_> heh
13:14 < jast> I think 99% of minecraft's CPU use is accounted for by the requirements of the game logic, forcing you to have tick processing code with an insane number of data dependencies
13:14 < gurun> so, just to be clear. We are not saying that the vanilla server has problems, because of the protocol, do we?!
13:14 < jast> well it's definitely not the biggest problem...
13:14 < Paprikachu_> no, i didnt say that
13:14 < Paprikachu_> otherwise i wouldnt write my own server
13:14 < gurun> jast, no i realize that YOU don't say that
13:15 < jast> yeah, just making sure we all have that, specifically, as common ground
13:15 < Paprikachu_> jast: but slow data access could be the reason
13:15 < Paprikachu_> i'm very sure it's at least among the reasons
13:15 < jast> well, many events require millions of data accesses and updates
13:15 < jast> packets don't even factor into that part
13:15 < jast> light updates, for example
13:16 < Paprikachu_> well yeah
13:16 < Paprikachu_> but this is where the OO-design issue i said comes in
13:16 < jast> well no
13:16 < jast> I mean, of course it adds some kind of overhead
13:16 < Paprikachu_> i doubt it's just chunk data
13:17 < jast> but at the end of the day you still have to run a calculation on millions of data cells
13:17 < jast> (pun originally not intended)
13:17 < Paprikachu_> but that's not how computers work...
13:17 < Paprikachu_> well, not exactly
13:17 < gurun> the biggest culprit for performance in my server used to be JIT_new
13:17 < gurun> that indicates issues either with ctor or GC
13:17 < gurun> the second highest was ctor, so it wasn't really GC.
13:18 < Paprikachu_> jast: entity containers are just one of those examples
13:18 < Wuppie> So, what are you guys talking about? :D
13:18 < gurun> i implemented an object pool, and that went away.
13:18 < Paprikachu_> ArraList<Entity> or whatever the fuck
13:18 < jast> I mean, I know you can implement a much faster client, I've seen examples... it stands to reason the same is true for servers
13:18 < Paprikachu_> that's just a performance killer
13:18 < jast> but still you have requirements in the game engine, and those will always give you hard ceiling on performance
13:19 < Paprikachu_> yes, but i don't think that's the issue
13:19 < Paprikachu_> the issue is inefficient data access patterns
13:19 < jast> oh dang, I forgot an article. veering dangerously close to pbunny...
13:19 < Paprikachu_> inheritance for entities is just asking for it
13:20 < jast> inheritance doesn't necessarily cause bad data access patterns... bad code access patterns are pretty likely, though :)
13:20 < jast> though you can fix that with insane amounts of inlining, too
13:20 < Paprikachu_> it makes them very easy :P
13:20 < jast> you'll still get tons of cache misses, but there's no way around that
13:20 < Paprikachu_> and now that i think of it,it's even worse
13:21 < jast> I think to make it seriously more efficient you're going to need to come up with new data structures
13:21 < Paprikachu_> because even if you didnt have inheritance Container<SomeClass> is always going to be slow
13:21 < Paprikachu_> because java
13:21 < Paprikachu_> jast: actually, value types are the solution
13:21 < Paprikachu_> and array-like containers.
13:21 < jast> I'm not talking about how to fix java
13:21 < jast> I'm talking about how to fix things that can't be fixed simply by porting to a different language/VM
13:22 < Paprikachu_> it's all about design
13:22 < jast> that class of fixes can be used to improve performance in any implementation, even java-based ones
13:22 < Paprikachu_> if you design it correctly, the expensive tasks will have near cached performance
13:24 < jast> a light update, for instance, still requires accessing several megabytes worth of data
13:24 < jast> cache? gone.
13:25 < Paprikachu_> well, does it?
13:26 < Wuppie> i guess http://wiki.vg/SMP_Map_Format is not up 2 date?
13:26 < Wuppie> The Data section atleast
13:26 < jast> well, it's a tradeoff
13:27 < Wuppie> because http://wiki.vg/Protocol#Chunk_Data says that the block id is now an unsigned short
13:27 < jast> you can either maintain an index of locations that will be affected by a light update, or iterate over a much broader set of potential locations when the update arrives
13:27 < jast> both causes overhead, just at different points in time
13:27 < Paprikachu_> lighting in minecraft is pretty basic though
14:22 < Grum> < Paprikachu_> [12:08:01] there is no ideal solution for everything, and varints are not suited for packet headers in minecraft. <-- they are? they are as suited as any type
14:23 < Grum> though a string might be a rather bad idea
14:36 < Wuppie> LOOOL, made MC a disco... Send time update... FLASH FLASH FLASH FLASH FLASH FLASH
14:49 < Paprikachu_> Grum: do we have to get into this discussion again? :|
14:49 < Wuppie> Fixed it :)
14:53 < Grum> Paprikachu_: if you keep bringing up stupid stuff you are going to keep getting that pointed out
14:53 < Paprikachu_> well, how about this instead: http://codepad.org/eXLUu0lL
14:54 < Paprikachu_> some points you already disagreed on, so forget about them
15:05 < Paprikachu_> (1) and (2) is what i really care about, (3) and (4) are kinda meh and (5) would be cool to have :p
15:06 < Grum> Paprikachu_: line 8 already flies for us, its super trivial to implement
15:07 < Grum> that completely invalidates 3
15:07 < Grum> and 4
15:07 < Paprikachu_> yeah, lets just discard 3 and 4
15:07 < Grum> and 5 makes no sense
15:07 < Paprikachu_> i already know your stance on that
15:07 < Paprikachu_> eh?
15:07 < Grum> you tick at 20tps, done :)
15:08 < Grum> the whole game is based on that
15:08 < Paprikachu_> it's not hard to change though
15:08 < Grum> lol
15:08 < Paprikachu_> you can take real time and then recalculate how much that is in ticks
15:08 < Grum> such naive, wow
15:08 < Grum> ah you can?
15:08 < Grum> and that requires no changes in any code anywhere?
15:08 < Paprikachu_> yes?
15:08 < Paprikachu_> i didn't say it doesnt
15:09 < Grum> eventhough all gameplay is based on having 20 ticks per second?
15:09 < Grum> and not skipping the,
15:09 < Grum> *them
15:09 < Paprikachu_> i mean sure, it's a huge change
15:09 < Wuppie> Remember that redstone ticks and stuff would also be different than...
15:09 < Paprikachu_> but it's not hard
15:09 < Wuppie> (atleast i guess)
15:09 < Thinkofdeath> Huge change for no gain
15:10 < Paprikachu_> well, my server will support different tick rates, if clients dont send updates that fast, that's unfortunate, but oh well
15:10 < Grum> its not hard?
15:10 < Grum> you seriously have absolutely no idea what you are talking about
15:10 < Paprikachu_> you can keep the server at 20 ticks
15:10 < Paprikachu_> only the client requires changes
15:10 < Grum> except that we just handle data from the client at 20tps ... because that is the biggest rate we can handle things in
15:11  * Wuppie got scared of grum
15:11 < Paprikachu_> ?
15:11 < Grum> if you want to allow 10 times higher tps from the client you are going to get 10 times more cheating :)
15:11 < Paprikachu_> i don't get what you're saying
15:11 < Paprikachu_> tick rate would be server controlled
15:11 < Thinkofdeath> (which it is already easy to cheat)
15:11 < Grum> except that the server has no way of handling more than 20 'inputs' per tick
15:11 < Paprikachu_> if you only suport 20 tps in vanilla, your server doesn't need any changes
15:11 < Grum> err second
15:11 < Paprikachu_> clients won't be sending more than that
15:11 < Paprikachu_> it's server controlled
15:12 < Grum> We're not going to change the client for a theoretical change that someone might want to do that is actually not remotely a good change at all
15:12 < Paprikachu_> i dunno how many changes the client would require
15:12 < Paprikachu_> probably not that many?
15:12 < Grum> beyond turning on: ZOMG SPAM BANDWIDTH
15:12 < Paprikachu_> (actually curious)
15:12 < Paprikachu_> Grum: thats the server owners problem
15:13 < Grum> an actually having data 100 times per second (this means the internal ticking @ client has to run @ 100tps)
15:13 < Grum> which means the whole game has to run at 100tps
15:13 < Grum> because the simulation the client does is the same the server does
15:13 < Paprikachu_> yes, which is why i asked what the changes to the client would be
15:13 < Grum> read
15:13 < Grum> it is *the same* as the server does
15:14 < Paprikachu_> mh
15:14 < Paprikachu_> so... redstone calculations as well and stuff?
15:14 < Grum> so now guess how that is implemented, clearly by maintaining two completely sepArate codebases that do exactly the same right? i mean it is java and that is the slowest possible way you can develop it
15:14 < Paprikachu_> ...
15:14 < Grum> so we must clearly have picked that
15:14 < Paprikachu_> no need to get pissed
15:14 < Paprikachu_> i'm just asking ok
15:15 < Paprikachu_> so what about (1) and (2)
15:15 < Grum> it is already trivial to implement the protocol
15:16 < Grum> (2) should be done just because what we do now is stupid and prevents you from teleporting between 'two identical typed dimensions'
15:16 < Grum> (1) doesn't actually solve any problem
15:17 < Paprikachu_> the only reason (1) works for you is because your implementation is single threaded more or less
15:17 < Grum> not at all?
15:17 < Grum> entity ids are just used for communication and nothing else
15:17 < Grum> sorry, serialization
15:17 < Grum> (which includes network and diskwriting)
15:17 < Paprikachu_> you have to have some sort of container that maps entity ids to data
15:17 < Grum> no?
15:18 < Paprikachu_> ?
15:18 < Paprikachu_> how do you identify entities then
15:18 < Grum> not sure, but i tihnk interaction with an entity sends the 'id of the entity interacted with'
15:18 < Grum> so i guess we need to be able to look up the entity by id somewhere yeah
15:19 < Paprikachu_> well see, if you do that single threaded it works fine
15:19 < Paprikachu_> but if you have one thread per world, you'd get lots of locking and that's bad
15:19 < Grum> threading has no influence on that at all
15:19 <+Amaranth> Except that the ids always involve a player and you know what world they're in
15:19 <+Amaranth> So just search there
15:19 < Paprikachu_> ugh...
15:19 <+Amaranth> The only threading issue there is assigning the ids
15:20 < Grum> yes
15:20 < Grum> and you can buffer those until after you iterate on them
15:20 < Paprikachu_> if you use entity ids as array indices, this all breaks apart
15:20 < Grum> because there is not going to be a request for the data until you've actually processed them
15:20 < Grum> Paprikachu_: yes so you are doing that wrong
15:20 < Grum> they are not indices
15:20 < Paprikachu_> no, i'm doing that exactly write
15:20 < Grum> they are unique numbers for entities
15:20 <+Amaranth> That model would fall apart anyway because they grow forever, there is no reuse
15:20 < Paprikachu_> there is reuse
15:21 < Grum> we do not reuse?
15:21 < Paprikachu_> well you don't, but i do
15:21 <+Amaranth> I've seen the code, it's a static counter in Entity
15:21 <+Amaranth> So what you'll want to do is have your own entity id for your engine
15:21 < Grum> Paprikachu_: so you are now making your problem my problem? :)
15:21 <+Amaranth> And have one of your components be the one for the MC protocol
15:22 < Paprikachu_> Grum: i'm asking you to change it a tiny bit that would allow me to do efficient things while still working with your model
15:22 <+Amaranth> Two ids for every entity
15:22 < Grum> maybe when we go to an ecs we might recycled entity ids because its potentially easier to store
15:22 < Grum> Paprikachu_: i see no benefit at changing at all
15:22 < Paprikachu_> fast lookups
15:22 < Paprikachu_> if you reuse ids
15:22 < Grum> not at atll
15:22 <+Amaranth> Paprikachu_: I've already solved your problem :P
15:23 < Paprikachu_> Amaranth: so?
15:23 < Grum> you can totally break your idea and make it leak memory like no tomorrow
15:23 < Paprikachu_> Grum: err, no?
15:23 < Grum> just create a million entities and keep the last one alive
15:23 < Paprikachu_> that's not what it's optimized for
15:23 < Grum> or 50 billion entities :)
15:23 < jast> reminds me of the time I used a lookup structure to speed up a piece of code and it got 20% slower :}
15:23 <+Amaranth> Paprikachu_: This is an open world sandbox, that's what players will do
15:23 < Paprikachu_> also, if the server can handle a million entities, that would be pretty damn impressive
15:23 < Grum> yup
15:23 < Grum> why? because they can
15:24 < Grum> so you need a dynamically growing entity-mapping container
15:24 < Grum> and you cannot ever scale it down
15:24 < Paprikachu_> first of all, you can, if you really wanted to
15:24 <+Amaranth> Although the actual numbers will be more like 10000 which I'd be willing to just accept
15:24 < Grum> smells like a bad ida :)
15:24 < Paprikachu_> second, you will never have 1 million entities at the same time
15:24 < Paprikachu_> per world that is
15:24 < Grum> you wont?
15:24 < Grum> i can spawn a million particles if i like :p
15:24 < Grum> and then drop an item
15:25 <+Amaranth> Also it's not like you have to stick to static ids, if you detect you have a lot of dead space you could renumber them so you can resize
15:25 <+Amaranth> MC protocol can't handle that of course but we're already established you'll need a separate id for that
15:26 < Paprikachu_> meh
15:26 < Paprikachu_> i guess
15:26 < Paprikachu_> so many ids
15:27 < Grum> not really, just millions :p
15:27 < jast> if you have an int64 counter, you can generate a billion IDs per second and keep going for 584 years
15:27 < Paprikachu_> world ids, client ids, entity ids, world local entity ids, uuids
15:27 < jast> just saying
15:27 < Grum> block ids, blockstate ids, biome ids etc etc etc etc
15:27 < Grum> way more ids :D
15:27 < Paprikachu_> and those
15:27 < Paprikachu_> but i dont call them ids
15:27 < Paprikachu_> i call them types
15:27 < Paprikachu_> but whatever
15:28 < Paprikachu_> jast: except that sucks if you want to use them as array indices
15:28 < jast> it's fortunate, then, that arrays aren't the only data structure, isn't it?
15:29 < Grum> they have ids because they get talked about
15:30 < Grum> internally they have names as well
15:30 < jast> how avant-garde
15:33 < Paprikachu_> maps are slow
15:33 < Paprikachu_> compared to arrays
15:33 < Wuppie> aargh, why do i get netherbrick when sending bedrock
15:33 < Wuppie> :|
15:35 < Thinkofdeath> Wuppie: bit shift fail somewhere
15:35 < Thinkofdeath> bedrock: 111  netherbrick: 1110000
15:35 < Wuppie> hmm, i have to shift the block id?
15:38 < Wuppie> Ah, you mean The block id is equal to (id << 4) | data
15:38 < Wuppie> thiat Thinkofdeath?
15:39 < jast> maps are space-efficient, compared to arrays
15:39 < jast> you win some, you lose some
15:39 < jast> given sparse keys, that is. which is infeasible to avoid in many cases.
15:40 < Wuppie> Thinkofdeath, is the block still 1byte? 
15:40 < Paprikachu_> space efficiency is not the servers issue
15:40 < Wuppie> 1 byte*
15:40 < Paprikachu_> it's always better to have less cpu, because it uses so much
15:41 < jast> why not optimize where it actually makes a difference, and tackle the details later
15:41 < jast> have you done actual profiling?
15:41 < Paprikachu_> dont need to, my design relies on doing a lookup whenver you want to fetch data for some entity
15:41 < Paprikachu_> which means millions of lookups
15:42 < jast> because, spending three months rewriting the data access layers can turn out to make 2% of the difference spending two hours rewriting an algorithm takes
15:42 < Paprikachu_> code is not what slows, data access is
15:42 < jast> perhaps your design is crap
15:43 < Wuppie> Thinkofdeath, is a 
15:43 < jast> the last time lookup patterns made a difference for me was when I did alpha-beta search
15:43 < jast> where the number of lookups easily exceeded billions
15:44 < Wuppie> Thinkofdeath, is a block still 2 bytes? byte 1: block id. byte 2: meta
15:44 < Paprikachu_> yes, my design is crap, so crappy that iterating over entities has L1 cache access speed
15:44 < jast> and even then the larger part of CPU time was spent evaluating the nodes
15:45 < jast> (slightly below 90% of the CPU time required, that is)
15:45 < Xor_Boole> Paprikachu_ so, did you set your code on fire yet?
15:45 < Paprikachu_> eh?
15:45 < Xor_Boole> you know, you were really mad yesterday and facedesking hard
15:46 < Xor_Boole> the natural thing to do is to burn something/someone
15:46 < Paprikachu_> i don't think you know what i'm like when i'm mad :)
15:46 < Xor_Boole> hmm, I'll guess it's like Thinkofdeath 
15:46 < Wuppie> like Xor_Boole , he burned grum's carpet
15:47 < Xor_Boole> Wuppie dude asked for it
15:47 < Wuppie> i guess so
15:47 < jast> so you use a global array for all entities?
15:47 < Paprikachu_> i have my own data structure and i use one per world
15:48 < Paprikachu_> but it's array based, yes
15:48 < Paprikachu_> and there currently is no notion of an entity
15:48 < Paprikachu_> entity data is spread across multiple maps
15:48 < Paprikachu_> it's grouped for specific subsystems
15:48 < jast> I thought maps were too slow?
15:49 < Paprikachu_> maps = array maps = my data structure
15:49 < Thinkofdeath> Wuppie: sorry, was away for a sec. Which packet?
15:49 < Wuppie> Chunk Data
15:49 < jast> what's that... an array of maps? a map of arrays?
15:49 < Wuppie> http://wiki.vg/Protocol#Chunk_Data
15:50 < Thinkofdeath> its unsigned little endian shorts, (id << 4) | data 
15:50 < Thinkofdeath> like it says in the 1.8 changes section
15:50 < Wuppie> then http://wiki.vg/SMP_Map_Format
15:50 < Wuppie> has to be updated
15:50 < Wuppie> :P
15:50 < Thinkofdeath> yeah I got lazy
15:50 < Paprikachu_> jast: 2 arrays actually
15:50 < Wuppie> haha ok :P
15:50 < Paprikachu_> one for bits that contain wether an entry is present, the other for values
15:51 < Wuppie> it is weird, why is that one Little endian, and the rest of the protocol big endian?
15:51 < jast> oh, so an array with a free bitmask?
15:51 < Paprikachu_> uh?
15:51 < Wuppie> Thinkofdeath, data is the meta data?
15:51 < Thinkofdeath> Wuppie: because they manually slice up the short (well char is what they use) instead of using the writeType methods
15:51 < Thinkofdeath> Wuppie: yes
15:52 < jast> you have one bit for each array member to know whether it's occupied?
15:52 < Wuppie> Thinkofdeath,  ok :) ill guess that is what ill do then
15:52 < Thinkofdeath> https://github.com/thinkofdeath/mc-autodocs/blob/master/protocol/play/PacketChunkData.java#L79-L91
15:52 < Paprikachu_> jast: correct
15:52 < jast> doesn't that make it somewhat inefficient to find the first empty cell?
15:52 < jast> I dunno, sounds like a case for a freelist
15:53 < Paprikachu_> i don't search for cells, the id generator has a free list
15:53 < Thinkofdeath> I should really update that with the cleaned up fernflower
15:53 < jast> then what do the bits do?
15:53 < Paprikachu_> ids are managed externally
15:53 < Paprikachu_> jast: it doesnt remember all ids
15:53 < Paprikachu_> though i guess that would be a worthwhile optimization
15:54 < Paprikachu_> thanks for giving me that idea :P
15:54 < jast> the classic freelist approach is to put a pointer to the next free cell in each array cell, and a pointer to the first free cell somewhere else
15:54 < Paprikachu_> actually nvm
15:54 < Paprikachu_> it doesnt work
15:55 < Paprikachu_> jast: the id generator just keeps an array of free ids
15:55 < jast> works wonders for any array with cells of at least sizeof (void*)
15:55 < jast> isn't it kind of inefficient having to maintain that array?
15:55 < Paprikachu_> not really
15:55 < Paprikachu_> i always remove ids from the back
15:56 < jast> I mean, you have an overhead of max_ids * sizeof (int) here
15:56 < jast> or even int64
15:56 < Paprikachu_> huh?
15:56 < Paprikachu_> the id generator has no "gap array"
15:56 < jast> well, unless you realloc the main array every time there's no free ID left
15:56 < Paprikachu_> it's regular array, similar to a stack
15:57 < Paprikachu_> when an id is freed, it gets pushed to the end and when a new id is needed i pop it from the bac
15:57 < Wuppie> Thinkofdeath, i get bedrock now :) with 1 row of air between each time :S and my skylight isn't there
15:57 < jast> and you start out with $all free IDs
15:57 < Paprikachu_> no, i dont just put all of them into an array
15:57 < Thinkofdeath> Wuppie: off by one error somewhere, I actually did the same thing :P
15:57 < Paprikachu_> i have a counter for the current max id
15:57 < Paprikachu_> and an array for the freed ids in that range
15:58 < jast> so, when you have a max id of 1 million, you have to maintain up to 999999 free IDs
15:58 < Paprikachu_> correct
15:59 < Paprikachu_> but that will never happen
15:59 < Paprikachu_> :)
15:59 < jast> I guess... for small servers
15:59 < Paprikachu_> for large servers as well.
16:00 < Paprikachu_> for that to happen, you have to have 1 million entitis at one point in time.
16:00 < Paprikachu_> i doubt my server will be able to handle that.
16:00 < jast> seems easy enough for players to make happen
16:00 < Wuppie> Thinkofdeath, where was the error for you?
16:00 < Paprikachu_> not if you put caps on it
16:00 < Paprikachu_> vanilla has such caps too
16:01 < Thinkofdeath> Wuppie: going along 4 bytes instead of 2 per a block in the output buffer
16:01 < Thinkofdeath> or something like that
16:01 < Wuppie> Thinkofdeath,  ah ok
16:12 < Wuppie> Thinkofdeath,  this is correct right? http://pastebin.com/QxgjzsAA
16:12 < Thinkofdeath> 'var blocks = new List<byte> ();' surely that should be ushort?
16:12 < Thinkofdeath> oh 
16:13 < Thinkofdeath> bitconverter I guess handles that
16:13 < Wuppie> yeah
16:13 < Thinkofdeath> and that code is for a single section? (16x16x16)
16:14 < Wuppie> column
16:14 < Thinkofdeath> actually even then its too small
16:14 < Thinkofdeath> 256 blocks isn't a full section or a chunk
16:16 < Wuppie> i guess you need to see the fullcode to understand it 
16:16 < Wuppie> haha
16:16 < Thinkofdeath> well duh
16:18 < Wuppie> Thinkofdeath,  i guess i found the problem
16:19 < Wuppie> with the new system a block is still 2 bytes right?
16:19 < Wuppie> as a unsigned short is 2 bytes?
16:19 < Thinkofdeath> yes
16:22 < Wuppie> Thinkofdeath, i now have 50% of the chunk xd
16:23 < Thinkofdeath> close enough, ship it!
16:23 < Wuppie> hahaha
16:26 < Wuppie> Thinkofdeath, well. i got it working, except for the lighting now xd
16:39 < Wuppie> Thinkofdeath, did the skylight stuff change too?
16:39 < SopaXorzTaker> hey, how to make the client accept my server
16:39 < Wuppie> SopaXorzTaker,  what do you mean sopa?
16:39 < SopaXorzTaker> can someone provide authenthication logs
16:39 < SopaXorzTaker> with online-mode=off
16:44 < Wuppie> SopaXorzTaker, what do you mean with 'make the client accept my server'?
16:44 < Xor_Boole> tfw greedy-matching highlight and people with "Xor" in their name are in the channel ;_;
16:44 < SopaXorzTaker> the client doesn't accept my packet
16:44 < SopaXorzTaker> without any error
16:44 < Wuppie> SopaXorzTaker, are you sending it correctly?
16:44 < Paprikachu_> use wireshark
16:44 < Wuppie> Progress :) http://prntscr.com/5v8gwn
16:44 < Paprikachu_> nice
16:44 < Wuppie> for some reason it doesn't seem to get the skylight
16:45 < Paprikachu_> can't you just set skylight to 15 for every block?
16:45 < Paprikachu_> to make the client calculate it
16:46 < Wuppie> That is what i thought i was doing
16:46 < Wuppie> :s
16:46 < Paprikachu_> well, for you too
16:46 < Paprikachu_> use wireshark :P
16:46 < Wuppie> haha xd
16:46 < Wuppie> wireshark, is it available for mac? 
16:46 < Wuppie> :P
16:46 < Paprikachu_> yup
16:46 < Wuppie> good xd
16:47 < Paprikachu_> tcp.port == yourport && tcp.len > 0
16:47 < Wuppie> it worked with the old system tho ;(
16:47 < Paprikachu_> that should be your filter
16:47 < Wuppie> ah, thnx :D
16:47 < Paprikachu_> capture on local interface
16:47 < Wuppie> i know
16:47 < Wuppie> used wireshark before
16:47 < Paprikachu_> :P
16:47 < Wuppie> :P
16:48 < Wuppie> are you dutch by any chance?
16:48 < Paprikachu_> you may want to remove errorneous packets tho
16:48 < Paprikachu_> that would by && !tcp.analysis.retransmition && !tcp.analysis.out_of_order
16:48 < Paprikachu_> *be
16:48 < Paprikachu_> nope, i'm austrian
16:49 < Wuppie> haha ok, because Paprika is a dutch word
16:49 < Wuppie> :P
16:49 < Paprikachu_> it's also german
16:49 < Wuppie> haha lol
16:49 < Wuppie> gaaaah
16:50 < Wuppie> wireshark requires X11
16:50 < Paprikachu_> oh yeah right
16:50 < Paprikachu_> i remember that
16:50 < Paprikachu_> X11 sucked on mac os
16:50 < Paprikachu_> so ugly
16:50 < dx> there's tshark
16:51 < Xor_Boole> dead
16:51 < Wuppie> i installed quartz but that fucked my mouse
16:51  * Xor_Boole hands dx a corpse
16:51 < dx> :(
16:51 < Wuppie> lol
16:51 < Xor_Boole> quartz is a pain
16:51 < Xor_Boole> I need it for a small number things though
16:51 < Wuppie> i know
16:51 < dx> oh i suck at skimming
16:51 < Xor_Boole> because fucking tshock won't run inside Terminal
16:52 < dx> i thought it was a headless server problem, not a "it looks silghtly ugly in my $5000 macbook pro"
16:52 < Bibl_> https://www.youtube.com/watch?v=tMgkt9jdjTU emotional
16:53 < Xor_Boole> dx 2000*
16:53 < Xor_Boole> sheesh, don't exagerate
16:53 < dx> heheh
16:53 < Wuppie> mweee, i need my skylight
17:03 < Wuppie> Got it working now
17:03 < Wuppie> :)
17:03 < Paprikachu_> what was the issue?
17:08 < Wuppie> i was using NibbleArrays for skylight and blocklight
17:08 < Wuppie> now im justing byte arrays
17:08 < Wuppie> http://prntscr.com/5v8rsu
17:08 < Wuppie> :)
17:50 < SopaXorzTaker> done
17:51 < SopaXorzTaker> my 'server' now makes the client wait for chunk
18:57 < Paprikachu> http://ideone.com/TFadYl
18:57 < Paprikachu> :)
18:57 < Paprikachu> needs more ids i think
19:00 < Xor_Boole> Paprikachu more cowbell, perhaps
19:00 < Paprikachu> i have yet to implement client ids
19:00 < Paprikachu> so thats gonna go into that event as well!
19:28 < gurun> what language is that supposed to be?
19:28 < gurun> c++?
19:31 < gurun> so, 200 users spamming eachother gives ~200*200 moves * 20/s = 800000 messages.
19:32 < Paprikachu> that is c++, correct
19:32 < gurun> each package is 40bytes => 32000000b
19:32 < Paprikachu> so?
19:32 < gurun> giving me sends of 256000000bits/s
19:32 < gurun> 256mbit/s roughly.
19:32 < gurun> is that "sane" ?
19:32 < gurun> ..for 200 users?
19:33 < Paprikachu> i dunno
19:33 < Paprikachu> wh
19:33 < Paprikachu> why
19:33 < gurun> it is a lot of data.. 
19:33 < Paprikachu> what does that have to do with me?
19:33 < gurun> just want to verify my "observations" and calculations
19:36 < gurun> Paprikachu, however, the part that has to do with you is that i don't see why 1000 users is a problem supporting in almost any server, as long as they aren't all at the same place.
19:36 < Paprikachu> i'm just gonna put a cap on the number of players you can see
19:37 < gurun> yeah, that is basically LOS, and that is not that far, is it?
19:37 < Paprikachu> ideally making it fair so the other player can't see you either
19:37 < Paprikachu> LOS?
19:37 < gurun> line of sight .. or sorry .. should perhaps say "field of view" with the depth included.
19:38 < Paprikachu> i wouldn't even go that far
19:38 < Paprikachu> just the chunks the player can see
19:38 < Paprikachu> no matter if they are in the fov
19:39 < gurun> well, that would be the simplest things since that calculation is already done for the chunking.
19:39 < Paprikachu> yeah
19:40 < gurun> considering that type of culling. I don't think 10k is even a problem
19:40 < Paprikachu> i do think it is
19:40 < Paprikachu> consider how much more AI needs to be simulated if those players are spread out
19:41 < gurun> the biggest limitation i keep hitting, is bandwith after all. So that is why i just want someone to sanity-check the numbers so I haven't done anything really stupid.
19:41 < gurun> (like i did earlier, sending duplicate packages)
19:47 < rom1504> seems unlikely the bottleneck is bandwidth
19:49 < rom1504> usually ram is a bigger problem
19:51 < gurun> object pools. not an issue.
20:54 < Fenhl> who runs the wiki?
21:02 < Xor_Boole> used to be Thinkofdeath 
21:02 < Xor_Boole> idk now
21:02 < Thinkofdeath> Xor_Boole: no?
21:02 < Xor_Boole> sorry right
21:02 < Thinkofdeath> I've never run the wiki, I just updated it
21:02 < Xor_Boole> you were just an editor
21:02  * Xor_Boole slaps himself and goes back to pokemon
21:02 < Thinkofdeath> Fenhl: TkTech 
21:04 < Fenhl> TkTech: would it be possible to allow custom user CSS?
21:06 < Fenhl> TkTech: you would just need to add $wgAllowUserCss = true; to the LocalSettings.php
21:10 < dx> Fenhl: stylish / greasemonkey?
21:11 < dx> always easier than asking the admins of the sites you want to customize
21:13 < Fenhl> dx: I do that, I just want to have a thing that disappears when I'm logged in
21:16 < Fenhl> there's also some other things I'm missing
21:18 < Fenhl> for example, it would be nice if the ParserFunctions extension could be activated, along with its string function functionality https://www.mediawiki.org/wiki/Extension:ParserFunctions
21:18 < Fenhl> that would allow me to write a template to make editing the Protocol article a lot easier
21:47 < TkTech> Fenhl: I don't know what you're talking about, user css is enabled and the ParserFunctions extension is installed :3
21:52 < Fenhl> wait that
21:52 < Fenhl> *what
21:53 < Fenhl> ooh you updated it, thanks :3
21:53 < TkTech> Doing my best to make you think you're crazy :)
21:56 < Fenhl> TkTech: could you please also add $wgPFEnableStringFunctions = true; ? I need this for the Packet template rewrite
21:57 < Fenhl> this enables the functions listed at https://www.mediawiki.org/wiki/Extension:StringFunctions#Functions
22:01 < TkTech> Fenhl: Unfortunately no, if you follow the discussion on the bug tracker it is extremely slow and opens up potential security holes.
22:01 < TkTech> It was rejected from use on any mediawiki project
22:02 < Fenhl> hm alright, the template gets some additional parameters then
22:02 < Paprikachu> http://ideone.com/uVwUPJ
22:02 < Paprikachu> i need more ids!
22:04 < Grum> doesn't even compile!
22:04 < Paprikachu> ):
22:06 < Fenhl> yeah, why do you ise ideone.com for these snippets?
22:06 < Fenhl> you could use something like hastebin instead
22:08 < Grum> gist!
22:08 < Grum> gist > *
22:08 < Paprikachu> because i use ideone by default
22:08 < Paprikachu> it's in my history :P
22:58 < Fenhl> is http://wiki.vg/index.php?title=Template:Packet&action=edit a blank page for anyone else?
22:59 < dx> nope, can see contents
22:59 < dx> <includeonly>{{#ifeq:{{{head|0}}}|1| blah blah
23:00  * Xor_Boole cringes at mediawiki parkup
23:00 < Fenhl> hm weird
23:02 < gurun> Question about speed of updates: What says your experience, how long between updates of movement would a player accept? 100ms? 150?
23:12 <+md_5> 50ms
23:27 < gurun> it's very difficult to keep, even at 200 users
23:35 <+md_5> but not all 200 users need all 200 users updates
23:42 < gurun> nah, it's a worst case scenario of course. But I'm thinking that if i can do 400, i can deal with anything.
23:42 < gurun> but now, struggle with 200. It varies around 50ms.
23:43 < gurun> but i actually did a test, raw. Allocating the buffers hardcoded is even a problem to do in C#.
23:45 < gurun> doing 60-160 hardly affect the tick-time. It of course grows exponentially
--- Day changed jeu. janv. 22 2015
00:15 < Fenhl> TkTech: I get a blank page when trying to edit Template:Packet, and it happens on any device, and only when I'm logged in. Any ideas?
00:30 < Wuppie> What packet do i have to send when a player joins?
00:31 < Wuppie> I guess just Join Game?
00:38 < jython234> Wuppie: Add Player Packet?
01:20 < Fenhl> hm. I can't see the edit preview on [[Protocol]] anymore either
04:36 < Fenhl> in http://wiki.vg/Protocol#Spawn_Player, what does packed/packet byte mean?
04:37 <+SpaceManiac> 'packet byte' is probably a typo
04:40 < Fenhl> SpaceManiac: yeah but what is “Player rotation as a packed byte”?
04:40 <+SpaceManiac> if you have an angle in degrees, the byte is (angle * 256 / 360)
04:40 < Fenhl> oh so angle as a fraction of tau
04:41 < Fenhl> basically
04:55 < Fenhl> this method of encoding angles appears to occur more often, maybe it should be added to [[Data Types]]
06:20 < Fenhl> are the angles in Entity Look and Entity Look And Relative Move relative?
06:21 < Fenhl> and what about Entity Teleport?
18:58 <+SpaceManiac> Fenhl: all absolute
19:11 < Xor_Boole> sigh, why does the vanilla client relog you automatically on startup yet requires you to reenter the password if you want to relod without closing it?
19:11 < Xor_Boole> this seems like inconsistent behavior, one of the is a bug I'd guess
19:12 < Xor_Boole> s/client/launcher
19:15 < Grum> because to 'relog without closing' means you hit 'logout'
19:16 < Grum> or humz i do not have to put in my password when i hit Switch User -> Play
19:18 < Xor_Boole> Grum exactly, it's annoying when my session expires
19:19 < Xor_Boole> in any case, the behavior is inconsistent; quitting the launcher should require a password to be reentered if you can't relog without entering while in the launcher
19:20 < Xor_Boole> oh, related: start packaging the client with oracle's tool, not apple's shitty outdated one. I had to rebuild my client so I could use java 8
19:22 < Xor_Boole> Grum this: http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/packagingAppsForMac.html
19:22 < Xor_Boole> the current app bundle locks you into apple's crap java distro
19:22 <+SpaceManiac> the launcher gives you the option to use a different JRE for the actual game
19:23 < Xor_Boole> SpaceManiac since when?
19:23  * Xor_Boole checks
19:23 < Xor_Boole> hue, so it does
19:23 < Xor_Boole> *shruggles*
19:34 < Grum> and we're not going to change the packaging eventhough it is highly broken right now
19:34 < Grum> we'll provide a native part like we do on windows 'soon'
19:34 < Xor_Boole> ok that's better
19:35 < Xor_Boole> hooray breaking protocol changes
19:35  * Xor_Boole stabs the protocol a little
19:35 < Grum> ?
19:36 < Fenhl> speaking of which, I should finish my overhaul of [[Protocol]]
19:38 < Xor_Boole> Grum fixing a mod, nothing related to you
19:38 < Grum> but ALL MODS are MINE!
19:40 < Xor_Boole> Grum shoo
19:40 < Xor_Boole> s/MINE/mojang's
19:40 < Grum> no mine!
19:40  * Xor_Boole stuffs a wet cloth in Grum's face
19:41 < Xor_Boole> shhhh
19:41 < Xor_Boole> good night sweet prince
19:41 < Xor_Boole> shhhhhh
19:41 < Grum> it was just wet
19:41 < Grum> mm tastes like sweat
20:00 < Fenhl> hmm I wonder what Entity Status 0 and 1 are
20:27 < Paprikachu> so.. what
20:27 < Paprikachu> ooops
20:27 < Paprikachu> what's the representation of map chunk bulk
20:28 < Paprikachu> http://wiki.vg/Protocol#Map_Chunk_Bulk and http://wiki.vg/SMP_Map_Format tell me different things
20:35 < Fenhl> Paprikachu: the Data field is just the Data part described on [[SMP Map Format]]
20:35 < Paprikachu> mhh
20:35 < Fenhl> that will be clearer in my rewrite
20:36 < Paprikachu> so essentially
20:37 < Paprikachu> {skylight-flag, column-count, meta{x, y, bitmap}[count], data{blocks, blocklight, skylight}[count]}
20:37 < Paprikachu> or did i forget anything
20:52 <+SpaceManiac> Paprikachu: data{} will sometimes have biomes at the end
20:52 < Paprikachu> hm ok
20:53 < Wuppie> Xor_Boole it's a miracle you didn't use gasoline on that cloth
20:54  * Xor_Boole sets Wuppie on fire
20:54 <+SpaceManiac> in non-bulk, you can tell whether biomes will be included by the 'continuous' flag; in bulk chunks it's assumed to be present
20:54  * Wuppie burns 
20:54  * Wuppie shoots Xor_Boole with his uzi
20:55 < Bibl> do you think these entities should be classified as tile entities? http://i.imgur.com/st6cX58.png
20:55 < Paprikachu> alright, thanks
20:55 < Paprikachu> what's the point of the chunk data packet tho?
20:56 < Paprikachu> no matter what, in every direction you move you have to load multiple chunks
20:56 <+SpaceManiac> it *can* be used to perform updates of a single chunk or portions of a single chunk that's already loaded
20:56 <+SpaceManiac> more compactly than multi-block change
20:56 < Paprikachu> mhh
20:56 <+SpaceManiac> Bibl: no for ender crystals, item frames, paintings, and primed tnt; yes for signs
20:56 < Paprikachu> what about nether/end, are biomes sent even there?
20:57 < Paprikachu> in bulk that is
20:57 < Bibl> SpaceManiac: what defines a tile entity?
20:57 <+SpaceManiac> biomes are still sent in bulk, but not in skylight
20:57 < Bibl> what other tile entities are there then?
20:57 < Paprikachu> that seems kinda pointless
20:57 < Paprikachu> it's just gonna be 256 times the same value, no?
20:58 <+SpaceManiac> usually, barring mods
20:58 <+SpaceManiac> Bibl: tile entities are things like chests, furnaces, mob spawners etc - essentially blocks that have NBT
20:58 < Bibl> ohhh
21:07 < Fenhl> essentially, tile entities have nothing to do with entities
21:07 < Fenhl> they just happen to have similar names
21:08 < Bibl> ^_^
21:38 < Paprikachu> how does the client deal with the chunk it is currently in being reloaded?
21:39 < Paprikachu> i thought about kind of emulating a world that is unlimited in 3 dimensions by updating all of the clients chunks when it gets low/high enough
21:41 <+SpaceManiac> Paprikachu: it handles it fine
21:41 < Paprikachu> this behaviour is probably going to feel terrible for players :D
21:45 < Paprikachu> tho i don't understand why minecraft doesn't support it in the first place
22:01 < Paprikachu> i could however write a client mod that has a plugin message for exactly that behaviour
22:19 < Fenhl> whew, reformatted the Player List Item packet table in my draft
22:23 < Fenhl> what does “previous integer value divided by 250” in http://wiki.vg/Protocol#Player_Abilities mean?
22:23 < Fenhl> that sounds like legacy info
22:23 <+SpaceManiac> it is legacy info, and probably doesn't belong there anymore
22:23 < MrARM> was wondering about that too
22:24 < MrARM> just ignored it huh
22:24 < Fenhl> alright
22:24  * Fenhl removes
23:29 < Bibl> Spawning object entity org.topdank.minenet.api.entity.object.item.ItemEntity@3bc41cc6
23:29 < Bibl> Extra data is 1
23:30 < Bibl> anyone know what that 1 is for? i cant find any documentation
--- Day changed ven. janv. 23 2015
00:01 <+SpaceManiac> Bibl: as I understand, the extra data signals the presence of the velocity fields, but I'd need to experiment to be sure of the effects
00:02 < Bibl> ok thanks
01:28 < Fenhl> the Reason field in http://wiki.vg/Protocol#Disconnect says it must be valid JSON. So is it actually Chat?
01:58 < Fenhl> what's the unit of Speed in http://wiki.vg/Protocol#World_Border ?
01:58 < Wuppie> Fenhl yes
01:59 < Wuppie> Fenhl for disconnect, you have to send chat format
02:01 < Fenhl> also what's the unit of Warning Time in the World Border packet
02:02 < Fenhl> Wuppie: ok, added that to the article
02:04 < Fenhl> and the time unit for the Title packet
02:05 < Fenhl> and what's the different between CLEAR and RESET
03:09 < Fenhl> what does serverbound packet 0x0A “Animation” do?
03:10 < Fenhl> sorry that I'm spamming all these questions, but the documentation is seriously lacking in some places
03:27 < Fenhl> and why is there a serverbound Confirm Transaction packet
03:50 <+SpaceManiac> Fenhl: speed -> IIRC it's the time remaining until the final radius is reached, so it graduall decrements, but I'm not 100%
03:50 <+SpaceManiac> title is ticks
03:51 <+SpaceManiac> CLEAR makes the title disappear, but if you run TIMES again the same title will appear; RESET erases the text
03:52 <+SpaceManiac> serverbound Animation is sent when the player's arm swings
03:53 <+SpaceManiac> noooo idea why the serverbound confirm transaction packet exists
03:55 <+SpaceManiac> I think it's sent as a response to the clientbound confirm transaction in some situations, but it's fuzzy
04:08 < Fenhl> SpaceManiac: world border speed is in real-time seconds, right?
04:09 <+SpaceManiac> My guess is ticks, but I'd need to check to be sure
04:10 < Fenhl> from my experiences with redstoning a blackbox for a UHC-style minigame, I'm pretty sure that it's not synced to server tick lag
04:10 < Fenhl> which is why ticks would seem like an odd unit
04:11 <+SpaceManiac> to be fair, *time of day* is measured in ticks and also client-side predicted
04:12 < Fenhl> sure, but the server syncs the sun back to game ticks, right?
04:12 <+SpaceManiac> so too might it for the world border
04:13 < Fenhl> again, I'm pretty sure it doesn't, but a definitive answer would still be nice
04:13 <+SpaceManiac> if I get a chance, I'll do some research
04:13 < Fenhl> SCIENCE
04:13 <+SpaceManiac> can always leave ???s on the wiki
04:13 < Fenhl> yeah that's what I'm doing
04:14 <+SpaceManiac> also, props for going the extra mile to tidy things up
04:14 <+SpaceManiac> I've been intending to for years but never found the time
04:14 < Fenhl> it's what I do
04:16 < Fenhl> I'd love to do more with templates, but the wiki seems to hiccup when the slightest bit of complexity is added to an article
04:16 < Fenhl> which not something I've encountered before. I still can't edit {{Packet}}
04:17 <+SpaceManiac> I seem to be able to edit (or at least get the edit page) fine, but previews are dead
04:17 < Fenhl> yeah, when I insert the template into an article, preview dies
04:18 <+SpaceManiac> TkTech: might want to investigate that ^
04:18 < Fenhl> which is why I'm leaving it out of [[Protocol]] for now
04:19 < Fenhl> the wiki is also running on an outdated MediaWiki, maybe it's a bug which is fixed in 1.24
04:27 < Fenhl> hm… the article says that food saturation “Seems to vary from 0.0 to 5.0 in integer increments”, but the Minecraft wiki lists the saturation of most food items as nonintegers http://minecraft.gamepedia.com/Food#Foods
04:44 < Fenhl> there we go. First bold edit since September
04:46 < Fenhl> now to write an intro section…
09:20 < dx> 05:13 < jeb_> Follow Friday @shoghicp! Our newest MC:PE developer :D #mcpe #ff
09:20 < dx> HAHA WHAT
09:20 < shoghicp> o/
09:20 < dx> should have seen that one coming
09:20 < dx> congrats
09:21 < shoghicp> :)
09:22 < shoghicp> now getting lots of things over twitter
09:22 < dx> how many followers before the tweet?
09:23 < shoghicp> 1800-1900
09:27 < Paprikachu|work> i should apply to mojang too, i'm sure my great ideas will make minecraft better
09:43 <+AndrewPH> shoghicp: are you gonna rewrite minecraft in php
09:43 < shoghicp> nope xD
09:43 < shoghicp> But I already used some PHP scripts to do things faster here :D
09:56 < SinZ> AndrewPH: atleast it wont be Java <3
09:56 < shoghicp> it's C++ ;D
10:00 < TkTech> Wait what
10:00 < TkTech> shoghicp: Nooooo, you've gone to work for The Man, you traitor!
10:01 < TkTech> shoghicp: But seriously, congrats!
10:02 < Paprikachu|work> so.. what's c++ at mojang like?
10:02 < Paprikachu|work> c++11? libraries? modern or old?
10:03 < dx> c++ that looks like php but compiled
10:03 < Paprikachu|work> heh
10:03 < Paprikachu|work> it's funny because gcc actually lets you start variable names with $
10:04 < dx> with the $ being part of the variable name, or some other token?
10:04 < Paprikachu|work> http://ideone.com/5vI8kb
10:04 < Paprikachu|work> par of the name
10:04 < Paprikachu|work> part
10:07 < Paprikachu|work> now, if you just used boost::any for every variable...
10:07 < shoghicp> TkTech: haha
10:49 < MrARM> MCPE C++? It's using C++11, doesn't use boost, only standard libraries, that's what I can tell from symbols
10:50 < MrARM> it's almost for sure not using using namespace std; too
10:51 < MrARM> from 3rd party libraries I think they only use raklib
11:14 < Paprikachu|work> MrARM: sounds pretty good
11:18 < Paprikachu|work> so how come mojang can do a rewrite for PE but not for PC