11:55 < gurun> well, if i can't "express myself" and "make money" at the same time, i'm afraid "make money" have preceedence. 12:04 < xehbit> laad.nl 12:04 < xehbit> whoa 12:04 < xehbit> wrong focus on window, sorry 12:09 < jast> not sure how that is relevant... you can always express yourself. all you need is turing completeness. 12:10 < jast> I'm just saying, if I can implement something in one hour in $language and it takes me ten hours in java... guess which is going to be my choice 12:53 < rom1504> yeah... but sometimes you need libraries 12:53 < rom1504> and these are in java 12:53 < rom1504> (and other popular languages) 12:54 < rom1504> ocaml and haskell got things to do compiler, but not necessarily for what you actually need to build 15:42 < TkTech> nickelpro: I can put it up under mcdevs, solum was officially marked as deprecated for six months, after which I removed it 17:53 < Techcable> In the Player list packet, is the display name the one shown above the head or is it the name 17:55 < Thinkofdeath> its the name that displays in the tab list 17:55 < Thinkofdeath> the overhead name is the username field 17:55 < Techcable> Thank you, great work on Spigot 1.8 btw 18:05 < nickelpro> TkTech: it's quite the useful little lib, I'd appreciate it having a place to live and will look into expanding or maintaining it if there is a need. 18:40 < TkTech> nickelpro: Jawa is the successor, but I never had time to really iron it out, or to port Burger to it 18:41 < barneygale> Jawa looked so nifty, I'm sad it never got finished 18:55 < TkTech> http://jawa.tkte.ch/ 18:55 < TkTech> Jesus it's been 3 years 18:55 < SinZ> inorite 18:57 < TkTech> nickelpro, what do you think about porting to Jawa if I put it back up? It would be a decent bit of work, a few days at least to port. 18:58 < TkTech> Internally, Jawa is a fair bit better and even allows mutation of the bytecode. 18:59 < TkTech> Would be happy to fix bugs when encountered, no real tests for either Jawa or solum 19:00 < TkTech> https://gist.github.com/TkTech/55df29d74b41ddd744cc 19:00 < TkTech> An example of using Jawa to generate a Hello World! JVM app from scratch 20:42 < nickelpro> TkTech: Expanding Burger is what I'm really after, I'd be willing to port Burger to Jawa. It looks like you guys made the attempt a number of years ago 20:45 < TkTech> nickelpro: I think (I seriously have no memory past like 2 weeks) I was using burger as a test for Jawa's capabilities 20:45 < TkTech> I had just, just, just started it 20:47 < nickelpro> well its a starting point for me and a good bit better than starting from scratch. Spock has hit a maintenance wall with regards to extracting values from MC and this seems the best direction to go 20:48 < TkTech> What would spock be? 20:48 < TkTech> Also, https://github.com/TkTech/Jawa 20:48 < TkTech> Jawa is now public again and will remain so 20:48 < nickelpro> ty :) 20:48 < TkTech> (Don't laugh at it, some things in there are silly :3) 20:48 < TkTech> https://github.com/TkTech/Jawa/tree/speed_freak 20:48 < nickelpro> Spockbot https://github.com/SpockBotMC/SpockBot 20:48 < TkTech> It looks like as recent as 10 months ago I was working on a faster fork 20:48 < TkTech> Although, seriously, I don't remember doing so. 20:54 < TkTech> Hm, it's a complete rewrite in there 20:56 < TkTech> Partial parsing support...when did I add this... 21:11 < gamingrobot> TkTech: what did you use to make http://jawa.tkte.ch/ ? 21:12 < gamingrobot> nvm sphinx 21:19 < TkTech> gamingrobot: That's the default sphinx theme as well. Most people these days use the readthedocs template (http://www.tkte.ch/tinycrawler/) 21:21 < TkTech> nickelpro: Yeaaaaah, just ignore the other branches, master is fine 21:22 < TkTech> https://gist.github.com/TkTech/de514a610d75543f8a5e 21:23 < TkTech> 0.085 seconds to assemble a functional Hello World, I'd say that's pretty good. 21:24 < nickelpro> A java bytecode assembler in Python, TkTech you should publish more /r/programming eats this stuff up 21:25 < TkTech> It hasn't really been tested, especially with the new JVM features 21:25 < TkTech> Probably fuuuuuuullllll of bugs 21:25 < TkTech> (if you find one just make an issue and I'll try to fix it quick) 21:26 < TkTech> I was going to make a clone of Jasmin first, on top of the lispy assemble() function. 21:48 < Not-311d> [Jawa] TkTech pushed 1 commit to master [+0/-0/±1] http://git.io/pMAZ 21:48 < Not-311d> [Jawa] TkTech 567cbe3 - Added a shortcut to access a static class field's ConstantValue attribute. Also corrected docstrings and indentation for PEP8. 21:53 < Not-311d> [Jawa] TkTech pushed 1 commit to master [+2/-0/±0] http://git.io/pMp1 21:53 < Not-311d> [Jawa] TkTech a088115 - Minimal README and LICENCE. 22:26 < Not-311d> [Jawa] TkTech pushed 2 commits to master [+2/-0/±1] http://git.io/pDYC 22:26 < Not-311d> [Jawa] TkTech ce85872 - Optional pytest dependency. 22:27 < Not-311d> [Jawa] TkTech 49a762d - Added simple parsing integration test for the world-standard HelloWorld.class example. 22:29 < TkTech> *a wild test appears* 22:35 < TkTech> That *one* test jumped coverage up to exactly 50% :) 22:35 < Not-311d> [Jawa] TkTech pushed 1 commit to master [+0/-0/±1] http://git.io/pDso 22:36 < Not-311d> [Jawa] TkTech c03fb3e - Add the py.test coverage plugin package (pytest-cov) as an extra dependency. 22:57 < Not-4e01> [mineflayer] roblabla pushed 2 commits to master [+0/-0/±4] http://git.io/pD8G 22:57 < Not-4e01> [mineflayer] rom1504 d5d362c - bot.onGround is bot.entity.onGround now, y is now always the feet position, and there's a location field instead of (x,y,z) in block_dig packet 22:57 < Not-4e01> [mineflayer] roblabla 4c57dd4 - Merge pull request #201 from rom1504/master some fixes in order to make digger.js work again 22:59 < Not-311d> [Jawa] TkTech pushed 1 commit to master [+0/-0/±1] http://git.io/pD46 22:59 < Not-311d> [Jawa] TkTech fd68b62 - Add a note on Stack Map problem to the README. 23:00 < TkTech> That's it for me for now, off to my Grandfather's 74th. 23:03 < roblabla> I still want to do a JSON representation of the protocol 23:03 < roblabla> :P 23:03 < roblabla> rom1504, 23:03 < roblabla> that´s what Protocols is all about right now. 23:04 < rom1504> oh nice :) 23:05 < roblabla> Of course we'll still have the code implementing reading all the "usual" datatypes 23:05 < roblabla> (Ergo ints, floats, arrays, structures, strings, etc...) 23:05 < roblabla> But the idea is that the packet structures are stored in a JSON, so we can easily generate a documentation of the protocol 23:06 < roblabla> (among other things) 23:08 < rom1504> yeah I get that, json is easier to process that js 23:38 < Xor_Boole> is the following a bug: the vanilla client will display two skulls with the same UUID with different valid, Yggdrasil-signed skin blobs but show different skins. 23:38 < Not-4e01> [mineflayer] roblabla pushed 2 commits to master [+0/-0/±2] http://git.io/pDiY 23:38 < Not-4e01> [mineflayer] roblabla cae324f - Fix updateBlock, remove column from chunkColumnLoad 23:38 < Not-4e01> [mineflayer] roblabla ee4f740 - Merge pull request #202 from roblabla/bugfix-map-handling Some places still used metadata. Fixed them. 23:39 < Xor_Boole> according to a tweet by DB, this is opposite of intended behavior, irrc 23:39 < roblabla> Xor_Boole, maybe if the guy changed skin between the time client got one or the other ? 23:40 < roblabla> other than that, IDK. 23:40 < Xor_Boole> roblabla no, this is a constructed senario 23:40 < Xor_Boole> I create a skull, change my skin, create a second skull 23:40 < Xor_Boole> both show the same 23:41 < Xor_Boole> at least, according to my last test 23:41 < Xor_Boole> I know why this happens, and it's because the skins are cached in the client according the UUID on the skull item 23:41 < Xor_Boole> so to get it to "work" you need fake UUIDs 23:41 < Xor_Boole> but obviouslly this is suboptimal 23:43 < roblabla> so you want both skulls to change skin ? 23:43 < Xor_Boole> no, I want the skin the remain static after skull creation 23:43 < roblabla> oh 23:43 < Xor_Boole> which is the intended behavior, I believe 23:43 < roblabla> Don't think so 23:43 < Xor_Boole> let me dig up the DB tweet 23:44 < roblabla> a player skull is supposed to represent the player's current skin 23:44 < roblabla> at least from your average player perspective 23:48 < Xor_Boole> this https://twitter.com/Dinnerbone/status/464414369452142592 23:49 < Xor_Boole> therefore, as I understand it, it is a bug 23:49 < Xor_Boole> unless this is no longer the case, in which case I am a sad panda 23:49 < Xor_Boole> roblabla ^ 23:50 < roblabla> hmm, true 23:51 < roblabla> I find that a bit confusing though 23:51 < roblabla> but it does have its uses :D --- Day changed ven. mars 13 2015 03:24 < TkTech> I *think* it's working, but a new version of the wikibot should be up. 03:24 < TkTech> We'll see when someone makes an edit to the wiki. 05:31 < nickelpro> TkTech: I don't know anyone else who codes python like you do. It seems like you use every single python-ism somewhere, even in small projects 06:06 < Fenhl> TkTech: well I just edited the wiki. 07:59 < TkTech> nickelpro: I'm going to take that as a positive thing... :) 07:59 < TkTech> Keep in mind that a lot of what I put on github are things I did quickly or for fun, they haven't been properly profiled, are usually missing tests, don't have good documentation, etc... 08:00 < TkTech> I spend all day filling out SRED research documenation and profiling bottlenecks, saps it right out of you by the time you get home 08:00 < TkTech> Fenhl: Hm 08:01 < dx> TkTech: fix your shit 08:01 < dx> TkTech: also there are two notifico instances from the same IP in this channel right now 08:03 < TkTech> dx: Yup. irc.freenode and chat.freenode. 08:03 < TkTech> Given an arbitrary set of hostnames, port, and SSL settings, you can end up with a lot of connections. 08:04 < TkTech> dx: Also, not a notifico bug, the wiki thing is WikiBot being bad. 08:04 < TkTech> Notifico is never getting a message. 08:05 < dx> TkTech: i blame notifico anyway 08:06 < dx> TkTech: you seem to have more free time lately (more than 0), is this something that will end shortly and we should enjoy it while it lasts? 08:07 < TkTech> Eh, it comes and goes. I don't really decide it. 08:10 < Not-4e01> [wiki.vg] Edit by TkTech to Sandbox -> http://wiki.vg/index.php?title=Sandbox&diff=6515&oldid=6513 08:11 < dx> \o/ 08:14 < TkTech> And good night, 3AM 11:51 < SnowDapples> Does anyone happen to have a precompiled Version of the ProtoProxy tool laying around? 13:07 < Not-4e01> [mineflayer] roblabla pushed 2 commits to master [+0/-0/±4] http://git.io/p9I0 13:07 < Not-4e01> [mineflayer] deathcap a83d34e - Update biomes enum for MC 1.8 13:07 < Not-4e01> [mineflayer] roblabla 359966a - Merge pull request #197 from deathcap/biomes Update biomes enum for MC 1.8 14:06 < toqueteos> stupid question, does difficulty change on server.properties i an op changes server difficulty in-game? 14:09 < toqueteos> or any other key on server.properties 14:12 < Gjum> I think that's stored per-world 14:12 < Gjum> not sure tho 14:15 < toqueteos> ty Gjum, it's actually stored per-world, i'm worried now with white-list 14:16 < Gjum> hm, whitelist is updated live I believe 15:07 < ensirius> hm, why can chest not spawns? 15:07 < ensirius> sign for example spawns corretcly 15:08 < ensirius> spawn* 16:36 < morfin> i forgot if Minecraft server can't handle ticks it just increase length? 16:52 < morfin> so every tick happen not every 0.05 seconds 17:49 < nickelpro> morfin: If ticks take longer than 1/20 of a second, tick rate slows down. Not doing the work each tick isn't an option 17:50 < nickelpro> 20tps is the default maximum tick rate, there is no minimum, and tick rate can fluctuate quite a bit on busy servers 17:57 < morfin> i don't understand how that works 17:57 < morfin> oh wait 17:57 < morfin> i meant timer fire event not every 1/20 second 17:57 < morfin> as example every 1/10 second 17:57 < morfin> but every tick do something 18:07 < nickelpro> morfin: I'm not sure I understand your question. Everything is done on a tick basis in Minecraft. So if tick rate slows down, everything slows down 18:14 < morfin> i know that 18:54 < Gjum> morfin: you mean you have multiple timers? one for minecraft ticks (1/20), one for some other things (e.g. 1/40)? 20:42 < ensirius> how corretcly spawn tile entity? 21:54 < toqueteos> is there any distributed server for mc working out there? 22:55 < Not-311d> [Jawa] TkTech pushed 5 commits to master [+1/-1/±9] http://git.io/p5Ho 22:55 < Not-311d> [Jawa] TkTech 37016f6 - Add test_requires to setup.py; Updated extra requirements to include sphinx for documentation generation. 22:55 < Not-311d> [Jawa] TkTech 006331d - Fix rouge underscore in docstring. 22:56 < Not-311d> [Jawa] TkTech 3cb48f1 - Small module-level docstring for cf.py 22:56 < Not-311d> [Jawa] ... and 2 more commits. 22:56 < Not-311d> [Jawa] TkTech pushed 1 commit to gh-pages [+3/-3/±46] http://git.io/p5Hh 22:56 < Not-311d> [Jawa] TkTech 2fc6d72 - Update documentation 23:10 < Not-311d> [Jawa] TkTech pushed 1 commit to master [+1/-0/±1] http://git.io/p5bx 23:10 < Not-311d> [Jawa] TkTech 87577af - Added a Hello World! example inline to the documentation. 23:10 < Not-311d> [Jawa] TkTech pushed 1 commit to gh-pages [+2/-0/±3] http://git.io/p5bj 23:10 < Not-311d> [Jawa] TkTech 9030023 - Update documentation --- Day changed sam. mars 14 2015 01:03 < Prodev> How do you give multiple commands to command blocks? 01:47 < rom1504> Hi, does someone know how we're supposed to handle onGround on 1.8 ? Since 0x08 packet doesn't send it anymore ? 01:51 < nickelpro> rom1504: Clientbound or Serverbound? 01:51 < nickelpro> Serverbound is PLAY>0x06 01:51 < nickelpro> http://wiki.vg/Protocol#Player_Position_And_Look_2 01:52 < nickelpro> Clientbound hasn't been necessary for a long time as far as I know 01:54 < rom1504> clientbound 01:54 < rom1504> how is it not necessary ? doesn't that make the bot fall ? 01:54 < nickelpro> rom1504: Server doesn't do physics, the client does 01:55 < rom1504> hmmm 01:55 < rom1504> ok 01:55 < rom1504> thanks 01:56 < rom1504> I'm trying to fix mineflayer physics 01:56 < nickelpro> Server only periodically checks to make sure you aren't grossly violating any physical laws by obviously flying or moving through blocks 01:56 < nickelpro> Vanilla Notchian Server* 01:56 < rom1504> yeah ok 01:56 < rom1504> oh right 01:57 < nickelpro> The only thing on_ground is still used for is to inform the server when it should apply fall damage AFAIK 01:57 < nickelpro> If you never change it, the client will never recieve fall damage 01:57 < rom1504> mineflayer was using the onGround thing to know if the bot should fall or not 01:57 < rom1504> since the server doesn't send it anymore apparently, that's annoying 01:57 < nickelpro> You fall when you're not intersecting with anything below you 01:58 < nickelpro> on_ground is hacky 01:58 < rom1504> yeah ok 02:02 < rom1504> might just be about the bounding boxes 02:02 < rom1504> apparently they changed 02:02 < rom1504> and they aren't up to date in mineflayer yet 02:03 < rom1504> well I guess we'll figure it out 02:16 < Gjum> actually a client can 'fly' above a half block, as if it was a full block 02:18 < Gjum> and the (vanilla) server will not detect that as flying 02:22 < nickelpro> TkTech: How much do you mind a few extra lines to support Python3 in Jawa? 02:52 < gamingrobot> nickelpro: ohhhhhh so thats why my teleport code kept killing the player 02:53 < nickelpro> gamingrobot: Dropping people from high places does that 02:53 < gamingrobot> I was dropping the player from 1 block and killing them 02:53 < nickelpro> Impressive 02:53 < Gjum> lol 02:53 < Gjum> pretty fragile I would say 02:54 < gamingrobot> That was my thought 02:55 < Gjum> well I save me the hassle and tp to y256, to the wanted xz, y still 256, and down to the wanted xyz, vanilla server never checks vertical collision ^^ 03:26 < nickelpro> fastmc has two different types of slots, the regular slot as documented on the wiki http://wiki.vg/Slot_Data and a "slot_1_8" that doesn't have an nbt size associated with it https://github.com/dividuum/fastmc/blob/master/fastmc/proto.py#L318-L366 03:27 < nickelpro> I've encountered a bug where slots failed to decode because of NBT weirdness and I suspect it's because of this "new" slot type, anyone have any details? 03:37 < nickelpro> Ignore all above I am dumb 04:13 < TkTech> Hah. 04:13 < TkTech> nickelpro: Hm 04:13 < nickelpro> TkTech: Hmmmm 04:13 < TkTech> nickelpro: Might be time to introduce six as a dependency? 04:13 < TkTech> HMMMMMMMMMMMM 04:14 < nickelpro> TkTech: It's really just the IO imports and a little sting handling 04:14 < nickelpro> Hardly worth the effort 04:14 < nickelpro> Oh and that one tuple 04:15 < dx> sounds like not even worth asking for permission to TkTech 04:16 < nickelpro> But it's your project, up to you. Py3 is pretty big in our pipeline so I like to maintain compatibility when it's easy 04:16 < nickelpro> dx: PR is on his repo, his call 04:17 < dx> oh. it's been there for two hours. okay. 04:20 < TkTech> nickelpro: https://github.com/SpockBotMC/Jawa/blob/905dcfb540c00ffc36b7cf718762548239a911da/jawa/constants.py#L412 04:20 < TkTech> nickelpro: This is probably missing a decode 04:21 < TkTech> def version(self, (major, minor)) seriously doesn't work in py3k? That's an unfortunate change. 04:22 < nickelpro> TkTech: Lots of reasons https://www.python.org/dev/peps/pep-3113/ 04:24 < TkTech> Justified 04:25 < TkTech> nickelpro: Can you add the missing decode to your PR and I'll merge it. 04:26 < TkTech> nickelpro: You're explicitly encoding it as utf-8 when you write, but never decoding it when it's read in 04:27 < nickelpro> TkTech: Ya I thought doing so in the constant class was enough but apparently not 04:29 < TkTech> nickelpro: That particular line is a special case. 04:29 < TkTech> nickelpro: That read() of UTF-8 strings is the (cumulatively) slowest method in Jawa. 04:29 < TkTech> nickelpro: If you try to parse all of minecraft's jar for example, most of the time will be spent doing io for that read. 06:35 < nickelpro> TkTech: There are two classfiles in the 1.8.3 Minecraft jar that contain invalid UTF-8 strings. One of them is avo.class, I haven't bothered tracking down the other one. Any thoughts on why? 06:36 < nickelpro> They're not valid anything strings as far as I can tell 07:06 < dx> opened avo.class in radare, got a bunch of nonsense bytecodes, and found a bug in radare that makes it eat a few gb of ram until the kernel kills it 07:07 < dx> good software. 07:12 < dx> oh latest git fixes it. 08:02 < Not-4e01> [mineflayer] roblabla pushed 2 commits to master [+0/-0/±2] http://git.io/pF8u 08:02 < Not-4e01> [mineflayer] rom1504 cdd9934 - Fix position : jumper.js can now make the bot move, it's still now falling though 08:02 < Not-4e01> [mineflayer] roblabla 31e7429 - Merge pull request #211 from rom1504/fix_position Fix position : jumper.js can now make the bot move 08:08 < Not-4e01> [mineflayer] roblabla pushed 2 commits to master [+0/-0/±18] http://git.io/pF42 08:08 < Not-4e01> [mineflayer] rom1504 3c8a18d - Add argv parameters to createBot in the examples, fix #204 08:08 < Not-4e01> [mineflayer] roblabla 6d01c24 - Merge pull request #208 from rom1504/argv_examples Add argv parameters to createBot in the examples, fix #204 13:27 < Not-4e01> [mineflayer] roblabla pushed 4 commits to master [+0/-0/±9] http://git.io/pboq 13:27 < Not-4e01> [mineflayer] rom1504 f43cd19 - start fixing the bot.players creation and update (player_info package changed) 13:27 < Not-4e01> [mineflayer] rom1504 f9e189a - Add bot.uuidToUsername because named_entity_spawn packet doesn't provide the username anymore, fix spawnPoint, comment display of time in chatterbox 13:27 < Not-4e01> [mineflayer] rom1504 c6fd466 - Merge branch 'master' of github.com:andrewrk/mineflayer 13:27 < Not-4e01> [mineflayer] ... and 1 more commits. 13:47 < Not-4e01> [mineflayer] roblabla pushed 1 commit to master [+0/-0/±1] http://git.io/pbMz 13:47 < Not-4e01> [mineflayer] roblabla e246b8e - Project is being updated.Add gitter chatroom link. 14:06 < ensirius> guys, how corretcly spawn chest/furnace? both invisible 15:15 < ensirius> and how server sends block face/direction? 15:33 < ensirius> oh, nvm, solved --- Day changed dim. mars 15 2015 15:37 < gurun> So, bukkit didn't appreciate this, but i'm sure you guys will. 15:38 < gurun> I'm declared Mojang as one of the biggest contributors to spreading interest for programming with the kids, of all time. Mojang problably did more for programming than any other company that exist or existed up til today. 15:39 < gurun> I wish we had a nobel price for computing science, because Mojang would get that. 15:43 < rom1504> I don't thing any nobel price reward vulgarisation 15:48 < gurun> any and all prices reward that, come on! :-P 16:01 <+Amaranth> gurun: It's called the Turing Award 16:04 < gurun> Amaranth, yeah, looks like it :-) --- Day changed lun. mars 16 2015 02:34 < squeegily> Does anybody know how Minecraft queries for Alex/Steve skin type? 02:34 < squeegily> How does it know the difference between a 64x64 Steve skin and a 64x64 Alex skin 02:35 < squeegily> It currently seems to be undocumented http://wiki.vg/Minecraft.net 03:30 < TkTech> nickelpro: I'm taking a look now, was busy with new steam games :) 03:34 < squeegily> TkTech: If you figure it out, can you /msg me? 03:34 < squeegily> Even with Google, I can't seem to figure it out 03:37 < TkTech> squeegily: Your name isn't nickelpro. 03:38 < squeegily> Whoops 03:38 < dx> squeegily: try /nick nickelpro 03:38 < squeegily> lol 03:38 < dx> you might have to murder nickelpro first 03:39 < dx> i don't recommend doing that unless it's worth it 03:41 < dx> squeegily: that page you linked is username based, which is deprecated. see http://wiki.vg/Mojang_API#UUID_-.3E_Profile_.2B_Skin.2FCape 03:42 < dx> in fact that page isn't linked from anywhere else in the wiki, how did you get there? 03:43 < squeegily> dx: Google 03:43 < dx> lol 03:43 < squeegily> As I was looking around for info on the protocol 03:43 < squeegily> dx: Do you have any idea how to query Alex/Steve status? 03:44 < dx> i think you just fetch the blob as with any other skin and the server returns either of those 03:44 < dx> it's not a special status 03:45 < squeegily> dx: How does Minecraft know whether to render 3px or 4px arms though? 03:46 < dx> what 3px arms 03:46 < squeegily> dx for the Alex model 03:46 < squeegily> it's been around for a while 03:47 < squeegily> Unless U R troling me 03:47 < squeegily> And pretending to be ignorant of this feature in which case I see through the ruse 03:47 < dx> uhm 03:47 < dx> i know about the skin, i just didn't know about the detail that it had 3px arms 03:48 < dx> squeegily: that's answered in the link i gave you 03:50 < squeegily> dx: So I get the UUID, then use that to get the sessionserver response, then extract the base64 blob from that, and if the user has a steve/alex set, it'll show in the model attribute? 03:51 < dx> there's an example response there 03:51 < dx> and yes 03:52 < squeegily> Do you have any friends who use the Alex model that I could test it on? 03:55 < dx> nope 04:01 < nickelpro> Don't kill nickelpro 04:01 < nickelpro> He's a decent kid 04:02 < nickelpro> TkTech: I feel you brother, I just got into XCOM the last couple days and it absorbed my weekend. I was going to do so many things this weekend... 04:13 < TkTech> nickelpro: Cities: Skyline is all the rage today since it's on sale on GmG for $22USD 04:21 < TkTech> nickelpro: It's looking like the safest thing to do is to treat ConstantUTF8 as a byte string at all times. 04:21 < TkTech> nickelpro: But that's the lazy solution. 04:21 < TkTech> nickelpro: It's not "real" UTF-8, as usual Java bastardized it. So we need a bit of custom decoding. 04:23 < TkTech> nickelpro: http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.4.7 04:32 < TkTech> nickelpro: I'll throw in a convert_modified_utf8 under util tomorrow 04:32 < TkTech> nickelpro: Off to bed, later! 05:08 < Not-311d> [Jawa] TkTech pushed 1 commit to master [+0/-0/±1] http://git.io/hfHJ 05:08 < Not-311d> [Jawa] TkTech 6e92bce - Started work on a 'Why Jawa' section in the documentation. 05:08 < Not-311d> [Jawa] TkTech pushed 1 commit to gh-pages [+0/-0/±3] http://git.io/hfHU 05:08 < Not-311d> [Jawa] TkTech 76e1567 - Update documentation 05:09 < TkTech> (I lied) 05:13 < Not-311d> [Jawa] TkTech pushed 1 commit to master [+0/-0/±1] http://git.io/hfH5 05:13 < Not-311d> [Jawa] TkTech 0ad7a2a - Add mention of the licence under 'Why Jawa' 05:13 < Not-311d> [Jawa] TkTech pushed 1 commit to gh-pages [+0/-0/±3] http://git.io/hfHF 05:14 < Not-311d> [Jawa] TkTech df2dd78 - Update documentation 06:12 < nickelpro> TkTech: wow, of course they do. I about half understand their reasoning but surely their could be a better way than fucking such a useful standard 06:23 < dx> JSON has the same surrogate pair bullshit because its unicode escapes can only go up to \uFFFF 06:25 < dx> the thing about preventing embedded null bytes is ehhhh. 06:28 < dx> would be nicer if that null byte thing was part of the original utf8 spec tbh. sounds convenient to have, but doesn't seem worth having an incompatible encoding 12:48 < Not-4e01> [wiki.vg] Edit by Rom1504 to Client List -> http://wiki.vg/index.php?title=Client_List&diff=6516&oldid=6512 12:54 < rom1504> oh there's a bot for this now ! 12:55 < rom1504> much bots 12:55 < dx> lol features "doesn't compile" 13:12 < rom1504> best feature 13:12 < rom1504> :D 13:14 < Not-4e01> [mineflayer] roblabla pushed 2 commits to master [+0/-0/±2] http://git.io/hUCJ 13:14 < Not-4e01> [mineflayer] roblabla 7712bd6 - fix updateBlock using wrong type and index 13:14 < Not-4e01> [mineflayer] roblabla 372ee64 - Merge pull request #216 from roblabla/bugfix-map-handling fix updateBlock using wrong type and index 13:19 < Not-4e01> [wiki.vg] Edit by Fenhl to Minecraft.net -> http://wiki.vg/index.php?title=Minecraft.net&diff=6517&oldid=4126 13:22 < Fenhl> squeegily: my skin uses the Alex model, feel free to test whatever mad science you're doing on me 13:22 < Fenhl> same nick in Minecraft 13:34 < Not-4e01> [wiki.vg] Edit by Fenhl to Mojang API -> http://wiki.vg/index.php?title=Mojang_API&diff=6518&oldid=6462 14:15 < TkTech> rom1504: It's been around for awhile, just took me 12 months to make a three character change ~(o_o)~ 14:19 < rom1504> ok ^^ 14:34 < squeegily> Fenhl: Thanks! Yours was the last one I needed to finish my testing! 14:34 < squeegily> I really appreciate it 14:37 < Fenhl> np 14:42 < ensirius> http://wiki.vg/Inventory#Windows can somebody add info about workbench? 14:43 < Fenhl> ensirius: what info is missing? 14:43 < ensirius> slot positin 14:44 < ensirius> position 14:44 < Fenhl> ensirius: you mean this? http://wiki.vg/Inventory#Crafting_window 14:50 < ensirius> yes this section 15:00 < squeegily> It takes so much work to download a Minecraft skin the right way! First you have to retrieve and extract the UUID, use that to retrieve a different file, extract a key embedded in that, decode it with base64, then extract a value from within that, and then you have the url which you can download 15:01 < squeegily> But I guess this way is more future-proof than the username-based skins.minecraft.net 15:28 < Fenhl> yes, and if the value within the base64-encoded JSON is missing you need to emulate Java's hash function for UUIDs and modulo the result by 2, so you know which of the default skins is being used 15:28 < Fenhl> still nicer than having the same default skin for everyone though 15:44 * Xor_Boole walks in 15:44 * Xor_Boole sees that horror of an algorithm 15:44 * Xor_Boole runs as fast as his tiny legs allow 15:45 < Xor_Boole> I still fail to see why the skin blob is base64'd 15:45 < Xor_Boole> it'd be much easier to NBT it, since it's probably be a smidgeon smaller 16:16 < ensirius> http://wiki.vg/Protocol#Close_Window "0 for inventory.". I think it's mean player inventory. 16:17 < TkTech> nickelpro: Well, my tests pass now. Don't know if it's actually right tho :P 16:23 < Not-311d> [Jawa] TkTech pushed 1 commit to unicode_support [+2/-0/±1] http://git.io/hTu4 16:23 < Not-311d> [Jawa] TkTech 68ae63f - First stab at properly parsing the modified UTF-8 JVM strings. 16:50 < TkTech> nickelpro: Want to give that branch a shot? 16:51 < TkTech> nickelpro: My test using the failed ConstantUTF8 in avo.class passes decoding now 16:51 < TkTech> Just need to write an encoder 17:33 < Not-311d> [Jawa] TkTech pushed 1 commit to unicode_support [+0/-0/±1] http://git.io/hkeN 17:33 < Not-311d> [Jawa] TkTech d076f36 - Use the new decode_modified_utf8 method when reading in ConstantUTF8 strings. PEP8 constants.py. 17:36 < TkTech> nickelpro: Based on some quick reading, it looks like we only need to handle decoding - we can write normal UTF-8 back to the file and the JVM won't give a hoot. 18:02 < nickelpro> TkTech: Then why the well does the JVM use modified in the first place? 18:04 < TkTech> nickelpro: So far as I can tell it's written in two places; ClassFile ConstantUTF8s and serialized objects. 18:04 < TkTech> nickelpro: In both of these places the original justification was to avoid null bytes in a string that might be parsed by a legacy, null-terminated method. 18:05 < nickelpro> TkTech: Dumb, but Java has always been obsessed with legacy. Works out for them mostly 18:06 < TkTech> nickelpro: Yeah, I can't be super-mad about this one. Easy enough to parse anyways (https://github.com/TkTech/Jawa/blob/unicode_support/jawa/util/utf.py#L1) 18:06 < nickelpro> TkTech: Yep, great work. I'll re-work Py3 support around it and test. I'm halfway through a workable Burger port for 1.8.x 18:07 < TkTech> nickelpro: √ 18:07 < TkTech> nickelpro: I'm going to throw in an encode_modified_utf8 as well to do this properly, but for your work you can just stub it with a return 18:08 < TkTech> I've got some manufactured classes and tests for it as well 18:11 < Not-311d> [Jawa] TkTech pushed 3 commits to unicode_support [+1/-0/±2] http://git.io/hka8 18:11 < Not-311d> [Jawa] TkTech 29e4c93 - Small module docstring for util.utf. 18:11 < Not-311d> [Jawa] TkTech 5ed7819 - Off-by-one fix for UTF-16 surrogates. 18:11 < Not-311d> [Jawa] TkTech b0e262a - Very basic MUTF8 decoder test. 18:44 < TkTech> barneygale: do you know if gsand floats around here under some other nick? 18:45 < TkTech> barneygale: I noticed mark2 is maintained by him now; We can do a transfer so that the original repo and all its followers move over 18:45 < barneygale> Seems to be online at the moment 18:45 < barneygale> (under the nick "gsand") 18:46 < barneygale> I asked gsand about that a couple of months ago. I thought perhaps he liked maintaining it away from the mcdevs organisation, but can't remember exactly what he said 18:46 < TkTech> barneygale: So he is, I typo'd. Want to go ahead? 18:46 < TkTech> barneygale: Oh no, it would be under his name, except github would redirect. 18:46 < barneygale> Ah 18:46 < TkTech> barneygale: And forks would show the proper parent 18:46 < barneygale> That's fine with me then 18:47 < TkTech> barneygale: The easiest way is for him to send you a PR updating the one under mcdevs, then renaming the one he currently has. 18:47 < TkTech> barneygale: Then we transfer mcdevs/mark2 to him 18:49 < barneygale> OK 18:55 < dx> (you could just merge without a PR) 18:56 < dx> the (...) are me covering just in case you're like those who really want to push the big green "merge pull request" button 19:45 < TkTech> nickelpro: https://gist.github.com/TkTech/dcc7f95f5527912e6a5e 19:45 < TkTech> nickelpro: I think this is a correct implementation based off of http://docs.oracle.com/javase/6/docs/api/java/io/DataOutput.html#writeUTF(java.lang.String) 19:45 < TkTech> nickelpro: Not sure how to test it 19:47 < TkTech> I guess an artificial test for each of the three conditions would work. 19:47 < TkTech> Oh, I'm not converting that bytearray back to a string before returning. Whoops. 19:50 < Not-311d> [Jawa] TkTech pushed 1 commit to unicode_support [+0/-0/±1] http://git.io/hIlb 19:50 < Not-311d> [Jawa] TkTech 2a84289 - Added a it-probably-works encode_modified_utf8 method. 20:28 < Not-4e01> [mineflayer] roblabla pushed 2 commits to master [+0/-0/±2] http://git.io/hI1n 20:28 < Not-4e01> [mineflayer] rom1504 9b7bbec - Start fixing block_change : now there's location in the block_change packet and not x,y,z 20:28 < Not-4e01> [mineflayer] roblabla 6a7c824 - Merge pull request #214 from rom1504/fix_falling Fix block_change : fix falling 20:32 < gsand> Hey friends! 20:32 < gsand> :D 20:38 < gurun> TkTech, it would be nice not to get the commits in the channel. 20:40 < Xor_Boole> gsand! 20:40 * Xor_Boole huggles gsand 20:40 < gsand> ey Xor_Boole 20:46 < Not-4e01> [mineflayer] roblabla pushed 2 commits to master [+0/-0/±2] http://git.io/hI7r 20:46 < Not-4e01> [mineflayer] rom1504 ffb0498 - Fix chat test 20:46 < Not-4e01> [mineflayer] roblabla 4e5268e - Merge pull request #215 from rom1504/fix_chat_test Fix chat test 20:46 < gsand> whats mineflavor? 20:46 < gsand> ah 20:46 < gsand> flayer 21:44 < TkTech> gurun: Any related project is free to "spam" #mcdevs. 21:45 < gurun> a java decompiler in phyton? 21:45 < TkTech> gurun: That powers burger and other disassembly tools used to RE minecraft? 21:45 < gurun> but don't worry, i muted the stream, so no problem. 21:45 < TkTech> There ya go. 21:45 < gurun> :-) 21:46 < Wuppie> lol 21:46 < TkTech> (It does kinda predate you by 8 years or so) 21:47 < gurun> which one? 21:47 < TkTech> The m3.medium doesn't appear to give us sufficient IO priority, even if we do push the cores to ~10k sockets a piece. 21:47 < TkTech> Er, wrong tab. 21:50 < gsand> hey man 21:50 < gsand> wassup 21:50 < The_Doctors_Life> nothing 22:02 < kvgeorge1> Good afternoon. I have a question about moving a user from one dimension to another. When the user changes dimensions and the 0x07 is sent to the client, what signals the end of the transition? Is this handled by the client, or does the client send the server something? --- Day changed mar. mars 17 2015 00:10 < nickelpro> The transition is "finished" once the server has sent the client all the chunks for its view distance in the new dimension 00:10 < nickelpro> The effects are all clientside 00:42 < Not-4e01> [mineflayer] roblabla pushed 3 commits to master [+0/-0/±5] http://git.io/htlZ 00:42 < Not-4e01> [mineflayer] rom1504 801ea74 - Fix itemFromNotch : fix list and equip in inventory.js 00:42 < Not-4e01> [mineflayer] rom1504 d0c4401 - Fix build in digger.js, all block_place and block_dig in inventory.js, itemToNotch. This also fix toss in inventory.js 00:42 < Not-4e01> [mineflayer] roblabla 66e0eb5 - Merge pull request #217 from rom1504/fix_inventory Fix itemFromNotch : fix list and equip in inventory.js 00:45 < Not-4e01> [wiki.vg] Edit by Fenhl to Template:Key -> http://wiki.vg/index.php?title=Template:Key&diff=6519&oldid=0 00:48 < Not-4e01> [wiki.vg] Edit by Fenhl to Inventory -> http://wiki.vg/index.php?title=Inventory&diff=6520&oldid=6474 01:08 < Not-4e01> [wiki.vg] Edit by Fenhl to Template:Hatnote -> http://wiki.vg/index.php?title=Template:Hatnote&diff=6521&oldid=0 01:11 < Not-4e01> [wiki.vg] Edit by Fenhl to Template:About -> http://wiki.vg/index.php?title=Template:About&diff=6522&oldid=0 01:26 < Not-4e01> [mineflayer] roblabla pushed 2 commits to master [+0/-0/±4] http://git.io/htVp 01:26 < Not-4e01> [mineflayer] rom1504 5ab8ba7 - Fix use and stop in inventory.js, fix craft in inventory.js. Inventory.js now works 100%. 01:27 < Not-4e01> [mineflayer] roblabla 943b9eb - Merge pull request #218 from rom1504/fix_craft Fix use and stop in inventory.js, fix craft in inventory.js 01:34 < gurun> wow, that was a first for me. A CPU leak .. uhh. 02:09 < Not-4e01> [wiki.vg] Edit by Fenhl to Protocol -> http://wiki.vg/index.php?title=Protocol&diff=6523&oldid=6503 02:09 < rom1504> does someone know if there is something smart to do so that the vanilla server accept placing a block after jumping, every time ? 02:09 < rom1504> placing a block under the bot feet I mean 02:10 < Not-4e01> [wiki.vg] Edit by Fenhl to Protocol -> http://wiki.vg/index.php?title=Protocol&diff=6524&oldid=6503 04:02 < Not-311d> [Jawa] TkTech pushed 1 commit to unicode_support [+0/-0/±1] http://git.io/hqIg 04:02 < Not-311d> [Jawa] TkTech 0e9487e - Use encode_modified_utf8 when writing ConstantUTF8 to the ConstantPool. Always cast newly created ConstantUTF8 values to unicode. 16:51 < Gjum> rom1504: is that still a probem or have you fixed that already? 16:56 < rom1504> Gjum: still a problem 16:56 < rom1504> https://github.com/andrewrk/mineflayer/issues/219 16:58 < Gjum> the server does not do physics, so make sure your last sent position is not in the placed block I guess 17:00 < Gjum> and because tcp keeps the packet order, you could possibly send a movement packet to block_pos + (0,1,0) just before placing, just to make sure you're not in the block 17:04 < Gjum> or try doing it the other way around: when you are high enough (callback to position change), place the block 17:15 < rom1504> well it's actually done like that (https://github.com/andrewrk/mineflayer/blob/master/examples/digger.js#L71) but yeah it would be worth checking what the last position packet is 17:15 < rom1504> I'll try to check that 17:20 < rom1504> right, the physics loop and the sendPosition loop are not on the same time interval, sounds like that's the problem 18:32 < TkTech> nickelpro: How goes it, run into any bugs/annoying interfaces? 19:03 < rom1504> Gjum: that fixed the problem :) (move signal was not sent after the position packet was sent) 20:32 < Not-311d> [Jawa] TkTech pushed 7 commits to master [+3/-0/±6] http://git.io/hs6I 20:32 < Not-311d> [Jawa] TkTech pushed 1 commit to gh-pages [+1/-0/±10] http://git.io/hs6m 20:32 < Not-311d> [Jawa] TkTech bef7285 - Update documentation 20:32 < Not-311d> [Jawa] TkTech deleted branch unicode_support 23:24 < Not-4e01> [mineflayer] roblabla pushed 2 commits to master [+0/-0/±4] http://git.io/hG5p 23:24 < Not-4e01> [mineflayer] rom1504 e1db192 - Fix #219 : bot.emit('move'); must be sent only after the packet position_look has been sent : only sending that packet actually change the position. Remove now unnecessary hack from digger.js. 23:24 < Not-4e01> [mineflayer] roblabla 5057b94 - Merge pull request #220 from rom1504/fix_position_updating Fix #219 : fix updating position 23:26 < Not-4e01> [mineflayer] roblabla pushed 2 commits to master [+0/-0/±2] http://git.io/hGdG 23:26 < Not-4e01> [mineflayer] rom1504 67e644f - Continue fixing crafting (#144) : the crafting slots need to be emptied after a craftOnce 23:26 < Not-4e01> [mineflayer] roblabla d2fb98c - Merge pull request #221 from rom1504/fix_craft Fix #144 : the crafting slots need to be emptied after a craftOnce 23:42 < vemacs> Help the docs are lying to me 23:42 < vemacs> sending block break animation packet with data of 12 or -1 23:43 < vemacs> doesn't reset the thing on the client 23:43 < vemacs> if I repeatedly send block break packet 23:43 < vemacs> the break graphics overlay 23:43 < vemacs> leading to weird stuff like this 23:43 < vemacs> http://i.imgur.com/Awnvpqb.png 23:43 < vemacs> (custom resource pack) 23:43 < vemacs> do I need to send an entity remove or something 23:44 < vemacs> http://wiki.vg/Protocol#Block_Break_Animation 23:44 < vemacs> "0–9 are the displayable destroy stages and each other number means that there is no animation on this coordinate" 23:44 < vemacs> 1.8.3 client --- Day changed mer. mars 18 2015 00:10 < Not-4e01> [mineflayer] thejoshwolfe pushed 1 commit to master [+0/-0/±1] http://git.io/hZkv 00:10 < Not-4e01> [mineflayer] thejoshwolfe 17065d2 - fixing chatterbox example naming items 00:11 < vemacs> tried destroying the entity 00:11 < vemacs> no results either 00:28 < Fenhl> vemacs: I don't know the solution to this problem, but if you find out, please do update the Protocol article 00:30 < vemacs> Yep 00:30 < vemacs> That's weird, time to look how vanilla does it 00:34 < vemacs> // CraftBukkit start - Force block reset to client 00:34 < vemacs> } else { 00:34 < vemacs> this.player.playerConnection.sendPacket(new PacketPlayOutBlockChange(this.world, blockposition)); 00:34 < vemacs> // CraftBukkit end 00:34 < vemacs> } 00:34 < vemacs> that's what CB does 00:57 < Fenhl> Bukkit is outdated though 01:11 < Thinkofdeath> looking at 1.8.3, its using -1 to remove it 01:12 < vemacs> However, both using -1 01:12 < vemacs> and then sending block change packet 01:12 < vemacs> or sending entity destroy packet 01:13 < vemacs> none of them work 01:13 < vemacs> I've also tried a combination of all 3 01:13 < vemacs> It looks like sending block break animation to -1 and then sending the block change packet should work, but it doesn't 01:18 < Thinkofdeath> vemacs: just sending -1 works fine here 01:18 < Thinkofdeath> no block change 01:21 < Thinkofdeath> vemacs: http://gfycat.com/DelightfulIncomparableGelding 02:42 < vemacs> weird 02:43 < vemacs> I must be doing something very wrong then 02:43 < vemacs> Basically, I want to progress the stage like players do 02:43 < vemacs> Not just nuking the old one, but also overlaying the next stage 02:43 < vemacs> that doesn't seem to work for me 05:09 < nickelpro> TkTech: I cant do programming this week, have too much real life going on. Big Thermodynamics test on Thursday and I don't even recognize half the symbols :-/ 05:28 < Not-4e01> [wiki.vg] Edit by Tux to Mojang API -> http://wiki.vg/index.php?title=Mojang_API&diff=6525&oldid=6518 14:58 < gurun> synchronization is a bitch. Without it, the server process 125.000.000 messages. With it only 20.000.000 :-( 14:58 < gurun> per second of course. 15:02 < toqueteos> gurun: how many players is that? (aprox.) 15:03 < gurun> that is 2500 players running around in a circle. 15:03 < gurun> so they are all broadcasting to eachother. 15:03 < gurun> it's just an approximation. In reality it is would most likely be way over 10-20.000 players. 15:04 < toqueteos> that's some nice numbers 15:04 < gurun> it's pretty evident that sync/lock is the problem. Becuase at 20.000.000 the CPU isn't even at 50%, but the receive buffer on UDP keeps growing. 15:05 < toqueteos> well.. if you are in for a ride, you can use position deltas and use cdrt's so you get rid of locks and it still is all in sync 15:06 < toqueteos> according to the theory i read 15:06 < gurun> what is cdrt? 15:07 < toqueteos> http://en.wikipedia.org/wiki/Conflict-free_replicated_data_type 15:07 < gurun> thanks. couldn't find it on google :-P 15:07 < toqueteos> yeah it's a bit.. odd to search 15:07 < toqueteos> it's quite interesting subject to read 15:08 < toqueteos> there's two flavors, commutative and convergent, one requires network order (tcp or something like that), the other does not 15:08 < toqueteos> so *it could* work with your UDP thingy 15:08 < toqueteos> as i said, only if you are in for a ride 15:10 < gurun> hmm, yes. Looks interesting. 15:11 < gurun> I figured that i need to invent something ingenous around the queues i use. To get them not thread-safe, but thread-ignorant like that stuff. 15:11 < gurun> i will try to simply ... create new queueus and see what is worse. JIT new or concurrency. 15:11 < toqueteos> there's also this book http://book.mixu.net/distsys/eventual.html that may help grasping the concepts 15:12 < toqueteos> anyway good luck and happy coding 15:12 < toqueteos> i have yet to get to some sort of quorum with the other hematite devs and coding world object, timers and such.. 15:24 < gurun> lol. thanks 15:28 < gurun> toqueteos, great stuff. I just lock the access when creating a new queue. SO it seems that JIT new is a bit more effecient. Awarded me me 45.000.000/s. Double the performance. 15:28 < gurun> And now the CPU max out at least. 15:28 < gurun> but the code is seriously uggly 15:28 < toqueteos> should it max cpu? what about physics? 15:30 < gurun> yes, it should max out CPU. It's an isolated test, I need to make sure it is threaded properly and no sync waits. 15:30 < gurun> so, when it is not buffering, and CPU can grow to 100% then i know i'm doing i right. 15:31 < gurun> this is consuming 35-40ms of tick-time. SO i still have another 20% left over for physics. 15:32 < gurun> I got this question today you know; I have 40 core and 128Gb RAM. Will MiNET use it. I answered "yes" a bit prematurely because i could see that somewhere in the code it was a cap. A sync wait thing. 15:32 < gurun> and now managed to remove it. 15:33 < gurun> so with 40 core server (if you have the network to deal with it) you should be able to do maybe up to 100k players on one server. 15:35 < gurun> The point of the implementation is to scale with hardware, not with processes. Cloud ready so to say. 15:36 < gurun> put your money on CPU, not maintain 200 servers and 1000 server instances. 15:38 < toqueteos> do big whales want to handle 100k players with just one server? 15:38 < toqueteos> that's 1 step away from total disaster for A LOT of people 15:39 < toqueteos> also a 40 core, 128gb ram server is super-duper expensive 15:39 < toqueteos> but hey, i'm not judging anyone 15:39 < toqueteos> brb lunchtime 16:46 < TkTech> nickelpro: Righto; I'm almost done DEX support. 16:56 < gurun> toqueteos, yeah well, that's not really how cloud stuff works. So it's not really a problem. 21:47 < SupaHam> I'm not reading any limits on Player Count here http://wiki.vg/Protocol#Teams should I assume I can add 200 players and the player would receive and process it just fine? --- Day changed jeu. mars 19 2015 01:02 < rom1504> how should we handle the fact that named_entity_spawn doesn't send the name of the player ? 01:03 < rom1504> I mean 0x0c 01:04 < rom1504> aaaaa 01:05 < rom1504> keeping in memory the dead/disconnected players ? 01:15 <+Amaranth> rom1504: You're supposed to be keeping track of the information the server sends for player list updates 01:30 < rom1504> hmm 01:31 < rom1504> ok --- Day changed ven. mars 20 2015 01:33 < Not-4e01> [mineflayer] roblabla pushed 3 commits to master [+0/-0/±3] http://git.io/h2p4 01:33 < Not-4e01> [mineflayer] rom1504 78de123 - Fix dying (fix #224) : keep the mapping between an uuid and a username when a player dies 01:33 < Not-4e01> [mineflayer] rom1504 3fbf17d - Fix crash when an other player disconnect : player_info with action 4 doesn't send the name, only the uuid 01:34 < Not-4e01> [mineflayer] roblabla 1030d34 - Merge pull request #225 from rom1504/fix_dying Fix dying (fix #224) 12:36 < gurun> ..and tomcc continue to scare the kids with C++ and they keep asking if it is part of 0.11 :-P 13:53 < Not-4e01> [wiki.vg] Edit by Gjum to Entities -> http://wiki.vg/index.php?title=Entities&diff=6526&oldid=6366 16:16 < morfin> gurun what language is used on those server? 16:18 < morfin> syncronization is slow everywhere ) 16:28 < gurun> morfin, C# 16:28 < gurun> i managed to get passed it by instead of trying to sync the access to the queue, i simply replace the queue on every call. 16:30 < gurun> but i'll implement a non-locking add and get to it. Do the work, when no one else is locking it. 16:39 < morfin> i thought you meant another locking 16:40 < gurun> i think we mean the same thing. 16:41 < gurun> just that .NET support non-blocking locking too. 16:41 < morfin> anyway i am trying to implement own "server" just for fun but that seems more complicated that i thought 16:41 < gurun> morfin, it's not complicated really. 16:41 < morfin> basically because i want to utilize maximum of resources i have 16:41 < morfin> so i want to split whole thing to tasks and parallelize those using TBB 16:42 < gurun> well, if you want to implement a server, that's easy. If you want to make sure the server is a really good one, that's a completely different thing. But has very little to do with Minecraft (if you know what i mean) 16:42 < morfin> basically implementing server is not a point 16:42 < morfin> that's more about learning how to write good servers 16:44 < gurun> different servers have different problems (obviously). With minecraft the biggest problem has been packet handling. I had to circumvent all normal object handling in .NET to get the performance needed. 18:13 < gurun> schematics files, is there any point in supporting these? 18:55 < Xor_Boole> gurun in what context? 18:55 < Xor_Boole> they've been a fairly standard format for a while 18:56 < gurun> In the context of a server supporting load of various formats. Anvil being given .. 18:57 < gurun> I've never come across that format before today, so i was a bit surprised. Looks like a fairly good format. 18:57 < Xor_Boole> why would you use a schematic as a map file? 18:57 < Xor_Boole> schematics are for storing arbitrary-sized components 18:57 < Xor_Boole> anvil regions store uniform chunks 18:59 < gurun> have absolutely no idea what the difference would be? 19:01 <+Amaranth> Schematic files are what you use to paste a structure in to a world 19:01 <+Amaranth> Like with WorldEdit 19:03 < gurun> ok, but as a format for say a PVP arena, it could be used. 19:27 <+Amaranth> gurun: That would be weird, they don't store any information about what kind of world they are and such 19:28 <+Amaranth> I mean, you can _assume_ they're normal world and the world and chunk times are all 0 and etc and that'd mostly work out 19:29 <+Amaranth> But it seems like a lot of work to support schematic files as a replacement for world directories just to have them not even work all of the time 19:53 < gurun> well, i guess i can view them as "stuff files" if i look at how MCEdit seems to use them. 19:53 < gurun> just store stuff in it. 19:53 < gurun> like you said, cut and paste kind of format. 19:53 < gurun> but the minecraft wiki kind of implies they are a community developed world format. 19:54 < Xor_Boole> they're not a worlf format 19:54 < Xor_Boole> they're meant to be a file-form of a "clipboard" type construct 20:23 <+Amaranth> iirc they're also kind of out of date and need a breaking change to fix 20:23 <+Amaranth> Well, assuming dynamically assigned id numbers ever happens 20:24 <+Amaranth> Or even just a reorganization of the existing numbers --- Day changed sam. mars 21 2015 00:28 < Aragas> nah. I think sometimes that the best way would be make both client and server, with different packets. Thanks to PluginMessage it isn't so hard. So it will support both vanilla and custom 02:22 < Not-4e01> [wiki.vg] Edit by Pat-g to Server List Ping -> http://wiki.vg/index.php?title=Server_List_Ping&diff=6527&oldid=5867 02:33 < Fenhl> the timestamp is uptime in milliseconds? Can someone confirm this? --- Day changed dim. mars 22 2015 04:36 < Not-4e01> [mineflayer] rom1504 pushed 1 commit to master [+0/-0/±5] http://git.io/hy4d 04:36 < Not-4e01> [mineflayer] rom1504 bc398ea - Fix sleeper * update node-minecraft-protocol with correct bed-related package handling * check the condition for sleeping and return an error in callback if it's not possible * update the api.md about that, update animationEvents (see http://wiki.vg/Protocol#Animation) * update http://wiki.vg/Protocol#Use_Bed package usage 05:06 < rom1504> any clue what exactly should the client send in the update sign lines for the server to accept the change ? 05:08 < rom1504> '{text:"line2"}' doesn't seem to work 05:12 < rom1504> oh right, that can only work after creating a sign 05:14 < rom1504> well I think ? 05:15 < rom1504> http://minecraft.gamepedia.com/Sign#Usage / Text : how does that command work ? 05:48 < Not-4e01> [mineflayer] rom1504 pushed 1 commit to master [+0/-0/±1] http://git.io/hy2g 05:48 < Not-4e01> [mineflayer] rom1504 25aec02 - Fix reading a sign. In graffiti.js * read works * update still isn't really implemented : updateSign must be used after placing a block * a painting is not block or at least not called that in blocks.json 06:06 < rom1504> what's the right packet to dismount ? 06:06 < rom1504> sending use entity again doesn't work... 06:23 < Not-4e01> [mineflayer] rom1504 pushed 1 commit to master [+0/-0/±2] http://git.io/hywS 06:23 < Not-4e01> [mineflayer] rom1504 8cfaba7 - Fix attack and mount. Dismount is still broken. 06:31 < Not-4e01> [mineflayer] rom1504 pushed 1 commit to master [+0/-0/±1] http://git.io/hyrw 06:31 < Not-4e01> [mineflayer] rom1504 4751794 - Fix sprint 08:04 < rom1504> http://wiki.vg/Protocol#Window_Property "Properties: 0, 1 or 2 depending on the “enchantment slot” being given." is wrong 08:05 < rom1504> but what's right 08:05 < rom1504> I'm getting 3 then 4... 09:09 < Not-4e01> [mineflayer] rom1504 pushed 1 commit to master [+0/-0/±1] http://git.io/hy58 09:09 < Not-4e01> [mineflayer] rom1504 0d109a5 - Fix two of the tests and start fixing the remaining one (still need to fix the map chunk format) 15:01 < ensirius> i think i found small problem with window click docs 15:01 < ensirius> http://wiki.vg/Protocol#Click_Window 15:01 < ensirius> middle click works as right click, not left 15:01 < ensirius> big diffrence 16:12 < Wuppie> hi 16:12 < Wuppie> To unload a chunk, i just have to write: 16:12 < Wuppie> X 16:12 < Wuppie> Z 16:12 < Wuppie> GroundUp = true 16:13 < Wuppie> Bitmask = 0 16:13 < Wuppie> right? 16:17 < Wuppie> yes 16:17 < Wuppie> it worked 16:17 < Wuppie> :D 19:02 < Not-4e01> [mineflayer] rom1504 pushed 2 commits to master [+0/-0/±2] http://git.io/hHVl 19:02 < Not-4e01> [mineflayer] Kupferhirn 73dba2b - Update items enum for 1.8 19:02 < Not-4e01> [mineflayer] rom1504 1adbdda - Merge pull request #227 from Kupferhirn/master Update items enum for 1.8 21:16 < Not-4e01> [mineflayer] rom1504 pushed 3 commits to master [+0/-0/±3] http://git.io/hQYr 21:16 < Not-4e01> [mineflayer] Kupferhirn 5231c79 - Update block enum for 1.8 21:16 < Not-4e01> [mineflayer] Kupferhirn d96fd7e - Fix block enum comma 21:16 < Not-4e01> [mineflayer] rom1504 0f84a30 - Merge pull request #230 from Kupferhirn/master Update block enum for 1.8 --- Day changed lun. mars 23 2015 00:30 < Not-4e01> [mineflayer] rom1504 pushed 1 commit to master [+0/-0/±4] http://git.io/hQbO 00:31 < Not-4e01> [mineflayer] rom1504 f4e8051 - Fix the scripts to extract the recipes from the wiki and update the recipes with that. Also put the output file in the arguments of the file instead of printing to stdout. I used merge_recipes.js so recipes aren't changed, just added. blocks.json and items.json aren't fully updated (see #229) so some recipes are probably still missing. 00:48 < Not-4e01> [mineflayer] rom1504 pushed 1 commit to master [+0/-0/±2] http://git.io/hQAw 00:48 < Not-4e01> [mineflayer] rom1504 d670dfc - Fix the recipe output count extractor 01:09 < rom1504> ok anyone know where we can get the wiki source of function(a) { return a.num > 10; 01:10 < rom1504> oh fail 01:10 < rom1504> of http://minecraft.gamepedia.com/Crafting#Complete_recipe_list 01:10 < rom1504> ie how do they edit it ? 01:15 < gurun> looks like ajax 01:15 < gurun> invoke: recipe list | type | Building block 01:15 < gurun> so .. that's a custom thing it seems 01:15 < gurun> you can check the source of each section on http://minecraft.gamepedia.com/index.php?title=Crafting/Building_blocks&action=edit 01:15 < gurun> like that 01:22 < Gjum> rom1504: pay attention to the "Pocket Edition only" notes 01:22 < rom1504> gurun: still doesn't have the content 01:23 < rom1504> #minecraft tells me it has something to do with http://minecraft.gamepedia.com/Module:Recipe_list 01:24 < rom1504> Gjum: oh right, thanks, I didn't see that 01:24 < Gjum> also console ed. 01:25 < Gjum> seems like recipes are not centralized, they are collected from all articles in each category on demand 01:26 < rom1504> yeah ok for console ed 01:26 < Gjum> e.g. the point where it gets readable wiki code is in http://minecraft.gamepedia.com/index.php?title=Bread&action=edit§ion=3 01:26 < rom1504> I think they are somehow collected from the individual pages 01:26 < rom1504> yeah 01:26 < rom1504> just need to figure out if I can use that script (how) 01:27 < Gjum> will mineflayer keep its crafting json format? 01:27 < rom1504> yeah, I'm currently updating it actually 01:28 < rom1504> (look at the commits up there ^) 01:28 < Gjum> nice 01:28 < rom1504> I have a script that extract the recipes from the html 01:28 < rom1504> but I'd better extract them for the wiki source 01:28 < rom1504> *from 01:32 < Gjum> why does the recipe format duplicate the "type"? 01:32 < rom1504> so it doesn't have to build the correct object at runtime I think 01:33 < rom1504> but yeah it would be possible to not have that 01:34 < Gjum> ah I see 01:37 < rom1504> Gjum: we're thinking about several ways to extract the enums https://github.com/andrewrk/mineflayer/issues/229 01:38 < rom1504> the items and blocks have been update manually 01:38 < rom1504> so they're not perfect 01:38 < rom1504> *updated 01:39 < rom1504> I think these enums should maybe be in their own repo, because mineflayer is not the only projet that can use them I think 01:39 < rom1504> it might be better for people from other projets to contribute to them 01:41 < Gjum> that's actually a great idea 01:42 < Gjum> maybe also including example algorithms for several languages on how to use the json 01:48 < Gjum> quick search on github revealed that there are no updated repos for this 01:57 < Gjum> besides cake, are there other recipes with an out-shape? 02:01 < rom1504> I don't know but I don't think so 02:01 < Gjum> recipes.json has none, and I can't think of one 02:02 < rom1504> bin/audit_recipes.js tells me it has one 02:02 < rom1504> oh that's probably cake yeah 02:02 < rom1504> yeah 354 is cake 02:02 < Gjum> yes, but the list is pretty incomplete 02:03 < rom1504> hmm 02:03 < Gjum> no colored wool and such 02:03 < Gjum> well we will see when your brilliant script works it out for us :) 02:04 < Gjum> are the entries of the arrays below the item ID sorted in some way? 02:05 < rom1504> you mean "inShape": [ ? 02:06 < rom1504> I think each array is one column 02:06 < Gjum> no 02:06 < Gjum> e.g. "143": [ starts a list of dicts 02:06 < rom1504> oh 02:06 < rom1504> well one item can have several recipes 02:06 < Gjum> for different recipes/metadata 02:07 < Gjum> yes 02:07 < rom1504> it doesn't have an order afaik 02:07 < Gjum> ok 02:07 < rom1504> what order could it have ? 02:07 < Gjum> metadata? 02:08 < Gjum> e.g. black dye, then orange, etc 02:08 < rom1504> yeah but why black dye before orange ? 02:08 < Gjum> hm but there are different recipes per metadata 02:08 < rom1504> yeah 02:08 < Gjum> because black=0, orange=1 02:08 < Gjum> white=15 02:08 < rom1504> oh ok 02:08 < rom1504> well 02:09 < rom1504> it could have some order 02:09 < rom1504> but I can't see the point of it 02:09 < Gjum> the only point of an order would be easy access, but then a dict of meta -> recipes[] would be the way... 02:09 < Gjum> i think searching these small arrays is enough atm 02:10 < rom1504> yeah 02:10 < rom1504> Gjum: do SpockBot handle the blocks/items/recipes currently ? 02:10 < rom1504> (what data does it use ?) 02:10 < Gjum> I'm building that right now lol 02:11 < Gjum> there was no crafting at all when I started, so I am currently trying to build something compatible to mineflayers json 02:12 < rom1504> right, so using these json files might be useful 02:12 < Gjum> exactly 02:12 < rom1504> I think the point of having a separate repo for these json would be to make it easier to update them 02:12 < Gjum> and in respect to other projects, a central format might be ideal 02:12 < rom1504> because mojang is probably going to make a minecraft 1.9 soon that change everything :p 02:12 < Gjum> soon(tm) 02:13 < Gjum> but yeah, community effort and such 02:13 < rom1504> yeah 02:13 < rom1504> json is supported by most languages 02:13 < Gjum> why not yaml? xD 02:13 < rom1504> and anyway a json parser is very easy to create 02:15 < rom1504> because http://www.yaml.org/spec/1.2/spec.html vs http://json.org/ 02:15 < Gjum> hehe good point 02:16 <+Amaranth> I'm not sure if anyone implements yaml correctly 02:16 < Gjum> what are the reformatX() functions for? they seem to do nothing 02:16 <+Amaranth> I know there are few implementations of the latest version of the spec 02:19 < Gjum> ouch, found a bug in mineflayer :D reipe.js#79 should use shape[y] 02:19 < rom1504> (I created an issue to talk about that there https://github.com/andrewrk/mineflayer/issues/231 , if you have any idea that might make a "enum repo" more easy to use for other projects) 02:20 < rom1504> Gjum: shape[y] why ? it's inShape in the enum 02:21 < rom1504> oh right 02:21 < Gjum> cake would get the wrong delta ^^ 02:22 < rom1504> yeah 02:22 < Gjum> zero actually? 02:22 < rom1504> I never tried to make a cake with mineflayer :D 02:23 < rom1504> Gjum: hmm 02:23 < rom1504> no but Cake has a inShape 02:23 < rom1504> oooh 02:23 < rom1504> I understood inShape and outShape 02:23 < rom1504> ^^ 02:24 < rom1504> well I have no idea if outShape works 02:25 < rom1504> Gjum: http://minecraft.gamepedia.com/Written_Book 02:25 < Gjum> ah 02:26 < Gjum> because you get a copy, there are two outputs 02:26 < Gjum> great find! 02:27 < rom1504> https://github.com/andrewrk/mineflayer/issues/222 02:27 < Gjum> hm mineflayer calculates all datas once, is that better than every time something is crafted? 02:27 < rom1504> I don't think it's significant performance wise 02:28 < rom1504> I don't fully understand inventory.js though 02:28 < rom1504> it's kind of a mess 02:28 < rom1504> but someone it's working 02:28 < rom1504> *somehow 02:28 < Gjum> inventory is really hard to implement clean-room 02:29 < Gjum> bukkit/... can just use minecrafts inventory code 02:29 < rom1504> yeah 02:29 < rom1504> the inventory protocol is not great 02:30 < Gjum> slot updates after clicks like with set block would make it trivial 02:30 < rom1504> yeah 02:30 < rom1504> dealing with clicks is a pain 02:30 < Gjum> but I foud the trick to force the server to send you the full current window, just send a faulty click 02:31 < rom1504> oh really ? that might be useful 02:31 < rom1504> we were trying to do that a while ago 02:32 < rom1504> mineflayer figures it out itself at that point I think 02:32 < Gjum> but you end up with lots of clicks that way, and it is not always possible without side effects 02:33 < Gjum> because the server still executes the click, and sends you the correct result 02:34 < Gjum> but still, for automatic crafting the client has to know any recipes, at least ingredients/shape_in 02:37 < rom1504> yeah 02:38 < rom1504> I think it's amazing the number of languages the minecraft protocol has been implemented in 02:41 < Gjum> yep 02:41 < Gjum> that's why I'm here and tinkering with it 02:43 < Gjum> how would recipes for smooth andesite etc look? i.e. how is metadata represented in inShape? 02:44 < Gjum> also, maybe it would be useful to keep the "Any ..." in some way and not have only id/meta in the shapes 02:45 < rom1504> I think metadata is currently not represented in inShape 02:45 < Gjum> that's a problem 02:46 < rom1504> hmm is it ? should it be represented inShape ? 02:47 < rom1504> can it be infered ? 02:47 < Gjum> how else would you tell the difference of crafting stonebrick and smooth andesite? 02:47 < rom1504> (by knowing the output metadata) 02:47 < Gjum> hm 02:47 < Gjum> explicit > implicit? 02:48 < rom1504> yeah well 02:48 < rom1504> I don't know how metadata is handled in inventory.js 02:48 < rom1504> I certainly didn't test it 02:48 < Gjum> we do not know if it can and will always be inferred 02:48 < rom1504> so yeah there's probably room for improvements there 02:48 < rom1504> yeah 02:50 < rom1504> Gjum: it could be represented the same way it's represented in ingredients I guess 02:50 < rom1504> that would make the whole file more complicated though 02:50 < Gjum> yes 02:51 < Gjum> there could be "shortcuts" though, as [1, ...] for [[1,0], ...] 02:51 < Gjum> where 1 is id and 0 meta 02:51 < Gjum> as often meta is not needed 02:53 < Gjum> I'm going to bed now, maybe I can dream up the perfect solution lol 02:53 < rom1504> it would be possible to have both possibilities in the json too (280 and {"id":17,metadata:1}) 02:54 < rom1504> just need to check which it is when reading the json 02:54 < Gjum> exactly 02:54 < rom1504> yeah I'm going to go too, see you ;) 02:54 < Gjum> ideally consistent with shape, result, ingredients 07:04 < AnimusJer> question about sending packets http://wiki.vg/Protocol#Handshake 07:05 < AnimusJer> would like to maybe use unsafe().sendPacket(send command to console) ?? 07:06 < AnimusJer> meh 07:06 < AnimusJer> good night 10:07 < rom1504> (if anyone knows http://minecraft.gamepedia.com/Talk:Crafting#Wiki_source_of_the_recipes ) 15:11 < Gjum> rom1504: that minetest you linked in the mineflayer chat, they have groups in their recipes, like "group:stone" for cobble, stone, ... Maybe that would be helpful in defining the recipes for minecraft? 15:13 < rom1504> hmm maybe yeah 15:14 < Gjum> for example besides the recipes, have a file with a mapping of negative numbers to groups, that then contain a list of items in that group 15:14 < rom1504> I think I'll think more about that when I start doing a more clean extraction from the wiki (I found some info into how to do it http://minecraft.gamepedia.com/Talk:Crafting#Wiki_source_of_the_recipes https://github.com/andrewrk/mineflayer/issues/229#issuecomment-84913545 ) 15:14 < Gjum> like this https://gist.github.com/Gjum/136188c6152458a7df39 15:15 < Gjum> yeah it would be better to see what data comes out of the wiki extraction script 15:15 < rom1504> Gjum: but then how would you know in the recipe which item from the group you need 15:15 < Gjum> and use some format close to that 15:15 < rom1504> yeah 15:15 < Gjum> it would be any item of these 15:16 < rom1504> Gjum: the problem is the metadata of the output item depends on the metadata of the input item 15:16 < rom1504> and you said we probably can't infer it 15:16 < Gjum> not for items like boats or sticks 15:16 < TkTech> nickelpro: I like the changes, I just want to avoid the scenario where it's copy-pasted into several files 15:16 < rom1504> oh yeah right 15:16 < rom1504> I see your point 15:21 < Gjum> hm, when thinking more about it, the items in these groups would only differ by metadata, right? 15:21 < Gjum> so it would also be possible to write something like "any item with ID 5" in a recipe 15:23 < rom1504> hmm 15:23 < rom1504> yeah 15:23 < Gjum> for example stick:[{inShape:[[5],[5]]}] for any meta of 5, but door.1:[{inShape:[[5.1,5.1],[5.1,5.1],[5.1,5.1]]}] 15:23 < rom1504> how would you encode "any item with ID 5" though ? 15:23 < rom1504> hmm 15:24 < Gjum> i was thinking of not giving any meta, or -1 15:24 < Gjum> but it ony matters when you would also probably have some entry with meta=0, so 5 for any 5 and 5:0 for only meta=0 15:24 < Gjum> not sure how to put that in json 15:25 < rom1504> I think 5.1 is not good 15:25 < Gjum> array? string? float? 15:25 < Gjum> yes 15:25 < rom1504> we shouldn't have to do much parsing after loading the json 15:25 < Gjum> right, but the format has to be able to express all recipes 15:26 < rom1504> probably something like {"id":5,"metadata":1} even if it's a bit verbose 15:26 < rom1504> and just 5 if it's for all metadata 15:26 < Gjum> hm, not sure, it's really verbose 15:26 < rom1504> maybe just [5,1] 15:27 < Gjum> as you only have id and meta when you have anything other than an id 15:27 < rom1504> I don't know 15:27 < Gjum> the thing is, different clients in different languages might prefer a different representation after parsing 15:28 < Gjum> like if mineflayer can directly copy-paste, that does not mean spock can do so too 15:28 < rom1504> ok so 15:28 < rom1504> the thing is https://github.com/andrewrk/mineflayer/blob/c471b5f06fd4a5c8b07bd92e235cf02729bc9dd0/index.js#L26 15:28 < rom1504> mineflayer currently load recipes in one line 15:28 < rom1504> I think it would be a shame to break that 15:29 < rom1504> hmm actually I'm not sure that's true 15:30 < Gjum> nope, there's recipe.js 15:30 < Gjum> you actually build {id:x, meta:x} from [5] 15:30 < rom1504> https://github.com/andrewrk/mineflayer/blob/c471b5f06fd4a5c8b07bd92e235cf02729bc9dd0/lib/recipe.js 15:30 < rom1504> yeah 15:31 < Gjum> yes, reformatShape and ...Ingredients 15:32 < rom1504> yeah 15:32 < Gjum> so, how is the wiki script going? any sample output yet? 15:32 < rom1504> hmm 15:33 < rom1504> I got information from the wiki scripts stuff 15:33 < rom1504> but actually I can't use it 15:33 < rom1504> it just takes stuff from the wiki and generate (ugly) html 15:33 < rom1504> so the idea is getting all the individual item/block pages source wiki 15:33 < Gjum> is the script somewhere so I can try myself? 15:33 < rom1504> and parsing that simple format 15:33 < Gjum> yes 15:34 < rom1504> all the info I found are there http://minecraft.gamepedia.com/Talk:Crafting#Wiki_source_of_the_recipes and there https://github.com/andrewrk/mineflayer/issues/229#issuecomment-84913545 15:35 < rom1504> also in there https://github.com/andrewrk/mineflayer/tree/c471b5f06fd4a5c8b07bd92e235cf02729bc9dd0/bin merge_recipes.js transform1_recipes.js and transform2_recipes.js 15:35 < rom1504> currently generate the recipes from html 15:35 < rom1504> but imperfectly 15:35 < rom1504> also they depend on correct display name on items.json and blocks.json which aren't perfect yet too (manual updating) 15:37 < rom1504> oh someone answers to me on the wiki 15:38 < rom1504> getting to the same conclusions apparently 15:39 < Gjum> maybe the WhatLinksHere is helpful? http://minecraft.gamepedia.com/Special%3aWhatLinksHere/Module%3aCrafting 15:43 < rom1504> indeed 15:44 < rom1504> I don't know if everything links there though 15:44 < Gjum> it should, as these liinks were all auto-generated by using the module 15:44 < rom1504> using the links on http://minecraft.gamepedia.com/Craft might be a way too 15:44 < rom1504> right 15:45 < rom1504> for it to work perfectly it would be nice to be able to also extract the items and blocks from the wiki, but I haven't really looked at how to do that 15:46 < rom1504> in particular the display names 15:46 < Gjum> yep 15:46 < rom1504> well the display name -- id correspondance would be enough 15:47 < rom1504> hmm maybe display name -- (id,metadata) 15:47 < rom1504> Gjum: what do you think about https://github.com/andrewrk/mineflayer/issues/231#issuecomment-84965355 ? 15:48 < Gjum> is there any overview of the grouped items? like "any wood" would have no item/meta 15:48 < rom1504> what would be the good way for a not node.js project to use these enums ? 15:48 < rom1504> (without copy pasting obviously) 15:48 < Gjum> most projects could impoort the json via some json library 15:49 < rom1504> Gjum: look at http://minecraft.gamepedia.com/Module:Grid/Aliases 15:49 < Gjum> so a submodule 15:49 < rom1504> yeah ok 15:49 < Gjum> ooh that's a treasure you found there! 15:52 < Gjum> something I did a while ago, might help a bit for the blocks: 15:52 < Gjum> https://gist.github.com/Gjum/c76bf2e5b0f1d64450e1 15:54 < Gjum> hm, actually I don't remember how I got that, might not be scriptable... 15:55 < rom1504> ok so I'll make a repo when I find some time (and the name of the repo ^^) to put these enums, and the script to generate them. And we can also add some issues to keep progress 15:56 < rom1504> this https://github.com/andrewrk/mineflayer/blob/master/lib/plugins/entities.js#L10 will probably go there too I think 16:09 < rom1504> Gjum: would "minecraft-data" be a good name ? 16:10 < Gjum> anythong that works 16:11 < Gjum> if it's weird at some point, rename and github will redirect... 16:13 < rom1504> https://github.com/andrewrk/mineflayer/issues/231#issuecomment-85042626 16:13 < rom1504> yeah 16:14 < rom1504> but I'd better not rename too many times :p 16:18 < AnimusJer> good morning 20:12 < Gjum> rom1504: documented the current recipe format here: https://github.com/PrismarineJS/minecraft-data/wiki/Recipe-format 20:12 < Gjum> tell me if there's anything to add 20:15 < AnimusJer> hi 21:13 < rom1504> Gjum: looks good, I'll check everything when I have time to actually put stuff on that repo 21:14 < rom1504> I wonder if there is some kind of model thing for json 21:14 < rom1504> like xsd for xml but for json 21:17 < rom1504> http://json-schema.org/ hmm 21:19 < rom1504> https://www.npmjs.com/package/jsonschema 21:19 < Gjum> huh of what use would that be? 21:19 < Gjum> the schema thingie 21:19 < rom1504> checking recipes.json actually respects https://github.com/PrismarineJS/minecraft-data/wiki/Recipe-format 21:19 < rom1504> automatically 21:19 < Gjum> ok i see 21:20 < Gjum> but when we generate it, it should already respect it by default? 21:21 < rom1504> yeah but there may be several extractors, we might forget to update https://github.com/PrismarineJS/minecraft-data/wiki/Recipe-format or an extractor 21:21 < rom1504> that way we can be sure 21:22 < Gjum> ah ok, like as part of tests 21:23 < rom1504> yeah 21:23 < rom1504> and it doesn't seem hard at all to write such a schema so we might as well do it 21:24 < rom1504> oh and btw : ```json does syntax highlighting (``` doesn't) 21:29 < Gjum> I know, but comments are not allowed in json and GitHub's highlighting makes them ugly red 21:29 < rom1504> yeah ```js did it 21:29 < rom1504> (I updated it) 21:31 < Gjum> ah, brilliant :D 22:06 < Gjum> rom1504: do you think it would make the code too complex when the outShape may not be of the same dimensions as inShape? 22:20 < rom1504> Gjum: hmm why would it not be the same dimensions ? 22:21 < Gjum> compactness? e.g. the cake only leaves one row of buckets 22:21 < Gjum> but yeah, it would get confusing when e.g. the center item was left 22:22 < Gjum> wrote something up https://github.com/PrismarineJS/minecraft-data/wiki/Proposed-new-recipe-format --- Day changed mar. mars 24 2015 04:13 < Not-4e01> [mineflayer] thejoshwolfe pushed 1 commit to master [+0/-0/±1] http://git.io/hx76 04:13 < Not-4e01> [mineflayer] thejoshwolfe e7b18fb - writing a proper parser for show_item values. closes #234. sorry, hardtabs. You're already wrong at line 75. I'm not following in those footsteps. SOFTTAB MASTER RACE! 14:51 < Gjum> rom1504: seems to be a bit more up-to-date, but does not have stack size http://minecraft-ids.grahamedgecombe.com/items.json 14:58 < rom1504> Gjum: ok, we could try to (automatically) compare it to what we have and merge it (see related script https://github.com/PrismarineJS/minecraft-data/blob/master/bin/merge_recipes.js ) 15:00 < rom1504> I think some of the issues currently in mineflayer should now be in minecraft-data 15:00 < rom1504> particularly this https://github.com/andrewrk/mineflayer/issues/229 15:01 < rom1504> well I think that's about the only one actually 15:04 < Gjum> 231, 229, 189 15:04 < Gjum> and maybe 222 15:26 < rom1504> yeah 15:26 < rom1504> it's not possible to move issues though, so we'll just write the information of these issues in new issues on minecraft-data if needed 15:41 < rom1504> I think I'll integrate minecraft-data in mineflayer tonight 15:42 < rom1504> it's just a matter of deleting files and changing a few lines in index.js 15:42 < rom1504> (and adding a line in package.json) 18:32 < Not-4e01> [mineflayer] rom1504 pushed 1 commit to master [+0/-13/±8] http://git.io/jvfI 18:32 < Not-4e01> [mineflayer] rom1504 d695193 - Use PrismarineJS/minecraft-data : remove bin/ and lib/enums , use minecraft-data instead in the files involved. Add a line in package.json. Fix #231 18:37 < rom1504> so that's done 20:15 < Gjum> rom1504: I converted the rcipes to the new format, see https://github.com/PrismarineJS/minecraft-data/pull/4 20:59 < Grum> rom1504: seems to be a bit more up-to-date, but does not have stack size http://minecraft-ids.grahamedgecombe.com/items.json <-- also going to be old and broken for 1.9 :) 21:02 < rom1504> yeah but currently items.json has been update manually by Kupferhirn (https://github.com/andrewrk/mineflayer/pull/227) 21:02 < rom1504> so until we have an automatic extractor for items.json , it's better than nothing 21:12 < Gjum> Grum: Any hints on the new internal format so we can prepare? 21:15 < Grum> internal format of? 21:16 < Grum> Gjum? :D 21:16 < Grum> (oh that'll get confusing) 21:16 < Gjum> items and blocks, as how they are handled, because there are rumors of not using the same item/block IDs as before 21:17 < Grum> they are going to be really different 21:17 < _Gjum_> better? 21:17 < Grum> haha no ;) 21:17 < Grum> its ok :) 21:17 < _Gjum_> :D 21:17 < _Gjum_> yes, really different, but in which direction? 21:18 * dx really should try those colored nick scripts 21:19 < Grum> humz 21:19 < Grum> many ideas atm