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

[Cratthorax]

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?

[Cratthorax]

I get you would extend the ItemFood class, but can you import class features into DataPacks? As to say, can you make an item ".canBeEaten()"-kind of in Datapacks?

[Cratthorax]

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 October 9, 2021 by Cratthorax

[Luis_ST]

Items are not added via data pack, this includ the FoodItems.

Why did you tried that via data pack (json) and not via java?

Edited October 9, 2021 by Luis_ST

[Cratthorax]

Because it is the recommended way to do it?

[Cratthorax]

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 October 9, 2021 by Cratthorax

[Luis_ST]

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

[Cratthorax]

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?

[Luis_ST]

sorry for asking, but i don't understand what you mean (i'm not from england so my english is okay but not the best)

[Cratthorax]

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 October 9, 2021 by Cratthorax

[Luis_ST]

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

[Draco18s]

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 October 11, 2021 by Draco18s

[Cratthorax]

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 October 13, 2021 by Cratthorax

[Cratthorax]

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 October 14, 2021 by Cratthorax

[Luis_ST]

did you're ItemGravelAntimony extends the vanilla Item class?
because it should

Edited October 14, 2021 by Luis_ST

[Cratthorax]

@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 October 15, 2021 by Cratthorax

[Cratthorax]

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)

[Draco18s]

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

A software developer is the professional term.

At best, you're a script kiddie.

Edited October 15, 2021 by Draco18s

[Cratthorax]

16 hours ago, Draco18s said:

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

A 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 October 16, 2021 by Cratthorax
Reason: Lots of words in my head aka brain f's

[Cratthorax]

Good evening,

a bit more progress and inherited info. I finally managed to understand why I couldn't perfectly connect my registry's to the object.class. You guys were right all the way. It was all about basic understanding of Java, and to correctly use fields, constants, properties etc. It's just one of 6 code languages I'm script kiddying, so bare with me.

It also made sense to understand, that my Fluid.class(not FluidBlock.class) was, from its logic, actually a "register".class just as my main register .class, and I could basically just have used all my fluid.class code inside the general registry as well. So it seems important you also give perfect label/naming/package structure to your mod, though I know from scripting with Papyrus, it isn't the worst thing to multithread.

However, the FluidRegistry.class has the FluidBlock.class registered like that now:

 

	    public static final RegistryObject<BlockCrudeOil> OIL_BLOCK = MatLibRegister.BLOCKS.register("crudeoil",
            () -> new BlockCrudeOil(null, AbstractBlock.Properties.create(MatLibFluidOil.MATOIL)
                    .doesNotBlockMovement().hardnessAndResistance(100f).noDrops()));    
	    /*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()));*/

 

And this is the actual FluidBLock.class:

 

	package com.mofakin.matlib.common.block;
	import com.mofakin.matlib.common.fluid.MatLibFluidOil;
	import net.minecraft.block.BlockState;
import net.minecraft.block.FlowingFluidBlock;
import net.minecraft.entity.player.PlayerEntity;
import net.minecraft.fluid.FlowingFluid;
import net.minecraft.fluid.Fluid;
import net.minecraft.fluid.FluidState;
import net.minecraft.util.Direction;
import net.minecraft.util.math.BlockPos;
import net.minecraft.world.IBlockReader;
	public class BlockCrudeOil extends FlowingFluidBlock {
	    public BlockCrudeOil(Object object, Properties props) {
        super(() -> (FlowingFluid) MatLibFluidOil.OIL_FLUID.get(), props);
    }
	    /*@Override
    public void entityInside(BlockState state, World worldIn, BlockPos pos, Entity entity) {
        if (entity instanceof LivingEntity && entity.tickCount % 10 == 0) {
            entity.hurt(DamageSourcePneumaticCraft.ETCHING_ACID, 1);
        }
    }*/
    
    @Override
    public boolean canHarvestBlock(BlockState state, IBlockReader world, BlockPos pos, PlayerEntity player)
    {
        return false;
    }
    
    @Override
    public int getFlammability(BlockState state, IBlockReader world, BlockPos pos, Direction face)
    {
        return 300;
    }
    
    @Override
    public boolean isFlammable(BlockState state, IBlockReader world, BlockPos pos, Direction face)
    {
        return true;
    }
    
    public int getFireSpreadSpeed(BlockState state, IBlockReader world, BlockPos pos, Direction face)
    {
        return 100;
    }
    
    public boolean canDisplace(FluidState fluidState, IBlockReader blockReader, BlockPos pos, Fluid fluid, Direction direction) {
        return false;
    }    
    
}

 

As you can see I forwarded the "catching" fire, burning, displacing, and "non harvestable" logic as well. Though I had to trace some of the methods back to 

package net.minecraftforge.common.extensions.IForgeBlock;

I changed the thread title as well, because I'm sure I'm not the last to search for this very delicate subject, of building custom fluids for worldGen.

 

Edited October 16, 2021 by Cratthorax

[Draco18s]

1 hour ago, Cratthorax said:

RegistryObject<BlockCrudeOil>

This, by the way, doesn't need to be strictly typed to your class. You could just use RegistryObject<Block>

[Cratthorax]

50 minutes ago, Draco18s said:

This, by the way, doesn't need to be strictly typed to your class. You could just use RegistryObject<Block>

That's interesting you say that. So basically the RegistryObject can be whatever it wants, but the new BlockCrudeOil is the one addressing the object.class?

This might be very well the reason why I can't get my custom oil tags working. I'd still have to "hack" the minecraft.water tag in order to give proper physics etc. to my custom fluid.

I've found some leftover traces from you, over here. But it wasn't a priority on my list, so after some struggle and fail I just moved on to more important topics. I shall test this tag thingy again with my newly gained kiddy skills...:)

Edited October 16, 2021 by Cratthorax

[Draco18s]

3 hours ago, Cratthorax said:

So basically the RegistryObject can be whatever it wants

Well, no. You need to be able to cast the thing you want to register (in this case, a block). You can't make a RegistryObject<Item> store a new Block() for instance.

3 hours ago, Cratthorax said:

but the new BlockCrudeOil is the one addressing the object.class?

That's precisely what the new  keyword does.