L12[02:00:03] <MCPBot_Reborn> [TEST CSV] Pushing snapshot_20180404 mappings to Forge Maven.

L13[02:00:07] <MCPBot_Reborn> [TEST CSV] Maven upload successful for mcp_snapshot-20180404-1.12.zip (mappings = "snapshot_20180404" in build.gradle).

L14[02:00:17] <MCPBot_Reborn> Semi-live (every 10 min), Snapshot (daily ~3:00 EST), and Stable (committed) MCPBot mapping exports can be found here: http://export.mcpbot.bspk.rs/

L50[09:51:23] <gigaherz> interesting

L51[09:51:23] <gigaherz> https://minecraft.net/en-us/article/minecraft-snapshot-18w14a

L52[09:51:39] <gigaherz> people are going to hate it XD

L53[09:51:49] <gigaherz> Elytra now requires Phantom Membrane to be repaired

L54[09:51:50] <gigaherz> Phantoms now drop Phantom Membrane instead of leather

L55[09:51:59] <gigaherz> meaning you will have to kill phantoms to repair elytra

L56[09:52:10] <ben_mkiv> aww the ocean looks sweet

L57[09:52:24] <ben_mkiv> well it required another elytra before, didntit?

L58[09:52:51] <gigaherz> no

L59[09:52:57] <gigaherz> you could put one elytra alongside leather

L60[09:52:58] <gigaherz> in an anvil

L61[09:53:03] <ben_mkiv> oh

L72[12:17:17] <axel> can someone do an explanation on how things like the stronghold are generated? i have a lot of troubling imagining things from the code as actual structures

L77[13:05:27] <barteks2x> axel, I can try

L78[13:07:07] <barteks2x> but first let me re-read the code because last time I interacted with it was some moinths ago

L79[13:09:20] <barteks2x> (ping me when you are back)

L80[13:13:43] <axel> im back

L81[13:13:48] <axel> barteks2x

L82[13:14:40] <barteks2x> ok, so the general idea of structure generators is shared between structures and caves/ravines, and it's the MapGenbase class

L83[13:16:09] <barteks2x> It starts by iterating over all chunk coordinates within some radius of the currently generated chunk, and calls some generate() method on all of them, but also giving the position of the actual currently generated chunks. For caves, this allows the generator to only carve the blocks for the current chunk, but for cave thet starts at the position from the iteration

L84[13:17:00] <barteks2x> for actual structures, this is used slightly differently: it doesn't actually set any blocks, and just prepares the StructureStart object, which (iirc) should contain enough information already to know the size of the whole structure

L85[13:17:48] <barteks2x> and then the actual block generation is called from populator, which uses the already in memory information about structure positions

L86[13:19:56] <barteks2x> the data about structures is also saved to NBT so it persists across server restarts

L87[13:20:38] <barteks2x> then actually generating the blocks correctly is a matter of creating StructurePieces that set the right blocks, finding all the StructurePieces that intersect the currently generated chunk and generating the blocks

L88[13:21:25] <barteks2x> what makes it doable is that when creating the whole layout of the structure in code, you don't care about chunks, as long as you don';t need to access any block data (and you shouldn't need to)

L89[13:21:58] <ben_mkiv> sounds pretty complicated for the archived result xD

L90[13:23:04] <barteks2x> this is actually surprisingle simple fopr what it achives

L91[13:23:33] <barteks2x> almost looks like cheating

L92[13:23:43] <ben_mkiv> i would rather parse some schematics and connect them "randomly"

L93[13:23:56] <ben_mkiv> based on the world seed

L94[13:24:03] <barteks2x> instead of parsibg schematincs you have that hardcoded

L95[13:24:07] <barteks2x> and they are randomly connected

L96[13:24:11] <axel> you mean nbt schematics?

L97[13:24:29] <barteks2x> the point is knowing nwhat blocks to set when something asks you "set bloicks for this chunk"

L98[13:24:29] <ben_mkiv> the format actually doesnt really matter

L99[13:24:32] <axel> ben

L100[13:25:16] <ben_mkiv> well, thats just how i would try to solve such problem, may have other downsides

L101[13:25:23] <ben_mkiv> but it would be more flexible in adding new structures

L102[13:25:34] <axel> thank you for the explanation, barteks

L103[13:25:46] <barteks2x> it kind of IS how it works, except the "schematics" are hardcoded. This is not the hard part of it at all

L104[13:26:11] <ben_mkiv> isnt there like some api interface or its in works?

L105[13:26:30] <barteks2x> for overworld, not really, unless one PR got already merged

L106[13:26:40] <barteks2x> for custom dimensions, you get what m,ojang made

L107[13:27:09] <barteks2x> you can implement custom structures this way but it requires knowing a bit about how it works

L108[13:27:13] <axel> im making a custom dimension for the structure, so that doesnt really help me i guess

L109[13:28:09] <barteks2x> if you have custom dimensions, you can implement custom structures using vanilla structure generation code

L110[13:28:17] <barteks2x> you need to extend MapGenStructure

L111[13:29:48] <barteks2x> and really just implement canSpawnStructureAtCoords, and getStructurStart

L112[13:30:09] <barteks2x> your StructureStart constructor should prepare all the structure pieces the way you want, with their bounding boxes set etc...

L113[13:30:35] <barteks2x> and then vanilla will try to find all the structure pieces that intersect a chunk being generated and call the right methods

L114[13:30:36] <ben_mkiv> so it generates the structure before actually starting to spawn it?

L115[13:30:53] <barteks2x> it generates in-memory representation of it before actually setting the blocks

L116[13:32:05] <barteks2x> oh and obviously you have to be able to serialize and deserialize your StructureStart objects

L117[13:32:28] <barteks2x> but basic code for it is al;ready provided in the basic StructureStart class

L118[13:32:44] <barteks2x> you only override that if you need more data stored

L119[13:44:31] <axel> alright, thank you again

L150[21:55:18] <Majora320> I think the mdk download links are currently broken

L151[22:03:41] <Majora320> Huh, never mind