devguydan

Read the reply right above yours on how to fix this

Scary

Here are a few examples: https://github.com/Cadiboo/Example-Mod/tree/1.15.2/src/main/java/io/github/cadiboo/examplemod/client/gui

Yes, it does. Fairly good example of it's use too. (template_torch.json) { "ambientocclusion": false, "textures": { "particle": "#torch" }, "elements": [ { "from": [ 7, 0, 7 ], "to": [ 9, 10, 9 ], "shade": false, "faces": { "down": { "uv": [ 7, 13, 9, 15 ], "texture": "#torch" }, "up": { "uv": [ 7, 6, 9, 8 ], "texture": "#torch" } } }, ... ] }

No, I don’t think it looks bad at all. It looks proper, if you mean that the base block of your chimney has a shadow. It would, if the flame light is coming from the furnace that is over an edge, the light would cast a shadow at the very base. Is this what you are referring to as “looks horrible”?

Yes! I was trying to get Deferred registers to work based on what I saw in your example mod, but was getting issues with a null registry. I got it all working without deferred registries now, so I plan to revisit it again next time I get a chance to look at it. Also just curious, what are the benefits of the deferred registries over the event hooks? Sounds like they both register things at the correct time.

It sounds like you have not tried much. What have you tried so far? Have you looked at the player class definition for functions that might do what you want? You aren’t going to find a tutorial for everything.

Check out this excellent example mod: https://github.com/Cadiboo/Example-Mod/. Check out the src/main/resources/examplemod/blockstates. Structure your mod similarly. To see how to control blockstates, check out src/main/java/examplemod/block/ModFurnaceBlock. For an example of plant growth blockstates, here is the blockstates for vanilla's carrots.json: { "variants": { "age=0": { "model": "block/carrots_stage0" }, "age=1": { "model": "block/carrots_stage0" }, "age=2": { "model": "block/carrots_stage1" }, "age=3": { "model": "block/carrots_stage1" }, "age=4": { "model": "block/carrots_stage2" }, "age=5": { "model": "block/carrots_stage2" }, "age=6": { "model": "block/carrots_stage2" }, "age=7": { "model": "block/carrots_stage3" } } } Here are the corresponding models for carrots: This is carrots_stage3.json, but obviously the other stages are very similar. { "parent": "block/crop", "textures": { "crop": "block/carrots_stage3" } } You can find all these your self in your External Libraries in Gradle: net.minecraft:client:extra.<version> All this should be more than enough to get you started and more than anyone else here will give you. You'll need to do the rest of the discovery and experimentation yourself. Best of luck.

Just taking a shot in the dark, but would this be block states with different assets? Just give each stage of growth a block state and a corresponding texture.

Yes, either find the func_... function that matches the signature, or update your mappings channel: 'snapshot', '....' in build.gradle

I have been digging through forge, and have not seen how vanilla generates ores yet. I did see the ChunkEvent, which looks promising. Mind pointing me what directories to look in for vanilla world generation? Not too familiar with the code base yet. For anyone in the future, check `DefaultBiomeFeatures` for implementation for structure, entities, ores, blocks, etc

haha Thanks will do Btw the 1.14 version is different. Credit to

biomeIn.addFeature(GenerationStage.Decoration.UNDERGROUND_ORES, Biome.createDecoratedFeature(Feature.ORE, new OreFeatureConfig(OreFeatureConfig.FillerBlockType.NATURAL_STONE, Blocks.DIAMOND_ORE.getDefaultState(), 8), Placement.COUNT_RANGE, new CountRangeConfig(1, 0, 0, 16))); This is how vanilla registers underground ores. Unfortunately there is no `createDecoratedFeature` function in `Biome` use in `ForgeRegistries.BIOMES`. Vanilla MC has this function in it's Biome class, but Forge's Biome class does not have anything matching this signature. Instead what works is to addFeature with a Underground Ores Decoration, and pass it your ore with a config, giving the config a filler block, your own ore, and the max size to generate the ores in. Then pass a placement config with min and max height, max generation per chunk, etc: @SuppressWarnings({"ConstantConditions"}) @SubscribeEvent public static void FMLLoadCompleteEvent(FMLLoadCompleteEvent event) { for (Biome biome : ForgeRegistries.BIOMES) { biome.addFeature(GenerationStage.Decoration.UNDERGROUND_ORES, Feature.ORE.withConfiguration(new OreFeatureConfig( OreFeatureConfig.FillerBlockType.NATURAL_STONE, ModBlocks.LOAD_STONE_ORE.getDefaultState(), 8)) .withPlacement(Placement.COUNT_RANGE.configure(new CountRangeConfig(4, 0, 0, 32)))); } } This is in my ModEventSubscriber class obviously. Now I want to make sure I am reading it correctly. Is this saying, that once per chuck (ie, once per 65,536 blocks), it will generate up to 9 ores in a group, and that group may be generated anywhere between levels 0 and 16? If so then the above vanilla example means diamond groups only generate once per 65k blocks? I find that hard to believe. Also for a side note, would updating my snapshot in `build.gradle` give me better names for functions? I am currently using the default 1.15.2 mdk build file with mappings channel: 'snapshot', version: '20190719-1.14.3' Edit: updating this DID resolve some more obsfucated function names.

