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> ::() 10:55 < dx> python has both 10:56 < dx> the one that looks like 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 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> 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::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?