03:30 < Drainedsoul> :P
03:30 < nickelpro> struct { enum type_id; union { TYPES_HERE} }; Variant done
03:31 < Drainedsoul> yeah enjoy implementing that from scratch every time you need it
03:32 < nickelpro> And if you look sideways and squint it's you can almost read it
03:33 < nickelpro> Ya I just through anonymous structs and unions and problems like that and say "NANANANA ITS A FRAMEWORK NOT MY PROBLEM"
03:33 < nickelpro> throw* not through, fuck how did I even do that
03:35 < Drainedsoul> lol
04:09 <+sadimusi> whoops wrong again
04:09 < GauHelldragon> oh my
04:09 <+sadimusi> sorry for the spam
04:09 < GauHelldragon> don't give up
04:09 < GauHelldragon> i believe in you
04:11 < Drainedsoul> bad internet, what an egregious offense /s
04:11 < Drainedsoul> he ought to be drawn and quartered at the least
04:13  * GauHelldragon draws a portrait of ajf and charges him 25 cents
04:14 < dx> it's a channel redirect, not really a ban
04:15 < GauHelldragon> neat, didn't know you could do that
04:15 < dx> only in freenode, although i think esper has the same ircd
04:16 < GauHelldragon> i see
04:16 < dx> ah, esper has charybdis, freenode has a fork of it
04:19 < Drainedsoul> I hate when things are almost useful
04:20 < dx> ?
04:20 < Drainedsoul> http://en.cppreference.com/w/cpp/numeric/random/random_device
04:20 < Drainedsoul> "[...] std::random_device may be implemented in terms of a pseudo-random number engine [...]"
04:20 < Drainedsoul> almost useful
04:20 < dx> uhh, that doesn't really mean anything
04:20 < dx> /dev/urandom is pseudo-random too
04:21 < Drainedsoul> sure
04:21 < Drainedsoul> but it doesn't mean that it is suitable to use for things like cryptography
04:21 < dx> but yeah if it says that, the implementation is likely to be shit.
04:22 < dx> you mean std::random_device?
04:22 < Drainedsoul> yeah
04:22 < Drainedsoul> it's one of those things that's specified so forgivingly that you can't rely on it for what it was actually intended for
04:22 < dx> true
04:22 < Drainedsoul> on at least one version of MinGW-w64 I used
04:22 < Drainedsoul> std::random_device actually just
04:23 < Drainedsoul> outputs the same random numbers each run of the program
04:23 < Drainedsoul> -_-
04:23 < Drainedsoul> "random"
04:23 < dx> oh damn, i have absolutely no idea what to do with windows. how do they solve it there?
04:24 < Drainedsoul> http://msdn.microsoft.com/en-us/library/windows/desktop/aa379942(v=vs.85).aspx
04:24 < dx> i had this function that was basically a read() of /dev/urandom, wrapped in an #ifndef WIN32, and the win32 side of the implementation was empty
04:24 < Drainedsoul> http://git.rleahy.ca/MCPP/blob/master/src/cryptorandom.cpp
04:24 < Drainedsoul> here's a Win32 side for that #ifndef?
04:26 < dx> CryptoRandom::CryptoRandom () : stream(RANDOM_FILENAME) {}
04:26 < dx> ...is that all? neat
04:26 < dx> i mean the unix side
04:26 < Drainedsoul> stream is a std::fstream, so yeah, pretty much
05:35 < Not-3b7> [Glowstone] SpaceManiac pushed 3 commits [+7/-0/±20] http://git.io/O_C4ug
05:35 < Not-3b7> [Glowstone] ZachBora 61914c1 - Added block placement handling for several blocks (see #119).
05:35 < Not-3b7> [Glowstone] SpaceManiac 19c7ec3 - Improved canAbsorb and added canOverride, implemented for slab, fire, and tall grass.
05:35 < Not-3b7> [Glowstone] SpaceManiac c0d7fc5 - Made warning on incorrect MaterialData more uniform, improved formatting.
06:42 < Drainedsoul> cc1plus.exe: internal compiler error: Segmentation fault
06:42 < Drainedsoul> -_- my favourite
08:55 < dx> just verified, both 1.8 server and client don't seem to include packet details in debug, only "OUT: [PLAY:25] kq"
08:56 < dx> [insert rant here about how mojang is making the lives of modders more difficult with each update]
08:56 < dx> (ignoring that this kind of logging didn't exist before 1.7)
08:59 < Drainedsoul> we should just write unit tests instead :)
08:59 < dx> unit tests? what?
08:59 < dx> i don't get it
08:59 < Drainedsoul> hmm?
09:00 < dx> how are unit tests related to the absence of packet details in debug in the mojang server?
09:00 < Drainedsoul> it was half tongue in cheek
09:00 < dx> but i still don't get it :(
09:01 < Drainedsoul> oh just a lot of people seem to want to get at packet debugging because they're just wildly throwing bits at the server/client
09:01 < Drainedsoul> sort of like "I'll try it to see if it works"
10:14 < Grum> Drainedsoul: let me check, but i think the reason was that it always stringified the packet even if it wasnt used
10:15 < Grum> hmm nope it seems to just have been lopped off
10:17 < Grum> yup just removed from the code, wonder why
10:23 < Drainedsoul> git blame?
10:30 < Thinkofdeath> I think it disappeared around the same time packets were changed to interfaces instead of abstract classes
10:32 < Drainedsoul> the whole interface vs. abstract class thing gets me upset-
10:32 < Drainedsoul> just feels like a hack around the lack of MI
10:43 < dx> Drainedsoul: "MI" being multiple inheritance?
10:48 < Drainedsoul> dx: Yes
10:50 < dx> uhh i wouldn't consider interfaces a "hack"
10:50 < dx> seems more elegant and explicit than the mess that you can create with multiple inheritance
10:51 < dx> but, that's, just, like, my, opinion, man
10:52 < Drainedsoul> you're comparing what interfaces FORCE you to do with what you CAN do with MI
10:52 < Drainedsoul> that's like saying Java>C# because in C# you can make a mess with goto
10:53 < dx> i'm not saying java>c++
10:53 < dx> i just hate multiple inheritance in general
10:53 < Drainedsoul> why?
10:54 < dx> ehh, i'm mostly thinking in python right now tbh
10:54 < Drainedsoul> I thought Python had MI
10:54 < dx> it does
10:54 < dx> it's also awful
10:54 < Drainedsoul> how so
10:54 <+SpaceManiac> lots of MRO silliness
10:55 < dx> method overrides other method. how to call parent method? NOBODY KNOWS
10:55 < Drainedsoul> C++ knows
10:55 < dx> Drainedsoul: how does C++ solve it?
10:55 <+SpaceManiac> super().method(params)
10:55 < Drainedsoul> <base class name>::<method name>(<params>)
10:55 < dx> python has both
10:56 < dx> the one that looks like <base class name> only really works for single inheritance
10:56 < Drainedsoul> how
11:03 < dx> ehhh i don't even know anymore
11:04 < dx> evidently i avoid it so much that i didn't even notice what SpaceManiac said is actually python syntax
16:28 < Aragas> so, minecraft will be officially on xna? lol
16:36 < dx> xna is dead as fuck
16:36 < Aragas> :DDD
22:14 < dx> hey #mcdevs, need a sanity check here. i'm building URLs to the libraries as specified here http://wiki.vg/Game_Files (wonderful page, btw, ♥ to the people who worked on it)
22:14 < dx> most of the work, some of them  throw access denied, like https://libraries.minecraft.net/tv/twitch/twitch-platform/6.5/twitch-platform-6.5.jar
22:14 < dx> or https://libraries.minecraft.net/tv/twitch/twitch-external-platform/4.5/twitch-external-platform-4.5.jar
22:14 < dx> or https://libraries.minecraft.net/org/lwjgl/lwjgl/lwjgl-platform/2.9.1/lwjgl-platform-2.9.1.jar
22:15 < Aragas> confirm. denied
22:15 < umby24> %
22:15 < umby24> ^
22:16 < dx> getting those from here http://s3.amazonaws.com/Minecraft.Download/versions/1.8/1.8.json
22:16 < dx> sooo... they just forgot to upload those files?
22:17 < Aragas> or maybe it need something like parameters or session id like in oauth
22:18 < Aragas> https://libraries.minecraft.net/org/lwjgl/lwjgl/lwjgl-platform/2.9.0/lwjgl-platform-2.9.0.jar - 1.7 version too
22:41 < Not-3b7> [Glowstone] SpaceManiac deleted branch mc-1.8
22:42 < Not-3b7> [Glowstone] SpaceManiac deleted branch stairs
23:17 < Dinnerbone> dx, you need to take the "natives" part into account
23:18 < Dinnerbone> "The natives key provides a string for each specific platform to be inserted between the .jar and the <version> of the filename, resulting in a filename with the format:"
23:18 < dx> Dinnerbone: having "natives" means the non-native jar doesn't exist?
23:18 < Dinnerbone> Yes
23:18 < dx> excellent, thanks
23:19 < Dinnerbone> They are platform natives, a non native version would be an empty file :D
23:19 < dx> i was actually wondering that, switched to this channel and saw dinnerbro. that was pretty cool.
23:53 < dx> http://stedolan.github.io/jq/ this thing is love
23:53 < dx> jq '[.id, (.libraries[] | [.name, .rules])]' *.json  ---> output http://dump.dequis.org/ehJZ3.txt
23:56 < dx> it's so nice that it makes me want to stop using plaintext + sed/awk/grep/perl and just use json for everything in my bash scripts
--- Day changed jeu. sept. 11 2014
00:44 < ScoreUnder> dx, I've seen that software used in a script before, always wondered how to get it. I just ended up replacing it with a call to node
00:47 < dx> ScoreUnder: hahah
00:47 < dx> ScoreUnder: not jq's fault that your script doesn't document dependencies
00:49 < ScoreUnder> dx, I know :/ kind of its fault that it has such a short name though
00:51 < dx> ScoreUnder: you're saying that as if all the other unix commands had long names :P
00:51 < dx> and i don't know about your google, but mine shows jq as a first result when searching jq
00:55 < ScoreUnder> ah. I'd been searching my package manager
00:56 < ScoreUnder> "community/python-pyquery" nope
03:16 < Not-3b7> [Glowstone] SpaceManiac pushed 6 commits [+2/-0/±151] http://git.io/TII-PA
03:16 < Not-3b7> [Glowstone] SpaceManiac 1225861 - Included a copy of the GPL in the distribution (fixes #147).
03:16 < Not-3b7> [Glowstone] se1by 3550e78 - Limit player yaw to values in the [0,360). Fixes #173.
03:16 < Not-3b7> [Glowstone] jkcclemens 74efe31 - Added .gitattributes to enforce LF line endings.
03:16 < Not-3b7> [Glowstone] ... and 3 more commits.
03:28 < dx> woo
03:29 < dx> "SpaceManiac authored 21 hours ago"
03:29 < dx> someone forgot to push, i see. was wondering what happened with it
03:33 < Drainedsoul> o_o; waiting 21 hours to push a commit is unusual?
03:33 < Drainedsoul> is this git or SVN?
03:33 <+SpaceManiac> git
03:34 < Drainedsoul> it was a rhetorical question
03:34 <+SpaceManiac> oh
03:35 < dx> Drainedsoul: uh, no, it's just that i was particularly impatient with this issue since there was a goddamn ticket that said it's not compatible with gpl
03:36 < dx> (and the title of that ticket is inaccurate)
03:36 < Drainedsoul> this sounds like licensing
03:36 < Drainedsoul> *glazes over*
03:36 < dx> hue
03:37 < Drainedsoul> ;)
03:37 < dx> i'd like to remind you that bukkit stopped existing due to licensing issues
03:37 < dx> craftbukkit, rather
03:37 < Drainedsoul> are you trying to support my position that licensing is stupid?
03:37 < Drainedsoul> you're doing a p. good job
03:37 < Drainedsoul> ;)
03:37 < dx> it may be stupid, but it's still serious business
03:38 < Drainedsoul> to some people, I suppose
03:39 < dx> and for a project like glowstone that is very tightly linked to bukkit, it definitely is
03:40 < Drainedsoul> that seems less to me that licensing is serious business, and more a good reason not to associated with people who think they have a right to coerce others into behaving in the manner they desire
03:40 < Drainedsoul> s/associated/associate/
07:06 < Fenhl> <dx> it's so nice that it makes me want to stop using plaintext + sed/awk/grep/perl and just use json for everything in my bash scripts
07:06 < Fenhl> dx: that's what I thought too, hence https://gitlab.com/jqsh/jqsh
07:12 < dx> Fenhl: i think i've seen this, but it was before becoming a fan of jq
07:12 < Fenhl> heh
07:12 < Fenhl> yeah I might have mentioned it in merveilles
07:13 < dx> oh right you're there too.
07:13 < Fenhl> :>
07:13 < dx> why is everyone everywhere?
07:15 < Fenhl> a lot of people play Minecraft it seems
07:16 < dx> may also be related to the fact that i have 80 channels open. jesus christ when did i get so many
07:16 < dx> i'm pretty sure i had less than 50 last week
07:18 < Drainedsoul> is there a C++ channel
07:19 < Fenhl> ##c++
07:19 < Fenhl> iirc
07:20 < Drainedsoul> "You're here because the channel you tried to enter has join throttling"
07:20 < Drainedsoul> lol
08:15 < dx> http://assets.minecraft.net/Barney---You%27re-a-Douchebag.jpg
08:16 < Drainedsoul> dx: wut
08:16 < dx> indeed
08:16 <+SpaceManiac> using directory listings to great effect, I see
08:17 < dx> yeah assets.minecraft.net is not a great place to hide that stuff
08:26 < dx> https://gist.github.com/dequis/d24ce9d9915401f13dd1
08:26 < dx> took me a bit too much to finish writing this crap
08:26 < dx> and at some point i started to think that maybe someone else did it already.
08:27 < Drainedsoul> ALL_OS = ['osx', 'linux', 'windows']
08:27 < Drainedsoul> TIL OSX is the only Unix
08:27 < Drainedsoul> ;)
08:27 < dx> supported by minecraft, yes
08:27 < dx> err, aside from linux...
08:28 < Drainedsoul> ;P
08:28 < dx> all_minecraft_resources.txt has 11523 lines. whoops.
08:29 < dx> 1705 after removing dupes
09:12 < dx> 1389mb, the following files are missing: http://dump.dequis.org/kvrUM.txt
11:26 < ensirius> Hi all
11:26 < ensirius> only i think "The block id is equal to (id << 4) | data" is bullshit?
11:27 < shoghicp> only that? :P
11:29 < ensirius> well, i mean docs are wrong?
11:30 < shoghicp> no, it's right
11:30 < shoghicp> also, on Chunk Data or Block Change packet?
11:31 < ensirius> chunk data
11:32 < shoghicp> remember that it's a little endian short
11:32 < shoghicp> not a big endian short
11:45 < shoghicp> ensirius: there is no need to private message me, let's talk here
11:45 < shoghicp> what are you sending?
11:46 < shoghicp> ensirius: data[i++] = (byte) ((blocks[i] << 4) | metadata[i]); is wrong
11:46 < shoghicp> that should be a short
11:47 < shoghicp> then, written to the network as a little endian short
11:52 < ensirius> like that:
11:52 < ensirius>                               int id = (blocks[i] << 4) | metadata[i];                                  data[position++] = (byte) (id & 0xFF);                                 data[position++] = (byte) ((id >> 8) & 0xFF);
11:52 < ensirius> oops
11:52 < ensirius> sry
11:53 < ensirius> ?
11:54 < shoghicp> why do you convert the id to a byte?
11:54 < shoghicp> as I said, it has to be sent as a short because it's using 8 + 4 bits
11:54 < shoghicp> and it has the extra 4 bits of add data at the fromt
11:54 < shoghicp> 16 bits ;)
19:34 < Aragas> SpaceManiac: I see that they have changed Records in MultiBlockChange packet. Glowstone use new version, if i correctly understand. My knowlegde of bit mask is very bad, can you say, how client should read these values? VarInt confuses me
19:35 <+SpaceManiac> if you have varint reading, just read the varint into an int
19:35 <+SpaceManiac> then the id is (x >> 4) and the data is (x & 0xf)
19:38 < Aragas> hm, so each record isn't more fixed-length. How should i separate it? Read varInt, get it length, then add 8+4+4 bits?
19:41 <+SpaceManiac> you just have to read the records sequentially
19:43 < Aragas> but what about bit mask? how do i get 'x' then?
19:43 <+SpaceManiac> 'x' in my example is just the result of reading the varint
19:45 < Aragas> we need to mark where we get the bit mask, right? from which position
19:45 <+SpaceManiac> I'm not sure I understand
19:45 < Aragas> It is easy, when data is fixed-lenght, we know where to use bit mask
19:46 <+SpaceManiac> read varint into int - now, it is int-sized, so you know which bits are which
19:46 < Aragas> oh, makes sense
20:45 < Dhruv0> Can someone please tell me what is wrong with my Position data type? https://github.com/PlasmaShaft/Craft.Net/blob/master/source/Craft.Net.Common/Position.cs
20:45 < Dhruv0> The player is getting disconnected on Spawn Player
21:55 < Not-3b7> [Glowstone] SpaceManiac pushed 3 commits [+2/-0/±14] http://git.io/gkAwQw
21:55 < Not-3b7> [Glowstone] greatman b21292c - Implemented artifact upload with travis.
21:55 < Not-3b7> [Glowstone] SpaceManiac 427b9e1 - Added remapper plugin for Bukkit backwards compatibility.
21:55 < Not-3b7> [Glowstone] SpaceManiac daaae74 - Switched to building against Glowkit.
22:27 < nickelpro> Death of bukkit apparently leads to dozens of devs duplicating effort, fun to watch I guess. Like Battle Royale except with people who should probably be doing more productive things with their time
22:29 <+AndrewPH> that's minecraft development for ya
22:39 < barneygale> meh that's any development for you when a big project gets taken down
22:44 <+AndrewPH> that's true for ya.
22:47 < Dhruv0> Are -'s included in 1.8 protocol and returned by the session server?
22:47 < Dhruv0> I'm getting an uuid error from LoginSuccess
22:48 < Dhruv0> And if so, where would the - be?
22:48 < Dhruv0> Front or end?
22:52 < dx> nickelpro: "duplicating effort"? isn't that what we (as in #mcdevs) kinda did since the beginning with custom servers/clients/libraries/proxies?
22:53 < nickelpro> dx: Absolutely, I was just observing that a lot more people are throwing their names in the hat for "next great minecraft implementaion" than pre-Fall of Bukkit
22:55 < dx> indeed, but of course it's natural that there's much more interest for a replacement now
22:56 < nickelpro> dx: Still, fun to hear about, what were mostly, hobby projects (Glowstone, Craft.Net) being talked about in such serious terms now. Half of /r/admincraft seems to think Glowstone in particular is days away from being feature complete
22:56 < dx> nickelpro: lol yes
22:57 < Dhruv0> Lol
22:57 < dx> glowstone really is getting a nice bunch of contributions, a bunch of them are quite nice, but it's still reeeaaaallly far from supporting all the same stuff as vanilla
22:58 < nickelpro> Does it even have a mob AI?
22:58 < dx> NOPE
22:58 < nickelpro> lol
22:58 < dx> not even mobs
22:58 < nickelpro> Didn't think so
22:58 < dx> someone is working on redstone, that's cool
22:59 < nickelpro> Just getting a baseline boxel server engine to a place where you can even begin implementing minecraft behavior is such a huge endeavour
22:59 < dx> you mean, what SpaceManiac already did?
23:00 < dx> you do have a point there, some newbies seem to think you can get a cleanroom implementation with the same feature set of glowstone (or craft.net, mcserver, bravo, etc) in no time
23:00 < nickelpro> Ya, and its impressive. But then you have to go the next 10k miles and build that behavior. And once you do that you're almost definitely way behind on performance unless you were thinking about it early on
23:01 < nickelpro> It just seems like expectations are set so damn high
23:01 < Dhruv0> Yea
23:01 < dx> glowstone even has a few significant issues with the bukkit api, too
23:02  * dx wants the async chat event PR to get merged ASAP
23:02 < Dhruv0> Uh
23:02 < Dhruv0> 1.8 includes -'s in uuids right?
23:03 < dx> oh yeah what you asked before, sorry
23:03 < dx> depends, where?
23:03 < shoghicp> Player Spawn packet has them
23:03 < dx> also they should be in the format of xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
23:05 < shoghicp> in my case, players were begging for mobs before we had physics and proper entities in
23:05 < shoghicp> now mob AI can be added, and other survival stuff is added
23:05 < shoghicp> still, it's hard
23:06 < nickelpro> PocketMine is the only real player in the PE world right?
23:06 < Dhruv0> Yea
23:06 < shoghicp> yeah, there are other projects besides this one
23:06 < Dhruv0> dx are you serious?
23:07 < shoghicp> but most of them port PocketMine code to other languages
23:07 < Dhruv0> How do I even implement that
23:07 < Dhruv0> The session server doesn't return -
23:07 < shoghicp> It's me who documents all the protocol changes
23:07 < nickelpro> shoghicp: Well ya, you're as close to a reference implementation as they're like to get
23:08 < shoghicp> well, and I get lots of feedback so things can be fixed
23:08 < shoghicp> and I've time to work on things
23:09 < shoghicp> getting into MCPE is harder - besides the Minecraft: PE protocol, you've to implement RakNet
23:09 < nickelpro> This isn't meant to start a language war, but why PHP? And ya I spent about 5 minutes looking at the PE protocol before calling it a wash because of RakNet
23:12 < shoghicp> I just started this to document things, and I can write quick and dirty things fast with PHP
23:12 < shoghicp> also, I think someone said I couldn't do it
23:12 < shoghicp> I hate PHP, too ;)
23:13 < Dhruv0> I did :D
23:13 < Dhruv0> I knew you couldn't do it
23:13 < Dhruv0> And yet you did...
23:13 < shoghicp> but this is not the normal PHP that you can find somewhere else - that I hate
23:13 < dx> Dhruv0: yes
23:13 < Dhruv0> dx, is it always in that set format
23:13 < Dhruv0> Or is it dynamic
23:14 < nickelpro> I just steal shit from other people, my first MC related repo was a straight up copy of one of Barney's client/server libraries
23:14 < dx> https://en.wikipedia.org/wiki/Universally_unique_identifier#Definition
23:15 < Dhruv0> Ok I see
23:20 < shoghicp> well, I moved all the RakNet part to a different project, RakLib
23:20 < shoghicp> runs in another thread :D
23:21 < shoghicp> so now PocketMine doesn't know anything about RakNet
23:21 < shoghicp> and just uses a network interface system
23:21 < shoghicp> so plugins can attach their interfaces there, if they want
23:56 < Dhruv0> dx could you answer 2 more questions?
23:56 < dx> ok
23:56 < dx> that's one
23:56 < dx> you've got another one, use it wisely
23:57 < Dhruv0> dx, OK
23:57 < Dhruv0> Ok*
23:57 < dx> ok*
23:58 < Dhruv0> dx, Does 1.8 have the AddBitMap metadata, and if it doesnt, how do I send the chunks?
23:58 < dx> i have no idea what you're talking about
23:59 < Dhruv0> Uh just tell me how to send/calculate chunks then
--- Day changed ven. sept. 12 2014
00:03 < dx> spoilers: i haven't dealt with that part of the protocol since beta 1.4
00:03 < Dhruv0> D:
00:03 < shoghicp> Dhruv0: it is part of the new blockId
00:03 < Dhruv0> shoghicp the add bitmap
00:03 < shoghicp> there are still 4 bits free in the Chunk Data short sent ;)
00:03 < Dhruv0> ?
00:03 < shoghicp> you don't send that anymore in 1.8
00:04 < Dhruv0> So how do I calculate the chunks/maps 0-0
00:04 < shoghicp> it's the primary bitmap
00:04 < shoghicp> everything is there now
00:05 < shoghicp> block id, block data is sent as multiple LE shorts now
00:05 < Dhruv0> So just replace addbitmap with primary bit map every time it is used?
00:05 < shoghicp> in my old code, I skipped addBitmap
00:06 < shoghicp> I only used primary
00:09 < Dhruv0> shoghicp would this work http://pastebin.com/QSjh1yYv?
00:09 < shoghicp> hmm, no idea
00:10 < shoghicp> I'm not in the mood for network code and chunks, too late here
00:10 < Dhruv0> Ok :P
00:10 < shoghicp> but it's mostly the same
00:10 < shoghicp> with less data
00:10 < shoghicp> uncompressed
00:10 < shoghicp> and remember that those shorts are little endian, not big endian :s
00:11 < Dhruv0> I'm getting that the buffer is 102 and the Max is 64
00:12 < Dhruv0> String buffer length*
00:26 < benbaptist> does the packet format change if you set compression to -1 in the server.properties? I'm getting issues even if I disable compression
00:30 < benbaptist> or rather, I'm getting issues WHEN I disable compression as if the protocol is different.*
00:31 < Thinkofdeath> benbaptist: when compression is -1 (disabled) the second header isn't sent
00:31 < Thinkofdeath> -1 being the default state until the first compression packet
00:32 < benbaptist> okay, that's what I thought. I guess that doesn't explain my issue then. 
00:32 < benbaptist> I'm wondering if maybe I'm sending far too much data for a single packet to handle for some reason, or handling it strangely
00:33 < Thinkofdeath> if you send too much the client will tell you :)
00:33 < benbaptist> I'm a man-in-the-middle between a client and server (proxy), but the client crashes with this junk http://s.benbaptist.com/iqzXYgv1fi.jpg
00:33 < Thinkofdeath> offline mode or online mode?
00:34 < benbaptist> The proxy itself is in online mode, but the server is in offline mode.
00:34 < benbaptist> due to encryption getting in the way
00:34 < Thinkofdeath> are you handling encryption correctly?
00:34 < Thinkofdeath> proxy -> client
00:35 < benbaptist> It should be, it works fine with compression turned on (on the server's side).
00:35 < benbaptist> But when it turn it off on the server side, things go screwy and I almost instantly disconnect. I wanted to turn it off because it seemed like a waste of CPU power to have it compress twice, plus I'm getting a few errors with compression for some reason.
00:35 < dx> uhm, dumb question, the official launcher doesn't allow sending fake usernames in offline mode, right?
00:36 < benbaptist> I don't think so dx, but Magic Launcher can do that easily.
00:36 < Dhruv0> Not the official
00:36 < dx> ah thanks benbaptist
00:36 < Dhruv0> But you could easily run the .jar file from terminal to do so
00:36 < benbaptist> Just enter any username and then press "Test" in the options menu. I love using it for debugging stuff.
00:36 < Thinkofdeath> benbaptist: And you are remembering the second length value isn't there without compression?
00:36 < benbaptist> Indeed Thinkofdeath 
00:37 < Thinkofdeath> (just going through things step by step)
00:37 < Thinkofdeath> no idea then :/
00:37 < benbaptist> I've noticed it does actually decode some packets and seem to work properly for the first 20 packets or so. If I slow down packet sending to send one packet per second, then I see my inventory and the server begins to send chunk packets, and then the client disconnects myself.
00:38 < Dhruv0> Anyone familiar with the 1.8 protocol
00:38 < Dhruv0> ?
00:38 < Dhruv0> I have another question :P
00:38 < benbaptist> yeah, it's really weird. I might turn off compression for the proxy
00:38 < benbaptist> I am Dhruv0, what's up?
00:38 < benbaptist> or turn compression off for the proxy to see if that fixes anything, that is*
00:39 < Dhruv0> benbaptist have you implemented the Position data type?
00:39 < benbaptist> Dhruv0, I have, but I have issues with the Z coordinate being crazy if it's in a negative.
00:39 < benbaptist> otherwise, X and Y are perfect, and Z works if it's a positive value.
00:39 < Dhruv0> Mine doesn't work at all
00:39 < Dhruv0> Could you check over my code?
00:39 < benbaptist> sure
00:40 < Dhruv0> https://github.com/PlasmaShaft/Craft.Net/blob/master/source/Craft.Net.Common/Position.cs
00:41 < benbaptist> hmm, unfortunately, I don't really know Java too terribly well. But this is my implementation in Python, if it would help at all http://pasteben.benbaptist.com/?id=5588619317859
00:41 < Dhruv0> Its C# ;P
00:41 < Dhruv0> And OK
00:41 < Dhruv0> Ok*
00:41 < benbaptist> Oh, whoops :P
00:41 < Dhruv0> I know a bit of python
00:41 < benbaptist> I get C# and Java confused, sorry :P
00:41 < Dhruv0> What about the write method?
00:42 < benbaptist> like I said though, the Z coordinate completely screwy with that implementation
00:42 < Dhruv0> That seems to be my trouble
00:42 < Dhruv0> Not writing well
00:42 < benbaptist> Dang, I don't actually have a write method yet. Sorry :P
00:42 < Dhruv0> XD
00:42 < benbaptist> I just realized that. Whoops.
00:42 < Dhruv0> Ok
00:42 < Dhruv0> ;P
00:42 < benbaptist> I'm going to need that in the future, I probably should figure one out :P
00:43 < Dhruv0> And I shall keep searching for another user
00:45 < Thinkofdeath> Dhruv0: http://hastebin.com/utibokexax.java
00:46 < Dhruv0> Tty
00:46 < Dhruv0> Ty*
00:49 < Dhruv0> Thinkofdeath I'm getting the same OutofBounds exception I had before
00:49 < Dhruv0> Could it be my x, y, z value?
00:49 < Drainedsoul> https://gist.github.com/RobertLeahy/e96f06553d82c365a132 here's a C++ implementation, if that helps?
00:49 < Drainedsoul> that also does bounds checking and adjusts sign bits? :|
00:54 < Dhruv0> I'll fix this tomorrow
03:09 < nickelpro> Are the docs up to date with the 1.8 world format?
03:10 < benbaptist> nickelpro, for the protocol? yes
03:10 < benbaptist> Oh, sorry, I didn't see what you said. :P
03:10 < benbaptist> I didn't see "world". Let me see if they're good.
03:10 < nickelpro> I'm too lazy to open a browser, apparently
03:11 < nickelpro> Ya no
03:11 < nickelpro> Someone has to update the SMP Map Format page
03:11 < benbaptist> Oh, for sending chunks?
03:11 < nickelpro> http://wiki.vg/SMP_Map_Format
03:12 < nickelpro> Still talks about the Add Bitmask and all that nonsense
03:13 < benbaptist> Did they finally stop using silly bitmasky junk for sending chunks?
03:13 < nickelpro> You still have your primary to tell you if you've got a a chunk or just air
03:13 < nickelpro> But there's no "Add" junk to deal with "large" block ids
03:15 < nickelpro> The fuck? We don't compress chunks anymore?
03:16 < nickelpro> 1.8 just gets weirder and weirder, I feel like Mojang just went "Fuck the protocol, we do what we want"
03:20 < benbaptist> no nickelpro, because the whole protocol is compressed now.
03:21 < nickelpro> benbaptist: I need to read this whole thing cover to cover, I just keep getting surprises
03:21 < benbaptist>  Yup, the 1.8 protocol is full of 'em. :P
03:22 < nickelpro> Wow this is going to require nearly as much work as 1.6 did, awesome
03:22 < benbaptist>  Probably :P
03:23 < benbaptist> especially with implenenting compression, so you'll have to redo some basic networking structure code.
03:32 < Drainedsoul> implementing compression should not be difficult if your parsing code is structured sanely
03:32 < Drainedsoul> if it's difficult, that should be a hint to refactor
03:46 < benbaptist> by any chance, does anyone know if Python's zlib.decompress() is not good for decompressing packets? Every once in a while, I receive a packet that I can't seem to decompress (incorrect header or some related error), but if I catch the error and move on, I can continue parsing the protocol so it doesn't seem like I'm screwing up protocol parsing.
03:48 < Drainedsoul> I wouldn't think there'd be the concept of "not good", either something inflates, or it doesn't
03:48 < Drainedsoul> if I were you I'd dump the binary of the offending packet, and try feeding it through your parser in an isolated environment
03:59 < benbaptist> okay
04:02 < Not-3b7> [Glowstone] SpaceManiac pushed 1 commit [+0/-0/±1] http://git.io/d1Phmg
04:02 < Not-3b7> [Glowstone] SpaceManiac f735b08 - Fixed Travis publication.
05:22 < deltab> benbaptist: a continuation of a previous stream, perhaps? or do you handle that?
06:20 < Not-3b7> [Glowstone] SpaceManiac pushed 5 commits [+4/-0/±8] http://git.io/Wy8slw
06:20 < Not-3b7> [Glowstone] SpaceManiac a041edd - Made logger use more uniform (fixes #255).
06:20 < Not-3b7> [Glowstone] coelho 3641cf4 - Fixed disconnect when sending empty chunks.
06:20 < Not-3b7> [Glowstone] coelho a4d17e2 - Changed sound radius to be min(volume * 16, 16).
06:20 < Not-3b7> [Glowstone] ... and 2 more commits.
07:25 < benbaptist> deltab, an encryption stream? I don't think that would be the issue, since I parse 99% of packets just fine before and after.
07:41 < Drainedsoul> benbaptist: Did you reproduce it in isolation?
19:33 < MrARM-PC_> hello
19:34 < MrARM-PC_> how do you read a negative VarInt? It seems to go to 0 when it's -1
19:39 < MrARM-PC_> Because I get: 00 03 00 00 00 00 00 20 19 b9 00 00 00 00 00 0c 8e 66 <- it's not 0 after the 00 03
19:48 <+Amaranth> iirc Mojang's handling of negatives is different from normal (protobuf) varints
19:49 < MrARM-PC_> Any code snippet maybe?
19:49 < MrARM-PC_> But it shouldn't read it as 0, should it?
19:49 <+Amaranth> SirCmpwn had a gist he kept sharing for this I think
19:50 <+Amaranth> Maybe not
19:50 < MrARM-PC_> All is fine, until I receive that SetCompressionPacket
19:50 < MrARM-PC_> it literally breaks everything
19:51 <+Amaranth> https://github.com/SpigotMC/BungeeCord/blob/master/protocol/src/main/java/net/md_5/bungee/protocol/DefinedPacket.java#L85
19:51 < MrARM-PC_> ok, thanks
19:52 < MrARM-PC_> ugh, this is same as I have
19:52 < umby24> https://github.com/SirCmpwn/Craft.Net/blob/master/source/Craft.Net.Common/MinecraftStream.cs#L22
20:01 < MrARM-PC_> nvm, that's releated to something other
20:01 < MrARM-PC_> The one in play isn't 0x03, but 0x46
20:33 <+sadimusi> MrARM-PC_: are there even negative varints left in the protocol? I thought they removed them all
20:33 < MrARM-PC_> yep. Set compression
20:34 <+sadimusi> well they're not handled any differently than positive ones so you get a 4 byte wide two's complement if a number is negative
20:34 < MrARM-PC_> not an issue anymore, I did another stupid mistake
20:35 <+sadimusi> so the threshold is -1 when compression is disabled? not 0?
20:36 < MrARM-PC_> Hmmm? It says -1 on the wiki
20:38 < MrARM-PC_> Btw on http://wiki.vg/Protocol#Player_Position_And_Look the flags aren't in order comparing to the fields?
20:39 <+sadimusi> right, 0 means everything's compressed. still weird to see negative varints being reintroduced after they all were removed
20:42 <+sadimusi> it does indeed look like they're not in order. maybe dinnerbro mixed the flags up when telling us what they mean or it's just another instance of mojang's famous protocol inconsistencies  
21:29 <+SirCmpwn> Amaranth: you were thinking of my java hex digest gist, probably
21:53 < Drainedsoul> MrARM-PC_: https://gist.github.com/RobertLeahy/e96f06553d82c365a132 if you're still looking?
21:56 < MrARM-PC_> not anymore, thanks anyway.
22:00 < Dhruv0> Ok back to Positions, anyone familiar with 1.8's protocol?
22:08 < Drainedsoul> somewhat
22:11 < Dhruv0> Drainedsoul, I'll tell you the exception I'm getting from Spawn Player
22:13 < Dhruv0> java.lang.IndexOutOfBoundsException: readerIndex(17) + length(1) exceeds writerIndex(17); UnpooledHeapByteBuf(ridx: 17, widx: 17, cap:17)
22:19 < Drainedsoul> what are you sending
22:21 < Dhruv0> Drainedsoul, SpawnPosition
22:22 < Dhruv0> It seems to be coming from Position
22:22 < Drainedsoul> what bytes are you sending
22:22 < Dhruv0> What do you mean?
22:22 < Dhruv0> my bad
22:22 < Dhruv0> Not SendPosition
22:22 < Dhruv0> its SpawnPosition
22:23 < Drainedsoul> umm
22:23 < Drainedsoul> what raw bytes are being sent
22:23 < Dhruv0> umm, 0
22:23 < Dhruv0> I set the spawn position to 0, 0, 0
22:23 < Dhruv0> encoded is still 0
22:24 < Drainedsoul> so you're just sending the byte zero.
22:24 < Dhruv0> yes
22:24 < Dhruv0> as a long
22:24 < Drainedsoul> okay so that's not just "the byte zero"
22:24 < Drainedsoul> that would be eight bytes, all zero
22:24 < Dhruv0> Yes
22:25 < Drainedsoul> okay that can't be all you're sending ,packets have a header too?
22:25 < Dhruv0> nope
22:25 < Dhruv0> oh, you mean like the packet ID?
22:26 < Drainedsoul> the packet header
22:26 < Drainedsoul> which has three members, length, decompressed length, and packet ID
22:26 < Dhruv0> Should be
22:26 < Dhruv0> Other packets work
22:26 < Dhruv0> That don't use Position datatyp
22:26 < Drainedsoul> so it should look like 0xA,0,0x5,0,0,0,0,0,0,0,0
22:26 < Dhruv0> datatype*
22:27 < Dhruv0> Hm
22:29 < Dhruv0> Drainedsoul, could there be any other reason?
22:29 < Drainedsoul> sure there could be
22:29 < Drainedsoul> have you verified that's the output of your serializer
22:29 < Dhruv0> I'll see in a second
22:30 < Dhruv0> If other packets work, this one should too though
22:30 < Drainedsoul> do you have tests?
22:30 < Dhruv0> Testserver yes
22:30 < Dhruv0> TestClient is broken
22:31 < Drainedsoul> unit tests, that test your serializer in isolation
22:32 < Dhruv0> Drainedsoul, its being sent correctly
22:32 < Drainedsoul> has the protocol transitioned into the correct state?
22:33 < Dhruv0> As in?
22:33 < Drainedsoul> have both parties been told that the protocol is in the "Play" state?
22:33 < Dhruv0> Yes
22:33 < Drainedsoul> have they both acknowledged that, etc.
22:33 < Dhruv0> JoinGame has already initiated
22:36 < Dhruv0> Drainedsoul, I am almost 100% sure its coming from my Position datatype
22:36 < Dhruv0> Drainedsoul, should Position be sent as unsigned or signed?
22:36 < Drainedsoul> it makes no difference, provided the bytes are correct
22:38 < Dhruv0> Drainedsoul, should the header be sent in VarInts?
22:46 < Drainedsoul> yes, all three fields in the header are varints
22:50 < Dhruv0> Drainedsoul, could you look at my Position implementation https://github.com/PlasmaShaft/Craft.Net/blob/master/source/Craft.Net.Common/Position.cs
22:57 < Drainedsoul> that looks alright, but I don't see why you're so fixated on it.  As long as -- in this instance -- the position is serializing to eight 0 bytes, even if it's not correct in the general case, it's correct in this case, so why would it be the source of problems?
23:06 <+SirCmpwn> this is a side note
23:06 <+SirCmpwn> but if you intend to contribute that code upstream you need to fix your formatting
23:07 <+SirCmpwn> https://github.com/TeamInferno/Server/commit/9cde19c179b9dbf647409378aea35f73f7714ebb
23:09 < barneygale> hey dx, did you get very far with that quarry-based logging proxy?
23:12 < Dhruv0> SirCmpwn Ok
--- Day changed sam. sept. 13 2014
00:21 < jython234> heh net spliot
00:21 < jython234> split
00:35 < dx> barneygale: NOT FAR AT ALL
00:48 < barneygale> dx: ALRIGHT THEN
01:29 < Dhruv0__> Drainedsoul, i got a bit further
01:30 < Dhruv0__> The new error in Spawn Position is The received encoded buffer length is longer than maximum allowed 102 > 64
01:30 < Dhruv0__> I logged the encoded position and it came out to -1275068416
03:58 < Dhruv0> Anyone here?
03:58 < expir3dcow> hi
03:58 < Dhruv0> Hai
03:58 < Dhruv0> expir3dcow, Can you help me once again?
03:59 < expir3dcow> i don't recall who you are
03:59 < Dhruv0> Um, the guy from yesterday
03:59 < expir3dcow> urrrm
04:00 < expir3dcow> I was in college yesterday so can't be me
04:00 < Dhruv0> Ok, can you help XD
04:00 < expir3dcow> I'll try
04:00 < expir3dcow> 1)I'm tired
04:01 < Dhruv0> Ok
04:01 < expir3dcow> 2)I'm not good at programming
04:01 < Drainedsoul> o_o; what's going on?
04:02 < Dhruv0> Well basically, my Join Game packet is disconnecting the client with the error message of encoded string buffer length is larger than maximum size (102 > 64)
04:02 < Dhruv0> I have no idea what is going wrong
04:02 < Dhruv0> I've heavily debugged server-sided, I couldn't find a 102
04:07 < Drainedsoul> do you have unit tests
04:14 < Dhruv0> Drainedsoul: No
04:18 < Drainedsoul> you should really do that so you can be sure your expectations of what your code does, match what it actually does.  It makes debugging easier when you know what your code is actually doing, rather than trying to simultaneously figure out if you code does what you think it does, AND if it does what it's supposed to do under the Minecraft protocol
04:27 < dx> "the guy from yesterday", great introduction
04:29 < deltab> less impressive version of the man from tomorrow
04:31 < Dhruv0> dx: Ikr?
04:32 < dx> Dhruv0: anyway: don't ask to ask, just ask. that means, don't wait for someone to confirm to you that they can help (without even stating the question!), and don't ask that to any person in particular, just post your question in the channel and someone will eventually help you
04:38 < Dhruv0> dx Kk
04:41 < Dhruv0> Still not able to figure this out, any ideas?\
04:43 < dx> have you even written a unit test like Drainedsoul suggested?
04:44 < dx> personally i know i'd be too lazy to do it, but it's a good suggestion tbh
04:45 < Dhruv0> dx, I honestly don't see what the units would be compared through, the only unit tests I've done is with recipes
04:45 < Drainedsoul> dx: http://git.rleahy.ca/MCPP/raw/master/src/test/packets.cpp :(
04:45 < dx> Drainedsoul: i am sorry for your loss
04:46 < Dhruv0> I have no unit to actually test
04:46 < Dhruv0> Its a client sided error
04:47 < Drainedsoul> what's the client?
04:47 < Dhruv0> the official
04:47 < Drainedsoul> so you're saying the official client is broken, and can't parse trivial packets, but your server is not broken?
04:47 < Dhruv0> No no
04:47 < dx> haha
04:47 < Drainedsoul> then it's a server side error
04:47 < dx> Drainedsoul++
04:48 < dx> pun not intended
04:48 < Dhruv0> I prefer to call it networking error D:
04:48 < Dhruv0> dx, you forgot the ; :P
04:49 < Dhruv0> 102..
04:49 < Dhruv0> Weirdest number caused by protocol issue
04:49 < dx> eh
04:50 < dx> spoilers: ascii 102 is the letter 'f'
04:52 < Dhruv0> Lel
04:52 < Dhruv0> Ok I got past that I think
04:52 < Dhruv0> I was sending a VarInt instead of Int32
04:52 < Dhruv0> Protocol History told me wrong -,-
04:52 < dx> why do you use the protocol history page
04:53 < dx> the main protocol page is already update to 1.8
04:53 < dx> updated*
04:53 < Dhruv0> I like to see what is changed
04:53 < dx> also, int32 where?
04:54 < Dhruv0> now I got a more complicated error on JoinGame
04:54 < Dhruv0> EntityID
04:56 < dx> the protocol history page never mentions any change of entity id in join game
04:57 < dx> you really should read the up to date spec instead
04:59 < Drainedsoul> What does the vanilla server do when it receives a packet it can't parse?
05:00 < Dhruv0> I guess it throws it away?
05:00 < Dhruv0> I haven't experimented with vanilla but Mojang is obvious at points
05:02 < Dhruv0> yay guess what i did this time?
05:02 < dx> Drainedsoul: disconnect the client and vomit an exception
05:02 < Dhruv0> I did WriteString for Reduced Debug info instead of WriteBoolean
05:02 < Dhruv0> I am stupid
05:02 < Drainedsoul> Dhruv0: Unit tests would trivially catch this.
05:03 < Dhruv0> I need to write one
05:03 < Dhruv0> but first, I need time
05:03 < Drainedsoul> look at all the time you've spent debugging like, one or two packets
05:03 < dx> lol yes
05:04 < Dhruv0> XD
05:04 < Dhruv0> I added so many checks
05:04 < dx> unit tests are usually a wise usage of time
05:04 < Dhruv0> now i have to remember where they are and remove them
05:04 < dx> some people are just not wise
05:04 < Dhruv0> Like me :)
05:04 < dx> same.
05:09 < Dhruv0> Trying to read past the end of stream is bad
05:09 < dx> you just keep sending crap to the server
05:10 < dx> err i mean client
05:10 < Dhruv0> nah I think I'm reading it wrong
05:10 < Dhruv0> its a client -> server issue
05:23 < Drainedsoul> Minecraft splash screen text: "Information wants to be free!"
05:23 < Drainedsoul> unless, you know, it's the Minecraft source code, couldn't have that!
05:30 < Dhruv0> dx: Its failing past the stream even when I send no packets after JoinGame
05:30 < Dhruv0> Something is wrong..
05:30 < Dhruv0> again..
05:36 < Dhruv0> Is this correct for Join Game? http://pastebin.com/6vR0SBDL
05:47 < Drainedsoul> it would appear to be
05:56 < Dhruv0> There is an extra byte somewhere in the JoinGame packet
05:56 < Dhruv0> but where
06:05 < Drainedsoul> unit tests would tell you
06:08 < Dhruv0> PlayerPositionAndLooks is not reading the x/z correctly
06:18 < Dhruv0> Yay! I got the read past stream thing done with and now I have a 
06:18 < Dhruv0> Caused by: java.io.IOException: Packet 0/32 (lp) was larger than I expected, found 1 bytes extra whilst reading packet 32
06:18 < Dhruv0> 	at he.decode(SourceFile:42) ~[1.8.jar:?]
07:44 < Drainedsoul> Server::PacketObserver<Packets::Status::Serverbound::Ping>::PacketEvent <= these type names make me feel like I'm writing enterprise Java
09:48 < Drainedsoul> does the vanilla MC client just not support IPv6?
11:40 < ensirius> hi guys, 1.8 compression in both sides going?
11:40 < ensirius> or only server compress packets?
11:41 < shoghicp> both sides
11:41 < expir3dcow> why did so many people leave?
11:42 < ensirius> what threshold is best?
11:45 < shoghicp> hmm, the default is 256
11:45 < shoghicp> (also, it is chosen by the server)
11:45 < shoghicp> but I guess the client-server MTU would be the best option ;)
11:47 < ensirius> 256 byte? bytes?
11:47 < shoghicp> yep
11:57 < ensirius> guys, what you think about 1.8 protocol changes and etc?
12:10 < ackpacket> I'm trying to proxy between a notchian client and a server, and right after I send the client my proxy's encryption request it crashes
12:10 < ackpacket> any ideas why this might be happening?
12:10 < ackpacket> no meaningful data from the client
12:12 < shoghicp> it's on 1.8?
12:12 < ackpacket> 1.7.2
12:13 < shoghicp> hmm, do you have a packet dump available?
12:13 < ackpacket> I can show you the encryption request i'm pushing to the client
12:14 < ackpacket> would you like it in hex?
12:14 < ackpacket> python string?
12:14 < shoghicp> hex works :)
12:17 < ackpacket> heeeeeere ya go:  http://pastebin.com/JZgZtMJS
12:19 < ackpacket> I never hear from the client again after that
12:20 < shoghicp> that's EncryptionRequestPacket, right?
12:20 < ackpacket> yes, from my proxy to the client
12:20 < ackpacket> using proxy's public key instead of the server's key, ofc
12:21 < ackpacket> meanwhile the server is very content with the process
12:21 < ackpacket> expir3dcow: I can't seem to msg you back, it says you are away
12:24 < shoghicp> ackpacket: is there any crash info?
12:25 < ackpacket> shoghicp: nothing meaningful that I can see, but i'll paste it
12:25 < shoghicp> that verify token xD
12:25 < shoghicp> "asdf"
12:26 < ackpacket> shoghicp: http://pastebin.com/TMx9zgEr
12:26 < ackpacket> haha, yeah
12:28 < shoghicp> so, things that can be wrong
12:28 < shoghicp> the public key
12:28 < shoghicp> or the packet header, I did not check that
12:29 < shoghicp> everything else seems ok
12:30 < shoghicp> Strings in 1.7.2 are prefixed by a VarInt, right?
12:30 <+SirCmpwn> shoghicp: yes.
12:31 < ackpacket> shoghicp: the public key works out ok.  http://lapo.it/asn1js/
12:32 < shoghicp> well, I was testing that :)
12:34 < shoghicp> yeah, compared it with the one I generate
12:35 < ackpacket> so i'm at a loss
12:36 < shoghicp> Is your varInt read/write right?
12:37 < ackpacket> Yup.  Near as I can tell
12:37 < ackpacket> Otherwise I can't imagine the server would be very happy with me
12:37 < shoghicp> hmm
12:37 < ackpacket> I've written successful clients
12:37 < shoghicp> I read the VarInt, it says 188
12:37 < ackpacket> that sounds right
12:37 < shoghicp> I check the packet length, it is 189
12:38 < shoghicp> (packet length includes the packet ID)
12:38 < ackpacket> hmmm
12:38 < ackpacket> id, 2 shorts, 16 chars, 162 for key, 4 for token, 1 for the string prefix
12:39 < ackpacket> what am i missing...
12:39 < ackpacket> oh
12:39 < shoghicp> the packet is right
12:39 < shoghicp> but you don't include the packetId on the length field
12:40 < ackpacket> interesting...
12:42 < ackpacket> packet length is supposed to be 188
12:42 < ackpacket> not 189
12:42 < ackpacket> so varint is correct
12:42 < shoghicp> let me check it again :P
12:43 < shoghicp> I get 189
12:43 < shoghicp> packetId + string serverId + short + publicKey + short 
12:43 < shoghicp> + token
12:44 < ackpacket> 1 + 17 + 2 + 162 + 2 + 4
12:44 < shoghicp> I used your own packet to calculate the length, it says 189
12:45 < shoghicp> wait
12:45 < shoghicp> sorry, I'm wrong
12:45 < ackpacket> :D
12:45 < ackpacket> did the space at the end getcha?
12:45 < shoghicp> added an extra \n
12:46 < ackpacket> believe me, I WISH you were right
12:46 < ackpacket> that would make this 10x easier
12:46 < Drainedsoul> what would make what 10x easier? o_o;
12:47 < ackpacket> because I would have found the problem
12:47 < ackpacket> or... shoghicp would have
12:47 < ackpacket> i'd prefer that to some mystery crash
12:49 < Thinkofdeath> ackpacket: what crash?
12:49 < shoghicp> ackpacket: Did you try sending a null serverId?
12:50 < ackpacket> Thinkofdeath: I'm writing a proxy, and after intercepting the server's encryption request and swapping in my public key and information, I send it to the client and never hear from it again
12:50 < ackpacket> shoghicp: I have, doesn't change much.  And the server i'm dealing with sends a 16 byte id, and the client logs in there happily
12:50 < Thinkofdeath> Oh I thought you said the client crashed
12:50 < ackpacket> it does
12:51 < Thinkofdeath> got the crash log?
12:51 < ackpacket> http://pastebin.com/TMx9zgEr
12:51 < Thinkofdeath> ah thats a race condition in the client, happens if you disconnect it too quickly
12:51 < ackpacket> I'm not disconnecting at all
12:51 < ackpacket> the client is closing the socket
12:52 < Thinkofdeath> something is
12:52 < Thinkofdeath> could be it doing it to itself but i've never seen that happen before
12:52 < ackpacket> I can hold off on sending the encryption packet, and the program will hang forever (almost) as the client waits for it
12:52 < Drainedsoul> race conditions
12:53 < Drainedsoul> we've got some quality engineering on our hands here
12:53 < ackpacket> but the second I push it over the wire, client crashes, connection closes
12:53 < ackpacket> I have a theory...
12:53 < ackpacket> but it means logging in will be dreadfully annoying
12:53 < ackpacket> I think when my proxy auths, it's deauthing the client
12:54 < ackpacket> so the client goes to the join endpoint and doesn't get a success
12:54 < ackpacket> and disconnects quickly
12:55 < ackpacket> Mojang's auth is really finicky, it takes a few times to work and once it does, it usually deauths anything else that had an access token
12:59 < ackpacket> doesn't seem to be helping any...
14:15 < hristo> Can anybody explain how compression works in the 1.8 protocol? There isn't much info on the wiki.
14:19 < hristo> What algorithm is used?
14:19 < hristo> Does only the client send compressed data?
14:19 < hristo> s/client/server/
14:20 < hristo> (logical because only the server can send Set Compression)
14:28 < shoghicp> server & client use DEFLATE
14:29 < shoghicp> but the server sets the compression threshold
14:29 < shoghicp> default is 256
14:30 < hristo> When does the client start sending compressed data?
14:31 < shoghicp> once the compression threshold is set by the server
14:31 < hristo> So the server has no way of knowing if the packet it received (1ns after setting compression) is compressed or not.
14:31 < shoghicp> welcome to Minecraft!
14:31 < hristo> I forgot
14:32 < shoghicp> you can send it on the pre-login stage, I think
14:32 < hristo> I'm writing a proxy so I'll do both.
14:32 < hristo> Super fun time
14:33 < hristo> Well, I'm using unix domain sockets to communicate with the server so the latency should be in the microseconds.
14:33 < shoghicp> oh, and it seems like you can't change it later
14:33 < hristo> great
14:34 < hristo> so I'll only do compression proxy<->client
14:34 < hristo> possibly
14:34 < shoghicp> that works ;)
14:34 < hristo> can I convince the server not to compress?
14:34 < shoghicp> yeah, change the network-compression-threshold setting
14:34 < shoghicp> to -1
14:34 < shoghicp> on the server.properties
14:34 < hristo> thanks
14:35 < shoghicp> you can also skip sending the compression packet to the client
14:35 < shoghicp> and handle it on your own
14:36 < shoghicp> you can also set it to something big on the server
14:36 < shoghicp> so chunk packets get compressed
14:36 < shoghicp> and just forward them to the client, if you use a lower threshold there
14:37 < hristo> or set -1 on the server and compress everything in the proxy
14:37 < hristo> I want to inspect/filter/sometimes modify the packets
14:37 < shoghicp> yeah, but if you are not going to filter chunk packets
14:38 < shoghicp> they are really big and the server compresses things on another thread
14:38 < expir3dcow> Okay I found why there is no source for minebot
14:39 < expir3dcow> its written in c :(
14:39 < shoghicp> C or C++?
14:40 < SinZ> which minebot, there have been many
14:40 < shoghicp> one for Minecraft: PE, I think
14:40 < PEMapModder> Why do some people code in C?
14:40 < expir3dcow> c
14:40 < shoghicp> https://play.google.com/store/apps/details?id=com.bigfatgorillastudios.minebot
14:41 < PEMapModder> I mean, instead of C++
14:41 < shoghicp> expir3dcow: sure about that? I think they use the same networking engine as MCPE ;)
14:41 < PEMapModder> The only difference I know so far is that the compiler looks to run faster
14:41 < shoghicp> BTW, RakNet is now open source https://github.com/OculusVR/RakNet
15:26 < Dhruv0> Shouldn't the topic be changed? http://mcdevs.org is gone
15:36 < shoghicp> Dhruv0: I don't see mcdevs.org in the topic
15:38 < Dhruv0> shoghicp: My bad, I meant chanserv welcome
15:39 < shoghicp> oh, right
--- Log closed sam. sept. 13 15:55:44 2014
--- Log opened sam. sept. 13 15:55:52 2014
15:55 -!- Irssi: #mcdevs: Total of 148 nicks [1 ops, 0 halfops, 10 voices, 137 normal]
15:58 -!- Irssi: Join to #mcdevs was synced in 164 secs
16:21 < Scruff> nickelpro, You there buddy?
16:31 < nickelpro> Scruff: Sup?
16:31 < Scruff> Spock
16:31 < Scruff> Your framework
16:31 < nickelpro> Define "your" and "framework"
16:31 < Scruff> This thing https://github.com/nickelpro/spock
16:32 < nickelpro> Damn it has my name on it
16:32 < Scruff> :P
16:32 < nickelpro> What's up?
16:32 < Scruff> How do I run it exactly.
16:34 < Scruff> omg
16:34 < Scruff> that notice
16:34 < nickelpro> That's a good question, I haven't even tested it on the 1.7.10 protocol
16:34 < nickelpro> lol ya
16:35 < nickelpro> Spock's always been more of a "If you wanted to write something that can connect to Minecraft in Python, this is what it might look like"
16:35 < nickelpro> For a practical program that can do this like, run
16:36 < nickelpro> You're better off with a macro mod or that javascript framework who's name currently escapes me
16:36 < nickelpro> mineflayer
16:36 < nickelpro> https://github.com/andrewrk/mineflayer
16:38 < Scruff> Yeah, no other Python thing works afaik
16:38 < nickelpro> Honestly, third-party clients are a pretty niche software package
16:38 < nickelpro> What are you trying to do?
16:40 < Scruff> chat/afk
16:40 < Scruff> don't want to move
16:40 < nickelpro> Ehhhhhh
16:40 < nickelpro> Spock actually is pretty good at that
16:40 < nickelpro> What platform/python version?
16:42 < Scruff> 3.4
16:42 < Scruff> windows/linux
16:43 < nickelpro> 3.4 good, windows bad. Spock's networking module either needs a large cleanup or a straight port over to asyncio before it will work on Windows and I don't know anyone with the kind of time/interest to do that
16:44 < Scruff> Lets forget about windows then
16:44 < Scruff> :P
16:45 < nickelpro> If you've got a 3.1+ environment running on a Unix-like, get your hands on a 1.7.10 server, put the name and password you want to use in the login.py file, and run the demo. If it all breaks in a spectacular display of errors, something is broken and I'll be happy to fix it for you
16:46 < nickelpro> I have watch this weekend, but porting to new protocols is actually pretty easy for Spock so I'll do 1.8 SoonTM
16:47 < Scruff> ™
16:48 < nickelpro> Also, when it does break, post all the details in the Github bug tracker. Myself and a few friends actually watch the repo so we'll get the notification
16:49 < Scruff> Okay
16:49 < Scruff> Will do.
17:02 < rom1504> try https://github.com/andrewrk/node-minecraft-protocol too, not sure how up to date it is now though
17:02 < rom1504> but it's more maintained than mineflayer
17:02 < nickelpro> rom1504: That's the protocol implementation that mineflayer is based on, they're intertwined
17:03 < rom1504> yes
17:03 < nickelpro> mineflayer just provides a nicer API and some boilerplate
17:03 < rom1504> I know
17:03 < rom1504> but mineflayer is not up to date
17:03 < rom1504> node-minecraft-protocol is a bit more up to date
17:03 < rom1504> 1.7.10 vs 1.6.2
17:04 < rom1504> I actually have a bot made with mineflayer (http://github.com/rom1504/rbot) but sadly it doesn't work with recent servers
17:05 < rom1504> it's kinda even higher level than mineflayer
17:08 < Scruff> ImportError: No module named 'spock'
17:08 < Scruff> riiiiiight.
17:08 < Scruff> Forgot to install
17:08 < nickelpro> Oh does it even install lol?
17:08 < nickelpro> I haven't tried distutils in ages
17:10 < Scruff> Yeah
17:11 < nickelpro> I just add wherever spock happens to be sitting to the python path usually ~/code/spock
17:11 < nickelpro> I don't believe in installing "development" packages
17:11 < nickelpro> Heh
17:13 < Scruff> Okay
17:13 < Scruff> I tried copying the folder with 'cp spock/ examples/'
17:13 < Scruff> didn't work
17:13 < Scruff> so I moved it
17:13 < Scruff> xD
17:13 < Scruff> Now I need to install Crypto or w/e it is.
17:15 < Scruff> So
17:15 < Scruff> It works
17:15 < Scruff> I just need to know
17:15 < Scruff> How do I change the server ip/port etc
17:18 < Dhruv0> It says on Protocol History that "Added 'Position' to Chat Message Clientbound"
17:18 < Dhruv0> But doesn't display it on Protocol
17:19 < Dhruv0> Which one is correct? O-o
17:19 < Dhruv0> Wait it does, I was looking at server-bound
17:23 < Scruff> nickelpro, Guess what.
17:23 < Scruff> It works.
17:23 < Scruff> After looking through the code trying to find out where to change the ip/port. :P
17:23 < nickelpro> Scruff: Well color me surprised
17:24 < nickelpro> Dhruv0: Whatever it currently shows on the protocol page is correct
17:24 < Scruff> Suprise!
18:34 < nickelpro> Gah, 1.8 broke too many things, don't even know where to begin
19:38 < nickelpro> Packet compression uses gzip headers or did we gain sanity and just use zlib like normal people?
19:49 <+SpaceManiac> nickelpro: it's deflate
19:49 < nickelpro> SpaceManiac: Ya but with what header?
19:50 <+SpaceManiac> guhh, zlib is my guess
19:50 < nickelpro> https://github.com/andrewrk/node-minecraft-protocol/issues/96 says gzip but the wiki is weirdly silent
19:50 < nickelpro> We always used gzip before, but zlib is the sane option. Wondering if we switched or not
19:52 <+SpaceManiac> it's java.util.zip.Deflate, which I *think* is zlib
19:52 < nickelpro> zip uses the gzip format
19:56 < nickelpro> "Creates a new compressor using the specified compression level. If 'nowrap' is true then the ZLIB header and checksum fields will not be used in order to support the compression format used in both GZIP and PKZIP."
19:56 < nickelpro> Could be either
19:57 <+SpaceManiac> I have that parameter false and everything works smoothly
19:58 < nickelpro> So probably zlib then, great thanks
20:01 <+SpaceManiac> deflate("hello") -> 78 9c cb 48 cd c9 c9 7 0 6 2c 2 15
20:07 < nickelpro> Updated the wiki, Post Compression was a bit skeletal, someone check for me and make sure I didn't write anything retarded http://wiki.vg/Protocol#Post_compression
20:22 < woder> so what exactly does the data http://wiki.vg/SMP_Map_Format actually look like now? I can't figure out what the little 1.8 notes are refering to
20:25 <+SpaceManiac> that page is out of date, I'll look at fixing it
20:26 <+SpaceManiac> for more up-to-date information, the chunk and chunk bulk packets on the Protocol page are fairly accurate
20:32 < Dhruv0> What is Value inside Properties inside PlayerListItem?
20:34 < Dhruv0> the PlayerItemList needs to be more documented
20:37 <+SpaceManiac> Properties is what you get from the login server (right now, skin info)
20:39 < Dhruv0> Ok, I'm leaving it out until I fix chunks
21:35 < nickelpro> Can compression start during Login if the server sends the 'Set Compression' packet, or just in Play?
21:41 < Dhruv0_> SirCmpwn, is there any tool to reformat code on VS?
21:41 <+SirCmpwn> no clue
21:41 <+SirCmpwn> I can tell you how to do it with vim, though
21:42 < Dhruv0_> ok
21:46 < Dhruv0_> SirCmpwn, on vim, would gg=G do the trick?
21:46 <+SirCmpwn> yes.
21:46 <+SirCmpwn> make sure your indent settings are right first, though
21:46 < Dhruv0_> Ok
21:46 <+SirCmpwn> ts=4 sw=4 et
21:47 <+SirCmpwn> (for Craft.Net)
21:47 < Dhruv0_> mkm
21:56 < deltab> do you know of .editorconfig files? http://editorconfig.org/
21:59 < nickelpro> Can clients send json chat or do they have to use old style?
21:59 < nickelpro> as of 1.8+
22:06 < Dhruv0> json
22:06 < Dhruv0> I think
22:06 < Dhruv0> Servers have to send JSON
22:07 < Thinkofdeath> nickelpro: clients can't send colors in chat
22:07 < Thinkofdeath> only servers
22:07 < Thinkofdeath> However they can send them in books
22:07 < nickelpro> Thinkofdeath: But they still send chat as json? Or just a string?
22:08 < Thinkofdeath> nickelpro: just a string for the client
22:08 < nickelpro> Thanks
22:42 < Drainedsoul> So, is there anyway to get the client to connect on IPv6?
22:44 < Drainedsoul> I tried ::1 and [::1]:25565 to no avail
23:31 < Dhruv0> Could someone identify what I'm doing wrong? http://pastebin.com/t18sAHUr
23:32 < Dhruv0> Before 1.8, it used AddBitMap, now I changed all AddBitMap occurrences to PrimaryBitMap
--- Day changed dim. sept. 14 2014
00:50 < nickelpro_> huh
00:50 < nickelpro_> odd
01:01 < ensirius> hi guys
01:01 < ackpacket> Anyone know where and how the client stores access tokens?
01:01 < ensirius> after server gets encryption response all packets are cryped?
01:01 < ensirius> crypted
01:02 <+SpaceManiac> ensirius: that's correct
01:02 < ensirius> wow O_o
01:02 < ensirius> for what reason do this? just takes more cpu
01:02 <+SpaceManiac> for... security?
01:03 <+sadimusi> ackpacket: it's stored in launcher_profiles.json
01:03 < ensirius> i was thinking thats only for auth purpose..holy moly..
01:04 < ackpacket> ensirius: a few versions ago, mitm attacks were a big thing
01:04 < ensirius> i dont think this security layer is necessary
01:04 < ackpacket> I could have your client join my app, and use the data it submits to have my app join a server you have privileges on
01:04 < ackpacket> then issue commands as you
01:04 < ackpacket> anything from a faction invite, paying money, sending a tpahere, all the way to op commands
01:04 < ackpacket> it's necessary
01:05 < ackpacket> sadimusi: thank you
01:05 < ensirius> you mean proxying requests like bongecoord?
01:05 < ensirius> bunge
01:05 < ackpacket> I don't know how bungee coord works, but what I just said is pretty self explanatory
01:05 < ackpacket> you -> my_app -> your_server
01:05 < ackpacket> my_app can then do anything you can do
01:05 < ensirius> yeap same
01:06 < ackpacket> afaik bungee coord is for handling server side proxying and managing multiple servers under one hub or something like that
01:06 < ensirius> need to read more about https :3
01:06 < ensirius> yeah i know
01:06 < ackpacket> ensirius: this has nothing to do with https
01:06 < ackpacket> They both use RSA encryption, but the two ciphers are very different
01:07 < ensirius> tech is almost same
01:07 < ackpacket> ok, you're right
01:07 < ensirius> SpaceManiac: how good already glowstone?
01:08 <+SpaceManiac> ensirius: fairly solid networking implementation, base world and player stuff is good, many vanilla features wip
01:09 < ensirius> well, i really like glowstone and that you found time to start project again
01:10 < ensirius> protocol part is overhelming
01:10 < ensirius> messages, codec, handler..
01:11 < ackpacket> ah.... it's working
01:11 < ackpacket> successful packet proxy
01:11 < ensirius> gratz
01:11 <+SpaceManiac> yeah, the organization makes it look a little huge
01:11 < ackpacket> tyvm
01:12 < ackpacket> the first thing i'm doing with this, is to screenshare with a buddy
01:12 < ackpacket> and for some reason every chest I open will be full of gold apples
01:12 < ensirius> I am writing currently my own server once again after break. Your project was abdoned when i started so.. :)
01:14 < ensirius> Do you already did light update proccess? I spend 1 week to write algorithm
01:14 <+SpaceManiac> not yet, the client has just enough prediction that I can avoid it for now
01:14 < ensirius> had so much headbangs xD
01:14 < ensirius> I think you need more unit testing
01:14 < ensirius> It's so awesome
01:15 < ensirius> I wrote test using MCProtocolLib
01:15 < ensirius> tests*
01:16 <+SpaceManiac> I agree, I'd love to try and get some protocol-level testing going, or even just more unit tests of the internals
01:17 < ensirius> I like your inventory code and tests. Looks good
01:18 < ensirius> what about threading?
01:18 < ensirius> still 1 thread upadting all?
01:18 <+SpaceManiac> thread per world, with this wacky stuff so calls out to plugins are always synchronized
01:20 < ensirius> Why not use 1 thread on entity, 1 thread on players, 1 thread on chunks and etc..
01:20 < ackpacket> This proxy really does eat up some cpu...
01:20 < ackpacket> I suppose I could make the microsleep longer
01:20 <+SpaceManiac> that's a lot of threads, + really complicated to do all that synchronization
01:21 < ensirius> i dont think it's need a lot sync
01:21 < ackpacket> ensirius: what you think of parallelism isn't how it actually works
01:21 < Drainedsoul> Task-based parallelism 4eva
01:21 < ensirius> and concurrency collections makes it's easy
01:21 < ackpacket> ensirius: games operate in frames because it allows them to loop through all (entites/players/etc), do calculations, and then sleep for some amount of time
01:21 <+SpaceManiac> plugins expect entity.getLocation() to not change between two adjacent calls
01:21 <+SpaceManiac> but if the entity is on its own thread, it might
01:22 < ackpacket> ensirius: by the time you setup semaphores on all the data that is subject to race conditions, you will have so many critical sections you'll operate *slower*
01:23 < Drainedsoul> ackpacket: "semaphore"?  What year is it?