18:39 < Grum> which kinda sucks
18:39 <+ammar2> pass the initialsize
18:40 < yawkat> ammar2: why?
18:40 < yawkat> 10 should be fine usually
18:40 <+ammar2> because the size is known
18:40 <+ammar2> it'll stop it from expanding everytime you call add
18:40 < yawkat> true, though then you should check for overflow there too :P
18:40 <+ammar2> and it minimizes overheads if <10
18:42 < Thinkofdeath> the size would need to be limited though
18:42 <+ammar2> true
18:42 < yawkat> yea, otherwise you can exploit that easily.
18:42 <+ammar2> anyway, nbt from the client should be up for more scrutiny
18:42 <+ammar2> than nbt used by the server for storage
18:43 <+ammar2> because even if you can expand it up to like 50 megs, you can easily spam it enough and get enough extra players to make it a problem
18:44 < Xor_Boole> remind me, why is the client allowed to send the entire book's nbt tag?
18:44 <+ammar2> well the block place is a hold over
18:44 <+ammar2> the creative one is a genuine use
18:45 <+ammar2> though honestly I think there's gotta be a better way to handle it
18:45 < Xor_Boole> well yeah but creative is, well, creative
18:45 < Thinkofdeath> creative should just be the client saying 'I clicked slot: X on tab: T'
18:45 < Thinkofdeath> and the server spawning the item
18:45 <+ammar2> that'd mean new items would have to be added at the end of tabs
18:45 < Thinkofdeath> would solve 90% of exploits, including the op one
18:45 <+ammar2> for new versions
18:46 < SinZ> I can see that ending horribly when you start considering search or mods
18:46 < Thinkofdeath> not really
18:46 < Thinkofdeath> the client and server are in sync anyway
18:46 < Thinkofdeath> if they weren't you'd have more issues
18:47 <+ammar2> oh right, the items at least stay the same
18:48 < SinZ> atleast currently, you can have a client mod add some items in the creative inventory, and when you pull them out they last a tiny bit in your survival inventory until the server validates and corrects it
18:48 < SinZ> but if you define the item that got put in your survival inventory by its coords in the creative inventory, you will have problems
18:51 < Thinkofdeath> those client mods are a pain
18:52 < Thinkofdeath> plus in creative there isn't any validation (for vanilla) for spawned in items
18:53 < Thinkofdeath> and doing it the way I suggested would mean that the validation wouldn't be required anyway
18:56 < TkTech> Well that's a fun backlog of chat.
18:57 < SinZ> heh
18:57 <+Amaranth> SinZ: Those mods are what he wants to block :D
18:58 < Xor_Boole> fun is an understatement
18:58 < Thinkofdeath> Amaranth: :D
18:58  * Thinkofdeath grumbles something about attributes
19:01 <+ammar2> is the nbt data actually used somewhere in the creative menu? can you spawn enchanted items or something?
19:01 <+ammar2> haven't actually played minecraft in ages
19:01 < SinZ> you can
19:01 < Xor_Boole> ammar2 yes
19:01 < Xor_Boole> enchanted books
19:01 <+Thinkofdeath> o.o
19:01 < cindy_k> heh
19:01 <+Thinkofdeath> shiny
19:01 <+SinZ> ooh shiny
19:01 <+SinZ> </3
19:01  * cindy_k gives a chocolate bar to Thinkofdeath 
19:03 < TkTech> g/o ammar2 
19:03 < TkTech> Er
19:04 < Xor_Boole> Thinkofdeath you're winner
19:05 < TkTech> Xor_Boole: You've been pretty active on IRC, you may want to pick a nickname and register it permanently with nickserv :)
19:06 < Xor_Boole> TkTech probs, jsut lazy =p
19:06 < Xor_Boole> sadly Xor is taken, so I enver got around to registering
19:06  * Xor_Boole goes off to stab nserv in the face
19:07 <+Amaranth> I have a feeling any fix for ammar2's thing CraftBukkit ever had was dropped when I saw the ReadLimiter class in the next update
19:07 <+Amaranth> Oops
19:07 <+SinZ> isn'
19:07 <+SinZ> isn't that dead
19:07 <+SinZ> (enter, stop pressing yourself </3)
19:07 < Xor_Boole> actually... is it?
19:07 < Xor_Boole> I don't think it is
19:07 < Xor_Boole> hmm, it is. odd
19:08 < Xor_Boole> is xorb taken though...?
19:08 <+SinZ> I thought people gave up trying to save it after the DMCA
19:08 < Grum> i guess we should allocate 40 bytes for each ListTag entry
19:08 < XorB> this is better
19:08 < Grum> err 4 bytes
19:08 < XorB> I hate long names
19:08 < TkTech> XorB: <3
19:09 < XorB> > already registered
19:09 <+Grum> It's a bit sad, it seems the only real issue is that 'EndTags' are not properly accounter for where they do take up space on the heap
19:09 < XorB> wat
19:09 <+Grum> that could have been communicated a bit nicer >.>
19:09 < XorB> welp looks like I'm stuck with XorBoole
19:10 < TkTech> (FYI the current round of +Vv is due to Freenode getting a bunch of channel spam again, I'm preempting having to set +m)
19:10 < XorBoole> there
19:10 <+XorBoole> hmm, shiny +D
19:10 <+XorBoole> s/+/=
19:11  * XorBoole goes off to edit his bouncer settings
19:11 <+Thinkofdeath> Grum: I went with 1 byte per an entry and it seemed to do the trick, since other entries should increase the limit themselves
19:12 <+Thinkofdeath> also could you make the limiter work in bytes not bits? thats just confusing :P
19:13 <+ammar2> lolwat, why does it work in bits
19:13 <+ammar2> that seems like asking for an overflow
19:13 < cindy_k> ha
19:13 <+Thinkofdeath> it counts in bytes, the increase method takes bits
19:13 < TkTech> Thinkofdeath: oO
19:13 <+Thinkofdeath> http://hastebin.com/okuxiyiwog.axapta
19:14 < TkTech> There's probably a reason for that, I just can't think of one.
19:14 <+Thinkofdeath> notchcode comes to mind
19:14 < TkTech> My immediate thought was optimal storage of booleans that never happened?
19:15 < yawkat> even then java allocs 1 byte for bools.
19:15 <+Amaranth> Nibbles?
19:16 <+Thinkofdeath> oh maybe, those aren't stored as a 'nibble' type
19:16 < yawkat> also the counter divides the increment input by 8 again and internally uses bytes
19:16 <+Amaranth> Well yeah it's stupid
19:16 <+Amaranth> You give it 4 bits for a nibble and it'll just convert to bytes, round to 1, and store that
19:17 <+Amaranth> So there is no point
19:17 <+Amaranth> But nibbles could still be why it took bits to begin with
19:17 < yawkat> itll round down actually.
19:17 < yawkat> does nbt have nibbles internally?
19:17 <+Thinkofdeath> no
19:17 <+Amaranth> I thought 0.5 would round to 1
19:17 < yawkat> Amaranth: integer division
19:17 <+Thinkofdeath> its integer division
19:18 <+Grum> Thinkofdeath: no, because then i cannot use the constants in java
19:18 <+Amaranth> I know, I can't remember the rules for that
19:18 <+Grum> Integer.SIZE etc are in our code
19:18 <+Amaranth> I mean, I thought I did but apparently not
19:18 <+Grum> https://gist.github.com/grum/1e632a85974af513747b <-- that should take care of it btw
19:18 <+Grum> but we still need to account for the 'ArrayList' object itself
19:18 < rom1504> 1=0*2+1
19:19 <+XorBoole> since when do primitives have a SIZE field?
19:19 <+XorBoole> TIL
19:19 < yawkat> its weird.
19:19 <+Grum> which would be ~40+4+4 bytes each
19:19 <+Amaranth> Alright so yeah, nibbles would be counted as 0, neat
19:19 < yawkat> Grum: and the wrapper object
19:20 <+Grum> yeah i guess
19:20 <+Grum> that is starting to get gross then
19:20 < yawkat> and the arraylist internal array
19:20 <+Grum> euuh?
19:20 <+Grum> yes that is 4 bytes
19:20 <+XorBoole> arrays have a header
19:20 <+Grum> and 4 bytes for the size
19:20 <+Grum> and 40 bytes for the object itself
19:20 <+Grum> or was it 48 mmm
19:21 < yawkat> an array list with a 0 array size is 24 bytes, including the internal array.
19:21  * XorBoole whips out Unsafe
19:21 <+Amaranth> Grum: Did you just not put a limit on the list size and then pass it to Lists.newArrayListWithCapacity?
19:21 < yawkat> actually, 28 bytes
19:21 <+Grum> yawkat: no? it only has Object[] which is 4 bytes and int size; which is another 4
19:22 <+Grum> unless it is hiding fields lower in the code >.>
19:22 < yawkat> Grum: im counting object headers
19:22 < yawkat> 8 bytes arraylist header + 4 ref to the array + 8 array header + 4 array len + 4 list size
19:22 <+Grum> java objects have 'fixed sizes' and are padded to 8 bytes
19:23 <+Amaranth> Of course you guys are all assuming CompressedOops, not that it'll likely make a difference
19:23 <+Grum> everyone is using CompressedOops unless >32gb
19:23 <+Grum> or you have been stupidly turning it off ;)
19:24 <+Amaranth> iirc if you do a lot of JNI it's good to turn it off
19:24 <+Thinkofdeath> I though linux 64bit had it off by default now?
19:24 < yawkat> Grum: if its padded then its 4 bytes more for the internal array but the rest should be the same
19:24 < yawkat> and that is less depending on internal array size.
19:25 <+Thinkofdeath> oh nevermind, I was wrong
19:25 < yawkat> Thinkofdeath: even if thats off, this is allocing lots of small objects without ref losses so it shouldnt use much more
19:25 <+Grum> Thinkofdeath: no everything has it on by default
19:27 <+Grum> but the real question is, what is the size of Object
19:27 <+Grum> because it is not just 4 bytes
19:27 < yawkat> 8 bytes i think in hotspot.
19:27 <+Grum> 12 for array
19:28 < yawkat> yea, because of the length field
19:28 <+Grum> i guess it is 4+4 for array though
19:28 <+Grum> and 4 for object
19:28 <+Grum> i presume compressedoops work on that too
19:28 < yawkat> its probably 4 for type and 4 for weird magic vm flags.
19:30 <+Grum> lets just presume for arraylist: 8 + 12 + 4 then
19:30 < yawkat> + 4 for the array ref
19:30 <+Grum> oh wait, forgetting the reference to the array
19:30 < yawkat> as i said, 28 :P
19:30 <+Grum> and then we need to figure out the exact sizes of all the nbt types
19:31 <+Grum> F U N
19:31 <+Thinkofdeath> Use unsafe and hope for the best?
19:31  * Thinkofdeath hides
19:31 < TkTech> (╯°□°）╯︵ ┻━┻)
19:31 < yawkat> Thinkofdeath++
19:32 < yawkat> actually, can you get total size with unsafe?
19:32 < yawkat> i dont think you can
19:32 < yawkat> only field offset and a good guess.
19:33 <+ammar2> well, what happens when the JIT inlines your code and suddenly you're only using 4 bytes :P
19:33 <+XorBoole> yawkat yes you can
19:33 <+XorBoole> or you can shove an agent in there and use Instrumentation
19:33 < yawkat> ammar2: can jit inline objects? and even then you only shot higher so its fine
19:33 < TkTech> ammar2: Using less bytes is fine I imagine
19:34 <+ammar2> yawkat: it can inline object creation if the object doesn't escape
19:34  * XorBoole inlines ammar2 
19:34 < yawkat> well it does escape
19:34 <+XorBoole> nbt objects have a habit of getting... throw around
19:35 <+XorBoole> then again, it shouldn't be terribly hard wihtout Unsafe
19:35 <+XorBoole> just reflectively iterate over the components
19:35 <+XorBoole> sizes of primitives are known, as are the sizes of pointers to reference fields
19:35 <+ammar2> well, yeah normally nbt objects do get passed around. but the one in block place is completely ignored last I recall
19:35 < yawkat> doesnt have to be that exact.
19:35 < yawkat> ammar2: i dont think it can inline that deep
19:36 < yawkat> it still has to alloc the whole tree
19:36 <+XorBoole> doesn't Compound use HashMap, too?
19:36 <+XorBoole> how big is HashMap, and how does it scale? presumably it's nonlinear?
19:36 <+ammar2> it does
19:36 <+ammar2> compound has a strict limit
19:36 <+XorBoole> nesting or size?
19:36 <+XorBoole> 512 is a big limit
19:37 <+ammar2> nesting limit
19:37 <+ammar2> iirc
19:37 <+XorBoole> it's 512, that's a bit large
19:37 <+Grum> not sure it nest-limits
19:37 <+XorBoole> Grum it does in CB, I dunno about your code
19:37 <+Grum> it does
19:37 <+Grum> 512 matters nothing
19:37 <+Grum> if object allocation is done right
19:37 <+Amaranth> HashMap size is complicated
19:38 <+Grum> very
19:38 <+ammar2> muh buckets
19:38 <+XorBoole> it'd hope it's concave-down in respect to size
19:38 <+XorBoole> s/size/element count
19:39 <+Amaranth> It's pretty much impossible to guess the size it'll be, it depends on insertion order and hashCode implementations.
19:39 <+XorBoole> I don't know enough about hashmap to give a good opinion
19:39 <+Amaranth> Ideally you'd end up with one item per bucket which is the least memory friendly situation
19:39 < yawkat> meh, just assume 16 bytes per item and that should be fine.
19:40 <+Amaranth> Although since it uses LinkedLists for the buckets I suppose there wouldn't be a difference in memory usage between two items in one bucket and two items in two buckets...
19:40 < yawkat> youre unlikely to hit the limit without reason anyway.
19:40 <+Amaranth> HashMap sucks, btw :P
19:40 <+XorBoole> Amaranth ur mum, Trebeck!
19:40  * XorBoole runs
19:40 < yawkat> the standard jre hashmap is pretty fast.
19:41 <+XorBoole> relative to what, LOHM? =p
19:41 <+Amaranth> The standard JRE HashMap looks like something they teach you to make in first year CS classes
19:41 <+XorBoole> > first year CS classes
19:41 <+XorBoole> those are a bit of a joke tbh. at least what I've seen
19:41 <+Amaranth> Exactly :P
19:41 <+XorBoole> friend of mine asked me if you could syncrhonize in a constructor
19:42 < yawkat> yea and then you asked us
19:42 <+XorBoole> and it's a hilarious idea
19:42 <+XorBoole> I also can't spell synchronize
19:42 <+Amaranth> Java's HashMap follows the theory of what a good HashMap would look like but completely ignores the fact that it has to run on actual computers and not theoretical Turing machines
19:42 <+XorBoole> real men use Unsafe.monitorEnter anyways
19:43 <+XorBoole> Amaranth you forgot the part about sane hashcodes
19:43 <+Amaranth> Well those aren't up to HashMap
19:43 <+XorBoole> hashmap should cope with semi-insane hashcode to some degree though
19:43 <+XorBoole> I'd hope it did, at any rate
19:44 < yawkat> Amaranth: i would guess that such a usual and often-reviewed map is pretty fast.
19:44 < yawkat> it actually got an update in 8 too.
19:44 <+XorBoole> yawkat break out caliper then
19:44  * XorBoole shoos yawkat to go do his benchmarking thing
19:44 < yawkat> map benchmarks are fast.
19:45 < yawkat> *hard.
19:45 <+Grum> this is so gross :/
19:45 < yawkat> Grum: just limit item count in one nbt env?
19:45 <+Grum> what?
19:46 < yawkat> like, max 1000 objects per nbt stream
19:46 <+XorBoole> ammar2 if anything, you'll be earning a nice bit of karma =p
19:46 <+Grum> yes, totally a good idea
19:46 <+Grum> negative karma :/
19:46 < yawkat> will totally not blow up in your face when loading worlds.
19:47 < yawkat> Amaranth: http://java-performance.info/hashmap-overview-jdk-fastutil-goldman-sachs-hppc-koloboke-trove-january-2015/
19:47 <+XorBoole> muh chest items containing chest items!
19:47 < yawkat> java hm scores pretty well.
19:47 <+XorBoole> yawkat that url doe
19:48 < yawkat> oh and Amaranth, they switched from a linked list to a treemap in 8.
19:49 <+Amaranth> yawkat: No, they put in some code to detect when they're getting too many items in a single bucket and switch the bucket to a treeset when that happens
19:50 < yawkat> well even then it seems to be a pretty fast approach.
19:50 <+Amaranth> So if you try to poison/hashdos a Java 8 HashMap you'll just collapse it to O(log(n)) performance instead of O(n)
19:50 <+XorBoole> I should look at the diffs for HashMap, sounds like an amusing read
19:53 <+XorBoole> ammar2 have you tried an attack using nested compounds rather than nested lists?
19:53 <+ammar2> yes, like I said there's a recursion limit on compounds
19:54 <+Amaranth> yawkat: That website basically says if you're doing Object-Object maps java's is alright but uses a bunch of memory. For anything else don't use it.
19:54 <+Amaranth> Oh, and also Trove sucks.
19:55 < yawkat> well object-object is what its made for, its not a fancy primitive one.
19:55 <+XorBoole> ammar2 doesn't your attack only use about 5 levels of recursion?
19:55 <+ammar2> yup
19:55 <+XorBoole> iirc the nest limit is pretty high, though I've porbably misread
19:55 <+ammar2> but its 5 levels of recursion with 10 objects at each layer
19:55 <+ammar2> so it grows exponentially to 10^5
19:56 <+XorBoole> ok, I feel stupid, let me check the limiter
19:57 <+Thinkofdeath> I still think your serialization was wrong with that somehow
19:57 <+Thinkofdeath> because that wasn't what the server was getting
19:57 <+Amaranth> yawkat: I suspect the other maps are doing poorly because they are slower for non-existing keys
19:58 <+Amaranth> Java's takes more or less the same amount of time whether the key is there or not, the others take longer if the key isn't there
19:58 < yawkat> Amaranth: even then the impact is miniscule and not relevant for most cases.
19:59 <+Thinkofdeath> ammar2: ah I think I found it, you named the lists when nested. Items in a list don't have names or types
19:59 <+Grum> oh shit, how long is a String :D
19:59 <+Amaranth> My last LOHM was about the same speed for non-existing keys as it was for existing ones, this makes me want to finish it up and throw it in this benchmark :P
19:59 <+ammar2> Thinkofdeath: that makes sense.
19:59 <+Grum> char[] + int; not too horrids
19:59 <+Grum> 8+4+12+4
19:59 <+Thinkofdeath> explains the weird sizes I was getting
19:59 <+ammar2> Grum: utf8 tho
19:59 < yawkat> Grum: i think its more on java 7.
19:59 <+ammar2> muh multibyte codepoints
19:59 <+Grum> that is just for 'header'
20:00 < yawkat> ammar2: its utf16 in java
20:00 <+Amaranth> ammar2: surrogate pairs
20:00 <+ammar2> is nbt utf16?
20:01 <+Thinkofdeath> in file its utf8, in memory its utf16
20:01 <+Amaranth> It was utf16 on disk before 1.7, right?
20:02 <+Thinkofdeath> nope
20:03 <+Thinkofdeath> nbt always was utf8
20:03 <+Grum> a fuck
20:03 <+Grum> we do not use FriendlyByteBuff :/
20:03 <+Thinkofdeath> its always done its own thing :P
20:03 < TkTech> Thinkofdeath: In memory it's a lot of things, newer JVMs use UTF-8 internally.
20:03 <+Grum> we have a limited utf8 readerer there, not in nbt :;
20:03 <+Grum> >.>
20:03 < yawkat> thats your internal class name for your special bytebuf? lol
20:03 <+Grum> yes :D
20:04  * yawkat PRs to spigot
20:04 <+Grum> FriendlyByteBuf because its friendly with lots of nice helper stuffs ;)
20:04 <+Thinkofdeath> TkTech: the class format is utf8, pretty sure the String object is still a char array
20:04 <+XorBoole> and this is why I /don't/ want to see the true mappings
20:04 <+Thinkofdeath> (char being uint16)
20:04  * yawkat prefixes all his classes with Cat
20:05 <+Grum> ugh there is not much to do about this
20:05  * XorBoole takes yawkat's yarn away
20:05 <+Grum> i cannot read the length of the string before i read it :/
20:05  * yawkat yearns for yarn
20:05 <+Grum> DataInput has no peeking >.>
20:06 <+XorBoole> Grum context?
20:06 <+Grum> https://gist.github.com/grum/5b70725ff071fcf898a5
20:06 <+Thinkofdeath> the funny thing is I'm pretty sure that data input is a ByteBuf wrapped in a ByteBufDataInputStream
20:06 <+Thinkofdeath> *ByteBufOutputStream
20:07 <+Thinkofdeath> *Input
20:07 <+Grum> Thinkofdeath: not in Nbt of disk at least
20:07 <+XorBoole> that's annoying
20:07 <+Thinkofdeath> oh thats true
20:07 <+Grum> the annoying part is the inflation factor 2
20:07 <+XorBoole> buuuut aren't string tags prefixed with their size in NBT?
20:07 <+Grum> you can read 2mb of data and allocate 4
20:07 <+Grum> but that is not 'THAT' bad
20:07 <+Grum> XorBoole: yes by writeUtf
20:07 <+XorBoole> oh, that's annoying
20:08 <+XorBoole> does DataInput mark?
20:08 < TkTech> Thinkofdeath: The class format is M-UTF-8, and up until recent the JVM used UTF-16 internally - now it's UTF-8.
20:08 <+XorBoole> mark, readInt, reset, read utf?
20:08 < yawkat> TkTech: string objects are still -16
20:08 <+Grum> no mark on datainput
20:08 <+XorBoole> oracle pls
20:08 <+Grum> no they are char[]
20:09 <+Thinkofdeath> TkTech: huh, they must be doing that internally, the String.java shows a char array still
20:09 < TkTech> Thinkofdeath: That's correct.
20:09 <+Grum> its UCS-2
20:09 <+Grum> partial mapping of UTF16 last i checked
20:09 <+XorBoole> Grum you could just reimplement .readUTF =s
20:10 <+Grum> XorBoole: lol you seen that code?
20:10 <+Grum> that is why i made one for FriendlyByteBuf
20:10 < yawkat> tip: you dont want to.
20:10 <+XorBoole> I'm afraid to at this point
20:10 <+Grum> you *really* do not want to
20:10  * XorBoole does it anyways
20:10 < yawkat> http://s.yawk.at/1cIk
20:10 <+Grum> it does the utf magic inlin
20:10 <+XorBoole> I've looked at reflection implementations and Im still safe
20:10 < TkTech> You guys don't get that you're all correct :)
20:10 <+XorBoole> s/safe/sane
20:11 <+XorBoole> Grum seen worse
20:11 <+XorBoole> much much worse
20:11 < TkTech> Depending on the JVM version, the distributions default flags, optimizations, the alignment of the sun and the moon
20:11 <+Grum> sure, but i cannot do anything with it
20:11 <+XorBoole> exhibit a: sun.reflect
20:11 <+Grum> beyond rewriting DataInput ;)
20:11 < TkTech> http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7129417
20:11 <+XorBoole> Grum *cough*asm*cough*
20:12 < TkTech> Like -XX:+UseCompressedStrings, which in Java 6 gives you mixed strings
20:12 <+Grum> XorBoole: not enough, you need java agents for that
20:13 <+XorBoole> annoyingly yes
20:13 <+Grum> AND asm :P
20:13 <+XorBoole> the client isn't an issue, the server on the other hand...
20:13 <+Grum> (i rewrote Object's constructor before heheh ... so much fun)
20:13 <+XorBoole> Grum pedestrian
20:13 <+XorBoole> once I made String a subclass of Int via unsafe
20:13 <+Thinkofdeath> you could always do what that one plugin did, inject an agent at runtime and rewrite random classes
20:13  * Thinkofdeath shivers
20:14 <+XorBoole> Thinkofdeath you know better than to give me ideas, Z750 will hate you for it
20:14 <+Grum> iirc you cannot do that unless the JVM is setup right?
20:14  * cindy_k shudders
20:14 < yawkat> it broke java 8 plugins, i remember that
20:14 < yawkat> Grum: you can with the attach api
20:14 <+Thinkofdeath> Grum: they bundled the dlls from the jdk and loaded them
20:14 <+Thinkofdeath> somehow it worked
20:15 < yawkat> ive done it too for my profiler, really fun but really evil.
20:15 < TkTech> yawkat: https://github.com/TkTech/Jawa/blob/master/jawa/util/utf.py#L12
20:15 <+Grum> scar-inducing shit
20:15 <+Thinkofdeath> yep
20:15 <+Grum> i thought it was horrible enough to load a javaagent to plant a callback in the Object's constructor
20:16 < yawkat> but yea, that plugin somehow managed to break other java 8 plugins by crashing the vm and the author refused to fix it.
20:16 <+Grum> so i could track allocation rates =)
20:16 <+Thinkofdeath> made tracking down issues fun, no way to tell which classes it swapped out
20:16 <+XorBoole> Thinkofdeath could you inject via JNI?
20:16 <+XorBoole> I'm pretty sure plugins have jni access
20:16  * XorBoole loves himself some good ol JNI
20:16 <+Grum> brrr
20:16 < yawkat> XorBoole: might as well use attach api at that point.
20:17 < yawkat> you cant do it with pure jni.
20:17 <+Grum> doing these horrible things now: https://gist.github.com/grum/0b33fed955491e2840d7
20:17 <+Grum> o.O
20:17 <+XorBoole> Grum are you terrified or is it still cold up there
20:18 <+XorBoole> Grum +1 for giving the semicolon its own line
20:18 <+Grum> and the prefixing +!
20:18 <+XorBoole> ++
20:18 <+Grum> meh now i need to do compound :/
20:18 <+Thinkofdeath> and comments! tis a rare sight
20:18 <+Grum> comments actually are a rare sight for my code
20:18 <+XorBoole> > commenting 
20:18 <+XorBoole> plebs
20:19 <+XorBoole> you should see my scala
20:19 <+Grum> but for this .... i kinda should
20:19 <+XorBoole> what is readable code
20:19 <+XorBoole> yawkat take note of the class names, we must update the mappings!
20:19  * XorBoole runs
20:19 < yawkat> hehe
20:20 < cindy_k> http://home.tamk.fi/~jaalto/course/coding-style/pic/comics-geekandpoke-the-real-coder.png
20:20 <+Grum> arggh should i change the default capacity of the hashmap? :/
20:20 < yawkat> cindy_k: akkarins comments in a nutshell
20:20 < cindy_k> lol
20:20 < yawkat> seriously
20:21 <+XorBoole> yawkat except they're in high german right
20:21  * XorBoole runs faster
20:21 <+Thinkofdeath> Grum: you don't have a way to get the number of elements in a compound, the default of 16 should be fine
20:21 <+Thinkofdeath> *in a compound before reading
20:21 <+Grum> yes but the problem is that its hard to figure out the real size then
20:21 < yawkat> https://github.com/LordAkkarin/AetherUtility/blob/master/src/main/java/com/torchmind/utility/aether/Aether.java#L127
20:22 <+Grum> i need to keep a counter and NOT allocate for the first 16 objects
20:22 <+Grum> or rather, until size == 16
20:22 < cindy_k> yawkat https://xkcd.com/1421/
20:23 < yawkat> :D
20:23 < yawkat> well according to red storm rising, when visiting iceland, you have to flee from russians all the time.
20:23 < yawkat> cant be that fun.
20:24 < cindy_k> but it has hot springs in snow and volcanoes
20:24 < cindy_k> sounds exciting
20:24 < yawkat> it also has no trees appearently
20:25 <+Thinkofdeath> Grum: do you really need to be that precise?
20:25 <+Thinkofdeath> seems overkill
20:26 <+Thinkofdeath> Grum: plus it wouldn't 16, it would be 16 * 0.75 before it resizes
20:26 <+Grum> if anything was shown today is that we need to be accurate O.o
20:27 <+Thinkofdeath> I thought it showed we needed to get rid of nbt from client->server? :P
20:28 <+Grum> wait --     static final Entry<?,?>[] EMPTY_TABLE = {};
20:28 <+Grum> its empty by default O.o
20:29 <+Grum> whoo and each entry is 8 + 16 bytes
20:38 <+Grum> this makes me sad on how java handles memory
20:39 <+Grum> also kinda sad this is needed :(
20:39 <+Grum> sofar the best abuse i can see is sending 2mb of strings that 'unpack' in just over 4mb of memory
20:41 < morfin> guys how Minecraft handle those rays of explosion?
20:41 <+Grum> shooting rays into the world
20:42 < morfin> each block spawn 1352  but they can grow exponentially
20:42 < morfin> i mean how it calculate those: it's impossible even theoretically
20:44 < morfin> that sounds like insane number of calculations: at least because each ray can have own intensity
20:45 <+Thinkofdeath> no one said the explosion code was fast/efficient
20:46 < TobiX> Make 3x3 TNT tower from bedrock to worldlimit, ignite, watch server performance grind to a halt ;)
20:46 < morfin> lol
20:46 < morfin> i did that on our server - it survived :(
20:47 < morfin> just worldedited and then everybody was wonderind what's that hole on map :D
20:47 <+XorBoole> Grum I dunno, rust's "pseudo-gc" system is a promising alternative
20:47 < morfin> *wondering
20:47 <+XorBoole> or are you refering to somethiung ekse?
20:48 < morfin> oh shi*
20:50 < morfin> that also calculates entities damage, also tnt entities can fly
20:50 < morfin> *primed tnt
20:50 <+Grum> yup
20:50 <+Grum> remember the 'we made an explosion of 1000000 strenght'-video?
20:50 <+Grum> that had to calculate for like 7 hours? :D
20:51 < morfin> holyshit
20:51 < morfin> "no lag really?"
20:52 < morfin> it looks like your machine is dying
20:53 <+Grum> this diff has gotten quite huge O.o
20:56 <+Grum> 420 lines of diffs, thanks ammar2
20:57 <+ammar2> blaze it
21:02 <+Thinkofdeath> Is this going to be 1.9, 1.8.4 or ninja fix?
21:04 < ScruffyRules> ninja fix!! ninja fix!!
21:05 < TkTech> It would take about 10 minutes to loop over server listings and crash them all soooooo...probably ninja fix.
21:05 < cindy_k> well not all of them :)
21:05 < LordAkkarin> wait? what? who? why yawkat?!
21:05 < LordAkkarin> Don't throw my code in here. You're going to blow my cover!
21:06 < yawkat> Tehe
21:06 < LordAkkarin> :<
21:08 <+Grum> You know, the stupidest thing is that most of the cause of this is 'ListTag' of EndTag
21:09 <+Grum> a quick hack would be disallowing that :/
21:09 <+Grum> only allow the type to be EndTag if size == 0
21:10 <+ammar2> yes, more quick hacks
21:12 <+Grum> ammar2: I really do not understand why you didn't just mention somewhere that 'EndTags in ListTags' had issues, would have been nicer
21:13 <+Grum> ammar2: especially since you are now pretending that nothing has been done with anything you've ever said to 'a mojang employee' which we both know is utter BS
21:13 <+ammar2> its the same proof of concept I sent back then
21:13 <+ammar2> did you just not test your fix at all
21:13 <+Grum> i've never gotten any proof of concept ever O.o
21:13 <+ammar2> ummm
21:13 <+Grum> wtf, who did you talk to besides me?
21:13 <+ammar2> grum, hold on.
21:14 <+Grum> The only thing I remember is discussing the possibility to have infinitely nested structures and totally out of bounds memory allocation because of absolutely no accounting
21:14 <+Grum> like doing a 'ByteArray' with Integer.MAX_SIZE as size, would just be allowed and we'd allocate the byte[] for it
21:15 <+ammar2> [15:52:04] <Grum> relayed data
21:15 <+ammar2> [15:52:13] <ammar2> thx
21:15 <+ammar2> [15:52:18] <ammar2> will you be relaying back any repsonses
21:15 <+ammar2> [15:52:44] <Grum> you'll see when it is solved; there is little to be responded about
21:15 <+ammar2> in response to me sending you the proof of concept
21:15 <+Grum> i seriously do not remember ever seeing any proof of concept
21:16 <+ammar2> http://pastie.org/pastes/8347418/text?key=yt7qnojkpy0cacfzmut22a
21:16 <+ammar2> you even commented about the code >.>
21:16 <+ammar2> [15:47:50] <Grum> misses data
21:16 <+ammar2> [15:48:08] <ammar2> hmm?
21:16 <+ammar2> [15:48:14] <Grum> +    with open('dump.nbt.gz', 'rb') as f:
21:16 <+ammar2> [15:48:59] <ammar2> yes...did you read the conversation? you're supposed to run a method first to generate that file
21:16 <+Grum> did you from the very moment use EndTags? O.o
21:17 <+ammar2> yes, its in the original code I sent
21:17 <+Thinkofdeath> that code has the same bug as the current one
21:17 <+Grum> I must have overlooked that then
21:17 <+Thinkofdeath> which causes the end tags
21:17 <+ammar2> honestly it just seems like you didn't bother testing with my code
21:17 <+Grum> I cannot run that code O.o
21:17 <+Grum> mac + python != working
21:17 <+Grum> or rather, crypto libs
21:17 <+ammar2> Grum, just stop.
21:19 <+Grum> Anyhow, my logs say the same, I did overlook the endtags, which ended up being a bit more buggy than intended
21:19 < morfin> it should work
21:20 <+Grum> but even if i would have caught that, it would have gone awry for other issues
21:20 <+Grum> morfin: should and do are two different things
21:20 <+ammar2> anything after <Grum> or rather, crypto libs? kinda timed out there, no scrollback
21:21 <+Thinkofdeath> http://hastebin.com/imeyenupey.xml
21:22 <+ammar2> thanks
21:23 <+Grum> But yes, I didn't test with the payload that created
21:23 <+Grum> I did test with other payloads, but since endtags themselves have no size (lal, java) i didn't use them
21:23 <+ammar2> and then you ignored me when I asked you on the status of the fix :|
21:23 <+ammar2> which I could have then retested with my code and showed you it didn't work
21:23 <+ammar2> can you see where I'm coming from here, from my perspective
21:25 <+ammar2> not that it matters now, whats done is done, but suffice it to say I didn't wanna go down this way either, I tried to be as reasonable as possible and waited
21:25 <+Grum> Yeah, i fixed the issue we discussed, i didn't fix the issue your proof of concept used
21:26 <+Grum> which in fact shows that there is a far bigger problem going on than just that
21:26 <+Grum> because we should be taking in account the actual memory-footprints of the objects we allocate
21:26 <+Grum> which ended up being a 400 line diff >.>
21:27 <+Grum> And even then, it is 'broken' because there is no way to guard to 'memory leaking' surrounding the readUtf8 bullshit
21:27 <+ammar2> yeah, its a complex problem
21:27 <+ammar2> I'd just have capped data from clients at .5kb and called it a day :P
21:28 <+Grum> which wont work
21:28 <+Grum> because you can explode 5k to a large size easily enough
21:28 <+ammar2> I mean like the actual nbt data
21:28 <+Grum> yes, and that wont work for big books
21:28 <+Thinkofdeath> or chests of chests of chests
21:28 <+ammar2> ehh yeah
21:28 <+ammar2> just make it so the client doesn't send nbt
21:28 <+Grum> its a hugely complicated problem >.>
21:28 <+ammar2> which is what I originally said
21:29 <+ammar2> ez pz
21:29 <+Grum> yes but the client has to be able to send nbt
21:29 <+Grum> else creative doesn't work
21:29 <+Grum> hmmm no, wait, that shouldn't be needed
21:29 <+Thinkofdeath> creative should just be a server side inventory they can grab from
21:29 <+Grum> yes tell Notch that
21:29 <+Grum> with his fucked up 'implementation'
21:29 <+Thinkofdeath> I wish I could
21:30 <+ammar2> mmyes lets all go to malibu and tell him that
21:30 <+Grum> https://github.com/java-decompiler/jd-gui
21:30 <+Grum> interesting!
21:30 <+Thinkofdeath> o.o
21:30 <+Thinkofdeath> its alive?
21:30 <+Thinkofdeath> and using gradle
21:31 < cindy_k> oh i should update
21:31 <+Grum> anyhow, i tested with your blob ammar2 >.>
21:31 <+Grum> that works now
21:31 <+ammar2> yay
21:31 <+ammar2> now we can all be a family again
21:32 <+Grum> initially on size, then i just let you *not* use EndTags in ListTag
21:32 <+Grum> and then i calculated all the fucking allocation sizes of the objects >.>
21:32 <+Grum> manyfuns
21:32 <+Thinkofdeath> I should really change my fix to that, I went for the quick fix option
21:32 <+Grum> ended up with https://gist.github.com/grum/ecece498e7bfa8a3459f
21:32 <+Grum> etc
21:33  * Thinkofdeath sticks with quick fix until 1.8.4
21:33 <+Grum> I'm not even sure if this is a good way to do it
21:33 <+Grum> I mean, this will let you 'roughly' allocate 2mb of JAVA memory
21:33 <+ammar2> jeez thats a lot of accuracy
21:33 <+Grum> yes but its needed ammar2 :/
21:33 <+Grum> and its not even accurate
21:34 <+Grum> you can make nested compound tags
21:34 <+Grum> you know what, can you do that? ;D
21:34 <+ammar2> yeah, I think Thinkofdeath had it right
21:34 <+ammar2> get rid of the slot in block place
21:34 <+ammar2> and fix the creative to be index and tab based
21:34 <+Grum> nested compound tags with a single letter key for names?
21:34 <+Grum> right unto the limit of 2mb? :D
21:35 <+ammar2> Grum: you have a limit on compound recursion
21:35 <+ammar2> that's one of the first things I had you fix
21:35 <+Grum> then do it onto the limit and then add a second key to the first one
21:35 <+ammar2> yeah you really should have some sort of amount of x thingy
21:35 <+Grum> because each of those objects if you add one key, is going to allocate 15*4 bytes excess
21:35 <+ammar2> but shit, only client data needs to be scrutinized this hard
21:36 <+ammar2> there has to be a better way
21:36 <+Grum> yeah on the server it gives no fuck
21:36 <+Grum> it uses an Accounter.UNLIMITED
21:39 <+ammar2> Grum: how do you feel about not sending nbt at all
21:39 <+Grum> looking into it now
21:40 <+Grum> seems to be 3 packets
21:40 <+ammar2> really?
21:41 <+Thinkofdeath> BlockPlace, Creative, PluginMessage:MC|BEdit and PluginMessage:MC|BSign
21:41 <+Thinkofdeath> from the top of my head
21:41 <+Grum> hmz yeah custom does stuff too
21:41 <+ammar2> and ClickWindow
21:41 <+ammar2> didn't notice that one before
21:41 <+Thinkofdeath> ah
21:42 <+ammar2> ClickWindow is so convoluted :D
21:42 <+Thinkofdeath> the bukkit side of it will make you cry :P
21:42 <+XorBoole> a lot of things in bukkit will make you cry
21:43 <+Grum> yeah it seems ClickWindows is rather hard ingrained :/
21:43 <+Grum> i wonder, it just uses it to check if you clicked 'the right item'
21:43 <+Grum> we could just hash the nbt >.>
21:44 <+Thinkofdeath> it seems to be
21:44 <+Thinkofdeath> if (ItemStack.matches(packetplayinwindowclick.e(), itemstack)) {
21:44 <+Grum> but unless you cache that you just added another cpu-exploit
21:45 <+Grum> where you can spam the packet and have it hash the nbt of an item in the inventory
21:45 <+Grum> make it sufficiently big, like a book .....
21:45 <+Thinkofdeath> heh, if the itemstack doesn't match the server resends the whole inventory
21:45 <+Grum> yeah it has to
21:45 <+Thinkofdeath> feel like thats a bigger issue than the hash
21:46 <+Grum> not really resolvable unless we fix the whole inventory code
21:46 <+Grum> but even then, if anything is wrong, everything is wrong by definition
21:47 <+XorBoole> > inventory
21:47 <+XorBoole> > fixable
21:47 <+XorBoole> haha. hahaha. hahahhahaha. haha. ha. haha. no
21:48 <+XorBoole> I think you mean "unless we burn all the inventory code and rewrite from scratch"
21:48 <+Grum> we only started that once ;D
21:48 <+Dinnerbone> We did that once.
21:48 <+Grum> we can pick that back up again
21:48 <+Dinnerbone> We had issues with testing so we had to shelve it
21:48 <+Grum> eventually o.O
21:48 <+Grum> we now know what we did wrong hehe
21:49 <+Grum> Dinnerbone: would be super nice not to have to handle nbt client->server :/
21:49 <+Grum> because my 400 line diff is NOT PRETTY++
21:49 < TobiX> Yay, jd-gui... Maybe someone... decompiled it? (I'll see myself out...)
21:49 <+XorBoole> oh, it can be fixed, but it requires locking the two of you in a closet until it gets fixed.
21:49  * XorBoole runs
21:49 <+XorBoole> > jd-gui
21:49 <+Grum> we could optionally also enforce a client->server packet-limit-size (with CustomPayload as exception)
21:49 <+XorBoole> pls, fernflowermasterrace
21:50 <+Dinnerbone> It would also be a much bigger diff, protocol change, and break a brand of client mods (any inventory one that lets you customise items)
21:50 <+Grum> anyhow! bed here
21:50 <+Dinnerbone> I agree nbt shouldn't be sent to the server but it's too big of a change to do in a rush.
21:50 <+XorBoole> I can't picture any elegant solution
21:50 < cindy_k> 1.9 :D
21:50 <+Grum> yes, so maybe the changes i've prepped now and a protocol level 'you cannot send big data to the server' might work
21:51 <+XorBoole> I love zip-bomb exploits...
21:51 <+Grum> there is no reason why any packet should be >500 bytes
21:51 <+Grum> or 5kb 
21:51 <+Thinkofdeath> unless its holding a book and right clicking
21:52 <+XorBoole> Grum uhh, you certain? give me a second, I think I have a counterexample on the tip of my tounge
21:52 <+Grum> yeah for that we could send the hash perhaps?
21:52 <+Grum> not sure where we use the clicking data for anyhow
21:52 <+Thinkofdeath> same as window click
21:52 <+XorBoole> the book protocol is just a lot of nope. it's super annoying how it's implemented, namely that the server is not notified of book openings
21:52 <+Grum>             if (!ItemInstance.matches(player.inventory.getSelected(), packet.getItem())) {
21:52 <+Dinnerbone> It should be noted that mods like TMI will not be possible if we remove client->server nbt, sadly
21:53 <+Grum> for that we can just check if the 'slot' is the same without checking the whole frikking item
21:53 <+Thinkofdeath> Dinnerbone: good, bain of my life
21:53 <+ammar2> Grum: whats the maximum uncompressed size the server accepts from a client?
21:53 <+XorBoole> Dinnerbone is TMI still a thing?
21:53 <+Grum> 1<<21
21:53 <+Grum> (2mb)
21:53 <+XorBoole> they can use the new /give anyways
21:53 <+ammar2> Grum: compressed?
21:53 <+Grum> uncompressed
21:53 <+Dinnerbone> "Mods like" :p
21:53 <+Thinkofdeath> Dinnerbone: spawning in items with max health attributes set to 0 to kill creative players isn't fun to deal with :P
21:53 <+Dinnerbone> Yeah of course
21:54 <+Dinnerbone> As I said, client->server custom items isn't a good thing anyway. I was just pointing that out.
21:54 <+Grum> ammar2: the hard-limit on packets we can read is 2mb
21:54 <+Thinkofdeath> :)
21:54 <+Dinnerbone> I like to point things out. Like your new shoes! Very fancy.
21:54 <+ammar2> Grum: umm, how much data can you zlib compress into 2mb
21:54 <+Thinkofdeath> o.o I got new shoes?
21:54 <+ammar2> a lot I'm guessing
21:54 <+XorBoole> Dinnerbone I disagree, they suck
21:54 <+ammar2> that's gonna be a in a buffer somewhere
21:54 <+Thinkofdeath> I haven't had new shoes in years
21:54 <+XorBoole> thinky has no taste
21:54 <+Grum> ammar2: yes but we allocate a buffer with the size you tell us in which we deflate
21:55 <+Grum> ammar2: so if you claim your 2mb of zlib data is only 2mb unpacked (anything more will get you a disconnect)
21:55 <+ammar2> aah okay
21:55 <+Grum> ammar2: it will still only unpack into a 2mb buffer and then crash
21:55 <+ammar2> and what's the hard cap on compressed data?
21:55 <+Grum> (because of not reading all the data of the socket)
21:55 <+Grum> ammar2: 2mb uncompressed
21:55 <+Grum> we cannot cap it
21:55 <+ammar2> right, but the buffer for inflation
21:55 <+Grum> as you dont know the size
21:55 <+Grum> the inflation buffer is 2mb max
21:56 <+ammar2> oh all right
21:56 <+ammar2> this was actually harder to do back when you had gzip and a short header :P
21:56 <+Grum> its just annoying that a EndTag object is allowed to exist in a ListTag which is not empty
21:56 <+Grum> and THAT is notch code
21:57 <+XorBoole> why isn't EndTag a singleton?
21:57 <+Grum> because notch made nbt
21:57 <+XorBoole> touche
21:57 <+Grum> anyhow, bed!
21:57 <+XorBoole> > bed
21:58 <+XorBoole> lies
21:58 < cindy_k> client nbt -> server gets you lovely potions like this: http://i.imgur.com/8YlWJAk.png
21:59 <+XorBoole> > lovely
21:59 <+XorBoole> > potion
21:59 < cindy_k> luckily thinkofdeath fixed it so it stopped crashing the server
22:00 <+XorBoole> is that magic text too?
22:00 < cindy_k> yep
22:00 < cindy_k> it was quite impressive
22:23 < cindy_k> .log
22:24 <+Thinkofdeath> .twig
22:25 < dx> .plank
22:25 < cindy_k> .twig
22:25 < cindy_k> lol nope
22:30 < TkTech> http://arstechnica.com/security/2015/04/just-released-minecraft-exploit-makes-it-easy-to-crash-game-servers/
22:30 < TkTech> Slow news day.
22:32 < cindy_k> :/
22:32 <+Thinkofdeath> psh, crashing vanilla isn't hard anyway
22:33 < cindy_k> heh truth
22:33 < cindy_k> I wrote a script to just restart it when it crashes every other day for no reason
22:34 < TkTech> "You wouldn't have these problems if Minecraft was written in <insert language>"
22:35 <+Amaranth> What language would be safer from this than Java?
22:35 < MrARM> then we could have nicer exploits lol
22:35 <+Amaranth> I mean, not even Rust would save you from this and I usually trot it out for things like this :P
22:35 < MrARM> maybe some nice buffer overflows causing code executions instead of a oom exception? :)
22:35 < dx> Amaranth: shhhh, don't think too much about it, people will say java sucks anyway
22:36 <+Amaranth> Java is probably better than most others you could have chosen because sometimes you can recover from OutOfMemoryException
22:36 <+Amaranth> Rust just aborts
22:36 < cindy_k> defensive programming is a pain and requires 4000 more lines of code. Doesn't matter the language
22:36 < MrARM> you know, the main reason Minecraft is in java is because it was a prototype at start
22:36 < dx> this one also fits with the "stereotype" of "java uses a lot of memory", it's perfect
22:37 <+Amaranth> MrARM: Nah, it was because notch knows Java
22:37 < MrARM> that too
22:37 <+Dinnerbone> We actually do catch OutOfMemoryException in mc, but only to do any emergency saving before continuing to panic and die. :D
22:38 <+Amaranth> iirc my "fix" for this was to catch OOM and drop the connection
22:38 <+Dinnerbone> (As it probably should be, in my opinion. You don't silently let that happen.)
22:38 <+Amaranth> I suppose that would have failed with the switch to netty anyway
22:38 <+Thinkofdeath> You also catch all fatal errors somewhere, although that might have been the task queue which has been fixed
22:38 <+Amaranth> If it ever worked at all
22:39 <+Amaranth> I think that was only for books too
22:54 < ScruffyRules> Dinnerbone, +1 for emergency saving
23:00 <+Amaranth> According to https://www.reddit.com/r/admincraft/comments/32t9si/hey_radmincraft_i_found_a_security_vulnerability/cqemhmd maybe my "fix" did work
23:00 <+Amaranth> Sometimes anyway
23:06 <+Thinkofdeath> Amaranth: it will sometimes recover, depends on where it OOMs 
23:07 <+Amaranth> I'd just like to say again that NBT is shit
23:07 <+Thinkofdeath> pretty sure this whole channel agrees with you there
23:08 <+Amaranth> Although in this case it's not even really NBT's fault so much as the way the network layer sends NBT
23:09 <+Amaranth> Well, and how much memory 2MB of NBT can turn in to with the MC NBT implementation
23:10 < gurun> cindy_k, instead of defensive coding i recommend the crash hard and fast. It's a bit of a pain in the beginning, but quickly bashes out the bugs.
23:10 <+Thinkofdeath> could have done it with a few bytes, Compound -> List(Type:0, Length: Integer.MAX_VALUE)
23:10 <+Thinkofdeath> maybe add a few more lists for great effect
23:11 < gurun> i think the MCPE team recently changed to the crash hard and fast approach.
23:11 < gurun> :-P
23:14 < gurun> or maybe they had that approach, but didn't have bugs until shoghicp starterd: http://lbsg.net/blamemojang.php
23:15 < shoghicp> gurun: :P
23:16 < gurun> seems he did a reset on the stats, and now you are a lonely leader :-)
23:17 < shoghicp> meh
23:17 < shoghicp> I have the blameshoghicp page
23:17 < shoghicp> at least it's better than the "shoghicp smells" page
23:18 < cindy_k> lol
23:18 < shoghicp> gurun: he did not. someone pointed a script and started blaming me
23:19 < TkTech> *whistles*
23:19 < gurun> haha .. yeah right. Last time i checked you and tomcc was around 14k .. now you only got blamed 11k and tomcc almost nothing. That is obviously not fair. Hmm, did tomcc perhaps make the script?
23:19 < gurun> i mean, it's not fair that you *only* have 11k blames. The blame is all on you :-P
23:20 < TkTech> Don't worry he's at 12k now.
23:20 < gurun> lol
23:20 < shoghicp> gurun: http://account.lbsg.net/blameshoghicp.php
23:20 < shoghicp> add those
23:21 < gurun> ah, was it two different scripts.
23:21 < shoghicp> yeah, this is the old one
23:22 < gurun> i'll hook that URL as a post-event to my compiler i think...
23:27 < TkTech> "You have hit your vote limit for the day."
23:27 < TkTech> D'aw.
23:52 <+AndrewPH> >no "blame notch" page
23:52 <+ammar2> I think the meanwhile at mojang page took care of that
23:53 <+AndrewPH> implying notch is part of mojang
23:53 <+ammar2> pftt, he was when the gif was made
23:53 <+AndrewPH> well, yeah
--- Day changed ven. avril 17 2015
00:19 < TobiX> Ars is really good at choosing stock pictures /s
00:19 <+ammar2> they don't call them arse for nothing
00:24 < TobiX> ammar2: Hey, at least the Ars comments are providing you with free memes: http://i.imgur.com/v90pVqe.jpg
00:24 <+ammar2> yeah those were some quality comments
00:24 <+ammar2> I liked the obi wan one
00:34 < TobiX> Oh by the way, since someone briefly mentioned compressed Oops: http://java-performance.info/over-32g-heap-java/ ...
00:35 < TobiX> Most interesting takeaway from that article: Setting Heap Size to anything between 32 and 37 GB is pretty useless :)
01:20 < DemiPixel> Anybody know of a rate limit on mojang authentication?
01:22 <+Thinkofdeath> 600 req / 10 minutes for api.mojang, 1 req / 1 min / per uuid for the session server skin blobs
16:37 <+XorBoole> did 1.8.4 finally fix custom skin URLs?
16:37 <+XorBoole> (about time, too)
16:37 <+XorBoole> I haven't tested but I saw a reddit post to that effect
16:38 < redstonehelper> OP doesn't explain :/
16:39 < redstonehelper> maybe/probably in response to things like this: http://www.reddit.com/r/Minecraft/comments/32md2t/since_map_makers_can_use_custom_skulls_and_log/
16:40 <+XorBoole> redstonehelper I'm aware of that silliness
16:40 <+XorBoole> that's what I assumed this was about
16:41 <+XorBoole> frankly I'm glad, there were too many annoying things you could do with that
16:42 < redstonehelper> XorBoole: he replied now http://www.reddit.com/r/Minecraft/comments/32xdcl/the_end_of_custom_player_heads/
16:42 <+XorBoole> excellent
16:43  * XorBoole jams 1.8.4 into fernflower and geps
16:46 <+Thinkofdeath> o.o what else made it into 1.8.4?
16:47 <+ammar2> Thinkofdeath: https://mojang.com/2015/04/minecraft-1-8-4-security-release/
16:47 <+Thinkofdeath> That list doesn't include everything
16:48 <+Thinkofdeath> theres a new flag for ops.json for example
16:49 <+XorBoole> can't find a whitelist, oddly...
16:49 <+Thinkofdeath> XorBoole: looking at the error they just check the signature
16:50 <+XorBoole> Thinkofdeath 
16:50 <+XorBoole> https://gist.github.com/drXor/8ca460f96fdf08e8a70d
16:50 <+XorBoole> eh
16:50 <+Thinkofdeath> oh wait, whitelist. whoops missed that part
16:50 <+XorBoole> that's from spigot fernflower, which failed to decompile some classes
16:51 <+XorBoole> (for whatever reason)
16:51  * XorBoole tries binary grep on the classfiles
16:53 <+Thinkofdeath> private static final String[] WHITELISTED_DOMAINS = { ".minecraft.net", ".mojang.com" };
16:53 <+Thinkofdeath> in authlib
16:53 < barneygale> Fun
16:54 <+XorBoole> ohwouldyoulookatthat
16:55 <+XorBoole> is authlib os? I can't remember... I feel like it's not
16:55 <+Thinkofdeath> it was by mistake at once point :P
16:55 <+Thinkofdeath> its not obf'd anyway
16:55 <+XorBoole> tbh it should be
16:56 <+XorBoole> it's useful
16:56 <+Dinnerbone> Thinkofdeath: by mistake?
16:56 <+Dinnerbone> The source is included, no?
16:56 <+Dinnerbone> At the very least we don't obfuscate it, and it's documented
16:56 <+Dinnerbone> It's just not officially supported for external use
16:56 <+Thinkofdeath> sources jars were on libraries.minecraft.net, pretty sure they disappeared later
16:57 <+Dinnerbone> Well I just took a look and the source jars are there for the latest version
16:57 <+Thinkofdeath> yeah, just checked
16:57 <+Thinkofdeath> maybe I picked a version were they were missing
16:57  * Thinkofdeath shrugs
16:58 <+XorBoole> ah, i forget libs aren't shaded into the client jar
16:59 <+Thinkofdeath> Dinnerbone: can't find a version missing the sources jars, going to mark this as me being dumb
16:59 <+Thinkofdeath> normally the correct answer in most cases
16:59  * Dinnerbone hugs Thinkofdeath and hands him a cookie jar
16:59 <+Thinkofdeath> :D
16:59 <+Dinnerbone> Now go fill it up, there's a good chap.
16:59 <+Thinkofdeath> o.o
16:59 <+Dinnerbone> :D
17:00  * Thinkofdeath fills it up with smarties
17:00 <+Thinkofdeath> Never liked cookies anyway
17:00 <+Dinnerbone> Which kind?
17:01 <+Dinnerbone> Oh who am I kidding, I don't mind. They're both yummy.
17:01 <+Thinkofdeath> :)
17:01 <+XorBoole> coooookies!
17:01  * XorBoole tackles Dinnerbone and takes cookies.jar
17:01 <+Dinnerbone> It's empty, you fool!
17:02 <+Dinnerbone> Now we have no cookies AND no jar :(
17:02 <+XorBoole> shhh, no tears, only dreams
17:02  * XorBoole covers Dinnerbone's eyes and puts the jar on his head
17:03 <+Dinnerbone> But I can't walk in this!
17:04 <+XorBoole> shhh, good night sweet prince
17:07 <+SinZ> wtf did I walk into
17:08 < TkTech> I don't know but I want an adult.
17:08 < barneygale> ^
17:08 < barneygale> infantilism is infuriating
17:09 <+XorBoole> I'm an adult. =D
17:14 <+Thinkofdeath> barneygale: could be worse, everyone acts like cats in my channel and I have no idea why
17:14  * XorBoole purrs at Thinkofdeath 
17:14 < barneygale> That is a strange problem to have :P
17:20 <+XorBoole> barneygale it's a bug with the spi.gt servers, it turns everyone into cats
17:20 < TkTech> http://i.imgur.com/AV242XW.png
17:20 < TkTech> I wonder if something happened yesterday?
17:20 < TkTech> (lol)
17:21 <+Thinkofdeath> lol
17:21 <+XorBoole> TkTech label your axes pls
17:21 < TkTech> -_- It's google analytics you scrub
17:21  * XorBoole looks again
17:21 <+XorBoole> of?
17:22 <+XorBoole> wiki.vg?
17:22  * Thinkofdeath looks at the channel we are in
17:22  * Thinkofdeath smacks XorBoole 
17:22 <+XorBoole> I need my coffee
17:24 < TkTech> ammar2: That'll be $59.99 for bandwith please
17:24 <+XorBoole> plus shipping and handling
17:27 < Fenhl> lol
17:31 <+ammar2> TkTech: pls help how do I bandwith https://i.imgur.com/KoOC4lj.png?1
17:41 < TkTech> ammar2: Wait, you're actually hosting a static blog yourself? Use das github.
17:41 <+ammar2> TkTech: its on github, that's the cloudflare analytics
17:43 < barneygale> has anyone attempted a minecraft network fuzzer? that might be fun
17:52 < TkTech> ammar2: Ah, haven't seen it before
19:38 <+Grum> Dinnerbone: they found out!
21:21 <+Amaranth> Dinnerbone: Why is https://dinnerbone.com/butts.png still a 404?
21:22 <+Dinnerbone> It's where I store all the selfie pictures of butts I get sent. I store the pictures of my own butt somewhere else, but I can find that url for you if you wish.
21:23 <+Dinnerbone> http://i.imgur.com/sovHA6E.jpg
21:25 <+Amaranth> Dinnerbone: That's the kind of thing I expected https://dinnerbone.com/butts.png to be :P
21:25 <+Dinnerbone> Oh good idea let me redirect that.
21:26 <+Dinnerbone> Fixed. You're a good friend, Amaranth. <3
21:26 <+Amaranth> Although redirecting people to imgur while telling them you don't trust imgur might not be so hot :D
21:31 <+Dinnerbone> That's not what I meant <_<
21:31 <+Dinnerbone> I said that I shouldn't make everybody else trust imgur just because they trusted me.
21:31 <+Amaranth> hehe, I know, but they're pissed off at you so will they?
21:31 <+Amaranth> btw I never thought about all the evil shit you can do with skulls not being whitelisted
21:31 <+Amaranth> Crazy
21:35 <+Dinnerbone> :(
21:43 < TkTech> Wait, what sillyness is this? Did you endorse imgur?
22:00 <+XorBoole> what's wrong with imgur =<
22:12 < ScruffyRules> Dinnerbone, Are you implying you want butts to be sent to you?! ;P
22:12 <+ammar2> who doesn't want butts to be sent to them?
22:13 < ScruffyRules> Lemmie mention CP and then i'll say me. :P
22:46 < gurun> guess it can't get more "on topic" than this :-)
23:04 < Aragasas> Okay, why is pre-release protocol empty? No network updates on 1.8.4?
23:05 <+XorBoole> Aragasas nope
23:05 <+XorBoole> security update
23:05 < Aragasas> and performance, as i heared
--- Day changed sam. avril 18 2015
15:31 < SopaXorzTaker> https://imgflip.com/i/kc6n8
15:31 < SopaXorzTaker> offtopic
15:40 < Not-5450> [wiki.vg] Edit by Dkkline to Library List -> http://wiki.vg/index.php?title=Library_List&diff=6588&oldid=6535
16:20 < Not-5450> [wiki.vg] Edit by Thinkofdeath to Client List -> http://wiki.vg/index.php?title=Client_List&diff=6589&oldid=6584
16:33 < barneygale> Is that Library List page in any particular order? I should add quarry but I don't know where to insert it
16:36 <+Thinkofdeath> it should be newest version first
16:36 <+Thinkofdeath> looks like it needs a resort
16:37 < barneygale> newest protocol supported?
16:37 <+Thinkofdeath> yes
16:37 <+Thinkofdeath> so 1.8.X top, then 1.7.X etc
16:38 <+Thinkofdeath> the order is kinda there already, just a few things out of place
16:38 < barneygale> is it worth listing libraries that support 1.1 etc do you think? I was thinking maybe 1.5 and older should go
16:38 < barneygale> as almost everyone is running 1.6+ right?
16:38 <+Thinkofdeath> might as well keep them there for historical reasons, just make sure the version is red
16:39 < barneygale> fair
16:39 <+Thinkofdeath> 1.7 should be red too
16:39 < barneygale> alright, I can do this if you'd like
16:39 < barneygale> f1 isn't on for another 20 minutes ;)
16:39 <+Thinkofdeath> sure :)
--- Day changed dim. avril 19 2015
01:52 < Gjum> does the server confirm all click transactions? or only some of them?
03:20 < rom1504> Gjum: https://github.com/andrewrk/mineflayer/blob/master/lib/plugins/inventory.js#L351
03:55 < Gjum> rom1504: that was the line that made me ask. I'm not sure if this is still the case over 2 years after that code was written.
03:56 < Gjum> besides, transactionRequiresConfirmation() always returns true: https://github.com/andrewrk/mineflayer/blob/a02db44db3e7b8c092a0bfdbace35515bd7f6039/lib/windows.js#L248-L250
08:01 < conji> Question: when breaking a block and the block constantly drops, each time from a slightly higher height with a glitchy framerate, what might be the problem?>
08:02 < conji> When the client breaks the block, all I do is send a Spawn Object packet with data as if it were a standard dirt block.
17:03 < Aragas> Just connected from my android device to modern server
17:03 < shoghicp> :o
17:03 < Aragas> Epic win
17:04 < shoghicp> Did that a few months ago, but I decided to do it the other way :)
17:04 < shoghicp> that reminds me, I've to update it :S
17:04 < Aragas> That's nice
17:05 < Aragas> I'll try now to use rendering as is, but, i'm sure that it will be a bit broken
17:06 < shoghicp> anyway, did you implement your own client?
17:07 < Aragas> yep
17:08 < shoghicp> nice
17:08 < Aragas> It will be really nice when it will render chunks
17:10 < shoghicp> it's always good to see the world :)
17:11 < Aragas> :(
17:12 < Aragas> Android don't like my render code
17:32 < Aragasas> It works
17:33 < Aragasas> A bit slow, but works
17:34 < Aragasas> http://i.imgur.com/EZKEWC5.png
17:50 < Aragasas> http://i.imgur.com/yuEl5h5.png http://i.imgur.com/q67ry0x.png http://i.imgur.com/qb9wK1V.png There are some minor problems with those white lines
19:47 < rom1504> Gjum: oh ok, then I don't know
20:47 < Not-5450> [wiki.vg] Edit by Tml to Mojang API -> http://wiki.vg/index.php?title=Mojang_API&diff=6590&oldid=6525
21:08 < Not-5450> [wiki.vg] Edit by Redstone sheep to Mojang API -> http://wiki.vg/index.php?title=Mojang_API&diff=6591&oldid=6590
23:50 < ispillmydrink> Hey all.
23:51 < ispillmydrink> Just saying hi, wanted to introduce myself. Releasing an app soon. :)
23:52 < ispillmydrink> The wiki is super helpful. Thank you!
23:52 < jython234> an app?
23:53 < ispillmydrink> Yeah, it’s just a server status monitor for Mac.
23:53 < ispillmydrink> Will do a Windows version soon, all of the business logic is C#.
23:56 < jython234> nice
23:59 < ispillmydrink> http://i.imgur.com/JaDp37K.png
--- Day changed lun. avril 20 2015
00:04 < ScruffyRules> Better than I was expecting ispillmydrink.
00:04 < ScruffyRules> Great job. +1
00:04 < ispillmydrink> Thanks!
00:05 < ispillmydrink> I never think of good personal projects/never have time because of work, so I used a bunch of PTO. Heh.
00:16 < Aragasas> Really nice
00:23 < ispillmydrink> Definitely some funky challenges for this kind of thing. Heh.
00:28 < Gjum> ispillmydrink: whoa, nice stuff! cool idea to support importing servers.dat
00:30 < ispillmydrink> I was originally going to support file-change events on the actual servers.dat file so it’s zero-conf, but I wanted to support sandboxing (urgh) on Mac and getting to a different app’s Application Support directory is a pain.
00:30 < ispillmydrink> Will still do that for Windows, though.
00:31 < dexter0> Just grant yourself an entitlement to ~/Library/Application Support/Minecraft
00:31 < dexter0> unless you're going to put this on the MAS
00:32 < Gjum> so the user will be able to add servers to servers.dat through creepr?
00:33 < ispillmydrink> It’s only one way right now. I figure users might not actually want to be watching every server in there. I was going to make it so you can disable monitoring on specific servers, but I thougt it’d be better to keep it simple initially.
00:33 < Gjum> ok
00:34 < Gjum> yeah, keeping it simple is often the better way.
00:34 < ispillmydrink> I kinda want to be reactive to user requests anyway so I can prioritize
00:34 < ispillmydrink> Over time
00:35 < ispillmydrink> Gotta run.
00:35 < ispillmydrink> Nice to meet you guys. Thanks again!
20:08 < TkTech> I imagine a few people here play EVE?
21:46 <+XorBoole> TkTech pls no
21:53 < TkTech> XorBoole: Is that a yes or a "please don't make me resub"? :D
21:54 <+ammar2> XorBoole is feeling the call of the spreadsheets
21:56 < TkTech> XorBoole: https://www.youtube.com/watch?v=AdfFnTt2UT0
21:56 < dx> "uncensored" sounds nsfw
21:56 < TkTech> While I spend most of my time going "pew pew" I would a liar if I said I don't have many, many spreadsheets.
21:58 < TkTech> Fleet operations are incredibly fun in EVE, especially when days of planning pay off, or a massively overwhelmed fleet suddenly has hero super capitals cyno onto the field.
21:59 < TkTech> dx: A few swearwords, tame if you've got headphones :)
22:01 < dx> TkTech: this actually looks fun. is it as fun as this thing makes it seem?
22:01 < TkTech> Absolutely, just avoid the trap many new players get into where they PvE or grind for days.
22:01 < TkTech> Don't immediately try to skill towards a battleship or expensive hulls, buy 300 small frigates and go get blown up 299 times
22:02 < dx> i know none of those words
22:02 < TkTech> Join a public NPSI fleet and go swarm a super carrier with 100 other people
22:02 <+ammar2> I don't think someone who knows nothing about eve is going to understand that
22:02 < dx> things i know about eve: 1. spreadsheets, 2. python backend, 3. i was in the "test alliance please ignore" xmpp chatroom once for some reason
22:03 < TkTech> Battleships. Big, slow, high damage and high tank. Also relatively expensive.
22:03 < TkTech> Frigates. Small, fast, dirt cheap, low damage, low tank.
22:04 < TkTech> Many new players see the massive capital fleets, or battleship fleets, and decide to go for those first instead of learning how to play on cheap ships they can afford to replace when they lose them.
22:04 < TkTech> It takes very little time to learn how to fly a battleship, so many new players do right off the bat, lose all their money, and cry.
22:05 < TkTech> It takes a very, very, very long time to learn how to fly well.
22:06 < TkTech> http://farm4.static.flickr.com/3088/2335016192_6003c39c4c.jpg
22:12 <+Amaranth> Something something brave newbies
22:14 < gamingrobot> *perks up* someone say EVE ?
22:19  * XorBoole waits for #mcdevs to turn into #mcdevsthatplayeve
22:19 < TkTech> I mean, it's a bunch of long-term developer addicts, odds are pretty good we've got some EVE players :P
22:19 < TkTech> Amaranth: What side of the coup are you on?
22:19 <+jnoah> eve > mc :)
22:19 <+Amaranth> TkTech: Uh, the side that likes spreadsheets?
22:20 <+Amaranth> I have no idea what you're talking about :P
22:20 <+jnoah> someone should build the EVE universe in minecraft
22:20 <+jnoah> that'd be insanely awesome
22:20 <+Amaranth> Someone was talking about brave newbies the other day so I know that's a thing
22:21 < TkTech> Oh, thought you were *in* Brave. They just went through a political coup #9993.
22:21 < dx> serious business
22:21 < TkTech> Someone tried to seize power, managed to do it for a few days, then the old CEO came back in and ripped it right back.
22:21 < TkTech> Kinda, Brave Newbies is about 12000 players.
22:21 < TkTech> So civil war is interesting for all involved.
22:22 < dx> i love how this really seems to be more than just roleplaying-as-if-it-were-serious-business
22:24 < TkTech> It's EVE. Fraud, piracy, stealing entire corporations and alliances, years of work. Just part of a normal day.
22:25 < TkTech> It takes an entire alliance that holds sovereign space and has the logistics to support it to build a 100 billion isk titan, and *blap* it's gone