22:57 < shoghicp> PocketMine is mine ;D
22:57 < shoghicp> mine in... PHP!
22:57 < gurun> MiNET is mine, written in C#
22:57 < Paprikachu> well, you can prob forget it then
22:57 < shoghicp> and supports +70 players with while doing funny stuff
22:57 < Xor_Boole> I don't have a server but if I did it would be written in scala!
22:57  * Xor_Boole runs
22:58 < Paprikachu> i'm convinced that you need C or C++ if you want to support massive servers
22:58 < shoghicp> I'm not competing for player amount :)
22:58 < Xor_Boole> Paprikachu false, java will do if you're not an idiot
22:58 < shoghicp> but there is this: http://status.lbsg.net/
22:58 < Paprikachu> you want memory layout control
22:58 < gurun> i know i can easily deal with 6400 simulatinous players moving continously, as long as they don't move close eachother
22:58 < Paprikachu> something java doesnt give you
22:58 < Paprikachu> and dunno about c#
22:59 < Xor_Boole> Paprikachu like I said, if you're not an idiot
22:59 < Paprikachu> so arrays everywhere?
22:59 < Paprikachu> how convenient
22:59 < Xor_Boole> shhh
22:59 < gurun> "memory layout" .. LOL. Yes, you just initialize a big fuckung byte array, and you are all set.
22:59 < Paprikachu> that's not really what i meant
22:59  * Xor_Boole goes back to entering credit card numbers into his DS
22:59 < Paprikachu> but okay
22:59 < gurun> hehe
23:00 < gurun> yes, both Java and C# suffer hard from GC kicking in at random times.
23:00 < Paprikachu> but for best performance you absolutely need to have good caching behaviour
23:00 < Paprikachu> honestly, i'm not sure if the GC is the biggest issue
23:00 < Paprikachu> memory layout matters a lot
23:00 < gurun> in both Java and C# the answer does remain the same though: Object pools.
23:00 < Paprikachu> if you're using inheritance to represent objects, you have already lost
23:01 < Xor_Boole> > 2015
23:01 < Xor_Boole> > objects
23:01 < Xor_Boole> everyone knows you should only be using lists and monads
23:01 < Paprikachu> not sure what you'
23:01 < Paprikachu> re trying to say
23:01 < dx> changelog: disabled address space layout randomization for performace reasons
23:01 < Paprikachu> and i keep hitting enter on accident on this new keyboard
23:01 < Paprikachu> dx: funny
23:02 < Xor_Boole> "credit card cannot be used" what the fuck nintendo
23:02 < gurun> Xor_Boole, they have been hacked ..or you need to start working and making money again.. you choose.
23:02 < Xor_Boole> gurun wrong zipcode I bet
23:02 < Paprikachu> polymorphic containers are a huge performance issue
23:02 < Xor_Boole> I used my uni's zipcode by mistake I think
23:03 < Xor_Boole> sigh, here we go...
23:03 < gurun> Paprikachu, i think you had the right approach a couple of hours ago though. One both me and shoghicp follow i believe.
23:03 < gurun> "start simple and deal with it when time comes"
23:04 < Paprikachu> gurun: you cant change your design once you use inheritance everywhere
23:04 < gurun> yes you can
23:04 < Paprikachu> this is not about optimization actually, it's about choosing a design that doesn't use it
23:04 < Paprikachu> which is very simple
23:04 < gurun> you can do it the hard way (as does shoghicp) or you can generate the code as i do.
23:04 < shoghicp> gurun: using my code >:)
23:05 < Paprikachu> so you're not actually using inheritance for entities?
23:05 < shoghicp> and how is that going?
23:05 < gurun> shoghicp, you optimized your code beyond usability the last couple of months :-)
23:05 < Xor_Boole> what the fuck is this bullshit. I used this card three hours ago at subway
23:05 < Xor_Boole> fuck you nintendo
23:05 <+SpaceManiac> what about inheritence is presenting a problem, anyway? data layout, or virtual method calls?
23:05 < Paprikachu> both
23:05 < Xor_Boole> SpaceManiac someone doesn't know that those things are pretty optimized these days
23:05 < Paprikachu> and other things
23:06 < Paprikachu> for example the instruction cache
23:06 < Paprikachu> if you have a Container<Entity> where Entity is a polymorphic type
23:06 < Paprikachu> and you're iterating over it
23:06 < Paprikachu> worst case is, the type of no entities next to each other
23:06 < Paprikachu> is the same
23:06 < shoghicp> gurun: those are automatic optimizations, the source code on GitHub is clean
23:06 < Xor_Boole> Paprikachu have you benchmarked this in hotspot?
23:07 < Paprikachu> and you end up kicking out the methods of the instruction cache with every single entity you iterate over
23:07 < Paprikachu> easy solution to that is to sort by type, but that doesn't solve the other issues
23:07 < Paprikachu> indirections, non-linear access patterns
23:08 < Xor_Boole> ping Thinkofdeath somehow I feel you'll enjoy this ^
23:08 < Paprikachu> also, this is not something jvm can magically fix
23:08 < gurun> Paprikachu, i feel i need to put that to a test. Feel i need to create a couple of milion packets with different layout.
23:09 < Paprikachu> the design of the java language is fundamentally flawed in that regard
23:09 < Xor_Boole> java sucks, yes, but /have you benchmarked it/
23:09 < Paprikachu> many people have
23:09 < Xor_Boole> give me numbers
23:10 < Xor_Boole> I'll accept people telling me scala is slow as fuck because it is but java is in no way slow compared to similar C++ code, if you're not retarded
23:10 < Xor_Boole> hotspot has beaten c++ before
23:10 < Paprikachu> there's a whole design philosophy centered around making your data access fast for the cpu
23:10 < gurun> i do know that creating static stuff in java (like buffers) was extermely much faster. however, quickly overrun by the complexity of monitoring.
23:10 < Paprikachu> it's called data oriented design, i'm sure you will find a lot about it using google, including benchmarks
23:11 < Xor_Boole> sigh
23:11 < Paprikachu> the tl;dr of it is that linear data access patterns are *fast* and java simply doesn't allow you to do that, unless you're using arrays of primitive types
23:11 < Xor_Boole> at this point a lot of these optimizations don't win you much for what work it requires
23:12 < Paprikachu> that's what you're saying because you don't know how huge the difference is
23:12 < Xor_Boole> hotspot is many things but it is not stupid. the JIT compiler can optimize a lot of things away
23:12 < Paprikachu> no, it can't.
23:12 < Xor_Boole> show me the difference then
23:12 < Paprikachu> this is not optimizable by a jvm, as i already told you
23:12 < Xor_Boole> don't just tell me to google it, back it with facts
23:13 < gurun> Wasn't it microsoft that ported Quake from C++ to C# to prove how powerful .NET was...
23:13 < gurun> ..and they completely failed :-P
23:13 < Xor_Boole> I won't deny the CLR is powerful
23:13 < Paprikachu> http://mechanical-sympathy.blogspot.co.at/2012/08/memory-access-patterns-are-important.html
23:14 < Paprikachu> disclaimer: i havent read the article
23:14 < Paprikachu> but it uses java and looks good
23:14 < Paprikachu> the first test should already give you a clue
23:15 < Paprikachu> random heap walks are ~75x slower than linear walks
23:15 < Paprikachu> in this particular test
23:15 < Xor_Boole> touche, I'll bookmark it and run it myself later
23:15 < Paprikachu> :D
23:16 < Xor_Boole> ok, so I believe you. now, is the performance increase worth the work required to maintain it?
23:16 < Paprikachu> the maintenance cost in my design is not very huge
23:16 < Xor_Boole> there is a point of dimiinshing returns of optimization v maitainability
23:16 < Paprikachu> i would say it's pretty maintainable actually
23:16 < Xor_Boole> really? repo pls
23:17 < Paprikachu> but one thing i do realize is that designing a plugin api is going to be much harder
23:17 < Xor_Boole> I actually went to a very interesting C++ internals lecture yesterday
23:17 < Paprikachu> and sorry, my server is closed source
23:17 < Xor_Boole> k den, I'll have to take your word for it
23:18 < Xor_Boole> "maintainable" is incredibly subjective, so unless I see code I can't judge
23:18 < Paprikachu> let's just say i use a lot of linear data structures :)
23:18 < Xor_Boole> I'm a scala man myself, so I have a very high standard of extensibility
23:19 < Xor_Boole> C++ is nice, but it's butt-ugly and frankly a clusterfuck
23:19 < Paprikachu> agreed, but it's the best language so far
23:19 < Paprikachu> everything else is just worse in one way or another that isnt tolerable
23:19 < Xor_Boole> I wouldn't say it's the best language, but it's certainly the most reliable
23:19 < Xor_Boole> the syntax is not extensible enough
23:20 < Xor_Boole> so it loses there
23:20 <+SpaceManiac> have you looked at Rust?
23:20 < Paprikachu> that's on my todo list
23:20 < Xor_Boole> rust is ugly, fuck it
23:20 < Xor_Boole> so fucking ugly
23:20 < Paprikachu> but i will say that it looks very restrictive from what i've seen
23:20 < Paprikachu> and i'm not sure how that is gonna turn out
23:20 < Xor_Boole> it's like someone poured javascript on it
23:20 < Xor_Boole> s/it/scala
23:20 < gurun> Node.js
23:20 < gurun> :-)
23:20 < Xor_Boole> Paprikachu I heard it's proveably memory-safe
23:21 < Xor_Boole> I haven't looked at it too closely to pass verdict though, except it's uglier than yawkat in the morning
23:21 < Paprikachu> yeah, but i don't really care about that
23:21  * Xor_Boole grumbles something about neckbeards
23:21 < Xor_Boole> have you seen kotlin?
23:22 < Paprikachu> can i eat that?
23:22 < yawkat> Hey cats have lots of hair 
23:22 < Xor_Boole> it's like scala for sane people
23:22 < dx> Xor_Boole: rust was very ugly in some stages of development, but the current one looks decent imo
23:22  * Xor_Boole eats yawakt's catnip
23:22 < dx> still a matter of opinion of course but check it again if you didn't recently
23:22 < Xor_Boole> Paprikachu http://kotlinlang.org/
23:22 < Paprikachu> > targeting the JVM
23:22 < Paprikachu> nope thanks
23:22 < Paprikachu> :D
23:23 < Xor_Boole> wow such hate
23:23 < Xor_Boole> it does javascript too =p
23:23 < Paprikachu> as in "pick your poison"?
23:23 < Xor_Boole> Paprikachu ok, I'll agree on that
23:23 < Xor_Boole> hating on the JVM is a bad idea in a minecraft dev channel though =p
23:23  * Xor_Boole cuddles the jvm
23:24 < Paprikachu> java is minecrafts biggest blessing and issue at the same time
23:24 < Xor_Boole> that null safety doe http://kotlinlang.org/docs/reference/null-safety.html
23:24 < Xor_Boole> NPEs are compile time errors!
23:25 < Xor_Boole> the most amusing bit is that they call `?:` the elivis operator
23:25 < Xor_Boole> which I can never unsee
23:25 <+Amaranth> The thing about sorting entities is actually a common optimization in game engines for the reason Paprikachu mentioned
23:26 < Paprikachu> makes me wonder, does minecraft do that?
23:26 < gurun> Paprikachu, this is an intersting article backing up your arguments i believe: http://msdn.microsoft.com/en-us/magazine/cc163856.aspx
23:26 < Xor_Boole> Paprikachu doubt it
23:26 <+Amaranth> No
23:26 < Xor_Boole> > minecraft
23:26 < Xor_Boole> > optimized
23:26  * Xor_Boole runs
23:26 < Paprikachu> hm, what about bukkit/spigot?
23:26 < Xor_Boole> Paprikachu still nope
23:26 < Paprikachu> hm wow
23:26 < Xor_Boole> do we look crazy to you?
23:26 < Paprikachu> that's a pretty obvious optimization
23:26 < Paprikachu> could probably improve performance a *lot*
23:26 < Xor_Boole> Paprikachu wanna make a PR? <3
23:27 <+Amaranth> Actually you'd just use an ECS setup and the sorting for instruction cache is automatic because you iterate systems not entities
23:27 < Paprikachu> PR?
23:27 < Xor_Boole> PR.
23:27 <+Amaranth> So you run the physics system on every entity them move on to the AI system or whatever
23:27 < Paprikachu> whatever that is :D
23:28 < Paprikachu> gurun: it is closely related
23:28 < Paprikachu> but it only covers layout wihtin data types
23:29 <+Amaranth> Although you end up with conflicting things to optimize for since for data cache you'd want to do everything on a component by component basis
23:29 < Paprikachu> what really matters is how all objects together are laid out, not the individual ones
23:29 <+Amaranth> Paprikachu: Do you know what ECS is?
23:29 < Paprikachu> Amaranth: i fear not :(
23:29 < gurun> "When managing large chunks of data, sometimes an application simply needs a lot of memory"
23:30 <+SpaceManiac> if you wanted to get fancy you could pack the components down so that you end up with big arrays of each component type
23:30 <+Amaranth> Oh.
23:30 <+Amaranth> SpaceManiac: Yeah, that's called an array in C++ ;)
23:30 <+Amaranth> (or Rust or C or whatever)
23:30 < Paprikachu> value types are important for performance
23:30 <+SpaceManiac> yes, but I mean as distinct from having them interwoven
23:31 <+Amaranth> I mean, in Java you'd have an actual byte array and use a static class to pull and interpret data from it
23:31 <+Amaranth> SpaceManiac: Oh yeah, that's how ECS works
23:31 < Paprikachu> Amaranth: to me that doesn't really count though
23:31 < Paprikachu> because it's so inconvenient
23:31 < Xor_Boole> turns out ovh blocked my card. that
23:31 < Xor_Boole> that
23:31 < Xor_Boole> that
23:31 < Xor_Boole> ffs
23:31 < Xor_Boole> that's amusing
23:31 < Xor_Boole> fucking bank decided not to tell me
23:32 <+Amaranth> Entity is an identifier, components go in a per-component array indexed by the entity, systems automatically apply to entities that have the components they require
23:32 <+Amaranth> More or less, you might end up with hashmaps for components or whatever depending on your design constraints
23:32 < Paprikachu> i use something similar to that
23:32 < Paprikachu> except i don't need hashing, i got something better :)
23:33 <+Amaranth> If you aggressively reuse entity ids you can easily use flat arrays
23:33 < Paprikachu> ^ that
23:33 <+Amaranth> It gets more complicated in Rust since you don't have nulls
23:33 < Paprikachu> i implemented a custom container for that
23:34 <+Amaranth> So you'd have arrays of Option<ComponentType>
23:34 < Xor_Boole> fuck you nintendo, accept my fucking credit card
23:34 < Paprikachu> Option<ComponentType> is suboptimal
23:34 < Xor_Boole> the bank told me it's unblocked, what is this shit
23:34 < Paprikachu> in fact extremely bad
23:34 <+Amaranth> Oh and you wouldn't want nulls here anyway since that implies an array of pointers which is bad
23:34 < Paprikachu> you're essentially using 8 bytes for 1 bit
23:34 <+Amaranth> So you'd need a zero value for your components
23:35 < Paprikachu> in rust maybe
23:35 <+SpaceManiac> okay, so you'd bit-vector it?
23:35 < Paprikachu> yup
23:35 <+Amaranth> You don't even know how Option<ComponentType> works or what I'm talking about
23:35 < Paprikachu> Amaranth: padding
23:35 <+Amaranth> And you need a sane zero value in C++ too
23:35 < Paprikachu> if you put option<componenttype> next to each other
23:35 < Paprikachu> you get padding
23:35 < Paprikachu> and no you dont
23:35 <+Amaranth> Because if you're storing pointing in your array you have no right to talk about data oriented design or worrying about cache
23:35 <+Amaranth> pointers*
23:36 < Paprikachu> you construct the values only if they are actually there
23:36 < Paprikachu> if not it's raw storage
23:36 <+Amaranth> And when the entity goes away?
23:36 < Paprikachu> you destroy the value and keep the storage
23:36 <+SpaceManiac> wouldn't even have to destroy the value if you were feeling edgy
23:36 < Paprikachu> yeah, true
23:37 <+Amaranth> I'm not even sure how you'd destroy the value
23:37 < Paprikachu> by explicitly calling the destructor
23:37 <+Amaranth> I'm talking about CompontentType[256] or some such thing
23:37 <+Amaranth> I can't type, getting tired
23:37 < Paprikachu> using ValueStorage = typename std::aligned_storage<sizeof(Value), alignof(Value)>::type;
23:37 < Paprikachu> std::unique_ptr<UInt8[]> present_;
23:37 < Paprikachu> std::unique_ptr<ValueStorage[]> values_;
23:38 < Paprikachu> that's essentially my array map
23:38 <+Amaranth> Anyway, Option has zero overhead if your type does not have a valid zero value, it uses the zero value as the marker
23:38 < Xor_Boole> why is C++ so ugly q _ q
23:38 < Paprikachu> 2 arrays, one for the bitmap, one for the values
23:38 <+SpaceManiac> how can you indicate that on arbitrary structs?
23:38 < gurun> sometimes . . but only sometimes, performance can be really easy to figure out too. Like after a couple of days of optimization and you realize that it is the "emulator" running that is taking all the memory, not the server.
23:39 <+Amaranth> SpaceManiac: http://doc.rust-lang.org/core/nonzero/struct.NonZero.html
23:39 < Paprikachu> values are explicitly constructed and destructed
23:39 <+Amaranth> Basically Option<NonZero<ComponentType>> :P
23:39 < Xor_Boole> Amaranth what is that even
23:39 <+SpaceManiac> hmm, throws you into unsafe territory, but I guess that's needed
23:40 < Xor_Boole> rust is so wierd
23:40 <+Amaranth> Actually that isn't how that works anymore, apparently you #[derive(NonZero)] on the struct definition
23:40 < Xor_Boole> is there an intellij plugin for it?
23:40 < Paprikachu> yes, getting it right took a lot of work
23:40 < Paprikachu> but it's worth it
23:40 <+Amaranth> SpaceManiac: It's not memory unsafe but if you misuse it you could get a logic error
23:40 < Xor_Boole> haskell is still better
23:40 < Paprikachu> haskell for everything
23:40 < Xor_Boole> #functionalmasterrace
23:41 < Xor_Boole> I'm busy at work converting my friends to the Functional Side
23:41 <+Amaranth> SpaceManiac: It's also automatic for pointers so Option<Box<Anything> compiles down to a pointer and null checking just like safe C would
23:41 <+SpaceManiac> right
23:41 < Thinkofdeath> My browser doesn't seem to like the rust docs :/ http://i.imgur.com/7WYR7kJ.png
23:41 < Xor_Boole> > safe > c
23:41 <+Amaranth> Haskell is not a systems language, GC alone ruins that
23:41 < Xor_Boole> Thinkofdeath it's because it's illegal in the UK
23:41  * Xor_Boole runs
23:42 <+Amaranth> Haskell is also proof that the Sufficiently Smart Compiler can go too far
23:42 < Xor_Boole> Amaranth have you seen scala?
23:42 < Xor_Boole> scalac*
23:42 < Xor_Boole> I think you don't want to see scalac. scalac will deprive you of your sanity
23:42 <+Amaranth> Shit in Haskell can get 100x slower when you change one small thing because suddenly it can't lazily evaluate it or whatever
23:42 < Xor_Boole> (as if working on bukkit hasn't already made you insane)
23:43 < Paprikachu> what's the state of bukkit btw
23:43 < Xor_Boole> quite fine
23:43 < Paprikachu> has it been discontinued
23:43 < Xor_Boole> now that Spigot maintains it
23:43 < Paprikachu> i remember there was something
23:43 < Xor_Boole> yeah some asshat tried to blow it up, but we have a workaround
23:44 < Xor_Boole> thanks to Thinkofdeath being fucking insane and having nothing better to do
23:44 < Xor_Boole> Paprikachu actually, I made a rather fun PR recently that replaces the old plugin description system
23:45 < Xor_Boole> Paprikachu greatest think I've done for bukkit in a while https://hub.spigotmc.org/stash/users/xor/repos/bukkit/commits/7e7e1d8140519d37d1e398521c4dc6884bb8d115
23:48 < Xor_Boole> Amaranth actually, did I ever show you this insanity I worked on? ^
23:50 < Xor_Boole> hmm, is freenode dying suddenly?
--- Day changed ven. janv. 16 2015
00:09 < Xor_Boole> dammit freenode
00:09  * Xor_Boole kicks the servers until the start wokring
14:49 < ChaosGamerist> Hey
14:50 < Weloxux> g´day
15:01 < ChaosGamerist> I need a little bit of help :)
15:01 < ChaosGamerist> I am coding with java for a while now
15:01 < ChaosGamerist> And now I want to code an android chat client for minecraft
15:01 < ChaosGamerist> Like MCChat or MineChat
15:02 < ChaosGamerist> But I have completely no idea where to start
15:03 < ChaosGamerist> Is there someone, who can help me?
15:04 < ChaosGamerist> SopaXorzTaker?
15:16 < MrARM> start here: wiki.vg
15:17 < MrARM> well, you most likely want to start here: http://wiki.vg/Server_List_Ping to get the idea
15:27 < ChaosGamerist> How do I send a packet?
15:28 < ChaosGamerist> Ah, I found it
15:35 < SopaXorzTaker> me
15:35 < SopaXorzTaker> ChaosGamerist, 
15:35 < SopaXorzTaker> ah
15:39 < ChaosGamerist> So I open a socket to the server?
15:39 < Weloxux> sounds like a good idea
15:40 < ChaosGamerist> Hmm, it gives me a ConnectException, Connection refused
15:46 < ChaosGamerist> Ah, now it works, but it says invalid packet ID, 0x00 is right, isn't it?
15:50 < ChaosGamerist> MrARM :)
15:51 < SopaXorzTaker> ChaosGamerist, explain
15:51 < SopaXorzTaker> 1. What version of minecraft you're writing server for.
15:51 < SopaXorzTaker> 2. In what programming language (:D)
15:52 < ChaosGamerist> Ah, I think that's the problem :D
15:52 < ChaosGamerist> 1.8
15:52 < SopaXorzTaker> show us your code
15:52 < SopaXorzTaker> pastebin
15:52 < ChaosGamerist> What about BungeeCord?
15:52 < ChaosGamerist> http://pastebin.com/kNzTvtmb
15:53 < SopaXorzTaker> what?
15:54 < SopaXorzTaker>                 Socket socket = new Socket("mc.secretcraft.de", 25565);
15:54 < SopaXorzTaker>                 main.setAddress(new InetSocketAddress("mc.secretcraft.de", 25565));
15:54 < SopaXorzTaker> ah
15:54 < ChaosGamerist> That's the server IP
15:55 < SopaXorzTaker> no, no
15:55 < SopaXorzTaker> understood
15:55 < MrARM> that's not how you send packets in the code 
15:55 < MrARM> also, handshake id is 0
15:56 < ChaosGamerist> It's through a DataOutputStream, isn't it?
15:57 < MrARM> Hmm? 
15:57 < ChaosGamerist> DataOutputStream handshake = new DataOutputStream(b); 		handshake.writeByte(0x00); // packet id for handshake
15:59 < ChaosGamerist> Just doing fetchData() would do it, wouldn't it?
16:01 < ChaosGamerist> MrARM + SopaXorzTaker ; jey, it worked
16:01 < ChaosGamerist> But it doesn't with 1.8 servers
16:05 < barneygale> ChaosGamerist, what does your server do?
16:05 < ChaosGamerist> barneygale, what do you mean?
16:05 < barneygale> you're writing a minecraft server? or client?
16:06 < ChaosGamerist> Client
16:06 < ChaosGamerist> Just a little client for chatting
16:07 < barneygale> you will need decent routines for packing data and packets
16:07 < barneygale> you won't get very far manually writing bytes
16:07 < ChaosGamerist> How I can learn them?
16:08 < barneygale> Read the wiki carefully. You'll need methods like "write a varint", "read a string", etc. You'll also need to support encryption and compression
16:09 < barneygale> There's a reasonable amount of example code for you - check out Glowstone, CraftNet, etc
16:17 < ChaosGamerist> Is there another source I can learn from?
16:23 < MrARM> Hmm, I can’t seem to be able to do chunk decoding
16:23 < MrARM> it works for first three chunks
16:23 < MrARM> but the next two are filled with 0s
16:23 < MrARM> anyone had same issue?
16:38 < ChaosGamerist> MrARM?
16:41 < MrARM> everything is clear on wiki
16:42 < ChaosGamerist> But I don't really understand it :/
16:50 < Wuppie> Respect for the people who made DragoNet! It is awesome!
16:53 < Wuppie> looking forward to see more of the project
16:56 < barneygale> ChaosGamerist, might as well recommend my library: http://github.com/barneygale/quarry
16:56 < barneygale> Specifically check out quarry.net.protocol and quarry.util.buffer
16:57 < ChaosGamerist> But yours is written in Phyton...
16:57 < barneygale> so?
16:57 < barneygale> Glowstone is Java if all you can read is Java
17:23 < ChaosGamerist> barneygale, did you ever code an android application?
17:23 < barneygale> no
17:23 < ChaosGamerist> Hmm, on Android it says error: remoteAddr = null
17:24 < barneygale> ok
17:24 < barneygale> this isn't really the channel for help with general android dev
17:24 < ChaosGamerist> Yea I know
18:10 < MrARM> anyone can have a look? http://pastebin.com/FGR07KhL
18:20  * Weloxux scratches chin
18:20 < Weloxux> looks like code to me
18:21  * Weloxux moves pipe around his mouth
18:21 < Weloxux> And it seems to bear a striking similarity to Java
18:35 < ChaosGamerist> Are there new Packet IDs for 1.8?
18:39 < ChaosGamerist> Because on one server it works, and on another is says Invalid Packet ID
18:40 < ChaosGamerist> You know that, barneygale?
18:41 < barneygale> Yes, the protocol changed between 1.7 and 1.8
18:41 < ChaosGamerist> But it works on a BungeeCord 1.8 server...
18:41 < barneygale> What works?
18:41 < ChaosGamerist> I am just getting the player count and version
18:42 < barneygale> via a status req?
18:42 < ChaosGamerist> Yea
18:43 < barneygale> AFAIK there were no changes in those packets between 1.7 and 1.8
18:43 < barneygale> Show your code
18:45 < ChaosGamerist> MinecraftConnection.java: http://pastebin.com/q68PwcV2
18:45 < ChaosGamerist> LoginActivity: http://pastebin.com/8i5CGjD2
18:52 < dx> 14:46 < Dinnerbro> My idea for 1.9 is something I've wanted to add for years now, but never got the time. I'll be so happy if I pull this off successfully.
18:52 < dx> 14:49 < Dinnerbro> I don't want to spoil anything that isn't 100% going to happen absolutely guaranteed for reals, but I can however say that it will involve c
18:52 < dx> from twitter
18:52 < dx> minecraft confirmed to be rewritten in C for 1.9
18:53 < dx> (totally not twitter's length limit cutting a word)
18:53 < ChaosGamerist> Any idea barneygale?
18:54 < dx> ChaosGamerist: on what server does it fail?
18:55 < ChaosGamerist> dx: On pvp.craftedeu.de it works
18:55 < ChaosGamerist> dx: But on mc.secretcraft.de is doesn't
18:57 < barneygale> Can you be more specific about the invalid ID thing?
19:00 < ChaosGamerist> barneygale: Look at this method: http://pastebin.com/A8yCP9sV
19:00 < dx> you already pasted that..
19:01 < barneygale> You throw that "Invalid packetID" exception in two places, and don't include the received packet ID in the exception message
19:01 < Wuppie> Guys... Did i just read MC will be doing something with C? :O
19:01 < dx> oh it's not even flexible about the stuff it receives
19:02 < dx> Wuppie: no it was just the twitter character limit
19:02 < Wuppie> awh ;(
19:02 < barneygale> rewriting minecraft in C would be insane and take months
19:03 < Wuppie> Definetely true
19:03 < dx> also it would result in a shittier game
19:04 < dx> but nevermind that
19:04 < dx> it's been talked about enough
19:05 < dx> regarding ChaosGamerist's problem, uh, i'm guessing it's a plugin message packet
19:06 < dx> but printing the received packet id is way better than guessing
19:13 < ChaosGamerist> It gives Packet ID 0
19:13 < Wuppie> How do you guys seperate packages with the same packet id? like a Chat Message and ping?
19:13 < shoghicp> context :)
19:15 < Wuppie> Ah yeah, what i did atm was check the packet length. However that offcourse is a bad way of doin it
19:28 < dx> Wuppie: there are no packets with the same packet id within the same state
19:29 < Wuppie> dx: Guess i need to rewrite my packet handler haha
19:29 < Wuppie> dx: im writing the newbiest server ever anyways
19:30 < dx> 'chat message' is in the play state, 'ping' is in the status state
19:30 < dx> you just need to switch handlers when you switch state
19:30 < dx> (so, after the handshake packet)
19:32 < dx> ChaosGamerist: packet id 0 sounds valid to me http://wiki.vg/Protocol#Response
19:32 < ChaosGamerist> Yea, it works now :)
19:33 < dx> neat
19:34 < ChaosGamerist> Now I am going for authentication, login and chatting :D
19:37 < Paprikachu> authentication would be one of the last things i'd implement
19:37 < Paprikachu> not very important imo
19:38 < Wuppie> dx: Thnx for the suggestion, thats what i did now! :)
19:38 < dx> ChaosGamerist: uhhh you'll probably want to give your code some structure then
19:38 < ChaosGamerist> dx: Yes, I will :)
19:39 < ChaosGamerist> Why I am not having org.json.JSONObject?
19:39 < dx> wot
19:40 < Wuppie> My plan is to write a server now, which is really noobie, after that. As i know howto implement stuff then. Ill create a new version which will be organized and less newbie :D
19:40 < ChaosGamerist> Oh, thats in the Android SDK
19:41 < Paprikachu> has the minecraft dev team considered implementing authentication without encryption yet
19:42 < dx> whyyyyy
19:42 < dx> oh, performance
19:42 < dx> uhm
19:42 < Wuppie> Paprikachu: Why would you implement authentication without encryption? :O
19:42 < dx> no comment
19:42 < Paprikachu> performance
19:43 < Wuppie> Hmm. 
19:43 < Paprikachu> the data isnt really worth protecting
19:43 <+jnoah> 4a/w dev
19:43 < shoghicp> but MitM
19:43 < dx> i agree with jnoah
19:43 < Paprikachu> true, mitm could be a concern
19:43 < dx> mitm, session replay, etc
19:44 < Paprikachu> well, i'm not a crypto expert
19:44 < Paprikachu> but can't replay attacks be executed even with encrypted data?
19:44 < shoghicp> not in this case
19:44 < dx> if you get the crypto wrong, of course
19:45 < shoghicp> the key is chosen at random, sent encrypted via public-key crypto verified against Mojang severs
19:45 < Paprikachu> hm yeah i guess
19:45 < Paprikachu> what about authentication without mojangs servers
19:46 < shoghicp> no crypto there
19:46 < Paprikachu> when login servers are down it's really annoying
19:46 < Paprikachu> i'm sure it could be done somehow
19:46 < shoghicp> but if enabled in that case, you would have to pin the fingerprint
19:46 < Paprikachu> server and client could store public keys of each other
19:47 < shoghicp> yep, auth via OpenPGP ;D
19:48 < Paprikachu> dunno what that is
19:48 < Paprikachu> isn't pgp used for email or something?
19:49 < shoghicp> it's just a standard, and a way to trust individuals via what other individuals say
19:49 < shoghicp> signing releases / files, for example
19:49 < shoghicp> sending encrypted mails
19:50 < shoghicp> or sending signed messages that cannot be spoofed
19:51 < Paprikachu> in any case, there needs to be a solution for when servers are down :\
19:51 < Paprikachu> i
19:52 < Paprikachu> i'm considering builting an external mechanism
19:57 < ChaosGamerist> Now how exactly is logging in working?
19:57 < ChaosGamerist> I'm having an accessToken and a clientToken now
20:05 < ChaosGamerist> dx?
20:05 < dx> beep boop computers
20:05 < dx> i have no idea
20:06 < ChaosGamerist> Someone who knows that?
20:06 < Wuppie> Not me, sadly. I'm only doing offline for now haha.
20:07 < Wuppie> i don't understand sending chunks tho....
20:14 < Wuppie> Did anyone see the Dragonet project? It is pretty cool :O
20:17 < Wuppie> <3 how they made it so you can play on a pc server with pc players, while on pocket edition
21:09 < ChaosGamerist> What's wrong about this?
21:09 < ChaosGamerist> http://pastebin.com/6axZFRRu
21:14 <+SpaceManiac> first, you write the sum of the lengths as an number, rather than encoded as a varint
21:14 <+SpaceManiac> second, the sum of the lengths doesn't include a bunch of stuff in the packet
21:16 <+SpaceManiac> third, you can probably re-use the byte[] you encode to get the length in the actual writing
21:19 < Wuppie> i already wrote him another method, that should work fine :P
21:35 < ChaosGamerist> And this? http://pastebin.com/rsKdCeMN
21:49 < Wuppie> u forgot the state xd. 
21:50 < Wuppie> we discussed this already tho
21:50 < ChaosGamerist> Oups
21:50 < ChaosGamerist> I added the state, but still nothing
23:42 < Wuppie> Set Slot packet not working for me for some reason... Bad packet id 47
23:44 < Wuppie> oh, i know why lol xD
23:44 < Wuppie> nvm
--- Day changed sam. janv. 17 2015
00:55 < Wuppie> anyone? if i want to send the player inventory i have to send the Set Slot packet right? 
00:56 < Wuppie> with Window ID 0, also for the quick bar?
00:56 < Wuppie> or Hot bar, just how you wanna call it
01:04 < Wuppie> anyone?
01:34 < Wuppie> Anyone knows why this happens? fieldSize is too long! Length is 2, but maximum is 1
01:34 < Wuppie> I'm sending the pacakge exactly as described on the wiki
02:55 < nickelpro> Hey everyone
06:33 < Paprikachu> does the 1.8.2 protocol version differ from 1.8?
06:34 <+SpaceManiac> assuming you mean .1, no
06:35 < Paprikachu> i mean the pre release
06:36 < Paprikachu> for some reason my status ping just won't work
06:37 < Paprikachu> i get the handshake, get a status ping request, send a status ping response and then the client stops sending and tries the old status protocol
06:37 < Paprikachu> i verified with wireshark that my packets are correct
06:38 < Paprikachu> http://i.imgur.com/34WRfXh.png
06:40 <+SpaceManiac> Still working for me
06:40 < Paprikachu> is my json incorrect? i just don't see it...
06:41 <+SpaceManiac> "protocol":"47" try :47 maybe?
06:41 < Paprikachu> oh shit
06:41 < Paprikachu> that could be it
06:41 <+SpaceManiac> other numbers also
06:42 < Paprikachu> wow
06:42 < Paprikachu> that was it
06:42 < Paprikachu> i feel stupid now
06:42 < Paprikachu> :|
06:42 < Paprikachu> thanks for the help though
09:32 < Player> Hello :)
09:32 < Player> I have a question about logging in to a server
09:33 < Player> I want to do an unencrypted and unauthenticated login
09:34 < Player> So I am sending a handshake packet with state 2 and get a 0 packet with size 35 back
09:35 < Player> But what now?
09:35 < Grum> the server is in offline mode?
09:36 < Player> Yes
09:36 < Grum> should just continue as normal then?
09:36 < Grum> what version are you running?
09:36 < Player> 1.8
09:36 < Player> I am still a newbie, what should I do after that?
09:37 < Paprikachu> skip encryption request/response
09:37 < Player> How do I skip that?
09:38 < Paprikachu> a client must do what the server asks it too
09:38 < Player> Yes
09:39 < Paprikachu> so if you get an encryption request, you need to do that auth wizardry
09:39 < Player> Paraphrase (with no authentication and no encryption): send a 0x02, get a 0xFD, send a 0xCD, get a 0x01, get a 0x06. Then you'll eventually get a 0x0D, and that's when the game really begins. ; like that?
09:40 < Paprikachu> the server will send login success directly if it is running in offline mode
09:40 < Player> And Login success is 0x02?
09:40 < Paprikachu> apparently
09:41 < Grum> keep in mind that protocol compression is there too
09:42 < Grum> which makes reading the packets 'from a certain moment' slightly hard :P
09:42 < Paprikachu> isn't the default threshold 256 though
09:42 < Player> But I get a 0x00 from the server
09:43 < Paprikachu> also, i have a question too
09:43 < Player> And that's disconnect, isn't it?
09:43 < Paprikachu> how are uuids from the login packet encoded as strings
09:43 < Paprikachu> in what format
09:43 < Paprikachu> (and why is it a string? :D)
09:44 < Grum> http://wiki.vg/Protocol <- doesn't describe?
09:44 < Paprikachu> oh here, spawn player
09:44 < Paprikachu> that should be it
09:45 < Player> But I'm not even getting login success
09:45 < Player> Oh I understand
09:45 < Paprikachu> but still, why are they sent as strings? in the "protocol types" section it says they are sent as 128 bytes
09:45 < Grum> i do not think they are sent as strings
09:46 < Paprikachu> mh
09:46 < Paprikachu> well i'm writing a server and the client is refusing my uuid
09:47 < Paprikachu> but maybe it's because i don't use the version byte correctly, i just generate them randomly
09:47 < Grum> yes, 'random' is not a 'good UUID'
09:47 < Grum> the UUID type-byte HAS to be in
09:47 < Paprikachu> i see
09:48 < Paprikachu> but apart from that byte, you can randomly generate them, right?
09:48 < Grum> you can generate a valid one
09:49 < Paprikachu> well, uuids are server-local, correct?
09:49 < Paprikachu> i'm not quite sure how all this uuid stuff works
09:49 < Grum> uuids is nothing special
09:49 < Grum> its just a 'unique id'
09:49 < Grum> but you have several differnt types 
09:50 < Paprikachu> is there a reason something similar to an entity id was not good enough?
09:50 < Grum> http://en.wikipedia.org/wiki/Universally_unique_identifier
09:50 < Grum> yes, we need something unique
09:50 < Grum> and non-guessable
09:50 < Paprikachu> hm, makes sense
09:50 < Player> Grum, I should get the login access, shouldn't I?
09:51 < Grum> No idea, read the packet you are getting back
09:51 < Grum> iirc '0x00' means: disconnect
09:51 < Grum> but I have no idea which packet has which number, we do not keep track of that in the code
09:51 < Player> But why I am getting that when trying to log in?
09:51 < Grum> probably because you are not doing what you are supposed to?
09:51 < Grum> read the packet, it should have a reason in it
09:51 < Paprikachu> you should get wireshark
09:52 < Paprikachu> and look at what you're actually sending/receiving
09:52 < Paprikachu> chances are you're not sending what you think you are
09:52 < Player> Do you want to take a look on my code?
09:53 < Grum> just print the raw bytes you are sending and recieving
09:53 < Grum> and make sure it is what you think it is
09:53 < Player> I am sending 0x00 with state 2
09:54 < Grum>  there is more in the initial packet not?
09:55 < Grum> i see, protocol version, hostname, port and intention
09:55 < Player> Yes, I have them
09:55 < Paprikachu> so about UUIDs
09:56 < Paprikachu> for offline mode v3 is used, which means i need a "namespace"?
09:56 < Player> I am getting read timed out with protocol 47, but with protocol 4 I get a 0x00 packet back
09:57 < Grum> read timeout?
09:57 < Grum> i think you are supposed to send more than a single packet to the server
09:57 < Grum> first your intention then the 'hello'
09:58 < Player> But why it's working with protocol version 4?
09:58 < Grum> i think it is not working?
09:58 < Player> I get a packet back, but not that one, that I wanted
09:58 < Grum> 0x00 should be the 'disconnect' packet from the server
09:59 < Grum> so it is probably telling you the protocol you select is not compatible
09:59 < Player> With protocol version 47 I just get a read timeout
09:59 < Grum> yes, because you are not sending the required information
09:59 < Grum> and you have very little time to do it
09:59 < Player> Ah ok
09:59 < Player> I understand
10:00 < Player> So I need to send Handshake, Login, Inventory, Compass and Chunks?
10:00 < Grum> whaa?
10:00 < Grum> I'm confused now, you were making a client not?
10:00 < Grum> why not look at what a normal client does?
10:00 < Grum> then replicate that?
10:00 < Player> Yes
10:01 < Player> Actually I just want to make a chat client
10:01 < Paprikachu> Grum: what is the namespace used for the uuid generator (offline mode)?
10:01 < Grum> Paprikachu: no idea
10:02 < Grum> look at what the server generates normally
10:02 < Grum> iirc we do not specify any namespace specifically
10:02 < Player> So what do I have to send after login?
10:02 < Paprikachu> does it even matter?
10:03 < Grum> Player: look at the wireshark information of a normal client
10:04 < Grum> http://wiki.vg/Protocol#Login
10:04 < Grum> There it says you are also supposed to send the 'Login' packet
10:05 < Player> But why I am not getting Login Success back?
10:05 < Player> I am doing that
10:05 < Grum> i guess you are sending it wrong?
10:05 < Paprikachu> -> wireshark
10:06 < Player> Do I have to send it two times? One time with state 1 and one time with state 2, or only with state 2?
10:08 < Grum> i do not really understand what the problem is
10:08 < Grum> you need to send two packets to the server
10:08 < Grum> one that says you want to login
10:08 < Grum> one with information it requires to login
10:09 < Grum> http://wiki.vg/Protocol#Login says:
10:09 < Grum> C->S : Handshake State=2
10:09 < Grum> C->S : Login Start
10:09 < Player> And which packet I use for the information?
10:10 < Grum> please look at the page :/
10:11 < Player> Ah okay
10:11 < Player> Now I understand
10:14 < Grum> from what I read you need to send the Login Start packet still
10:14 < Grum> i think it just contains your name
10:15 < Player> Yes I did that now
10:17 < Player> Internal Exception: io.netty.handler.codec.DecoderException: The received encoded string buffer length is longer than maximum allowed (101 > 64)
10:18 < Paprikachu> Grum: the uuid in login is actually send as a string
10:18 < Paprikachu> sent
10:19 < Player> So just as an UTF-8 String?
10:19 < Paprikachu> i still don't understand how to choose the namespace/name parameters for the uuid, but it works now
10:22 < Paprikachu> what's odd is that i'm using a v5 uuid and the client seems to be fine with it
10:22 < Player> Is that code right? http://pastebin.com/V2tHv5h1
10:22 < Grum> Paprikachu: the client has no business checking, the server has
10:22 < Player> Just wrong comments, I c&p'ed it
10:23 < Grum> that is not how you write packets
10:23 < Paprikachu> Grum: but it refused my random uuids :(
10:23 < Grum> ah wait, you do prefix them with the size
10:23 < Grum> Paprikachu: random != uuid
10:23 < Grum> uuid NEEDS to have a valid type in it
10:23 < Paprikachu> i used a boost::uuids::random_generator
10:23 < Paprikachu> which should set the type correctly
10:23 < Player> It's an example from the wiki
10:23 < Grum> Player: yeah
10:24 < Grum> but not sure if that writes the username correctly
10:24 < Grum> i doubt it
10:24 < Player> How should I write it?
10:26 < Grum> http://wiki.vg/Protocol#Data_types
10:28 < Grum> And further questions will just make me paste that site over and over again
10:28 < Grum> because it contains all you need :)
10:30 < Player> I am doing it like that
10:30 < Player> But now I am getting another error
10:31 < Player> IndexOutOfBoundsException: readerIndex(2) + length(49) exceeds writerIndex(16): UnpooledHeapByteBuf(ridx: 2, widx: 16, cap: 16)
10:31 < Paprikachu> have i mentioned wireshark yet?
10:31 < Grum> so you are not sending it right
10:33 < Player> I am send the name with the length prefixed as a VarInt
10:33 < Player> *sending
10:33 < Grum> and i guess you are sending the name wrong
10:33 < Grum> feel free to show how you send the string
10:34 < Player> How do I split the length from the name?
10:34 < Player> Is there something that I have to put in?
10:34 < Grum> ?
10:35 < Paprikachu> no, length and data are next to each other
10:35 < Grum> you need to get the size of the utf8 encoded bytes
10:35 < Grum> send that as varint, then send the utf8 encoded bytes
10:35 < Paprikachu> and length is varint encoded
10:35 < Paprikachu> speaking of varints, what was the reason to encode the length in the packet "header" as a varint?
10:36 < Grum> because its flexible?
10:37 < Paprikachu> why not a fixed length integer
10:37 < Player> YES
10:37 < Player> It works <
10:37 < Grum> because that is not flexible?
10:37 < Player> *<3
10:37 < Paprikachu> define flexible
10:37 < Grum> how big would you like the information to be you send as size?
10:37 < Grum> i prefer as small as possible
10:37 < Paprikachu> just put a 4 byte int in the header
10:37 < Paprikachu> or 3 byte
10:37 < Grum> or 2 ?
10:37 < Paprikachu> doesn't really matter
10:38 < Grum> or 1?
10:38 < Player> Should I stay logged in? But I get instantly kicked out
10:38 < Grum> now it does just that, 1-5 depending on the real size
10:38 < Grum> Player: http://wiki.vg/Protocol
10:38 < Paprikachu> varints are harder to parse
10:38 < Paprikachu> the savings of 1-3 bytes aren't really worth it imo when you're doing stuff like sending json
10:39 < Grum> except it saves on every single packet
10:39 < Grum> most packets are small enough, sending 3 bytes extra would be silly
10:39 < Paprikachu> the savings will be completely nullified by the overhead of the payload of other packets
10:39 < Grum> but restricting it to 1 byte doesn't work, 2 doesn't even, 3 goes to spending too much
10:40 < Grum> Paprikachu: i do not care that it 'seems strange' to have a flexible and space-saving system when the things send are nto actually that
10:40 < Paprikachu> and anyways, don't tcp pdus have a minimum length and will be padded anyways
10:40 < Grum> that is not the point, the point is to not be wasteful with all the new shit we make
10:40 < Grum> pdus?
10:40 < Paprikachu> PDUs
10:40 < Paprikachu> tcp packets
10:40 < Paprikachu> i'm pretty sure they do
10:41 < Grum> pdu?
10:41 < Paprikachu> prodocol data unit
10:41 < Paprikachu> a tcp packet
10:43 < Paprikachu> minimum ethernet frame size is 64 bytes
10:43 < Paprikachu> minimum tcp size is 20 and so is ipv4
10:44 < Paprikachu> ethernet header is about 16 bytes
10:44 < Paprikachu> depending on the definition of header
10:44 < Paprikachu> which leaves 8 bytes that are gonna be padded if not used
10:45 < Grum> there is really nothing you can say that will make me use 4 bytes
10:45 < Paprikachu> since a movement packet has more than that i guess that actually saves space
10:45 < Grum> and 4 bytes is not even the 'right number'
10:45 < Grum> we might need only 3
10:45 < Grum> but reading 3 is painful as well
10:46 < Paprikachu> not really, let's say you make the type fixed size 1 byte
10:46 < Paprikachu> one could just use bitshifts
10:46 < Grum> no?
10:46 < Grum> that limits us to 255 different packets
10:46 < Grum> for what reason? :/
10:46 < Paprikachu> well, do you need more?
10:47 < Grum> i might
10:47 < Paprikachu> the protocol uses how many? 100?
10:47 < Grum> do you need more than 256 blocks?
10:47 < Grum> or rather, do you need more than 256 unique faces for blocks?
10:47 < Paprikachu> eh?
10:48 < Grum> remember we once upon a time only had a 16x16 icon texture sheet?
10:48 < Grum> when i made the texture atlas we didnt need more than that
10:48 < Grum> so TOTALLY OVERKILL IN COMPLEXITY
10:48 < Grum> and then when you look now ...
10:48 < Grum> we get the flexibility to do what we do at a near constant cost
10:49 < Paprikachu> let's just assume you used 8 byte headers, 4 for size and 4 for type
10:49 < Paprikachu> would those 6 bytes really hurt?
10:49 < Grum> yes
10:49 < Paprikachu> why?
10:49 < Grum> because 'just making it 4 bytes' is inflexible
10:50 < Paprikachu> you're using int32's anyways
10:50 < Grum> arbitrary restrictions ftl
10:50 < Paprikachu> you just encode them as varints
10:50 < Grum> with the option of making them varwhatevertherfucklength
10:50 < Grum> because that is the trivial thing you can do when you have varints
10:50 < Grum> varlong? var128b?
10:51 < Grum> varmanylongasirequire ?
10:51 < Paprikachu> so when you're saying a 4 byte size might not be enough
10:51 < Paprikachu> you're essentially saying that you might want to send a packet more than 4gb in size
10:51 < Grum> i am saying it doesn't work the best in most situtations
10:51 < Paprikachu> 2gb because signed actually
10:52 < Paprikachu> similarly, with 2 byte packet types, you can use 32k packet types
10:52 < Paprikachu> that's only 4 bytes more than right now for those small packets
10:52 < Grum> 1 byte is not enough, 2 bytes is not enough
10:53 < Paprikachu> for types? 2 bytes are surely enough
10:53 < Grum> 3 bytes is on the edge of wasteful and a pain in the ass to read, 4 bytes is wasteful 
10:53 < Paprikachu> for sizes, 4 bytes will do
10:53 < Grum> and you've just wasted 4 bytes for small packets
10:53 < Paprikachu> yes, and?
10:53 < Grum> and limited the amount of packets we can have
10:53 < Grum> maybe we want to never reuse ids
10:54 < Paprikachu> are you going to define 32k packets in your life time?
10:54 < Grum> yes
10:54 < Grum> challenge accepted
10:54 < Paprikachu> :P
10:54 < Paprikachu> let's do the math here
10:54 < Paprikachu> if you make both fields 4 bytes
10:55 < Paprikachu> you're "wasting" 6 bytes per small packet
10:55 < Paprikachu> now, how many packets does a client send/receive per second?
10:55 < Grum> every single client sends 20 packets per second, 100 clients online means 2k packets per second of minimal incoming data
10:55 < Grum> now we have 12kb/s of traffic wasted just because you want to waste 6 bytes
10:56 < Paprikachu> so that's 12KB/s
10:56 < Grum> yes of the purest basicest data
10:56 < Paprikachu> who cares about 12 kb/s
10:56 < SinZ> to be fair, the vanilla client is very wasteful when it comes to those 20 packets per second
10:56 < Grum> the server sends FAR more
10:56 < Grum> it sends thousands of packets per second
10:56 < Paprikachu> yes
10:56 < Paprikachu> and if you are hosting such a server
10:56 < Grum> yes server and client are wasteful
10:56 < Paprikachu> you probably have 100 mbit at least
10:56 < Grum> it's really simple, when we designed it, we made it flexible enough to suit for whatever
10:57 < Paprikachu> 12kb/s don't even show up on such a scale
10:57 < Grum> the cost of reasing a varint is not 'that insane' compare to reading byte/short/int
10:57 < SinZ> Paprikachu: and what about people hosting minecraft on a home connection
10:57 < Paprikachu> those 12kb/s prob won't make the difference between being able to host it or not
10:58 < Paprikachu> also, that's for 100 players
10:58 < SinZ> its a minor saving on an already wasteful system
10:58 < Grum> also only for incoming traffic
10:58 < Grum> it's quite simple, the cost of reading varints is less than the flexibility gained
10:58 < Paprikachu> i'm just saying the tradeoff isnt worth it
10:59 < Grum> And that is what notch would have said
10:59 < Grum> and that is how you'd never be able to add blocks to the game
10:59 < Grum> because 'you would run out of space on the texturesheet'
10:59 < Paprikachu> the cost of reading varints is higher than the bandwith and the complexity
10:59 < Grum> oh and you just have one, because that is all you need
10:59 < Paprikachu> err, put complexity on the other side
11:00 < Paprikachu> if you're going for 10k players (like i am) nothing hurts more than things that waste cpu for no reason
11:00 < Grum> i prefer flexibility if the cost is low enough
11:01 < Grum> and it definitely is
11:01 < Grum> the cost is low enough it wont show as a hotspot for a looooooooooooooooong time
11:01 < Paprikachu> maybe
11:02 < Paprikachu> speaking for costs, would it be possible to add a way to run online mode without encryption
11:02 < Paprikachu> s/for/of
11:02 < Grum> nope never
11:02 < Paprikachu> sad day
11:02 < Grum> go play 1.4 orso
11:02 < Paprikachu> why not?
11:02 < Grum> because of the reason it was added in the first placde
11:03 < Paprikachu> what is the reason? i honestly don't know
11:03 < Grum> main in the middle attacks
11:03 < Grum> err man
11:04 < Paprikachu> right, but you can potentially sign messages or something
11:04 < Paprikachu> something cheaper than encryption
11:04 < Grum> AES is cheap enough
11:06 < Grum> there is also no way to do it without actually setting up encryption
11:08 < Paprikachu> mh
11:08 < Paprikachu> why is the length of the type field included in the packet length
11:09 < Grum> because the sizing is added after the packet is written
11:10 < Paprikachu> eh?
11:10 < MrARM> If you want to make for example a simple chat app, it makes EVERYTHING easier 
11:11 < Paprikachu> it only made everything harder for me
11:11 < Grum> honestly, it's not designed to be cherry-picked
11:11 < Grum> read all the shit and it should be easy :)
11:12 < MrARM> Yeah, but that takes some time :p
11:12 < Grum> not really, you can now quite trivially skip things
11:12 < Paprikachu> i'm not saying it's a problem, just makes code more complicated than it needs to be
11:12 < SinZ> Grum: and if that UK politition gets into power, and encryption potentially outlawed, would there be online mode no encryption, or just boycott the country
11:12 < Grum> it doesn't on our end
11:12 < Grum> hahahaha outlaw encryption?
11:12 < Grum> hahahahahah
11:13 < Grum> he must be ok that everyone sees every single thing he does
11:13 < SinZ> hurrhurr we need complete survelience to counter terrorists
11:13 < Grum> every site he visits, every mail he writes
11:13 < Grum> because that is what that means
11:13 < MrARM> I meant that it would take time to make implementation for every packet 
11:13 < Paprikachu> http://ideone.com/Vl9d6J
11:14 < Grum> Paprikachu: you must be using a radical different wat to read data than we do
11:14 < Paprikachu> this is what you have to do if you want your encoding to be efficient
11:14 < Paprikachu> where efficient means: no superficial allocations, no copying
11:14 < Paprikachu> varInt() is just a marker btw
11:15 < Grum> to us it is just adding a single pipeline element :p
11:15 < Paprikachu> yeah well, i bet you don't care about efficiency as much :P
11:16 < MrARM> It's not a problem, really 
11:17 < Paprikachu> this is also a little problem: if you have variable length headers, you don't know yet where in the buffer the packet will go, you have to precalculate what size it's gonna be.
11:17 < Paprikachu> (which is what this code does)
11:17 < Grum> not having that problem at all
11:17 < MrARM> you just allocate a buffer with the size varint 
11:17 < Paprikachu> yes, because you don't care about efficiency
11:17 < Grum> erm>
11:17 < Paprikachu> i do
11:17 < Grum> you mean you do not find an efficient way of handling it where we did?
11:18 < Paprikachu> i'm curious to see what that looks like
11:18 < MrARM> mcp :p
11:18 < Paprikachu> if it involves anything like streams, nope, it's not efficient
11:18 < MrARM> also, glowstone 
11:18 < MrARM> why? 
11:18 < Paprikachu> reallocations.
11:18 < MrARM> hmmm? 
11:19 < Paprikachu> you can only append to an array until it's full
11:19 < Paprikachu> after that you need a new one
11:19 < Grum> https://gist.github.com/grum/cb6ca427ad9901ee0f3d
11:19 < MrARM> Yeah, 1 per an uncompressed packet 
11:20 < Grum> that is literally all the code needed to do what you say :P
11:20 < Paprikachu> well, if you use a lib
11:20 < MrARM> it really won't matter even if you reallocate 
11:20 < Paprikachu> and we don't know what that lib does internally
11:20 < MrARM> You'll have higher problems about ping rather than that 
11:20 < Grum> oh it is missing the encoder/decoders for the encryption
11:20 < Grum> because those are just added runtime
11:21 < Grum> same for the compression/decompression
11:21 < Grum> so it has 4 more elements in the pipeline
11:21 < MrARM> Also, do you use a ByteArrayOutputStream for compression? 
11:21 < Paprikachu> this just makes me wonder if you understood my concerns at all :|
11:22 < MrARM> Anyway, who cares Paprikachu. It's not an performance bottleneck. 
11:22 < MrARM> it probably takes less than 1ms
11:23 < MrARM> much less
11:23 < Paprikachu> reallocations could become an issue if you have 200k packets per second
11:23 < Grum> Updated the gist to show all elements possible
11:23 < Paprikachu> in any case, i solved it, but i'm saying it's more complicated than it needs to be
11:24 < Grum> its not?
11:24 < Paprikachu> of cours it's easy if you have a lib like netty
11:24 < MrARM> You won't have more than 200k packets per server 
11:24 < Grum> that is literally all you need
11:24 < MrARM> Even without a lib is simple 
11:24 < Paprikachu> MrARM: im going for 10k players
11:24 < Grum> Paprikachu: lib or not, if it is hard, you are doing it wrong
11:24 < Paprikachu> Grum: it's not hard, it's easy to get wrong
11:24 < Grum> that is the nature of making your own implementation
11:25 < Grum> go try making a skype client
11:26 < MrARM> myself, I just read a varint, allocate a buffer with the size, create some sort of a ByteInputStream and it's done (when no compression has been done yet) 
11:26 < Paprikachu> that's where the inefficiency starts
11:26 < MrARM> after it is, I do reallocate the array even when it's compressed though 
11:26 < MrARM> I could not find an way not to do that 
11:26 < Paprikachu> what i did is i read as many bytes as the system ahs received and parse it manually
11:27 < Paprikachu> no reading of single bytes
11:27 < MrARM> writing was harder to do, as then I possibly reallocate many times if packet is big and compressed 
11:27 < Paprikachu> which means i can potentially read multiple packets with a single read
11:27 < MrARM> Yeah 
11:27 < MrARM> or 
11:27 < MrARM> half a packet 
11:27 < Paprikachu> yes
11:27 < Grum> aka: doing it wrong :p
11:27 < MrARM> also
11:27 < Paprikachu> but if you read half a packet
11:27 < Paprikachu> you have to start a new io operation anyways
11:28 < MrARM> you don't need to reallocate the buffer when you read half a packet 
11:28 < Paprikachu> it just happens hidden in some library
11:28 < Paprikachu> i have fixed size buffers for some predefined max length value
11:28 < Grum> which is how long?
11:28 < Paprikachu> if a client sends more, it gets disconnected
11:28 < Paprikachu> 1k for read buffers, for send buffers i currently use the same size, but i know i will need more for chunks
11:29 < Grum> so you are not even compatible to our protocol ;)
11:29 < Grum> 21bits is the longest data you need to be able to read
11:29 < MrARM> ^
11:29 < MrARM> wait 
11:29 < Paprikachu> what packet would that be
11:29 < Grum> any packet
11:29 < MrARM> did I... do that wrong 
11:29 < Grum>                     .addLast("splitter", new Varint21FrameDecoder())
11:29 < Paprikachu> well, if you're sending 2^21 bytes, chances are you're ddosing
11:29 < Grum> not at all
11:29 < MrARM> no, I did not :) 
11:30 < Grum> not from the server :)
11:30 < Paprikachu> ?
11:30 < Paprikachu> i'm talking about data sent from clients
11:30 < Grum> also mods can trivially send that much data if they need to
11:30 < Grum> clients as well
11:30 < Paprikachu> i don't have to support mods
11:30 < Paprikachu> i'd rather get a server running before dealing with any mods
11:31 < MrARM> you can also easily read the data from the stream itself if you want to 
11:31 < Paprikachu> and right now fixed size buffers are easy and just work efficiently
11:31 < Paprikachu> there is no stream
11:31 < MrARM> I meant socket
11:31 < Paprikachu> well that's what i'm doing
11:32 < MrARM> and then check how many data you read in total 
11:32 < MrARM> and throw an exception if the varint was other 
11:32 < Paprikachu> lol exceptions
11:32 < Paprikachu> i don't use exceptions for client-caused errors, that's wrong
11:32 < MrARM> what language you use then lol
11:32 < Paprikachu> c++
11:32 < MrARM> Me too 
11:32 < MrARM> and then is a thing called exceptions there 
11:33 < MrARM> I don't see what's wrong with using it
11:33 < Paprikachu> it's wrong to use exceptions for expected behaviour
11:33 < Paprikachu> malformed data is completely expected
11:33 < MrARM> It's not :p
11:33 < Paprikachu> when a client sends malformed data, there's exactly 2 lines that get executed
11:33 < Paprikachu> the first is usually disconnect(client
11:33 < Paprikachu> )
11:33 < Paprikachu> the second usually a return
11:33 < MrARM> tcp has packet recovery and also orders packets. If you get malformed data you should really disconnect 
11:34 < Paprikachu> that's it
11:34 < Paprikachu> no exceptions
11:34 < MrARM> catch the exception and disconnect 
11:34 < Paprikachu> no need to throw one in the first place, you can disconnect right away.
11:34 < MrARM> maybe or maybe not 
11:34 < MrARM> not always you have to 
11:35 < MrARM> anyway, what are you doing? 
11:35 < Grum> your fixed size buffer should be 2mb :)
11:35 < Paprikachu> gonna eat something now :)
11:35 < Thinkofdeath> If you want an example of a serverbound packet that /could/ reach the protocol limit it would be 'Creative Inventory Action'
11:36 < MrARM> I think also chat packet could eventually do that 
11:37 < Thinkofdeath> not from a client
11:37 < Thinkofdeath> from the server it can (and will on some servers)
11:37 < Grum> yup
11:37 < Grum> and any custom data packet
11:37 < Grum> go write a huge book :P
11:38 < MrARM> anyway, protocol limit or limit of a 2mb buffer? 
11:38 < Thinkofdeath> oh and if you don't care about creative 'Player Block Placement' for some strange reason still has the held item as a field
11:41 < Paprikachu> maximum book length sounds reasonable
11:46 < Grum> right now a protocol limit
11:46 < Grum> we have no way to read a packet > 21bits
11:47 < Paprikachu> well, i can't use 2mb buffers though
11:47 < Paprikachu> multiply that by 10k :P
11:48 < Grum> you are not reading from all the sockets at the same time are you? ;D
11:48 < Paprikachu> actually i am
11:48 < Paprikachu> it's a single syscall down the road
11:48 < Grum> to read from all sockets?
11:48 < Paprikachu> yup
11:49 < Grum> well good luck :)
11:49 < Grum> enjoy the encryption too then
11:49 < Grum> manylots of bytes that have to be decrypted
11:49 < Paprikachu> oh, i won't encrypt probably
11:49 < Paprikachu> i'd rather build my own auth system
11:50 < Grum> enjoy mitm attacks then :)
11:50 < Paprikachu> that also doesn't suffer from the issue that you can't login if login servers are down
11:50 < Grum> or have those nasty skins
11:51 < Paprikachu> also, encryption is probably not even an issue, at least not programming wise
11:51 < Paprikachu> performance wise maybe
11:52 < Grum> wasn't that all that mattered?
11:52 < Paprikachu> cpu usage is the main concern, yeah
11:52 < Paprikachu> i don't wanna end up with a server like the vanilla one
11:53 < Paprikachu> Grum: i've heard you don't even sort entities by type, have you checked if that improves performance?
11:53 < Grum> and you think that all we've talked sofar is contributing to 'slow' in the vanilla server? :)
11:53 < Grum> sort entities by type?
11:53 < Grum> what?
11:54 < Paprikachu> you have some kind of entity container, right?