Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

[1.16.4]DataPack, Object.class, RegisterObject, Custom Fluid, How to?


Cratthorax
 Share

Recommended Posts

Good morning,

now with the new Data Pack system in place, I'd like to address a couple of things.

1. is there a comprehensive list of things to do with DataPacks vs item.class?

2. which of the two, code wise, is more efficient/resource friendly?

3. Can you bake any item.class property to the register method?

In special, I'd like to comprehend how to define an item as FoodItem in the DataPack? This doesn't seem to be covered on any of the MC Wiki's?

Link to comment
Share on other sites

Posted (edited)

Ok. So how do I connect the ItemFood.class to already existing items imported via DataPacks then? I assumed this would happen automatically when using the same internal name, but it didn't.

I tried this already 3 times, but failed miserably. Then I got annoyed because I'd failed at something(supposedly) so trivial, and never tried again.

Edited by Cratthorax
Link to comment
Share on other sites

Posted (edited)

Ok. I was about to say "wtf!" since you two guys were just recommending to me 2 weeks ago, or so, to do items/blocks via DataPacks.

So if I use the same ID that I'm using for said item/block in my registerMain.class, will it refer to the corresponding item/block.class? Because I'm already using that kind of code structure in my registry for items/blocks:

 
     public static final RegistryObject<Block> BLOCKZINCITE = BLOCKS.register("blockzincite", 
            () -> new Block(
                    Block.Properties
                        .create(Material.ROCK)
                        .hardnessAndResistance(3.0f, 30.0f)
                        .sound(SoundType.STONE)
                        .harvestLevel(1)
                        .harvestTool(ToolType.PICKAXE)
            )
        );
        
    public static final RegistryObject<Item> BLOCKZINCITEITEM = ITEMS.register("blockzincite", 
        () -> new BlockItem(BLOCKZINCITE.get(),
                   new Item.Properties().group(MATERIALEVOLUTION_GROUP)
        )
    );
Edited by Cratthorax
Link to comment
Share on other sites

11 minutes ago, Cratthorax said:

Ok. I was about to say "wtf!" since you two guys were just recommending to me 2 weeks ago, or so, to do items/blocks via DataPacks.

what? in which thread?

 

12 minutes ago, Cratthorax said:

So if I use the same ID that I'm using for said item/block in my registerMain.class, will it refer to the corresponding item/block.class? Because I'm already using that kind of code structure in my registry for items/blocks:

what's the problem with the code? because it looks good

Link to comment
Share on other sites

Quote

what's the problem with the code? because it looks good

Quite easy. I don't know how to embed item.class code into registry methods...;)

So I can entirely mimic item.class code inside a registry method as well?

Link to comment
Share on other sites

Posted (edited)

Well, me neither English. So language barriers are indeed a problem sometimes.

The above code I posted is sitting inside my registry.class, where I register all blocks/items. I combine this with DataPacks to create the items/blocks via .json. Now @Sieben said you can't do all you want inside the DataPacks, that you could do inside a "regular" item.class. But since the registry method already does what I had done inside the item.class in the past, I'm asking if all methods that I would use in the item.class are useable in the registry method properties as well?

Edited by Cratthorax
Link to comment
Share on other sites

30 minutes ago, Cratthorax said:

But since the registry method already does what I had done inside the item.class in the past, I'm asking if all methods that I would use in the item.class are useable in the registry method properties as well?

Item.Properties set only the properties like stackSize, durability or the CreativeTab.
if you want to create a Item with logic you need to extends the Item class, you can look at the vanilla Item classes for examples

Link to comment
Share on other sites

On 10/9/2021 at 11:17 AM, Cratthorax said:

Ok. I was about to say "wtf!" since you two guys were just recommending to me 2 weeks ago, or so, to do items/blocks via DataPacks.

False. Your first thread on this very forum on this topic was this one in which you were already under the assumption that items and blocks were done via datapacks. The first reply even says "no you don't" and linked you the relevant documentation.

Unless you mean this post which was referring to the blockstate, model, and loot table files which was already in reply to your complaint that datapacks are a hassle.

Edited by Draco18s
  • Like 1

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

On 10/11/2021 at 7:09 PM, Draco18s said:

False. Your first thread on this very forum on this topic was this one in which you were already under the assumption that items and blocks were done via datapacks. The first reply even says "no you don't" and linked you the relevant documentation.

Unless you mean this post which was referring to the blockstate, model, and loot table files which was already in reply to your complaint that datapacks are a hassle.

Yeah. Obviously I had the details mixed up. Forgive me, as I am still in a state of confusion about the whole DataPack way of doing things.

But I get to understand a bit more every week.

So, if I have registered my item like this:

    public static final RegistryObject<Item> GRAVELANTIMONY = ITEMS.register("gravelantimony", 
            () -> new Item(
                    new Item.Properties().group(MATLIB_GROUP)));

Which would be the correct naming for the corresponding item.class? The one with the capital letters, or the non capital letters?

