07:21 < ecx86> oh
07:21 < ecx86> the main reason i do the ac work right now is because i get to meet people i want to meet
07:21 < javaprophet> Aah, if it's at a good company, for sure.
07:22 < ecx86> and me and the head developer (also the owner) are friends
07:22 < ecx86> or, we are friends now
07:22 < ecx86> you know who he is right?
07:22 < javaprophet> In a professional setting, you would be paid hourly from the get go.
07:22 < ecx86> yeah, but this isn't exactly professional lol
07:22 < javaprophet> :P
07:22 < javaprophet> I don't recall who he is.
07:22 < ecx86> oh, and you probably don't know him. you're new in the scene
07:22 < javaprophet> I'm eternally new, I keep disappearing :P
07:23 < ecx86> mainly
07:23 < ecx86> the 2nd biggest reward is that when cheaters start playing they freak out because they're getting detected for something they cant figure out
07:23 < javaprophet> :P
07:23 < javaprophet> The puzzle, I enjoy it too.
07:23 < ecx86> itll be fun watching the drama on HF :)
07:24 < javaprophet> That's what I enjoyed about the Bot and learning C.
07:24 < javaprophet> But I can see an anticheat being fun too like that,
07:24 < javaprophet> I'll certainly be making one, perhaps we will have a competition.
07:25 < javaprophet> Since mine will be for a C server, it'll probably be closed source C.
07:27 < ecx86> one of the biggest concerns i have is that the server wont succeed
07:27 < ecx86> then again, minecraft is a growing game
07:27 < ecx86> and the minigames are fun
07:27 < javaprophet> That would be a horrible loss.
07:28 < ecx86> nah, maybe to the owner. not me
07:28 < ecx86> i just did some cool ac stuff, and i can just sell it to some other server cough cough
07:28 < javaprophet> So much time and thought, and the language isn't compatible!
07:28 < ecx86> and i get to stay friends with the owner, arguably the best reward
07:28 < ecx86> its protocol level. ez
07:28 < javaprophet> Wasn't it Avo from the Team Avo from like 10 years ago
07:28 < javaprophet> ?
07:28 < javaprophet> Ah, right.
07:28 < ecx86> yeah. why
07:28 < javaprophet> I remembered. :)
07:29 < ecx86> it's better that i dont associate the server name with that
07:29 < ecx86> we've discussed this before
07:29 < javaprophet> Aah
07:29 < javaprophet> Yes.
07:29 < javaprophet> Considering my server will be OS, I ain't buying, but I'll probably allow people to sell plugins.
07:31 < javaprophet> I'm getting off, cya.
07:31 < ecx86> bye
08:09 < ackpacket> ecx86: dollars to donuts my client would pass your anticheat checks
08:12 < ackpacket> ecx86: what's this I hear about a proxy?
08:12 < ecx86> anticheat is private. no public test server will exist
08:12 < ecx86> im not affiliated with javaprophet at the moment. he was working on a reverse proxy server previously. the stuff mcleaks is doing now.
08:13 < ecx86> the anticheat looks for inconsistencies in aiming and player actions
08:13 < ecx86> im going to bed. bye
08:14 < ackpacket> goodnight
08:14 < ecx86> i really cant disclose how it is done.
08:14 < ecx86> but i have a good feeling it will detect almost every client
08:14 < ecx86> i would be suprised to find one that doesn't bypass the check, or at least the core concept of the check
08:14 < ackpacket> I rate limit turning, have a bit of randomness, etc.
08:14 < ecx86> still probably detected. bye
08:14 < ackpacket> Probs not.  G'night
11:56 < barneygale> if the functioning of your anti-cheat depends on no-one figuring out how your anti-cheat works, your anti-cheat is shit
12:33 < JustASlacker> word
12:33 < rom1504> sentence
12:43 <+SinZ> barneygale: but security through obscurity is the best security
12:43 <+SinZ> ^.^
12:45 < rom1504> hide all the passwords !
19:14 < ackpacket> barneygale: amen
21:26 < Not-9c26> [wiki] Edit by Navid to Entities -> http://tinyurl.com/hufk3ss
23:56 < Not-9c26> [wiki] Edit by Cybermaxke to Protocol -> http://tinyurl.com/zqzujxu
--- Day changed mer. mars 09 2016
00:28 < ecx86> serverside anticheats is literally just security through obscurity
00:28 < ecx86> client-side anticheats on the other hand
00:30 <+AndrewPH> could you elaborate? serverside anticheats such as stopping a player from moving too fast don't seem like security through obscurity
00:31 < rom1504> can't see why server can't check stuff properly
00:31 < rom1504> yes I agree with that ^
00:33 < pokechu22> If it's an anticheat like asking a player to press the "." key in a chat message (which apparently some hacks use to open menus), then that falls under security through obscurity.
00:34 < pokechu22> But other things are more silly, and break even on vanilla actions (sprint jumping -_-)
00:35 < rom1504> is http://wiki.vg/Plugin_channel#MC.7CAutoCmd up to date ?
00:35 < rom1504> (and if not, any clue where these stuff are in the code)
00:36 <+ammar2> rom1504: did you try searching for the channel name string?
00:37 < rom1504> ah found it thanks
00:38 < rom1504> err it's 100 lines
00:39 < rom1504> looks like the wiki is correct
00:40 < pokechu22> It's correct, though some of those things aren't clearly described yet.
00:41 < pokechu22> It's in NetHandlerPlayServer.handleVanilla250 or something like that.
00:41 < pokechu22> Even though plugin channel packets aren't 250 anymore and haven't been for some time.
00:41 < rom1504> it's in mb.java for me :p
00:42 < pokechu22> There is an MCP beta - you should try it :p
00:42 < pokechu22> https://twitter.com/SeargeDP/status/705970418486788096
00:43 < rom1504> yeah I guess
00:43 < rom1504> I never used mcp yet
00:46 < pokechu22> It's pretty easy - just download it, run decompile.bat, and then wait a bit while it works.  It'll find your minecraft installation automatically.
01:01 < ecx86> ok
01:01 < ecx86> its not really that simple
01:01 < ecx86> basic checks are obvious. like movement
01:01 < ecx86> if you want to actually detect people you will need other checks
01:13 <+ammar2> not really possible to prove an "untampered" client
01:15 < pokechu22> Yea, I've thought about that; clientside validation isn't really possible.  You might naïvely say "Just allow the server to check hashes of arbitrary files", but there's nothing stopping the client from using the vanilla jar to hash (this is an example).
01:21 <+ammar2> if you can solve the problem of verifying an untampered client based on what they send just by software, congrats, you've just invented an anticheat that works with literalyl every game
01:22 <+ammar2> and you are now easily rich beyond your wildest dreams
01:27 < rom15044> Also that kills interoperability
01:28 < rom15044> Checking the player behaves accordingly to a defined world model seems like the correct way to me
01:30 < rom15044> Untampered client isn't enough a sufficient condition, you could make a bot that move the mouse on the vanilla client
01:30 < rom15044> *isn't even
01:30 < pokechu22> Of course, even then - you get to the point where you can have hacked clients moving at the _exact_ maximum possible allowed by the model - frame perfect and such.  _Theoretically_ possible for humans, but practically impossible.
01:32 <+ammar2> that's a good point, even with a pure client you can still fake "real" input, however its harder and greatly limits cheats
01:33 <+ammar2> honestly anti-cheats are mostly just a way of putting up as many hurdles as possible
01:33 <+ammar2> because at the end of the day the only sure fire way to prevent cheating is to make people play on computers provided by you, with hardware you supply
01:34 < pokechu22> What I like is anti-cheats that notify the owner of the server to investigate further but don't actually take any automatic action.  That's really the only possible way to do it.
02:01 < Gjum> there was that other game I analyzed, agar.io
02:01 < Aikar> Grum: https://github.com/starlis/Paper/blob/b2dd99e74e91fbe5f7c28fe29faa58b7162c1aa6/Spigot-Server-Patches/0078-Optimize-Navigation-Listener.patch for 1.9.1 plz
02:02 < Gjum> every time there were really annoying bots, the creator changed a few minor things, which broke pretty much all bots as the users wouldn't know how to update
02:02 < Gjum> stuff like adding padding in the middle of a packet
02:03 < Gjum> and the most recent thing, a different coordinate system for every client
02:32 < Momo> How does the server handle 'Block states' (e. g., for piston_heads, the 'type' string block state, which is either "normal" or "sticky")? Is it stored/sent as NBT?
02:47 < pokechu22> I think it's still sent and as a nibble data value, and I know it's still stored as such.  But internally it's using full-on block states.  I might be wrong; haven't looked too deep into it.
02:57 < pokechu22> Momo: In case you do need a ping - I did partially answer your question (you might have already seen the answer; if so, ignore this ping)
06:37 <+Grum> wtf is paper Aikar? :D
06:37 < Aikar> Grum: spigot fork
06:37 <+Grum> Let me guess, this is to balance the fact that entities get created fully and then discarded? so the pressure on add/remove listeners drops?
06:37 < Aikar> pretty much where all of us working performance patches contribute to now
06:38 < Aikar> Grum: that is one part, but the .keySet().toArray is super slow too
06:39 < Aikar> it looks like someone just used a weakhashmap to be lazy on cleanup, then used toArray to avoid CME's
06:40 < Aikar> but yeah this patch is running good for people
06:40 < Aikar> and logically is clean
12:03 <+Grum> Aikar: similar fix applied
12:20 < ScruffyRules> Is the bed vision client sided?
12:25 < Meeeh> Aikar, can you tell what exacly you fixed? what is that this.b.C().a(this); ? it is something related to AI/pathfinder, why it is costly if this is only some kind of register method?
15:47 < Aikar> Meeeh, tha registers the navigation object to the worlds navigation listener
15:48 < Aikar> Grum, can you share what you did differently?
15:50 < Aikar> Meeeh, ultimately the implementation of that entire class was just hacky, so cleaned it up
16:04 < Aikar> Grum, or was it just minus the add/remove methods? I had updated the patch w/o those. only had those in there because I was doing the add/remove in World, then found that better place to do the add/remove.
16:54 < bigpresh> I admin a server where we're periodically having blocks just not place since we went to 1.9 - anyone had similar problems, or suggestions on how to investigate it?
16:54 < bigpresh> I added some code to our custom plugin to catch and log BlockPlaceEvent events, and it doesn't fire when blocks fail to place
16:54 < bigpresh> So that suggests to me that it's not that the event was cancelled by some other plugin, but rather just "didn't happen"
16:55 < bigpresh> Unless anyone recognises it as a known 1.9 problem (I've looked but failed to find a matching bug report), I'm at a bit of a loss as to how best to further investigate
16:56 < bigpresh> Maybe capture the raw traffic from a client, and see whether player block placement events arrive at the server from the client, and what the server responds with?
16:56 < bigpresh> I should clarify that this is a Spigot server, kept up to date with the latest builds from Jenkins - currently on 671
16:57 < bigpresh> We are running Grief Prevention and NoCheatPlus among other plugins, but I'd expect my code to still see the BlockPlaceEvent events but with cancelled set, if it was them nerfing them
17:10 < ScruffyRules> bigpresh, Your own private Jenkins I hope.
17:12 < bigpresh> Sorry, I mean the latest that BuildTools pulls, which tells me what Jenkins build number it was
17:12 < ScruffyRules> Ah yeah
17:12 < bigpresh> So I go by that when referring to what "build" I'm running
17:12 < ScruffyRules> Seems armour isn't getting updated when going through a nether portal.
17:12 < bigpresh> but for reference, /version reports git-Spigot-3104eb1-daf4514 and that it's the latest version
17:13 < bigpresh> (I've seen this block placement issue with I think every build since I updated our server to 1.9, though, so it's not isolated to this one)
17:13 < bigpresh> Also seeing hoppers/furnaces randomly stop working, but I saw a bug report for that already
17:57 < Aikar> Grum, lol nice release note
17:59 < Techcable> yeah Grum :)
18:02 <+ammar2> woah Mojang actually acknowledging open source "inspiration"/contributions in patch notes?
18:02 <+ammar2> what a day to be alive
19:55 < Aikar> Grum, Thinkofname reported seeing some CME on tracker. Looks like main diff you did was using iterator vs the for (;;) { get() }; problem with that approach is if an entity is added to world due to the actions of that loop, that array will be modified, causing the CME. I used for (;;) to avoid the CME, as worse can happen is that entity also gets ticked as part of that iteration that just got added. which logically seems ok. Removals are safe because 
19:55 < Aikar> those are queued and done as part of the World tickEntities
21:03 < Gjum> what does -1 mean in the chunk palette?
22:16 <+Grum> Gjum: -1?
22:16 <+Grum> Aikar: yeah tons and tons of CME, shouldn't happen obviously but its ok they do
22:16 <+Grum> should be easy to fix
22:17 < Gjum> Grum: I have 23 palette entries, and the last one is -1. the following block array has 407 entries that are found in the palette, then comes a 24, which is just after the palette...
22:17 < Gjum> well it has 4096, ut the first 407 are ok
22:19 <+Grum> the data it sends is:
22:19 <+Grum> byte with the amount of bits
22:19 <+Grum> then the palette, then a varint + varint-longs
22:19 < Gjum> I do it like this http://wiki.vg/SMP_Map_Format
22:20 <+Grum> the palette length can be 0
22:20 <+Grum> this happens when bits >= 9 iirc
22:20 < Gjum> yes, it's 23, and amount of bits is 5, which matches
22:21 <+Grum> so just 23 out of the 32 entries in the palette are being used
22:22 <+Grum> so you then read 23 varints
22:22 <+Grum> which is the contents of your palette
22:22 < Gjum> yes, I read the 23 varints, and the last is 0xffffffff0f, which is -1
22:22 <+Grum> the 'last one' being 23rd?
22:22 <+Grum> not accidentally 24th? :P
22:22 < Gjum> array pos 22
22:22 <+Grum> k
22:22 <+Grum> we dont store -1 at all
22:23 < Gjum> well I read most chunks fine the way I do it, just this one breaks
22:23 <+Grum> there is no state with id -1 :)
22:23 < Gjum> Grum: palette is like this https://gist.github.com/Gjum/0375b643ec13a42ab3c0#file-section04-md
22:24 <+Grum> I'm a bit confused
22:24 <+Grum> there is no varint data read for 1-6?
22:25 < Gjum> it's 1 byte so varint == reordered
22:25 < Gjum> (did that manually just to be sure my varint parser isn't broken)
22:26 <+Grum> I honestly do not know
22:27 <+Grum> the system is not capable of storing negative indices
22:27 < Gjum> yeah, I'm confused too, but it actually sent a -1, so there must be a source of it
22:28 < Gjum> rom1504: does the nmp proxy modify the chunk data? it just forwards it right?
22:28 <+Grum> because they are being used in array[]'s so -1 would immediately die
22:29 <+Grum> also at most we have 12 bits of data orso
22:29 < Gjum> well there are lots of -1 checks in the relevant classes: return p_186805_1_ == -1 ? -1 : this.field_186819_c[p_186805_1_];
22:29 < Gjum> which poses the opportunity to miss one
22:29 <+Grum> oh that is interesting
22:29 < Gjum> (this is from IntIdentityHashBiMap)
22:29 <+Grum> so it would have a blockstate for which it has no actual mapping
22:29 < Gjum> yes
22:30 <+Grum> bruteforce which one it is?
22:30 <+Grum> oh shit, i might actually know, i might have seen it, tripwire in a certain state
22:30 < Gjum> well I don't have the worldsave, waiting for javaprophet ;)
22:30 < Gjum> it's a jungle biome, so could be tripwire
22:31 <+Grum> that would be bad :(
22:32 <+Grum> the strange part is, the tripwires have been tested, but it could be a broken upgradepath
22:32 <+Grum> need to go to bed, but please let me know :D
22:33 < Gjum> could as well be sth else. I'll ping you when I have the worldsave
23:04 < rom1504> Gjum: the nmp proxy doesn't modify the chunk data
23:04 < Gjum> ok, so that's one error source less
23:06 < rom1504> very confusing that conversation with only one letter of difference in the pseudo ^^
23:07 < rom1504> good thing my irc client color the pseudos with a different color, but still
23:20 < rom1504> Oh I might know your pb Gjum 
23:20 < rom1504> https://github.com/PrismarineJS/minecraft-data/blob/master/data/1.9/protocol.json#L1315
23:20 < rom1504> http://wiki.vg/Protocol#Chunk_Data
23:20 < rom1504> the biomes are included in your chunks
23:21 < rom1504> idk if you accounted for that ?
23:21 < Gjum> I do exactly as it says on http://wiki.vg/SMP_Map_Format and it works most of the time. just some chunks have -1 in their paletts
23:21 < Gjum> *palette
23:23 < Gjum> but the biome data thing explains a different error I have, should be solved once I account for the section bit map
23:26 < Gjum> I am noticing the same -1 issue in another, local world, analyzing the chunk sections now to find out what causes this 
23:50 < Gjum> so, the chunks seem completely normal, and the palette key that maps to -1 is never used in my sample
23:51 < Gjum> although it seems to have nothing to do with tripwire
--- Day changed jeu. mars 10 2016
03:00 < ninjas> what do you guys recommend to start using packets I been programing in java with bukkit a long time
03:01 < pokechu22> It's complicated.  If you just want to use it without reimplementing everything, and you're using bukkit, though, there's a few libraries.
03:02 < pokechu22> ProtocolLib is pretty nice: https://www.spigotmc.org/resources/protocollib.1997/
03:03 < ninjas> I want to use it even if I reimplement
03:04 < ninjas> should I study minecraft code sourse
03:04 < ninjas> or any video that speak about packets
03:04 < ninjas> or a text
03:05 < ninjas> for exemple a thing like https://hub.spigotmc.org/javadocs/spigot/
03:05 < ninjas> but for packets?
03:05 < ninjas> is there any?
03:05 < ninjas> i learn a lot from https://hub.spigotmc.org/javadocs/spigot/
03:06 < pokechu22> http://wiki.vg/Protocol, though it's in transition to 1.9 so it'll be a bit incomplete.
03:06 < pokechu22> Here's the 1.8 version that should be fairly usable: http://wiki.vg/index.php?title=Protocol&oldid=7368
03:07 < pokechu22> And if you want to look through the actual code, I recomend using MCP (http://www.modcoderpack.com/website/releases) to decompile the game; it makes it a fair bit easier.
03:08 < Gjum> if you want 1.9 you can also try the mcp beta: http://www.mediafire.com/download/3ww1inazlkamkcc/mcp924-beta1.zip
03:10 < ackpacket> ninjas: I find the packets portion pretty trivial.  You can churn out a handler for them in about a day, or less.
03:11 < ackpacket> ninjas: pokechu22's link is a good one, it has most of the things you need.  Read up on that, but you might want to goto version history and find a complete version for 1.8
03:17 < ninjas> xD
03:17 < ninjas> will do xD
03:27 < ackpacket> pokechu22: So, in order to not violate any IP mcp doesn't actually contain any code from the original client/server?
03:28 < pokechu22> Indeed; MCP only contains deobfuscation mappings.  It _does_ have a few patches which are applied afterwards to fix things where decompilation is broken, and those (kinda) contain the orignal source at a minimal level, but you can't use it without having the actual game.
05:15 < cooldude_> I read the page wiki.vg/protocol
05:16 < cooldude_> to learn about packets
05:16 < cooldude_> but I didnt find anything about the actual things I want to learn 
05:16 < cooldude_> and the most of the page is stuff I already know
05:17 < cooldude_> I need to read a place where explain what PacketPlayOutRespawn is for
05:17 < cooldude_> or GameProfile
05:17 < cooldude_> and how to understand it
05:17 < cooldude_> the options
05:18 < cooldude_> what can I do to learn about that stuff
05:18 < cooldude_> or where can I read
05:18 < cooldude_> the protocol page does not say a Thing about that xD
05:19 < cooldude_> they just talk about ids and stuff goin between client and server
05:22 < umby24> Where is it you found those two things you're looking for information on?
05:23 < cooldude_> https://www.youtube.com/watch?v=T_yN0niNYpA&index=98&list=PL2CG7-ALtTLU12Vk30UKKd7S3GhTAbOH3
05:24 < cooldude_> here for exemple
05:24 < cooldude_> but is in german :c
05:24 < cooldude_> he actualy explain all that stuff
05:24 < cooldude_> but I dont speak german
05:24 < cooldude_> :s
05:24 < cooldude_> he made a video of packets and another of reflections
05:24 < umby24> fun, neither do I.
05:25 < cooldude_> but in german
05:25 < cooldude_> hehehe
05:25 < cooldude_> but where can I read about what each class handles
05:25 < cooldude_> or some info 
05:25 < umby24> I've never done spigot/bukkit dev, just based on the name of "PacketPlayOutRespawn", sounds like the method that sends the respawn packet, out (from a server to a client, im assuming), that is in the play packet state.
05:26 < cooldude_> maybe reading the minecraft code
05:26 < cooldude_> I guess that is the way
05:27 < cooldude_> the protocol page did not help not even a little
05:27 < umby24> what is it you're trying to do exactly? just learn more about how minecraft's networking works?
05:27 < cooldude_> what is supposed that some one can learn from there?
05:27 < cooldude_> what is the info that can help with packets on that page
05:27 < cooldude_> no
05:27 < cooldude_> i am trying to use packets
05:28 < cooldude_> to change skins put people to sleep on the stone
05:28 < cooldude_> create mobs 
05:28 < cooldude_> with skins
05:28 < umby24> that page is a documentation of every packet used in communication between minecraft clients and servers, using the info on that page you could develop your own custom minecraft servers and clients
05:28 < cooldude_> I use spigot
05:29 < cooldude_> and the players will use minecraft
05:29 < cooldude_> I dont need to develop a server or cliente
05:29 < cooldude_> just use the options I dont know
05:29 < umby24> spigot is just a wrapper around the vanilla minecraft server, so that information is still applicable, but at a much lower level than you want it seems.
05:30 < cooldude_> I want to understand this
05:30 < cooldude_> PacketPlayOutEntityDestroy packet = new PacketPlayOutEntityDestroy(new int[] {entityID});                 rmvFromTablist();                 sendPacket(packet);
05:30 < cooldude_> hehe
05:30 < umby24> I'd say doing some digging on developing spigot plugins would be where you can learn some of the information you're looking for, but it may turn out that full blown minecraft modpacks is what will really acheive what you want.
05:31 < umby24> the page for plugin development: https://www.spigotmc.org/wiki/spigot-plugin-development/
05:31 < umby24> as for that code you posted..
05:31 < cooldude_> I know all that
05:31 < cooldude_> just want to know packets
05:31 < cooldude_> when u use this imports
05:32 < cooldude_> import net.minecraft.server.v1_9_R1.PacketPlayOutPlayerInfo;
05:32 < cooldude_> that staff is not documented there
05:32 < umby24> the code you posted 
05:32 < cooldude_> I know all the staff from spigot api
05:32 < umby24> ah
05:33 < cooldude_> and is easy to know something with the api on hub.spigot...
05:33 < umby24> the code you posted creates the entity detroy packet, defining the entity to be despawned, it removes that entity from the client's tab lists, and then sends out the entity destroy packet to the client
05:33 < cooldude_> but there is not info 
05:33 < cooldude_> but how can I know that
05:33 < cooldude_> cause I cant ask you all the questions
05:34 < ackpacket> cooldude_: where did you see that code
05:34 < cooldude_> https://www.youtube.com/watch?v=T_yN0niNYpA&index=98&list=PL2CG7-ALtTLU12Vk30UKKd7S3GhTAbOH3
05:34 < cooldude_> here
05:34 < cooldude_> and I have seen code like that since a long time ago
05:34 < ackpacket> Well, we can't tell you where to find documentation for someone else's code
05:35 < cooldude_> no he share the code
05:35 < cooldude_> what I am asking is a place where
05:35 < cooldude_> can I learn about packets
05:35 < ackpacket> cooldude_: however, the bukkit documentation and protocol documentation combined will allow you to do pretty much anything.  So rather, let us know what it is you're trying to accomplish, and we can make recommendations
05:35 < ackpacket> cooldude_: the protocol page documents every packet, it's all there.  If you're looking for something that's not there, then it's not a packet
05:36 < cooldude_> I want to know how to use
05:36 < cooldude_> code like that
05:36 < cooldude_> when CraftPlayer
05:36 < cooldude_> or packets
05:36 < cooldude_> or the classes
05:36 <+AndrewPH> dude english?
05:36 < cooldude_> like PacketPlayOutPlayerInfo
05:36 < ackpacket> AndrewPH: he's esl, relax
05:36 <+AndrewPH> oh ok
05:36 < umby24> ohi aph
05:37 <+AndrewPH> sorry sir
05:37 < ackpacket> cooldude_: what is PacketPlayOutPlayerInfo a part of.  Bukkit?
05:38 <+AndrewPH> umby24: I am eternal
05:38 < cooldude_> xD
05:38 < cooldude_> is part of minecraft
05:39 < cooldude_> import net.minecraft.server.v1_9_R1.PacketPlayOutPlayerInfo;
05:39 < cooldude_> see import
05:39 < cooldude_> thats why bukkit has no info about 
05:40 < ackpacket> cooldude_: Ah.  So then your question really is not "How can I learn code in that video", but what you want is "Where can I find documentation for the vanilla client source code"
05:41 < cooldude_> when i googled PacketPlayOutPlayerInfo tutorial
05:41 < cooldude_> nothing appears
05:42 < cooldude_> yes
05:42 < cooldude_> something like that
05:42 < cooldude_> just like in bukkit theres documentation like the hub.spigot ...api
05:43 < cooldude_> where you can see what entity is ..
05:43 < cooldude_> what is PacketPlayOutPlayerInfo ?
05:43 < cooldude_> and theres a lot of packets like that
05:43 < cooldude_> what variables does it return
05:43 < cooldude_> what vars do I have to send
05:43 < cooldude_> stuff like that
05:43 <+Amaranth> You have to read the obfuscated code or sniff the protocol and figure out what things are
05:44 < cooldude_> like this one?
05:44 < cooldude_> https://github.com/Bukkit/mc-dev/blob/master/net/minecraft/server/PacketPlayOutRespawn.java
05:45 < cooldude_> you saying to read that kind of code?
05:45 < cooldude_> right?
05:45 < cooldude_> xD
05:46 < ackpacket> cooldude_: PacketPlayOutPlayerInfo is a method, not a packet.
05:46 < ackpacket> cooldude_: at least in the context you're talking about
05:47 < ackpacket> cooldude_: you want to read about the methods.
05:47 < umby24> and the code you just linked, not to confuse you more, has methods to read and write this packet: http://wiki.vg/Protocol#Respawn
05:48 < cooldude_> but how can this
05:48 < cooldude_> To change the player's dimension (overworld/nether/end), send them a respawn packet with the appropriate dimension, followed by prechunks/chunks for the new dimension, and finally a position and look packet. You do not need to unload chunks, the client will do it automatically. 
05:48 < cooldude_> teach me something
05:48 < ackpacket> cooldude_: because it teaches you about that packet, and what it's effects are
05:48 < ackpacket> cooldude_: that's all you need to know to use that packet
05:49 < ackpacket> cooldude_: you're not asking about packets, you're asking about methods that send/create them.  The protocol is for information on the *packets*
05:50 < cooldude_> yeah i am asking about methods how can I learn about them
05:50 < cooldude_> where can I read about the minecraft methods
05:50 < cooldude_> for example
05:50 < cooldude_> PacketPlayOutPlayerInfo
05:50 < cooldude_> this one
05:50 < cooldude_> is it on the protocol page also?
06:02 < ackpacket> cooldude_: the protocol page deals with packets, *not* code
06:33 < cooldude_> xD gonna read the code thanks for the time xD
06:33 < cooldude_> i appreciate
07:05 <+Fenhl> ugh
07:05 <+Fenhl> I should finish the 1.9 update
07:06 <+Fenhl> does anyone know what happened to Attach Entity? Is it now only used for leashes, since attaching directly now uses Set Passengers?
07:07 < javaprophet> I think there might be an issue with the Chunk Format too.
07:07 < javaprophet> Gjum has done more research than me though.
07:09 <+Fenhl> the -1 thing seems to be a bug in the server if I understand Grum correctly
07:09 < javaprophet> I see.
07:13 < javaprophet> Is it true that MC sends padding in chunk data?
07:15 <+Fenhl> Data Array is padded to the next multiple of 8 bytes, yes
07:15 < javaprophet> I'm finding it's sending length of >200 kb for chunks which should be 30 kb or so.
07:15 < javaprophet> And it's zero padded, seems legit from the network.
07:15 < javaprophet> I have a packet dump if your interested.
07:16 <+Fenhl> sure
07:16 < javaprophet> One second.
07:16 <+Fenhl> I can't promise I'll get around to analyzing it any time soon though
07:17 < javaprophet> This is the contents of the Data Array, and the file size is equal to the size in the Chunk Data packet: http://mirror.javaprophet.com/chunkdump.dat
07:17 < ackpacket> What's the best way to get packetdumps?
07:17 < ackpacket> Had a proxy doing this for me, a while back
07:18 < javaprophet> Seems my mirror is broken, I'll upload elsewhere.
07:19 < javaprophet> http://www.avuna.org/chunkdump.dat
07:29 <+Grum> Gjum: you happen to have the map? because it should crash when you go there with a vanilla client i presume
07:30 <+Grum> javaprophet: you also got a -1?
07:30 < javaprophet> I did see that, however in my impl I'm getting corruption somewhere really bad.
07:30 < javaprophet> Is it true that you buffer say a 30 kb chunk to 250ish kb? zero padded?
07:31 < javaprophet> See this chunk dump: http://www.avuna.org/chunkdump.dat
07:31 <+Grum> I think there is a calculation mistake in the buffer creation yes
07:31 <+Grum> it almost always makes excessively large buffers
07:31 <+Grum> do you have a world which generates a -1?
07:32 < javaprophet> Yes, I'm also having an issue where it's not able to get good data after the first chunk section, but that's probably my fault. I think I have seen that in my local world, would you like me to zip it up?
07:32 <+Grum> Can you give me that world?
07:32 < javaprophet> Yes, one second.
07:32 <+Grum> yeah please
07:32 <+Grum>         final int rawSize = storage.getSize();
07:32 <+Grum>         return 1 + palette.getSerializedSize() + FriendlyByteBuf.getVarIntSize(rawSize) + rawSize * 8;
07:32 <+Grum> That calculation is wrong
07:33 <+Grum> it should be: storage.getRaw().length * 8 instead of rawSize*8
07:33 <+Grum> i've tested it and it ALWAYS creates buffers that are too large right now
07:33 <+Grum> beyond being a bit wasteful, not much problems created by it
07:34 < javaprophet> Very wasteful on memory, if it doesn't get optimized away somewhere else.
07:35 <+Grum> its not too bad honestly, it allocates 32k instead of 500-8000 bytes
07:35 <+Fenhl> might explain the client-side lag spikes we've been getting on chunk loads
07:35 <+Grum> not really
07:36 <+Grum> keep in mind that before it allocated full chunk-buffers, which were far larger
07:36 < javaprophet> http://www.avuna.org/world.zip
07:36 <+Fenhl> hmm, let me see if I can find an issue for that
07:36 <+Fenhl> lag issues, especially client lag, are always a pain to report/find on Mojira
07:36 < javaprophet> Fair enough, I've been writing an entire client impl in C, and I tend to overoptimize things.
07:37 <+Grum> in C its basically free
07:37 <+Grum> in java however it 0's the memory
07:37 <+Grum> so you end up doing ~26k too many '0 writings'
07:37 < javaprophet> Keep in mind that Java is sending the chunk data zeroed, and I'm just allocating, and then freeing it.
07:37 <+Grum> oh crap
07:38 < javaprophet> If it ever matters, I'll recalculate the real size and trim it.
07:38 <+Grum> wait, is it sending the full data?
07:38 <+Grum> oh shit it probably does
07:38 <+Grum> GAH
07:38 < javaprophet> Yes, it sends an extra 150-200 kb of zeroes.
07:38 <+Grum> o.O
07:38 <+Grum> argh
07:38 <+Grum> yeaaaah ok
07:38 <+Grum> that will cause problems
07:38 < Vice> Hello, I've been experimenting with launchers and I was wondering what does the userid field mean in .minecraft/launcher_profiles.json ?
07:42 < Not-9c26> [wiki] Edit by Fenhl to Protocol -> http://tinyurl.com/hfbxh5c
07:46 <+Amaranth> Grum: DEFLATE wipes it out on the wire though
07:46 <+Amaranth> You're not wasting bandwidth
07:46 <+Amaranth> Well, you're wasting the few bytes DEFLATE will take to say "there's a shitload of zeros here"
07:46 <+Grum> Yeah but that deflate is quite bad
07:47 <+Amaranth> Nah, it'll find a match right away in the search window :D
07:47 < Not-9c26> [wiki] Edit by Fenhl to Protocol -> http://tinyurl.com/z2lesn3
07:48 <+Amaranth> You're wasting some CPU and RAM but the CPU happens on another thread and you just wrote off the RAM
07:48 <+Amaranth> Still, you should fix it :)
07:48 <+Grum> yeah already did
07:53 <+Grum> Makes quite a difference: https://gist.github.com/grum/4f270ab1dff039d2f729
07:54 <+Grum> (before and after size-estimates)
07:58 <+Grum> And those numbers *16; makes for 480k excess allocation per column max
07:58 <+Grum> and 25.5k minimum >.>
08:00 <+Grum> Anyhow, that should be better now hehehe
08:01 <+Grum> from 32-512k down to 2-104k
08:07 < Not-9c26> [wiki] Edit by Fenhl to Protocol -> http://tinyurl.com/z4644oh
08:08 < Not-9c26> [wiki] Edit by Fenhl to Pre-release protocol -> http://tinyurl.com/zrrl5qh
08:13 < Not-9c26> [wiki] Edit by Fenhl to Pre-release protocol -> http://tinyurl.com/za86crs
08:20 < Not-9c26> [wiki] Edit by Fenhl to Protocol -> http://tinyurl.com/j3ostjj
08:20 <+Fenhl> is the change from “more than 4” to “more than 1024” on http://wiki.vg/Pre-release_protocol#Entity_Teleport correct? It's not marked as a change
08:22 <+Grum> i dont think that is correct
08:22 <+Grum> we changed how we send the data but i dont think the threshold is that high
08:25 < Not-9c26> [wiki] Edit by Fenhl to Protocol -> http://tinyurl.com/hwk99vn
08:26 <+Grum> 'This packet is sent by the server when an entity rotates and moves. Since a short range is limited from -32768 to 32767, and movement is offset of fixed-point numbers, this packet allows at most 1024 blocks movement in any direction. (-32768/32 == -1024) '
08:26 <+Grum> i think we send more than 32 subdivisions per block
08:26 <+Grum> that was the whole idea at least :)
08:27 < Vice> This is somewhat of an odd question, but does anyone know how skins are set through minecraft.net? As far as I can tell a profile (with uuid) is never selected.
08:28 <+Grum> there is just one profile with one uuid
08:28 < Vice> What if hypothetically there are multiple?
08:28 <+Grum> there are not
08:29 < Vice> Hypothetically though.
08:29 < Vice> like the username "lol"
08:29 <+Grum> the fact that that site doesn't support is is part of the reasons we do not allow multiple profiles per account
08:30 < coolsa> oh, will the new site support it?
08:30 < coolsa> the beta.minecraft.net thing
08:30 <+Grum> Unknown, but i think all other things support it already
08:30 < Vice> The minecraft launcher actually doesn't
08:30 < Vice> I had to mess with launcher_profiles.json to get it to work.
08:31 <+Grum> it does
08:31 <+Grum> but your account doesn't have multiple profiles
08:31 < Vice> It only uses the default profile
08:31 < Vice> despite there possibly being multiple
08:31 <+Grum> yes, but your account doesn't report back multiple when you log in :)
08:31 < Vice> default = first one in the list, by the way.
08:31 <+Grum> it actually does support it
08:32 <+Grum> you get an additional 'select the account' question if your account has multiple active profiles
08:32 < Vice> I've seen that, you can choose from the list but you always get the same uuid.
08:32 < coolsa> the person "daqa" had this issue
08:32 <+Grum> Fenhl: the cutoff is set at 32k, 4k positions per block
08:32 < Vice> You have to mess with launcher_profiles.json to select a different uuid.
08:32 < coolsa> no idea what happened to him
08:32 <+Grum> a bug most likely
08:32 <+Grum> Fenhl: so teleport if distance > 8 blocks
08:34 <+Fenhl> Grum: you sure it's not ±4?
08:35 <+Grum>                 final long xn = EntityTracker.truncate(entity.x);
08:35 <+Grum>                 final long xa = xn - xp;
08:35 <+Grum>                     if (xa < -CUTOFF || xa >= CUTOFF || ya < -CUTOFF || ya >= CUTOFF || za < -CUTOFF || za >= CUTOFF || teleportDelay > 20 * 20 || wasRiding || wasOnGround != entity.onGround) {
08:35 <+Grum>     private static final int CUTOFF = 32768;
08:35 <+Grum> so if the delta is >32k
08:36 <+Grum> the delta is of 'truncate(entity.x)' which does:
08:36 <+Grum>         return Mth.lfloor(input * TRUNCATION_STEPS);
08:36 <+Grum>     public static final int TRUNCATION_STEPS = 4096;
08:38 <+Fenhl> okay, so it changed from ±4 blocks to ±8
08:40 <+Grum> it changed from: 1/32th of a block resolution to 1/4096
08:40 <+Grum> and from byte -> short
08:52 < rom15044> ackpacket: Gjum recently did that using node-minecraft-protocol proxy. Maybe you still have the code you added Gjum ?
10:44 < rom1504> (but basically it's just about adding some require("fs").writeFile('parsed_packet.dump',packet); or require("fs").writeFile('raw_buffer.dump',meta.buffer);)
11:30 < PEMapModder> The Minecraft Wiki article on weather seems to be too lack of information. Can anyone provide me with information on details like the range of weather time, or the chance of transition into a certain kind of weather?
12:12 < Not-9c26> [wiki] Edit by Fenhl to Protocol -> http://tinyurl.com/zkx64q3
12:13 < Not-9c26> [wiki] Edit by Fenhl to Protocol -> http://tinyurl.com/glf5uj3
12:15 < Not-9c26> [wiki] Edit by Fenhl to Pre-release protocol -> http://tinyurl.com/jzh6wyg
12:15 <+Fenhl> PEMapModder: sure, give me a sec
12:23 <+Fenhl> PEMapModder: this is some js for a weather forecast website, it should give you the relevant data https://github.com/wurstmineberg/isitraining.wurstmineberg.de/blob/master/rain.js
12:30 < PEMapModder> thanks!
13:58 < Not-9c26> [wiki] Edit by Fenhl to Pre-release protocol -> http://tinyurl.com/ju7myr3
14:08 < Meeeh> debug in MC was ctrl + ?
14:08 < Meeeh> or f3? nah
15:05 < rom1504> f3
16:00 < Not-9c26> [wiki] Edit by Fenhl to Protocol -> http://tinyurl.com/h5hc7f4
16:01 < Not-9c26> [wiki] Edit by Fenhl to Pre-release protocol -> http://tinyurl.com/jo5h2es
16:16 < Not-9c26> [wiki] Edit by Fenhl to Protocol -> http://tinyurl.com/zoehp29
16:17 < Not-9c26> [wiki] Edit by Fenhl to Protocol -> http://tinyurl.com/j8r5396
16:41 <+Grum> javaprophet: thanks for the world, helped me debug the issue, its gone -- you can just ignore -1's
16:41 <+Grum> (for the time being until the fix is out -- which is after pre2 (so likely in the 1.9.1 if we do not have another pre)
16:42 < javaprophet> No problem. :)
16:44 <+Fenhl> did the chunk format fix make it into pre2?
16:44 <+Fenhl> wow the Minecraft Wiki is slow today, there's still no article on it
17:00 < Gjum> ackpacket, rom1504: https://gist.github.com/Gjum/60341a5899784eff7f7a
17:00 < Not-9c26> [wiki] Edit by Pokechu22 to Protocol -> http://tinyurl.com/zemjnhs
17:06 < rom1504> ok nice
17:47 < Not-9c26> [wiki] Edit by Pokechu22 to Block Actions -> http://tinyurl.com/hupyllq
17:51 < javaprophet> Has the protocol number changed for 1.9.1 PR 2?
17:53 < Aikar> javaprophet, someone just mentioned it, so seems so
17:53 < javaprophet> Yes, I'll wireshark the client to find it.
17:55 < javaprophet> It's 108 unsurprisingly.
18:19 <+Grum> Fenhl: the 0-padding is fixed
18:19 <+Grum> the occasional -1 is not; will be before 1.9.1
18:19 <+Grum> javaprophet: yeah it did
18:19 <+Grum> also 1 change, the loginpacket sends an integer for the dimension now
18:19 <+Fenhl> Grum: uh, yeah that's what I meant
18:19 < javaprophet> Thanks, was just about to ask if any changes were made.
18:20 <+Fenhl> Grum: this one? http://wiki.vg/Protocol#Join_Game
18:20 <+Grum> yes
18:20 <+Grum> the only one that was a byte
18:20 <+Grum> for no reason
18:21 <+Grum> and since we need to encourage people to get to 1.9.1 for the buffer-fix we pushed protocol (also its not guaranteed compatable)
18:21 <+Grum> compatible even
18:24 < Not-9c26> [wiki] Edit by Fenhl to Pre-release protocol -> http://tinyurl.com/jybyjo2
18:25 < javaprophet> Grum, a minor issue, there is still some zero padding at the end of chunk data.
18:25 < javaprophet> Not as much, 500-1200 usually.
18:25 < javaprophet> remainder: 1172
18:25 < javaprophet> remainder: 616
18:26 < javaprophet> remainder: 640
18:26 < javaprophet> etc
18:29 < Not-9c26> [wiki] Edit by Fenhl to Pre-release protocol -> http://tinyurl.com/jktaoat
18:49 < Meeeh> javaprophet, it isn't only in buffer? o.O like netty buffer is larger than packet, but only used bytes are send?
18:54 <+Grum> then something in the math to figure out the size might still be going wrong
18:55 <+Grum> https://gist.github.com/grum/4f270ab1dff039d2f729 <-- those are the numbers it allocates now (old above, new below)
18:55 <+Grum> oh wait those might miss the actual amount of entries in the palette
18:56 <+Grum> go check my math :P it should 'work out' :(
18:57 <+Grum> return 1 + palette.getSerializedSize() + FriendlyByteBuf.getVarIntSize(storage.getSize()) + storage.getRaw().length * 8; <-- that one should be 'right'
18:57 <+Grum> the storage is a long[], so the raw length * 8 for the bytes
18:57 <+Grum> 1 is for the 'bits' and then the palette is send
18:58 < Gjum> why the +1 though?
18:58 < Gjum> ah nvm
18:58 <+Grum> because we start with writing a byte with the amount of bits used
18:58 <+Grum> we have 3 palettes
18:58 < Gjum> yup
18:59 <+Grum> a linear, hashmap and global
18:59 <+Grum> global is size 0
18:59 <+Grum> (so it reports 'size of 0' which is 1 byte)
19:00 <+Grum> the linear one is 'size of entries' (1) + the varint size of each blockstate it holds
19:00 <+Grum> which kinda cant go wrong either :/
19:00 <+Grum> unless size is 'off' :P
19:02 <+Grum> the other one has an off-by-one error (because of some other fudging)
19:02 < Gjum> the bimap one?
19:02 <+Grum> yeah
19:02 <+Grum> which was the reason for the weird -1 appearing
19:03 <+Grum> but it should report the projected size correctly
19:03 < Meeeh> what about chunk masks?
19:03 < Meeeh> or this is code only for single section, ugh
19:03 <+Grum> masks?
19:03 <+Grum> this is just for a single section
19:03 < Meeeh> ah, ok.
19:04 <+Grum> the buffer that gets allocated is just 'for a single chunk' so at max 16 sections
19:04 < Gjum> can confirm, pretty much all palettes with -1 are 5 or 6 bits in my sample
19:04 <+Grum> javaprophet: there is still at least an off-by-one but the data sgould be filled
19:04 <+Grum> Yeah, its in 5-9 bits where the -1 happens
19:04 <+Grum> but it is sortof ignorable
19:05 < Meeeh>  1 + section.getPalette().byteSize() + MathUtils.varintSize(i) + (section.getBlockData().size() * 8) nah, I use this same code, but I never saw any huge amount of zeros, maybe I should actually check that
19:05 < Gjum> yeah I accidentally linked it to another error, probably in my impl
19:06 <+Grum> nah could be there still is crap going on
19:06 <+Grum> but please double-check and let me know where there is fail going on :)
19:07 < Gjum> it's that unknown index issue, eg. index 24 in a palette with 24 entries
19:07 < Gjum> and it's probably not an offbyone on my side
19:07 < Meeeh> Grum, maybe it is caused by palette/section implementation, so your calculations are right but your storage.getRaw() is much bigger than needed
19:08 <+Grum> that would be strange
19:08 <+Grum> because it just does: size * bits / 64 and then rounds it up :)
19:08 <+Grum> for the amount of longs
19:10 < Not-9c26> [wiki] Edit by Fenhl to Pre-release protocol -> http://tinyurl.com/jo4vvdj
19:16 < Meeeh> Actually, what is going on? there are strange zeros at the end of data? that isn't air or other blocks? i don't quite understand this :D as I don't see anything stange in my own packets (nut maybe I just don't know where to look :D))
19:17 <+Grum> 1.9 and 1.9.1-pre1 had tons of trailing 0's
19:17 < Gjum> Meeeh: the ckunk data has all the expected data, but tons of 0s at the end, because the allocated buffer is too large
19:18 < Meeeh> Can onyone tell me some example normal chunk packet size? (how big should be normal one, just to fast check if my code is affected)
19:18 < Gjum> grums gist link has some data
19:18 <+Grum> at max 104kb for the allocated buffer
19:19 <+Grum> (of the raw data)
19:20 < Meeeh> oh, yeach, I broke it too <3
19:20 < Gjum> Meeeh: writing a server?
19:20 < Meeeh> Capacity: 590260, Index: 98756 (indax of buffer at the end of my write method)
19:20 < Meeeh> Gjum, yep, I have too much free time
19:21 < Meeeh> Grum, removing *8 somehow make it more sane  Capacity: 41286, Index: 31051 but I have no idea why it works like that :D nah
19:22 < Gjum> Meeeh: he posted te correct formula above somewhere
19:22 <+Grum> the *8 is because we have a long[] buffer
19:22 < Meeeh> I know, I use long[] too, so I also have *8
19:23 < Meeeh> I just removed it for test in my code, weird, I really fucked up something
19:23 <+Grum> I only use long because its just easier to bitshifting crap on single values :)
19:23 < Meeeh> 1 + section.getPalette().byteSize() + MathUtils.varintSize(i) + (section.getBlockData().size() * 8) -> from my code
19:23 <+Grum> yeah that is wrong
19:24 <+Grum> because getBlockData().size() returns '4096'
19:24 <+Grum> and you want: getBlockData().getRaw().length
19:24 < Meeeh> this is my own server, so :D
19:25 < Meeeh> idk if I have anything like that 
19:25 <+Grum> or: Mth.ceil(getBlockData().getSize() * bits / Long.SIZE) * 8
19:25 <+Grum> (aka the same calculation as you do to calculate the amount of longs you need)
19:25 < Meeeh> ah, I have getDataArray here, and size don't return size of it tooo
19:25 < Meeeh> how I missed that
19:26 <+Grum> its annoying to have to pre-allocate buffers and thus you have to expose internal stuff
19:27 < Meeeh> I keep api/core separation anyway (kind of, I still like to have access to some stuff here, I don't want to make super-api-friendly server) so I don't have this problem here :P but nah... java.lang.IndexOutOfBoundsException: I broke it :<
19:30 < Meeeh> oh, but I only didn't fit biomes as far as I see
19:32 < Meeeh> Grum, can you check my small method? I missing that 256 bytes somewhere 
19:32 < Meeeh> https://hasteb.in/ogikayipiy.avrasm
19:33 < Meeeh> there is anything that I missed? I have light stuff, and biomes, and that data size, no idea where I lost my 256 bytes
19:33 < Gjum> tried with both full=true and false?
19:34 <+Grum> 256 is biomes indeed
19:36 < Meeeh> Grum, I add biomes here, and as far as I debug, array have valid size of 256 bytes. (or maybe it was changed?)
19:38 < Gjum> no, still 256
19:40 < Meeeh> ooohhh, I it isn't 256 bytes too small, only few bytes too small, so I miss 2-6 bytes somewhere, so it must be some varint
19:43 < Meeeh> this is weird ;/ it is always few bytes too large or too small, and I don't see anything invalid
19:44 <+Grum> your var-int-size-method is not right?
19:44 < Meeeh> it works for all other stuff, so should be valid ;/ will check anyway
19:47 < Meeeh> anyone can send valid method so I can compare them?
19:48 < Meeeh> ok, found one
19:48 <+Grum>  https://gist.github.com/grum/980c28ac51041a11333b
19:49 < Meeeh> oh, thnaks, max is 5?
19:49 <+Grum> yes
19:49 < Gjum> for long, max is 5 bytes
19:50 <+Grum> no long goes to 10
19:50 <+Grum> 7 bits per 8; so 10 bytes for a long
19:50 < Meeeh> nah, just to be sure that I will not miss anything in code I run loop of all integers with  if (varintSize(i) != getVarIntSize(i)) System.out.println(i)
19:50 < Meeeh> and it is valid
19:51 < Meeeh> ;/
19:51 <+Grum> your blockstate table is different
19:51 <+Grum> if you have another palette, it might return different sizes
19:52 < Gjum> oh right, java long is 64bit not 32, my bad
19:52 <+Grum> on every system a long is that
19:52 <+Grum> unless some retarded retypdeffing on c :)
19:55 < Meeeh> I always miss from 17 to 5 bytes :D
19:55 < Meeeh> or 16*
19:58 < tktech> Fenhl, That's a lie, you are a chanop
20:00 < Meeeh> bytes += chunk.getBiomes().length + 16; good code, perfect quality, would buy. I must find that stupid mistake... :D Grum, what about minecraft? you fixed this zeros? as someone was saying that there are stll some zeros at the end
20:03 < Gjum> Meeeh: it's fixed in pre2 if I understand correctly
20:16 < Meeeh> ohhh now I see more, it is just always 1 byte per chunk section
20:17 < Gjum> so maybe you are missing the bit length at the beginning?
20:17 < Meeeh> I have it, maybe section.getPalette().byteSize() returns 1 bit less than it should, but I don't remember correct values :D
20:17 < ackpacket> what's this zeroing issue with minecraft?
20:17 < ackpacket> Seems to be all the talk in here lately
20:18 < Gjum> javaprophet: in the dump you sent me, do you also get a block that's not in the palette, at the 5th section, block index 407?
20:18 < Meeeh> Gjum, data on wiki.vg is valid for chunks?
20:18 < Gjum> yes
20:19 < Gjum> ackpacket: chunk data in 1.9 and 1.9.1pre1 has tons of zeroes at the end, because the allocated buffer is too large
20:20 < ackpacket> Wow... that seems something easily fixable.  Is it length prepended?
20:30 < Meeeh> nah.I'm idiot
20:32 < Meeeh> Yey, fit perfectly. Thanks javaprophet, Grum for info about this and for help :D
20:41  * Gjum can never be sure if people actually see the consonant difference
20:41 < ecx86> that's incorrect
20:42 < ecx86> a long is 32 bits in C
20:42 < ecx86> a long long is 64 bits
20:42 < ecx86> in java a long is 64 bits and an int is 32 bits
20:44 < Meeeh> Gjum, you mean me? Actually, I forgot to thank you too :D as gru.m helped me too. So, thanks to you! :P 
20:46 <+Amaranth> btw gru.m pings him :P
20:46 < Gjum> I was referring to rom1504 complaining about the conversation yesterday between gru m and me
20:47 < Meeeh> Amaranth, oh, sorry :D
20:47 <+Amaranth> I tried to use G-man to reference him without a ping but no one got it
20:48 <+Amaranth> So now I just ping him :P
20:48 < Gjum> lol
20:49 < Gjum> what about eric?
20:49 < Gjum> *erik
20:50 <+Thinkofname> could call him ☃ since he seems to like them so much :)
20:50 <+Thinkofname> not the easiest to type though
20:50 < Gjum> oh, I actually thought that was fernflower
20:51 < Meeeh> Gjum, that would be very weird to create program for decompilation that obfuscate the code :D
20:57 < Gjum> rom1504: dos nmp proxy work with 1.9.1 pre 2?
21:06 < rom1504> Gjum: not yet no
21:06 < rom1504> did anything changed ?
21:07 < Gjum> at least protocol version nr and loginpacket dimension byte->int
21:07 < Gjum> rom1504: ^
21:08 < rom1504> okay let's do that
21:09 < rom1504> I wonder why an int is needed to store the dimension
21:10 < rom1504> "Int Enum -1: Nether, 0: Overworld, 1: End"
21:10 < rom1504> realms have dimensions maybe ?
21:10 < Gjum> rom1504: > +Gr um | the only one that was a byte\nfor no reason
21:11 < rom1504> the only one among what ?
21:16 < rom1504> 1.9.1-pre1 is 107 or 108 ?
21:16 < Gjum> javaprophet says 108
21:17 <+Amaranth> int or varint?
21:17 < rom1504> Gjum: no that's for pre2
21:17 < Gjum> and no idea among what, there are other byte fields in join game
21:18 < Gjum> rom1504: oh, then probably 107
21:18 < Not-8b17> [minecraft-data] rom1504 pushed 1 commit to master [+2/-0/±2] https://git.io/vaOkB
21:18 < Not-8b17> [minecraft-data] rom1504 c95b36f - add 1.9.1-pre2
21:27 < rom1504> Gjum: alright, pull nmp, and put "1.9.1-pre2" as option for the proxy
21:27 < Gjum> ok, ty :)
21:27 < rom1504> then tell me if it crashes because I didn't actually tested the proxy :D
21:28 < rom1504> (if the join game packet is indeed the only change then things should work fine)
21:31 < Not-8b17> [mineflayer] rom1504 deleted branch greenkeeper-minecraft-data-1.2.6
21:31 < Not-8b17> [flying-squid] rom1504 deleted branch greenkeeper-minecraft-data-1.2.6
21:31 < rom1504> hmm I should do that notifico pr
21:48 < rom1504> Gjum: okay I tried it, it works
22:21 < somerandomperson> not sure who to send this to
22:21 < somerandomperson> on
22:21 < somerandomperson> http://wiki.vg/Realms_API
22:21 < somerandomperson> the /downloads/latest has been changed
22:22 < somerandomperson> now there it's /worlds/$ID/slot/1/download and the response is json downloadLink:, resourcePackUrl: and resourcePackHash
22:23 < Gjum> somerandomperson: you mean GET /worlds/$ID/backups/download ?
22:23 < somerandomperson> yes
22:23 < Gjum> I can update it, sec
22:24 < Gjum> what would /slot/2/download etc be, ie. other slot numbers?
22:24 < somerandomperson> yep
22:25 < Gjum> hmm, maybe the $ID/slot/1 is actually the full ID
22:25 < somerandomperson> if you GET /world/id/backups it matches whatever slot those returned ids are
22:25 < somerandomperson> no, it's just the number 1
22:25 < somerandomperson> I'm using it in a script to auto download the backup and render a map on my server
22:27 < Gjum> can you hastebin that script?
22:28 < somerandomperson> when I finish it I can
22:28 < somerandomperson> I'll probably make the repo live on github
22:28 < somerandomperson> there's new stuff also, there's now an activities that shows liveplayerlist
22:28 < Gjum> you can also create an account and change it yourself: http://wiki.vg/index.php?title=Special:UserLogin&type=signup
22:29 < Gjum> because I have not used realms myself and can only guesswhat to change
22:29 < somerandomperson> ah ok thanks
22:30 < somerandomperson> I'll do that
22:30 < Gjum> cool, thanks!
22:39 < Momo> What is the default VarInt value of a Zombie for the "Is villager (profession)" metadata entry?
22:39 < rom1504> there is no default in the protocol
22:39 < rom1504> for spigot api, ask #spigot
22:40 < Momo> Then how does it say that it's not a villager?
22:40 < rom1504> what says ?
22:40 < Momo> I'm talking about http://wiki.vg/Entities#Zombie (index 12)
22:41 < Not-9c26> [wiki] Edit by Bartle man to Realms API -> http://tinyurl.com/zgq4922
22:41 < Momo> Since 0 is the brown villager, so it can't be set to 0 for 'non-villager'
22:41 < Gjum> maybe the field isnt present then?
22:42 < Not-9c26> [wiki] Edit by Bartle man to Realms API -> http://tinyurl.com/hslgmw5
22:42 < rom1504> so "Is villager (profession)" is the wrong description ?
22:43 < Gjum> it is missing information at least
22:43 < Momo> I think not, it means that if it's a villager, this represents the ID of the profession of the Zombie
22:43 < Momo> (Zombie Villager)
22:43 < rom1504> hmm
22:43 < rom1504> well then I guess just don't set that property indeed
22:44 < Momo> So is there a way to 'unset' it? =P
22:45 < Gjum> I'll sniff a packet and see
22:49 < Gjum> Momo: spawning a normal zombie I get 12=0, 13=false
22:49 < Gjum> got a command for spawning a villager zombie?
22:50 < Momo> ./summon Zombie ~ ~ ~ {IsVillager:1}
22:53 < Gjum> hmm, 12=5, 13=false
22:54 < Gjum> can I set the profession to 0 when spawning?
22:56 < Momo> ./summon Zombie ~ ~ ~ {IsVillager:1,VillagerProfession:0}
22:57 < Gjum> thanks
23:03 < rom1504> if you don't set a property, it's unset
23:03 < rom1504> I mean, if you send an update entity metadata packet, without that property set
23:03 < Gjum> Momo: profession=0 spawns with meta 12=1
23:04 < Gjum> when my system decides to stop swapping, I see if profession=3 results in 12=4
23:04 < Momo> So maybe 12=0 means it's not a villager, and over that is the id (+1)?
23:04 < Momo> Alright, thanks =)
23:05 < rom1504> get some ram Gjum 
23:05 < Gjum> buy me some :P
23:05 < rom1504> you need at least 16GB :p
23:08 < Gjum> with my ram saving skills, 8 are already very much :P
23:11 < rom1504> I bet if you collected ram capacities by language used of devs, you'd fine java people have more ram :p
23:14 < ecx86> just download some ram
23:14 < ecx86> 16 is more than enough
23:14 < ecx86> i ran 3 minecraft clients and a server, intellij, eclipse, visual studio, csgo, firefox, at the same time under 70% load
23:15 < Gjum> "download ram" "cloud"
23:16 < rom1504> some people run games on ec2 instances
23:16 < rom1504> I wouldn't say that's a cheap option though :p
23:17 < ecx86> ive got a great idea
23:17 < ecx86> u put all ur ram in the cloud
23:17 < ecx86> unlimited ram
23:17 < ecx86> but
23:17 < ecx86> so u make ur os
23:18 < ecx86> read/write to the cloud
23:18 < ecx86> usingn etwork io
23:18 < ecx86> whenever anything is supposed to go to ram
23:18 < ecx86> u map ur ram to the cloud. brilliant idea.
23:18 < ecx86> then you can literally download more ram
23:18 < rom1504> running the whole computer in the cloud (=ec2) is kind of easier :p
23:19 < Gjum> Momo: can confirm, profession is offset by 1
23:19 < rom1504> you just got to have a decent ping and bandwidth and it works
23:19 < ecx86> i mean thats not a big deal i live in a datacenter anyways
23:20 < Momo> Gjum: Awesome. So using profession=1 is the Farmer villager, right?
23:20 < ecx86> p.s. even 0.1ms for main memory read/write is unacceptable
23:20 < Gjum> log https://gist.github.com/Gjum/10916f362c8ab8e97e2d
23:20 < Gjum> it had a brown coat iirc
23:21 < Momo> Alright, tyvm for your help =)
23:21 < rom1504> add it to the wiki ;)
23:21 < mewking> hi
23:22 < Not-9c26> [wiki] Edit by Gjum to Entities -> http://tinyurl.com/gwyckj9
23:22 < Gjum> done 
23:22 < Gjum> checking now if the villager professions are also offset
23:22 < rom1504> ecx86: if you lived in the cloud directly, then you could get a better ping !
23:23 < ecx86> heres the dillemma though
23:23 < mewking> Does anyone know how velocity works in detail? Is there anything like friction which decreases it until it is zero?
23:23 < ecx86> if all your ram is mapped to the cloud
23:23 < ecx86> how will you allocate the memroy for the socket???
23:24 < rom1504> put it on the harddrive
23:25 < ecx86> but you need to put it in memory do operations on
23:25 < ecx86> it has to be a buffer somewhere
23:25 < Gjum> mewking: nickelpro and gamingrobot implemented that for spockbot: https://github.com/SpockBotMC/SpockBot/blob/master/spockbot/plugins/helpers/physics.py
23:25 < ecx86> OMG
23:25 < ecx86> IVE GOTI T
23:25 < ecx86> PUT IT IN THE L2 CACHE
23:25 < ecx86> AHAHAHAHAHA
23:25 < rom1504> :D
23:26 < mewking> Gjum: Thank you, I'll look into that
23:26 < Gjum> mewking: also https://github.com/SpockBotMC/SpockBot/blob/master/spockbot/mcdata/constants.py#L28-L30
23:31 < Gjum> tested villagers, profession is not offset. interesting
23:57 < mewking> Is the entity velocity packet sent alongside the entity relative move packet to the client?
--- Day changed ven. mars 11 2016
00:01 < rom1504> they are both sent yes
00:01 < rom1504> not sure what you mean exactly by "alongside" ?
00:02 < mewking> Any requirement for the order? i sent both in the same server tick and the entity was still floating in mid-air
00:02 < mewking> I meant "both at the same moment", sry
00:03 < rom1504> I think they can be sent in any order
00:03 < rom1504> are you coding for 1.8 or 1.9 ?
00:03 < rom1504> 1.9 relative move is quite different
00:03 < mewking> 1.9
00:04 < rom1504> http://wiki.vg/Pre-release_protocol#Entity_Relative_Move
00:04 < rom1504>  (currentX * 32 - prevX * 32) * 128
00:05 < mewking> Thanks, I will try this. (I really don't know why I didn't look there :/ Thanks!)
00:05 < rom1504> it's a +/- 8 maximum delta now
00:07 < PunKeel> Hello, has the "string format" (VarInt followed by UTF8 bytes) changed in 1.9.1-pre2 ? Thx :)
00:08 < Not-9c26> [wiki] Edit by Rom1504 to Pre-release protocol -> http://tinyurl.com/jffkhcb
00:08 < rom1504> PunKeel: no it didn't change
00:10 < PunKeel> Thanks rom1504. Weird, I have an issue (I suspect my plugin message to cause it ...) `The received encoded string buffer length is longer than maximum allowed (102 > 64)`
00:14 < rom1504> the vanilla client shows that ?
00:15 < PunKeel> yup, vanilla 1.9.1-pre2 (custom server, unfortunately)
00:28 < rom1504> maybe you are sending a string that is too long ?
00:44 < PunKeel> Hmm ... I really don't know but I don't think so. Actually (with proper logging & Thread.sleep everywhere to make it run step by step), it looks like the "Spawn player" is guilty. UUID, 64bits, would match the "64" from the error message
00:49 < rom1504> well are you sending it right http://wiki.vg/Protocol#Spawn_Player ?
00:52 < PunKeel> I would love to tell you "indeed !" but I'm not even sure of that. Right now, I suspect that packet (Spawn) sends a String and no more an UUID ... that's really weird. (Client does not crash if I don't send it, but it crashes when it receives the entity spawn, that also has an UUID field)
00:52 < PunKeel> And right now I'm using BungeeCord's DefinedPacket.writeUUID to write the UUID
01:10 < Not-9c26> [wiki] Edit by Pokechu22 to Minecraft Forge Handshake -> http://tinyurl.com/jky3ogq
01:14 < PunKeel> i'm so lame. It crashes when the server sends its own "brand" and I sent the whole commit id ... Thanks, rom' (no need to notify you ;D)
01:22 < pokechu22> The brand has a max length of 32767, though...  At least when the client reads it, it takes 32767 characters.
01:25 < PunKeel> I'm lost. Must be a silly mistake, but I don't see it.
01:27 < ackpacket> Why does bukkit not have a way to spawn player entities without diving into protocol lib etc?
01:27 < pokechu22> Hm... wait, are you using 1.9.1-pre2?  I'm looking at the 1.8 code... one sec.
01:28 < PunKeel> I'm using 1.9.1-pre2, yep. ackpacket because the protocol is not "stable"
01:29 < ackpacket> PunKeel: Well, this was a problem that's existed for many versions if not all.  What does it have to do with protocol anyway?
01:30 < pokechu22> } else if ("MC|Brand".equals(☃.a())) { this.f.h.h(☃.b().c(32767)); }
01:30 < pokechu22> Hm, seems like 1.9 still has the same max length for the brand.  Does your code work on 1.8?
01:31 < ackpacket> pokechu22: What is the purpose of that MC|Brand portion?  I remember seeing that when writing a client and never fully diving into it's purpose
01:31 < PunKeel> My code works on 1.8 and 1.9, but not 1.9.1
01:32 < pokechu22> MC|Brand is used to show the client/server brand.  It's purpose is to let the server know if you're running a modded client, and for the client to know if the server's modded.
01:32 < pokechu22> It mainly shows up in crash reports.
01:32 < ackpacket> Hmm
01:32 < ackpacket> Can't imagine why either client or server would want to advertise that they've been modified
01:32 < ackpacket> Well, maybe server
01:33 < PunKeel> To help Mojang debug things, maybe ? ;)
01:33 < pokechu22> You're free to not send it or leave it as vanilla.  It's pretty useful for debuging, though.
01:33 < ackpacket> useful to mojang?  I don't see how, my experience is that if you're not running something vanilla, they don't offer to help
01:34 < PunKeel> ackpacket that's the point
01:34 < ackpacket> At least, don't feel obligated to
01:34 < pokechu22> It's helpful for them to know if it's not vanilla :P
01:34 < pokechu22> Also, it lets the player figure out who to report bugs to, at some level.
01:34 < ackpacket> pokechu22: which goes back to...
01:34 < ackpacket> <ackpacket> Can't imagine why either client or server would want to advertise that they've been modified
01:34 < ackpacket> not helpful to them heh
01:34 < ackpacket> Oh I see, so a client connecting to a bungee server would offer their report to bungee
01:35 < ackpacket> s/bungee/bukkit
01:35 < PunKeel> In a perfect world with unicorns lying around, cheats use a different MC|Brand.
01:35 < pokechu22> FYI, ClientBrandRetreiver, which is used clientside to get the value with MC|Brand, is one of the only classes that isn't obfuscated :P
01:35 < pokechu22> PunKeel, have you tried looking on http://wiki.vg/Debugging to see at which packet the server's disconnecting you?
01:36 < PunKeel> Too lazy to paste it, so ... http://j.ungeek.eu/BJKS13x
01:36 < ackpacket> pokechu22: does "PLAY" indicate the state of the client
01:37 < pokechu22> PLAY, LOGIN, etc are all the state, yes.
01:39 < javaprophet> I'm seeing something very odd, that the Player Pos Look (clientbound) is sent with all zeroes to spawn in. Is this my own implementation error, or is this some new thing?
01:47 < pokechu22> Well, whatever's causing it isn't in MC|Brand; it's in Join Game probably.
01:47 < PunKeel> (no idea javaprophet, what version ?) pokechu22 that would not be an issue if I didn't drop that packet. :)
01:47 < javaprophet> Oh pokechu22, the dimension field in Join Game was changed from a byte to a int
01:47 < javaprophet> int32
01:47 < javaprophet> in pre2
01:48 < javaprophet> Also, my issue was a signedness issue, the exponent was at the wrong end.
01:48 < pokechu22> That would do it
01:48 < javaprophet> Not a varint, a 4 byte signed int btw.
01:50 <+Thinkofname> forge is going to be happy with that, pretty sure they've asked for that for a while now
01:53 < Gjum> javaprophet: did you figure out chunk data parsing yet? ;)
01:54 < javaprophet> Yes, I intended to do light later as it wasn't important, but I forgot that it was between the block data...
01:54 < javaprophet> It works fine now, and I'm fixing some stability issues to get the first render test running.
01:54 < Gjum> I get weird palette indices, might try pre2 and see if gr um fixed it
01:54 < javaprophet> 'printf("segfault incoming!\n");'
01:55 < javaprophet> I'm using pre2 now myself.
01:55 < javaprophet> It is not fixed in pre2, but he did fix the too large buffers mostly.
01:55 < javaprophet> He said to just ignore them I think.
01:55 < javaprophet> I'm afraid to use my debugger because it crashes my GPU drivers -.-/
01:56 < PunKeel> Thanks javaprophet & pokechu22 ... be damned packets that I don't log.
01:56 < Gjum> javaprophet: https://gist.github.com/Gjum/cae2486affbcc2de3304
01:56 < javaprophet> No problem.
01:56 < ecx86> h
01:57 < javaprophet> He said it had something to do with 5 and 6 bit block sizes I think. Hey ecx.
01:59 < PunKeel> (and there is a String in the Join Packet ... causing this error msg. Damn.) It works perfectly, now. Love and everything, <3
01:59 < javaprophet> PunKeel: What's your project?
02:00 < PunKeel> My real project is a BungeeCord (fork) server that is able to translate 1.8 packets into 1.9 and 1.9.1, but I wanted to have a MitM to debug. And it failed :(
02:01 < Gjum> javaprophet: out of 4295 sections in 902 chunks, 232 have weird palette usages
02:01 < javaprophet> Aaah.
02:01 < javaprophet> Gjum, try to analyze what the MC client sees there, maybe you can help Gr um with the bug.
02:06 < PunKeel> KeepAlive is killing me. Funny.
02:13 < Gjum> is there a http api to get a list of all (or some recent) versions?
02:14 < pokechu22> You can probably fetch the version list the launcher uses.  Let's see...
02:14 < Gjum> yup. but restarting mc would take me dozens of minutes on my pc :P
02:16 < Gjum> pokechu22: https://launchermeta.mojang.com/mc/game/version_manifest.json (thanks wurstmineberg!)
02:17 < PunKeel> I'm wondering ... is there a way to disable, as a "server owner", the enableWeakAttacks option ? (I mean, force a setting)
02:17 < Gjum> PunKeel: via modding, certainly; via config... look at the current fields ;)
02:17 < Gjum> I believe some server.properties fields were added in 1.9
02:18 < PunKeel> --' You're absolutely right, should have looked there
02:22 < PunKeel> Looks like no option was added in server.properties / gamerule :(
02:23 < pokechu22> Well, fortunately that makes creating a mod for it pretty easy :P
02:24 < Gjum> can't find anything in mcp either
02:24 < PunKeel> Hope we'll one day be able to run commands on the clientside. Like `sed -i 's/enableWeakAttacks=true/enableWeakAttacks=false' options.txt`. :(
02:26 < Gjum> nothing beats `execute '%!python -m json.tool'`
02:26 < PunKeel> +1 for python
02:30 < PunKeel> I really like the enableWeakAttacks option, I'm going to sell that as an option on my factions shop. :D (jk, but that would be fun)
02:36 < ackpacket> PunKeel: the default clients log all packets if you want to debug
02:36 < ackpacket> PunKeel: The problem with translating 1.8 to 1.9 is... what're you going to do about the new stuff
02:37 < PunKeel> ackpacket : it doesn't log the packet's content, or my conf. is wront
02:37 < pokechu22> Yea, it seems like the content logging got removed in 1.8 :/
02:37 < ackpacket> PunKeel: So, you're saying you want a simple mitm?
02:37 < PunKeel> Absolutely
02:38 < ackpacket> I might have such a thing already, I remember extracting the networking aspect out of a client a year or two ago in order to make a proxy for dumping
02:38 < ackpacket> Let me look around
02:38 < ackpacket> do you care what it's written in?
02:38 < PunKeel> I don't care at all
02:38 < ackpacket> Do you need the proxy to parse the packets as well?
02:38 < Gjum> PunKeel: https://github.com/PrismarineJS/node-minecraft-protocol/blob/master/examples/proxy/proxy.js
02:38 < PunKeel> yup, that's the "whole point"
02:39 < ackpacket> Are you looking for one with encryption enabled?
02:39 < Gjum> you can even ignore packets or set a version
02:39 < PunKeel> it's for localhost use, so I don't care about encryption/performance
02:39 < PunKeel> Gjum don't tell me this thing works --' I've been using minecraft-data's protocol.json for now, and this was lying next to it
02:39 < Gjum> I use it all the time! :D
02:40 < ackpacket> oh, well, there you go then :D
02:40 < Gjum> and rom1504 does a great job keeping it updated
02:40 < Gjum> it will even work for 1.7 and mcpe soon
02:41 < PunKeel> Amazing ... and I struggled for 2(3?) hours just to support 1.9.1-pre2. You're driving me crazy D:
02:41 < PunKeel> Thanks, :-)
02:41 < rom15044> It already works for 1.7 ;)
02:41 < Gjum> strange, the version_manifest.json is minified, but the 1.9.1-pre2.json isn't...
02:42 < Gjum> they even use 4 spaces!
02:43 < rom15044> https://github.com/PrismarineJS/minecraft-data/blob/master/data/common/protocolVersions.json is a list of all versions numbers BTW, idk if that's what you were looking for
02:43 < rom15044> It's taken from wiki.vg version list page
02:43 < Gjum> nah I'll parse mojang api already, thanks :)
02:44 < PunKeel> rom15044 wiki.vg's version page is not up to date :( (Had to update it before I joined #mcdevs)
02:44 < rom15044> Yeah it's missing the 1.9.1 pre I think
02:45 < PunKeel> wtf, I added it later "today" ... 0_o
02:46 < Gjum> timezones are hard
02:48 < pokechu22> Pretty sure that the default timezone is UTC.  You can change the timezone setting on http://wiki.vg/Special:Preferences#mw-prefsection-datetime
02:49 < PunKeel> pokechu22 the issue is not wiki.vg's timezone, but "our" timezone. I'm GMT+1, but idk about anything you ;)
03:00 < Gjum> ahh nice it works: curl `mcurl` > minecraft_server_1.9.1-pre2.jar
03:02 < rom15044> What is mcurl ?
03:02 < Gjum> this script: https://gist.github.com/Gjum/40ef2ca650058cecc4b8
03:03 < rom15044> https://github.com/rom1504/node-minecraft-wrap can download all the MC servers btw
03:03 < Gjum> download any version's client or server jar
03:03 < Gjum> very useful for mcp
03:04 < pokechu22> I've found https://mcversions.net/ to be useful - it basically parses that list and gives the regular client and server jar links.
03:04 < rom15044> Ah it's interesting for the client indeed, it doesn't have a predictable url like the server
03:04 < Gjum> yup, essentially the same, but command line is 2 minutes faster :D
03:05 < Gjum> also auto-downloads the latest version by tefault, without needing to look it up manually
03:05 < Gjum> *default even
03:07 < rom15044> Ah yeah nice
03:08 < rom15044> I might integrate that list parsing in mc-wrap
03:08 < Gjum> rom15044: proxy fails for me, even though I did npm install :/
03:08 < pokechu22> FYI, both the client and the server do actually have predictable URLs.  It's just that the launcher (and the wiki)  uses a different set.
03:09 < pokechu22> EG https://s3.amazonaws.com/Minecraft.Download/versions/1.9-pre2/1.9-pre2.jar
03:09 < Gjum> yeah the s3 ones
03:09 < Gjum> although you have to know the version ID for these
03:09 < Gjum> I wanted a way to get the latest snapshot/release from the cmd line
03:09 < rom15044> Gjum: did you pull and are you giving "1.9.1-pre2" as the version?
03:11 < Gjum> yes
03:11 < rom15044> pokechu22: ah interesting
03:11 < PunKeel> I'm still trying to find out if a 1.9.1-pre2 client with the magical option uses the same behaviour as 1.9.0 or not ... I don't get the difference :[
03:12 < rom15044> Gjum what error do you get ? It was working for me...
03:12 < Gjum> node-minecraft-protocol/dist/createServer.js:29
03:12 < Gjum> var version = mcData.version
03:12 < Gjum> TypeError: Cannot read property 'version' of null
03:12 < Gjum> but it said it updated to minecraft-data@1.2.6
03:14 < Gjum> ah, do I have to pull mcdata manually?
03:14 < rom15044> No
03:14 < rom15044> How are you starting the proxy exactly?
03:15 < Gjum> node proxy-chunk-dump.js --dump-all ...some -x flags... localhost 1.9.1-pre-2
03:15 < Gjum> oh right, one - too much
03:17 < Gjum> hmm, different error now :P
03:19 < rom15044> Really ? Is it a pebkac error again :p ?
03:20 < Gjum> rom15044: are you in #PrismarineJS/minecraft-data ?
03:25 < ackpacket> I'm working on laptop and fml, the client just eats up resources.  Ram, cycles, you name it.  Anyone have any recommendations for reducing the client's usage? I don't care if it's crippled or inconvenient, I just need to view certain worlds
03:26 < Gjum> ackpacket: reduced view distance probably helps
03:26 < ackpacket> Pretty much there already
03:26 < pokechu22> Optifine if you can get it to work, maybe.
03:26 < pokechu22> Or even load it with MC-edit...
04:29 < Gjum> Grum: the 0-padding is gone, but there are still chunks with block keys that are not in the palette or with palettes with unused keys. gist with world save, analysis code, result log part: https://gist.github.com/Gjum/0375b643ec13a42ab3c0#file-unusual-chunks-log
04:34 < Gjum> those chunks are coincidentally the same as those with -1 palette entries...
04:40 < Gjum> looking at them ingame does not reveal any special properties
05:17 < PunKeel> I really really want 1.9.1-pre3 to see how the new option is handled. :(
05:28 < ackpacket> Anyone have any luck running mc through a SOCKS proxy using the java args -DsocksProxyHost?
05:58 -!- Fenhl changed the topic of #mcdevs to: A haunt for developers working on projects related to Minecraft | Website & Rules: http://wiki.vg/MCDevs/rules | Wiki: http://wiki.vg | Channel is publicly logged as of Feb.25/13 https://logs.rom1504.fr/
05:59 <+Fenhl> tktech: thanks, I didn't know that, it's not like ChanServ tells you
06:22 < Not-9c26> [wiki] Edit by Fenhl to Protocol -> http://tinyurl.com/hf6qppr
06:25 < PunKeel> @Fenhl I don't get it. Why don't you merge in a single move ? (no offense, innocent question)