23:42 < dav1d> o/ Grum 
23:42 < Thinkofdeath> (See log at bottom of paste)
23:42 < Grum> ello dav1d
23:43 < Grum> Thinkofdeath: kinda weird
23:43 < Grum> because in channelActive channel should exist
23:43 < Grum> always
23:44 < Grum> amazing
23:44 < Grum> so we do a 'send' without having a channel open
23:44 < Thinkofdeath> Yep
23:44 < Grum> should be trivial to fix
23:44 < Grum> thanks :)
23:44 < Thinkofdeath> np
23:49 < barneygale> :D
23:57 < barneygale> Here's a fun one. In 1.6, mc.net auth and encryption start are separated by a single plaintext packet (encryption response with an empty payload). In 1.7 it looks like encryption starts at the same time. Does this mean I have to support encryption even if I want to kick the player immediately after auth?
23:58 < barneygale> Am I reading this right?
23:58 < Thinkofdeath> TkTech: This ok http://wiki.vg/Debugging ?
23:59 < Thinkofdeath> barneygale: There is a login disconnect
23:59 < Thinkofdeath> http://wiki.vg/Pre-release_protocol#Disconnect_2
23:59 < Thinkofdeath> Wait... that might still need encryption
--- Day changed jeu. oct. 24 2013
00:00 < Thinkofdeath> barneygale: Yeah I think you will need to support encryption
00:02 < barneygale> what a ballache!
00:02 < barneygale> I haven't touched minecraft encryption in over a year
00:04 < Drainedsoul> barneygale: But you can kick the player by just closing the socket o_O
00:04 < barneygale> I can, but the whole point of this program is to tie into a website signup process
00:04 < Drainedsoul> ah okay :(
00:04 < barneygale> Drainedsoul: https://github.com/barneygale/authserver
00:05 < Drainedsoul> shutdown(fd,SHUT_RDWR);close(fd); is more fun tho
00:20 < Grum> barneygale: you can kick during auth afaik
00:21 < Grum> yeah there is a server->client packet to get rid of the client
00:21 < barneygale> Oh really? I must be doing it wrong then
00:24 < Thinkofdeath> Still needs to be encrypted after Encryption Response
00:25 < barneygale> I'm figuring out the best way to make the server to fail the auth step and kick the client
00:25 < barneygale> so I can observe what vanilla does
00:26 < dav1d> send an invalid encoeded verify token thingy?
00:26 < barneygale> I don't have a client implementation of the protocol. I'm working with vanilla client + server
00:27 < barneygale> I could just patch out the checkserver.jsp call and point it to localhost
00:27 < dav1d> oh
00:27 < Thinkofdeath> or use the hosts file with sessionserver.mojang.com
00:28 < barneygale> Would that work? I thought it uses SSL nowadays
00:28 < barneygale> Through wiki.vg/Protocol_Encryption says otherwise.
00:28 < barneygale> I'll try that
00:29 < Thinkofdeath> Also its https://sessionserver.mojang.com/session/minecraft/hasJoined now
01:41 < TkTech> Thinkofdeath: Yup, thanks.
01:46 < TkTech> Thinkofdeath: The server can do it as well
01:46 < TkTech> It's explicitly set to DENY by default on the server
01:47 < TkTech> There's also NETWORK which NETWORK_PACKETS is a subclass of
01:48 < TkTech> Also PACKET_RECIEVED
01:48 < TkTech> And PACKET_SENT
01:49 < TkTech> And EVENT
01:50 < TkTech> And FLOW, ENTRY, EXIT, EXCEPTION, THROWING and CATCHING although I don't know if those ones are used.
01:50 < TkTech> Just log4j defaults.
02:08 < barneygale> Right, looks like my kick message does need to be encrypted, pah!
02:20 < barneygale> This doesn't seem right to me. Auth succeeding should be followed by a plaintext packet to say "OK, lets do encryption now!" as it used to be. Without that, the client could send back an invalid symmetric key, or an incorrect verify token, and the server /has/ to use the key in order to kick the client to say it's invalid?
02:20 < barneygale> Does that seem wrong to anyone else?
02:20 < barneygale> Yet I've confirmed in wireshark that everything after the encryption response is encrypted
02:23 < barneygale> which is what the wiki says too
02:23 < barneygale> thoughts?
02:26 < Drainedsoul> you seem to think that if the client totally fudges encryption, the server is under some obligation to respond in a sane way
02:26 < Drainedsoul> the client broke sanity by fudging encryption, close their socket
02:27 < barneygale> Obviously it's not an obligation, but every other protocol error results in a kick rather than a straight d/c.
02:28 < Drainedsoul> it can result in a kick
02:28 < Drainedsoul> you can opt to just close the client's socket instead
02:28 < barneygale> Also everything prior to 1.7 had that single plaintext packet which I assume is there for exactly that reason
02:28 < barneygale> If someone has failed name authentication, what's the point in starting protocol encryption for a single packet, right? The old way worked fine and had no disadvantages
02:29 < Drainedsoul> then don't.  Close their socket.
02:29 < barneygale> That's just going to the other extreme :/
02:29 < Drainedsoul> I don't see how that's extreme
02:30 < barneygale> You think just d/cing someone when their session goes stale is OK? How often do you see "failed to login" errors come up? How will that situation be made any better by providing no error message at all?
02:31 < barneygale> The fact is that minecraft does a reasonable job to report errors via kick messages. It doesn't just d/c
02:31 < Drainedsoul> I haven't really done a lot of client side programming, but doesn't the client have to verify its session etc. during the handshake?  Shouldn't it find out then that it's session etc. is out of date etc.?
02:31 < Drainedsoul> I don't see why the server should have to provide a diagnostic for a client side error
02:32 < barneygale> It's not a client side error. The client believes in good faith that it's session is valid. It says to the server "I'd like to log in with this session", and it's up to the server to tell it otherwise. If you add that to the client you're pointlessly duplicating work.
02:33 < barneygale> (as the server will need to make that check anyway)
02:34 < barneygale> "failed to login" has, in the past, been caused by auth server failures, leaving the game open too long, or logging in from somewhere else. I don't know how many of those are still relevant, but afaik it isn't a problem that's gone away
02:34 < Drainedsoul> but the client has to make some kind of call to Mojang's servers with the server ID/public key/etc., otherwise the step where the server authenticates aganst Mojang wouldn't work?
02:36 < barneygale> This is testing my memory
02:36 < barneygale> Yeah, it does.
02:43 < barneygale> Grum: in 1.7, encryption starts immediately after the key exchange + auth, which means that encryption is always enabled, even if it's only encrypting a single Disconnect("Bad login") packet. Is this a deliberate design decision that will stay? Prior to 1.7 there was a packet sent in plaintext to signify "auth was successful, we're starting encryption now", or alternatively a plain-text kick message.
02:45 < barneygale> The old behaviour is preferable to me, but obviously you shouldn't give undue consideration to 3rd party devs. I just bring it up from a design perspective, as the new scheme seems somewhat less elegant to me.
04:08 < dividuum> I might be incorrect, but the "Bad login" message isn't sent by the server but generated when the client does the /joinserver http request with an expired session token.
04:08 < dividuum> At least I get that error when logging into my server sometimes. And I'm sure I don't send "Bad login" :-)
04:36 < nickelpro> Minecraft varints are big-endian right?
04:38 < nickelpro> Or do they actually follow the standard (a nice change for MC) and are little-endian?
04:50 < Drainedsoul> Network byte order is big endian
04:50 < dividuum> it's little endian: The lowest 7 bits are in the first byte you receive.
04:50 < Drainedsoul> ^
04:50 < nickelpro> dividum: Thanks
04:51 < nickelpro> I was scratching my brain trying to figure out how to sanely implement a decoder when I realized they're probably little endian
04:51 < nickelpro> encoder*
04:51 < Drainedsoul> it doesn't really make sense to think of them as having any endianness
04:52 < Drainedsoul> since they're encoded on a per byte basis, and it doesn't make sense for bytes to have a sub word byte ordering
04:52 < nickelpro> "least significant group first" then
05:40 < Not-001> [fCraft] fragmer * r2242 2 files : Adjusted code style, to allow simple getters/setters and if's on a single line.
05:41 < Not-001> [MCPP] RobertLeahy pushed 6 commits to 1_7_protocol [+2/-0/±9] http://git.io/jD3vHw
05:41 < Not-001> [MCPP] RobertLeahy 238680c - Protocol Analysis
05:42 < Not-001> [MCPP] RobertLeahy 11629b2 - HTTPHandler Update
05:42 < Not-001> [MCPP] RobertLeahy b5e8f50 - Variant Assign/Construct from Convertible Types
05:42 < Not-001> [MCPP] RobertLeahy ed7133d - JSON Tweak
05:42 < Not-001> [MCPP] RobertLeahy 213cd6b - Ping Cleanup
05:42 < Eviltechie> spaaaaam
05:42 < Not-001> [MCPP] RobertLeahy 10e1f10 - Yggdrasil
05:45 <+fragmer> everyone loves spam
05:52 < Not-001> [fCraft] fragmer * r2243 161 files : Normalized formatting for all code files.
05:53 < Eviltechie> ooo, a c++ server
05:54 < nickelpro> got MC varints working in Python, code could probably be much more dense if I was better with bitwise arithmatic https://gist.github.com/nickelpro/7131058
05:57 < Drainedsoul> Eviltechie: which?
05:58 < Eviltechie> Drainedsoul: whatever that mcpp thing is fragmer just pushed to
05:58 < Drainedsoul> nickelpro: Doesn't Python let you do neg = val < 0 ?
05:58 < Drainedsoul> Eviltechie: Oh that's me.
05:59 < nickelpro> Drainedsoul: See this is what happens when I have to work with bitwise operations
05:59 <+fragmer> I didn't push, RobertLeahy did
05:59 < nickelpro> I miss obvious stuff
05:59 < Eviltechie> why does it say your name then
05:59 < Eviltechie> MEH
05:59 <+fragmer> Look closer :P
06:32 < Not-001> [fCraft] fragmer * r2244 68 files : Normalized formatting/indentation for the rest of the projects.
06:42 < barneygale> nickelpro: here's my python code, though it doesn't support negatives: https://gist.github.com/barneygale/7b04d45d25dacab37f63
06:42 < barneygale> also excerpted
07:21 < nickelpro> barneygale: Or unpacks are nearly identical except for two lines I use to support negatives, supporting negatives in pack got much trickier than I initially thought :-\
07:21 < nickelpro> our*
07:23 < nickelpro> barneygale: Also if your pack packs a number with an MSB set (ex 64) won't minecraft think it's negative?
07:29 < Drainedsoul> nickelpro: What's hard about supporting pack for negatives?
07:31 < nickelpro> Drainedsoul: Python doesn't use twos complement, have to xor everything
07:31 < Drainedsoul> wtfg
07:32 < Drainedsoul> *wtf
07:32 < Drainedsoul> that's the saddest thing I've heard today
07:35 < nickelpro> Ya negative is more like a flag set on an integer object in Python
07:37 < Drainedsoul> sometimes I want to give Python a try, and then I hear things like this...
07:37 < nickelpro> It makes sense since it doesn't have fixed with integers
07:37 < nickelpro> width*
07:37 < nickelpro> it just makes bitwise stuff get silly
07:41 < Drainedsoul> ._. I'll just stick with C++
07:41 < nickelpro> For some reason I never really loved C++, I love C, and I love Python, but C++ never appealed to me
07:42 < nickelpro> Too many ways to do the right thing, though I've spent a good bit of time playing with templates
07:43 < Eviltechie> I have this tendancy to not like languages like python
07:43 < Eviltechie> I find them sort of wishy washy
07:44 < nickelpro> I can get that
07:45 < nickelpro> I've been thinking about doing a client in Go or C for that reason
07:45 < Drainedsoul> nickelpro: How is having many ways to do the right thing an issue?  Besides which, you'll usually find that a certain way of doing something is slightly preferable to another way.
07:45 < Drainedsoul> I guess it also depends which dialect of C++ you were writing
07:45 < Drainedsoul> C++98/03, I'd only write that if someone was paying me
07:45  * Eviltechie did Borland C++
07:46 < Drainedsoul> C++11/14 though, are a different story entirely
07:46 < nickelpro> Eviltechie: My first CompEng class was in Borland C++
07:46 < Eviltechie> Yup, still love that ide.
07:46 < Drainedsoul> I just use Notepad++ for everything.
07:46 < nickelpro> lol, the debugger was actually solid
07:46 < Eviltechie> But when I tried to use a more modern version, it was like "namespaces, what's that"
07:47 < nickelpro> I actually love Notepad++, wish it was on linux
07:49 < nickelpro> I like Python whenever I'm working on a project that I actually want people to use, for better or worse its barrier to entry is super low. My little brother can write plugins for my minecraft client, and that was a goal for me
07:49 < Eviltechie> Yeah, there are advantages to having a looser language like that.
07:50 < Eviltechie> Just the other day, I wanted to xor a list of numbers in hex, and I could write 3 lines of python and bam
07:51 < nickelpro> Ya its scripting capabilities are awesome, though for embedded stuff I'm starting to prefer Lua
07:51 < Eviltechie> Some days I love java because of how rigid it is. Other days I curse it for the same reason.
07:51 < nickelpro> I feel the same way
07:52 < Drainedsoul> I can't take a language that doesn't have unsigned integers seriously
07:52 < nickelpro> When I'm working in a Java project I know exactly how everything will fit toghether, except when it doesn't all fit toghether, and then I'm screwed
07:53 < Eviltechie> I have a hard time starting a project in java because I can see conceptually how it all fits together, but I can't get words on the page
07:53 < nickelpro> Thats regardless of language, writing the first few stub functions is the hardest part of any class implementation for me
07:53 < nickelpro> once I have code down, modifying it is the easy part
07:54 < Eviltechie> Yeah, I've been working on a program to score baseball games for an eventual character generator. I've been through so many iterations before I finally sat down and found something that I liked.
07:55 < Eviltechie> Baseball has super complex rules though, so that's sort of my own fault
11:09 < Valin> hi
11:09 < Valin> 1.7: "The Network Code has been completely rewritten"
11:10 < Valin> did they rewrite the protocol or just the network code itself in 1.7?
11:12 < Drainedsoul> the protocol
11:12 < Drainedsoul> and the network code
11:15 < Grum> bit of both :)
11:31 < SinZ> not the easiest thing to rewrite the entire protocol without changing the network code
11:35 <+Amaranth> Packet handling is still a shotgun parser though
11:35 <+Amaranth> Well, actually I guess that isn't quite the correct term for it
11:36 <+Amaranth> But having packet classes which do some of the parsing and packet handling methods with (hopefully) do the rest is weird and doing it in your own code makes it more likely the protocol will require doing it
11:36 <+Amaranth> s/with/which/
11:37 < Drainedsoul> In my implementation the packet classes don't do any parsing/serialization
11:39 <+Amaranth> How that packets have a length header that is easier to setup
11:40 < Drainedsoul> that's half a blessing and half a curse as far as I'm concerned
11:40 < Drainedsoul> the blessing part is that you don't have to incrementally build packets, or build them and then roll back to try again
11:40 < Drainedsoul> the curse part is that you can't be 100% sure how long the length header is, so there's some memcpy/memmove to get the header at the front of the outgoing buffer :[
11:55 < Grum> why not just emit another buffer with the length before emitting the actual buffer Drainedsoul?
11:55 < Grum> that is what netty does :p
11:56 < Drainedsoul> I would have no guarantee those buffers would be sent in order
11:59 < Grum> why not? O.o
11:59 < Grum> wtf
12:00 < Grum> whatever you queue up to be send has to be send in *that* order ;)
12:01 <+Amaranth> I think he might mean non-transactional inserts into the queue might mean you get packet data interlaced
12:01 < Drainedsoul> because packet serialization is not coupled to the network stack at all.  It is guaranteed that buffers are not interleaved, but multiple threads are permitted to "write" to the network stack simultaneously, in which case their buffers are queued up in whatever order they happen to arrive
12:01 <+Amaranth> So yes, that was the concern
12:02 < Grum> packets have order
12:02 <+Amaranth> Unless you take a lock to ensure you queue both pieces without interruption you can't split the packet data into multiple buffers
12:02 < Grum> not sure how you ever want to dodge that
12:02 <+Amaranth> Well there is no order required for sending entity position updates
12:02 <+Amaranth> Random example
12:02 < Grum> they better come after the init of the entity though ;0
12:03 < Drainedsoul> which has nothing to do with the network stack
12:03 < Drainedsoul> the component/module managing entities is responsible for that ordering
13:16 < Grum> Drainedsoul: yes but its rather void to order in the component/module if then the network stack is going to randomize it again ;)
14:09 < mrapple> Grum: it appears connecting to servers is more reliable in 1.7.1, but it also appears that not all race conditions have been fixed
14:10 < mrapple> often times, after leaving and joining a few 1.7.1 servers, i stop being able to connect to a new server without relaunching
14:10 < mrapple> cc Dinnerbone 
14:10 < Grum> yeah
14:11 < Grum> there seems to be a race-condition where it sometimes doesnt send the intention
14:27 < Grum> mrapple: meh its hard to replicate
14:36 < Thinkofdeath> Just don't send packets until channelActive is called
14:58 < Grum> Thinkofdeath: not so super easy
15:39 < Grum> mrapple / Thinkofdeath: had a reliable way to test it? :/
15:48 < Thinkofdeath> Grum: Just keep connecting and disconnecting, always happens at some point for me but its very random 
15:58 < Grum> i cant reproduce it
15:58 < Grum> tried 100x
16:17 < barneygale> Grum: local server?
16:51 < Grum> barneygale: tried local and on dinnerbones system
16:52 < Grum> were you able to reproduce it?
16:52 < barneygale> Yeah. I connected 20 times to a local server - 11 failures, 9 successes
16:52 < Grum> could you test a jar? ;D
16:52 < barneygale> Sure
16:54 < Grum> cleanassing
16:56 < Grum> barneygale: http://db.grum.nl/minecraft.test.jar
17:00 < barneygale> Grum: 1 success, then 5 failures, then 4 successes
17:00 < barneygale> After the 5th failure I hit "refresh" on the multiplayer menu
17:00 < Grum> how the fuck
17:00 < barneygale> I don't know if that affects it, will test a bit
17:01 < Grum> what O.o that makes no sense
17:02 < Grum> can you turn on the debug?
17:02 < Grum> it should say:             LOGGER.debug("Qeued packet, connection not ready yet");
17:02 < Grum> lol missingu
17:02 < barneygale> You gave instructions for doing that yesterday right? I'll find them in my log.
17:03 < Grum> i could make you a jar that has it
17:03 < Grum> buildings
17:04 < barneygale> Thanks
17:04 < barneygale> Btw it seems like that refresh was unrelated
17:05 < Grum> barneygale: http://db.grum.nl/minecraft.test.2.jar
17:07 < barneygale> Sure you did it right? I don't seem to be getting any extra debug info
17:11 < Grum> hmmm
17:11 < Grum> ah no
17:11 < Grum> fail
17:12 < Grum> ah fuck i fubarred
17:14 < Grum> barneygale: http://db.grum.nl/minecraft.test.3.jar
17:19 < barneygale> Grum: did you change anything other than debug printing? I can't reproduce it in this version
17:21 < barneygale> Yeah, just tried about 40 times. Worked every time.
17:24 < Thinkofdeath> Same happened when I enabled debugging last night to test it
17:26 < Flemmard`> ahh debugging messages that "fixes" the problem .. so nice
17:40 < Thinkofdeath> Grum: Client> [16:39:59] [Server Connector #2/INFO]: Queued packet, connection not ready yet   (had to change it to LOGGER.info to get it to work)
18:37 < Grum> oh yeah meh all debugging turns on then
18:37 < Grum> barneygale / Thinkofdeath: kinda messed up this :/
18:40 < Thinkofdeath> ?
18:54 < Grum> well, without debugging it should work
18:55 < Grum> Thinkofdeath: with that 'info' thing did it work 'as expected' ?
18:57 < Thinkofdeath> Grum: yeah the bug happens with info not debug
19:00 < Thinkofdeath> With log level set to info in log4j.xml
19:37 < Grum> Thinkofdeath: you get the message and the bug happens?
19:37 < Thinkofdeath> Grum: Yes
19:37 < Grum> the strange part is, the bug shouldn't happen when you get the message
19:37 < Grum> i mean, there is a race-condition
19:37 < Grum> but that one is not trivially solvable
19:37 < Grum> so to solve it i just queue up the packets we intended to send
19:37 < Grum> and then send em later
19:38 < Grum> oh
19:38 < Grum> and i just realize another race-condition in that
19:38 < Grum> goddammit >.>
19:38 < barneygale> let me know if you need anything tested
19:38 < Grum> yeah coding now :P
19:39 < Grum> building
19:39 < Grum> i left in a case where i could mis-order the packets
19:41 < Grum> barneygale: http://db.grum.nl/minecraft.test.4.jar
19:45 < Thinkofdeath> Grum: [Server Connector #4/INFO]: Queued packet, connection not ready yet <-- And it connects!
19:45 < barneygale> Yep
19:45 < barneygale> Appears fixed for me
19:45 < Grum> yeah
19:45 < Grum> so what happened is that we do: connect(); send(); send()
19:46 < Grum> and if it wasn't ready the first send wold queue
19:46 < Grum> and i forgot to flush the queue on the send
19:46 < Thinkofdeath> Ah
19:47 < Thinkofdeath> Well thank you for fixing :)
19:47 < Grum> thanks for confirming :)
19:47 < Thinkofdeath> https://mojang.atlassian.net/browse/MC-34947 Guess this is the issue for it
19:47 < Grum> some of those issues are just not reproducable :(
19:49 < Thinkofdeath> Yeah the fact that turning on debugging fixed didn't help track it down :P
19:49 < Grum> yeah ..... i run with debugging on by default in my dev env >.>
19:49 < Grum> for obvious raisins :)
19:49 < Thinkofdeath> Haha yeah
19:52 < barneygale> Guessing this'll be 1.7.2 then?
19:53 < Thinkofdeath> Or just update 1.7.1 since it doesn't change much
19:53 < barneygale> that's true
19:53 < Grum> yeah considering doing ninja update
19:54 < Grum> obfuscation will change for 1 file
19:54 < Grum> but meh
20:15 < mrapple> Grum: go go ninja update
20:15 < mrapple> nice work, btw
20:25 < Grum> stupid issues
20:25 < Grum> i know better ways of doing it
20:25 < Grum> but that would require another restructure
22:25 < mrapple> Grum: ninja update or 1.7.2?
22:38 < iBotPeaches> It's just you. http://wiki.vg is up.
22:39 < iBotPeaches> ugh. what is my Internet doing
23:23 < elarcis> well hi there
23:23 <+sadimusi> o/
23:25 < elarcis> I'm currently developping a pvp plugin (using bukkit api) where a lot of tp are involved, but my players keep telling me that sometimes, tped players are invisible. I was thinking about regularly send the destination chunk to players via custom packets manipulation to reduce lag, but I'm not even sure if that would work. What do you think ?
23:25 < elarcis> thanks in advance
23:27 < elarcis> I stumbled upon wiki.vg, which seems to tell a lot on protocols, and i know that it isn't quite managed by bukkit (as much as I know)
23:27 < elarcis> I stumbled upon wiki.vg, which seems to tell a lot on protocols, and i know that it isn't quite managed by bukkit (as much as I know), so this is not a bukkit question but rather a technical minecraft question
23:27 < elarcis> oops
23:28 < elarcis> My main fear is that even if I send custom chunks to every player, their clients decide themselve to unload them, since the destination chunk can be quite far away, or even in another dimension
23:30 < Thinkofdeath> Not sure why sending the chunk would help
23:30 < Thinkofdeath> Plus clients unload chunks only when the server tells them too
23:30 < elarcis> good to know
23:30 < elarcis> My hypothesis is that invisibility is caused by lagging players having troubles loading the destination chunk
23:31 < Thinkofdeath> sending the chunk only sends blocks not players/entities, they are different packets
23:31 < elarcis> as when I tp a player which is in a nearly chunk, he doesn't have any trouble moving right after tp, and I can see him instantlx
23:31 <+sadimusi> iirc there used to be a bukkit plugin that fixed this issue
23:31 <+sadimusi> maybe you could look at that if you manage to find it
23:32 < elarcis> hum
23:32 < elarcis> thanks, I'll check this
23:32 < zifnab> elarcis: i ran into that with the snapshot last night, it'd take a few seconds for the tp'd player to show up
23:32 <+sadimusi> teleporting nearby is just the same as moving, you won't encounter any problems there
23:33 < elarcis> also good to know
23:56 < elarcis> after some searches, World.refreshChunk() of the bukkit API would do exactly what I'm searching for, so I'll see if that's a good fix
23:57 < elarcis> I'll let you know
--- Day changed ven. oct. 25 2013
00:26 < elarcis> well after some tests, it appears that if not solved, it reduced invisibility time significantly among my players, so I guess I'll stick to it for now
00:26 < elarcis> thanks for the help !
00:49 < mrapple> Grum: another 1.7 bug http://cl.ly/image/0r0j1f2u0I0L
00:50 < mrapple> chat message with format {text: "§aColored text that goes onto a new line does not color when it hits the new line"}
00:52 < Thinkofdeath> Its a known issue
01:24 < Drainedsoul> are people still using the old formatting codes
01:25 < Thinkofdeath> Drainedsoul: bukkit servers still do
01:25 < Drainedsoul> and they just send them, rather than parsing/converting them? -_-
01:26 < Thinkofdeath> Currently yes
01:26 < Drainedsoul> that's awful.
01:26 < Drainedsoul> I wouldn't've hated the old system so much if it didn't have unrepresentable characters
01:28 < Thinkofdeath> I guessing an api for json chat will be added at some point 
02:02 < TkTech> go osde
02:09 < Drainedsoul> TkTech: what?
02:12 < TkTech> Drainedsoul: ./go #opag + beer.
02:12 < TkTech> I was changing channels. Whoops.
06:26 < Grum> <mrapple> chat message with format {text: "§aColored text that goes onto a new line does not color when it hits the new line"} <-- works as intended, stop using old shit
06:55 < Drainedsoul> Thinkofdeath: How'd you ascertain that Chat Message, client to server, contains JSON Data?
06:56 < Drainedsoul> http://i.imgur.com/peJaHoT.png
06:56 < Drainedsoul> that's just plaintext "hello", not JSON
07:04 < mrapple> Grum: that does not work as intended....
07:05 < mrapple> the color should go onto the next line
07:05 < mrapple> just like it has in every previous version of minecraft
07:05 < SinZ> you are still using §, so you cannot expect it to work
07:05 < mrapple> and it's not as simple as updating, we have thousands of custom messages and using the "text" attribute is by far the easiest and most efficent
07:05 < Drainedsoul> then write a parser to transform the old stuff into the new stuff
07:06 < Eviltechie> very curious to see how bukkit will handle all this
07:06 < mrapple> Grum: you can't deny that's a bug. text is still supported, it shouldn't randomly be broken in 1.7
07:07 < SinZ> obviously it isn't supported
07:07 < mrapple> if it isn't supported why is it in the spec dinnerbone posted?
07:07 < Drainedsoul> Saying that something the mod community uses is "supported" in Minecraft belies the true nature of Minecraft
07:07 < mrapple> and not marked as unsupported/deprecated
07:08 < SinZ> using text is fine, but using it with §colour codes isn't
07:10 < mrapple> you're using an unintentional bug to justify the breaking of a supported feature
07:11 < Drainedsoul> I'm pretty sure Mojang doesn't support "features" that the vanilla server/client don't use
07:16 < mrapple> Drainedsoul: looks supported to me http://cl.ly/image/1I3c1i2J3N1K
07:17 < Drainedsoul> how does that prove anything?
07:17 < mrapple> you just said the vanilla server/client don't use it
07:17 < Drainedsoul> they use JSON
07:18 < SinZ> mrapple: tellraw, so its user error
07:18 < Drainedsoul> ^
07:18 < mrapple> ....
07:18 < mrapple> user error?
07:18 < mrapple> the result does not match the expected result of a supported feature
07:18 < mrapple> therefor, bug
07:18 < SinZ> {"colour" : "green", "text" : "Hello world!"}
07:19 < mrapple> that is a working equivilant, however, that does not mean the alternative (which is still correct) should not work
07:19 < Drainedsoul> I don't see what the argument is about.  Grum told you that it's working as intended.  You're saying that Mojang supports this feature when Grum is telling you that either: A. They don't. B. They support it in the state it's in.
07:20 < Drainedsoul> instead of getting angry about things that you can't change, you should go write a parser to transform the section sign escapes into JSON
07:20 < Drainedsoul> or just use JSON in the first place
07:21 < mrapple> this is so that grum does not write this off as a non-issue by mistake
07:22 < Drainedsoul> {"text":[{"text":["Drainedsoul"],"bold":true},{"text":[": "],"bold":true}]} <== could someone tell me why the client dislikes this (i.e. crashes), I'm reasonably sure this was valid in 1.6.4
07:22 < mrapple> text can not be an array
07:39 < Valin> SinZ: 
07:39 < Valin> if you aren't supposed to use the color escape sequence
07:39 < Valin> how are you supposed to do multiple colors in a message?
07:39 < Valin> or can you just not?
07:40 < Drainedsoul> by using JSON?
07:40 < Valin> how?
07:40 < Valin> https://gist.github.com/Dinnerbone/5631634
07:41 < Valin> that's the only examples I've seen and there is not one that has multiple colors on the same line
07:41 < Drainedsoul> https://gist.github.com/thinkofdeath/e882ce057ed83bac0a1c#file-gistfile1-js-L55
07:41 < Drainedsoul> https://gist.github.com/thinkofdeath/e882ce057ed83bac0a1c#file-gistfile1-js-L15 *
07:41 < Drainedsoul> sorry, wrong line number
07:41 < SinZ> { "text" : [ {"colour" : "green","text" : "SinZ"}, {"colour" :"red","text" : "ational"}]} should work
07:42 < SinZ> untested though
07:42 < Drainedsoul> that won't work
07:42 < Drainedsoul> {"text":"",extra:[<everything from SinZ's "text">]} should though
07:42 < Drainedsoul> *"extra"
07:42 < Drainedsoul> also untested
07:42 < Drainedsoul> but I just had the 1.7.1 client crash on me for trying to send an array in "text"
07:43 < Drainedsoul> even though iirc the 1.6.4 client was totally fine w/it
07:48 < Valin> Drainedsoul: so an equivalent to the string "plain $cred $agreen $9blue" would be
07:48 < Valin> {"text": "plain ", "extra": [{"color": "red", "text": "red "}, {"color": "green", "text": "green "}, {"color": "blue", "text": "blue"}]}
07:48 < Drainedsoul> as far as I know, yes
08:09 < Grum> <mrapple> Grum: you can't deny that's a bug. text is still supported, it shouldn't randomly be broken in 1.7 <-- yes it is
08:10 < Grum> (randomly broken)
08:10 < Grum> its not a bug
08:10 < Grum> mrapple: you can still send the old colors for now, this will go away
08:10 < Grum> but as you noticed they give some issues
08:11 < Grum> issues we do not care for
08:11 < Grum> use the new way and you will not have those issues
09:11 < Not-001> [MCPP] RobertLeahy pushed 14 commits to 1_7_protocol [+0/-0/±30] http://git.io/JRtm7g
09:11 < Not-001> [MCPP] RobertLeahy 5934bd4 - Variant Alignment
09:11 < Not-001> [MCPP] RobertLeahy c66ed45 - Authentication Update
09:11 < Not-001> [MCPP] RobertLeahy 75ed861 - Time Update/Cleanup
09:11 < Not-001> [MCPP] RobertLeahy aa4dcf5 - Yggdrasil Cleanup
09:11 < Not-001> [MCPP] RobertLeahy 2ac447c - Client Logging and Receive Fix
09:11 < Not-001> [MCPP] RobertLeahy 7407926 - ClientList and ClientListIterator Fixes/Cleanup
09:11 < Not-001> [MCPP] RobertLeahy bdce808 - Packets Update
09:11 < Not-001> [MCPP] RobertLeahy 0c5c3a6 - Server Status - Formatting Fix
09:11 < Not-001> [MCPP] RobertLeahy 6b8c026 - Favicon Fix
09:12 < Not-001> [MCPP] RobertLeahy 2c5c3b1 - Chat Update
09:12 < Not-001> [MCPP] RobertLeahy 722e810 - Basic Chat Overhaul
09:12 < Not-001> [MCPP] RobertLeahy e9a8516 - Time Cleanup
09:12 < Not-001> [MCPP] RobertLeahy 0be6207 - World Update
09:12 < Not-001> [MCPP] RobertLeahy 9a45475 - Player Update
09:18 < SinZ> all the commits
09:18 < BizarreCake> How's encryption done in 1.7? The shared secret isn't sent anymore by the client.
09:20 < Drainedsoul> yes it is
09:20 < BizarreCake> It sends the public key back
09:20 < Drainedsoul> it definitely actually sends a shared secret
09:21 < Drainedsoul> the labeling of stuff in the login section of the prerelease protocol documentation is kind of haywire
09:21 < BizarreCake> Oh, I see
09:21 < BizarreCake> Thanks
09:21 < Drainedsoul> :]
09:23 < Paprikachu> is the minecraft 1.7 protocol still that retarded?
09:32 < Drainedsoul> retarded in what way, specifically?
09:33 < Paprikachu> not implementable in an async way efficiently, wrong datatypes, etc
09:33 < Drainedsoul> how was the previous protocol not implementable in an async way
09:33 < Paprikachu> > efficiently
09:34 < Drainedsoul> okay go on
09:34 < Paprikachu> variable length everything...
09:34 < Drainedsoul> you could build packets incrementally
09:35 < Paprikachu> requires reallocations and scattering of async operations
09:35 < Drainedsoul> what
09:36 < Paprikachu> ideally, there would be a fixed length header, followed by variable length data ...
09:36 < Drainedsoul> yeah, there is now.  I still don't understand your complaints wrt the previous protocol
09:36 < l4mRh4X0r> from what I've heard that's how the new system is
09:36 < Paprikachu> http://wiki.vg/Pre-release_protocol#Packet_format
09:36 < l4mRh4X0r> Drainedsoul, you actually had to process the packet to know the length
09:36 < Paprikachu> seems like it isn't
09:36 < Paprikachu> VarInt
09:37 < Drainedsoul> okay, how does that relate to his complaints
09:38 < Paprikachu> here's the thing, with variable length data, you have shittons of async handlers, for every thing that is variable in length
09:38 < Drainedsoul> wut
09:38 < l4mRh4X0r> Paprikachu, or just parse the packet and *then* pass it to a handler?
09:38 < l4mRh4X0r> As in, parse the length
09:38 < Drainedsoul> you get an asynchronous callback when you receive data, you check for a complete varint, if there isn't one, you pass
09:38 < Drainedsoul> if there is, you parse it, if there's that amount of data, you parse the whole packet, otherwise you pass
09:39 < Paprikachu> i hope you're not gonna argue with me that read(header_size) followed by read(header.packet_length) is more efficient than readVarInt() readVarInt() readVarInt() readWhatever() ...
09:40 < Drainedsoul> Are you really going to get bent out of shape about checking to see if there's a complete varint
09:40 < Valin> Paprikachu is right
09:40 < Drainedsoul> oh no I have to scan 5 bytes on a modern x86 CPU, this is going to drag my whole program down
09:40 < Valin> incremental reads aren't challenging, but they're terrible for high performance
09:40 < Paprikachu> you don't seem to understand
09:40 < Valin> you'll cause memory fragmentation that way
09:40 < Valin> and incurs more function calls, also expensive
09:41 < Valin> also nicer for modders because you can listen to only the packetids you're interested in
09:41 < Drainedsoul> how can't you do that now?
09:41 < Valin> otherwise you have to parse the entire protocol for say, a chat bot even if you only care about the 10 packets needed to log in and not get kicked, + chat
09:41 < Drainedsoul> yeah you don't have to do that.  there's length headers.  Skip the packets you don't care about
09:41 < Valin> well, you can now
09:41 < Valin> you couldn't before 1.7
09:41 < Valin> no length headers
09:42 < Drainedsoul> yeah we weren't talking about before 1.7
09:42 < Drainedsoul> he was complaining about checking for a complete varint
09:42 < Valin> I was referring to Paprikachu's comments
09:42 < Paprikachu> reading a header should be like 5 read calls
09:42 < Valin> 1.6 vs 1.7 protocol
09:42 < Paprikachu> i haven't counted them
09:42 < Paprikachu> but readint a varint is 2 calls
09:42 < Paprikachu> *reading
09:42 < Valin> Paprikachu: only two read calls
09:42 < Valin> read(3) (packet id + short length)
09:43 < Valin> read(length)
09:43 < Paprikachu> Includes the type's length  <<< fair enough
09:43 < Paprikachu> sounds alright then
09:44 < Paprikachu> except the length isn't a short
09:44 < Valin> w/e it is, I haven't looked at 1.7 yet
09:44 < Paprikachu> how is a 'VarInt' represented?
09:44 < l4mRh4X0r> https://developers.google.com/protocol-buffers/docs/encoding#varints
09:44 < Drainedsoul> it's a sequence of bytes.  If the MSB is set, you have to read another byte.
09:44 < Drainedsoul> also links to protobuf docs work
09:44 < l4mRh4X0r> Apparently like that.
09:45 < Paprikachu> that sounds incredibly stupid for a header
09:45 < Valin> ah, pb
09:45 < Valin> no, it makes sense
09:45 < Valin> most packets will fit in one byte
09:45 < Valin> larger packets might need more than that
09:45 < Valin> mainly chunk packet
09:45 < Paprikachu> it's slow
09:45 < Valin> 0x26 MapChunkBulk
09:45 < Paprikachu> because you might need multiple read calls
09:46 < l4mRh4X0r> Paprikachu, you won't for the majority of packets though
09:46 < Paprikachu> and you have to store your progress of reading somewhere
09:46 < Paprikachu> especially if async
09:46 < Valin> yeah, that's true
09:46 < Drainedsoul> what is this guy talking about
09:46 < Valin> didn't think about the read calls
09:46 < Valin> Drainedsoul: he's talking about high performance networking
09:46 < Valin> if you don't understand it's probably way over your head
09:46 < Valin> no offense intended
09:46 < Drainedsoul> lol
09:46 < Drainedsoul> okay dude
09:46 < dx> lol
09:47 < l4mRh4X0r> It's kinda funny though
09:47 < l4mRh4X0r> Minecraft and high performance
09:47 < Valin> yeah, it's a moot discussion to 99.9% of people
09:47 < Valin> and besides high performance the minecraft protocol is just a mess anyway
09:47 < Paprikachu> there's no reason a high performance server wouldn't be able to handle, say, 2k concurrent users
09:47 < Valin> 2k? lol
09:47 < Valin> that's tiny
09:47 < Paprikachu> yeah, i know
09:48 < l4mRh4X0r> Not with the vanilla server.
09:48 < Valin> 'high performance' means the c10k problem or higher
09:48 < Paprikachu> but look at the vanilla server
09:48 < Valin> pretty much
09:48 < Flemmard`> Paprikachu: i think protocol is not the thing that will hold you off
09:48 < Paprikachu> it cant even handle much more than 200 on a huge machine
09:48 < Valin> Paprikachu: pm
09:48 < Flemmard`> but chunk management and all that shit
09:48 < dx> well tbh thinking about the protocol as a sequence of readType() only makes sense if you dedicate a thread for reading
09:48 < Flemmard`> the protocol itself is a tiny bit of all that ..
09:48 < Drainedsoul> if you dedicate a thread for reading, you're not doing "high performance networking"
09:49 < dx> yeah
09:49 < Drainedsoul> I still don't understand what "read" he's talking about in the context of high performance networking
09:49 < Paprikachu> read is just symbolic, can be an async read as well
09:50 < Drainedsoul> your async read returns a bunch of data, you look at it and say "okay no varint here" and you come back to it after the next read.  You have this problem fixed length headers or not
09:50 < Drainedsoul> because what happens if you get 1.5 packets, or 2 packets, or 0.5 packets
09:50 < Valin> Drainedsoul: because now you have to store state
09:50 < Valin> with varints
09:50 < Valin> and you can't preallocate a flat buffer
09:50 < Valin> so you get segmentation
09:51 < Valin> it shouldn't be a major problem, but it does make the code slightly more complicated
09:51 < Valin> and you really don't save many bytes
09:51 < Valin> either way it's not significant though
09:51 < Drainedsoul> so reuse the same buffer on a per client basis, eventually the buffer's size stabilizes
09:52 < Drainedsoul> getting mad about parsing 5 bytes for a varint is ridiculous.  The time it takes to parse those 5 bytes is noise compared to the time it takes to drag the first one into L1 cache
09:52 < Drainedsoul> and when you get the first one in L1 cache, you get all 5
09:53 < Drainedsoul> you may as well get mad that the integers are BE and you have to reverse the bytes
09:53 < Paprikachu> talking about performance, does the protocol still use tcp?
09:53 < Drainedsoul> yes
09:53 < Paprikachu> ugh
09:54 < l4mRh4X0r> Isn't TCP what you want though, except perhaps for position updates?
09:54 < Valin> yeah, that's exactly what you want
09:54 < Valin> movement updates over UDP, TCP for everything else
09:55 < Paprikachu> TCP is conceptually broken, that's the problem
09:55 < Valin> same form pretty much every FPS has used since the dawn of time
09:55 < Drainedsoul> using a high reliability protocol for things that will be irrelevant after retransmits is dumb
09:55 < l4mRh4X0r> Hmm, glad to hear I'm still sane :P
09:58 < Paprikachu> you should take a look at SCTP
09:58 < Paprikachu> it's the only sane protocol for reliable transmition right now
09:58 < l4mRh4X0r> Hmm, never heard of it. Might be interesting to look into, thanks :)
09:58 < Paprikachu> sadly it's not supported on windows
09:59 < l4mRh4X0r> who the fuck uses windows anyway? :P
09:59 < Paprikachu> people who play minecraft
09:59 <+AndrewPH> Paprikachu: if I'm reading this correctly, it's usable via udp
09:59 <+AndrewPH> if native support isn't available
09:59 < Paprikachu> i haven't looked into that tbh
10:00 < Paprikachu> might very well be possible
10:00 < Paprikachu> there are drivers for windows, but forcing a user to install a driver just for sctp is kinda meh
10:01 <+AndrewPH> according to le wikiped "In the absence of native SCTP support in operating systems it is possible to tunnel SCTP over UDP,[3] as well as mapping TCP API calls to SCTP ones.[4]"
10:02 <+AndrewPH> wonder what performance would be like
10:03 < Paprikachu> switching from tcp to sctp won't really help, networking code needs to be redesigned to fully take advantage of sctp
10:04 < Thinkofdeath> Drainedsoul: Bad copy and paste, fixed it http://wiki.vg/Pre-release_protocol#Chat_Message_2
10:05 < Paprikachu> one reason tcp is so bad is the stream-like nature of it
10:06 < Paprikachu> it forces applications to introduce message boundaries, thus introducing overhead not only in parsing, but also with head of line blocking: http://en.wikipedia.org/wiki/Head-of-line_blocking
10:07 < Valdiralita> Paprikachu, it seems like youre against everything :p
10:07 < Paprikachu> TCP is just conceptually wrong
10:07 < Drainedsoul> Thinkofdeath: Now that you're around, did you see my message about ChatMessage from the client to the server?
10:07 < Drainedsoul> it's marked as containing JSON data, but it doesn't?  Is there something I'm missing?
10:07 < Thinkofdeath> Just fixed it
10:08 < Drainedsoul> okay cool, thanks
10:08 < Drainedsoul> I was going to fix it myself, but didn't want to tread on toes if you'd discovered something I wasn't aware of
10:08 < Thinkofdeath> Copy and pasted it from S->C and forgot to change it :P
10:08 < Valin> Paprikachu: tcp isn't wrong, just isn't optimal for this use case
10:08 < Paprikachu> tcp is almost always wrong, because networking is not a stream of bytes
10:09 < Paprikachu> it's a bunch of messages that do not necessarily have a relevant order
10:10 < Paprikachu> sctp has a concepts of channels, where messages are sequenced only on those channels, but there is no global sequencing of messages
10:10 < Paprikachu> additionally a message can also be completely unsequenced
10:11 < Paprikachu> that's useful for async events for example.
10:13 < Paprikachu> "player A breaks block (x, y, z)" could be such an event
10:14 < Paprikachu> it doesn't matter if this event is delivered before or after the event "player B breaks block (x2, y2, z2)", you just care that it be delivered
10:22 < Paprikachu> http://en.wikipedia.org/wiki/Transport_layer#Comparison_of_transport-layer_protocols
10:23 <+md_5> sctp is nice
13:59 < Dinnerbone> dividuum: your issue with authenticating should be fixed
13:59 < dividuum> really? awesome!
14:00 < Dinnerbone> You hit the limit of client tokens and it was revoking the most recent instead of the oldest
14:01 < dividuum> works perfect!
14:01 < dividuum> thanks so much :-)
14:02 < Paprikachu> hey Dinnerbone, are there any plans to rewrite the server?
14:03 < dividuum> Rewrite the server?
14:03 < Paprikachu> the vanilla server...
14:04 < xy> Paprikachu: rewrite as in completely redo?
14:04 < Paprikachu> well, redo what needs to be redone to make it faster
14:05 < xy> the vanilla server is pretty fast as it is right now
14:05 < xy> never had issues with vanilla servers lagging
14:05 < Paprikachu> bukkit is built on top of it
14:06 < Paprikachu> it inherits the design flaws
14:06 < dividuum> flaws like?
14:06 < Paprikachu> being single-threaded
14:07 < dividuum> you can use multiple threads in bukkit. You just have to smart about it
14:07 < Dinnerbone> It needs more synergy.
14:07 < Paprikachu> how come most bukkit servers cannot handle more than ~200 users
14:08 < Paprikachu> i doubt its a plugin issue
14:08 < dividuum> did you profile it?
14:09 < Paprikachu> am i supposed to do others' work?
14:09 < xy> i think the real large servers use spigot anyway
14:09 <+AndrewPH> the real large servers are also networks behind bungee usually I believe
14:09 < xy> and bungeecord to split the user load onto multiple spigot instances
14:09 < xy> fff AndrewPH you were faster 
14:09 <+AndrewPH> ^ yeah
14:10 < Paprikachu> never heard of spigot
14:10 <+AndrewPH> it's a thing
14:10 <+AndrewPH> does some stuff
14:10 < dividuum> Just wondering, how many users can bungee handle?
14:10 < xy> theoretically unlimited, afaik
14:11 < Paprikachu> just wondering, does chunk generation use multiple threads?
14:11 < xy> bungee itself doesn't do very much cpu-heavy work
14:12 < dividuum> yeah. I read a little bit of its source. I liked that entity id remapped :-}
14:12 < dividuum> with 1.7 it should be even faster i guess, since not every packet has to be inspected
14:12 < xy> bungee is not going to be the bottleneck, something like bandwith or the server instances behind it will
14:14 < mrapple> Grum: alright, sounds fine (in regards to text colors)
14:14 < mrapple> also, were the race condition fixes pushed?
14:14 < Paprikachu> tbh i think just rewriting the server in c++ would solve a lot of performance issues
14:15 < Thinkofdeath> mrapple: Not yet
14:17 < Paprikachu> why can't just the whole game be rewritten in c++, pc is the only platform stuck with java
14:18 <+AndrewPH> because it would take a lot of time and minecraft's fans aren't the most patient
14:18 <+AndrewPH> + it would completely break compatibility with literally every client/server mod out there.
14:18 < Paprikachu> it can be done in parallel.
14:18 < dividuum> also c++ is not magically faster
14:19 < Paprikachu> uhh, yes it is
14:19 <+AndrewPH> no, not magically
14:19 < mrapple> Dinnerbone: have you and grum discussed 1.7.1 ninja update vs 1.7.2?
14:19 < Paprikachu> define magically
14:19 <+AndrewPH> something written in c++ can be slower than something written in java
14:19 < dividuum> do the authservers support jsonp by any chance?
14:20 < Grum> 1.7.2
14:20 < Grum> compiling now
14:21 < Grum> Paprikachu: here, some clue
14:21  * Grum opens a can of clue and pours it over Paprikachu
14:21 < Paprikachu> aha
14:22 < Cubix> Paprikachu: performance problems aren't caused by java
14:22 < Cubix> main reason is that server is single-threaded
14:22 < mrapple> Grum: cool, thanks
14:22 < Cubix> so people use proxies (eg. bungeecord) to scale to multiple cores/machines
14:24 < nickelpro> Also there is simply a limit as to what can realistically be done on a single machine when it comes to peristant world/MMO-like structure. 200 simultaneous users isn't bad
14:24 < Paprikachu> 200 simulateneous users is terrible
14:24 < nickelpro> Nop
14:25 < Paprikachu> multiply that by 10
14:25 < nickelpro> 2000 users would crash your average EVE node
14:25 < Paprikachu> what's an even node?
14:25 <+AndrewPH> EVE online is a very popular spreadsheet program
14:25 < nickelpro> lol
14:25 < Paprikachu> please...
14:26 < nickelpro> It's a massive persistent world MMO
14:26 <+AndrewPH> ^ and it's very statistics based
14:26 < Paprikachu> what is a 'node'?
14:26 < nickelpro> A single server instance
14:26 < Paprikachu> and what does 'average' mean
14:27 < Paprikachu> what is an average node
14:27 < nickelpro> Popular nodes with lots of users are beefier than small remote nodes that no one visists
14:27 < Paprikachu> i mean like what kind of hardware
14:27 < Paprikachu> how much is average
14:28 < nickelpro> lolwat? You asking me what EVE's hardware setup looks like? I'm not in their datacenter
14:29 < Paprikachu> you said [14:28:11] <nickelpro> 2000 users would crash your average EVE node
14:29 < nickelpro> Ya, it would
14:29 < Paprikachu> so clearly there's gotta be a definition of average
14:29 < Paprikachu> otherwise the question arises: how do you know?
14:29 < nickelpro> Their average node handles at most a couple hundred players, and not without slowdowns
14:30 < nickelpro> Because I play EVE?
14:30 < Paprikachu> ...
14:30 <+AndrewPH> Paprikachu: Asking questions whose answers are unimportant to the subject is useless btw. EVE online is a pretty massive and pretty popular online game, they're not running it on p3's.
14:31 <+AndrewPH> it's a massive game, and the average node wouldn't be able to handle 2000 players at a time.
14:32 < Paprikachu> great, i'm sure a minecraft server could if done correctly
14:32 < nickelpro> Also worth mentioning is most of the game is written in Python, multithreading is provided by tasklets. C++ isn't an automatic answer
14:32 < Paprikachu> lol python
14:32 < Flemmard`> and that server doesnt send the maps?
14:33 < Paprikachu> maps do not have to be server generated, for example.
14:33 < Flemmard`> still need to send them
14:33 < Paprikachu> distribute the work on clients.
14:33 < Flemmard`> a minecraft without that would be like useless
14:33 < nickelpro> Paprikachu: Wat? Malicious clients could affect world gen
14:34 < nickelpro> Never trust a client
14:34 < zutto> ^is a good policy
14:34 < Paprikachu> assign a task to multiple clients and exchange hashes.
14:34 < zutto> never trust anything but your own servers
14:34 <+AndrewPH> Paprikachu: multiple clients that are working together to send invalid data
14:34 < Paprikachu> also, never send full chunks
14:34 < Paprikachu> only transmit differences to the original
14:35 < Paprikachu> AndrewPH: im just giving ideas, not saying that there's no problem
14:35 < nickelpro> You want clients to store chunk deltas?
14:35 < Paprikachu> clients *could* store the original chunks, servers send deltas.
14:36 < nickelpro> Eh... I guess you might have slightly less network usage, not enough to make any real difference
14:36 < Paprikachu> there'd be a way to query the originals
14:36 < Paprikachu> yes it would make a difference
14:36 < nickelpro> The majority of latency comes from the way the vanilla client handles networking and inherent TCP lagginess
14:36 < Paprikachu> because suddenly most of the chunk data just becomes zeroes
14:36 < nickelpro> vanilla server*
14:36 < Paprikachu> and lots of zeroes can be compress very well.
14:37 < Paprikachu> *compressed
14:37 < Paprikachu> yes, TCP is also a problem, ofc
14:37 <+AndrewPH> udp movement would be magical
14:37 < dividuum> so just I understand that correct: you want the server to do more work (generating delta) so the server uses less cpu!?
14:37 < nickelpro> Ya, it wouldn't be efficient
14:38 < Paprikachu> deltas can be stored as well as originals.
14:38 < nickelpro> Sending chunks is a tiny fraction of the network load anyway
14:38 < zutto> network load is the least of your problems with minecraft
14:38 < nickelpro> Ya
14:38 < zutto> that can be easily load balanced
14:38 <+AndrewPH> remember when the ping packet was sent exponentially based on how many users were on lol
14:39 < nickelpro> On Spigot you're realistically limited by the entity thread more than anything else, and chunk loading on the server
14:39 < Paprikachu> chunk generation should use multiple threads
14:39 < nickelpro> It's not generation that's the problem
14:40 < Paprikachu> so what is the problem?
14:40 < nickelpro> You do generation once, on sufficiently large worlds, or pre-generated worlds, that stops being a problem fast
14:40 < Cubix> most servers pregenerate map anyway.
14:40 < nickelpro> loading chunks from disk is the problem
14:40 <+AndrewPH> a little of everything is the problem really
14:41 < nickelpro> Eh. chunk loading and the entity thread are our two main bottlenecks for single server performance ATM
14:41 < Paprikachu> who's 'you'?
14:41 < nickelpro> Minecraft server owners?
14:42 < Paprikachu> what's the entity thread?
14:42 < nickelpro> Thread that moves entities around
14:43 < Paprikachu> does it also calculate AI?
14:43 < nickelpro> The reason you can lag a server to death with enough chickens
14:43 < nickelpro> Anyway I have work, cya guys
14:44 < Cubix> cya ;)
14:44 < Cubix> paprikachu: yeah, it does ai
14:44 < Paprikachu> i think it might be an improvement to have one thread per world then
14:45 < Cubix> maybe a little, but in most cases main world is biggest
14:45 < Cubix> coroutines per chunk would be a nice idea
14:46 < Paprikachu> you can't really use threads on smaller "units" than worlds
14:46 < Cubix> i thought about rewriting server in go, but game is constantly evolving and keeping alternative server up-to-date would be a problem
14:46 < Cubix> paprikachu, coroutines, not threads.
14:46 < Paprikachu> how would coroutines be any better?
14:46 < Cubix> coroutines are light
14:47 < Paprikachu> they don't actually run in parallel...
14:47 < Cubix> they don't have to
14:47 < Cubix> just multiplex them on many threads
14:47 < Paprikachu> that's no different from just using multiple threads directly
14:48 < Cubix> it's simpler and scales well
14:48 < Cubix> you dont have to write state machines
14:48 < Paprikachu> depends on what you want to parallelize
14:49 < Paprikachu> the problem is, at any point in any thread executing a task, you need a coherent state of the world that you can modify
14:49 < Paprikachu> otherwise there might be races and what not
14:49 < Cubix> you don't need coherent state
14:49 < Cubix> you need eventual consistency
14:49 < Cubix> entites can do their AI based on older state
14:49 < Cubix> 1 or 2 ticks from 'now'
14:50 < Cubix> it should really make a big difference
14:50 < Paprikachu> entities aren't really the problem
14:50 < Cubix> and event 5000 blocks away don't have to propagate instantly
14:50 < Paprikachu> what do you do about block updates?
14:50 < Cubix> chunks can communicate events between them, redstone activations etc
14:51 < Cubix> i don't see a problem
14:51 < Cubix> every chunk is coroutine, just send block update
14:51 < Paprikachu> what would send do?
14:52 < Cubix> you synchronize on channel/queue
14:52 < Paprikachu> you'd have a queue or something?
14:52 < Cubix> yup
14:52 < Cubix> play with erlang, go or gevent in python
14:52 < Paprikachu> when is this update gonne be executed?
14:53 < Cubix> when given chunk gets cpu time
14:53 < Cubix> probably instantly, depends on implementation
14:53 < Paprikachu> the problems i see are with consistency
14:53 < Paprikachu> let's say you're writing a plugin
14:53 < Paprikachu> on right clicking on a block it's checking if that block is a specific type
14:54 < Cubix> in specific conditions it may be a problem
14:54 < Paprikachu> another thread might at any type produce a block update to change that type
14:55 < Cubix> yeah, it could
14:55 < Paprikachu> decisions based on the conditions determined to be true might no longer be true afterwards
14:55 < Paprikachu> i think this is extremely problematic
14:56 < Cubix> i don't think so
14:56 < Paprikachu> i think parallelizaion needs to be done on the task level
14:56 < Cubix> you can always use locks on chunks
14:56 < Paprikachu> locks prevent concurrency
14:56 < Cubix> on chunks is not a problem
14:56 < Cubix> other chunks execute concurrently
14:57 < Paprikachu> that's not what i mean
14:57 < Cubix> so?
14:57 < Paprikachu> you have 2 threads executing 2 different event handlers
14:57 < Cubix> you always have to lock on some thing
14:57 < Paprikachu> both want to access the same block
14:57 < Paprikachu> one of them has to wait
14:57 < Cubix> so?
14:58 < Cubix> or dont use 'transactions' and work on older state of the world
14:58 < Paprikachu> because of this i think you cannot in general parallelize event handling
14:58 < Cubix> you can
14:58 < Paprikachu> single tasks could create multiple tasks
14:58 < Cubix> look
14:59 < Cubix> block updates could be fired in chunk's coroutines
14:59 < Cubix> so chunks wold not change
14:59 < Paprikachu> how do you get the type of a block from a chunk?
14:59 < Cubix> entity updates in each entity's coroutine etc
14:59 < Cubix> send a message and receive snapshot of chunk in given point in time
15:00 < Cubix> snapshot always would have a version
15:00 < Cubix> chunk keeps version counter
15:00 < Paprikachu> that sounds extremely hard to write a plugin for
15:00 < Cubix> nope
15:00 < Paprikachu> can you give me some pseudo code?
15:02 < Paprikachu> i can't really follow how this would work
15:05 < Paprikachu> just the the api
15:06 < Cubix> func chunkMainLoop {
15:06 < Cubix> 	cmd = recv_command_from_chunk_msg_queue()
15:06 < Cubix> 	if cmd.name == 'set_block' {
15:06 < Cubix> 		this.setBlock(cmd.x, cmd.y, cmd.z, cmd.block_type)
15:06 < Cubix> 		this.atomicallyIncrementVersionCounter()
15:06 < Cubix> 	}
15:06 < Cubix> 	if cmd.name == 'get_snapshot' {
15:06 < Cubix> 		data = new ChunkSnapshot(this)
15:06 < Cubix> 		cmd.sender.send(data)
15:06 < Cubix> 	}
15:06 < Cubix> }
15:06 < Cubix> you send messages to given chunk, each chunk has it's own main loop
15:06 < Cubix> it's just the loop body ofcourse
15:07 < Paprikachu> callers of get_snapshot would be coroutines that are suspended?
15:09 < Thinkofdeath> 1.7.2 is out, who wants to handle the move?
15:10 < Cubix> func sheepEntityEatGrassAction() {
15:10 < Cubix> 	chunk = this.location.getChunk()
15:10 < Cubix> 	snapshot = get_chunk_snapshot(chunk) // little helper method to skip all channel logic
15:10 < Cubix> 	location = find_nearest_grass_block(snapshot)
15:10 < Cubix> 	this.walkto(location)
15:10 < Cubix> 	err = chunk.tryReplaceBlock(snapshot.version, location, DIRT)
15:10 < Cubix> 	if err == CHUNK_VERSION_CHANGED {
15:10 < Cubix> 		// handle error
15:10 < Cubix> 		return
15:10 < Cubix> 	}
15:10 < Cubix> 	this.is_hungry = false
15:10 < Cubix> }
15:10 <+sadimusi> Cubix: please don't do that
15:11 < Paprikachu> what would world edit do?
15:11 < Paprikachu> let's say you're using //overlay
15:11 < Paprikachu> terrain changes inbetween
15:11 < Cubix> same thing or just use locks if it really has to have consistent sate
15:11 < Cubix> it't simple
15:12 < Thinkofdeath> http://wiki.vg/Pre-release_protocol#1.7.2
15:12 < Paprikachu> how are you so fast with the changes?
15:12 < dividuum> where does the minecraft server get the players uuid? It must be the /checkserver.jsp call, but i don't see that in there
15:13 < Paprikachu> Cubix: so tryReplaceBlock would be a blocking call?
15:13 < Dinnerbone> We don't checkserver.jsp, that's old auth
15:13 < dividuum> oops. ok
15:13 < Thinkofdeath> https://github.com/NetherrackDev/netherrack/blob/master/protocol/auth/auth.go#L58
15:13 < Thinkofdeath> Return {"id":"<uuid>"}
15:13 < dividuum> thanks
15:13 < Thinkofdeath> *returns
15:13 < Dinnerbone> I'd recommend using our AuthLib if you're in java
15:13 < dividuum> nope. python :-)
15:14 < Thinkofdeath> Moving Pre-release protocol‎ to Protocol is going to be fun
15:21 < Paprikachu> why is chunk loading in amplified worlds so bugged ;_;
15:24 < Paprikachu> Dinnerbone: any plans to fix the launcher on newer OS X versions to use java 7?
15:25 < Thinkofdeath> Paprikachu: Use the issue tracker, don't ping the devs
15:26 < Paprikachu> uh, issue tracker?
15:28 < Dinnerbone> The one we link to in the launcher and on the blogpost every single time we do an update. But nobody reads :D
15:28 < Dinnerbone> https://mojang.atlassian.net
15:28 < Paprikachu> oh, sorry, wasn't aware of that :p
16:14 < Thinkofdeath> http://wiki.vg/Protocol Updated (and most sub pages)
16:15 < Cubix> <3
16:15 < Thinkofdeath> Now for Protocol_Encryption
16:26 < Thinkofdeath> http://wiki.vg/Protocol_Encryption Should be ok now, the client parts need checking because I can't test them
16:33 <+fragmer> Oh hey I just noticed, the NBT format has been amended
16:33 <+fragmer> Time to update fNbt...
16:36 <+fragmer> Hm. The official changelog is rather vague. 
16:36 <+fragmer> "Improved the NBT format: List tags no longer need to be named"
16:37 <+fragmer> Not sure what that means.
16:37 <+fragmer> Dinnerbone, could you elaborate please? ^
16:38 < redstonehelper> jeb did that
16:38 < redstonehelper> I can get a link, one sec
16:39 < redstonehelper> (feel free to correct me if I fuck up on anything technical)
16:39 < redstonehelper> http://www.reddit.com/r/Minecraft/comments/1lnedb/twitter_jeb_after_hours_of_pain_jeb_has_finally/cc1hpaz?context=3
16:40 <+fragmer> thanks redstonehelper 
16:41 <+fragmer> Hm. I thought tags inside lists were required to be NOT named since the beginning
16:41 < Thinkofdeath> I think the change was for their JSON -> NBT converter
16:41 <+fragmer> ah
16:42 <+fragmer> Alright, so no changes to the NBT bitstream format. Thanks.
16:42 < Thinkofdeath> ench:[0:{id:16;lvl:2}] -> ench:[{id:16;lvl:2}]
16:58 <+fragmer> Hm. Perhaps I should add a JSON <-> NBT converter to my library.
17:10 < dividuum> Thinkofdeath, thanks for the updated documentation on the session servers. Works like a charm
17:10 < Thinkofdeath> :)
17:49 < lol768> Does anyone know where I can find documentation for the 1.7 server list ping request?
17:50 < lol768> Actually, found some at http://wiki.vg/Protocol#Status
18:13 < dividuum> Dinnerbone, would it be possible to add either JSONP or CORS headers to the auth server? that way i can to authenticate in javascript
18:14 < Dinnerbone> Not likely.
18:14 < dividuum> hm. for security reasons?
18:15 < Dinnerbone> I don't think we care much for supporting authentication through javascript.
18:17 < dividuum> that would be really useful in my case, because right now i request credentials. And i don't want to do that. Doing the authentication from javascript would solve that.
18:18 < dividuum> ( http://miners-movies.com/ )
18:19 < Dinnerbone> Yeah this is not something we want to support.
18:20 < dividuum> The perfect way would be some kind of openid flow where one could get the accessToken.
18:21 < dividuum> but i understand your point :}
18:24 < dividuum> looks like i'm stuck with requesting credentials :-\
18:29 < TkTech> dividuum: I was promised OpenID 3 years ago. Don't hold your breath.
18:29 < barneygale> Requesting credentials is a bad idea
18:30 < barneygale> You can use an auth server: https://github.com/barneygale/authserver
18:30 < barneygale> But that needs updating for 1.7, and unfortunately it now needs to support encryption
18:30 < TkTech> barneygale: Nix' it out of mc4p?
18:31 < barneygale> Yeah, I will
18:31 < TkTech> Actually, you could probably do all of this with mc4p if you wanted to save yourself work.
18:31 < TkTech> Implement mc4p plugin
18:31 < dividuum> barneygale, i already use that idea for authentication uses on the website. I just have a jump links that carries over the authenticated user to the website
18:32 < dividuum> the problem is, for my usecase i have to login to other servers on behalf of the user, so i can record
18:33 < dividuum> For that I either need the credentials or the accessToken
19:28 < barneygale> Anyone know the difference between 1.7.1 and 1.7.2? I guess it might be the network fix from ydasy
19:28 < barneygale> yday*
19:47 < Thinkofdeath> barneygale: http://wiki.vg/Protocol_History#1.7.2
19:47 < barneygale> ah
19:48 < barneygale> what were they previously?
19:48 < Thinkofdeath> VarInts
19:48 < barneygale> Hm, why the change I wonder?
19:48 < Thinkofdeath> VarInt are always 5 bytes with negative numbers
19:49 < Thinkofdeath> Kinda ruins the point of them in that case
19:49 < Thinkofdeath> Thats why they changed
19:50 < barneygale> fair enough
20:05 < Valdiralita> any chance for a burger vitrine update?
20:06 < Thinkofdeath> Valdiralita: The protocol changes are already updated
21:03 < Grum>  <Thinkofdeath> Thats why they changed <-- yeah i wanted to just up the version blindly, then i remember i could fix something for it ;)
21:04 < Thinkofdeath> Grum: :) It was a good thing to fix
21:06 < Thinkofdeath> Grum: Btw did you get anywere with packing block coords into a long?
21:08 < Grum> i wrote the code for it. nothing uses it
21:47 < TkTech> Valdiralita: I believe sadimusi is very busy.
21:47 < Valdiralita> ah okay
23:02 < iBotPeaches> Thinkofdeath: Do you have happen to have the implementation of reading the VarInt on hand? 
23:02 < Thinkofdeath> iBotPeaches: https://gist.github.com/thinkofdeath/e975ddee04e9c87faf22
23:02 < iBotPeaches> Thinkofdeath: thanks
23:15 < iBotPeaches> Okay, maybe im not understanding this correctly. Is the 2nd VarInt (1st being size), the type like whether its a handshake/play/status/login packet or something else
23:16 < Thinkofdeath> Packet ID
23:16 < Thinkofdeath> Which packet depends on the current state
23:17 < iBotPeaches> ah, which was my next question
23:17 < iBotPeaches> I guess I need to move some things around so I can detect that, since currently I used to treat all packets the same way
23:17 < Thinkofdeath> Starting state is Handshaking
23:18 < Thinkofdeath> From there its Status (1) or Login (2)
23:19 < iBotPeaches> ah, then if Login is completed you move to Play then
23:19 < Thinkofdeath> Yep
23:45 < iBotPeaches> Thinkofdeath: thanks :) all is working now, besides a hiccup until I realized UTF16 seems to be UTF8 now
23:45 < Thinkofdeath> Yeah that was on the pre release page, got dropped in the move over to the main page :P
23:46 < Thinkofdeath> I did put it on here though http://wiki.vg/Data_types
23:47 < Valin> hi
23:47 < Valin> does 1.7 have support for resourcepacks changing the sky texture/color?
23:48 < Thinkofdeath> Not last time I checked
--- Day changed sam. oct. 26 2013
00:05 < Not-001> [fCraft] fragmer * r2245 4 files : Documentation improvements in Heartbeat.cs. Also, renamed "Uri"s to "Url"s in the API.
00:05 < Not-001> [fCraft] fragmer * r2246 2 files : fCraft now sets the default spawn point 1 block above the highest non-air block on the map, instead of the very top of the map.
00:06 < Not-001> [fCraft] fragmer * r2247 7 files : Sporadic documentation improvements.
00:12 < JonasOSDever> Hello
00:12 < JonasOSDever> I have a question about the 1.7.2 protocol
00:12 < JonasOSDever> Some Packets use varints
00:13 < JonasOSDever> I looked at the link to be found at the wiki.vg page about the data types, but I still don't understand what way I have to encode/decode the numbers
00:14 < JonasOSDever> The example uses 300 to show how to decode it: 1010 1100 0000 0010. I'm not quite fimilar with that big/little-endian stuff, but I think this is little endian
00:14 < JonasOSDever> And Minecraft uses big endian. So how is it transmitted then
00:14 < JonasOSDever> 0000 0010 1010 1100
00:14 < JonasOSDever> In reversed byte order?
00:15 < Thinkofdeath> https://gist.github.com/thinkofdeath/e975ddee04e9c87faf22
00:15 < Thinkofdeath> ^ From minecraft's code
00:15 < JonasOSDever> Thank you very much
00:58 <+sadimusi> Valdiralita: I probably have to rewrite Burger completely, and right now I just don't have the time
00:59 < Valdiralita> okok, thanks anyway!
01:01 <+sadimusi> :D marvel doesn't seem to get minecraft
01:01  * sadimusi looks for youtube clip of the scene
01:01 <+sadimusi> there http://youtu.be/F_QDFf-WTVw
01:03 < Not-001> [Craft.Net] SirCmpwn pushed 4 commits to 1.7.x [+1/-0/±10] http://git.io/2VkD9w
01:04 < Not-001> [Craft.Net] SirCmpwn 244ad1e - Add VarInt methods to MinecraftStream
01:04 < Not-001> [Craft.Net] SirCmpwn 0f4955e - Rework PacketReader to support multiple network modes
01:04 < Not-001> [Craft.Net] SirCmpwn aff5dba - Update README
01:04 < Not-001> [Craft.Net] SirCmpwn c7a45f4 - Modified network infrastructure a bit
04:21 < cnlohr> hey, anyone who is familiar with the wiki.vg/Protocol site, if you can, give me a heads up...
04:29 < cnlohr> I'm trying to update my avrcraft server, but, the protocol is confusing... It says "Packets are not prefixed with their length." however that is defined...
04:34 < zml> cnlohr: that's old. Packets do have their length prefixed now.
05:00 < Jailout2000> I hear there's a packet length descriptor now. This makes things a lot more interesting.
05:27 < cnlohr> yaeh... Unfortunately for me, while this makes the protocol 100x better, it makes it 2x worse for me... I only have ~1kB of ram I have to do everything in.  I have to store packets to RAM before sending them now.
05:27 < cnlohr> Also
05:27 < cnlohr> I don't understand how a client exits a given state
05:27 < nickelpro> cnlohr: What do you mean?
05:28 < cnlohr> Well, client sends server packet ID 0x00, with a next state set...
05:28 < cnlohr> but in any given state, how does it change the state again/
05:29 < nickelpro> 0x00 is a keepalive
05:29 < cnlohr> I am certainly getting 0x00's that resemble the handshake 
05:29 < nickelpro> It's both now
05:29 < cnlohr> o.O
05:30 < cnlohr> how's that work?
05:30 < cnlohr> Is 0x02 the state the client/server stays in all the time when playing?
05:30 < nickelpro> everything that's not a handshake or a status ping is a keepalive
05:31 < nickelpro> 0x02 just says "This packet is requesting a handshake
05:31 < nickelpro> "
05:31 < nickelpro> 0x01 says "This packet is requesting a status ping"
05:31 < cnlohr> let's back up a moment
05:32 < cnlohr> upon a new connection, I place the server into "mode 0" I then receive a packet 0x00, which tells me to go to "mode 1" or "mode 2"
05:32 < cnlohr> correct?
05:32 < nickelpro> Sorta, sure, that's a little convoluted though
05:33 < cnlohr> so... is mode 0x02 what everything lives in?
05:33 < nickelpro> Think of it like this, client connects to server and sends a 0x00 handshake
05:33 < nickelpro> if the 'Next State' field is 0x01 the client is requesting a status ping
05:34 < cnlohr> alright
05:34 < nickelpro> if the 'Next State' field is 0x02, the client is requesting to login
05:34 < cnlohr> ok
05:34 < cnlohr> now, that it wants a login, I send it one 
05:34 < cnlohr> now... what should I be expecting?
05:35 < cnlohr> well
05:35 < cnlohr> wait
05:35 < cnlohr> if it's a 0x02, I should be expecting a cmd0x00 to tell it to send the login?
05:35 < nickelpro> http://wiki.vg/Protocol_Encryption
05:36 < nickelpro> Handshake -> Login start -> encryption dance