The DataPacks are referring to the one with non capital inside the strings, but the actual .json files have the corresponding object type as starting name convention, like this f.e:

blockantimony
itemgravelantimony
fluidcrudeoil etc. etc. etc.

Oh wait. The actual item.class is supposed to have the same naming convention as the DataPack name declaration, right?

Edit: shit's going to get even more confused now, since I just last week started to implement custom fluids. But I'm gonna make a new thread for this.

Edited by Cratthorax
Link to comment
Share on other sites

29 minutes ago, Cratthorax said:

Which would be the correct naming for the corresponding item.class? The one with the capital letters, or the non capital letters?

You can name your item class whatever you want. The name of the class does not matter to the game. You can make it an anonymous inner class if you wanted to.

30 minutes ago, Cratthorax said:

The DataPacks are referring to the one with non capital inside the strings, but the actual .json files have the corresponding object type as starting name convention, like this f.e:

blockantimony
itemgravelantimony
fluidcrudeoil etc. etc. etc.

Oh wait. The actual item.class is supposed to have the same naming convention as the DataPack name declaration, right?

Your class name is entirely irrelevant. What matters is the registry name, which is the first argument to the register call.

Link to comment
Share on other sites

I'm sorry, but you guys seem to understand my problem just as much as I understand the technical details you're directing me at.

What you said @Sieben is not my problem.

My problem is, I, somehow managed to create a custom object(regardless of being block, item, or fluid, or whatever) without using an actual item./block./fluid.class. And I fail at connecting a(n) item/block/fluid.class to the registered version of my already existing object. Hence why I'm asking which name I need to give the .class object in order to make the registered object use the .class's logic?

So again, if I have my registered object:

    public static final RegistryObject<Item> GRAVELANTIMONY = ITEMS.register("gravelantimony",              () -> new Item(                     new Item.Properties().group(MATLIB_GROUP)));

And I have my item.class which is named ItemGravelAntimony.java, and use the naming method posted downside, inside the item.class, why does the registered item not make use of the actual item.class?

    public ItemGravelAntimony(String name){
        this(name, MatLibMain.MODID, "item/" + "gravelantimony");
    }
Edited by Cratthorax
Link to comment
Share on other sites

1 hour ago, Cratthorax said:

And I have my item.class which is named ItemGravelAntimony.java, and use the naming method posted downside, inside the item.class, why does the registered item not make use of the actual item.class?

 

Because you registered a new Item, not a new ItemGravelAntimony. Please learn basic Java.

Link to comment
Share on other sites

@Sieben, always a charming...:D

I already made clear that I'm not a coder, but a mod building hacker. The reason for this has been stated as well. Limited time and other obligations. I do hear you though, once I get to be a pensioner, and have the time to spend all my focus on coding Java....in like 20 years from now.

However. The correct answer would have been: "You can either define object.class logic/properties in the place you are doing the register, OR you can do it in the object.class, and then refer to this object.class in your register method. You can't do both, because they are two different objects.".

Quote

did you're ItemGravelAntimony extends the vanilla Item class?

Sure it does. The underlying problem was, and still is, I'm used to 2013/2015 code, and 2021 is far away from that. I have to accept that starting from all over would have been the better solution when I started. But now that I've done so much "conversion work" already, I might have done things more complicated than they need to be.

Edited by Cratthorax
Link to comment
Share on other sites

2 hours ago, Cratthorax said:

I already made clear that I'm not a coder, but a mod building hacker. The reason for this has been stated as well. Limited time and other obligations. I do hear you though, once I get to be a pensioner, and have the time to spend all my focus on coding Java....in like 20 years from now.

You are asking to operate a train without being willing to learn what rails are. Building a mod is programming. By building a mod you are a coder. If you do not want to write programs, you cannot write a mod. A mod is a program. A mod is software.

2 hours ago, Cratthorax said:

However. The correct answer would have been: "You can either define object.class logic/properties in the place you are doing the register, OR you can do it in the object.class, and then refer to this object.class in your register method. You can't do both, because they are two different objects.".

Nothing about this "correct answer" makes any sense.

Link to comment
Share on other sites

I disagree. A coder is someone doing what you just said on a professional level. I'm not a professional. But I get things working, even if it doesn't look nice, and takes ages.

By that I'd label me an endurant tinkerer...:D

You may as well just close this thread, as I figured how to solve my fluid/lake/worldGen problem as well. For anyone interested, it basically also covers the issue I had posted inside here:

How to make a fluid, and spawn in it worldGen(without building an object.class)

Link to comment
Share on other sites

4 hours ago, Cratthorax said:

A coder is someone doing what you just said on a professional level. I'm not a professional. But I get things working, even if it doesn't look nice, and takes ages.

Being a professional software developer, no, a "coder" is "someone who codes."

software developer is the professional term.

At best, you're a script kiddie.

Edited by Draco18s

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

16 hours ago, Draco18s said:

Being a professional software developer, no, a "coder" is "someone who codes."

software developer is the professional term.

At best, you're a script kiddie.

