Jump to content

[1.8] Natural vs. Manufactured block detection


tool_user

Recommended Posts

I am working on some things where I want to identify if a block is natural (stone, log, sand, dirt, gravel, etc.) or manufactured (cobblestone, plank, stone brick, brick, etc.).  Is there any function somewhere (world gen, ore dict, materials, etc.) that would help with this? I have a basic function now in my mod where I have all the "natural" blocks, but I'd like to have something that would be compatible with other mods without having to resort to a manual config file.  I've looked through world gen a little, crafting manager (doesn't work because of things like sandstone), and the ore dict.

 

I'm looking for direct answers such there is on in XYZ place, or places to look that I might be able to tap into would be great.

 

Thanks.

Link to comment
Share on other sites

You will not be able to tell that the player has placed a block vs. the same block placed during worldgen.  It is not possible because that data is not stored anywhere in the chunk data.

 

You could in theory use metadata to do this, but only for blocks that had a bitflag to spare, but with the new BlockState mechanism that 1.8 has, I am not sure you can do that any more.

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Link to comment
Share on other sites

Another very hacky idea:

Whenever manufactured block is placed, add to chunk saved data it's position.

Now, when you want to check if block is manufactured or not, just check list of manufactured blocks in this chunk.

 

Although there are 2 not sure things here:

-I don't know if there's chunk saved data, but i know for sure that there are Chunk.Save and Chunk.Load events that you can use to save list of manufactired blocks.

-Depending on what you call manufactured block, it can be easy or even nearly impossible. If it's player placed block, there are events you can use. For everything else, there's no proper way of detecting source of placement. (Well, you can ASM chunk class and read stack traces to find placement source, but is it worth it?).

Link to comment
Share on other sites

Thanks for the feedback!

 

Sorry!  I don't actually want to tell if the player placed the block, but if it is a naturally occurring block. Basically trying to separate mostly natural terrain from something someone probably made.  Obviously, if they make something out of dirt or sandstone, I can't detect those blocks.

 

Right now in my "is natural" routine I am just doing this:

    public static boolean isNatural(IBlockState state)
    {
        Block block = state.getBlock();
        return (block == Blocks.stone ||
                block == Blocks.gravel ||
                block == Blocks.log ||
                block == Blocks.log2 ||
                block == Blocks.leaves ||
                block == Blocks.leaves2 ||
                block == Blocks.sand ||
                block == Blocks.sandstone ||
                block == Blocks.dirt ||
                block == Blocks.grass);
    }

 

This seems to work ok as things like "Block.stone" covers diorite, andesite, etc. I was just hoping for some clever way to use the crafting manager or ore dict.

 

Link to comment
Share on other sites

The important question I have is do you mean to detect something that is manufacturable, or do you want to detect things that were specifically manufactured by a player? Because some manufacturable blocks will spawn naturally in structures and villages.

 

If you just want to check if a block can be manufactured, I think you can do it by just looking to see if there is a crafting recipe that creates it.

Check out my tutorials here: http://jabelarminecraft.blogspot.com/

Link to comment
Share on other sites

It is impossible to do this fail-safe either way, because:

  • If you're trying to tell whether an item can be manufactured, you have to know all the ways in which an item can be manufactured (crafted, smelted, etc.). If mods add their own ways of manufacturing (e.g. pulverizers), you may not always know if an item can be manufactured in that way.
  • If you're trying to tell whether a block is naturally generated, you've basically got no chance. The best chance you've got is searching through ASM data, but even a best-effort algorithm to test if a block is naturally generated would still fail about 50% of the time. You've got a bit more chance with items generated in chests, as Forge has hooks for chest generation, and even more chance with mob drops, provided you have an instance of World.

 

Even after all that, there still might be a way to be about 90% sure that an item can be manufactured: use NEI. Most mods which add extra machines will register their crafting recipes to NEI, so you have less chance of missing any manufacturing methods.

 

You can also find a list of blocks and whether they are naturally generated on the Minecraft Wiki.

 

Hope this helps :)

catch(Exception e)

{

 

}

Yay, Pokémon exception handling, gotta catch 'em all (and then do nothing with 'em).

Link to comment
Share on other sites

Once you have other mods and things like the IC2 Macerator, almost everything can be crafted.  There's a few more mods that add even more ways of crafting things.  Such as seeds + dirt = grass.

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Link to comment
Share on other sites

Well compatibility with other mods would take work, but wouldn't necessarily be impossible. For mods that modify or add to the existing recipe systems, you can still just search the recipes. For mods that use their own recipe system, it would be "impossible" to make a general solution, but if you wanted to cover the major mods that people are using you can handle each one -- basically just detect whether the mod is loaded, and if it is proceed accordingly. Things like uncrafting tables, grinders, etc. usually reduce things to natural ingredients so those might not be an issue. But certainly any custom crafting / smelting that uses a separate recipe system would need you to code for it.

 

But really it wouldn't be that much work. If a certain mod is loaded, you can just add to your list of "manufactured" blocks based on what you know about the mod's functionality.

