08:09 < Drainedsoul> yeah it's pretty awful.  I've done quite a bit of .NET work, and people in the .NET world loooove their XML
08:09 <+md_5> should of just used nbt imho
08:10 < Grum> i'm liking msgpack
08:10 < Drainedsoul> isn't that the one with "nil"?
08:11 <+md_5> msgpack is just non shittynbt
08:11 <+md_5> ie: every other binary datastore
08:12 < Drainedsoul> yeah NBT is kind of strange.
08:12 < Drainedsoul> in my experience it's only painful for like a few hours while you write something to serialize/deserialize it, and then it doesn't really matter.
08:13 < Grum> except the format sucks
08:14 < Drainedsoul> Definitely.  I just don't think about it too much when I'm not specifically programming a parser/serializer
08:16 < Grum> its worse, it sucks in use
08:32 <+ammar2> isn't xml turing complete
08:32 < Drainedsoul> oh fuck not turing completeness
08:33 < Drainedsoul> apparently it's not though
08:33 < Drainedsoul> C++ templates, however, are
08:33 < Drainedsoul> ; )
08:36 <+ammar2> Drainedsoul: aah, I'm thinking of XSLT
08:38 < Drainedsoul> aww, not C++ templates?  You sure? :P
09:07 < jast> hard to tell which is worse
09:10 < Drainedsoul> ): no love for template metaprogramming
09:35 < Not-001> [fNbt] fragmer pushed 1 commit to master [+0/-0/±2] http://git.io/TxrXxA
09:35 < Not-001> [fNbt] fragmer 2c84f6b - Thoroughly documented NbtWriter. Added 2 more WriteByteArray overloads to NbtWriter for copying data directly between streams. Added NbtWriter.BaseStream property.
11:12 < Not-001> [fNbt] fragmer pushed 11 commits to master [+0/-0/±29] http://git.io/tgPFQw
11:12 < Not-001> [fNbt] fragmer 86f5f62 - Updated NbtReader comments.
11:12 < Not-001> [fNbt] fragmer d227339 - Updated assembly versions to 0.6.0
11:12 < Not-001> [fNbt] fragmer f349f19 - Updated README.txt
11:12 < Not-001> [fNbt] fragmer 940d281 - Sped up NbtList constructor and ListType setter.
11:12 < Not-001> [fNbt] fragmer b89e78f - NbtWriter's BeginList(...) methods now validate given list type.
11:12 < Not-001> [fNbt] fragmer ad98d1e - Expanded NbtWriter and NbtList unit test coverage.
11:12 < Not-001> [fNbt] fragmer fe18a85 - Updated the changelog.
11:12 < Not-001> [fNbt] fragmer 76d8be2 - Corrected output paths for x86 and x64 build configurations.
11:12 < Not-001> [fNbt] fragmer 58f557f - Updated the README once again, clarifying information about .NET 2.0 compatibility.
11:12 < Not-001> [fNbt] fragmer 3db5409 - Updated Doxyfile
11:12 < Not-001> [fNbt] fragmer 115be9c - Normalized formatting, and switched to using explicit "internal" modifier, to help Doxygen generate better docs.
11:12 < fragmer> pardon the commit spam
11:12 < fragmer> fNbt 0.6.0 is out! https://github.com/fragmer/fNbt/blob/master/docs/Changelog
11:14 < Not-001> [fNbt] fragmer tagged 115be9c as v0.6.0 http://git.io/r6QxVg
13:34 < Valdiralita> will there be a burger vitrine update?
13:49 <+sadimusi> not in the next few days
13:49 <+sadimusi> @Valdiralita
13:50 < Valdiralita> okay thanks
17:56 < ellisvlad> new protocol is #confusing :P
17:57 < ellisvlad> working on understanding it using wireshark while my wifi is being really tempermental... yup
18:25 < TkTech> Wiki will go down for a minute, cleaning up some tables.
19:15 < TkTech> Annnd done. At some point today it'll be slow for a few minutes while doing an OPTIMIZE TABLE.
21:49 < dx> omg new snapshot
21:51 < Thinkofdeath> Looking at it now
21:53 < dx> <3 Thinkofdeath
21:56 < dx> i'd like to mess with it soon but this job never ends. they told me it would be one week..
21:57 < Thinkofdeath> :(
22:17 < Thinkofdeath> http://wiki.vg/Pre-release_protocol#13w42a Done
22:17 < iBotPeaches> :)
22:17 < Cubix> <3
22:18 < dx> <3
22:18 < Thinkofdeath> lol
22:23 <+md_5> lmao
22:23 <+md_5> "lets remove level type"
22:23 <+md_5> "actually lets add it back"
22:24 < Thinkofdeath> Still not sure what the client uses it for...
22:30 < mrapple> Thinkofdeath: nice!
22:31 <+ammar2> Thinkofdeath: hrm, maybe the nether skybox colouration?
22:32 < Thinkofdeath> ammar2: "default, flat, largeBiomes, amplified, default_1_1" don't think they effect the nether
22:38 < Dinnerbone> It uses it for "worldly effects" like superflat has no void fog
22:39 < Thinkofdeath> Ah ok then
22:57 < Thinkofdeath> New map colours http://jsfiddle.net/tVY6L/ 
23:09 < Grum> omg such hacking
23:12 < dx> grum please
23:12 < dx> we all know the IP address of minecraft.net
23:12 < dx> do not anger the hackers
23:12 < Grum> FUHACKR
23:13 < Cubix> lol
23:59 <+Amaranth> I thought minecraft wasn't using the same varint type as protobuf
--- Day changed ven. oct. 18 2013
04:18 <+SpaceManiac> ooh, new map colors
05:59 < Not-001> [fCraft] fragmer * r2236 7 files : Improved code reuse between ch/cw/f2d/f3d/ln/torus draw operations.
06:00 < Not-001> [fCraft] fragmer * r2237 2 files : UpdateBuilder now references ZipStorer class from fCraft.dll, instead of keeping its own duplicate copy of the class.
06:21 < Not-001> [MCPP] RobertLeahy pushed 6 commits to 1_7_protocol [+0/-0/±8] http://git.io/SgtY4w
06:21 < Not-001> [MCPP] RobertLeahy 28fe8aa - ObjectData
06:21 < Not-001> [MCPP] RobertLeahy 38379fe - Template Recursion Depth Fix
06:21 < Not-001> [MCPP] RobertLeahy 7dc094c - PacketParser::FromBytes Clean Up
06:21 < Not-001> [MCPP] RobertLeahy ff26820 - Packet Pretty Printing
06:21 < Not-001> [MCPP] RobertLeahy 02907d2 - common.hpp Clean Up/Fix
06:21 < Not-001> [MCPP] RobertLeahy 578823d - NBT Strict Aliasing Fix
14:34 < Grum> <+Amaranth> [23:59:28] I thought minecraft wasn't using the same varint type as protobuf <-- we are, we just do not do the 'signed'-zigzag version
14:35 < clonejo> I don't get how zigzag is smaller than signed LEB128
18:05 < Grum> clonejo: LEBwhat?
18:08 < clonejo> Grum: http://en.wikipedia.org/wiki/LEB128
18:41 < Grum> clonejo: but that is just 'varint' without taking in account 'making negative numbers smaller'
18:42 < Grum> clonejo: how it is smaller is that the whole point of varints is to encode until the 'last seen bit'
18:42 < Grum> and you know that -1 is all bits set
18:42 < Grum> anything negative will have bits set in the MSB
18:46 < clonejo> Grum: signed LEB128 just drops the all-one 7 bit groups
18:47 < clonejo> on decoding the msb is inspected and the formerly dropped high one bits are added back
23:34 < Eviltechie> anybody ever try minecraft with a fixed length font?
23:45 < clonejo> did you mean "fixed width"?
23:56 < Eviltechie> <_<
23:59 < clonejo> Sorry, I don't know what you mean, so I speculated.
--- Day changed sam. oct. 19 2013
02:49 < Eviltechie> you were right
02:53 < clonejo> Eviltechie: your question might be better suited for #minecraft
02:53 < clonejo> we are a channel for custom server/client development (and related tools)
02:55 < Eviltechie> I was thinking from the side of making a text interface with that new clickable chat stuff
02:56 < clonejo> as a server-side plugin?
02:59 < clonejo> Eviltechie: ^
03:04 < Eviltechie> Yeah, something like the bukkit conversations api
03:04 < Eviltechie> But not having a fixed width font makes it hard to put text inside boxes
03:09 < clonejo> Eviltechie: there are ressource packs with different fonts
05:26 < Drainedsoul> the second part of the new server list ping, is that just to try and establish latency?
09:27 < Grum> Drainedsoul: yes
12:31 < Not-001> [MCPP] RobertLeahy pushed 5 commits to 1_7_protocol [+3/-1/±15] http://git.io/iWygdg
12:31 < Not-001> [MCPP] RobertLeahy 70ddc96 - Base64
12:31 < Not-001> [MCPP] RobertLeahy 43089b0 - InsufficientBytes Fix
12:31 < Not-001> [MCPP] RobertLeahy f3f2066 - Remove Commented Code
12:32 < Not-001> [MCPP] RobertLeahy 6bed59a - Packet Parsing Update
12:32 < Not-001> [MCPP] RobertLeahy 27d75e9 - MCPP Overhaul -- New Protocol
--- Day changed dim. oct. 20 2013
03:44 < Drainedsoul> what's the deal with the "favicon" field in the server status response
05:56 < Not-001> [MCPP] RobertLeahy pushed 6 commits to 1_7_protocol [+0/-0/±9] http://git.io/V0darw
05:56 < Not-001> [MCPP] RobertLeahy 320ad96 - Base64 Encoder Improvement
05:56 < Not-001> [MCPP] RobertLeahy 8e2e5ab - MySQLDataProvider GCC 4.8.1 Update
05:56 < Not-001> [MCPP] RobertLeahy f70e3bb - Add GetBinary Overload
05:56 < Not-001> [MCPP] RobertLeahy 949f44b - MySQLDataProvider Bug Fix
05:56 < Not-001> [MCPP] RobertLeahy 46b13db - Handshake - Remove Debug Code
05:56 < Not-001> [MCPP] RobertLeahy 1ce757f - ConsoleScreenBuffer Improvement
08:00 < mrapple> Dinnerbone: this bug is pretty bad https://mojang.atlassian.net/browse/MC-35776
08:00 < mrapple> if you try to connect a server and it's either offline or disconnects you for some reason (invalid packets or timeout), you can't rejoin until you restart minecraft
08:01 < mrapple> reproducable in 13w42a and 13w42b
08:01 < SinZ> ouch
08:02 < mrapple> yeah, makes testing bungeecord a pain
08:02 < mrapple> i keep having to relaunch minecraft ^_^
08:38 < Drainedsoul> I've noticed that the multiplayer screen exhibits all sorts of weird behaviour
15:13 < ellisvlad> Woo!! Finally got it working xD http://puu.sh/4UHOM.png
17:53 < G33kDude> I'm hunting around for a good MC chatbot framework. I'm not necessarily looking for something *all-in-one*, just a framework. Hopefully event based. Anyone know of a good one?
17:54 < G33kDude> I was looking at spock, but there demo.py either doesn't work, or I am missing something
17:55 < dividuum> i think i found a denial of service against a 13w42b server: if the client doesn't do the session /joinserver.jsp requests, the server ends up with this exception: https://gist.github.com/dividuum/a850c2cee0e6ed296e10
17:55 < dividuum> after that, i can no longer join the server
17:55 < dividuum> that is: until i restart it
17:57 < [z]2> So... If the session server is down... Everyone's server would die?
17:59 < dividuum> i think the server has to do the check_player request. so the session server probably has to be down for the player, but not the server. but i'm not sure about that
18:01 < G33kDude> Ah. I seem to have mis-spelled "their". Anyways, would it be better if I wrote my own?
18:02 <+clonejo> G33kDude: you can use an existing protocol implementation
18:03 <+clonejo> G33kDude: http://wiki.vg/Library_List
18:04 <+clonejo> most need a bit of updating, though (should be only a few packet changes)
18:05 < G33kDude> They don't change the whole structure radically, do they? Simple login & chat packets should remain about the same
18:05 < G33kDude> right?
18:06 < dividuum> not really. with the new snaphots, the protocol changed a lot
18:06 < dividuum> so if you have a 1.6. parser, you can only reuse parts of it
18:06 < [z]2> If it's for multiplayer... Can't you just make it a bukkit plugin?
18:07 <+clonejo> dividuum: most changes are trivial if you already have parsing structures and an encryption implementation in place
18:07 < G33kDude> Not really. Server's in a different location than where I want to run the script.
18:08 < [z]2> So you want to annoy people on someone else's server with your talking bot? :P
18:08 <+clonejo> G33kDude: your client has to be capable of parsing every packet the server sends (or at least know how to skip them)
18:09 < G33kDude> hmm. That could be a problem. All or nothing :P
18:19 < G33kDude> I think it might be easier for me to get an IRC bukkit plugin and route everything through IRC (again)
18:24 < G33kDude> Ooooh, there's one that runs an IRC *server* and not just a client
18:35 < G33kDude> Doesn't seem to be very stable, though. It floods my server with java socket errors every time a chat is sent
21:46 < Drainedsoul> so does anyone have any details on the "favicon" field?  Size limitations, format limitations, etc.?
21:47 <+clonejo> Drainedsoul: ellisvlad might
21:50 < Thinkofdeath> 64x64 png last time I checked
21:54 < Thinkofdeath> Drainedsoul: https://gist.github.com/thinkofdeath/c1a684785d626f477b93
21:59 < Drainedsoul> exactly 64x64, or a maximum of 64x64?
22:21 < Eviltechie> Drainedsoul: going by that code, exactly
22:24 < Drainedsoul> Eviltechie: okay.  Wasn't sure how official that code was @_@  Thanks
22:24 < Eviltechie> well, just try something smaller and see what it does
22:25 < Eviltechie> If it catches fire, you know you've found a combination that didn't work
22:25 < Eviltechie> That's science \o/
22:26 < Drainedsoul> well I already discovered that things bigger don't work :P
22:27 < Drainedsoul> "When libpng encounters an error, it expects to longjmp back to your routine"
22:27 < Drainedsoul> omfg
22:27 < Drainedsoul> I can't...
22:38 < Thinkofdeath> Drainedsoul: That code is minecraft's
22:56 < dividuum> any idea why the uuid is now part of the protocol? what's the reason for this?
22:56 < dividuum> are usernames being replaced as a unique identifier in the long term?
22:57 < Thinkofdeath> Thats the plan
22:57 < Thinkofdeath> To allow username changing in the future
22:58 < dividuum> ok
22:58 < dividuum> thanks
23:01 < Drainedsoul> thinkofdeath: Thanks, got favicons working!
23:01 < Thinkofdeath> Drainedsoul: np
23:07 < dividuum> yay. achievement unlocked: my snapshot python protocol parser is now able to proxy the protocol. 
23:10 < Not-001> [MCPP] RobertLeahy pushed 1 commit to 1_7_protocol [+1/-0/±2] http://git.io/s5-mtg
23:10 < Not-001> [MCPP] RobertLeahy 5e3cab7 - Favicon Support
23:10 < dividuum> ~100k packets per second :)
23:12 < Not-001> [MCPP] RobertLeahy pushed 1 commit to 1_7_protocol [+0/-0/±1] http://git.io/OGJdsg
23:12 < Not-001> [MCPP] RobertLeahy 77c2030 - Comment Fix
23:12 < Drainedsoul> nice
23:13 < Drainedsoul> is that single connection throughput or just throughput in general?
23:14 < dividuum> i recorded ~33k packets in client mode by joining a local server
23:14 < dividuum> it's a 1.2mb file. and i can reparse that in 330ms
23:14 < dividuum> lots of mobs and explosions in the recording :)
23:15 < Drainedsoul> ah lol
23:15 < dividuum> but it's total throughput, the cpu is 100% saturated. and being python, multithreading doesn't really help %)
23:15 < dividuum> but that's ok. i'll use it in multiple processes later.
23:15 < Drainedsoul> how can the CPU be 100% saturated if it's not multithreaded?
23:16 < dx> maybe he has only one core
23:16 < dividuum> yeah. one core. sorry
23:16 < Drainedsoul> but it's 2013
23:16 < dx> or, more realistically, only counting one core
23:16 < Drainedsoul> that'd make more sense :P
23:17 <+clonejo> probably he's refering to system load
23:17 < dx> also, some people consider 200% = 2 cores at full load
23:17 < Drainedsoul> strange
23:22 < Not-001> [MCPP] RobertLeahy pushed 1 commit to 1_7_protocol [+0/-0/±1] http://git.io/f2yWWw
23:22 < Not-001> [MCPP] RobertLeahy a77eca4 - Favicon Cleanup
--- Day changed lun. oct. 21 2013
00:31 <+ammar2> dx: some people and top and htop
16:54 < mrapple> Dinnerbone: did you see that bug i linked a few days ago?
17:01 < ellisvlad> Drainedsoul: From what I can tell, teh favicon is a 64x64 png in rgb/rgba format, encoded directly with base64. Literally just open a png with your server, encode it with base64, concat with "data:image/png;base64," at the start and send that in the favicon in the ping packet 0x00 json
17:06 < ellisvlad> Also, why don't more people do this: http://puu.sh/4VFIk.png (The player count area) It's much nicer for players to see :P. Achieved by sending an outdated protocol version, and a custom protocol name string.
17:09 < mrapple> ellisvlad: we do rhat
17:09 < mrapple> i thini hive does roo
17:10 < mrapple> that* too*
17:27 < ellisvlad> Also, quick way to test the image sent as a favicon is just to paste the string into chrome and see if the image renders correctly. e.g. http://www.ellisvlad.com/base64.php
17:45 < [z]2> Doesn't that header being at the start suggest that that is just one possible format?
17:47 < ellisvlad> I mean the png formatting :P The favicon must be a png (64x64 only as far as I have tried), but the internal formatting of the png can be either just RGB, or can have an alpha channel (transparency)
17:47 < ellisvlad> If you are going to be testing around... don't do what I did and send a black square as the favicon... you'll never see it against the black background of the serevr selection screen xD
19:20 < Thinkofdeath> http://wiki.vg/Pre-release_protocol#13w43a Just a protocol version bump
19:50 < mrapple> Thinkofdeath: nice, did you write a script to parse everything?
20:10 < Thinkofdeath> mrapple: Nah, that would be a good idea though
20:13 < mrapple> Thinkofdeath: how do you manage to check everything?
20:14 < Thinkofdeath> mrapple: Manually comparing each one
21:08 < dividuum> Thinkofdeath, thanks for doing that
21:11 < GeekDude> Is there a channel for bukkit dev?
21:12 < redstonehelper> #bukkitdev on esper I think
21:12 < redstonehelper> if it's not that, there's a few bukkit channels on esper afaik
21:12 < GeekDude> redstonehelper: You aren't redstonehelper from reddit, are you?
21:13 < redstonehelper> I am
21:13 < balrog> yeah it's that
21:13 < balrog> #bukkitdev on esper
21:13 < redstonehelper> thanks
21:13 < GeekDude> redstonehelper: Good job with all the update changelog posts
21:13 < redstonehelper> thanks
22:31 < dividuum> now with added website: http://miners-movies.com/ :-)
--- Day changed mar. oct. 22 2013
15:37 < Grum> mrapple: so vague!
15:40 < Grum> mrapple: ? :(
16:14 < mrapple> Grum: you there?
16:15 < ellisvlad> mrapple: Maybe we could help instead? :D?
16:15 < mrapple> ellisvlad: ?
16:16 < ellisvlad> Do you need any help with anything? :P
16:16 < ellisvlad> Grum is probably working at this hour
16:18 < mrapple> ellisvlad: he pinged me before you joined
16:18 < ellisvlad2> mrapple: Oh right :P
16:20 < mrapple> Grum: if you /stop a server or it is down, you cant rejoin
16:21 < mrapple> i didnt test in the most recent snapshot but in 13w42a it happens fpr sure
16:32 < jast> you mean when you stop the server you can't join it?
16:32 < jast> wonder how that happens
16:59 < mrapple> jast: if youre pn a server and /stop, then when you start it back up you cant join again until you restart MC
17:02 < mrapple> Grum: ^ a better explanation
17:27 < Dinnerbone> mrapple: it may or may not be fixed
17:27 < Dinnerbone> We fixed some race conditions that disabled client &| server
18:03 < ellisvlad2> snapshot 1.7 o.0?
18:03 < ellisvlad2> Woo!! :D
18:07 < mrapple> Dinnerbone: cool, youre able to join a server after getting kicked now?
18:07 < mrapple> also, another snapshot this week? :D
18:07 < Dinnerbone> Another snapshot? No...
18:08 < Dinnerbone> After the pre-release we're either going to have something major that needs another pre-release, or we're going to mark that as released and no more snapshots for a while.
18:09 < mrapple> oh wow i just saw the pre-release dur
18:10 < mrapple> so thay fix should be in there? i will test when i get home! thanks!
18:10 < Dinnerbone> Yes
18:10 < mrapple> <3
18:10 < ellisvlad2> So the protocl will stay the same for a bit? :P
18:10 < Dinnerbone> Yes
18:11 < mrapple> the release is friday??!!
18:11 < Dinnerbone> Yes
18:11 < ellisvlad2> Woo! Time to get cracking on working out the new protocol ;)
18:11 < mrapple> damn time to get my shit in gear
18:12 < ellisvlad2> Ooh, MC|PingHost is that new? :D? :P
18:12 < Dinnerbone> No... not at all...
18:12 < Dinnerbone> In fact it's very old and only supported for legacy...
18:13 < ellisvlad2> aha, was going to say... it uses the old string format :P
18:14 < mrapple> i think the only thing left is making my bungee detect if the client is 1.6/1.7
18:14 < mrapple> 1.7 client <-> 1.6 server is working though
18:15 < ellisvlad2> Nice
18:15 < dividuum> mrapple, you're the bungee developer?
20:05 < Eviltechie> dividuum: md_5 is the bungee developer
20:06 < dividuum> ah. ok. thanks
21:26 <+md_5> <mrapple> i think the only thing left is making my bungee detect if the client is 1.6/1.7
21:26 <+md_5> its already in master
21:27 <+md_5>  *snapshot
21:27 <+md_5> not sure why you would duplicate effort
21:28 <+md_5> Thinkofdeath pre release just ver bump?
21:29 < Thinkofdeath> md_5: Yep
21:30 < Dinnerbone> Protocol version is not just "did any packets change format", but new blocks/entities/items/etc require protocol change because of incompatibilities
21:30 <+md_5> yeah. but please stop changing it when there are no incompats
21:31 < Dinnerbone> New blocks == it's now incompat
21:31 < zifnab> Dinnerbone: 1.6.4 had no new blocks though
21:31 < zifnab> hello by the way!
21:31 < Dinnerbone> No that was one of the rare times we needed to change it for propogation reasons
21:32 < Dinnerbone> We've only done that like 2 or 3 times I think
21:32 < Dinnerbone> No way to update servers so we had to version bump client to make server owners realize they're out of date
21:32 < zifnab> that makes sense
21:33 < Dinnerbone> Also hello
21:33 < zifnab> didn't realize mojang devs wandered irc for some reason
21:33 < Dinnerbone> Gotta roam somewhere
23:40 < itsmartin> I have a mark2 question if anyone's around who can answer it - is there any way, in scripts.txt, to execute a command when a player joins, including the joining player's username in the command?
23:41 < itsmartin> Basically what I'm looking for is to be able to do something like "@playerjoin  /tellraw {username} Welcome to the server"
23:41 < itsmartin> Apologies if this isn't the right channel :)
23:42 < zifnab> itsmartin: try in #mark2
23:42 < zifnab> however, i think you can add a trigger on the playerjoin event
23:43 < zifnab> erm, not sure how to include their username actually
23:43 < itsmartin> zifnab: thanks, didn't know about #mark2
23:43 < zifnab> anytime :)
--- Day changed mer. oct. 23 2013
02:17 < nickelpro> Anyone know how often physics are applied in vanilla client? Mineflayer does once every 20ms, but is that official or a guess?
02:18 <+sadimusi> afaik pretty much everything except rendering only happens once every tick
02:18 <+sadimusi> so it's official
02:18 < nickelpro> And then position updates are done every 50ms or so?
02:19 <+sadimusi> probably every tick as well
02:19 < nickelpro> Mineflayer does once every 50ms, and I seem to remember reading every 50ms on the wiki once :-\
02:19 < nickelpro> I'll just try it and compare to vanilla
02:20 < nickelpro> thank sdi
02:23 < barneygale> Ah fuck this. MC-31714 marked as invalid, despite affecting a variety of graphics cards
02:23 < barneygale> My PC is broken too so looks like no more minecraft for me come friday :/
02:25 < nickelpro> Does manually updating LWGL do anything or is it strictly a driver problem?
02:30 < barneygale> who knows
02:30 < barneygale> Gru-m reckons it's drivers but it affects loads of different cards from different manufacturers
02:38 < dx> ...invalid?
02:39 < dx> that sounds as good as "works for me"
02:40 < barneygale> I wonder if when 1.7 gets released it'll get a hoard of "why isn't it working?"
02:40 < iBotPeaches> like that pixel shader bug report :p
02:42 < iBotPeaches> MC-297. 1976 duplicates :p
02:42 < dx> nice
02:45 < dx> the main difference is that MC-297 does have a proposed solution
02:46 < dx> for this one it looks like the best they can do is starting a virtual machine and playing minecraft with software rendering
02:46  * dx has done that before
02:46 < dx> it was fun
02:52 < barneygale> This laptop struggles to play minecraft through hardware rendering
02:53 < barneygale> Lots of items drops me down to ~10fps or so
06:42 < Grum> clonejo<barneygale> Gru-m reckons it's drivers but it affects loads of different cards from different manufacturers <-- then it's the subsystem, whatever it is, its not minecraft
06:43 < barneygale> what subsystem?
06:45 < nickelpro> Could be a problem in Mesa, unlikely though
06:47 < nickelpro> More likely LWGL or Minecraft doing something non-obvious that OpenGL doesn't like, don't know the spec well enough to speculate
06:48 < barneygale> I asked in #lwjgl and they say "we don't do mc support"
06:49 < dx> unsurprising
06:49 < barneygale> Yah, it was a long shot
06:49 < dx> they are probably used to it
06:49 < barneygale> So as far as I can tell its up to the affected users to figure out the problem, uhg
06:49 < nickelpro> For a long time MC used an ancient version of LWJGL, that would get frustrating fast
06:50 < dx> barneygale: if only we could bisect
06:50 < barneygale> nickelpro: yah. Xorg wouldn't report keyups properly so you would get stuck heading straight for lava haha
06:51 < nickelpro> barneygale: Ya that was fun, on Arch it wouldn't even launch unless you manually updated the LWJGL jars
06:52 < dx> ...always worked for me?
06:53 < dx> with the stuck keys issue
06:53 < nickelpro> I forget the error it used to throw, I think it was related to not being able to grab a rendering context
06:54 < dx> barneygale: do we even know if it's a graphics related issue?
06:54 < dx> or is the pulseaudio theory still around?
06:56 < nickelpro> dx: Feel like it would be more widespread if it was PA
06:57 < nickelpro> looks like people running flat alsa still run into it as well
06:58 < barneygale> dx: pulseaudio theory is a red herring
06:59 < barneygale> I changed openal to use a null driver, and also to just error out, but it didn't affect it.
07:02 < Grum> barneygale: you have the problem?
07:02 < barneygale> I do.
07:02 < barneygale> My PC blew up so I'm stuck on this laptop which exhibits it.
07:03 < barneygale> I'm going to bed soon but I can set up a VNC or something if you promise not to touch anything
07:05 < barneygale> wait, why are you awake Grum?
07:05 < Grum> because its morning?
07:05 < Grum> do you know how to make a custom version to run?
07:05 < barneygale> Oh yeah, you're ahead not behind. derp.
07:05 < barneygale> Yeah, I do
07:05 < barneygale> create folder, edit some json, etc?
07:06 < Grum> yes, how much time do you have spare now?
07:06 < barneygale> I can spare an hour or two
07:06 < Grum> ok gimme a min, i'll see if i can make some custom builds for you to test
07:06 < barneygale> This is why I love you Grum <3
07:07 < SinZ> btw Grum, are you actually going to rewrite EntityBoat?
07:07 < Grum> no idea SinZ
07:07 < Grum> barneygale: you do not get me then, i'm going to try to prove its not something we do
07:08 < Grum> and i'll force-hack out the probing and usage of FBO's
07:08 < Grum> if that fixes it, its not our problem
07:08 < Grum> BUT we can make a workaround
07:08 < Grum> a --linuxsucksdonkeycocksandcannotrunthegameinthefutureunlesstheystop
07:08 < Grum> so sec=D
07:08 < barneygale> I'm just happy that progress is being made, even if that progress is eliminating possibilities
07:08 < SinZ> <Mikeee> told Grum to spend time rewriting that shit :P
07:09 < Grum> barneygale: building now
07:09 < Grum> diff:
07:09 < Grum> -        useFbo = separateBlend && GLContext.getCapabilities().GL_ARB_framebuffer_object;
07:09 < Grum> +        useFbo = false && separateBlend && GLContext.getCapabilities().GL_ARB_framebuffer_object;
07:10 < Grum> i'm sure its some sort of quirky compat mode that now falls on its face
07:10 < Grum> however we have no intention of not using FBOs in the future
07:10 < nickelpro> why poll for them then?
07:10 < Grum> we do want to stop using them and gllists at the same time (we're slowly moving towards VBOs like we should)
07:11 < Grum> nickelpro: because right now it is optional
07:11 < Grum> but some videocards/drivers/subsystems lie about support and then die
07:11 < Grum> meh not awake, building now :P
07:11 < Grum> its a bit early out here ;)
07:11 < barneygale> :D
07:13 < Grum> takes 2-3 mins orso :P
07:13 < Grum> Total time: 1 mins 41.417 secs
07:13 < Grum> oh bit shorter, yay
07:14 < Grum> http://db.grum.nl/minecraft.linux.1.jar
07:15 < barneygale> Running now
07:16 < barneygale> err, well, "installing" now.
07:16 < Grum> ;)
07:19 < barneygale> Grum: same as before (i.e. not working). Want me to wait a while?
07:19 < Grum> euuh lol lets see
07:20 < Grum> building again
07:20 < dx> the plot thickens
07:21 < Grum> even less probing to opengl now O.o
07:23 < Grum> barneygale:  http://db.grum.nl/minecraft.linux.2.jar
07:25 < barneygale> stand by
07:25 < barneygale> no workie.
07:25 < Grum> err right
07:27 < dx> woo fancy flowers
07:28 < dx> all over the motherfucking place
07:28 < Grum> building again
07:30 < Grum> barneygale:  http://db.grum.nl/minecraft.linux.3.jar
07:30 < Grum> stripping more and more opengl related things
07:31 < dx> minecraft.linux.512.jar will be a directx version of minecraft
07:31 < barneygale> hah
07:33 < barneygale> Grum: failure once again :(
07:33 < Grum> barneygale: running out of options
07:33 < SinZ> which version did it start to derp
07:34 < SinZ> work your way up in commits and figure out what caused it
07:34 < dx> yeah, git bisect
07:34 < Grum> i have no idea when it broke
07:34 < barneygale> I found that out the other day. Let me check again
07:35 < barneygale> w37 works, w38 doesn't
07:36 < barneygale> w38 might work after 7 minutes (or whatever), I never bothered to wait that long
07:36 < Grum> both 'a' ?
07:36 < Grum> 13w37a / 13w38a ?
07:37 < barneygale> 13w37b / 13w38c
07:37 < barneygale> Those are the only ones I see in my launcher
07:37 < barneygale> Want me to check 13w38a and 13w38b?
07:37 < Grum> $ git log --oneline snapshot-13w37b..snapshot-13w38a | wc -l
07:37 < Grum>      106
07:37 < Grum> sigh ..... 106 commits o.O
07:37 < barneygale> ouch
07:38 < Grum> 12500 lines of diff
07:38 < dx> that isn't a lot of steps with git bisect!
07:38 < barneygale> eek1
07:39 < SinZ> thats still less than 1.6..1.7
07:39 < Grum> yeah starting bisect now
07:40 < Grum> the thing is, i dont even know if this compiles
07:40 < Grum> this will be the bestest bisect ever
07:40 < Grum> remotely tested =)
07:41 < barneygale> when do I get my first paycheck
07:41 < Grum> whenever you start using windows
07:41 < barneygale> >:(
07:41 < dx> Grum: you can always do "git bisect skip" if it's a broken commit
07:41 < Grum> i know how to bisect
07:41 < Grum> i just dont know if these things are buildable :D
07:41 < Grum> also i think the libraries changed with the release
07:41 < nickelpro> rebooting, what's the mail time across atlantic?
07:42 < Grum> barneygale: diff the two snapshot json files please
07:42 < Grum> see if their libraries changed
07:42 < Grum> i know we added vecmath
07:42 < Grum> but see if anything else did
07:42 < Grum> and then use the 13w38 one for the build i'll be giving you
07:43 < Grum> barneygale:  http://db.grum.nl/minecraft.linux.bisect.1.jar + 13w38's json
07:43 < barneygale> Grum: https://gist.github.com/barneygale/27e9422e9fc668974ddc
07:43 < Grum> good
07:43 < Grum> so use any json for it as base
07:43 < Grum> we did change libs for 1.7
07:43 < Grum> and i'm not compiling against those now
07:45 < barneygale> Grum: works!
07:45 < Grum> k
07:45 < Grum> Bisecting: 26 revisions left to test after this (roughly 5 steps)
07:45 < Grum> whoo :p
07:46 < SinZ> 106 down to 26, impressive
07:46 < Grum> well 52 now
07:46 < barneygale> is that average or max? hopefully it'll take fewer than that
07:46 < Grum> should be max
07:46 < Grum> its a binary walk to the problem
07:46 < Grum> assumes that one commits causes it
07:46 < Grum> weird cases let it be more
07:46 < Grum> but we'll see
07:47 < Grum> pfft obfuscation taking time :P
07:47 < barneygale> just give it to me unobfuscated, I totally won't put it on TPB ;)
07:47 < Grum> barneygale:  http://db.grum.nl/minecraft.linux.bisect.2.jar
07:48 < barneygale> Grum: also works.
07:49 < Grum> building next
07:49 < Grum> Bisecting: 13 revisions left to test after this (roughly 4 steps)
07:49 < Grum> and yeah for 1.7 we have 1100+ commits
07:49 < Grum> that would take a little bit longer (a least 3-4 bisects)
07:51 < Grum> barneygale:  http://db.grum.nl/minecraft.linux.bisect.3.jar
07:53 < barneygale> Grum: this one seems slightly broken, let me screenshot
07:53 < Grum> it starts right?
07:53 < Grum> it's stuck in the bottom-left corner
07:53 < barneygale> It starts, but the whole menu is squashed into the bottom left hand side the window
07:53 < barneygale> the rest is black
07:53 < Grum> yeah
07:54 < Grum> known issue back then
07:54 < barneygale> OK, cool
07:54 < Grum> this does mean your videocard is lying about FBO support in some way
07:54 < Grum> because you shouldn't have to reset the viewport for that
07:54 < Grum> building ofc ;)
07:55 < Grum> buildsystem is getting a workout :P
07:55 < Grum> happy its stable =)
07:55 < Grum> barneygale:  http://db.grum.nl/minecraft.linux.bisect.4.jar
07:56 < Grum> oh wait
07:56 < Grum> not upped yet
07:56 < Grum> barneygale:  http://db.grum.nl/minecraft.linux.bisect.4.jar
07:56 < Grum> now is! :D
07:56 < barneygale> Thanks!
07:56 < Grum> Bisecting: 6 revisions left to test after this (roughly 3 steps)
07:57 < barneygale> Starts; same issue as previous one.
07:57 < Grum> building
07:59 < Grum> barneygale:  http://db.grum.nl/minecraft.linux.bisect.5.jar
08:01 < barneygale> Fuck, I think I made a mistake Grum. Previous one you sent me /doesn't/ work (i.e. bisect.4)
08:01 < barneygale> I accidentally launched bisect.3 instead
08:01 < Grum> hmmm
08:01 < Grum> lol how to rollback!
08:01 < barneygale> :/ sorry, you're doing all this hard work and I messed it up
08:02 < barneygale> bisect.5 doesn't work either, as you might expect
08:03 < Grum> building again
08:03 < Grum> i just redid the bisecting
08:03 < Grum> the process is stable
08:03 < barneygale> yep
08:03 < Grum> so i just had to make sure i did the right amount of 'good'-s :D
08:03 < barneygale> :D
08:03 < Grum> 3xgood yo!
08:03 < dx> there's git bisect log and git bisect replay
08:04 < Grum> yeah i failed to notice log
08:04 < Grum> i did replay, didn't have log ... well ok .. reset ... scroll, copy/paste 3x .. done ;D
08:04 < dx> lol
08:04 < Grum> i'll check the log after we finish for the science
08:04 < dx> yay science
08:05 < Grum> barneygale:  http://db.grum.nl/minecraft.linux.bisect.6.jar
08:07 < barneygale> Grum: hang
08:07 < Grum> k
08:07 < Grum> erikbroes@grumm:~/src/mojang/Minecraft ((a52bd74...)|BISECTING)$ git bisect bad
08:07 < Grum> Bisecting: 0 revisions left to test after this (roughly 1 step)
08:07 < Grum> [70f530deeff38044f769b66982526ec0be368213] Don't let players silktouch lamps
08:07 < dx> wat.
08:07 < barneygale> wat :/
08:07 < Grum> so close! ;D
08:08 < Grum> the bug was actually the silktouching of lamps that are *ON*
08:08 < Grum> you can silk-touch them, they just go off ;)
08:08 < dx> and... linux graphics initialization is a metaphorical lamp that gets silk-touched?
08:08 < barneygale> Surely there's a commit in there somewhere that fixes the shrunken menu?
08:08 < Grum> no idea
08:09 < Grum> barneygale: yeah
08:09 < Grum> but i think its after
08:09 < Grum> the menu is not the problem
08:09 < barneygale> Uhg...
08:09 < Grum> barneygale:  http://db.grum.nl/minecraft.linux.bisect.7.jar
08:10 < dx> so much suspense
08:10 < Grum> one more to go if this one is bad i think
08:12 < nickelpro> this is better than football
08:12 < dx> a lot of things are better than football
08:12 < barneygale> Grum: bad
08:12 < Grum> $ git bisect bad
08:12 < Grum> Bisecting: 0 revisions left to test after this (roughly 0 steps)
08:12 < Grum> [0653bbf1f74dc2fe6c727436359309974114ece2] Added a slider for view distance
08:12 < Grum> cleaning ass again!
08:13 < barneygale> Is that it?
08:13 < barneygale> Nothing else to try?
08:13 < dx> he's building
08:13 < Grum> building
08:13 < barneygale> Oh, sorry
08:13 < Grum> 'clean ass' is building :p
08:13 < Grum> gradle clean ass(emble)
08:14 < barneygale> hah!
08:14 < nickelpro> heh
08:14 < Grum> yeah i have a little pun every time i make a build for you lot =)
08:14 < Grum> barneygale:  http://db.grum.nl/minecraft.linux.bisect.8.jar
08:15 < barneygale> Grum: bad
08:16 < dx> uh oh.
08:16 < Grum> oh god
08:16 < Grum> 0653bbf1f74dc2fe6c727436359309974114ece2 is the first bad commit
08:16 < Grum> commit 0653bbf1f74dc2fe6c727436359309974114ece2
08:16 < Grum> Author: Nathan Adams <dinnerbone@dinnerbone.com>
08:16 < Grum> Date:   Thu Sep 19 15:53:28 2013 +0200
08:16 < Grum>     Added a slider for view distance
08:16 < Grum> that makes *NO* SENSE
08:16 < nickelpro> I'm falling out of my seat
08:17 < Grum> errr
08:18 < nickelpro> We know for sure the commit prior to it is good? Tested in the bisect?
08:18 < dx> science time?
08:18 < barneygale> :/
08:18 < dx> nickelpro: actually nope
08:18 < dx> we got two bads in a row
08:18 < Grum> 3
08:19 < Grum> i dont trust this at all
08:19 < barneygale> I'm going to double-check everything
08:19 < barneygale> I may have made a mistake earlier on that I didn't notice (launched the wrong version)
08:20 < barneygale> Fat lot of fucking help I am.
08:20 < Grum> nah its ok
08:20 < Grum> this a fickle process
08:20 < dx> so.. new bisect starting from the last confirmed bad to the last confirmed good?
08:21 < Grum> yup
08:21 < Grum> finding the shas :D
08:21 < dx> have fun!
08:21 < nickelpro> I would have really loved if it _was_ the sliders
08:21 < Grum> if what you did was correct barneygale; then http://db.grum.nl/minecraft.linux.bisect.9.jar -- should be 'good'
08:22 < Grum> as that is the commit right before the 'one first bad'
08:22  * barneygale crosses fingers
08:22 < dx> if .9 is good then it's the sliders? lol
08:22 < Grum> yes o.O
08:22 < nickelpro> HAH
08:23 < barneygale> Grum: good
08:23 < barneygale> ...
08:23 < dx> ..
08:23 < nickelpro> Oh lord
08:23 < Grum> ok
08:23 < Grum> looking into that commit
08:23 < dx> well at least we don't have to bisect again
08:23 < Grum> you run 64bit java and shit?
08:23 < barneygale> Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)
08:24 < Grum> dafuq
08:24 < Grum> this has nothing to do with anything
08:24 < barneygale> Which bisect is the one immediately after that? I'll double-check
08:25 < Grum> errr
08:25 < dx> 8 = slider and 9 = slider^?
08:25 < Grum> pfft hard to figure that out after the fact >.>
08:26 < barneygale> Yah
08:27 < barneygale> 8 definitely doesn't work
08:28 < Grum> 8 hangs, 9 works?
08:28 < barneygale> Yes
08:29 < barneygale> Wait, wtf
08:29 < barneygale> Hold on a minute :/
08:30 < Grum> i hope you found something that went wrong
08:30 < Grum> :p
08:30 < barneygale> Nope, I was right. 8 hangs, 9 works
08:30 < barneygale> I just re-downloaded them and double-checked I was launching the right version
08:30 < Grum> ok
08:30 < Grum> testing something
08:30 < barneygale> I've been up for a long time now so don't trust myself with this.
08:31 < Grum> i found one thing that might be causing an issue
08:31 < Grum> but .... it has nothing to do with lwjgl :P
08:31 < Grum> building
08:32 < Grum> this will be 8 with a tiny change
08:34 < Grum> -        is64bit = is64Bit();
08:34 < Grum> +        is64bit = false; //is64Bit();
08:35 < Grum> barneygale:  http://db.grum.nl/minecraft.linux.bisect.10.jar
08:35 < barneygale> Grum: bad
08:36 < barneygale> Uhg, that's not good news is it?
08:39 <+md_5> io.netty.handler.codec.DecoderException: java.lang.IndexOutOfBoundsException: readerIndex(3) + length(109) exceeds writerIndex(6): UnpooledHeapByteBuf(ridx: 3, widx: 6, cap: 6)
08:39 <+md_5> I keep getting a too small handshake :c
08:39 <+md_5>     at net.md_5.bungee.protocol.DefinedPacket.readString(DefinedPacket.java:23)
08:39 <+md_5> maybe strings are still shorts not varint
08:40 < Grum> no, port is short
08:40 <+md_5> no, but Strings in general
08:40 <+md_5> hm
08:40 <+md_5> writerIndex is 6
08:40 <+md_5> how can a handshake be that short
08:40 < Grum> barneygale: building a new one, found some oddity
08:41 < Grum> but meh this is feeling rather hopeless :/
08:41 < barneygale> I agree. Don't put yourself out too much
08:41 < barneygale> Are we sure 8 and 9 differ by only that commit?
08:41 < Grum> barneygale:  http://db.grum.nl/minecraft.linux.bisect.11.jar
08:42 < dx> what's this one?
08:43 < Grum> fixed some weird oddity in the code
08:43 < dx> yay oddities
08:43 < barneygale> Grum: sadly this is bad too
08:43 <+md_5> Grum fix chat on 1.7
08:43 <+md_5> colours dont carry over the line
08:43 < Grum> it works
08:43 < Grum> you just use old shit
08:43 < Grum> that doesnt work
08:43 < Grum> TOUGH COOKIE
08:44 < dx> rip §
08:44 < dx> will be missed
08:44 < Grum> goddammit, i have no idea what is causing this
08:45 < dx> can we have another build of 0653bbf1f74dc2fe6c727436359309974114ece2^ (slider^) just as a sanity check?
08:46 < Grum> making another build
08:46 < Grum> barneygale:  http://db.grum.nl/minecraft.linux.bisect.12.jar
08:47 < barneygale> I'll be 2 mins
08:49 < barneygale> Grum: I'm just checking out jconsole. For non-working builds, when it hangs, "PS Survivor Space" is at 100% while the others are at zero. For the working version, PS Survivor Space is at ~30% and the others (PS Eden and PS Old Gen) are at 1-5%.
08:49 < barneygale> I don't know if this is relevant, I don't know much about Java memory management.
08:49 < Grum> neither do i
08:50 < barneygale> OK. Trying your latest version in a sec
08:51 < barneygale> Grum: bad
08:51 < Grum> good, that was a trick
08:51 < Grum> that was 8 ;) -- or *REALLY* close to that
08:51 < Grum> so lets see wtf happened
08:52 < barneygale> I'll check 8 again
08:52 < Grum> something is fishy
08:52 < Grum> meh tripply checking
08:52 < Grum> its not exactly 8, it should have been
08:52 < dx> slider^ plz
08:52 < dx> PLS
08:52 < Grum> that is what this was
08:52 < Grum> i had all the changes in the commit stashed
08:53 < dx> ...what
08:53 < Grum> yeah 
08:53 < Grum> so something is up
08:53 < dx> slider^ is what 9 was supposed to be
08:53 < dx> if slider^ is bad then we need to run another git bisect
08:54 < Grum> could be the effect isnt stable
08:54 < dx> hm, true
08:54 < dx> barneygale: try 9 more
08:55 < barneygale> repeatedly?
08:55 < dx> i guess!
08:55 < barneygale> OK
08:58 < barneygale> Ran 10 times. Worked every time
08:59 < barneygale> I can do the same thing for 8?
08:59 < Grum> i'm just going to make you two fresh builds :P
09:00 < barneygale> This is one mysterious bug.
09:00 < Grum> barneygale:  http://db.grum.nl/minecraft.linux.bisect.13.jar
09:02 < barneygale> Grum: bad
09:02 < barneygale> back in 2-3 mins
09:04 < Grum> barneygale:  http://db.grum.nl/minecraft.linux.bisect.14.jar
09:06 < barneygale> Grum: good
09:06 < Grum> ok sigh
09:06 < Grum> confirmed at the same point
09:06 < Grum> i need to fragment the commit that causes it
09:06 < Grum> maybe we can figure out wtf causes it
09:07 < barneygale> We can certainly take a break and come back to it another day if you'd like? This isn't much fun.
09:11 < Grum> i dont care
09:11 < Grum> if you need to sleep, go sleep :D
09:11 < barneygale> I'll be here for another 20 minutes
09:12 < dx> Grum: same point? slider?
09:12 < Grum> yes
09:12 < Grum> minimizing commit-diffs now
09:13 < dx> so apparently 14 == 12 == 9 == slider^
09:13 < Grum> yup :p
09:13 < dx> and they are good, bad, good respectively
09:13 < Grum> mm i think 12 fubarred somehow
09:13 < barneygale> I'll check 12 again
09:15 < barneygale> 12 confirmed bad
09:16 < Grum> ok making a build
09:16 < Grum> this is the 'bad' commit but completely minimized
09:18 < Grum> barneygale: http://db.grum.nl/minecraft.linux.try.1.jar
09:19 < barneygale> Grum: bad
09:19 < Grum> expected; building new
09:20 < Grum> each build will have a really tiny little piece extra :/
09:20 < barneygale> You have more patience than I
09:20 < dx> shouldn't it have less?
09:20 < Grum> nah easier to work towards fail
09:20 < dx> but we're at fail
09:21 < Grum> barneygale: http://db.grum.nl/minecraft.linux.try.2.jar
09:21 < Grum> that one *should* work :P
09:21 < Grum> i mean, it only removes code =)
09:22 < barneygale> Grum: good
09:22 < dx> whoa
09:22 < SinZ> what changed between 1 and 2
09:22 < Grum> oooooh
09:23 < Grum> no
09:23 < barneygale> hah!
09:23 < Grum> this is just like 5% of the commit that caused fail
09:23 < Grum> but i think i know what it is
09:23 < dx> apt-get install sliders
09:23 < dx> those sneaky external dependencies!
09:25 < Grum> god this is really entangled, sec
09:26 < Grum> building
09:26 < dx> how big is that commit diff, btw?
09:26 < Grum> not big anymore
09:26 < Grum> but its entangled
09:26 < dx> lol
09:26 < Grum> we used the view distance everywhere
09:26 < Grum> and it was 'inverted'
09:26 < Grum> higher numbers was smaller range
09:27 < dx> oh, so it's like a refactor commit
09:27 < Grum> we sanified the viewdistance
09:27 < Grum> but! i just noticed it is setting glfog
09:27 < Grum> so maybe we're going over the range of the min/max
09:27 < Grum> so i just set it to 0-1 now
09:27 < barneygale> :o
09:28 < barneygale> this sounds promising
09:28 < Grum> barneygale: http://db.grum.nl/minecraft.linux.try.3.jar
09:28 < Grum> got i hope that works
09:28 < Grum> *god
09:28 < barneygale> :( it doesn't
09:29 < Grum> ok
09:30 < Grum> got another target
09:30 < Grum> sec
09:31 < Grum> hahahahhaa
09:31 < Grum> this MUST be it!
09:32  * SinZ waits to see if it is
09:32 < Grum> hahahah
09:32 < barneygale> I really hope so
09:32 < Grum> i'm actually rather sure about it
09:32 < Grum> god glaring error >.>
09:32 < SinZ> what is it?
09:32 < barneygale> don't say that, you'll jinx it
09:32 < Grum> barneygale: thanks so much for this bisect
09:32 < dx> !!
09:32 < dexter0> the suspense
09:32 < barneygale> Grum: thank you so much for doing this!
09:32 < SinZ> Grum: just add him to credits.txt or whatever
09:32 < Grum> it *IS* minecraft doing a wrong thing
09:33 < barneygale> :O
09:33 < barneygale> Lets not count our chickens before they've hatched
09:33 < Grum> goddammit finish building already
09:33 < SinZ> either way, its cleaning the codebase
09:33 < Grum> so i can checkout master
09:33 < Grum> and do the change there :D
09:33 < SinZ> Grum: so are we getting a 1.7.1 straight away?
09:33 < Grum> barneygale: http://db.grum.nl/minecraft.linux.try.4.jar <-- works :D
09:34 < barneygale> Grum: good!
09:34 < barneygale> :D
09:34 < dx> :D
09:34 < SinZ> :D
09:34 < barneygale> What was it?
09:34 < Grum> already building 1.7 with that fix
09:34 < Grum> yeah erm .... no :P
09:35 < Grum> i'm not saying!
09:35 < Grum> =D
09:35 < dexter0> :(
09:35 < Grum> hehe
09:35 < dx> glFuckShitUp();
09:35 < Grum> nah
09:35 < SinZ> atleast change the ticket to resolved
09:35 < barneygale> oh no way!
09:35 < Grum> MathShitUp
09:35 < barneygale> It's dinnerbone's commit, we can blame him!
09:35 < Grum> you can
09:35 < Grum> though i think i was looking at his screen at the time
09:35 < Grum> and i also missed it
09:35 < SinZ> and took awhile to find the derp
09:35 < dx> it's okay, you can tell us, we promise not to laugh
09:35 < SinZ> ^
09:35 < Grum> i will
09:35 < Grum> just gimme a sec
09:36 < Grum> first want to give him a working 1.7 
09:36 < Grum> and make sure it works
09:36 < Grum> maybe we do another derptiderp after
09:36 < barneygale> technical term
09:36 < SinZ> #mcdevs++
09:36 < Grum> thinking about it, its bloody amazing that any people can run this
09:36 < barneygale> hahahahaha
09:36 < barneygale> linux: more correct than windows.
09:36 < dx> *some linux
09:36 < Grum> barneygale: how much ram do you have? ;D
09:37 < Grum> barneygale: http://db.grum.nl/minecraft.linux.fixed.1.7.jar
09:37 < Grum> omg the confidence!
09:37 < Grum> ok so the diff:
09:37 < Grum> -        int maxChunksWidth = (MAX_VIEW_DISTANCE + 1) * 2; // Why +1?
09:37 < Grum> +        int maxChunksWidth = (Options.RENDER_DISTANCE_EXTREME + 1) * 2; // Why +1?
09:37 < Grum> and from that you can guess the error ;)
09:37 < dx> ..the reverse diff, right?
09:37 < Grum> no this is the one i have now
09:38 < barneygale> Grum: 6GB
09:38 < SinZ> please tell me EntityBoat's onUpdate is better than this now http://pastebin.com/c61PBjSq
09:38 < Grum> barneygale: videocard ram?
09:38 < barneygale> Give me a minute, I'll just test this first
09:39 < Grum> someone gimme the ticketnumber :P
09:39 < Grum> ah found https://mojang.atlassian.net/browse/MC-31714
09:39 < barneygale> https://mojang.atlassian.net/browse/MC-31714
09:39 < barneygale> Grum: good! :DDD
09:40 < Grum> whooooo! :D
09:40 < dx> \o/
09:40 < Grum> \o/ \o/ \o/ \o/ \o/
09:40 < SinZ> \o/\o/\o/\o/\o/\o/\o/\o/\o/
09:40 < SinZ> Lets hold hands
09:40 < Grum> anyhow, so what we did
09:40 < barneygale> Grum: you're an absolute hero! I'll be playing minecraft for many months yet :)
09:41 < Grum> we accidentally tried to allocate ((512 + 1) * 2) * ((512 + 1) * 2) * 16 glLists O.o
09:41 < barneygale> hahahahaha
09:41 < Grum> instead of: ((16 + 1) * 2) * ((16 + 1) * 2) * 16 ;)
09:41 < dx> dammit barneygale, you broke the promise
09:41 <+AndrewPH> / Why +1?
09:41 <+AndrewPH> //*
09:41 < barneygale> dx: which promise?
09:41 < dx> 04:35 < dx> it's okay, you can tell us, we promise not to laugh
09:42 < barneygale> Oh, foo
09:42 < Grum> so ... 16842816 instead of 18496
09:42 < SinZ> ouch
09:42 < barneygale> I wonder why it worked on windows etc
09:42 < Grum> for that it has to allocate  ~64mb of ram to even request this from the videocard
09:42 < dexter0> I suspect it works on os x b/c os x can page cram.
09:42 < dexter0> page vram
09:43 < Grum> nah, i think drivers work differently
09:43 < Grum> they do not actually have to allocate it
09:43 < Grum> they just have to block it
09:43 < Grum> and then give back an array of that amount of unique numbers
09:43 < Grum> if they do it smart, they just give back the list in a block
09:44 < Grum> this was nice and hidden in the commit :P
09:45 < barneygale> Grum: 6 stages of debugging apply: http://web.archive.org/web/20051023090428/http://www.68k.org/~jrc/old-blog/archives/000198.html
09:47 < Grum> pffft
09:49 < barneygale> Thanks again Grum :)
09:50 < Grum> thank you
09:50 < Grum> retarded issue
09:56 < Not-001> [MCPP] RobertLeahy pushed 11 commits to 1_7_protocol [+2/-0/±18] http://git.io/PtPjbw
09:56 < Not-001> [MCPP] RobertLeahy 771a647 - Packet ToString Fixes
09:56 < Not-001> [MCPP] RobertLeahy bd9a065 - Protocol Analysis
09:56 < Not-001> [MCPP] RobertLeahy e0ba238 - Cleanup
09:56 < Not-001> [MCPP] RobertLeahy 6791fc0 - Server Documentation
09:56 < Not-001> [MCPP] RobertLeahy 624a92e - Version, Compatibility, and Server Information Overhaul
09:57 < Not-001> [MCPP] RobertLeahy d0e0ff7 - Server Status Cleanup
09:57 < Not-001> [MCPP] RobertLeahy dc9e228 - Packet Router Header Fix
09:57 < Not-001> [MCPP] RobertLeahy 37c15c7 - Interactive Front-End Fix
09:57 < Not-001> [MCPP] RobertLeahy 2cc40d7 - Handshake Cleanup
09:57 < Not-001> [MCPP] RobertLeahy 44a7e7d - Packets Fix
09:57 < Not-001> [MCPP] RobertLeahy ac2dab3 - minecraft.net Authentication
11:52 < Not-001> [fCraft] fragmer * r2238 3 files : Updated fNbt to 0.6.0
11:54 < Not-001> [fCraft] fragmer * r2239 3 files : Minor cleanup in RealisticMapGen
12:08 < Not-001> [fCraft] fragmer * r2240 2 files : Eliminated redundant code between ReplaceNotBrush and ReplaceBrush, by making RNB a subclass of RB. Hooray for code reuse.
12:35 < Not-001> [fCraft] fragmer * r2241 8 files : Further improvements to code reuse: Added fCraft.ConsoleUtil for console-related functions, and moved some shared code from CuboidDrawOperation and PasteDrawOperation into DrawOperation base class.
13:10 < rom1504> "Completely rewrote how the network (multiplayer) works." in 1.7
13:10 < rom1504> really ?
13:19 < SinZ> yup
13:20 < dividuum> yes. and it's way better than before. finally a size header
14:00 < Valdiralita2> rom1504, oh shi-
17:21 < nickelpro> Are 1.7 varints signed or unsigned?
17:30 < Thinkofdeath> nickelpro: unsigned
17:31 < Thinkofdeath> well signed but encoded as unsigned varints (not zigzag encoded)
17:39 < nickelpro> Thinkofdeath: wait, what? So encoded into unsigned var ints, but decoded to signed ints? ie twos complement once decoded
17:40 < Thinkofdeath> nickelpro: yeah https://gist.github.com/thinkofdeath/e975ddee04e9c87faf22
17:40 <+sadimusi> doesn't that defeat the very purpose of varints for all negative numbers?
17:41 < Thinkofdeath> http://wiki.vg/Pre-release_protocol#Multi_Block_Change is the only place with negatives
17:41 < Thinkofdeath> but its 5 bytes always for a negative number
17:41 <+sadimusi> m(
17:42 < nickelpro> weird, alright, thanks Think
17:45 <+clonejo> Why don't they just use the signed variant of varints?
17:46 <+sadimusi> because
17:50 <+clonejo> best reason ever
18:00 < Flemmard`> and probably most used reason even
18:00 < Flemmard`> ever
18:00 < Flemmard`> :>
18:30 < barneygale> Does anyone have some example JSON data from a new Disconnect packet?
18:31 < barneygale> Thinkofdeath: ?
18:31 < Thinkofdeath> barneygale: From what I can tell it should be the same as chat
18:31 < barneygale> Righto, thanks
18:33 < nickelpro> What reason should a client send for the server to log a normal disconnect? ie disconnect.quitting
18:34 < Thinkofdeath> nickelpro: The client doesn't send it anymore (from what I can tell)
18:35 < nickelpro> Thinkofdeath: Huh, what does a client do to disconnect then? Just close the socket and call it a day?
18:35 < Thinkofdeath> barneygale: Just tested, it is the same as chat
18:35 < Thinkofdeath> nickelpro: Yep
18:42 < barneygale> Is the prefix of new strings length in characters still? UTF-8 has variable-width characters so that makes reading a string a little more complex, right? (I can't just pull 2*length bytes from the socket and decode em)
18:43 <+sadimusi> it's in bytes
18:43 < barneygale> Oh great, excellent!
18:46 < barneygale> sadimusi: do you have a python varint packer+unpacker written that I could look at? I want to make sure mine are sane
18:48 <+sadimusi> barneygale: no, I haven't had time to even look at the protocol yet
18:48 < barneygale> fair enough :)
18:48 <+sadimusi> but you could just show me yours
18:48 < barneygale> I'm just writing the packer now so I'll me a minute or two
19:13 < barneygale> OK, I think I have it working. That took longer than I expected >.>
19:27 < Thinkofdeath> barneygale: Tested it with negative numbers?
19:29 < barneygale> No, but this only needs to handle auth so I don't care
19:31 < nickelpro> I have an unpack that works with negatives, working on pack
20:36 < barneygale> Uhg, I'm having some trouble with this. It seems that /sometimes/, the client doesn't send the initial Handshake when logging in? Seems to be consistent for the server list ping
20:37 < barneygale> But I'm looking in wireshark and it seems to be sending the "Login start" right at the beginning of the TCP connection. Any thoughts?
20:38 < barneygale> md_5: is this something you've encountered?
21:04 < Drainedsoul> barneygale: I've seen the same thing
21:04 < Drainedsoul> I have no idea why it does it, but it's irritating
21:05 < Thinkofdeath> Yep same here, I thought it was my server
21:07 < Drainedsoul> barneygale: I have a C++ packer/unpacker, if that helps? :3
21:09 < barneygale> Drainedsoul: Thinkofdeath do you know of any factors that influence it, e.g. closing a connection shortly before, etc?
21:10 < Thinkofdeath> Nope, does it happen with vanilla?
21:10 < barneygale> I'll test that later tonight
21:10 < barneygale> if it does I'll ping Gru-m, but I don't think I'm doing anything vanilla doesn't
21:11 < Drainedsoul> my attempts to log into vanilla were spotty, but that could've just been the snapshot I was using
21:11 < Drainedsoul> I haven't seen the behaviour since the day before yesterday, at any rate
21:11 < Drainedsoul> but I was about ready to kill someone the day before yesterday, because I was convinced that it was my implementation
21:13 < Drainedsoul> https://github.com/RobertLeahy/MCPP/blob/1_7_protocol/include/packet.hpp#L825 Here's a packer/unpacker in like ~150 lines.  Probably less thanks to my egregious use of whitespace
21:17 < barneygale> mine is packed full of debug code at the moment heh
21:17 < Grum> [21:11:02] <barneygale> if it does I'll ping Gru-m, but I don't think I'm doing anything vanilla doesn't <-- might be an issue, please lemme know if you reproduce it somehow
21:18 < barneygale> The packed ID reuse makes it tricky to work around too
21:18 < barneygale> packet*
21:19 < Drainedsoul> barneygale: While you were away: [12:17] <Gr*m> [21:11:02] <barneygale> if it does I'll ping Gru-m, but I don't think I'm doing anything vanilla doesn't <-- might be an issue, please lemme know if you reproduce it somehow
21:19 < barneygale> Yeah I managed to ctrl_q
21:21 < barneygale> Grum: just reproduced in vanilla. Want me to send a wireshark dump?
21:22 < barneygale> I assume that the client gets mixed up about what protocol state it's in. All I did was connect to the server, disconnect, and try connecting again.
21:22 < barneygale> I could file a bug report of course
21:22 < barneygale> When it happens, the client just hangs on "logging in..."
21:26 < barneygale> This is tested on a local server, and I know that can sometimes bring out timing issues that don't occur if you have a bit more latency
21:57 < Grum> barneygale: just tell me how to reproduce it :
21:57 < Grum> i think we have a race-condition left somewhere in some way
21:58 < Grum> i just wonder what on earth is happening
21:58 < Grum> does the first packet not arrive, not get send ... weirdness
22:37 < barneygale> hey, sorry for being afk. Grum, I don't know exactly how to reproduce it, it just happens some times. Try rapidly joining and quitting a local server. I'm pretty sure the first packet is never sent. I'm using wireshark and following the TCP stream. The very first data sent is the "login start" packet which contains only their username.
22:38 < barneygale> The TCP connection is established, first data sent is that packet.
22:41 < barneygale> whoops, battery died
22:43 < dx> rip
22:48 < Thinkofdeath> Well I changed ef.class to add check in when a packet is sent ( https://gist.github.com/thinkofdeath/f4644d8f1f8bf426a038 ). When the stuck on "Logging in..." happens it prints "Error(jc) j is null", jc being the handshake and since j is null it is never sent
22:49 < Grum> Thinkofdeath: you can provide a log4j config that spits out debug stuff
22:49 < Grum> we have network level debug
22:49 < Thinkofdeath> no idea how to do that :P
22:50 < Thinkofdeath> Plus I don't see any logging if j in null, it just ignores it and carries on
22:51 < Grum> oh its in another file
22:52 < Grum> extract the log4j xml file
22:52 < Grum> edit it and provide: -Dlog4j.configurationFile=pathtoconfigfile.xml
22:54 < Grum> Thinkofdeath: change:                 <MarkerFilter marker="NETWORK_PACKETS" onMatch="DENY" onMismatch="NEUTRAL" />
22:54 < Grum> to:                 <MarkerFilter marker="NETWORK_PACKETS" onMatch="ACCEPT" onMismatch="NEUTRAL" />
22:54 < Grum> and you will have all the debug
22:55 < dx> neat
22:55 < Grum> go test it
22:55 < Grum> i havent actually tested it
22:55 < Grum> oh!
22:55 < Grum> and erm mmm
22:55 < Grum> you need to do more
22:56 < Grum> Root level="debug" i think
22:56 < Grum> and perhaps Configuration status="WARN"
23:02 < Thinkofdeath> Grum: I can't get the launcher to set -Dlog4j.configurationFile
23:05 < Grum> why not?
23:05 < Grum> just a jvm arg like -xmx :)
23:05 < Thinkofdeath> Well it might not be the launcher 
23:05 < Thinkofdeath> -Dlog4j.configurationFile=%appdata%/.minecraft/log4j2.xml  does nothing
23:05 < Grum> quite sure it doesnt expand
23:05 < Grum> give the full path
23:06 < Thinkofdeath> Ah that was it
23:06 < Thinkofdeath> Thanks
23:06 < Grum> lots of debug now?
23:07 < Thinkofdeath> yep
23:08 < Thinkofdeath> And now the issue stops...
23:08 < Grum> quite sure its a racecondition
23:08 < Grum> could be that this stops it from happening :/
23:10 < Thinkofdeath> Grum: Well j only gets a value when channelActive is called but you try and a packet straight away (unless I'm miss reading something)
23:10 < Thinkofdeath> (in ef.class)
23:28 < TkTech> Would be great to add that to the wiki.
23:36 < Thinkofdeath> Grum: http://hastebin.com/didiqelufa.java Better view at the race condition 
23:36 < Thinkofdeath> Which is why the handshake gets dropped
23:41 < Grum> j is channel O.o
23:41 < Grum> not sure how that even can be null
23:42 < Thinkofdeath> It is set in the Netty Client IO thread but used in the Server Connector thread
23:42 < Grum> so, sometimes the channel simply doesnt exist yet? O.o