Don't be silly. A script kiddie is capable of basic copy pasting. I can't even do that.

However, one more thing to add. How do you connect the registered FlowingFluidBlock, to your actual FluidBlock.class? I wasn't aware that you can actually customize the FlowingFluidBlock RegistryObject(or any other RegistryObject in that regard). Do it like that, and take info from the vanilla FluidBlocks how to build your FluidBlock.class accordingly:

Change that...


        public static final RegistryObject<FlowingFluidBlock> OIL_BLOCK = MatLibRegister.BLOCKS.register("crudeoil",
            () -> new FlowingFluidBlock(() -> MatLibFluidOil.OIL_FLUID.get(), AbstractBlock.Properties.create(MATOIL)
                    .doesNotBlockMovement().hardnessAndResistance(100f).noDrops()));
     
    ...to that...


        public static final RegistryObject<MyCustomFluidBlock> OIL_BLOCK = MatLibRegister.BLOCKS.register("crudeoil",
            () -> new MyCustomFluidBlock(() -> MatLibFluidOil.OIL_FLUID.get(), AbstractBlock.Properties.create(MATOIL)
                    .doesNotBlockMovement().hardnessAndResistance(100f).noDrops()));

 

...and name your FluidBlock MyCustomFluidBlock.class. As far as I understand you do not want to extend to FlowableFluidBlock, but to FlowableFluid. I've yet to understand why, because in the past a fluid block, was still a block. It seems like it is now an "in between" thingy, or no longer a block at all. I hope someone of the wizards can spread some wisdom on that? And if it's just to ease the tinkering...👍

Edit: If someone wants more learning material, I'd recommend the TechReborn FlowableFluid.class, and their actual Fluid.class(Fabric only, so lots of adaptions needed, but good for getting an idea of structure), or PneumaticCraft(Forge). Notice they seem to be on 1.16.5 or even 1.17.1, but the code is compiling fine and dandy with minor adaptions(for 1.17.1 only?). You'd quickly find traces on how to "adapt" by highlighting methods/fields/etc., and open the declaration. Trouble starts really if references aren't public, because then you have to @Override in a custom.class. Which is something I've yet to learn as well. In the past, for 1.7(yes, that's 2013), it looked something like that:

 
	package com.mofakin.materialevolution.blocks.organics;
	import com.mofakin.materialevolution.MaterialEvolutionModBase;
	import cpw.mods.fml.relauncher.Side;
import cpw.mods.fml.relauncher.SideOnly;
import net.minecraft.block.material.Material;
import net.minecraft.client.renderer.texture.IIconRegister;
import net.minecraft.init.Blocks;
import net.minecraft.util.IIcon;
import net.minecraft.world.IBlockAccess;
import net.minecraft.world.World;
import net.minecraftforge.common.util.ForgeDirection;
import net.minecraftforge.fluids.BlockFluidClassic;
import net.minecraftforge.fluids.Fluid;
	public class BlockCrudeOil extends BlockFluidClassic {
	    @SideOnly(Side.CLIENT)
    protected IIcon stillIcon;
    @SideOnly(Side.CLIENT)
    protected IIcon flowingIcon;
   
    public BlockCrudeOil(Fluid fluid, Material material) {
        
            super(fluid, material);
            setCreativeTab(MaterialEvolutionModBase.materialEvolutionCustomTab);
            setBlockName(MaterialEvolutionModBase.MODID + "_" + "blockCrudeOil");
            
    }
    
    @Override
    public int getFlammability(IBlockAccess world, int x, int y, int z, ForgeDirection face)
    {
        return 300;
    }
    
    @Override
    public boolean isFlammable(IBlockAccess world, int x, int y, int z, ForgeDirection face)
    {
        return true;
    }
    
    public int getFireSpreadSpeed(IBlockAccess world, int x, int y, int z, ForgeDirection face)
    {
        return 100;
    }
   
    @Override
    public IIcon getIcon(int side, int meta) {
            return (side == 0 || side == 1)? stillIcon : flowingIcon;
    }
   
    @SideOnly(Side.CLIENT)
    @Override
    public void registerBlockIcons(IIconRegister register) {
            stillIcon = register.registerIcon("materialEvolution:oil_still");
            flowingIcon = register.registerIcon("materialEvolution:oil_flow");
    }
   
    @Override
    public boolean canDisplace(IBlockAccess world, int x, int y, int z) {
            if (world.getBlock(x,  y,  z).getMaterial().isLiquid()) return false;
            return super.canDisplace(world, x, y, z);
    }
   
    @Override
    public boolean displaceIfPossible(World world, int x, int y, int z) {
            if (world.getBlock(x,  y,  z).getMaterial().isLiquid()) return false;
            return super.displaceIfPossible(world, x, y, z);
    }
   
}
Edited by Cratthorax
Reason: Lots of words in my head aka brain f's
Link to comment
Share on other sites

  • Cratthorax changed the title to [1.16.4]DataPack, Object.class, RegisterObject, Custom Fluid, How to?

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
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.

 Share



×
×
  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.