Check out my tutorials here: http://jabelarminecraft.blogspot.com/

Link to comment
Share on other sites

Thanks everyone for the input, it seems to share what I found during my research.

 

To answer a few of the questions that came up.  I just want a way to easily separate "natural" things from man-made things.  I am working on yet another set of creative mod tools (structure builders, tunnelers, etc.) for fun and some of the features I'd like to add would like to be able to discriminate between "ground" (natural) and something built.  For example a road builder wants to walk the terrain and not go "over" structures or even remove them.  I also want to make a "cleanup" that removes all non-natural blocks so I can remove unwanted structures easily.

 

I think my approach (for now) is basically going to detect "natural" based on block type (by name) then just support a config file.  Since I have a robust undo (in transient memory), if it doesn't detect right the person can undo the work, or manually fix it.  I'll probably add a tool (wand) so they user can right-click to add the block to the config file easily, so they won't need to leave the game.

 

Again, thanks all for the quick feedback and insight!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • Try deliting feur builder  It caused this issue in my modpack
    • I am not using hardcoded recipes, I'm using Vanilla's already existing code for leather armor dying. (via extending and implementing DyeableArmorItem / DyeableLeatherItem respectively) I have actually figured out that it's something to do with registering item colors to the ItemColors instance, but I'm trying to figure out where exactly in my mod's code I would be placing a call to the required event handler. Unfortunately the tutorial is criminally undescriptive. The most I've found is that it has to be done during client initialization. I'm currently trying to do the necessary setup via hijacking the item registry since trying to modify the item classes directly (via using SubscribeEvent in the item's constructor didn't work. Class so far: // mrrp mrow - mcmod item painter v1.0 - catzrule ch package catzadvitems.init; import net.minecraft.client.color.item.ItemColors; import net.minecraft.world.item.Item; import net.minecraftforge.registries.ObjectHolder; import net.minecraftforge.fml.event.lifecycle.FMLClientSetupEvent; import net.minecraftforge.fml.common.Mod; import net.minecraftforge.eventbus.api.SubscribeEvent; import net.minecraftforge.client.event.ColorHandlerEvent; import catzadvitems.item.DyeableWoolArmorItem; @Mod.EventBusSubscriber(bus = Mod.EventBusSubscriber.Bus.MOD) public class Painter { @ObjectHolder("cai:dyeable_wool_chestplate") public static final Item W_CHEST = null; @ObjectHolder("cai:dyeable_wool_leggings") public static final Item W_LEGS = null; @ObjectHolder("cai:dyeable_wool_boots") public static final Item W_SOCKS = null; public Painter() { // left blank, idk if forge throws a fit if constructors are missing, not taking the chance of it happening. } @SubscribeEvent public static void init(FMLClientSetupEvent event) { new Painter(); } @Mod.EventBusSubscriber private static class ForgeBusEvents { @SubscribeEvent public static void registerItemColors(ColorHandlerEvent.Item event) { ItemColors col = event.getItemColors(); col.register(DyeableUnderArmorItem::getItemDyedColor, W_CHEST, W_LEGS, W_SOCKS); //placeholder for other dye-able items here later.. } } } (for those wondering, i couldn't think of a creative wool helmet name)
    • nvm found out it was because i had create h and not f
    • Maybe there's something happening in the 'leather armor + dye' recipe itself that would be updating the held item texture?
    • @SubscribeEvent public static void onRenderPlayer(RenderPlayerEvent.Pre e) { e.setCanceled(true); model.renderToBuffer(e.getPoseStack(), pBuffer, e.getPackedLight(), 0f, 0f, 0f, 0f, 0f); //ToaPlayerRenderer.render(); } Since getting the render method from a separate class is proving to be bit of a brick wall for me (but seems to be the solution in older versions of minecraft/forge) I've decided to try and pursue using the renderToBuffer method directly from the model itself. I've tried this route before but can't figure out what variables to feed it for the vertexConsumer and still can't seem to figure it out; if this is even a path to pursue.  The vanilla model files do not include any form of render methods, and seem to be fully constructed from their layer definitions? Their renderer files seem to take their layers which are used by the render method in the vanilla MobRenderer class. But for modded entities we @Override this function and don't have to feed the method variables because of that? I assume that the render method in the extended renderer takes the layer definitions from the renderer classes which take those from the model files. Or maybe instead of trying to use a render method I should be calling the super from the renderer like   new ToaPlayerRenderer(context, false); Except I'm not sure what I would provide for context? There's a context method in the vanilla EntityRendererProvider class which doesn't look especially helpful. I've been trying something like <e.getEntity(), model<e.getEntity()>> since that generally seems to be what is provided to the renderers for context, but I don't know if it's THE context I'm looking for? Especially since the method being called doesn't want to take this or variations of this.   In short; I feel like I'm super super close but I have to be missing something obvious? Maybe this insane inane ramble post will provide some insight into this puzzle?
  • Topics

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.