17:40 < morfin> i am not sure only in one thing: how he nested chest in the chest in the chest ... 17:40 < morfin> could such thing be done without mods? 17:43 < Gjum> morfin: that video is purely about vanilla possibilities 17:44 < morfin> hmm 17:44 < morfin> but how you'll do that 17:44 < morfin> command blocks? 17:45 < morfin> or just thing like MCEdit 17:45 < morfin> put 27 stacks of chests containing 27 stacks of chests containing 27 stacks of chests etc etc 17:45 < morfin> *in 17:57 < Gjum> morfin: like I said and like he shows it in the video: hold CTRL and middle-click the chest in creative 18:03 < kahrl> this is what I was referring to: https://www.youtube.com/watch?v=dBaKirPsGIw 18:04 < kahrl> it's truly infinitely nested, not limited by the NBT depth limit of 512 18:08 < Gjum> ah, great application of loot tables, very cool --- Day changed dim. janv. 31 2016 14:02 < M4GNV5> is there still a repo with up-to-date source of minecraft or should one just use smth like jdgui and decompile it himself? 14:03 < Gjum> M4GNV5: publishing the source code in a repo would violate the terms of use, but you can decompile it for yourself 14:09 < Meeeh> M4GNV5, but use fernflower instead of jd-gui 14:29 < Gjum> Meeeh: any idea why fernflower creates so many unicode snowmen for me? 14:30 < Meeeh> Gjum, you need use flag that will ignore variable name tables 14:30 < Meeeh> then it will name them like var1/var2 etc 14:34 < Gjum> Meeeh: you mean udv=0 ? 14:37 < rom15043> Ah yeah but loot table is a Minecraft saves concept if I understand correctly. So you can't create infinite chests from the game. 14:38 < Meeeh> Gjum, idk, I don't remember :D 14:38 < Gjum> you can in 1.9 with commands I believe 14:38 < Gjum> ok, I'll just try it out then 14:53 < rom15043> Gjum: but then commands are limited to 32 characters 14:53 < rom15043> 32k 14:55 < rom15043> Doesn't the server send the full nbt of an item anyway? 14:55 < Meeeh> rom15043, hyym command block should be able to handle longer string, but you need find other way to add text to it 14:56 < rom15043> Doesn't the server check the limit ? 14:57 < Meeeh> hyym, idk, I never see any other limit than in packets 14:57 < rom15043> I mean, you do understand that if you can create an infinitely nested item, if is something that can be exploited to crash the server and/or other players (from a client) ? 14:58 < rom15043> *it 14:58 < rom15043> Except if it is lazy in some way 14:58 < Meeeh> you CAN crash server/client with NBT 14:59 < rom15043> Wasn't it fixed a while ago ? 14:59 < Meeeh> but it was blocked in one of spigot updates, and possible in 1.9 too, but not fully as far as I know 15:00 < rom15043> Ok 15:00 < Meeeh> I still see some people that say they crash severs with that and user that say that they were crashed, but... they don't trust me enough to allow me check what is that... 15:01 < Meeeh> and don't want install my plugin that just save packets to file :< 15:01 < Meeeh> so I can't confirm anything 15:12 < Gjum> there is no infinite command, yes, but you can use loot tables which generate new items on the fly, so you have theoretical infinity 15:13 < Gjum> which would be lazily evaluated, exactly 15:21 < Gjum> great, -udv=0 worked, thanks Meeeh :) 16:09 < rom15043> Yes that makes sense. Hopefully the server checks that case and doesn't let loot tables actually generate > 512 nbt, or it will crash something 16:10 < rom15043> Ah 16:10 < rom15043> But then I guess the server never send the full nbt representation of chests over the protocol 16:10 < rom15043> So it's probably ok 16:11 < Meeeh> that are only loot tables 16:11 < Meeeh> they should be server side 16:12 < rom15043> It uses the inventory packets to send the content 16:12 < Meeeh> client should only get generated chest 16:12 < Gjum> exactly. the only case where the client gets to see the word loot table is when it gets a placeable chest item with that tag 16:14 < rom15043> Not sure what that means for the size of a region file though 16:14 < Meeeh> Gjum, hyym, isn't this tag contains only loot table name? 16:14 < Meeeh> that is still read from server? 16:14 < rom15043> Could it be used to make infinitely big region files? 16:15 < Meeeh> region size can't be infinitely big 16:15 < Meeeh> there is hard limit 16:15 < rom15043> Yes 16:15 < rom15043> So crash 16:15 < Meeeh> loot tables are saved in separate files 16:15 < Meeeh> and server only use name of them 16:15 < Meeeh> in save files 16:16 < rom15043> Or it just wouldn't save these chests 16:16 < Meeeh> or item nbt 16:16 < Meeeh> etc 16:16 < Meeeh> at leat this is how it should work as far as I know 16:17 < rom15043> Yea but loot table create a real chest, which create a real chest,... The server eventually has to try to save this. Which is not in loot table at that point. 16:19 < Meeeh> then it is normal chest, like it always was, so no new problem, it is possible to create too big NBT data 16:19 < Meeeh> and you can't do anything about that :{ 16:19 < Meeeh> or you can, if you chreate own save system ofc 16:19 < Meeeh> create* 16:21 < rom15043> Ok so that means it's infinite only until you restart the server and the chest info is gone 16:22 < Gjum> no 16:22 < Gjum> the loot table only evaluates into a full chest when it is placed and opened, as long as the chest item with that tah is in some inventory (eg another chest), it is not evaluated (lazy) 16:24 < rom15043> Ah, so you can't place items in that "infinite" chest 16:24 < Gjum> so your region stores tiles: [ { type:chest (already placed and opened), items: [ {type: chest, lootTable: someTable123}, ... ] }, ... ] 16:24 < Gjum> exactly, as only the first 1/2/few are evaluated 16:25 < Gjum> and they even change if you update the server's loot tables 16:25 < rom15043> Yeah OK and "few" is <512 16:26 < rom15043> Ok 19:53 < morfin> hey guys 19:56 < morfin> remember you said you could put NBT in a chest, commands probably can do that even without commandblock but it seems like you have to use syntax {Item:{id:#,Damage:#,Count:#,tag:{Item NBT data here}}} 19:57 < morfin> could such syntax be parsed with regular JSON parser? 19:58 < Gjum> well it is mojangson I believe, so maybe 19:58 < morfin> it seems to be proper JSON expression for me, well it have "objects", "arrays", "numeric", etc 19:59 < morfin> otherwise i will need write own lexer to parse that which is not good idea for me :) 20:00 < morfin> there is lots of non-standard things: 20:00 < morfin> AttributeModifiers:[0:{AttributeName,Name,Amount,Operation} 20:02 < morfin> i think that's bad JSON 20:12 < morfin> lexer to parse that is huge 20:13 < morfin> well, not as huge as YAML parser but big enough(it's called JsonToNBT) 20:14 < Not-b656> [SpockBot] Gjum pushed 18 commits to master [+0/-0/±36] https://github.com/SpockBotMC/SpockBot/compare/8d1e2f7e7f67...dc933843986a 20:14 < Not-b656> [SpockBot] Gjum c7d0e5e - Fix wrong packet name (Entity Look [aA]nd Relative Move) 20:14 < Not-b656> [SpockBot] Gjum 539c9bd - physics bail is debug not warning 20:14 < Not-b656> [SpockBot] Gjum 132c563 - Fix handler docs in world plugin 20:14 < Not-b656> [SpockBot] ... and 15 more commits. 20:33 < M4GNV5> morfin, the mojangjson is not just bad its incorrect, let me give you a small example: create a commandblock with "foo" in it then run /blockdata x y z {"Command":"bar"} and check the commandblock, it will still have the command "foo" its blockdata will now look smth like {Command:"foo","Command":"bar"} 20:33 < M4GNV5> (just a thing to keep in mind when writing your own parser) 20:35 < morfin> wow 20:35 < morfin> why the heck they did not just use plain JSON 20:37 < M4GNV5> well at some parts its understandable for more typings like 42b or 3.14d etc. 20:38 < M4GNV5> also indexed arrays can be usefull when e.g. blockdata'ing the inventory fo a chest so you dont have to write 20 null, for placing an item in slot 21 20:38 < M4GNV5> but parsing correct json incorrectly... meh 20:39 < morfin> ha 20:39 < morfin> you mean [0:{...}, 20: {...}]? 20:39 < morfin> array with holes 20:39 < morfin> yes writing lots of nulls would be crap 20:43 < M4GNV5> im not quite sure but if i recall correctly minecraft uses some google json lib called gson or smth? if your project is written in java maybe you can achieve your stuff using that one too, otherwise i guess checking it out might not a bad idea anyways 20:45 < M4GNV5> https://github.com/google/gson 21:12 < hansihe> basic terrain gen is working https://usercontent.irccloud-cdn.com/file/5adPBBVz/2016-01-31_21.01.19.png 21:53 < Pangea> morfin, https://github.com/rom1504/node-mojangson might help 21:53 < Pangea> there are some other parsers out there I think 22:40 < rom15043> Yeah mojangson definitely isn't json 22:42 < rom15043> But I believe the point is there is a bijection between mojangson and nbt 22:42 < rom15043> Not that it's the only way to encode nbt textually 22:51 < hansihe> in what cases would a server have to parse mojangson? 22:51 < hansihe> well, chat commands i presume 22:56 < rom15043> Yeah chat commands with nbt I think. Probably /summon . I've only used mojangson in the client in hoverevent of chat 22:56 < Gjum> signs can also have mojangson I believe, or is that json? 22:58 < M4GNV5> afaik in the snapshots "chat" things like books, tellraw, signs etc. use strict json 22:59 < Gjum> ah nice 22:59 < rom15043> There's a difference between the "non strict json" that was previously accepted in the chat and mojangson 22:59 < rom15043> The hoverevent in the chat is mojangson in json 23:00 < hansihe> oO 23:00 < Gjum> in a json string right? 23:00 < rom15043> "hoverevent":" some mojangson there" 23:00 < rom15043> Yeah 23:00 < hansihe> right 23:00 < Gjum> ok 23:01 < rom15043> Basically nbt has typed numbers, so you can't just encode nbt in a naive json 23:01 < rom15043> You need to indicate the types somehow 23:02 < rom15043> Or you lose the type information and can't encode it back 23:02 < hansihe> that could be fixed by making the nbt parser take non-lossy conversions though 23:02 < M4GNV5> you could also let the parser try to convert the json number to the given type and throw smth if the number doesnt fit in the type 23:03 < hansihe> idk, the approach seems a bit overkill 23:03 < M4GNV5> i dont know how powerfull java reflection is but it doesnt seem to hard to implement to me 23:03 < rom15043> It's possible to do https://github.com/PrismarineJS/prismarine-nbt/blob/master/sample/bigtest.js instead of mojangson though 23:04 < hansihe> like, if you have a byte nbt tag, and the parser is expecting an integer, just cast the byte to int 23:04 < rom15043> hansihe: that means you need to know the expected schema 23:04 < M4GNV5> rom15043, well thats some workaround cuz js doesnt have typing needed for parsing nbt files 23:04 < rom15043> You don't know that in lot of cases 23:05 < hansihe> rom15043: how is it done in java? 23:05 < hansihe> i would thing you have a compound tag object, you call read on it 23:05 < hansihe> think* 23:05 < hansihe> in that case you could do what i said 23:05 < rom15043> M4GNV5: well that link was basically json ;) 23:06 < rom15043> Which is why I'm saying you need to add some info if you want to encode nbt as json 23:06 < rom15043> Json doesn't have typed numbers 23:06 < rom15043> It only has "number" 23:06 < rom15043> And bool 23:07 < rom15043> hansihe: yes it is possible to encode nbt in types languages sure 23:07 < M4GNV5> true but in minecraft you just serialize a json to a known java type so you could use normal jsons in commands/chat and just cast the types 23:07 < M4GNV5> ofc you cannot display nbt files as normal json 23:07 < rom15043> So in java it's not a problem 23:07 < rom15043> In json it would be though 23:07 < hansihe> my point is, if you made the nbt parser more lenient, you could convert between pure json and nbt, the parser would read it regardless 23:08 < M4GNV5> yeah because you know the schema you convert it to 23:08 < M4GNV5> hansihe, + 23:08 < hansihe> as long as a number is a number, it would work 23:09 < M4GNV5> i guess the only reason why mojang is using gson is because its so super easy to implement. just a fromJson and toJson 23:09 < rom15043> Reading nbt is not the problem, the problem is writing nbt from (untyped) json 23:09 < rom15043> Without knowing the schema 23:09 < hansihe> say we have a nbt tag with an integer 23:10 < hansihe> the integer is 12, its of the type integer 23:10 < hansihe> converted into json, you would lose that type info, you would only know it's a number 23:10 < hansihe> when converting it back into nbt, it would get written as a byte, as it fits into that data type 23:11 < hansihe> when calling readInteger on the nbt parser, it would find a byte, no problem, it would upcast it to integer 23:11 < hansihe> would be safe to do, as long as it only casts upwards to a bigger data type 23:12 < rom15043> "when calling readInteger" except how do you know you need to do that ? 23:13 < hansihe> i don't know how java does nbt parsers 23:13 < jast> there's no problem you can't solve with even more objects 23:14 < hansihe> but if they have a compound tag type object, which would make sense, you would call methods on it when reading values from the tag 23:14 < M4GNV5> rom15043, reflection 23:15 < hansihe> you wouldn't need reflection with the way i was thinking at least 23:16 < hansihe> but yeah, the way jnbt does it, the way i was talking about won't work 23:18 < rom15043> Reflection = more objects = schema 23:19 < rom15043> If you know the schema sure 23:19 < rom15043> Otherwise if you're just trusting the type encoded in the nbt it doesn't work 23:20 < rom15043> But I guess it would be possible to know all the schemas 23:20 < hansihe> you wouldn't need to i think 23:21 < hansihe> you have code for parsing a hypothetical entity nbt tag thing 23:21 < rom15043> Hard coding all the readInt calls is an other way to encode the schema 23:21 < hansihe> yeah 23:21 < hansihe> it would be encoded in the actual code, no need to specify it separately 23:22 < rom15043> Yeah that's one way to do it 23:22 < hansihe> the read methods would just try to do a non lossy conversion from the actual data type to the one you requested 23:22 < hansihe> if it can't it throws 23:23 < hansihe> don't think it would be too different from how it's done today 23:23 < hansihe> things like byte arrays would still be a problem though, might not need to convert that to and from json though 23:24 < rom15043> Well afaik the types are always the same in nbt currently 23:24 < rom15043> They wouldn't be if we just guessed it from json 23:24 < rom15043> Except if you have to guess which nbt writing method to use from the json I guess 23:24 < rom15043> Not sure if that's possible 23:25 < hansihe> you just do the smallest datatype that would fit the value 23:25 < rom15043> Yes, that would work. I'm just saying you'd get a different nbt from what we have currently 23:26 < hansihe> yeah, it would require a change to nbt readers 23:27 < hansihe> i was thinking what mojang could do 23:28 < hansihe> does minecraft pe use nbt? 23:29 < hansihe> seems like it does, at least in the world file 23:31 < rom15043> http://minecraft.gamepedia.com/Pocket_Edition_level_format 23:31 < rom15043> That says is doesn't anymore if I understand right 23:31 < rom15043> *it 23:32 < rom15043> Damn stupid Android completion, can you grammar 23:33 < hansihe> oh, right 23:33 < hansihe> well, i don't think dumping nbt is that bad of a thing --- Log closed lun. févr. 01 06:46:02 2016 --- Log opened lun. févr. 01 06:46:13 2016 06:46 -!- Irssi: #mcdevs: Total of 136 nicks [1 ops, 0 halfops, 16 voices, 119 normal] 06:49 -!- Irssi: Join to #mcdevs was synced in 215 secs 17:47 < Meeeh> NMS support multiple address bindings, it is used anywhere in vanilla? --- Day changed mar. févr. 02 2016 15:35 < hansihe> got biomes working https://usercontent.irccloud-cdn.com/file/XYB8RBHX/2016-02-02_15.35.04.png 15:37 < rom1504> nice! 15:38 < rom1504> do you plan on doing population too ? (and do you want to do it as minecraft does it : 2 steps, or not ?) 15:40 < rom1504> I wanted to do it all in one step, but that requires handling multi-chunk stuff and that's not quite convenient 15:49 < hansihe> how does minecraft do it? 15:49 < hansihe> 2 steps? 15:55 < hansihe> but yeah, i will try to do a fairly complete minecraft world generator 15:57 < rom1504> yes minecraft does it in 2 steps 15:57 < rom1504> it adds trees and dungeons and ... in the second step (called population) 15:58 < rom1504> but trees can be in several chunks 15:58 < rom1504> (putting a tree in the middle of a chunk is not a problem) 15:59 < hansihe> oh yeah, i thought about that 16:00 < hansihe> oh, so minecraft adds the stuff it can add at generation, adds stuff like trees when it has all the chunks needed? 16:00 < hansihe> don't know if i like that 16:01 < hansihe> not sure if you can get away from it easily though 16:03 < rom1504> yeah first it generate all the chunk of some area then add stuff to it 16:03 < rom1504> when someone gets near I think 16:03 < rom1504> if you fly fast enough, you'll see trees appear after the rest 16:03 < hansihe> hmm 16:03 < rom1504> I don't like this too much either 16:04 < hansihe> okey, but solutions 16:04 < hansihe> generate overlap? 16:04 < hansihe> that would be expensive 16:05 < hansihe> it would be possible to generate a rough surface mesh instead of solid blocks 16:05 < hansihe> that would be cheaper 16:05 < rom1504> the other solution we were thinking about was some kind of "cache" : do the "population" in the same time but don't actually set the blocks in the chunks that are not generated yet, store the tree blocks in some kind of queue, and only set them when all the chunks required have been generated 16:06 < hansihe> hmm 16:06 < rom1504> I've been doing other stuff though, and didn't have time to try this 16:07 < rom1504> ( https://github.com/PrismarineJS/prismarine-world/pull/13#issuecomment-148873342 ) 16:07 < rom1504> maybe the way minecraft does it is the correct way though 16:08 < rom1504> I mean, maybe considering that trees appear "after" does make sense 16:08 < rom1504> not sure 16:09 < hansihe> what does minecraft take into account when generating things like trees? 16:09 < hansihe> is it just terrain around the tree and the biome? 16:10 < rom1504> yes I think so 16:10 < hansihe> the way i do generation i could easily make a mesh of the surrounding area fairly cheaply 16:11 < hansihe> this is after cave generation though 16:11 < hansihe> that would complicate it 16:11 < rom1504> maybe their code handle both tree population and tree growth 16:11 < rom1504> I mean the same code 16:11 < hansihe> that makes sense, yeah 16:11 < hansihe> they way minecraft does it is probably the best way actually 16:12 < hansihe> anything else is just really complicated or really expensive 16:12 < rom1504> yeah maybe 16:12 < hansihe> you would have to be careful though, tree growth couldn't be affected by blocks generated by other trees for example 16:13 < rom1504> I'm not sure when population should be triggered though 16:14 < hansihe> if it did, result of the population could be different depending on what direction player triggering the population would approach from 16:14 < rom1504> yeah indeed 16:14 < hansihe> yeah, and in how big chunks should population be done in 16:14 < hansihe> chunk by chunk or area by area 16:15 < rom1504> ah I think I heard that mc does it by 2x2 chunks 16:15 < hansihe> that makes sense 16:15 < hansihe> are dungeons done in population? 16:16 < Meeeh> minecraft is using separate random instance for each chunk, with separate seed 16:17 < hansihe> mineshafts, villages, strongholds, temples, monuments, lava lakes, dungeons 16:17 < hansihe> that's terrain generation 16:17 < hansihe> population is done in a second step 16:17 < hansihe> + ores obviously 16:19 < hansihe> my order of messages made it unclear 16:19 < rom1504> https://github.com/cuberite/cuberite/blob/master/src/Generating/StructGen.cpp#L152 16:19 < hansihe> the two messages in the middle was meant for meeh 16:20 < Meeeh> hansihe, but population also use separate randoms, so trees etc are always in this same place 16:20 < hansihe> yes 16:21 < rom1504> https://github.com/cuberite/cuberite/blob/a7d0abcdc1f62038094f22805b2ffaab860aad08/src/Generating/ComposableGenerator.cpp#L151 : that's interesting 16:21 < rom1504> that's the order cuberite generate things in 16:21 < hansihe> but it is not purely dependent on the output of that rng, it also depends on the terrain around it 16:21 < hansihe> that means you have to look across chunks 16:21 < rom1504> GenFinish is basically "population" it seems 16:22 < rom1504> it looks like my cache idea 16:23 < rom1504> they wait for required chunks to be generated to add trees 16:23 < hansihe> right 16:24 < hansihe> you could do population in quadrants 16:25 < hansihe> do 2x2 chunks together, populate the quadrant of each chunk that faces the other 3 chunks 16:25 < hansihe> that's probably how minecraft does it actually 16:27 < hansihe> well, idk 17:14 < morfin> wait a second hmm 17:14 < morfin> i remember that one chunk was not hardly dependend on another chunks around it 17:16 < morfin> should not world generator be able to generate any chunk separately? 17:18 < hansihe> yeah, the base terrain is generated independently 17:19 < hansihe> when chunks are populated, filled with trees and stuff that is, it seems to look at neighboring chunks 17:19 < morfin> oh 17:20 < Gjum> hansihe: cool, how do you generate overhangs like in that picture? 17:20 < hansihe> generation is from two noise sources 17:21 < hansihe> a basic height map, and a density map 17:21 < hansihe> the heightmap is added to the density map, you get a density in a voxel 17:21 < morfin> is not that result of "Perlin 3d" 17:21 < hansihe> if the density is above a threshold, a block is placed 17:21 < morfin> oh 17:22 < hansihe> i use simplex, but yeah 17:22 < morfin> simplex is nice too i heard 17:22 < hansihe> simplex2d and simplex3d 17:22 < hansihe> i use 16 octaves on the heightmap though, generates nice terrain-ish features 17:22 < morfin> i was thinking about libnoise usage 17:23 < hansihe> my generator is in rust, i'm using noise-rs 17:25 < hansihe> Gjum: i should mention, heightmap is in 2d, density map is 3d 17:27 < Gjum> oh, does that also generate caverns then? 17:27 < hansihe> nah, that's separate 17:28 < hansihe> https://github.com/hansihe/voxel_worldgen/blob/master/src/generators/vanilla/height_field.rs#L119 17:33 < hansihe> keep in mind the terrain gen algorithm itself is not mine, i looked at some terrain generation mods as well as decompiled minecraft to figure it out roughly 17:33 < morfin> caverns are perlin worms 17:33 < hansihe> you sure? 17:33 < morfin> well, i remember even Notch(when he was in charge) said that 17:34 < hansihe> ah, alright 17:34 < morfin> caverns generation is separate 17:34 < hansihe> yeah, cuberite does it differently 17:34 < morfin> oO 17:34 < morfin> better? 17:34 < hansihe> they don't do perlin worms, they set a start and end point for the cave, and mutate the path 17:34 < hansihe> then carve it out 17:35 < morfin> hmmmmmm 17:35 < hansihe> perlin worms are probably easier and just as good though 17:35 < morfin> basically i was digging Minecraft generation algorithm when you could get server map seed 17:36 < morfin> i know generation could change since that times but not that much 17:37 < morfin> and generator generate stuff one-by-one terrain-caves-trees-villages-citadels etc 17:37 < hansihe> yeah 17:38 < morfin> not sure how it do generation now 17:38 < morfin> but i suspect similar way 17:39 * morfin was generating clear unmodified chunk in multiplayer on server protected by Antixray plugin to see truth :) 17:39 < hansihe> now it's biomes-terrain-caves-ravines-mineshafts-etc 17:39 < morfin> hmm 17:40 < morfin> biomes changes terrain generation? 17:40 < hansihe> yep 17:40 < hansihe> biomes have two factors that can affect terrain, height modifier, and variance modifier 17:41 < morfin> oh 17:42 < hansihe> if you look at the picture i posted earlier, that is what is done there as well 17:42 < hansihe> there are two biomes, one with low variance and height, one with high of both 17:42 < hansihe> you can see where it switches 17:48 < morfin> i was thinking about writing own customizable implementation of server 17:48 < morfin> not sur i will ever accomplish that 17:49 < hansihe> that's sorta my goal 17:49 < hansihe> i will never finish it though :p 17:49 < morfin> i wanted Lua full customization 17:50 < morfin> so you can do entities, blocks worldgens without doing C++ ) 17:50 < morfin> is that cuberite you write? 17:50 < hansihe> noo 17:50 < morfin> sadly it's very far from vanilla 17:51 < morfin> does not have a lot of stuff 17:51 < hansihe> yeah 17:51 < hansihe> https://github.com/hansihe/McEx 17:51 < hansihe> that's mine 17:51 < morfin> Elixir ? 17:51 < morfin> wtf is that 17:52 < hansihe> so far it only has chunk generation, block destruction, player movement 17:52 < hansihe> heard of erlang? 17:52 < morfin> yep 17:52 < hansihe> elixir is a ruby-ish language on top of the erlang vm 17:53 < morfin> yes i see 17:53 < morfin> i started learning Ruby at work :) 17:53 < morfin> i see it operates "messages" 17:53 < hansihe> yeah 17:53 < hansihe> erlang is based on processes 17:53 < hansihe> not system processes, erlang vm processes 17:54 < hansihe> you can have millions of them if you need 17:54 < morfin> do you know what's my problem(maybe it's not a problem) 17:54 < hansihe> you would write everything as a process, the processes communicate with messaging 17:54 < morfin> i rely on external libs much : ) 17:54 < hansihe> haha :) 17:55 < morfin> well, i trust them because they were tested for years 17:56 < morfin> as example ASIO(used for event-based programming), it exists like hmm 17:56 < morfin> 5 years i think 17:57 < morfin> C developers use libevent/libev/libuv 17:57 < hansihe> the erlang vm has existed for 30 years :) 17:58 < morfin> lol 17:58 < clonejo_> fun thing is, erlang solves exactly the problem that nodejs tries to solve. but erlang's approach is much better (erlang code while parallel is still written linearly, much easier to reason about). 17:58 < hansihe> yeah 17:58 < clonejo_> so from an erlang point of view, the world is full of poor nodejs hipsters 17:58 < clonejo_> (nothing against hipsters) 17:59 < morfin> node.js code without using promises becomes holyshit ) 17:59 < morfin> because of callbacks 17:59 < morfin> in callbacks 17:59 < hansihe> }}}}}}}}}} 17:59 < morfin> yes that's shit could happen to you :) 17:59 < hansihe> promises makes it better, async/await even better 18:00 < morfin> v8 sadly does not support ECMA 6 as i know 18:00 < hansihe> i still erlangs approach better 18:00 < morfin> async/await? i heard about that hmm 18:00 < hansihe> you can use webpack though, but that's more trouble 18:00 < hansihe> well, async/await is sugar for promises 18:00 < clonejo_> erlang is lacking some features though. like submodules and proper templating/macros. the elixir macros are gorgeous. 18:00 < hansihe> just makes your code more linear 18:01 < hansihe> yeah, i prefer elixir 18:01 < hansihe> erlangs module system is a bit of a clusterfuck 18:01 < clonejo_> hansihe: documentation too 18:02 < clonejo_> or rather naming in the stdlibrary 18:02 < hansihe> oh yea 18:02 < hansihe> definitely 18:02 < hansihe> the fact that the stdlib is old definitely does show 18:02 < morfin> btw do you know what 18:03 < clonejo_> somebody should create replacement modules with a more consistent and obvious naming 18:03 < morfin> i did not know but there is weird hax to compile ES 6 into ES 5 oO 18:03 < hansihe> babel? :P 18:03 < morfin> yes, i remember now it's babel 18:04 < hansihe> i said webpack earlier, i meant babel 18:05 < morfin> not sure it will work with nodejs code(with modules etc) in theory should 18:05 < hansihe> i have used it, works perfectly 18:05 < morfin> but as you said nodejs for hipsters ) 18:06 < hansihe> no i didn't 18:06 < morfin> hmm 18:06 < morfin> i misread then 18:06 < morfin> ah it was not you it was clonejo_ 18:07 < morfin> all that async stuff could be done even with Ruby as well 18:07 < clonejo_> morfin: i did write hipsters, yeah. i let myself go a bit there 18:07 < hansihe> well, it's at least partly true 18:07 < hansihe> :p 18:08 < morfin> returning to Minecraft 18:08 < morfin> i said that was going to use libnoise 18:09 < clonejo_> the advice to programmers (well, actually anybody) should be not to cling to one fancy idea, but to look over her/his horizon and try to reason for him/herself what's sensible and what isn't. 18:09 < morfin> btw 18:09 < morfin> http://libnoise.sourceforge.net/examples/worms/index.html 18:09 < morfin> that's how perlin worms looks like 18:10 < clonejo_> hansihe: there are two design decisions in elixir that needlessly complicate integration of with erlang: 1. wtf do atoms begin with a large letter and 2. why does an elixir module 'Foo.Bar' compile to 'Elixir.Foo.Bar' and not just to foo_bar? These two make interfacing Elixir with Erlang a pain in the ass. My feeling is the Elixir community builds on the Erlang ecosystem, but does not give back to it. 18:10 < morfin> i imagine what if that would be voxelized 18:14 < hansihe> clonejo_: good points. 1. capitalized things are module names, general atoms are written like this: :this_is_an_atom 2. i don't know the design decisions behind that, but it sorta makes sense to do a different separator when introducing a concept of modules and submodules. many erlang modules use underscores as spaces, not as an indicator that something 18:14 < hansihe> contains something else. as for giving back, i know there has been focus lately on integrating a lot of the elixir build tools and the package manager with erlang 18:15 < hansihe> for number one, if you want to call something in an erlang module, you just do :erlang.thing 18:15 < clonejo_> hansihe: yeah, the capitalization is the lesser issue. 18:15 < clonejo_> hansihe: elixir modules could just have been foo.bar 18:16 < hansihe> that's fair, yeah 18:16 < hansihe> but i think the thought behind it is to kinda separate atoms from modules 18:17 < hansihe> i can't really answer any better then that 18:17 < clonejo_> erlang module names are just atoms 18:17 < hansihe> i know 18:17 < hansihe> as are elixir ones 18:17 < clonejo_> jo can even do Module = foo, Module:function() 18:17 < clonejo_> *you 18:20 < hansihe> but as i said, i think the intent is to separate usage of modules from general atom usage in the code. 18:20 < hansihe> but i do agree, it is unnecessary 18:21 < clonejo_> it seems the elixir core developers didn't care about proper integration with the ecosystem. they just wanted ruby syntax and standard library on the erlang vm. 18:22 < hansihe> morfin: yeah, it seems like they don't really connect in the way you would expect a cave system to connect 18:22 < hansihe> clonejo_: possibly, can't really answer that though 18:23 < hansihe> you could ask them over in #elixir 18:23 < hansihe> #elixir-lang that is 18:24 < clonejo_> i might do that one day. or i'll grab jose valim in person when i get the opportunity (that is unlikely though) 18:24 < hansihe> does seem like a nice guy from what i have seen/experienced 18:25 < clonejo_> yup 18:25 < clonejo_> for my part, elixir doesn't add enough to erlang to not just use straight erlang. 18:26 < Gjum> hansihe: are exists_if() and array() sufficient for the whole protocol? 18:27 < Gjum> (looking at packets.ex) 18:27 < hansihe> yeah, if i knew erlang, i might not have bothered with elixir 18:27 < hansihe> Gjum: probably not, will add more stuff if needed though 18:27 < clonejo_> hansihe: and that's the whole problem. the erlang and elixir people both do their own thing. 18:27 < clonejo_> hansihe: btw i have that project idea to implement elixir style macros in erlang (using parse transforms). shouldn't be that much work, just a bit of mindfuck. 18:27 < hansihe> array() and exists_if() both just expand to two function, one for encode and one for decode 18:28 < hansihe> two functions* 18:28 < hansihe> clonejo_: bringing that to erlang would be a really good idea, i feel it's the one major thing elixir has on erlang 18:29 < clonejo_> hm, some easy fame to earn :) 18:30 < clonejo_> my current free time project is slowly coming to an end, might do that next. 18:33 < hansihe> clonejo_: what's your current project? 18:34 < clonejo_> hansihe: a status keeping tool for the local hackerspace (https://github.com/clonejo/clubstatusd) 18:34 < clonejo_> also learning rust while implementing it ;) 18:35 < hansihe> ah, nice :) 18:38 < clonejo_> rust will definitely be my go-to language for a lot of things now. i've had little experience c and c++ before though. 18:39 < hansihe> same with me 18:39 < hansihe> did some things in c before, nothing major 18:39 < hansihe> rust is really pleasant to work in once you get the hang of the special stuff 18:39 < jast> I like C, but it's quite a chore to write things in it 18:39 < hansihe> yeah, exactly 18:40 < hansihe> rust is much better in that regard 18:40 < jast> I mean, of course C is still better than Java :) 18:40 < hansihe> haha, can't say i disagree :) 18:40 < jast> I like rust, too, just haven't really done anything in it yet 18:40 < jast> so it's more of a theoretical like 18:41 < hansihe> i feel like to learn rust you need to decide to do a project in it, and just power through it 18:41 < hansihe> in the beginning it's really annoying 18:41 < jast> that's true for all languages 18:41 < clonejo_> ack, did the same for erlang 18:42 < jast> I guess in rust the borrow concept is a bit tricky at first 18:42 < hansihe> more so in rust then others for me 18:42 < hansihe> yeah, the borrow checker was my main problem at first 18:42 < jast> after christmas I spent some time looking at perl6. I love it... but then I'm weird ;) 18:43 < hansihe> i think my problem was that i didn't know c that well, i imagine you would have to enforce a lot of the things the rust compiler does for you manually 18:43 < jast> or you can not enforce them 18:43 < hansihe> well, yeah :p 18:44 < jast> with certain development practices you need to know a lot about the internal state at any point in time 18:44 < jast> point is, in C you can write things you know are safe that a compiler like rust's would reject 18:44 < jast> so there's less safety but also more flexibility 18:45 < hansihe> you can do that in rust too though 18:45 < hansihe> you just need to opt-out from safety 18:45 < jast> sure 18:45 < clonejo_> in rust i often write lots of .unwrap even though i know it's safe 18:45 < jast> C's view is that safety should never be the default :} 18:46 < hansihe> yup 18:46 < clonejo_> this library does a nice static typing trick: http://hyper.rs/hyper/hyper/server/response/struct.Response.html ( vs. ) 18:47 < clonejo_> both variants are internally identical, it's just used to keep some state and stop you from using the methods that would be inappropriate in that state. 18:47 < hansihe> oh, yeah, phantomdata 18:49 < hansihe> its when you look at stuff like that you realize how handicapped javas type system is 18:49 < clonejo_> rather phantom types: http://rustbyexample.com/generics/phantom.html 18:49 < clonejo_> totally 18:49 < clonejo_> the haskell style enums are also very nice 18:50 < hansihe> yeah, i guess phantom types is the correct word for it 18:51 < clonejo_> you probably want to use both at the same time 21:58 < Meeeh> http://i.imgur.com/thhf9O3.png North Carolina, wat o.O 22:02 <+ammar2> what's does the constructor for WorldSettings use it for 22:11 < kashike> ammar2: seed 22:12 <+ammar2> aah 22:12 < Meeeh> return arrayOfString[((int)(java.lang.System.nanoTime() % arrayOfString.length))]; epic way to get random string from array 22:13 <+ammar2> hah 22:15 < Meeeh> https://hasteb.in/fubuvevayu.java 22:20 <+ammar2> I wonder if that's better or worse than a psuedo RNG 22:20 <+ammar2> that mod over such a small number would more than likely give you uniform distribution 22:21 <+ammar2> plus it wouldn't be predictable 22:21 < Gjum> lol Meeeh where are these lines from 22:22 < Gjum> ah the crash logs right? 22:24 < hansihe> well, for humans it would effectively be a good rng i guess 22:24 < hansihe> you couldn't really get much entropy from it though 22:32 < Meeeh> Gjum, crash and debug command 22:41 <+ammar2> yeah for humans it works great because its modded with such a small number and its only generated once every few minutes 22:41 <+ammar2> but if you tried to generate two consecutive random numbers with it you'd most likely get the same thing 22:42 <+ammar2> since nanoTime isn't likely to be 100% accurate, and even if it was computers are way too fast --- Day changed mer. févr. 03 2016 00:38 < Akaibu> Meeeh: yea, i'm not sure why North Carolina is used, but it is common knowledge that that is the seed for demo mode, it's even on the wiki 00:38 < Akaibu> the offical minecraft wiki i mean 07:31 < morfin> hCraft 2 developer gave up 16:52 <+SinZ> hCraft, thats a name I haven't heard in ages 16:59 < morfin> there was hCraft 2 16:59 < morfin> also 16:59 < morfin> but seems like author did not commit in it like 9 month 17:20 < Gjum> hcraft 2 isnt even haskell anymore 17:25 < rom1504> https://github.com/oldmanmike/opensandbox is the most recent haskell server 17:49 < hansihe> surprisingly few custom servers have gotten past things like player movement 18:28 < rom1504> really ? 18:29 < rom1504> there are quite a lot of servers there http://wiki.vg/Server_List 18:29 < rom1504> I mean except if by few you mean "~10" 23:46 < Meeeh> someone just asked me if my server will have more fps than vanilla.... fps, server, ugh. 23:47 < redstonehelper> tell him fps are a paid DLC --- Day changed jeu. févr. 04 2016 00:20 <+ammar2> donate 10 dollars for improved fps! 00:21 <+ammar2> also theoretically you can up FPS from the server side 00:21 <+ammar2> if you just send the client less block information 00:21 <+ammar2> lose seeing the world for more fps = worth 00:40 < Gjum> nah, kick on join for maximal fps! 01:27 <+Thinkofname> Gjum: the main menu has something like a 30 fps cap. It would actually reduce fps by kicking for a large number of users :) 01:28 < Gjum> oh does it? that's useful 05:05 < morfin> hello 05:05 < morfin> how client knows which model it should draw? 05:06 < morfin> for mobs as example: from NBT? --- Log closed jeu. févr. 04 05:121:13 < Monkey0x9> Hey, does anynone know how long this URL is being fased out? http://s3.amazonaws.com/Minecraft.Download/versions/versions.json 22:15 < Not-84da> [Miners] Wallbraker pushed 1 commit to wip-d2-port [+0/-0/±67] https://github.com/Charged/Miners/compare/59f5a8085905...fb574bcca0e5 22:15 < Not-84da> [Miners] Wallbraker fb574bc - charge: More porting 22:41 < rom1504> Monkey0x9: "fased out" ? 22:50 < nickelpro> s/fased/phased/g 22:55 < rom1504> still not understanding 23:18 < Gjum> rom1504: when you access that url it says "This URL is being phased out! Please update your scripts [...]" 23:44 < TobiX> Monkey0x9: Maybe ask Dinnerbone? 23:45 < TobiX> Monkey0x9: But why do you need to know? Just update your tools and be done with it... 23:50 < hansihe> cave generator working mostly as intended https://usercontent.irccloud-cdn.com/file/ob7rNJMi/2016-02-04_23.48.37.png 23:50 < Gjum> close enough 23:51 < TobiX> "cave" --- Day changed ven. févr. 05 2016 02:12 < hansihe> works now, the problem was that i wasn't mixing the seeds for the rng properly 02:12 < Gjum> pics or gtfo 02:12 < Gjum> ;) 02:13 < hansihe> https://usercontent.irccloud-cdn.com/file/PbrUeueT/2016-02-05_02.10.58.png 02:13 < hansihe> https://usercontent.irccloud-cdn.com/file/XHcZEENq/2016-02-05_02.13.32.png 02:13 < hansihe> well, it's cave generation 02:14 < hansihe> doesn't look that impressive 02:14 < Gjum> any plans for ores yet? 02:14 < hansihe> not implemented yet 02:14 < hansihe> definitely plans for it 02:14 < hansihe> should be one of the easier parts 02:16 < Akaibu> ... 02:17 < hansihe> huh? 02:19 < Akaibu> i want to make a mc dungeon brute force checker(mainly in browser/js, since i don't know anything else atm), i know "how" they gen, i just need an condensed but accurate version of the algorithm 02:19 < Akaibu> anyone mind scoping up the code for me? 02:20 < Gjum> you could check out amidst 02:20 < Akaibu> doesn't do it 02:20 < Akaibu> made an issue for it though: https://github.com/toolbox4minecraft/amidst/issues/57 02:20 < hansihe> haven't done dungeons yet, haven't reverse engineered that algorithm 02:21 < Gjum> oh ok 02:21 < Akaibu> hansihe: you doing a clean room version of cave gen? 02:22 < Gjum> I thought you meant the end portals 02:22 < Gjum> yep 02:22 < hansihe> wouldn't be clean room 02:22 < hansihe> i am making sure i don't copy code however 02:22 < hansihe> i first figure out how the algorithms work, then reimplement them 02:23 < hansihe> that a legal way to work in my country at least 02:23 < Akaibu> what country you live in? 02:23 < hansihe> norway 02:23 < Akaibu> ah 02:23 < Akaibu> isn't that right next to Sweden? 02:23 < hansihe> should be the same for most of eu though 02:23 < hansihe> close :) 02:26 < Gjum> so clean room would be if you made it generate exactly like vanilla, but without copying code? 02:26 < hansihe> clean room would be one team reverse engineering, then writing a spec on the algorithm 02:27 < hansihe> other team that never sees the original program reimplements it 02:27 < hansihe> from the spec alone 02:27 < Gjum> ah 02:27 < hansihe> it's what the truecraft guys are doing 02:27 < Akaibu> hansihe: i think that definition is kinda cheating 02:27 < Akaibu> wait, really? 02:27 < hansihe> yeah 02:27 < Gjum> that makes sense now, didnt for the longest time 02:28 < hansihe> that's the method used by computer companies to make ibm knockoffs, it has legal precident 02:29 < hansihe> well, just looked at the dungeon spawning code, it's not complicated by itself 02:29 < Akaibu> yea, but i'm kinda shit at actually understanding java code 02:29 < Akaibu> i mean, i can get it at some level 02:30 < hansihe> but it looks at the terrain that has been generated 02:30 < hansihe> so you would need a terrain generator as well 02:30 < Akaibu> yea 02:31 < Akaibu> maybe someone here would maybe instead want to make a plugin to do that for zipkrowd.com/tools.htm instead of me making some cringy hack of js code 02:32 < hansihe> that would probably be easier 02:32 < Gjum> I remember someone from the zip krowd using a mod for displaying potential dungeon spawning positions 02:33 < hansihe> potential positions is easy 02:33 < Akaibu> yea, thats the same guy Gjum, but this is kinda like a brute forcer 02:33 < hansihe> most of them are not spawned in though, the terrain in the location is checked 02:34 < Akaibu> and Gjum, its wasn't potential dungeon spawning positions it was displaying, it was the locations that the terain generation checks to place dungeons 02:35 < Gjum> yeah thats what I meant 02:36 < Gjum> but even if you do world gen and check against that, it's still just an approximation as the world can be changed by players before the dungeons get spawned in 02:36 < hansihe> could it? 02:37 < hansihe> isn't the world populated before the player gets close enough? 02:37 < Akaibu> and maybe have the plugin check for areas that can be loaded by a player up to 72 spawers( https://www.youtube.com/watch?v=oQ_VqZcfN74 is the proof for the limit) 02:38 < Akaibu> Gjum: yea, so we could put a check for "are you going to try and use a krobra to generate this, or do you just want a natural generation?" 02:39 < Akaibu> hansihe: yes, but again, this kinda thing is possible due as seen with: 02:39 < Akaibu> shit, one secodn 02:39 < Gjum> hehe 02:40 < Gjum> if I just knew which video explains it best :) 02:41 < Gjum> there are so many already building on that concept, but none really explaining it in a compact way 02:41 < Akaibu> https://www.youtube.com/watch?v=9iaU1TvIQqM 02:45 < Akaibu> i wish that the 1.9 update would come out already, i know thats whats causing delay with zipkrowd, there is litterly almost nothing they can do atm new 05:58 < oldmanmike> Does the Map Chunk Bulk packet still exist for the current snapshots? 05:59 < oldmanmike> The wiki lists Map Chunk (0x21) and Map Chunk Bulk (0x26), the protocol according to minecraft-data seems to only have Map Chunk now as 0x20 06:16 < Fenhl> oldmanmike: where does the wiki list that? It's not in the snapshots anymore 06:18 < Fenhl> for the record, the relevant documentation is at http://wiki.vg/Pre-release_protocol#Map_Chunk_Bulk 06:19 < oldmanmike> I'll post the link 06:20 < oldmanmike> And yeah, there's a "see also, some stuff has changed in 1.9" post-it there too 06:20 < oldmanmike> http://wiki.vg/SMP_Map_Format 06:22 < oldmanmike> Fenhl: Wow, cool. I didn't know there was a current page for the protocol 06:23 < oldmanmike> Never bothered to click that *other* link on the front page 06:23 < Fenhl> usually, the wiki documents the current stable release (1.8.9), snapshot is only documented on that single article 06:24 < oldmanmike> gotcha 08:20 < Not-84da> [Miners] Wallbraker pushed 1 commit to master [+0/-0/±1] https://github.com/Charged/Miners/compare/442b55898c31...b19662f8a1f9 08:20 < Not-84da> [Miners] Wallbraker b19662f - mc: Fix build on 64 bit 08:22 <+Wallbraker> tktech: Heh, Esper does not like notifico 08:24 < Not-84da> [Miners] Wallbraker pushed 1 commit to master [+0/-0/±1] https://github.com/Charged/Miners/compare/b19662f8a1f9...4542f1e02bcd 08:24 < Not-84da> [Miners] Wallbraker 4542f1e - mc: Fix build on 64 bit 08:54 <+ammar2> charged miners? that's a name I haven't heard in a long time 09:08 < rom1504> what's nice about classic is client/server for it don't get outdated 09:09 <+Wallbraker> Indeed 12:51 < hansihe> the same thing almost applies to 1.8 servers 12:53 < rom1504> well yeah but people don't play 1.8, they play modern 12:54 < rom1504> which is going to be 1.9 soon™ and break all custom servers 12:54 <+Fador> it took couple of weeks to port my 1.5 server to 1.8 =/ 12:56 < hansihe> what I meant is 1.9 has been in the soon stage for a very long time now 12:59 < rom1504> sure 12:59 < rom1504> but I mean, once it's out, your server is kind of outdated if it only supports 1.8 13:01 < hansihe> yeah 13:02 < hansihe> I did sound like a total dick, I expressed myself really badly 13:02 < hansihe> was meant as a joke about minecraft being slow on updates lately 13:04 <+Fador> I miss the days when accessing chest inventory was done in NBT chunks.. =b 18:41 < morfin> is there anywhere description of NBT pseudo-JSON format(as EBNF or something like that)? 18:43 < rom1504> there's https://github.com/rom1504/node-mojangson/blob/master/grammar.jison 18:43 < rom1504> it's not ebnf though 18:43 < morfin> seems not very supercomplicated 18:44 < rom1504> no it's not very complicated 18:44 < rom1504> but it does require its own parser 18:44 < morfin> yes of course 18:45 < morfin> because of array with hols 18:45 < morfin> *holes 18:45 < morfin> and other stuff 18:46 < morfin> btw does array having [0:{},20:{}] assume that when i parse it will fill 1,2,3,4,..,19 with null or something? 18:48 < rom1504> yeah something like that 18:49 < morfin> oh 18:50 < rom1504> it doesn't matter too much how you handle that case though since I don't think that's a value that's actually send by the server 18:50 < rom1504> *sent 18:50 < rom1504> but filling it with null works 18:51 < rom1504> it gets filled with undefined automatically in js 18:51 < rom1504> but well you don't have undefined in other languages 18:51 < rom1504> so just pick something that makes some sense 18:56 < morfin> what is that syntax btw 18:57 < morfin> i mean that link you gave 18:58 < rom1504> it's a yacc-like syntax 18:58 < rom1504> to express a grammar 18:59 < morfin> oh yacc 18:59 < morfin> i knew i saw that syntax before somewhere 22:51 < hansihe> writing stuff in a low level language compared to java is very nice 22:51 < hansihe> especially hot code 22:51 < hansihe> you can actually use the features of the language for abstraction without performance going off a cliff --- Day changed sam. févr. 06 2016 04:10 < ma3str0> anyone have any advice on custom item rendering? 04:11 < pokechu22> I think wiki.vg is down right now... 04:12 < pokechu22> Scheduled maintainence or is something broken? 04:50 < pokechu22> It seems like wiki.vg is still down. 04:57 < oldmanmike> :( 05:06 < pokechu22> Ooh! "500 - Internal Server Error". So something's back on, at least. ... though it's still broken. 05:21 < oldmanmike> Gotta love dem cache pages 05:32 < oldmanmike> Knock Knock Knockin' an Apache's door 07:16 < morfin> you can do even C++ and still get nice perfomance 07:17 < Fenhl> btw, do we have backups of the wiki? 07:39 <+XorBoole> is wiki.vg kill? 07:39 <+XorBoole> I picked with a stick, and it just stared back at me 09:06 < ma3str0> lol 09:08 < morfin> oh crap 09:08 < morfin> wiki.vg died 09:10 < rom15043> tktech what's going on with wiki.vg ? 09:11 < rom15043> Good idea about having backups... 09:11 < Fenhl> I hope it's not too late 09:12 < Fenhl> I asked this once already but tktech tends to not respond to my messages 09:13 < rom15043> I don't know mediawiki that much but it is possible to do a dump of the wiki I think 09:14 < morfin> haha error 500 09:14 < morfin> nobody had backups i guess 09:14 < morfin> basically wiki.vg is not that big i think 09:15 < morfin> so dumping it should not be pretty hard 09:19 < rom15043> Can't really do a backup from the outside. Except by scrapping the source of every revision of every page but that's not quite convenient 09:30 < morfin> well it's not but only way 09:37 < rom15043> Probably not. It's probably coming back 09:40 < rom15043> Well there's that http://superuser.com/a/387715 09:50 < morfin> i suspected there is already existing solution 11:50 < Meeeh> nah, 1.8 outdated... tell that to people in my country, 90% of servers are still on 1.7 + 1.8 11:50 < Meeeh> that spigot/paperspigot with protocolhack with all that bugs, ways to crash servers etc. 11:55 < rom15043> It's not outdated until 1.9 is out 11:58 < Meeeh> 1.7 is not outdated? 12:15 < rom15043> It is 12:16 < rom15043> I meant 1.8 won't be outdated until 1.9 is released 12:26 < Meeeh> 1.7+1.8 it is just 1.7 12:27 < Meeeh> with support for 1.8 clients that still can only use 1.7 stuff + more bugs, issues and problems. 12:31 < rom15043> Ah 12:31 < rom15043> Well servers in your country are outdated then 12:31 < rom15043> Here you go : p 12:32 < rom15043> Well I see your point, outdated servers can still be useful 12:33 < rom15043> I think a nice way to do it is multiple version support but it's kind of annoying for high level features 12:33 < rom15043> (If possible at all) 15:27 < morfin> why? 15:27 < morfin> i mean why they can be useful? 15:56 < Gjum> well google did some kind of backup for us yesterday https://webcache.googleusercontent.com/search?q=cache:jmD47cvBQtIJ:wiki.vg/Protocol+&cd=1&hl=en&ct=clnk&gl=us 16:03 < hansihe> is everyone preparing for the worst? 16:06 < barneygale_> what's happened? 16:07 < Gjum> wiki.vg is offline kinda 16:08 < edk> the last time this happened everyone got worried and then it came back the next day 17:30 < dood> http://wiki.vg/ isn't working 17:32 < hansihe> yep, it's offline at the moment 19:05 < morfin> hmmm 19:05 < morfin> i am reading about restone things like comparator - does it lookup blocks around to do stuff? 19:07 < morfin> it seems to be working with different block types(even with enderportal frame) 19:18 < Gjum> morfin: I believe when a block like a chest that influences a comparator gets updated, it looks for comparators in the possible positions and schedules them in the tile queue 19:19 < Gjum> at least that's what I understood from several videos about zerotick behaviour 19:20 < Gjum> keep in mind that item frames (entities) also influence comparators 19:35 < hansihe> chest open/close doesn't cause a block update, right? 19:48 < Gjum> hansihe: it does for trapped chests at least 19:49 < Gjum> well, maybe not block update, but it influences comparators and redstone 19:49 < hansihe> yeah, that would make sense since it updates redstone 19:50 < redstonehelper> I'm not sure open/close actually updates comparators 19:50 < Gjum> it updates redstone two blocks below it, so that's not really a block update 19:51 < Gjum> redstonehelper: comparators on trapped chests measure how many players are looking into it 19:51 < redstonehelper> ohhh yes 21:33 < morfin> oO 21:34 < morfin> so it's not comparator looking up what's around but block looks up for comparator 21:35 < hansihe> it would make sense if it's sorta like a second block update system 21:36 < morfin> i am just wondering how redstone works under hood 21:38 < Gjum> morfin: keep in mind taht I haven't looked at the actual code, just at the behaviour --- Day changed dim. févr. 07 2016 02:10 < ma3str0> woo got my custom renderer working... more or less 02:10 * ma3str0 is a newb at this 02:13 < hansihe> nice 02:13 < hansihe> what is it written in? 02:13 < ma3str0> java 02:13 < ma3str0> isn't that the only thing you can use with minecraft? 02:13 < ma3str0> (again, newb) 02:13 < hansihe> well, minecraft is written in java 02:14 < hansihe> but you can implement the stuff minecraft does in any language 02:14 <+Amaranth> I think ma3str0 is talking about rendering a custom block/entity as a mod to the real game 02:14 < hansihe> oh, right 02:14 < ma3str0> ^ 02:14 < ma3str0> what Amaranth said 02:14 < hansihe> i misunderstood you then, sorry :) 02:14 < ma3str0> ha, no worries, i didn't say it right 02:14 <+Amaranth> This is mostly a channel for people making tools and custom client/server implementations 02:14 < ma3str0> oh 02:14 <+Amaranth> Not much modding talk in here :) 02:15 < ma3str0> my fault 02:15 < ma3str0> i'll lurk a while anyway 02:15 <+Amaranth> No worries, not much any talk here in most of the time :D 02:15 < ma3str0> lol 02:15 < Meeeh> there isn't anything like ConcurrentIntObject map in java? (I mean some library) 02:16 <+Amaranth> Nah, the good concurrent maps don't mix so well with primitives 02:17 <+Amaranth> You could probably do one like Java's though, it's just 16 maps internally with a separate lock for each one 02:18 < Meeeh> Amaranth, isn't it using Unsafe? 02:19 <+Amaranth> I mean, it might use a little for performance but the concept is just sharding and locks 02:20 <+Amaranth> https://github.com/boundary/high-scale-lib/blob/master/src/main/java/org/cliffc/high_scale_lib/NonBlockingHashMap.java is a little more complicated though :) 02:21 < Meeeh> Amaranth, I mean that they edited ConcurrentHashMap some time ago 02:21 < Meeeh> and it don't use concurrencyLevel anymore 02:21 < Meeeh> so it don't create 16 maps by default 02:22 < Meeeh> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/java/util/concurrent/ConcurrentHashMap.java?av=f#893 02:22 < Meeeh> look, it isn't even used :P 02:22 < Meeeh> they reimplemented whole class 02:22 <+Amaranth> I was just trying to load that up, guess they changed it in java 8 then 02:23 < Meeeh> yeach, I think it was java 8 02:23 < Meeeh> https://github.com/JetBrains/intellij-community/blob/master/platform/util/src/com/intellij/util/containers/ConcurrentIntObjectHashMap.java 02:23 < Meeeh> oh, intellij have that xD 02:24 < Meeeh> but sadly only for ints 03:21 < pokechu22> As a mod developer, is there any way for me to use hopper.minecraft.net to look for crash report relating to my mod? 03:24 < oldmanmike> yay, it's up! 03:25 < hansihe> \o/ 03:27 <+ammar2> yeah I wouldn't worry too much if it goes down for like a day or so, tktech is quite busy these days 03:28 <+ammar2> and he is a competent sysadmin so he probably has backups and stuff 03:28 < hansihe> yeah, was not too worried 03:30 < pokechu22> I grabbed a snapshot of it using Special:Export just now, just in case. Over 200 megabytes... 03:32 <+ammar2> interesting, what's making up the bulk of that? 03:33 < pokechu22> The fact that I exported the revision history and images, probably. 03:33 <+ammar2> aah yeah version history would do that 03:34 <+ammar2> we actually lost version history when tk migrated the wiki to a new setup 03:34 <+ammar2> but that was a few years ago 05:03 < Gjum> when mining blocks or clicking entities, is the reaching distance calculated from the player position (feet) or the eyes? any idea where that code is? 05:08 <+ammar2> Gjum: don't quote me on this but for mining blocks at least I remember the server calculated distance between eyes to block 05:09 <+ammar2> not sure about clicking entities but its likely the same 05:09 < pokechu22> IIRC it's eyes; let me check 05:09 < pokechu22> It's something like world.rayTraceBlocks. I had to use it recently for a camera thing... 05:10 <+ammar2> on the server side it was something like distance between eyes and center of block 05:10 <+ammar2> but yeah I'd imagine on the client it's different and based on where the camera is 05:10 <+ammar2> not sure if you're interesting in server or client side code 05:11 < Gjum> server, because I write on a client ;) 05:15 < pokechu22> Looks like the client uses the head position, at least... from Entity.func_174822_a (1.8) 05:15 < Gjum> btw how do people get these nice names, world.rayTraceBlocks etc? fernflower alone is so dull and confusing 05:18 < pokechu22> MCP (http://www.modcoderpack.com/website/releases). It renames most things at decompilation and then can recompile back to the original names. 05:18 < pokechu22> Though it doesn't have everything named (hence Entity.func_174822_a). But even those names stay the same between versions, and are all unique rather than having 20 methods named 'a'. 05:20 < Gjum> I hoped there was another way, because the mcp guys tend to take a long time to release after new versions, but they also update the mcp api etc which isnt what I need 05:20 < Gjum> do they release just the mappings somewhere? 05:21 < pokechu22> If you just decompile to SRG names (which are things like func_174822_a) it remains mostly constant. 05:21 < pokechu22> And yep, the mappings can be found in the 'conf' folder or at http://export.mcpbot.bspk.rs/ (and the ones there are usually more up to date) 05:24 < pokechu22> Looks like the server uses a square distance of 36 from 1.5 above the player's feet, but the normal eye height is at 1.62 on the client. 05:25 < pokechu22> https://gist.github.com/Pokechu22/a3eda8605b7f3e9e8a57 05:26 < Gjum> oh, that mappings page is great, thanks a lot! 05:28 < Gjum> interesting, why would they use a different value there 05:28 <+ammar2> probably no particular reason, it's a good enough approximation 05:29 <+ammar2> whoever originally wrote that code was probably like, "what's the fastest way to get the eye height" 05:30 < Gjum> that explains why sometimes you can reach a block but the server doesnt accept your interaction 05:30 < pokechu22> If I remember correctly the names in the MCP csv files there are based off of SRG names, not the default obfuscated names. Though fernflower might change them. You'll have to look at the combined.srg file in the MCP configuration to convert to SRG names before the MCPbot mappings will be too useful :/ 05:34 < pokechu22> That's odd... place block seems to use different logic. 05:36 < Gjum> what does srg stand for? 05:37 < pokechu22> I'm not entirely sure to be honest. I think it's searge? Named after one of the forge developers? 05:43 <+ammar2> yeah its a mapping format created by searge 05:46 < pokechu22> OK, something's pretty weird: _placing_ blocks measures from the feet as far as I can tell, and has a distance of 8. https://gist.github.com/Pokechu22/9a56e3f85faaa8573809 05:47 < Gjum> I heard in creative you can reach further than in survival 05:51 < pokechu22> You might be right... 05:51 < pokechu22> I think I saw something like that. 05:52 < pokechu22> Indeed. 05:53 < pokechu22> In net.minecraft.client.multiplayer.PlayerController: public float getBlockReachDistance() { return this.currentGameType.isCreative() ? 5.0F : 4.5F; } 05:56 < pokechu22> Hm, https://bugs.mojang.com/browse/MC-92484 might relate to that too. 09:21 < Fenhl> Gjum: comparators on trapped chests only measure fill level. “How many people have the inventory open” is the regular (non-comparator) redstone signal 09:21 < morfin> so 09:22 < morfin> if i open it it send signal with power 1 but comparator sends signal depending on fill level 09:22 < Fenhl> yes 09:23 < Fenhl> comparators don't get activated by opening trapped chests, even empty ones 09:40 < morfin> heh 09:40 < morfin> seems like wiki.vg is alive 09:40 < morfin> for now.. 09:53 < ecx86> . 13:30 < Not-84da> [Charge] Wallbraker pushed 3 commits to master [+0/-0/±8] https://github.com/VoltLang/Charge/compare/20eb73c4e015...192009576d3f 13:30 < Not-84da> [Charge] Wallbraker 49294a7 - charge: Fix Makefile 13:30 < Not-84da> [Charge] Wallbraker d8f5803 - charge: Whitespace and remove unneeded returns 13:30 < Not-84da> [Charge] Wallbraker 1920095 - charge: Update ignore 15:48 < hansihe> rom1504: would blocks.json be the right place for light values? 16:02 < morfin> hmm 16:03 < morfin> i think i should look at original sources to understand some stuff 16:27 < Meeeh> weird https://scr.hu/32v8/53qaf 16:28 < rom1504> hansihe: what kind of light values ? 16:30 < rom1504> http://minecraft.gamepedia.com/Light this ? 16:31 < rom1504> if so then yeah I think so 16:31 < morfin> whatis that? 16:32 < morfin> are not light values just nibble with values 0-15 16:33 < hansihe> it's the amount the block emits light 16:33 < rom1504> well maybe we should put it in its own file, a blocks_light.json or something since blocks has already lot of stuff (separating that kind of info in a new file make it easier to extract it automatically and it's anyway possible to link it to the blocks data with ids) 16:33 < hansihe> also, the value a block absorbs light should probably be in there 16:34 < morfin> hmm 16:34 < morfin> there is also skylights 16:34 < morfin> as i know 16:34 < hansihe> rom1504: idk, it would fit well in blocks.json 16:34 < rom1504> morfin: that's dynamically computed by the client/server, it's a different thing from what hansihe is talking about 16:35 < hansihe> seems silly to put it in another file just cause 16:35 < morfin> basically now i can't even imagine how some stuff works in Minecraft 16:35 < hansihe> it's not *that* complicated 16:35 < morfin> things like redsone with all that rules 16:35 < morfin> for different block types 16:36 < rom1504> blocks.json is currently automatically extracted hansihe 16:36 < morfin> i assume proper implementation of redstone should work like on vanilla 16:36 < hansihe> oh, right 16:36 < hansihe> yeah, then i understand the rationale behind a separate file 16:37 < rom1504> the extractor is already pretty fat https://github.com/PrismarineJS/minecraft-wiki-extractor/blob/master/lib/block_extractor.js and I'd prefer avoiding to add even more stuff to it 16:37 < rom1504> (even if that's possible indeed) 16:39 < rom1504> especially is that data http://minecraft.gamepedia.com/Light#Effects_of_light is relevant 16:39 < rom1504> it links blocks and entities 16:40 < rom1504> anyway, yeah that data can be put in mcdata ;) 16:43 < morfin> wow i did not know bats spawns so high(at 62) 16:43 < hansihe> yep, i needed the data for lighting calculations, didn't want to hardcode it :) 16:44 < rom1504> https://github.com/PrismarineJS/minecraft-data/issues/96 16:45 < hansihe> yep, sounds good! 16:45 < morfin> btw spiders as i know are not hostile only under daylight 16:45 < hansihe> i could have a go at writing it, right now i think the cost of writing an extractor for it outweigh the benifit 16:51 < hansihe> imo minecraft wiki has it backwards, the wiki page should be generated from the data representation, not the other way around 16:51 < hansihe> i guess it's the same way with the wiki.vg protocol page 16:53 < Not-84da> [Charge] Wallbraker pushed 2 commits to master [+7/-0/±3] https://github.com/VoltLang/Charge/compare/192009576d3f...25a042624dd6 16:53 < Not-84da> [Charge] Wallbraker 3034606 - charge: Add sources.mk 16:53 < Not-84da> [Charge] Wallbraker 25a0426 - ctl: Copy over from Charge 17:00 < Not-84da> [Charge] Wallbraker pushed 2 commits to master [+7/-0/±3] https://github.com/VoltLang/Charge/compare/25a042624dd6...601a4a760cf5 17:00 < Not-84da> [Charge] Wallbraker 8693f3c - charge: Add sources.mk 17:00 < Not-84da> [Charge] Wallbraker 601a4a7 - ctl: Copy over from Charge 17:01 < rom1504> hansihe: I agree! that's kind of the goal of https://www.wikidata.org/wiki/Wikidata:Main_Page for wikipedia 17:01 < rom1504> and we've been trying to generate a wiki.vg/Protocol from the data in http://prismarinejs.github.io/minecraft-data/?d=protocol 17:01 < rom1504> (which is not finished but it's interesting already) 17:02 < hansihe> oh, nice! 17:02 < rom1504> but really data expressed in wiki table are going to be around for some time, that's why I've been writting extractor from the wiki 17:02 < rom1504> but it would be nice if it were the other way around indeed 17:03 < rom1504> feel free to write a manual .json though ;) 17:03 < rom1504> we can always write an extractor for it later if it makes sense 17:04 < hansihe> yep 17:04 < hansihe> "0 but diffuses sky light at the top-most block" 17:04 < hansihe> anyone understand this? 17:05 < hansihe> i don't think i completely understand skylight 17:09 < rom1504> I don't understand anything about lights :d, I've been doing light:15 and skylight:15 for all blocks in flying-squid :D 17:09 < rom1504> I guess it means it produce light in the top of the light column 17:09 < rom1504> not sure what that means 17:10 < rom1504> probably need to understand the light algorithms to understand that 17:17 < hansihe> right 17:23 < nickelpro> light_block is the light cast by other blocks and is constant. A torch always gives off the same amount of light 17:24 < nickelpro> light_sky if the amount of light from the sun that block is exposed to at Notchian noon. The value is always the same but the calculated light level depends on the time of day 17:25 < morfin> sounds not very complicated 17:25 < nickelpro> So the light level of a block is max(light_block, f(light_sky)) where f is a function that accounts of time_of_day 17:25 < morfin> it's more complicated on client-side i think(rendering) 17:26 < nickelpro> Server needs to know that light level for mob spawning reasons 17:26 < hansihe> yeah, that's the way the rendering is done, i think i understand 17:26 < hansihe> you know how sky light level is calculated? 17:29 < nickelpro> The value the server sends is based on how many transparent blocks are above the base block, the max value is 15 I think. If Leaves are in the way for example, the server might send 13. If a cobble block is above, the value will be 0. I don't know the exact calculation for transparent blocks and I don't know the exact time_of_day function either. But I would bet money they're not that hard to find in MCP 17:29 < morfin> hmm 17:30 < hansihe> you know what happens if there are more then 15 transparent blocks above? 17:30 < hansihe> does it just clamp at 1 and have a more expensive special case in the lighting calculations? 17:30 < morfin> light is equal to 0? 17:31 < nickelpro> Probably equal to 0 17:31 < morfin> how can you check that 17:31 < hansihe> so if there are more then 16 sky blocks, it obscures skylight? 17:31 < hansihe> that's checkable, yeah 17:32 < morfin> i am going to check what happens 17:32 < nickelpro> Ya just check the sky_light light level for a block with 15 transparent blocks above it. Air doesn't count here obviously. The usual choice is leaves, not sure about glass 17:33 < hansihe> glass would probably behave the same way 17:34 < morfin> weird 17:34 < hansihe> just tried it 17:34 < morfin> i built 15 blocks of glass above 17:34 < hansihe> yeah 17:34 < morfin> and nothing bad happened 17:34 < hansihe> still skylight 17:34 < morfin> ... 17:35 < hansihe> might be like i said then, it is clamped at 1 and has a more expensive special case for updating 17:35 < morfin> i think it's not 1 17:35 < morfin> hmm 17:35 < morfin> too bright for 1 17:36 < hansihe> skylight level doesn't affect brightness directly i think 17:36 < nickelpro> There are plenty of mods that will display the light levels for you 17:36 < morfin> yes 17:36 < hansihe> at render time the only think taken into consideration is if the block has skylight or not 17:36 < hansihe> oh wait, f3 displays skylight and block light 17:37 < hansihe> huh, leaves decrement skylight by one, regardless of how many there are 17:37 < hansihe> glass doesn't 17:37 < hansihe> right, this makes sense 17:38 < hansihe> skylight is like block light in every way, except the rendered value varies by time of day 17:39 < morfin> light == 15 17:39 < hansihe> the thing i said earlier is wrong, the exact skylight value is used in rendering, except it is scaled to time of day when rendering 17:39 < hansihe> which is what nickel was talking about 17:39 < morfin> i build special tower with 2x2x15 glass 17:40 < hansihe> yeah, glass doesn't reduce skylight at all 17:40 < hansihe> try the same thing with leaves, you will see there are light level 14 underneath 17:42 < morfin> weird 17:42 < morfin> when i am below single solid block i get -1 of skylight 17:42 < morfin> so it's 14 17:43 < hansihe> oh wait 17:43 < morfin> stained glass is transparent? oO 17:43 < hansihe> leaves decrement skylight by 1 for every block 17:43 < morfin> oh 17:43 < hansihe> yeah, stained glass behaves like normal glass 17:44 < morfin> same for i ice i think 17:44 < morfin> i just tested 17:45 < hansihe> ice is same as leaves 17:45 < morfin> yes i meant -1 for every block 17:45 < hansihe> ah, yep 17:45 < morfin> or not... 17:46 < morfin> i got 10 below 2x2 layer of ice 17:46 < hansihe> yeah 17:46 < morfin> magic 17:46 < hansihe> neither ice or leaves let the ray going from the top of the world through 17:47 < hansihe> it stops the ray itself, but then is transparent to the skylight spread 17:47 < morfin> 5 blocks of ice == 0 light 17:48 < morfin> right now i am in absolutely dark plce 17:48 < hansihe> okey, not totally transparent then, it has opaqueness of 3 17:49 < hansihe> whereas glass and air has 1 17:49 < morfin> hmm 17:49 < hansihe> works the same way with normal light 17:50 < hansihe> i understand i think 17:50 < morfin> hmm 17:50 < morfin> ice is strange 17:51 < hansihe> when calculating skylight, a ray is cast from the top of the world until it hits a block that is considered opaque to the skylight ray