@SuppressWarnings({"ConstantConditions"}) @SubscribeEvent public static void FMLLoadCompleteEvent(FMLLoadCompleteEvent event) { for (Biome biome : ForgeRegistries.BIOMES) { biome.addFeature(GenerationStage.Decoration.UNDERGROUND_ORES, Feature.ORE.withConfiguration(new OreFeatureConfig( OreFeatureConfig.FillerBlockType.NATURAL_STONE, ModBlocks.LOAD_STONE_ORE.getDefaultState(), 8)) .withPlacement(Placement.COUNT_RANGE.configure(new CountRangeConfig(4, 0, 0, 32)))); } } Tried this, but unfortunately, withConfiguration is not a function in my case. Note sure why yet. Ok turns out mine was "obsfucated" still? instead of withConfiguration I have func_225566_b_. Anyone know why this happens?

Thanks so much, will give this a go

haha Thanks will do I have been digging through forge, and have not seen how vanilla generates ores yet. I did see the ChunkEvent, which looks promising. Mind pointing me what directories to look in for vanilla world generation? Not too familiar with the code base yet.

Looking for a good place to start to generate my custom ores and entities for 1.15. I previously tried a way that was written for 1.12 and no luck. I found a way for 1.14 on here, and will try that when I get home, but wondering if anyone has recommendations for best practices and methods for 1.15. I currently have my custom ore, ingot, and block. I want to generate that ore in levels 5-25 for example so players can find it.

It’s funny seeing how much stuff I did not know back then. I understand all this now, and am lost and confused on completely different things now, yay! And I can’t believe this was less than a year ago. I don’t remember it at all.

Hey does anyone know if these methods will work for 1.15? I am new to moddding as well, but have created a basic mod with a special ore, resulting ingot, and block, that works. However, I am struggling to get the custom ore to generate in the world. I think the stuff I have been going off of are too outdated (1.12), but this gives me hope, being 1.14. Does anyone know a good place to find how to insert custom ore generation in the over world in 1.15? I’ll try this stuff when I get home and update if these methods do indeed work for 1.15

See that’s what I mean. He uses common proxy and he doesn’t use even handlers for registration. Yet every one still recommends him as an example?

First, I often have been seeing this. Where it is recommended to register/create blocks, items and entities in pre-init. Instead of in EventHandlers. I even saw one case where it was said EventHandlers run B4 pre-init, but after debugging, I found that was not the case. What is the current best practice in this regard? Here is an example of this practice /** * Run before anything else. Read your config, create blocks, items, etc, and register them with the GameRegistry */ public void preInit() { // register my Items, Blocks, Entities, etc }

Trying to make sure I understand the lifecycle and best practices properly. The problem is, many tutorials, code examples, and even the docs, use practices that are either definitely outdated or contradict the logic that many people here have put forward. So I'm just going to start putting them here when I see something I think is like that. If anyone can clarify on any given code example, that would be great. I'll try to make the code examples isolated and clear what particular practice or aspect I am asking about.

Ok I totally misunderstood their purpose then. So I know they are refreshed after block, item, and then all other registry events. What does "refreshed" do to them and why? What do they get used for down the line?

Just got to models https://mcforge.readthedocs.io/en/latest/models/introduction/ this has to be it

Ok I lowercase and matched my registry names. I made the @ObjectHolder variable final, and created the Block when registering it? Not sure how to do this part @SubscribeEvent public static void addBlocks(RegistryEvent.Register<Block> event) { Blocks.myRock.setHardness(0.1f); Blocks.myRock.setCreativeTab(CreativeTabs.MATERIALS); Blocks.myRock.setRegistryName(MOD_ID,"myrock"); event.getRegistry().register(new Block(Material.ROCK)); }